Практика применения Apache Doris в хранилище данных Meituan Takeaway Data Warehouse

Преамбула

Техническая группа Meituan Takeaway Data Warehouse отвечает за поддержку ежедневных бизнес-операций и ежедневный анализ аналитиков.Из-за высокой стоимости производства данных и низкой эффективности запросов, обусловленных характеристиками бизнеса на вынос, они оптимизировали производственный план, внедрив Apache Doris. двигатель для достижения баланса между низкой себестоимостью производства и эффективными запросами. На основе этого анализируется применимость режима MOLAP на основе Kylin и режима ROLAP на основе механизма Doris в различных бизнес-сценариях. Надеюсь, это может вдохновить или помочь вам всем.

В этой статье основное внимание уделяется усовершенствованию и осмыслению производственной архитектуры хранилища данных с помощью механизма Doris в качестве «движка». В среде с открытым исходным кодом расцветают различные механизмы обработки данных. Однако из-за сложности и разнообразия бизнеса ни один механизм не может адаптироваться ко всем бизнес-сценариям. Поэтому мы надеемся предоставить вам некоторый опыт и рекомендации благодаря нашей деловой практике и мышлению. . . . Техническая команда Meituan Takeaway Data Warehouse стремится максимизировать эффективность применения данных, принимая во внимание минимизацию затрат на исследования и разработки, производство, эксплуатацию и техническое обслуживание, а также постоянно улучшая возможности хранилища данных. предложения.

Статус приложения механизма уровня взаимодействия с хранилищем данных

В настоящее время масштабы интернет-бизнеса становятся все больше и больше.Будь то производственная система бизнеса или система журналов, в основном хранилище данных строится на основе распределенной экосистемы технологии больших данных Hadoop / Spark, а затем данные должным образом многослойный и обработанный. На уровне взаимодействия с приложениями данных из-за требований своевременности окончательное представление и запрос данных по-прежнему должны поддерживаться механизмами СУБД (MySQL) и MOLAP (Kylin). Как показано ниже:

Взаимодействие с агрегированными данными

Наиболее типичным сценарием для ежедневного бизнес-анализа бизнес-группы является пользовательский запрос в различных измерениях.Сталкиваясь с таким гибким и изменчивым сценарием приложения WYSIWYG, платформа Meituan использует Kylin в качестве основного механизма MOLAP компании. MOLAP — это предварительно вычисленное производство, которое хорошо работает в сценариях инкрементного бизнеса и анализа заданных измерений, но стоимость производства огромна в сценариях с изменяющимися измерениями. Например, если вы используете последний тип продавца, чтобы оглянуться назад на производительность продавца за последние три месяца, вам необходимо пересчитать куб за три месяца, что занимает несколько часов для вычисления почти терабайт исторических данных. Кроме того, в ответ на анализ непредустановленных измерений модель MOLAP необходимо повторно адаптировать и рассчитать, а также требуется определенный объем итерационной работы.

Взаимодействие подробных данных

В дополнение к макроданным, бизнес-анализ также требует подробного запроса данных. Обычно люди выбирают реляционные БД, такие как MySQL, в качестве быстрого запроса на получение подробных данных, но когда бизнес быстро растет, вскоре возникают узкие места в производительности, а затраты на эксплуатацию и обслуживание также высоки. Например, такие операции, как синхронизация больших объемов данных, добавление полей и обновление исторических данных, требуют очень высоких затрат на обслуживание.

Особенности бизнеса на вынос

Миссия Meituan — «помочь всем лучше питаться и лучше жить». Бизнес по доставке еды предоставляет услуги по доставке еды для всех, соединяя продавцов и пользователей.Это трудоемкий бизнес.Бизнес по доставке еды имеет операционную группу из десятков тысяч человек, которые обслуживают миллионы продавцов по всей стране.Обслуживание предприятий в «деловой квартал». "Деловой круг" — это наименьший уровень в измерении организационной структуры. Он происходит от характеристик организаций по доставке еды. "Деловой круг" и его организационная структура верхнего уровня представляют собой измерение изменений. Когда граница "делового круга" «изменения, это приведет к ежедневному. В методе пошагового производства бизнеса возврат исторических данных теряет свое справочное значение. Во всех бизнес-сценариях, отображающих организационные данные, организационные изменения являются неизбежной технической проблемой. Кроме того, другие измерения, такие как категория и тип продавца, также имеют проблему изменения измерений. Как показано ниже:

Проблемы производства данных

Взрыв данных, ежедневное использование новейших измерений для повторной истории данных. Есть проблема в режиме мочика Cylin:

