Практика Применение Kylin в Didi OLAP Engine

Почему нам нужно уделять внимание различению сценариев доступа к данным? Как различать сценарии доступа к данным?

По сути, сценарии доступа к данным представляют собой тип требований к доступу к данным, которые можно классифицировать и идентифицировать, изучив следующие аспекты:

1. Ожидаемые запросы, частота запросов каждого запроса и доля от общего количества запросов;

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

3. Взаимосвязь между чтением и обновлением данных, например соотношение чтения и записи, степень детализации обновления данных и т. д.;

4. Масштаб работы с данными и то, как данные используются локально;

5. Требования к уровню изоляции транзакций и транзакций;

6. необходимость дублирования данных и логической целостности;

7. Требования к задержке и пропускной способности для каждого типа запроса;

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

Типичные сценарии доступа к данным: сценарии OLTP (оперативная обработка транзакций) и сценарии OLAP (оперативная обработка анализа). Сценарии OLAP можно по крайней мере подразделить на гибкий анализ для исследовательского анализа и строгие режимы доступа к данным. Существует два типа сценарии анализа затвердевания. Упомянутый здесь строгий режим доступа к данным относится к конкретному анализу, который может быть выполнен с данными перед выводом данных. Он имеет четкие границы и, более конкретно, означает, что данные имеют фиксированные измерения анализа, фиксированные показатели анализа. и фиксированные методы агрегирования поверх метрик.

Таблица 2.2-1 суммирует сравнение гибкого анализа и анализа отверждения:

В интернет-предприятиях, особенно в тех, в основе которых лежат данные, незаменимы как гибкий анализ, так и твердый анализ. также не возможны). Интеграция гибкого анализа и анализа затвердевания породила OLAP-движок DiDi, который поддерживает несколько сценариев.

В настоящее время существует множество механизмов OLAP. В области больших данных, таких как Hive, он полагается на надежное хранилище и вычислительную мощность, предоставляемые Hadoop, чтобы предоставить пользователям стабильные услуги анализа.Другим примером является Presto, Spark SQL, который выделяет вычисления в памяти и может удовлетворить потребности пользователей. нужен быстрый анализ. Хотя эти продукты имеют разную направленность, все они удовлетворяют потребности гибкого анализа и надежных сценариев анализа.

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

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

Рисунок 3.2-1 Схема механизма OLAP (без учета некоторых ассоциаций компонентов)

Как показано на рис. 3.2-1, в общей схеме запрос запроса сначала поступает в механизм OLAP, маршрутизация запроса выбирает соответствующий механизм сцены на основе метаданных, а затем переписывает запрос в соответствии с выбранным механизмом сцены, и на сцену будет отправлен переписанный запрос. Движок завершает выполнение и возвращает результаты запроса.

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

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

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

В разделе 3.3 анализируется реализация сценария анализа затвердевания и при выборе технологии используется Apache Kylin, главным образом потому, что Kylin предоставляет следующие три функции:

1. Агрегированный расчет для детальных данных;

2. Храните агрегированные результаты в HBase;

3. Поддерживает стандартный доступ SQL для получения подробных и агрегированных результатов;

Вышеуказанные три функции не только обеспечивают полные возможности кэширования агрегации, но также поддерживают доступ к SQL, поэтому стоимость доступа относительно низкая.Кроме того, Kylin также предоставляет проверенные методы оптимизации запросов, такие как последовательность HBase RowKey, кодирование словаря и т. д. в определенной степени удобно использовать оптимизацию.

Kylin, как механизм сценария анализа затвердевания, в основном отвечает за ускорение запросов к таблицам с агрегированными требованиями к кешу. Какой стол будет иметь такой спрос?

1. Таблицы, используемые отчетными продуктами;

2. Таблицы, определенные решением о передаче данных ядра OLAP, которые необходимо агрегировать и кэшировать;

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

Способ, которым Didi использует Kylin, отличается от традиционного: Kylin тесно связан с бизнесом с точки зрения проектирования архитектуры.Традиционным способом бизнес-аналитики моделируют на основе Kylin, строят кубы, а затем выполняют аналитические запросы. Однако Didi использует Kylin в качестве механизма в надежном сценарии анализа для предоставления услуг совокупного кэширования для таблиц, так что Kylin, как общий компонент данных, лишен бизнес-атрибутов, отделен от пользователей и прозрачен для внешнего мира.

