Экспертный блог
+7 905 230 91 49
info@bilab.ru
блог о bi, №1 в рунете

Распределенное хранилище аналитических данных

Apache Kylin
Apache Kylin™
— это распределенное хранилище аналитических данных с открытым исходным кодом, разработанное для обеспечения возможностей OLAP (онлайн-аналитической обработки) в эпоху Big Data. Распределенные вычисления и хранение данных обеспечивают ряд преимуществ, таких как масштабируемость, отказоустойчивость и балансировка нагрузки.
Аналитики вынуждены часто группировать и объединять данные. Эти операции в реляционных базах данных являются ресурсоемкими. Оперативная аналитическая обработка (OLAP) — это технология, которая упорядочивает большие коммерческие базы данных и поддерживает сложный анализ. Ее можно использовать для выполнения сложных аналитических запросов без негативного воздействия на системы транзакций. Данные OLAP предварительно рассчитаны и агрегированы, что ускоряет анализ.

Фундаментальная структура Kylin OLAP Engine включает в себя механизм метаданных, механизм запросов, механизм заданий и механизм хранения для запуска всего стека. Он также включает сервер REST для обслуживания клиентских запросов. В качестве хранилища аналитических данных Kylin предлагает ANSI SQL для Hadoop/Spark и поддерживает большинство функций запросов ANSI SQL. На рисунке 1 представлена схема взаимодействия подсистем Apache Kylin. Последняя стабильная версия Kylin4, основными компонентами которой являются:

  1. Hadoop
  2. Hive
  3. Spark + Parquet

схема взаимодействия процессов в Hadoop

Hadoop
— это свободно распространяемый набор утилит, библиотек и фреймворк для разработки и выполнения распределённых программ, работающих на кластерах из множества нод (узлов).

Изначально проект разработан на Java в рамках вычислительной парадигмы MapReduce, когда приложение разделяется на большое количество одинаковых элементарных заданий, которые выполняются на распределенных компьютерах (узлах) кластера и сводятся в единый результат.


В проект входят такие модули:


  1. Hadoop Common — общие утилиты, поддерживающие другие модули Hadoop
  2. Распределенная файловая система Hadoop (HDFS™) — распределенная файловая система, обеспечивающая высокоскоростной доступ к данным приложений
  3. Hadoop YARN — платформа для планирования заданий и управления ресурсами кластера
  4. Hadoop MapReduce — система на основе YARN для параллельной обработки больших наборов данных

Кластер HDFS включает следующие компоненты:


  1. Управляющий узел, узел имен или сервер имен (NameNode) — отдельный, единственный в кластере, сервер с программным кодом для управления пространством имен файловой системы, хранящий дерево файлов, а также мета-данные файлов и каталогов. NameNode — обязательный компонент кластера HDFS, который отвечает за открытие и закрытие файлов, создание и удаление каталогов, управление доступом со стороны внешних клиентов и соответствие между файлами и блоками, дублированными (реплицированными) на узлах данных. Сервер имён раскрывает для всех желающих расположение блоков данных на машинах кластера.
  2. Secondary NameNode — вторичный узел имен, отдельный сервер, единственный в кластере, который копирует образ HDFS и лог транзакций операций с файловыми блоками во временную папку, применяет изменения, накопленные в логе транзакций к образу HDFS, а также записывает его на узел NameNode и очищает лог транзакций. Secondary NameNode необходим для быстрого ручного восстановления NameNode в случае его выхода из строя.
  3. Узел или сервер данных (DataNode, Node) — один их множества серверов кластера с программным кодом, отвечающим за файловые операции и работу с блоками данных. DataNode — обязательный компонент кластера HDFS, который отвечает за запись и чтение данных, выполнение команд от узла NameNode по созданию, удалению и репликации блоков, а также периодическую отправку сообщения о состоянии (heartbeats) и обработку запросов на чтение и запись, поступающих от клиентов файловой системы HDFS. Стоит отметить, что данные проходят с остальных узлов кластера к клиенту мимо узла NameNode.
  4. Клиент (client) — пользователь или приложение, взаимодействующий через специальный интерфейс (API — Application Programming Interface) с распределенной файловой системой. При наличии достаточных прав, клиенту разрешены следующие операции с файлами и каталогами: создание, удаление, чтение, запись, переименование и перемещение. Создавая файл, клиент может явно указать размер блока файла (по умолчанию 64 Мб) и количество создаваемых реплик (по умолчанию значение равно 3-ем).

