В этом мире большинство аналитических продуктов ориентированы либо на специальную аналитику, которая требует гибкости запросов без гарантированной задержки, либо на аналитику с низкой задержкой и ограниченными возможностями запросов. В этом блоге мы рассмотрим, как получить лучшее из обоих миров с помощью 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 этапов:
- На этапе сканирования таблицы сканируются данные из обеих таблиц: одно полное сканирование заказов таблицы со столбцами:
<date, customer_id, amount>
И еще одно полное сканирование клиентов таблицы для извлечения всех совпавших<customers_id, city>
с заданным предикатом<state = ‘California’ AND gender = ‘Female’>
. - На этапе соединения данные из обеих таблиц перемешиваются на основе customer_id.
- На этапе группировки снова происходит перемешивание данных на основе
<orders.date, customers.city>
, а затем совокупная сумма заказа. - Фаза уменьшения собирает все результаты групп по и отображает окончательные результаты.
Фаза перетасовки данных в значительной степени способствует задержке запроса, включая разделение данных, сериализацию, сетевой ввод-вывод, десериализацию.
ETL жертвует свежестью данных за меньшее время запроса
…..