Как Tencent использует Elasticsearch для добычи триллионов данных?

Оригинал: https://mp.weixin.qq.com/s/FVbjGTvZP97u5CAydDx7dw

предисловие

Elasticsearch (ES) — популярная в последние годы распределенная поисковая и аналитическая система с открытым исходным кодом.Благодаря простому развертыванию она может легко реализовать множество требований, таких как анализ журналов в реальном времени, полнотекстовый поиск и анализ структурированных данных, и значительно сократить стоимость майнинга значения данных.

У ES есть множество крупномасштабных сценариев внедрения внутри Tencent и среди пользователей Tencent Cloud, и они продолжают продвигать оптимизацию собственного ES в направлении высокой доступности, высокой производительности и низкой стоимости. В этой статье будут представлены проблемы, идеи оптимизации, результаты оптимизации и будущие направления исследований, с которыми Tencent столкнулась в процессе применения ES, в надежде предоставить разработчикам справочную информацию.

1. Сценарии применения ЭС

1.Сценарии внутренних приложений Tencent

В Tencent сценарии приложений ES в основном включают «анализ журнала в реальном времени, службу поиска, анализ данных временных рядов и т. д.

1. [Сценарий анализа журнала в реальном времени]

Типичный сценарий выглядит следующим образом:

Оперативный журнал:Например, медленный журнал, журнал исключений (используется для обнаружения бизнес-проблем);

Бизнес журнал:Например, клики пользователей, журналы доступа (используются для анализа поведения пользователей);

Журнал аудита:Может использоваться для анализа безопасности.

ES прекрасно решает задачу анализа логов в реальном времени и обладает следующими характеристиками:

Экосистема Elastic завершена:Любой разработчик может создать полную систему анализа журналов в реальном времени, просто развернув готовые компоненты.

Высокая своевременность:Время, необходимое для создания журнала до того, как он станет доступным, обычно находится на уровне 10 с. По сравнению с традиционными решениями для работы с большими данными, которые занимают от десятков минут до нескольких часов, своевременность повышается в сотни раз.

Гибкие возможности анализа поиска:Благодаря поддержке таких структур данных, как инвертированные индексы и хранилище столбцов, ES обладает очень гибкими возможностями поиска и анализа.

Короткое время отклика поиска:ES поддерживает интерактивный анализ, а время отклика при поиске составляет секунды даже при триллионах журналов.

Энергичное развитие ES в последние годы неотделимо от его способности идеально поддерживать «сценарий анализа журнала в реальном времени».

2.【Сценарии службы поиска】

Типичный сценарий выглядит следующим образом:

поиск продукта:То есть поиск товаров на основных платформах электронной коммерции;

Поиск приложения:То есть поиск приложений в магазине приложений;

Поиск по сайту:То есть функции поиска, такие как форумы и онлайн-документы.

Tencent использует ES для поддержки большого количества поисковых сервисов, которые в основном имеют следующие характеристики:

высокая производительность:Одна служба может достигать максимум 10w+ запросов в секунду, среднее время отклика составляет около 20 мс, а задержка P95 составляет менее 100 мс.

Сильная корреляция: Опыт поиска в основном зависит от соответствия между «результатами поиска» и «намерениями пользователя», которые можно оценить с помощью таких показателей, как уровень точности и уровень отзыва.

Высокая доступность: Сценарии поиска обычно требуют наличия четырех девяток и поддерживают восстановление после сбоя в одной комнате.

3.【Сценарии анализа данных временных рядов】

Типичные данные временных рядов включают:

Метрики:То есть традиционный мониторинг серверов.

АРМ:Мониторинг производительности приложений.

Данные датчика:Генерируется данными Интернета вещей, интеллектуальным оборудованием, промышленным Интернетом вещей и т. д.

Tencent была вовлечена в такие сценарии очень рано и накопила большой опыт. Такие сценарии имеют следующие характеристики:

Высокий параллелизм пишет:Максимальный масштаб одного онлайн-кластера — до 600+ узлов, а скорость записи — 1000 Вт/с.

Высокая производительность запросов:Задержка запроса одной кривой или одной временной шкалы должна быть на уровне 10 мс.

