Статья для понимания технической архитектуры Apache Kylin

Apache Kylin
Статья для понимания технической архитектуры Apache Kylin

Это 16-й день моего участия в августовском испытании обновлений.Подробности о событии:Испытание августовского обновления

текст

在这里插入图片描述

Систему Apache Kylin можно разделить на две части: онлайн-запрос и автономное построение.Техническая архитектура показана на рисунке.Онлайн-модули запросов в основном находятся в верхней половине, а автономное построение — в нижней половине.

Автономная сборка

Давайте сначала посмотрим на часть автономной сборки.

Как видно из рисунка, источник данных находится слева, в основном это Hadoop/Hive/Kafka/RDBMS, который сохраняет пользовательские данные для анализа.

В соответствии с определением метаданных механизм сборки, приведенный ниже, извлекает данные из источника данных и строит Cube.

Данные вводятся в виде реляционных таблиц и должны соответствовать схеме Star.

Map Reduce и Spark — основные технологии сборки, а Spark Engine — единственный механизм сборки в Kylin 4.0.

Построенный Cube сохраняется в механизме хранения справа, а Parquet используется в качестве хранилища.

В 3.x и более ранних версиях kylin всегда использовал HBase в качестве механизма хранения для сохранения предварительно вычисленных результатов после построения куба. Будучи ориентированной на семейство столбцов базой данных поверх HDFS, HBase обладает превосходной производительностью запросов, но все же имеет следующие недостатки:

  1. HBase не является настоящим колоночным хранилищем;
  2. HBase не имеет вторичного индекса, его единственным индексом является Rowkey;
  3. HBase не кодирует хранимые данные, и kylin должен сам выполнять процесс кодирования данных;
  4. HBase не подходит для облачного развертывания и автоматического масштабирования;
  5. Версии API разных версий HBase отличаются, и есть проблемы совместимости (например, 0,98, 1,0, 1,1, 2,0);
  6. Существуют разные версии HBase от поставщиков, и между ними возникают проблемы совместимости.

В ответ на вышеуказанные проблемы сообщество предложило использовать Apache Parquet + Spark для замены HBase по следующим причинам:

  1. Parquet — это зрелый и стабильный формат хранения столбцов с открытым исходным кодом;
  2. Parquet более удобен для использования в облаке и совместим с различными файловыми системами, включая HDFS, S3, хранилище BLOB-объектов Azure, Ali OSS и т. д.;
  3. Parquet хорошо интегрируется с Hadoop, Hive, Spark, Impala и др.;
  4. Паркет поддерживает пользовательские индексы.

онлайн-поиск

在这里插入图片描述

После завершения автономного построения пользователи могут отправлять SQL из указанной выше системы запросов для анализа запросов.

Kyin предоставляет различные интерфейсы RestAPI, JDBC/ODBC.

Независимо от того, из какого интерфейса вы входите, SQL в конечном итоге попадет на уровень сервиса Rest, а затем будет передан механизму запросов для обработки.

Здесь следует отметить, что оператор SQL написан на основе реляционной модели источника данных, а не Cube.

Во время разработки Kylin намеренно скрыл концепцию Cube от пользователей, выполняющих запросы. Аналитикам нужно только понять простую реляционную модель, чтобы использовать Kylin. Нет дополнительного порога обучения, а традиционные приложения SQL также легко мигрировать.

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

Весь процесс не обращается к исходному источнику данных.

Расширяемая архитектура для Apache Kylin версии 1.5

Apache Kylin версии 1.5 представил концепцию «расширяемой архитектуры».

Расширяемость означает, что Kylin может делать произвольные расширения и замены для трех модулей, от которых он в основном зависит.

Три зависимых модуля Kylin:数据源,构建引擎и存储引擎.

В начале проектирования, как члена семейства Hadoop, тремя являются Hive, MapReduce и HBase.

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

Например, для анализа в реальном времени может потребоваться импортировать данные из Kafka вместо Hive, а быстрое развитие Spark заставляет нас рассмотреть возможность замены MapReduce на Spark, чтобы значительно повысить скорость построения Cube, а HBase, его производительность чтения может быть не такой хорошей, как у Cassandra или Kudu и т. д.

Как видите, вопрос о том, можно ли заменить одну технологию на другую, стал распространенным.

Поэтому системная архитектура Kylin версии 1.5 была реконструирована, а три зависимости источника данных, механизма сборки и механизма хранения были абстрагированы в интерфейсы.

Пользователи Deepin могут выполнять вторичную разработку в соответствии со своими потребностями и заменять одну или несколько из них более подходящими технологиями.

Категории