{
    "version": "https:\/\/jsonfeed.org\/version\/1.1",
    "title": "Yuriy Gavrilov: posts tagged Quickwit",
    "_rss_description": "Welcome to my personal place for love, peace and happiness 🤖 Yuiry Gavrilov",
    "_rss_language": "en",
    "_itunes_email": "yvgavrilov@gmail.com",
    "_itunes_categories_xml": "",
    "_itunes_image": "https:\/\/gavrilov.info\/pictures\/userpic\/userpic-square@2x.jpg?1643451008",
    "_itunes_explicit": "no",
    "home_page_url": "https:\/\/gavrilov.info\/tags\/quickwit\/",
    "feed_url": "https:\/\/gavrilov.info\/tags\/quickwit\/json\/",
    "icon": "https:\/\/gavrilov.info\/pictures\/userpic\/userpic@2x.jpg?1643451008",
    "authors": [
        {
            "name": "Yuriy Gavrilov - B[u]g - for charity.gavrilov.eth",
            "url": "https:\/\/gavrilov.info\/",
            "avatar": "https:\/\/gavrilov.info\/pictures\/userpic\/userpic@2x.jpg?1643451008"
        }
    ],
    "items": [
        {
            "id": "143",
            "url": "https:\/\/gavrilov.info\/all\/kak-binance-stroil-100pb-servis-dlya-obrabotki-logov-na-quickwit\/",
            "title": "Как Binance строил 100PB сервис для обработки логов на Quickwit",
            "content_html": "<p>Оригинал: <a href=\"https:\/\/quickwit.io\/blog\/quickwit-binance-story\">https:\/\/quickwit.io\/blog\/quickwit-binance-story<\/a><\/p>\n<p>Три года назад мы открыли исходный код Quickwit, распределенного поискового движка для работы с большими объемами данных. Наша цель была амбициозной: создать новый тип полнотекстового поискового движка, который был бы в десять раз более экономичным, чем Elasticsearch, значительно проще в настройке и управлении, и способным масштабироваться до петабайт данных.<\/p>\n<p>Хотя мы знали потенциал Quickwit, наши тесты обычно не превышали 100 ТБ данных и 1 ГБ\/с скорости индексации. У нас не было реальных наборов данных и вычислительных ресурсов для тестирования Quickwit в масштабе нескольких петабайт.<\/p>\n<p>Это изменилось шесть месяцев назад, когда два инженера из Binance, ведущей криптовалютной биржи, обнаружили Quickwit и начали экспериментировать с ним. В течение нескольких месяцев они достигли того, о чем мы только мечтали: они успешно перенесли несколько кластеров Elasticsearch объемом в петабайты на Quickwit, достигнув при этом следующих результатов:<\/p>\n<ul>\n<li>Масштабирование индексации до 1,6 ПБ в день.<\/li>\n<li>Операция поискового кластера, обрабатывающего 100 ПБ логов.<\/li>\n<li>Экономия миллионов долларов ежегодно за счет сокращения затрат на вычисления на 80% и затрат на хранение в 20 раз (при том же периоде хранения).<\/li>\n<li>Значительное увеличение возможностей хранения данных.<\/li>\n<li>Упрощение управления и эксплуатации кластера благодаря хорошо спроектированной многокластерной установке.<\/li>\n<\/ul>\n<p>В этом блоге я расскажу вам, как Binance построила сервис логов объемом в петабайты и преодолела вызовы масштабирования Quickwit до нескольких петабайт.<\/p>\n<p><b>Вызов Binance<\/b><\/p>\n<p>Как ведущая криптовалютная биржа, Binance обрабатывает огромное количество транзакций, каждая из которых генерирует логи, важные для безопасности, соответствия и оперативных аналитических данных. Это приводит к обработке примерно 21 миллиона строк логов в секунду, что эквивалентно 18,5 ГБ\/с или 1,6 ПБ в день.<\/p>\n<p>Для управления таким объемом Binance ранее полагалась на 20 кластеров Elasticsearch. Около 600 модулей Vector извлекали логи из различных тем Kafka и обрабатывали их перед отправкой в Elasticsearch.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/gavrilov.info\/pictures\/image-55.png\" width=\"1889\" height=\"856\" alt=\"\" \/>\n<\/div>\n<p><b>Настройка Elasticsearch в Binance<\/b><\/p>\n<p>Однако эта установка не удовлетворяла требованиям Binance в нескольких критических областях:<\/p>\n<ul>\n<li><b>Операционная сложность<\/b>: Управление многочисленными кластерами Elasticsearch становилось все более сложным и трудоемким.<\/li>\n<li><b>Ограниченное хранение<\/b>: Binance хранила большинство логов только несколько дней. Их целью было продлить этот срок до месяцев, что требовало хранения и управления 100 ПБ логов, что было чрезвычайно дорого и сложно с их настройкой Elasticsearch.<\/li>\n<li><b>Ограниченная надежность<\/b>: Кластеры Elasticsearch с высокой пропускной способностью были настроены без репликации для ограничения затрат на инфраструктуру, что компрометировало долговечность и доступность.<\/li>\n<\/ul>\n<p>Команда знала, что им нужно радикальное изменение, чтобы удовлетворить растущие потребности в управлении, хранении и анализе логов.<\/p>\n<p><b>Почему Quickwit был (почти) идеальным решением<\/b><\/p>\n<p>Когда инженеры Binance обнаружили Quickwit, они быстро поняли, что он предлагает несколько ключевых преимуществ по сравнению с их текущей установкой:<\/p>\n<ul>\n<li><b>Нативная интеграция с Kafka<\/b>: Позволяет инжектировать логи непосредственно из Kafka с семантикой “ровно один раз”, что дает огромные операционные преимущества.<\/li>\n<li><b>Встроенные преобразования VRL (Vector Remap Language)<\/b>: Поскольку Quickwit поддерживает VRL, нет необходимости в сотнях модулей Vector для обработки преобразований логов.<\/li>\n<li><b>Объектное хранилище в качестве основного хранилища<\/b>: Все проиндексированные данные остаются в объектном хранилище, устраняя необходимость в предоставлении и управлении хранилищем на стороне кластера.<\/li>\n<li><b>Лучшее сжатие данных<\/b>: Quickwit обычно достигает в 2 раза лучшего сжатия, чем Elasticsearch, что еще больше сокращает занимаемое место индексами.<\/li>\n<\/ul>\n<p>Однако ни один пользователь не масштабировал Quickwit до нескольких петабайт, и любой инженер знает, что масштабирование системы в 10 или 100 раз может выявить неожиданные проблемы. Это не остановило их, и они были готовы принять вызов!<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/gavrilov.info\/pictures\/image-56.png\" width=\"577\" height=\"433\" alt=\"\" \/>\n<\/div>\n<p><b>Поиск в 100 ПБ, вызов принят<\/b><\/p>\n<p><b>Масштабирование индексации на 1,6 ПБ в день<\/b><\/p>\n<p>Binance быстро масштабировала свою индексацию благодаря источнику данных Kafka. Через месяц после начала пилотного проекта Quickwit они индексировали на нескольких ГБ\/с.<\/p>\n<p>Этот быстрый прогресс был в значительной степени обусловлен тем, как Quickwit работает с Kafka: Quickwit использует группы потребителей Kafka для распределения нагрузки между несколькими модулями. Каждый модуль индексирует подмножество партиций Kafka и обновляет метахранилище с последними смещениями, обеспечивая семантику “ровно один раз”. Эта установка делает индексаторы Quickwit безсостоятельными: вы можете полностью разобрать свой кластер и перезапустить его, и индексаторы возобновят работу с того места, где они остановились, как будто ничего не произошло.<\/p>\n<p>Однако масштаб Binance выявил две основные проблемы:<\/p>\n<ul>\n<li><b>Проблемы со стабильностью кластера<\/b>: Несколько месяцев назад протокол переговоров Quickwit (называемый Chitchat) с трудом справлялся с сотнями модулей: некоторые индексаторы покидали кластер и возвращались, делая пропускную способность индексации нестабильной.<\/li>\n<li><b>Неоднородное распределение нагрузки<\/b>: Binance использует несколько индексов Quickwit для своих логов, с различной пропускной способностью индексации. Некоторые имеют высокую пропускную способность в несколько ГБ\/с, другие – всего несколько МБ\/с. Алгоритм размещения Quickwit не распределяет нагрузку равномерно. Это известная проблема, и мы будем работать над этим позже в этом году.<\/li>\n<\/ul>\n<p>Чтобы обойти эти ограничения, Binance развернула отдельные кластеры индексации для каждой темы с высокой пропускной способностью, сохраняя один кластер для меньших тем. Изоляция каждого кластера с высокой пропускной способностью не накладывала операционного бремени благодаря безсостоятельным индексаторам. Кроме того, все модули Vector были удалены, так как Binance использовала преобразование Vector непосредственно в Quickwit.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/gavrilov.info\/pictures\/image-57.png\" width=\"2110\" height=\"1183\" alt=\"\" \/>\n<\/div>\n<p><b>Настройка Quickwit в Binance<\/b><\/p>\n<p>После нескольких месяцев миграции и оптимизации Binance наконец достигла пропускной способности индексации в 1,6 ПБ с 10 кластерами индексации Quickwit, 700 модулями, запрашивающими около 4000 vCPU и 6 ТБ памяти, что в среднем составляет 6,6 МБ\/с на vCPU. На заданной теме Kafka с высокой пропускной способностью этот показатель увеличивается до 11 МБ\/с на vCPU.<\/p>\n<p>Следующий вызов: масштабирование поиска!<\/p>\n<p><b>Один поисковый кластер для 100 ПБ логов<\/b><\/p>\n<p>С Quickwit, способным эффективно индексировать 1,6 ПБ ежедневно, вызов сместился к поиску по петабайтам логов. С 10 кластерами Binance обычно потребовалось бы развернуть модули поиска для каждого кластера, что подрывало одно из преимуществ Quickwit: объединение ресурсов поиска для доступа к общему объектному хранилищу всех индексов.<\/p>\n<p>Чтобы избежать этой ловушки, инженеры Binance придумали умный обходной путь: они создали унифицированное метахранилище, реплицируя все метаданные из метахранилища каждого кластера индексации в одну базу данных PostgreSQL. Это унифицированное метахранилище позволяет развернуть один единственный централизованный поисковый кластер, способный искать по всем индексам!<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/gavrilov.info\/pictures\/image-58.png\" width=\"1966\" height=\"1098\" alt=\"\" \/>\n<\/div>\n<p><b>Многокластерная установка Quickwit<\/b><\/p>\n<p>На данный момент Binance управляет разумно размером кластером из 30 модулей поиска, каждый из которых запрашивает 40 vCPU и 100 ГБ памяти. Чтобы дать вам представление, вам нужно всего 5 поисковиков (8 vCPU, 6 ГБ запросов памяти) для нахождения иголки в стоге сена в 400 ТБ логов. Binance выполняет такие запросы на петабайтах, а также запросы агрегации, отсюда и более высокие запросы ресурсов.<\/p>\n<p><b>Заключение<\/b><\/p>\n<p>В целом, миграция Binance на Quickwit была огромным успехом и принесла несколько существенных преимуществ:<\/p>\n<ul>\n<li>Сокращение вычислительных ресурсов на 80% по сравнению с Elasticsearch.<\/li>\n<li>Затраты на хранение сократились в 20 раз при том же периоде хранения.<\/li>\n<li>Экономически жизнеспособное решение для управления большими объемами логов, как с точки зрения затрат на инфраструктуру, так и эксплуатации.<\/li>\n<li>Минимальная настройка конфигурации, эффективно работающая после определения правильного количества модулей и ресурсов.<\/li>\n<li>Увеличение хранения логов до одного или нескольких месяцев в зависимости от типа лога, улучшение возможностей внутренней диагностики.<\/li>\n<\/ul>\n<p>В заключение, миграция Binance с Elasticsearch на Quickwit была захватывающим шестимесячным опытом между инженерами Binance и Quickwit, и мы очень гордимся этим сотрудничеством. Мы уже запланировали улучшения в сжатии данных, поддержке многокластерных систем и лучшем распределении нагрузки с источниками данных Kafka.<\/p>\n<p>Большое спасибо инженерам Binance за их работу и идеи в ходе этой миграции <3<\/p>\n",
            "date_published": "2024-07-04T21:46:49+03:00",
            "date_modified": "2024-07-04T21:46:34+03:00",
            "tags": [
                "big data",
                "Quickwit"
            ],
            "image": "https:\/\/gavrilov.info\/pictures\/image-55.png",
            "_date_published_rfc2822": "Thu, 04 Jul 2024 21:46:49 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "143",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": [
                    "https:\/\/gavrilov.info\/pictures\/image-55.png",
                    "https:\/\/gavrilov.info\/pictures\/image-56.png",
                    "https:\/\/gavrilov.info\/pictures\/image-57.png",
                    "https:\/\/gavrilov.info\/pictures\/image-58.png"
                ]
            }
        }
    ],
    "_e2_version": 4171,
    "_e2_ua_string": "Aegea 11.4 (v4171e)"
}