Многомерный анализ:Требуются гибкие и многомерные возможности статистического анализа.Например, при просмотре и мониторинге статистический анализ может выполняться по различным измерениям, таким как регионы и бизнес-модули.

2. Сценарии отраслевого применения

В отрасли основные сценарии применения ES чаще встречаются на платформах электронной коммерции, таких как поиск продуктов, этикеток и магазинов.

Типичным примером является веб-сайт электронной коммерции M с годовой GMV 20 млрд. Сценарии его применения в ES также очень обширны, включая рекомендации по поиску продуктов, анализ и мониторинг журналов, а также статистический анализ. Его бизнес-команда управляет десятками кластеров ES и растет в размерах.

2. Возникшие проблемы

1.Проблемы Tencent

В контексте такого масштабного, напряженного и многосценарного бизнеса внутри Tencent применение ES действительно столкнулось со многими проблемами, которые можно разделить на две основные категории: поиск и временные ряды.

1.【класс поиска】

Высокая доступность:Возьмем в качестве примеров поиск в электронной коммерции, поиск приложений и поиск на месте. Они придают большое значение доступности, а соглашение об уровне обслуживания составляет более 4 9. Сценарии аварийного восстановления, такие как сбой одного компьютера и сбой сети в одной комнате, должны рассматриваться.

высокая производительность:Они имеют чрезвычайно высокие стандарты производительности, такие как 20 Вт QPS, плоский звук 20 мс, задержка P95 100 мс.

Короче говоря, в бизнес-сценарии поиска основная проблема заключается вВысокая доступность и высокая производительность.

2.【Класс времени】

Сценарии временных рядов включают журналы, метрики, APM и т. д. По сравнению со службами поиска, ориентированными на высокую доступность и высокую производительность, службы временных рядов будут более эффективными.Сосредоточьтесь на стоимости, производительности.

Например, пользователям в сценариях временных рядов обычно требуется высокая пропускная способность записи, которая в некоторых сценариях может достигать 1000 Вт/с; при такой пропускной способности записи данные могут храниться в течение 30 дней, а емкость хранилища может достигать уровня ПБ. Если количество машин, используемых пользователями для реального онлайн-бизнеса, равно 100, но 50 для мониторинга, ведения журналов и т. д., это в принципе неприемлемо для большинства пользователей (поскольку преимущества мониторинга и ведения журналов относительно невелики). Таким образом, в бизнесе временных рядов основные проблемы связаны со стоимостью хранения, вычислительной стоимостью и так далее.

Столкнувшись с такими сложными проблемами, Tencent оптимизировала практику ES с точки зрения ядра (после того, как результаты этой оптимизации с помощью облака Tencent также открыты для внешних пользователей, среди которых есть сайты электронной коммерции M).

2. Проблемы, с которыми сталкивается отрасль

Отрасль также испытывает те же проблемы, что и Tencent. Возьмем в качестве примера сайт электронной коммерции M. Компании электронной коммерции часто проводят рекламные акции, и им приходится обращать внимание на кластер ES.стабильностьи сгруппированыРезервное копирование для аварийного восстановления.

Что касается стабильности кластера, проблемы, с которыми они часто сталкиваются, заключаются в следующем: «крупномасштабные запросы вызовут переполнение памяти JVM для узлов ES, что повлияет на стабильность кластера», и «когда количество индексов или сегментов слишком велико, кластер Изменения в массиве происходят медленно, а загрузка ЦП высока, что влияет на стабильность кластера».

Что касается аварийного восстановления и резервного копирования, они часто сталкиваются с проблемами «как гарантировать, что службы не прерываются при выходе из строя одного компьютерного зала» и «как восстановить данные после сбоя».

3. Практика оптимизации ЭУ

Прежде всего, в ответ на спрос на «высокую доступность» разработчики Tencent разделили ее на части и сделали прорыв, чтобы разделить высокую доступность на три измерения:

1 Надежность системы:Относится к надежности самого ядра ES, что также является распространенной проблемой, с которой сталкиваются распределенные системы. Например:

Отказоустойчивость кластера при аномальных запросах и перегрузке давлением;

Масштабируемость кластера в сценариях с высокой нагрузкой;

