Что такое ОЛАП?

Благодаря постоянному развитию таких технологий, как Интернет, Интернет вещей, 5G, искусственный интеллект и облачные вычисления, в Интернете генерируется все больше и больше данных, и работа Интернета стала более совершенной. данные, анализ данных и цифровой маркетинг. Это стало предметом внимания каждой интернет-компании. OLAP и OLTP — это технологии, с которыми мы обязательно столкнемся при анализе данных. Прежде чем перейти к выбору технологии механизма OLAP, давайте сначала посмотрим, что означают эти две технологии.

OLTP (онлайн-обработка транзакций OnlineTransactionProcessing),да Традиционная технология применения реляционной базы данных,по поставкам Обработка ежедневных и основных дел,Например, онлайн-транзакции и т. д.。OLAP (онлайн-аналитическая обработка),даанализ больших данныхизприкладная технология,поставляет комплекс аналитических операций с упором на поддержку принятия решений. Текущий основной двигатель изOLAP включает Hive, Presto, Druid, Clickhouse, Kylin, Sparksql, Greeplum.,Каждый двигатель имеет свои особенности

OLAP (On-line Analytical Processing, Онлайн-аналитическая обработка) — совокупность различных ориентированных на анализ операций, реализованных на основе многомерной модели хранилища данных. Вы можете сравнить его с традиционной OLTP (онлайн-обработкой транзакций), чтобы увидеть его характеристики:

Разговор об OLAP восходит к 1993 году.

Рекомендации OLAP

Руководство 1. Модели OLAP должны обеспечивать многомерное концептуальное представление. Принцип 2. Рекомендации по обеспечению прозрачности Критерий 3 Критерии доступности Руководство 4. Стабильные возможности отчетности Руководство 5. Архитектура клиент/сервер Критерий 6: Критерий равенства по размерам Рекомендации 7: Рекомендации по обработке динамических разреженных матриц Руководство 8. Руководство по возможности многопользовательской поддержки. Руководство 9. Неограниченные межпространственные операции Руководство 10. Интуитивное манипулирование данными Руководство 11. Гибкое создание отчетов Руководство 12. Неограниченная размерность и уровни агрегирования

Ключевые характеристики сценариев OLAP

Большинство из них — запросы на чтение Всего данныхдасо значительнымизпартия(> 1000 строки) писать Не изменять добавленные данные Каждый запрос считывает большое количество строк из базы данных, но требует лишь небольшого количества столбцов. Широкие таблицы, то есть каждая таблица содержит большое количество столбцов. Меньше запросов (обычно сотни запросов в секунду или меньше на сервер) Для простых запросов допускайте задержку примерно в 50 миллисекунд. Данных в столбцах сравнительно мало: числа и короткие строки (например, каждый URL 60 байт) Требует высокой пропускной способности при обработке одного запроса (до миллиардов строк в секунду на сервер). Бизнес не обязателен Низкие требования к согласованности данных Каждый запрос небольшой, за исключением одной большой таблицы. Результаты запроса значительно меньше исходных данных. Другими словами, данные можно фильтровать или агрегировать и помещать в память одного сервера.

В отличие от OLAP, система OLTP делает упор на эффективность использования памяти базы данных, скорость выполнения различных индикаторов памяти, переменные привязки, параллельные операции и транзакционность.

В системах OLAP основное внимание уделяется анализу данных, времени выполнения SQL, дисковому вводу-выводу и секционированию.

OLAP-классификация

OLAP — это метод вычислений, который позволяет пользователям удобно и быстро анализировать данные с разных точек зрения. Основной поток OLAP можно разделить на три категории:

1. Многомерная OLAP (Многомерная OLAP)、 2. Реляционная OLAP 3. Гибридный OLAP Три основные категории.

1. Многомерная OLAP (Многомерная OLAP)

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

Архитектура MOLAP состоит из трех компонентов: сервера базы данных, сервера MOLAP и интерфейсных инструментов.

