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

Сегодняшние компромиссы: задержка или гибкость

Давайте сделаем шаг назад и посмотрим, как мы анализируем данные с разными компромиссами.

Гибкость требует времени

Предположим, ваши необработанные данные размещены в озере данных, доступном для обработки пользователями с помощью вычислительных заданий Spark / Hadoop или из механизма SQL.

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

Однако получение результатов занимает много времени, так как необработанные данные считываются из озера данных (s3 / HDFS / и т. Д.), А вычисления запускаются по запросу (специальным образом).

Возьмем этот простой пример на Presto: у предприятия электронной коммерции есть таблица измерений пользовательской информации (100 тыс. Строк со схемой <customer_id, name, gender, country, state, city, …>) и таблица фактов заказов пользователей (1 миллиард строк со схемой <order_id, date, customer_id, items, amount>).

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

Выполнение этого запроса состоит из 4 этапов:

  1. На этапе сканирования таблицы сканируются данные из обеих таблиц: одно полное сканирование заказов таблицы со столбцами: <date, customer_id, amount> И еще одно полное сканирование клиентов таблицы для извлечения всех совпавших <customers_id, city> с заданным предикатом<state = ‘California’ AND gender = ‘Female’>.
  2. На этапе соединения данные из обеих таблиц перемешиваются на основе customer_id.
  3. На этапе группировки снова происходит перемешивание данных на основе <orders.date, customers.city>, а затем совокупная сумма заказа.
  4. Фаза уменьшения собирает все результаты групп по и отображает окончательные результаты.

Фаза перетасовки данных в значительной степени способствует задержке запроса, включая разделение данных, сериализацию, сетевой ввод-вывод, десериализацию.

ETL жертвует свежестью данных за меньшее время запроса

…..

Подробнее читайте по этой новой ссылке!