Real-time Analytics

LinkedIn показывает 'Кто просматривал профиль' 300 миллионам пользователей. Если бы каждый запрос сканировал 2 трлн событий просмотров - страница грузилась бы часы. Apache Pinot отвечает за 100 мс: не потому что данных меньше, а потому что архитектура спроектирована под этот конкретный запрос.

• **Cloudflare** обрабатывает 6 млн HTTP-запросов в секунду в ClickHouse для real-time security analytics: аномалии в трафике выявляются за секунды вместо часов в традиционных SIEM
• **Netflix** использует Apache Druid для streaming analytics: метрики качества видео (buffering ratio, startup time) агрегируются по минутам и влияют на CDN routing в реальном времени
• **Walmart** запустил Apache Pinot для real-time inventory analytics: наличие товаров на полках обновляется в секунды, что позволяет избегать overselling при пиковой нагрузке

Apache Druid

Apache Druid появился в Metamarkets в 2011 году с одной целью: отвечать на аналитические запросы за миллисекунды на данных, которые только что появились в Kafka. Стандартные OLAP-хранилища требовали ждать batch-загрузки - часы или дни. Druid решил это через lambda-подобную архитектуру: streaming ingestion в мutable realtime сегменты, которые затем конвертируются в immutable historical сегменты. Netflix, Airbnb и LinkedIn используют Druid для dashboards реального времени на миллиардах событий.

Архитектура Druid: **Realtime nodes** - ingestion из Kafka/Kinesis в памяти, индексирование в реальном времени. **Historical nodes** - иммутабельные сегменты на диске, оптимизированы для сканирования. **Broker** - маршрутизирует запросы к нужным нодам, мержит ответы. **Coordinator** - управляет балансировкой и retention. Данные хранятся в колоночном формате с bitmap индексами - это позволяет сканировать миллиарды строк за секунды через SIMD-инструкции процессора.

ClickHouse

ClickHouse создали в Яндексе в 2009 году для Яндекс.Метрики - системы веб-аналитики, обрабатывающей триллионы событий. В open source вышел в 2016 году и за несколько лет стал стандартом для аналитических задач: быстрее Druid на batch-запросах, проще в операционном управлении, поддерживает настоящий SQL без ограничений. Cloudflare обрабатывает в ClickHouse 6 миллионов HTTP-запросов в секунду для real-time security analytics.

Ключевые особенности ClickHouse: **MergeTree engine** - основной движок; данные хранятся отсортированными по ORDER BY ключу, что позволяет читать нужные диапазоны без полного сканирования. **Materialized Views** - автоматически обновляемые агрегаты при вставке: INSERT в основную таблицу -> Materialized View считает агрегаты. **ReplicatedMergeTree** - автоматическая репликация через ZooKeeper/ClickHouse Keeper. **Vertical scaling** - ClickHouse эффективнее работает на больших одиночных серверах (больше CPU/RAM) чем в распределённом режиме.

Apache Pinot

Apache Pinot создан в LinkedIn в 2013 году для одного конкретного кейса: 'Кто просматривал мой профиль за последние 24 часа' - запрос, который делают 200 миллионов пользователей одновременно, каждый видит свои данные. Это user-facing analytics - аналитика прямо в продукте, а не в внутреннем дашборде. Latency требования: P99 < 100 мс при тысячах QPS. Ни ClickHouse, ни Druid не оптимизированы под такой сценарий с этим масштабом.

Что отличает Pinot от Druid/ClickHouse: **StarTree index** - специализированный индекс для запросов с многими фильтрами одновременно (userId + campaignId + dateRange). **Upsert support** - обновление записей в real-time стриме (Druid append-only по умолчанию). **Multi-tenancy** - изоляция между таблицами разных клиентов на уровне ресурсов. **Tiered storage** - горячие данные в памяти/SSD, холодные в S3. LinkedIn, Uber и Walmart используют Pinot для user-facing product analytics.

Materialized Views

Materialized View - это предвычисленный результат запроса, хранящийся как таблица и автоматически обновляемый при изменении исходных данных. Парадокс: ClickHouse без Materialized View на запросе 'сумма продаж за год по 100 млн строкам' тратит секунды. С правильно настроенным Materialized View на агрегаты по минутам - тот же запрос выполняется за миллисекунды, потому что агрегирует уже 525 600 строк вместо 100 млн.

Типы обновления Materialized Views: **Incremental** (ClickHouse AggregatingMergeTree) - новые данные агрегируются в момент INSERT, результат мержится с существующим агрегатом. **Streaming** (Kafka Streams, Flink) - агрегат пересчитывается непрерывно на стриме событий. **Scheduled refresh** (классические СУБД) - пересчёт по расписанию, данные устаревают. **On-demand** - пересчёт по запросу (самый простой, самый медленный). Для real-time систем актуальны первые два.

Ключевые идеи

• **Druid** - lambda-архитектура с realtime + historical нодами; оптимален для временных рядов с rollup на ingestion; bitmap индексы дают субсекундное сканирование миллиардов строк
• **ClickHouse** - MergeTree с sparse index и incremental Materialized Views; проще в операционном управлении чем Druid; лидер для инженерной аналитики и batch-запросов
• **Pinot со StarTree** - единственный вариант для user-facing analytics при тысячах QPS и P99 < 100 мс; multi-tenancy и upsert отличают его от Druid/ClickHouse

Связанные темы

Real-time OLAP стоит в конце pipeline стриминговой обработки:

• Stream Processing Patterns — Результаты windowing и deduplication из Flink/Spark Streaming приземляются в OLAP-движки для интерактивных запросов
• Брокеры сообщений — Kafka - стандартный источник для всех трёх OLAP движков: Druid, ClickHouse и Pinot читают из Kafka топиков

Вопросы для размышления

• ClickHouse лучше Druid для batch-запросов, но хуже для high-concurrency user-facing queries. При каком QPS и latency требовании стоит мигрировать с ClickHouse на Pinot?
• Materialized View ускоряет чтение но усложняет запись: каждый INSERT пересчитывает агрегаты. При каком соотношении read/write нагрузки Materialized View перестаёт окупаться?
• Druid использует rollup на ingestion: несколько событий агрегируются в одну строку. Это снижает storage, но теряет сырые данные. Как решить, какую granularity хранить, если бизнес-требования к детализации меняются?

Связанные уроки

• stat-31-eda