блог о bi, №1 в рунете
Основные нюансы сборки куба Kylin
Apache Kylin
Не так давно наша компания начала осваивать новый стек технологий Apache. Спустя несколько успешных проектов мы хотим поделиться опытом разработки и некоторыми фичами.
Apache Kylin – это распределенное хранилище предварительно рассчитанных и агрегированных данных, предназначенных для сложного анализа, то есть кубов оперативной аналитической обработки (OLAP). Важным этапом разработки кубов является настройка типов измерений и групп агрегирования. Apache Kylin имеет обширную документацию по настройке и оптимизации процесса сборки кубов. В данной статье будут рассмотрены выявленные закономерности скорости обработки данных и вариант конфигурации куба с большим количество измерений.
Разработка ведется в среде, развёрнутой из docker-образа Apache Kylin (apachekylin/apache-kylin-standalone:4.0.0) и настроенной в соответствии с рабочим сервером (описание конфигурации Apache Kylin в предыдущих статьях). Рассматриваемое в этой статье решение построено на модели данных, включающей одну таблицу фактов и пять таблиц измерений. Конструктор кубов Apache Kylin воспринимает каждый столбец таблицы измерения как отдельную единицу, тогда суммарно модель включает 61 столбец-измерение (далее в тексте «измерение»).
Конструктор куба Apache Kylin имеет два варианта типов измерений: normal и derived. Опытным путём определено, что запросы к кубу, включающие измерения типа normal, выдают данные в 2 раза быстрее, чем те же запросы, но с измерениями типа derived. Соответственно, в конструкторе кубов на шаге 2 для всех измерений модели установим тип normal (рисунок 1) с целью оптимизации скорости выполнения sql запросов.
В документации Apach Kylin указано, что теоретически для N измерений типа normal получается 2N комбинаций измерений – кубоидов. Время обработки куба и количество необходимых для этого вычислительных ресурсов прямо пропорционально количеству кубоидов. Следовательно, для оптимизации этого процесса необходимо разумно сократить количество комбинаций измерений. Этот этап проектирования куба предусмотрен на шаге «Advanced Setting» в разделе «Aggregation Groups».
Разработка ведется в среде, развёрнутой из docker-образа Apache Kylin (apachekylin/apache-kylin-standalone:4.0.0) и настроенной в соответствии с рабочим сервером (описание конфигурации Apache Kylin в предыдущих статьях). Рассматриваемое в этой статье решение построено на модели данных, включающей одну таблицу фактов и пять таблиц измерений. Конструктор кубов Apache Kylin воспринимает каждый столбец таблицы измерения как отдельную единицу, тогда суммарно модель включает 61 столбец-измерение (далее в тексте «измерение»).
Конструктор куба Apache Kylin имеет два варианта типов измерений: normal и derived. Опытным путём определено, что запросы к кубу, включающие измерения типа normal, выдают данные в 2 раза быстрее, чем те же запросы, но с измерениями типа derived. Соответственно, в конструкторе кубов на шаге 2 для всех измерений модели установим тип normal (рисунок 1) с целью оптимизации скорости выполнения sql запросов.
В документации Apach Kylin указано, что теоретически для N измерений типа normal получается 2N комбинаций измерений – кубоидов. Время обработки куба и количество необходимых для этого вычислительных ресурсов прямо пропорционально количеству кубоидов. Следовательно, для оптимизации этого процесса необходимо разумно сократить количество комбинаций измерений. Этот этап проектирования куба предусмотрен на шаге «Advanced Setting» в разделе «Aggregation Groups».
Рисунок 1 – настройка типов измерений куба
В результате тестирования различных вариантов групп агрегации, были выявлены общие правила их формирования:
1) Группа должна включать все измерения.
2) Mandatory Dimensions отсутствует.
3) Hierarchy Dimensions содержит все существующие иерархии, последними элементами которых являются первичные ключи (пример представлен на рисунке 2).
4)Joint Dimensions объединяет измерения, принадлежащие одной таблице (пример представлен на рисунке 3). Важно, что Hierarchy и Joint Dimensions должны содержать неповторяющиеся измерения.
1) Группа должна включать все измерения.
2) Mandatory Dimensions отсутствует.
3) Hierarchy Dimensions содержит все существующие иерархии, последними элементами которых являются первичные ключи (пример представлен на рисунке 2).
4)Joint Dimensions объединяет измерения, принадлежащие одной таблице (пример представлен на рисунке 3). Важно, что Hierarchy и Joint Dimensions должны содержать неповторяющиеся измерения.
Рисунок 2 – пример конфигурации Hierarchy Dimensions
Рисунок 3 – пример конфигурации Joint Dimensions
Предварительно рассчитанные данные хранятся в файлах parquet. Перед сохранением в HDFS (хранилище объектов) Kylin выполняет перераспределение предварительно рассчитанных данных (преобразование кадра данных Spark) и нумерацию разделов в соответствии с shard by столбцом, что положительно влияет на время поиска данных во время выполнения запроса к кубу и сокращает время выполнения sql запросов на 30% по сравнению с тем же решением, но без установленного столбца shard by.
Рисунок 4 – определение shard by date_id
Основной целью манипуляции данными является вычисление мер. Apache Kylin предоставляет ограниченный список функций агрегирования, представленный на рисунке 5.
Рисунок 5 – функций агрегирования Apache Kylin
Особого внимания заслуживает функция count_distinct, а именно определение типа возвращаемого ею значения. Для получения точного результата следует настроить меру в соответствии с рисунком 6.
Рисунок 6 – конфигурация меры с функцией агрегирования count_distinct
Вычисление count_distinct в Kylin возможно оптимизировать определением минимального размера секции глобального словаря на шаге «Configuration Overwrites» kylin.dictionary.globalV2-min-hash-partitions = 3. Кроме того, для использования Spark Cubing здесь необходимо прописать kylin.cube.aggrgroup.is-mandatory-only-valid = true (рисунок 7).
Рисунок 7 – изменение свойств Kylin для определённого куба
Следование вышеизложенным принципам проектирования куба в Kylin для рассматриваемого решения позволяет сократить количество кубоидов до 49, время построения секции за один месяц с количеством данных 25000 строк до 3,5 минут, среднее время sql запросов к кубу до 0,3 секунды.
Список источников:
https://kylin.apache.org/docs/tutorial/create_cube.html
https://kylin.apache.org/docs15/howto/howto_optimize_cubes.html
https://kylin.apache.org/docs/
https://cwiki.apache.org/confluence/display/KYLIN/Improve+query+performance+by+setting+shard+by+column
https://cwiki.apache.org/confluence/display/KYLIN/Global+Dictionary+on+Spark
https://juejin.cn/post/6854573220016701454
Список источников:
https://kylin.apache.org/docs/tutorial/create_cube.html
https://kylin.apache.org/docs15/howto/howto_optimize_cubes.html
https://kylin.apache.org/docs/
https://cwiki.apache.org/confluence/display/KYLIN/Improve+query+performance+by+setting+shard+by+column
https://cwiki.apache.org/confluence/display/KYLIN/Global+Dictionary+on+Spark
https://juejin.cn/post/6854573220016701454