Фундаментальная идея YARN состоит в том, чтобы разделить функции управления ресурсами и планирования/мониторинга заданий на отдельные демоны. Идея состоит в том, чтобы иметь глобальный ResourceManager ( RM ) и ApplicationMaster для каждого приложения ( AM ). Приложение представляет собой либо одно задание, либо группу DAG заданий.

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

ApplicationMaster для каждого приложения, по сути, представляет собой библиотеку, специфичную для платформы, и ему поручено согласовывать ресурсы с ResourceManager и работать с NodeManager(s) для выполнения и мониторинга задач.

схема взаимодействия процессов в Hadoop

ResourceManager состоит из двух основных компонентов: Scheduler и ApplicationsManager.
Scheduler отвечает за распределение ресурсов для различных запущенных приложений с учетом известных ограничений мощностей, очередей и т. д. Scheduler не выполняет мониторинг или отслеживание состояния приложения. Кроме того, он не дает никаких гарантий в отношении перезапуска невыполненных задач из-за сбоя приложения или аппаратных сбоев. Scheduler выполняет свою функцию планирования на основе требований приложений к ресурсам; это делается на основе абстрактного понятия ресурсы контейнера, который включает в себя такие элементы, как память, процессор, диск, сеть и т.д.
ApplicationsManager отвечает за прием отправленных заданий, согласование первого контейнера для выполнения конкретного приложения ApplicationMaster и предоставляет услугу для перезапуска контейнера ApplicationMaster в случае сбоя. ApplicationMaster для каждого приложения отвечает за согласование соответствующих контейнеров ресурсов с планировщиком, отслеживание их состояния и мониторинг хода выполнения.
Hadoop MapReduce — это программная среда для простого написания приложений, которые обрабатывают огромные объемы данных (много терабайтные наборы данных) параллельно на больших кластерах (тысячи узлов) общедоступного оборудования надежным и отказоустойчивым способом.
MapReduce job (задание) обычно разбивает входной набор данных на независимые фрагменты, которые обрабатываются map tasks полностью параллельно. Фреймворк сортирует выходные данные карт, которые затем вводятся в reduce tasks. Обычно как ввод, так и вывод задания хранятся в файловой системе. YARN заботится о планировании задач, их мониторинге и повторном выполнении невыполненных задач.
Hive

Apache Hive ™ — программное обеспечение хранилища данных, облегчающее чтение, запись и управление большими наборами данных, находящихся в HDFS, с помощью SQL-подобного языка запросов HiveQL.
Hive был создан, чтобы дать возможность непрограммистам, знакомым с SQL, работать с петабайтами данных, используя HiveQL. Традиционные реляционные базы данных предназначены для интерактивных запросов к малым и средним наборам данных и плохо обрабатывают огромные наборы данных. Вместо этого Hive использует пакетную обработку, чтобы быстро работать с очень большой распределенной базой данных. Hive преобразует запросы HiveQL в задания MapReduce, которые выполняются в распределенной среде планирования заданий Apache Hadoop, Yet Another Resource Negotiator (YARN). Он запрашивает данные, хранящиеся в распределенном хранилище Hadoop (HDFS).
HiveQL позволяет создавать таблицы хранилища данных и для них явно указывать директорию хранения файлов в HDFS, тип файлов, разделитель. Пример скрипта представлен на рисунке.

скрипт создания таблицы в Hive