Типичными представителями МОЛАП являются: Друид и Кайлин. MOLAP обычно генерирует предварительно агрегированные данные при записи данных на основе определяемых пользователем измерений и показателей (также называемых индикаторами). Когда приходит запрос Query, он фактически запрашивает предварительно агрегированные данные вместо исходных подробных данных. В режиме запроса. относительно фиксированных сценариях такое ускорение оптимизации очевидно.

Все преимущества и недостатки MOLAP связаны с его ссылкой на предварительную обработку данных (предварительная обработка). Предварительная обработка данных: исходные данные предварительно агрегируются и рассчитываются по заданным правилам расчета, что позволяет избежать большого количества мгновенных вычислений в процессе запроса и повышает производительность запроса.

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

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

2. Реляционная OLAP

Реляционная OLAP (ROLAP) — это промежуточные серверы, которые находятся между реляционными внутренними серверами и пользовательскими интерфейсными инструментами, которые используют реляционную или расширенную реляционную СУБД для сохранения и обработки данных хранилища, а также используют промежуточное программное обеспечение OLAP для предоставления недостающих данных.

Архитектура ROLAP показана ниже и включает в себя сервер базы данных, сервер ROLAP и интерфейсные инструменты.

Типичными представителями ROLAP являются: Presto, Impala, GreenPlum, Clickhouse, Elasticsearch, Hive, Spark SQL, Flink SQL.

Преимущества ROLAP заключаются в следующих двух аспектах:

Во-первых, при записи данных ROLAP не использует технологию предварительного агрегирования, такую ​​как MOLAP. Когда ROLAP получает запрос запроса, он сначала анализирует запрос, генерирует план выполнения, сканирует данные, выполняет реляционные операторы и выполняет фильтрацию (Where), агрегацию (Sum, Avg, Count), ассоциацию (Join) и группировку. по исходным данным (Группировать по), сортировать (Упорядочить по) и т. д. и, наконец, возвращать результаты расчета пользователю. Весь процесс рассчитывается в реальном времени, и для оптимизации запроса нет предварительно агрегированных данных. Все, что имеет значение, — это размер ресурсов и вычислительная мощность.

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

Однако у ROLAP есть и недостатки: когда объем данных велик или запрос сложен, производительность запроса не может быть такой стабильной, как MOLAP. Все вычисления запускаются немедленно (без предварительной обработки), поэтому они потребляют больше вычислительных ресурсов и приводят к возможным повторным вычислениям.

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

3. Гибридный OLAP

Гибридный OLAP представляет собой сочетание MOLAP и ROLAP. При запросе агрегированных данных используйте технологию MOLAP; при запросе подробных данных используйте технологию ROLAP; В соответствии с заданными сценариями использования, чтобы добиться оптимизации производительности запросов. Техническая архитектура гибридного OLAP выглядит следующим образом:

Преимущество гибридного OLAP в том, что он сочетает в себе преимущества MOLAP и ROLAP и обеспечивает быстрый доступ ко всем уровням агрегации. А еще потому, что он хранит только совокупную информацию на сервере OLAP, а подробные записи хранятся в реляционной базе данных. Таким образом, дубликаты подробных записей не сохраняются, что позволяет сбалансировать требования к дисковому пространству.

Недостаток гибридного OLAP заключается в том, что он объединяет MOLAP и ROLAP, поэтому ему необходимо поддерживать как MOLAP, так и ROLAP, а его архитектура также очень сложна.

4.Others

В дополнение к этому включены некоторые другие классификации, в том числе OLAP с поддержкой Интернета (WOLAP), настольная OLAP (DOLAP), мобильная OLAP (MOLAP) и пространственная OLAP (SOLAP). Но в целом он не очень популярен, поэтому больше вводить его не будет.

OLAP-архитектура

Концептуальная записка

• Serde：сериализациядесериализация,serialize/deSerialize
• MPP：Технология массово-параллельной обработки (Massively Parallel Processor)
• В зависимости от типа запроса OLAP Обычно делится на Специальный запроси Солидный запрос,
  • Специальный запрос:по почерку sql Выполните некоторые временные потребности в анализе данных, например sql Форма изменяема, логика сложная, жестких требований к времени запроса нет.
  • Солидный запрос：обратитесь кизда Некоторые затвердевшиеиз Получить номер、Посмотрите на спрос,пользователям через информационный продукт в форме предоставления,Тем самым повышая эффективность анализа данных и операций. Этот вид sql Фиксированный режим предъявляет более высокие требования ко времени отклика.