Исторические данные обновляются ежедневно, теряя смысл приращения.
Каждый день отслеживается большое количество исторических данных, причем более 1 миллиарда исторических данных отслеживаются с возвратом.
Вычисление данных занимает 3 часа+, а хранилище составляет 1 ТБ+, что потребляет много вычислительных ресурсов и ресурсов хранения и серьезно влияет на стабильность SLA.
Фактическая скорость использования большого количества предварительно рассчитанных исторических данных низка.В реальной работе 80% ретроспективной истории сосредоточено примерно в одном месяце.Однако, чтобы справиться со всеми сценариями спроса, бизнесу необходимо рассчитать истории больше полугода.
Запросы подробных данных не поддерживаются.

Решение: Внедрите механизм MPP, и данные будут использоваться и рассчитываться немедленно.

Поскольку ожидается, что изменение размеров исторических данных будет сопряжено с огромными затратами, лучше всего использовать текущий подсчет, но теперь с текущими операторами требуются мощные возможности параллельных вычислений. Реализация OLAP - это MOLAP, ROLAP, HOLAP в трех формах, MOLAP Cube - это форма выражения, но более высокие затраты на расчеты и управление. ROLAP нуждается в надежной поддержке механизма реляционной БД. Долгое время из-за ограниченных возможностей обработки данных традиционной реляционной СУБД, поэтому режим ROLAP имеет значительные ограничения. По мере развития технологии распределенных, параллельных приложений, механизм MPP постепенно демонстрировал высокую пропускную способность и малую задержку вычислительной мощности, известную как «сто миллионов секунд для открытия», двигатель несколько, режим ROLAP может быть лучшим расширением. Один из бизнес-кейсов для рассмотрения практического применения, порядка десятков тысяч секунд производительности реляционных запросов на сайте, уже может охватывать множество сценариев приложений с возможностью применения. Например: ежедневный объем данных ROLAP-сайт вычислений, неделя, месяц для расчета тенденций, а также просматривать подробные данные могут лучше справиться.

На следующем рисунке представлено сравнение схем приложений в режиме MOLAP и режиме ROLAP:

Недостатки модели MOLAP

Модель прикладного уровня сложна, и необходимо выполнить дополнительную предварительную обработку модели в соответствии с потребностями бизнеса и производственными потребностями Kylin. Таким образом, в различных бизнес-сценариях коэффициент использования модели также относительно низок.
Процесс настройки Kylin громоздкий, и он требует настройки дизайна модели и взаимодействия с соответствующей стратегией «сокращения» для достижения баланса между вычислительными затратами и эффективностью запросов.
Поскольку MOLAP не поддерживает запрос подробных данных, в сценарии приложения «сводка + подробности» подробные данные необходимо синхронизировать с механизмом СУБД, чтобы реагировать на взаимодействие, что увеличивает стоимость эксплуатации и обслуживания производства.
Больше предварительной обработки связано с более высокими производственными затратами.

Преимущества модели ROLAP

Дизайн модели прикладного уровня упрощен, и данные могут быть зафиксированы со стабильной степенью детализации данных. Например, звездообразная модель детализации продавцов имеет относительно высокий уровень повторного использования.
Бизнес-выражение уровня приложения может быть инкапсулировано представлением, что уменьшает избыточность данных, повышает гибкость приложения и снижает затраты на эксплуатацию и обслуживание.
Также поддерживает «резюме + детали».
Модель облегчена и стандартизирована, что значительно удешевляет производство.

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

Проблема адаптации сценария приложения под двухъядерный движок

Архитектура использует двухъядерный режим MOLAP + ROLAP для адаптации к различным сценариям приложений, как показано на следующем рисунке:

технические компромиссы

MOLAP: за счет предварительного расчета он обеспечивает стабильные данные среза, реализует несколько запросов и одно вычисление, снижает вычислительную нагрузку во время запроса, обеспечивает стабильность запроса и является лучшим путем для «пространства во времени». Он реализует алгоритм дедупликации на основе Bitmap, поддерживает статистику индикаторов дедупликации в реальном времени в разных измерениях и обладает высокой эффективностью.ROLAP: Основываясь на крупномасштабных параллельных вычислениях в реальном времени, требования к кластерам относительно высоки. Ядром механизма MPP является повышение мощности параллельных вычислений за счет рассредоточения данных для реализации распределения ресурсов ЦП, ввода-вывода и памяти. Когда текущее хранилище данных в основном основано на дисках, большие дисковые операции ввода-вывода, необходимые для сканирования данных, и высокая загрузка ЦП, вызванная параллелизмом, по-прежнему являются недостатками ресурсов. Следовательно, для высокочастотных крупномасштабных сводных статистических данных возможности параллелизма будут сталкиваться с большими проблемами, которые зависят от возможностей параллельных вычислений аппаратного обеспечения кластера. Традиционные алгоритмы дедупликации требуют много вычислительных ресурсов, а крупномасштабные индикаторы дедупликации в реальном времени представляют собой огромную проблему для ЦП и памяти. В настоящее время последняя версия Doris уже поддерживает алгоритм Bitmap, который вполне может решить сценарий приложения дедупликации с предварительными вычислениями.