В сценарии расширения кластера и аварийного узла способность балансировки данных между узлами и несколькими жесткими дисками.

2. План аварийного восстановления:Например, выстраивая систему управления и контроля, она может обеспечить быстрое восстановление услуг в случае сетевых сбоев в машинном зале, предотвратить потерю данных при стихийных бедствиях, а также быстро откатиться после неправильной эксплуатации.

3. Дефекты системы:Это неизбежная проблема при разработке любой системы, такая как блокировка главного узла, распределенная взаимоблокировка, медленный последовательный перезапуск и т. д.

В ответ на вышеуказанные проблемы решения Tencent ES заключаются в следующем:

1. Надежность системы:

Нестабильный сервис:Благодаря ограничению тока службы он может допускать ненормальные условия, такие как сбой сети машины и ненормальный запрос.

Проблемы с масштабируемостью кластера:Благодаря оптимизации логики управления и контроля метаданных кластера возможности расширения кластера были улучшены в 10 раз, и он поддерживает тысячи кластеров узлов и миллионы сегментов;

Проблема баланса кластера:Благодаря оптимизации баланса сегментов между узлами и несколькими жесткими дисками обеспечивается баланс давления крупномасштабных кластеров.

2. План аварийного восстановления:

Данные можно восстановить:

Расширяя подключаемый механизм ES, он поддерживает резервное копирование и резервное копирование, а также резервное копирование данных ES в дешевое хранилище для обеспечения возможности восстановления данных;

Отказоустойчивость:

Tencent Cloud ES поддерживает аварийное восстановление между зонами доступности. Пользователи могут развертывать несколько зон доступности по требованию, чтобы избежать сбоев в одной комнате.

Кроме того, Tencent Cloud ES также поддерживает функцию резервного копирования COS.Пользователи могут напрямую создавать резервные копии базовых файлов данных в COS Tencent Cloud Object Storage, используя ES API, реализуя недорогую и простую в эксплуатации функцию резервного копирования данных.

Аномальное восстановление:

Благодаря механизму корзины гарантируется, что кластер может быть быстро восстановлен в таких сценариях, как задолженность и неправильная работа.

3. Дефекты системы:

Tencent исправила ошибки нативного ES при последовательном перезапуске, блокировке Master, распределенной взаимоблокировке и т. д. Среди них оптимизация скользящего перезапуска может увеличить скорость перезапуска узла более чем в 5 раз; главная проблема блокировки — Tencent оптимизировала версию ES6.x вместе с официальным представителем Elastic.

В части ограничения тока службы Tencent выполнила 4 уровня работы по ограничению тока:

Уровень разрешения:После оптимизации ES поддерживает XPack и собственные разрешения для предотвращения атак и неправильных операций;

Уровень очереди:Оптимизируя детали скорости выполнения задач, повторения, приоритета и т. д., он решает проблемы накопления очереди основных задач и голодания задач, с которыми часто сталкиваются пользователи;

Иерархия памяти:Начиная с ES 6.x поддерживается ограничение тока памяти на всем канале (включая HTTP-запись, узел координации, узел данных и т. д.): при этом для точного контроля используется память JVM, статистика градиента и т. д.;

Уровень мультиарендности:Используйте схему CVM/Cgroups, чтобы обеспечить изоляцию ресурсов между несколькими арендаторами.

Вот введение в проблему ограничения тока в сценариях агрегации Когда пользователи используют ES для анализа агрегации, они часто взрывают память из-за слишком большого количества сегментов агрегации. Официально в ES 6.8 предусмотрен параметр max_buckets для управления максимальным количеством бакетов для агрегации, но этот метод очень ограничен: будет ли память разрываться, зависит от размера одного бакета (в некоторых сценариях пользователь устанавливает 200 000 бакетов). buckets) Разбиение может нормально работать, но в других сценариях может быть исчерпана память на 100 000 Buckets), поэтому пользователь не может точно понять, сколько должен быть установлен этот параметр. В настоящее время Tencent использует алгоритм градиента для оптимизации и проверяет память JVM каждые 1000 выделенных сегментов.Когда памяти недостаточно, запрос прерывается вовремя, чтобы обеспечить высокую доступность кластера ES.