В соответствии с реализацией архитектуры основные механизмы OLAP в основном делятся на следующие три категории:

• Система архитектуры MPP(Presto/Impala/SparkSQL/Drill ждать). Эта архитектура в основном начинается с механизма запросов и использует механизм распределенных запросов вместо использования hive+mapreduce архитектура для повышения эффективности запросов.
• Система архитектуры поисковой системы(es,solr и т.д.), конвертировать данные в инвертированный индекс при входе в базу данных, используя Scatter-Gather Вычислительная модель жертвует гибкостью ради хорошей производительности и может обеспечить ответ на поисковые запросы за доли секунды. Однако для запросов, ориентированных на сканирование и агрегацию, по мере увеличения объема обрабатываемых данных время ответа снижается до минутного уровня.
• Предварительная вычислительная система（Druid/Kylin и т. д.), данные предварительно агрегируются при вводе в базу данных, что еще больше снижает гибкость в плане производительности для достижения реакции второго уровня на чрезвычайно большие наборы данных. Текущий метод реализации отслеживания данных с точки зрения потребностей бизнеса заключается в следующем: запрашивать и составлять список данных в соответствии с указанными данными в каждом отчетном периоде, а также анализировать причины неуплаты, что смещается в сторону Солидного. запросить способ. Однако существующий способ реализации заключается в том, чтобы сначала запросить данные основной таблицы в соответствии со значением столбца запроса, а затем получить вспомогательную таблицу запроса на основе связанных полей вспомогательной таблицы основной таблицы. sql,sql Для динамического сращивания этот вид метода более склонен к Специальный запросить реализацию.

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

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

Общие операции механизма OLAP

Несколько операций OLAP, описанных ниже, предназначены для схем Кимбалла «Звезда» и «Снежинка». В модели Кимбалла определены факты и измерения.

Сведение/агрегирование: выберите определенные измерения и агрегируйте факты на основе этих измерений. Если они выражены в SQL, это выбор dim_a, aggs_func(fact_b) из группы fact_table с помощью dim_a. Детализация: Детализация и детализация — это противоположные операции. Он выбирает определенные измерения, разбирает их на более мелкие измерения (например, годы на месяцы, провинции на города), а затем объединяет факты. Нарезка (Slicing, Dicing): выберите определенные измерения, отфильтруйте значения этих измерений в соответствии с конкретными значениями и разрежьте исходный большой куб на маленькие кубики. Например, dim_a в («CN», «США») Вращение (Pivot/Rotate): смена размерных позиций. На рисунке ниже приведен конкретный пример:

Сравнение движка OLAP с открытым исходным кодом

Учитывая текущую популярность в индустрии больших данных, несколько OLAP с открытым исходным кодом: Hive, SparkSQL, FlinkSQL, Clickhouse, Elasticsearch, Druid, Kylin, Presto и Impala выбрали несколько сценариев для проведения теста.,Можно сказать, что в настоящее время не существует двигателя, способного обрабатывать такой объем данных.,Идеальная гибкость и производительность,Пользователям необходимо делать выбор исходя из своих собственных потребностей.

Введение

impala

Impala разработана с открытым исходным кодом Cloudera. Impala разработана с открытым исходным кодом Cloudera и может запрашивать данные, хранящиеся в HDFS и HBase. Как и Hive, это также решение SQL на Hadoop. Но Impala отказалась от MapReduce и использовала технологию баз данных, более похожую на традиционную MPP, для повышения скорости запросов.

Impala может напрямую запрашивать данные в HDFS или HBase и легко подключаться к существующему хранилищу. Импалу нужно устанавливать отдельно, а паас - это основная рекомендация в компании. Необходимо подтверждение на сайте. Impala предоставляет интерфейс jdbc и механизм выполнения sql, которые можно интегрировать с существующими системами.

Presto

Presto — это механизм запросов больших данных Facebook с открытым исходным кодом, который предназначен для решения проблемы медленного создания запросов улья. Написанные на Java, все данные обрабатываются в памяти.