При первоначальном использовании, поскольку нет контроля над внутренним параллелизмом механизма OLAP, задача совокупного кэша из планирования будет выполнять загрузку таблицы Kylin, создание модели и куба с высокой степенью параллелизма в некоторых случаях из-за механизма обновления Kylin Project. метаданные Существует вероятность того, что операция завершится ошибкой. В настоящее время мы в определенной степени облегчили проблему, используя очередь внутри OLAP-механизма.Кроме того, в сочетании с механизмом повторных попыток успешное завершение операции в принципе может быть гарантировано. Наконец, мы также заметили, что эта проблема была исправлена ​​в последней версии Kylin.

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

Рисунок 4.4-1 показывает развертывание Kylin в механизме OLAP Didi.Кластер Kylin включает 2 распределенных узла сборки и 8 узлов запросов, из которых 2 узла запросов служат интерфейсами кластера для выполнения запросов REST.Запросы REST в основном включают два типа: Задание сборки запросы состояния и создавать операции класса, такие как загрузка таблиц, моделирование, создание кубов и эквивалентные операции удаления и т. д. Для запроса состояния задания на строительство требуются два узла для опроса, в то время как для операции создания класса требуется один фиксированный узел, а другой существует в качестве резервного.Основная цель этого дизайна - избежать проблемы с одной точкой интерфейса кластера и решить проблему возможного сбоя операции создания класса, вызванного механизмом синхронизации метаданных кластера Kylin.

Рисунок 4.4-1 Развертывание кластера Kylin

В настоящее время кластер Kylin поддерживает более 700 кубов, ежедневно запускает более 2000 заданий сборки, среднее время сборки составляет 37 минут, а общий объем хранилища кубов составляет более 30 ТБ (устранено влияние копий HDFS). запросы заняли менее 500 мс, а 90% запросов заняли менее 2,8 секунд. Следует отметить, что, поскольку модуль «Решение о передаче данных» в механизме OLAP инициирует «копирование» данных в Kylin в соответствии со сценарием запроса, в недавней статистике количество кубов когда-то достигнет 1100+.

С точки зрения бизнеса, Kylin косвенно обслуживает ряд важных информационных продуктов, таких как Shuyi (отчетные информационные продукты для всей компании), открытая платформа (справочный портал для всей компании) и другие важные информационные продукты, охватывающие более десяти бизнес-процессов. линии, такие как экспрессы и специальные автомобили 3000+ непрямых пользователей, внедрение Kylin обеспечивает пользователям стабильную, надежную и эффективную производительность анализа отверждения.

Движок DiDi OLAP подразделяет несколько типов сценариев, таких как гибкий анализ, затвердевший анализ и горячие данные.Kylin, как затвердевший механизм сцены анализа, играет важную роль в движке Didi OLAP. Механизм использует три функции, предоставляемые Kylin: агрегированный расчет для подробных данных, хранение агрегированных результатов в HBase и поддержка стандартного доступа SQL для подробных и агрегированных результатов для прозрачного обслуживания пользователей. В настоящее время движок обслуживает ряд важных продуктов обработки данных, охватывающих более десяти бизнес-направлений, предоставляя пользователям стабильную, надежную и эффективную производительность анализа данных.

Как первый проект Apache с открытым исходным кодом верхнего уровня, возглавляемый китайцами, Kylin имеет важные сценарии покрытия, активное сообщество и обширные материалы.В будущем мы сосредоточимся больше на стабильности Kylin в сценариях приложений движка Didi OLAP, а также как запрос и оптимизация сборки.

Чжэн Цюе, старший инженер-эксперт платформы данных Didi, руководитель группы системы данных Didi.

Джин Говей, опытный инженер платформы данных Didi, в основном отвечает за создание механизма OLAP.

Чжан Сяодун, старший инженер Didi Data Platform, в основном отвечает за проектирование и разработку метаданных механизма OLAP, а также за эксплуатацию и обслуживание кластера Apache Kylin.

Команда платформы данных отдела базовой платформы Didi отвечает за построение хранилища данных компании, управление данными и разработку основных инструментов обработки данных и т. д. Команда предоставляет механизмы OLAP, специальные инструменты, карты данных, платформы анализа данных, платформы моделирования и другие продукты для стабильно и эффективно обслуживать пользователей.