Эти текущие ограничивающие решения могут решить проблему стабильности служб ES в таких сценариях, как ненормальный запрос, перегрузка по давлению, сбой одного узла и разделение сети. Тем не менее, все еще есть небольшое количество сценариев, которые не были реализованы, поэтому Tencent в настоящее время изучает возможность охвата более ненормальных сценариев, полагаясь на тесты хаоса.

В ответ на проблему «количество индексов или сегментов слишком велико, метаданные кластера изменяются медленно, а загрузка ЦП высока, что влияет на стабильность кластера», в ядре Tencent оптимизировала алгоритм распределения сегментов, с помощью таблицы маршрутизации узла кэша и метода инкрементного обновления метаданных для ускорения изменения метаданных кластера.

Решив проблемы высокой доступности и высокой производительности, пора поговорить о практике оптимизации затрат.

Проблема затрат в основном отражается в потреблении машинных ресурсов в сценариях временных рядов (таких как журналы и мониторинг). Благодаря анализу типичных онлайн-журналов и сервисов временных рядов соотношение стоимости жесткого диска, памяти и вычислительных ресурсов близко к 8:4:1. То есть жесткий диск и память являются основными противоречиями, за которыми следуют вычислительные затраты.

Данные временных рядов имеют очевидные характеристики доступа: «ближе и намного меньше». Объем доступа к данным за последние семь дней составляет более 95%, доступ к историческим данным меньше и обычно имеет доступ к статистической информации.

Основываясь на анализе этих узких мест и характеристиках доступа к данным, можно предложить следующие оптимизированные по стоимости решения:

(1) Принять архитектуру холодного и горячего разделения и использовать гибридное решение для хранения, чтобы сбалансировать стоимость и производительность;

(2) Поскольку исторические данные обычно доступны для статистической информации, хранение и производительность заменяются предварительными вычислениями;

(3) Если исторические данные вообще не используются, их можно скопировать в более дешевую систему хранения;

(4) В зависимости от характеристик доступа к данным временных рядов затраты памяти можно оптимизировать с помощью кэша.

(5) Другие методы оптимизации: такие как сокращение объема памяти, управление жизненным циклом и т. д.

Разверните раздел Rollup здесь. Rollup похож на кубы и материализованные представления в сценариях с большими данными. Его основная идея заключается в том, чтобы заранее генерировать статистическую информацию посредством предварительных вычислений для выпуска исходных гранулярных данных, тем самым снижая затраты на хранение и повышая производительность запросов. Вот простой пример: в сценарии мониторинга машин исходная степень детализации данных мониторинга составляет 10 секунд, в то время как данные мониторинга месячной давности обычно нужно просматривать только с почасовой детализацией, что является сценарием приложения Rollup. Официальный запуск Rollup из ES 6.x, на самом деле Tencent начала исследования в 5.x.

В области больших данных традиционное решение состоит в том, чтобы полагаться на внешнюю автономную вычислительную систему для периодического считывания полного объема данных для расчета.Этот метод требует больших вычислительных ресурсов и затрат на обслуживание.

Система рекламных индикаторов Google Mesa использует схему непрерывной генерации. Когда данные записываются, система генерирует входные данные для каждого сводного значения и сортирует данные. Затраты на расчет и обслуживание относительно низкие.

ES поддерживает сортировку данных, начиная с версии 6.x. Tencent выполняет несколько слияний для создания Rollup с помощью потоковых запросов. Окончательные накладные расходы на вычисления составляют менее 10% от накладных расходов ЦП при записи полных данных, а использование памяти составляет менее 10 МБ. Этот метод оптимизации ядра был предоставлен Tencent сообществу открытого исходного кода для устранения узких мест в вычислениях и памяти в Rollup с открытым исходным кодом.

Как упоминалось выше, когда многие пользователи используют большие модели хранения, приоритет памяти становится узким местом, и жесткий диск не может быть полностью загружен.Основным узким местом таких проблем является то, что индекс занимает большой объем памяти. Учитывая, что исторические данные редко используются в сценариях временных рядов, а некоторые поля практически не используются в некоторых сценариях, Tencent представила кэш для повышения эффективности использования памяти.