Нативная интеграция с Hive, Hbase и реляционными базами данных. Необходимо подтвердить на сайте, может ли это быть предоставлено. Предоставить интерфейс jdbc и механизм выполнения sql, которые можно интегрировать с существующими системами.

druid

Друид, как и килин, использует предварительные вычисления. Основное решение — выполнять агрегатные запросы к большому объему данных на основе временных рядов. Данные могут быть получены в режиме реального времени и проверены сразу после входа в Друид. При этом данные практически неизменяемы. Обычно это фактическое событие, основанное на временном ряде. После того, как факт произошел, он вводится в Druid, и внешняя система может запросить этот факт.

Его необходимо предварительно вычислить и данные сохранить в файле Segment друида, который занимает часть ресурсов хранилища. Необходимо подтвердить на сайте, может ли это быть предоставлено. Не дружелюбен к поддержке sql, должен быть написан на его собственном диалекте

kylin

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

1. Хранилище построения данных: построение куба, информация метаданных. 2.Разбор и выполнение SQL: механизм запросов (интерпретатор SQL), модуль маршрутизации (выполнение SQL). 3. Служба интерфейса верхнего уровня jdbc/odbc, служба отдыха;

Идея приложения: Преобразуйте данные в кусте в куб в соответствии со столбцом запроса, сохраните его в hbase и подключите трассировку данных к интерфейсу jdbc kylin для реализации быстрого запроса.

Необходимо выполнить предварительные вычисления, собрать данные в куб и сохранить их в hbase. Необходимо подтвердить на сайте, может ли это быть предоставлено. Предоставление интерфейса jdbc и службы отдыха. Redis Синхронизируйте данные, подлежащие анализу, с Redis и быстро запрашивайте данные в Redis. Данные за этот месяц можно синхронизировать с Redis перед анализом.

контраст

1. Контраст параллелизма и задержки запросов

Увидев это, некоторые люди могут задать вопросы: Hive, SparkSQL, FlinkSQL и т. д. либо медленны в скорости выполнения запросов, либо неспособны увеличить количество запросов в секунду. Как их можно рассматривать как механизмы OLAP? Фактически в определении OLAP нет ограничений на скорость выполнения запроса и количество операций в секунду. Кроме того, вот два важных показателя для измерения конкретных бизнес-сценариев OLAP:

Скорость запроса: задержка поиска Возможность параллельного выполнения запросов: QPS Если перечисленные выше механизмы OLAP разделены в соответствии с различными сценариями запросов и двумя показателями скорости запроса и возможности параллельного выполнения запросов, возможности этих механизмов OLAP делятся следующим образом:

Сценарий 1: Простой запрос

Простые запросы относятся к точечным запросам, простым запросам агрегирования или запросам данных, которые могут обращаться к индексам или материализованным представлениям (материализованные представления относятся к материализованным промежуточным результатам запроса, таким как предварительно агрегированные данные). Такие запросы часто появляются в корпоративных приложениях [онлайн-сервисов передачи данных], таких как Alibaba Business Consultant, Tencent's Guangdiantong, рекламный бизнес JD.com и т. д. Их общими характеристиками являются внешние услуги и они ориентированы на бизнес-клиентов B-конца (обычно несколько уровней 100 000); большой объем одновременных запросов (QPS); высокие требования ко времени ответа, обычно на уровне мс (вы можете себе представить, что если рекламодатель запрашивает данные о доставке страницы, и если через 10 секунд не будет результата, это ухудшит впечатление) ; режим запроса Относительно фиксированный и простой. Как видно из рисунка ниже, наиболее подходящими для этого сценария являются Elasticsearch, Druid и Kylin.

Сценарий 2: Сложный запрос