адаптация бизнес-модели

MOLAP: Когда измерение бизнес-анализа относительно твердое и когда доступно историческое состояние, поэтапное производство выполняется в соответствии со временем, стоимость обработки увеличивается линейно, а данные обрабатываются с более грубой степенью детализации (например, организационное подразделение), уменьшая количество данных о результатах и повышение эффективности взаимодействия. Как показано на рисунке выше, использование Kylin — хороший выбор для предварительного расчета от модели A к модели B.

ROLAP: Когда измерение бизнес-анализа является гибким или специфичным для последнего состояния (как показано в приведенной выше модели А, для просмотра истории всегда используется последняя атрибуция торговой организации), стоимость предварительного вычисления ретроспективных исторических данных огромна. В этом сценарии данные стабилизируются на уровне детализации продавца, а ретроспективный анализ исторических данных выполняется посредством расчета на месте, чтобы реализовать текущий расчет, который может сэкономить огромные затраты на предварительный расчет и принести большая гибкость приложений. В этом случае он подходит для производственного режима ROLAP, поддерживаемого механизмом MPP.

Выбор двигателя MPP

В настоящее время существует множество OLAP-движков с открытым исходным кодом, которые привлекают больше внимания, например, Greenplum, Apache Impala, Presto, Doris, ClickHouse, Druid, TiDB и т. д., но не хватает практических примеров, поэтому мы не есть большой опыт, чтобы учиться. Поэтому мы объединили наши собственные бизнес-потребности, начиная со стоимости конструкции двигателя и всесторонне учитывая экологическую интеграцию технологий компании, интеграцию, простоту использования и другие аспекты Дорис из сообщества Apache.

Введение и характеристики Дорис

Doris — это механизм OLAP, основанный на архитектуре MPP, который в основном объединяет технологии Google Mesa (модель данных), Apache Impala (движок запросов MPP) и Apache ORCFile (формат хранения, кодирование и сжатие).

Системная архитектура Doris выглядит следующим образом, в основном разделена на два компонента: FE и BE. FE в основном отвечает за синтаксический анализ запросов, компиляцию, оптимизацию, планирование и управление метаданными, BE в основном отвечает за выполнение запросов и хранение данных. Для получения более подробной технической информации о Дорис см.официальная документация.

Особенности Дорис:

В то же время он поддерживает точечные запросы с высокой степенью параллелизма и специальные запросы с высокой пропускной способностью.
Он поддерживает как в режиме реального времени, так и в автономном объемном объеме.
Поддерживаются как подробные, так и агрегированные запросы.
Совместимость с протоколом MySQL и стандартным SQL.
Интеллектуальная маршрутизация запросов, поддерживающая сводную таблицу и сводную таблицу.
Поддержка улучшенной стратегии объединения нескольких таблиц и гибких выражений запросов.
Поддержка онлайн-изменения схемы.
Поддержка вторичных разделов Range и Hash.

Эффективность применения Дорис на складе на вынос

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

В среде Doris из 20 BE+3FE эффективность и производительность следующие:

Он поддерживает более десятков продуктов для анализа данных, а общий отклик достигает уровня ms.
Он поддерживает связанный запрос миллионов и десятков миллионов больших таблиц и одновременно выполняет модель ассоциации таблиц измерений в виде снежинки.После оптимизации функции Colocate Join он может получить ответ второго уровня.
На дневном уровне он рассчитывается на месте на основе сведений о продавцах, и в то же время он удовлетворяет запросу сводных и детализированных данных, а время запроса в основном можно контролировать на втором уровне.
7-дневный анализ тренда, 2~3 секунды. Из-за большого объема данных производительность запроса зависит от размера кластера.Однако, когда объем данных велик, мобилизуется больше ресурсов кластера.Поэтому производительность параллелизма MPP ограничена производительностью кластер. Общий принцип заключается в том, что для предприятий с высоким параллелизмом необходимо строго контролировать ограничение времени запроса (в основном в миллисекундах), для предприятий с низким параллелизмом разрешены запросы большего размера, но также следует учитывать емкость кластера.
Благодаря применению в течение одного года и постоянному совершенствованию и обновлению Doris была дополнительно подтверждена высокая надежность, высокая доступность и высокая масштабируемость Doris, а сервис стал стабильным и надежным.