Что касается оптимизации памяти, какие решения есть в отрасли?

Сообщество ES поддерживает размещение индексов вне кучи начиная с версии 7.x и их загрузку по запросу, например DocValue. Недостаток этого метода в том, что важность индексов и данных совершенно разная, большой запрос легко может привести к исключению индексов, а производительность последующих запросов будет кратно затухать.

HBase использует Cache для кэширования индексов и блоков данных для повышения производительности доступа к горячим данным.Начиная с HBase 2.0, он фокусируется на своей технологии Off Heap, которая делает доступ к памяти вне кучи и внутри кучи близкими. Основываясь на опыте сообщества, Tencent представила LFU Cache в ES для повышения эффективности использования памяти, поместила Cache вне кучи, чтобы уменьшить нагрузку на память кучи, и уменьшила потери с помощью таких технологий, как копирование Weak Reference внутри и вне кучи. С помощью этого метода использование памяти улучшается на 80 %, потеря производительности запросов составляет менее 2 %, а накладные расходы на сборщик мусора снижаются на 30 %.

Когда дело доходит до методов оптимизации производительности, в качестве примера возьмем сценарии временных рядов, представленные журналами и мониторингом.Они предъявляют чрезвычайно высокие требования к производительности записи, а параллелизм записи достигает 1000 Вт/с. Однако при записи первичным ключом производительность ES снижается в 1+ раз, а в некоторых сценариях стресс-тестов ЦП не может быть загружен полностью. Сценарии, представленные поисковыми службами, предъявляют очень высокие требования к производительности запросов, часто требуя 20 Вт QPS, 20 мс неизменяемого ответа и чтобы избежать сбоев запросов, вызванных GC и плохими планами выполнения.

В ответ на вышеуказанные проблемы у Tencent также есть контрмеры:

(1) Оптимизация записи:Для сценария дедупликации первичного ключа индекс используется для сокращения, чтобы ускорить процесс дедупликации первичного ключа и повысить производительность записи на 45%. Кроме того, одним из направлений исследований Tencent является оптимизация производительности записи за счет векторизованного выполнения и уменьшения числа переходов и пропусков инструкций, и ожидается, что производительность удвоится.

(2) Оптимизация использования ЦП:Для проблемы, связанной с тем, что ЦП не может быть полностью использован в некоторых сценариях стресс-тестов, производительность улучшена на 20% за счет оптимизации вытеснения ресурсов, когда ES обновляет Translog.

(3) Оптимизация запросов:Повысьте производительность запросов, оптимизировав стратегию слияния. Сокращение запросов на основе минимального/максимального индекса каждой записи сегмента повышает производительность запросов на 30 %. Благодаря стратегии CBO операция кэширования запросов позволяет избежать более чем 10-кратного сбоя, связанного с запросом, который отнимает много времени. Кроме того, оптимизация производительности с помощью нового оборудования (например, Intel AEP, Optane, QAT и т. д.) также является хорошим направлением для изучения.

Далее давайте подробно поговорим об оптимизации стратегии слияния: родная стратегия слияния ES в основном фокусируется на сходстве размеров (попробуйте выбрать сегменты одинакового размера при объединении) и максимальном верхнем пределе (рассмотрите возможность попытки собрать сегменты вместе до 5 ГБ). . Тогда возможно, что сегмент содержит данные за весь месяц января и 1 марта.Когда пользователь запрашивает данные за определенный час 1 марта, необходимо сканировать большое количество бесполезных данных, что приводит к серьезной потере производительности.

В ответ на вышеуказанные проблемы Tencent представила слияние временных рядов в ES: при выборе сегментов для слияния ориентируйтесь на фактор времени, чтобы сегменты с одинаковым временем объединялись вместе. Когда пользователи запрашивают данные на 1 марта, им нужно только сканировать отдельные меньшие сегменты, а другие сегменты можно быстро обрезать.

Кроме того, ES официально рекомендует пользователям поиска выполнять принудительное слияние после написания: цель состоит в том, чтобы объединить все сегменты в один для повышения производительности поиска. Однако это увеличивает стоимость использования для пользователя, а в сценариях временных рядов необходимо сканировать все данные, что не способствует кадрированию.