Сложные запросы относятся к сложным запросам агрегации, СКАНИРОВАНИЮ больших пакетных данных и сложным запросам (например, JOIN). В специальных сценариях часто возникают такие запросы. Часто пользователи не могут заранее знать, что они хотят запросить, и они носят скорее исследовательский характер. Здесь также разделены на несколько ситуаций в зависимости от количества запросов в секунду и времени запроса, как показано на рисунке ниже. Просто выберите соответствующий механизм в соответствии с потребностями бизнеса. Следует отметить, что, хотя FlinkSQL и SparkSQL могут удовлетворить схожие потребности, они еще не доступны в готовом виде и требуют периферийной экологической конструкции. В настоящее время все больше сценариев применения этих двух технологий по-прежнему реализуются через гибкие API-интерфейсы программирования. оффлайн расчеты.

2. Выполнить модель контрастности

Модель выполнения Scatter-Gather: эквивалент карты и сокращения в MapReduce, без нескольких раундов итераций, а промежуточные результаты вычислений часто сохраняются в памяти и обмениваются напрямую через сеть. Elasticsearch, Druid и Kylin — модели этого типа. MapReduce: Hive использует эту модель. MPP: Научное название MPP — массовые параллельные вычисления. На самом деле трудно дать ему точное определение. Если говорить в широком смысле, то Presto, Impala, Clickhouse, Spark SQL и Flink SQL — все имеют значение. Некоторые говорят, что Spark SQL и Flink SQL относятся к модели DAG. Поразмыслив над этим, мы считаем, что DAG — это не отдельная модель, а просто способ генерировать планы выполнения.

Основные характеристики основных OLAP-движков с открытым исходным кодом

1.Hive

Hive — это распределенное решение SQL на Hadoop, которое использует вычислительную модель MapReduce для выполнения распределенных вычислений. Hive хорошо справляется с длительной автономной пакетной обработкой. Чем больше объем данных, тем очевиднее преимущество. Hive более популярен среди крупных интернет-компаний с большими объемами данных и сильными потребностями, ориентированными на данные. За последние два года, с постепенной популярностью Clickhouse, многие компании перешли на решения Clickhouse для некоторых нужд Интернет-хранилищ данных, общий объем данных которых не превышает ста петабайт. Преимущество Clickhouse в том, что одиночный запрос выполняется быстрее, он не зависит от Hadoop, а его архитектура, эксплуатация и обслуживание проще.

2.Spark SQL、Flink SQL

В большинстве сценариев скорость вычислений Hive слишком низкая, не говоря уже о том, что она не может удовлетворить потребности внешних онлайн-сервисов, которым требуется высокое количество запросов в секунду и низкая задержка запросов. Даже внутренние аналитики продуктов, операций и данных предприятия часто жалуются на производительность Hive. . Специальные запросы выполняются слишком медленно. Эти болевые точки способствовали появлению и развитию моделей вычислений MPP и DAG. Такие технологии, как Spark SQL, Flink SQL и Presto, также очень популярны на предприятиях.

Spark SQL и Flink SQL имеют более высокую скорость выполнения, богатые API-интерфейсы программирования, поддерживают как потоковые вычисления, так и пакетную обработку, а также имеют тенденцию унифицировать потоки и пакеты, что упрощает приложения для больших данных.

3.Clickhouse

ClickHouse — это столбчатая база данных с открытым исходным кодом, которая в последние годы привлекла большое внимание и в основном используется в области анализа данных (OLAP). В настоящее время отечественное сообщество находится на подъеме, и крупные производители последовали его примеру и использовали его в больших масштабах.

Исходя из потребностей сценариев OLAP, ClickHouse настроил и разработал новый набор эффективных механизмов столбчатого хранения, а также реализовал богатые функции, такие как упорядоченное хранение данных, индекс первичного ключа, разреженный индекс, сегментирование данных, секционирование данных, TTL и первичный индекс. и вторичная репликация. Вышеупомянутые функции вместе закладывают основу для чрезвычайно быстрого выполнения анализа ClickHouse.

ClickHouse имеет простую архитектуру развертывания, прост в использовании и не зависит от системы Hadoop (HDFS+YARN). Что он хорош, так это выполнение агрегатных запросов к одной таблице с большим объемом данных. Clickhouse реализован на C++. Базовая реализация имеет возможности оптимизации, такие как векторизованное выполнение (Vectorized Execution) и сокращение ветвей, а также обеспечивает высокую производительность запросов. В настоящее время широко используемый в интернет-компаниях, он больше подходит для внутренних приложений типа отчетов BI и может обеспечить скорость ответа с малой задержкой (уровень мс), что означает, что одиночный запрос выполняется очень быстро.