Особенностью такого вида таблиц является процесс добавления, удаления, изменения данных, который осуществляется путём работы с файлами в HDFS. То есть для загрузки данных в таблицу, созданную скриптом, представленным на рисунке 2, необходимо и достаточно расположить текстовый файл (например .csv), соответствующий структуре таблицы (без заголовков столбцов), в директории hdfs:/tmp/sqldata/t_dim_items.
Spark
Spark — это быстрый и универсальный движок для крупномасштабной обработки данных. Секрет скорости заключается в том, что Spark работает в оперативной памяти, что делает обработку намного быстрее, чем на жестких дисках.
RDD (Resilient Distributed Dataset) — это базовая концепция Spark. Набор кубоидов N-измерения может быть хорошо описан как RDD, куб N-измерения будет иметь N + 1 RDD. Эти RDD имеют отношение родитель/потомок, поскольку родитель может использоваться для создания дочерних элементов. С родительским RDD, кэшированным в памяти, генерация дочернего RDD может быть намного эффективнее, чем чтение с диска. Следующий рисунок описывает этот процесс.

Схема процесса построения RDDs

Рисунок 5 подробно иллюстрирует процесс вычисления кубоидов: на «этапе 5» Kylin использует HiveContext для чтения промежуточной таблицы Hive, а затем выполняет операцию «сопоставления», которая представляет собой сопоставление один к одному, чтобы закодировать исходные значения в K-V байты. При завершении Kylin получает RDD с промежуточным кодированием. На «этапе 6» промежуточный RDD агрегируется с помощью операции «reduceByKey», чтобы получить RDD-1, который является базовым прямоугольным параллелепипедом. Затем выполняется «flatMap» (карта «один ко многим») на RDD-1, потому что базовый кубоид имеет N дочерних кубоидов. И так далее, вычисляются RDDs всех уровней. Эти RDD будут сохранены в распределенной файловой системе по завершении, а также будут кэшированы в памяти для расчета следующего уровня. Когда дочерний элемент будет сгенерирован, он будет удален из кеша.

DAG Cubing в Spark

В результате работы Spark формируются файлы с агрегированными данных в формате Parquet. Apache Parquet — это формат файла данных с открытым исходным кодом, ориентированный на столбцы, разработанный для эффективного хранения и извлечения данных. Он обеспечивает эффективное сжатие данных и схемы кодирования с повышенной производительностью для обработки больших объемов сложных данных.
Spark работает в режиме распределенных вычислений, что позволяется предотвратить существование узкого места в производительности. Вычислительную мощность системы можно увеличить за счет горизонтального расширения (масштабирования). Существуют различные схемы планирования ресурсов, такие как Yarn, K8S или Mesos, для удовлетворения потребностей в изоляции ресурсов (в Apache Kylin4 используется Yarn).
Заключение
После рассмотрения подсистем Apache Kylin становится логичным описать процесс работы с этим инструментом, включающий в себя следующие основные этапы:
  1. Загрузка данных в HDFS;
  2. Разработка хранилища данных в Hive (создание таблиц c указанием источников в HDFS);
  3. Разработка модели данных, куба в Kylin;
  4. Сборка куба:
  • YARN выполняет процесс планирования и распределения ресурсов.
  • Spark формирует план построения кубоидов.
  • Spark выполняет построение кубоидов и запись данных в файлы Parquet.
5. Работа с аналитическим кубом (разработка sql-запросов).
В статье рассмотрена архитектура Apache Kylin, понимание которой существенно помогает при разработке аналитических решений и позволяет контролировать построение ненужных комбинации прямоугольных параллелепипедов при выполнении заданий Spark. Это значительно сокращает время сборки куба и задержку запросов.

Список источников:
https://bigdataschool.ru/wiki/hdfs
https://kylin.apache.org/
https://hadoop.apache.org/
https://hive.apache.org/
https://spark.apache.org/
https://bigdataschool.ru/wiki/spark
https://medium.com/@info_91596/apache-kylin-architecture-challenges-and-optimization-techniques-132ab6dddf44
https://medium.com/@cesaradvincula/next-generation-olap-analytics-apache-kylin-7a1c12a0c082

Вернуться к блогу