В результате Tencent представила автоматическое слияние холодных данных в ES: для неактивных индексов базовые сегменты будут автоматически объединяться, чтобы приблизиться к 5 ГБ, что уменьшает количество файлов и облегчает отсечение сцен временных рядов. Для сценариев поиска пользователь может настроить размер целевого сегмента, чтобы все сегменты в конечном итоге объединились в один. Эта оптимизация стратегии слияния может удвоить производительность сценариев поиска.

После подключения к Tencent Cloud ES базовые возможности ES, а также эффективность разработки, эксплуатации и обслуживания веб-сайта электронной коммерции M были значительно улучшены:

надежность:Основываясь на способности Tencent оптимизировать ядро ES, надежность кластера ES веб-сайта электронной коммерции M была значительно повышена, выдерживая несколько пиков трафика и получая очевидные экономические выгоды.

Аварийное восстановление безопасности:Зона мультидоступности обеспечивает гарантию аварийного восстановления, управление разрешениями X-Pack обеспечивает гарантию безопасности;

Эффективность эксплуатации и обслуживания:Облако обеспечивает эффективное развертывание и стабильное эластичное масштабирование.Возможности SQL, предоставляемые X-Pack, повышают удобство работы, а повышение эффективности эксплуатации и обслуживания значительно высвобождает рабочую силу.

Особо стоит отметить, что весь проект очень плавный и стабильный в процессе миграции:

Исходный кластер ES M достиг полной безостановочной миграции;

После миграции по-прежнему поддерживается стыковка системы эксплуатации и обслуживания, разработанной собственной ES М.;

В процессе миграции версия сообщества ES не поддерживала особые требования M к ядру. Специализированная группа ядра Tencent Cloud ES активно отреагировала и предоставила эту возможность.

4. Будущее планирование и вклад в открытый исходный код

В настоящее время в Китае существует множество сценариев применения ЭС в «большом диапазоне запросов» и «большом количестве индексов или шардов», поэтому отечественные разработчики сообщества также уделяют этому особое внимание. В этих двух областях схема оптимизации Tencent Cloud ES была официально принята Elastic из-за ее полноты и чистоты кода.

За последние шесть месяцев Tencent представила сообществу открытого исходного кода более 10 PR, включающих различные модули, такие как написание, запросы и управление кластером (некоторые функции оптимизации завершаются вместе с официальной разработкой Elastic). Tencent создала группу по сотрудничеству с открытым исходным кодом Elasticsearch, чтобы все разработчики Tencent могли участвовать в экологическом строительстве Elastic.

В настоящее время Tencent и Elastic запустили облачный сервис ES с улучшенным ядром в Tencent Cloud, экспортируя возможности поиска на триллионном уровне. Однако у развития ES еще есть много ценных направлений, которые можно дополнительно изучить, именно поэтому Tencent Cloud итеративно оптимизирует продукты и продолжает наращивать ядра после запуска продуктов.

В будущем Tencent также проведет долгосрочное исследование:

Взяв за идею карту больших данных, все поле больших данных можно разделить на три части в соответствии с характеристиками объема данных и требованиями к задержке:

(1) DataEngineering, включая знакомые пакетные вычисления и потоковые вычисления;

(2) обнаружение данных, включая интерактивный анализ, поиск и т. д.;

(3) DataApps, в основном используемые для поддержки онлайн-сервисов.

Хотя ES считается технологией в области поиска, ES также поддерживает такие сценарии, как онлайн-поиск и службы документов; кроме того, существует множество зрелых систем OLAP, которые также основаны на технологических стеках, таких как инвертированный индекс и смешанные строки и столбцы. место хранения. Из этого видно, что возможность развития ЭС в этих двух областях очень высока. Поэтому Tencent сосредоточится на изучении технологии ES в направлении «онлайн-сервисов» и «OLAP-анализа».

Наконец

Приглашаю всех обратить внимание на мой официальный аккаунт [Программист в погоне за ветром].В 2019 году многие компании собрали более 1000 400-страничных pdf-документов для вопросов на собеседовании по java.

Если вам понравилась статья, не забудьте подписаться на меня и поставить лайк, спасибо за вашу поддержку!