Но Clickhouse также имеет свои ограничения. Выбирая технологию OLAP, вам следует избегать ее использования в качестве механизма для запросов, связанных с несколькими таблицами (JOIN), и избегать ее использования в сценариях, где ожидается поддержка запросов к данным с высоким уровнем параллелизма, таких как Поля анализа OLAP. В Jingzhong обычно считается, что QPS достигает 1000+, что считается высоким параллелизмом, но в таких бизнес-сценариях, как электронная коммерция и захват красного конверта, более 10 Вт считается высоким параллелизмом. В конце концов, в сценариях анализа данных, где. данные огромны, а расчеты сложны, QPS, достигающий 1000, уже очень высок. Например, Clickhouse, если объем данных соответствует уровню ТБ и расчет агрегации немного сложнее, для одного кластера, как правило, очень сложно достичь 100 QPS, поэтому он больше подходит для внутренних приложений отчетов BI на предприятии. но не подходит для сотен тысяч отчетов рекламодателей или приложений отчетов, связанных с миллионами владельцев магазинов Taobao. Модель выполнения Clickhouse определяет, что она сделает все возможное для выполнения запроса вместо одновременного выполнения множества запросов.

4.ElasticSearch

Когда дело доходит до ElasticSearch, у многих создается впечатление, что это распределенная поисковая система с открытым исходным кодом. Нижний уровень опирается на структуру инвертированного индекса Lucene и поддерживает сегментацию текста, что делает его очень подходящим в качестве службы поиска. А используя Elasticsearch в качестве поисковой системы, кластеру из трех узлов несложно поддерживать более 1000 запросов в секунду. Это сценарий поиска.

Однако то, о чем мы собираемся здесь поговорить, — это еще одна функция Elasticsearch, то есть как OLAP-движка для сценариев агрегации, которая сильно отличается от сценариев поиска. Сценарий агрегирования может быть эквивалентен выбору c1, c2, sum(c3), count(c4) from table where c1 in (‘china’, ‘usa’) and c2 < 100 Этот вид SQL используется для выполнения многомерной группировки и агрегирования. Хотя Elasticsearch DSL — это сложный JSON, а не SQL, но смысл тот же, и их можно конвертировать друг в друга.

Использование Elasticsearch в качестве механизма OLAP имеет несколько преимуществ: (1) Хороший результат при высоком количестве QPS (QPS). > 1K), низкая задержка, множество условий фильтрации и простые режимы запросов (например, «укажи и щелкни», простое агрегирование). (2) Возможности автоматического управления кластером (осколки распределение, восстановление) возможности очень сильны. API-интерфейсы для кластеризации, управления индексами и просмотра очень богаты.

Механизм выполнения ES — это простейшая модель Scatter-Gather, которая эквивалентна сочетанию Map и сокращения в вычислительной модели MapReduce. Обмен данными узла между Scatter и Gather также основан на памяти и не требует предварительной записи на диск для каждого Shuffle, как MapReduce. Формат файла Lucene, на который опирается ES на нижнем уровне, мы можем понимать Lucene как смешанный режим строк и столбцов и ускорять запрос данных через FST, пропускать таблицы и т. д. во время запроса. Проблема с этой моделью Scatter-Gather заключается в том, что если объем данных Gather/Reduce относительно велик, он может быть очень медленным, поскольку ES выполняется на одном узле. В целом ES повышает качество выполнения простых запросов OLAP и снижает задержку за счет жертвования гибкостью.

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

ElasticSearch и Solar также можно отнести к моделям с широкими таблицами. Однако архитектура их систем совершенно различна. Эти две системы обычно называются поисковыми системами. Они используют инвертированные индексы и применяют модель вычислений Scatter-Gather для повышения производительности запросов. Эффект запроса лучше для поисковых запросов, но когда объем данных велик или выполняются запросы сканирования и агрегирования, производительность запроса будет сильно снижена.

5.Presto