Приложения в сценариях квазиреального времени

Автономный бизнес-анализ в основном основан на офлайн-данных T+1, но в случае маркетинговой деятельности команде доставки часто нужны данные в реальном времени за день для мониторинга и анализа изменений в бизнесе, что обычно реализуется в режиме реального времени. потоковые вычисления.

Вынос бизнес-мониторинга в режиме реального времени имеет следующие характеристики:

Чтобы избежать влияния минутных колебаний производительности, данные квазиреального времени в течение 10 или 15 минут работы могут удовлетворить потребности анализа.
Данные в реальном времени необходимо сравнивать с автономными данными ежедневно и еженедельно.
Бизнес заказов требует времени на события, бизнес впечатлений требует производственного времени, а логика согласования бизнеса сложна.
Разные бизнес-направления предъявляют разные требования, и индикаторы нуждаются в хорошей масштабируемости.

Из-за сложности бизнеса необходимо учитывать согласование многих бизнес-калибров в потоковых вычислениях в реальном времени. Стоимость разработки бизнес-модели ER при обработке слияния высока, а потребление ресурсов велико. Хранилище производственных данных в реальном времени на основе Doris, оно может быть гибким. Оно может реализовывать бизнес-микропакетную обработку, а затраты на разработку и производство относительно низкие. Ниже приведена архитектура хранилища данных квазиреального времени на основе Doris, которая является типичной производственной архитектурой Lambda реального времени:

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

возможность записи в реальном времени: в настоящее время поддерживает задержку второго уровня Kafka To Doris. С точки зрения надежности и устойчивости конструкции по-прежнему необходимы дальнейшие улучшения.конструкция двигателя: Короткие и быстрые вычисления + эффективная производительность хранения. В настоящее время еще есть возможности для улучшения производительности движка Doris, и в 2020 году будут большие улучшения. С последующим запуском Page Cache, таблицы памяти и других возможностей ввод-вывод больше не будет тормозом, и возможности параллелизма будут значительно улучшены.Возможность надежного планирования: Обеспечить 5, 10, 15, 30 минут гарантированной возможности планирования.Упрощенная лямбда-архитектура: данные в режиме реального времени и автономные данные лучше интегрированы в Doris для гибкой поддержки приложений.Эффективное OLAP-взаимодействие: поддерживает гибкий доступ к бизнес-запросам.Бизнес-уровень напрямую повторно использует многомерную модель сводного уровня посредством логической инкапсуляции через представления, что повышает эффективность разработки и снижает затраты на эксплуатацию и обслуживание.

По сравнению с оконными вычислениями в Storm и Flink преимущества микропакетной обработки БД в квазиреальном времени:

Важные улучшения двигателя Дорис в Meituan

Транзитивная оптимизация объединения предикатов Pushdown

Как показано выше, для следующего SQL:

select * from t1 join t2 on t1.id = t2.id where t1.id = 1

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

Итак, мы реализовали первую оптимизацию в Doris: транзитивную оптимизацию выталкивания предиката соединения (называемую распространением констант в MySQL и TiDB). Транзитивная оптимизация проталкивания предиката соединения означает: на основе предикатов t1.id = t2.id и t1.id = 1 мы можем вывести новый предикат t2.id = 1 и протолкнуть предикат t2.id = 1 в сканирование узел t2. Таким образом, если таблица t2 состоит из сотен секций, производительность запросов повысится в десятки и даже сотни раз, поскольку объем данных, задействованных в сканировании и соединении таблицы t2, будет значительно уменьшен.

Оптимизация параллельного выполнения запросов с несколькими экземплярами

Как показано на рисунке выше, Doris по умолчанию создает только один экземпляр выполнения для каждого оператора на каждом узле. В этом случае, если объем данных велик, оператору каждого исполняемого экземпляра необходимо обрабатывать большой объем данных, и такие ресурсы, как ЦП, ввод-вывод и память кластера, не могут быть использованы полностью.

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

На следующем рисунке показан эффект оптимизации, когда параллелизм установлен на 5. Видно, что для различных типов запросов производительность запроса будет улучшена в 3-5 раз:

Colocate Join

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

Ключевые моменты всей реализации Colocate Join в Doris следующие:

Локальность данных гарантируется при импорте данных.
Локальность данных гарантируется при планировании запросов.
Локальность данных гарантируется после балансировки данных.
Запросить модификацию Плана.
Постоянство и согласованность метаданных Colocate Table.
Степень детализации Hash Join меняется с детализации сервера на степень детализации сегмента.
Условное решение Colocate Join.

Дополнительные сведения о реализации Doris Colocate Join см. в документе «Принцип и практика соединения Apache Doris Colocate».

Для следующего SQL сравнение производительности Doris Colocate Join и Shuffle Join при разных объемах данных выглядит следующим образом:

select count(*) FROM A t1 INNER JOIN [shuffle] B t5    ON ((t1.dt = t5.dt) AND (t1.id = t5.id)) INNER JOIN [shuffle] C t6    ON ((t1.dt = t6.dt) AND (t1.id = t6.id)) where t1.dt in (xxx days);

Точная дедупликация растровых изображений

Способ, которым Дорис раньше добивалась точной дедупликации, заключался в расчетах на месте, а метод реализации был аналогичен Spark и MapReduce:

Для SQL, который вычисляет PV на приведенном выше рисунке, Дорис вычислит его в соответствии со следующим рисунком, сначала в соответствии со столбцом страницы и группой столбцов user_id, и, наконец, посчитает:

Очевидно, что с помощью вышеуказанного метода расчета, когда объем данных становится все больше и больше, достигая миллиардов или десятков миллиардов, используемые ресурсы ввода-вывода, ресурсы ЦП, ресурсы памяти и сетевые ресурсы будут становиться все больше и больше, и запрос также будет становятся все более и более Медленнее и медленнее.

Поэтому мы добавили индикатор агрегации Bitmap в Doris.При импорте данных данные того же столбца измерения будут агрегированы с использованием Bitmap. С Bitmap способ вычисления точной дедупликации в Doris выглядит следующим образом:

Видно, что после использования Bitmap предыдущий процесс расчета PV будет значительно упрощен, а также значительно уменьшится количество операций ввода-вывода, ЦП, памяти и сетевых ресурсов во время запроса на месте, и они больше не будут увеличиваться линейно с размером данных.

Резюме и размышления

В деловой практике анализа операций по доставке еды из-за сложности бизнеса и различных сценариев применения ни одно решение для производства данных не может решить все бизнес-задачи. Развитие технологии ядра базы данных предоставляет нам больше средств для улучшения решений по построению данных. Практика показала, что режим ROLAP, управляемый механизмом Doris, может лучше обрабатывать такие сценарии, как сводка и детализация, историческая ретроспектива изменяющихся измерений, гибкое применение непредустановленных измерений и пакетная обработка в квазиреальном времени. Модель MOLAP на основе Kylin по-прежнему важна для обработки поэтапного бизнес-анализа, закрепления многомерных сценариев и обмена пространства на время с помощью предварительных вычислений.

С точки зрения бизнеса, благодаря успешной практике Дорис на складах на вынос и обменах между BG, у Meituan есть больше команд, которые понимают и пытаются использовать решение Doris. И благодаря совместным усилиям студентов, изучающих платформу, еще есть много возможностей для улучшения производительности двигателя.Считается, что модель ROLAP, управляемая двигателем Doris, принесет больше пользы бизнес-команде Meituan. Судя по текущему практическому эффекту, имеет тенденцию к замене двигателей Kylin, Druid, ES и других.

В настоящее время технология баз данных развивается быстрыми темпами.Недавно компания Bairui Data выпустила RapidsDB v4.0, распределенную базу данных с полной памятью, которая поддерживает миллисекундный отклик на уровне терабайт (обработка сотен миллиардов данных может обеспечить отклик на миллисекундном уровне). Можно предвидеть, что развитие технологии баз данных значительно повысит эффективность иерархического управления и поддержки приложений в хранилищах данных, бизнес станет «определенным и видимым», а ценность данных значительно повысится.

об авторе

Чжу Лян, инженер хранилища данных миссии США на вынос.
Кайсен, инженер по большим данным Meituan, коммиттер Apache Kylin.

Предложения о работе

Группа Meituan Takeaway Data Intelligence уже долгое время набирает инженеров для хранилища данных, интеллектуального анализа данных, машинного обучения, компьютерного зрения и алгоритмов поиска и рекомендаций, расположенных в Пекине. Заинтересованные студенты могут отправить свой опыт по адресу: tech@metuan.com (отметьте в теме письма: Takeaway Data Intelligence Group)

Чтобы прочитать больше технических статей, отсканируйте код, чтобы подписаться на общедоступную учетную запись WeChat — техническая команда Meituan!