Presto, Impala и GreenPlum основаны на архитектуре MPP по сравнению с простыми моделями Scatter-Gather, такими как Elasticsearch, Druid и Kylin, они более универсальны в поддержке вычислений SQL и больше подходят для сценариев специальных запросов. системы общего назначения часто лучше, чем специализированные системы. Оптимизировать производительность сложнее, поэтому они не подходят для запроса QPS (эталонное значение QPS). > 1000), требования к задержке относительно высоки (поиск опорного значения latency < 500 мс) онлайн-сервис, который больше подходит для сервисов внутренних запросов внутри компании и сервисов для ускорения запросов Hive. Еще одна замечательная особенность Presto заключается в том, что он использует SQL стандарта ANSI и поддерживает более 30 соединителей источников данных.

6.Impala

Impala — это интерактивный инструмент запросов к большим данным SQL в реальном времени, разработанный Cloudera на основе Google Dremel. Это предпочтительный механизм запросов и анализа больших данных на уровне PB для платформы CDH. Он обладает той же масштабируемостью, что и Hadoop, обеспечивает синтаксис типа SQL (Hsql), а также может иметь высокую скорость ответа и пропускную способность в многопользовательских сценариях. Он реализуется на Java и C++. Java обеспечивает интерфейс и реализацию взаимодействия с запросами, а C++ реализует часть механизма запросов. Кроме того, Impala также может совместно использовать Hive Metastore и даже напрямую использовать JDBC JAR Hive и Beeline Query Impala. и поддерживают широкие форматы хранения данных (Parquet, Avro и т. д.).

Кроме того, Impala больше не использует медленную пакетную обработку Hive+MapReduce, а использует механизм распределенных запросов (состоящий из трех частей: планировщик запросов, координатор запросов и механизм выполнения запросов), аналогичный механизму в коммерческих параллельных реляционных базах данных, который может напрямую запрашивать данные. из HDFS Или используйте SELECT, JOIN и статистические функции для запроса данных в HBase, что значительно снижает задержку. Impala часто предоставляет услуги вместе с механизмом хранения Kudu. Самым большим преимуществом этого является то, что перечисление происходит быстрее и поддерживает обновление и удаление данных.

7.Druid

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

Особенности Друида включают в себя:

Потребление данных в реальном времени Druid действительно обеспечивает получение данных в реальном времени и получение результатов запросов в реальном времени.

Druid поддерживает данные уровня PB, быструю обработку сотен миллиардов событий и поддерживает тысячи одновременных запросов в секунду.

Ядром Druid являются временные ряды, в которых данные хранятся в пакетном режиме в соответствии с временными рядами. Это очень удобно для сценариев статистического анализа, основанных на времени.

Druid делит столбцы данных на три категории: временные метки, столбцы измерений и столбцы индикаторов.

Druid не поддерживает соединения нескольких таблиц.

Данные в Druid обычно представляют собой статистические данные низкого уровня, предварительно рассчитанные с использованием других вычислительных платформ (Spark и т. д.).

Druid не подходит для обработки сценариев запросов со сложными и меняющимися измерениями перспективы.

Типы запросов, с которыми хорошо справляется Druid, относительно единичны. Некоторые часто используемые операторы SQL (groupby и т. д.) выполняются в Druid со средней скоростью.

Druid поддерживает вставку и обновление данных с малой задержкой, но это намного медленнее, чем hbase и традиционные базы данных.

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

8.Kylin

Kylin сам по себе является системой MOLAP. Конструкция многомерного куба (MOLAP Cube) позволяет пользователям определять модели данных для более чем 10 миллиардов наборов данных в Kylin и строить кубы для предварительного агрегирования данных.

Сценарии, подходящие для Кайлина, включают:

Пользовательские данные существуют в Hadoop HDFS. Hive используется для доступа к данным файлов HDFS в режиме реляционных данных. Объем данных огромен, более 500 ГБ.

Каждый день постепенно импортируется несколько гигабайт или даже десятков гигабайт данных.

Существует менее 10 относительно фиксированных измерений анализа.

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

Подвести итог

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

Ссылки

https://blog.csdn.net/weixin_52672149/article/details/119248932