SQL в потоке: выбор потоковой СУБД для аналитики Big Data

Что такое потоковая аналитика больших данных, какие бывают СУБД потоковой передачи, когда и зачем их использовать, а также что влияет на выбор этих инструментов хранения и аналитической обработки Big Data.

Что такое потоковые базы данных и как они работают

Мы уже упоминали, что аналитика данных в реальном времени может быть реализована 2-мя способами: с помощью потоковой передачи и OLAP-СУБД реального времени. Оба этих варианта работают с потоками – последовательностями событий/элементов данных, которые непрерывно во времени генерируются различными источниками, такими как IoT-датчики, события пользовательского поведения на сайтах и в мобильных приложениях, действия в соцсетях и пр. Потоковая обработка включает в себя непрерывный и постоянный сбор, вычисления и доставку данных в виде событий или сообщений.

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

Потоковые СУБД позволяют обрабатывать и анализировать данные в режиме реального времени с помощью SQL-запросов, применяя тот же язык структурированных запросов, как и для пакетной обработки. При этом можно создавать материализованные представления, которые представляют собой виртуальные таблицы с результатами часто выполняемых SQL-запросов. Благодаря предварительному вычислению результата и сохранению его в таких материализованных представлениях с помощью команды CREATE MATERIALIZED VIEW SQL-запросы выполняются быстрее и с меньшими затратами. Многие СУБД, как пакетные, так и потоковые, поддерживают материализованные представления с автоматическими обновлениями.

Таким образом, потоковая СУБД предназначена для обработки непрерывного потока данных в режиме реального времени и оптимизирована для обработки и хранения больших объемов данных, поступающих непрерывным и быстрым потоком. Потоковая СУБД использует тот же декларативный язык SQL и те же абстракции (таблицы, столбцы, строки, представления, индексы), что и традиционная база данных. Однако, в отличие от традиционных баз данных, в потоковых базах данные хранятся в таблицах, соответствующих структуре операций записи (вставки, обновления), а вся вычислительная работа выполняется при запросах чтения (выборки). Причем потоковые базы данных работают непрерывно, обрабатывая данные по мере их поступления и сохраняя их в постоянное хранилище в виде материализованного представления. Это позволяет проводить немедленный анализ и реагировать на события в режиме реального времени, позволяя оперативно реагировать на события согласно самой актуальной информации.

Потоковые базы данных обычно используют специализированные структуры данных и алгоритмы, оптимизированные для быстрой и эффективной обработки данных. Они также поддерживают сложную обработку событий (CEP), о которой мы писали здесь и здесь на примере Apache Flink, и другие инструменты аналитики больших данных в реальном времени. Одной из уникальных особенностей потоковых баз данных является возможность постепенного обновления материализованных представлений. Это позволяет постепенно агрегировать поступающие данные, чтобы использовать их в нижестоящих по конвейеру приложениях. Примерами потоковых баз можно назвать Rockset, Materialise, RisingWave и DeltaStream. Далее рассмотрим, какие критерии стоит учитывать при выборе потоковой СУБД.

Архитектура Данных

Код курса

ARMG

Ближайшая дата курса

22 апреля, 2024

Продолжительность

24 ак.часов

Стоимость обучения

72 000 руб.

7 главных критериев выбора потоковой СУБД

Хотя на практике можно выделить около пары десятков факторов, которые следует учитывать при выборе базы данных, с точки зрения потоковой СУБД особенно важными являются следующие:

Поддерживаемые источники данных, например, Apache Kafka, Pulsar, Redpanda, AWS Kinesis, Google Pub/Sub и/или базы данных (PostgreSQL, MySQL, Redis, Apache HBase и пр.);
масштабируемость, включая возможность обрабатывать большие объемы данных и одновременно работать с несколькими пользователями. Желательно, чтобы СУБД поддерживала горизонтальное масштабирование без прерывания обработки данных. Например, проект RisingWave с открытым исходным кодом динамически распределяет данные по каждому вычислительному узлу, используя согласованный алгоритм хеширования, чтобы каждый узел мог вычислить свою уникальную часть данных, а затем обменяться выводом с другими узлами кластера. Большинство SaaS-решений от различных облачных провайдеров поддерживают функцию автоматического масштабирования «из коробки».
интеграция с другими системами и инструментами, включая BI-платформы и прикладные системы. Следует убедиться, что потоковая СУБД поддерживает API для подключения к другим системам как для мониторинга системных метрик, например, Grafana и Prometheus, так и для визуализации бизнес-показателей (Apache Superset, Yandex Datalens и пр.).
производительность, включая скорость выполнения запросов и объем обрабатываемых данных в единицу времени. Ключевыми KPI для потоковых СУБД будут частота возникновения событий, пропускная способность, временная задержка обработки, надежность и количество топиков (для архитектур pub-sub). Низкоуровневый язык разработки потоковой СУБД вместо JVM-инструментов может повысить ее производительность.
Безопасность, включая различные политики управления пользователями и контроля доступа к данным, алгоритмы шифрования и криптографические протоколы;
простота эксплуатации, в т.ч. пользовательский интерфейс, документацию и ресурсы поддержки;
стоимость внедрения и использования, включая лицензионные сборы, расходы на обслуживание и любые дополнительные затраты на программно-аппаратное окружение. При этом важно убедиться, что выбранная СУБД соответствует бюджету и обеспечивает приемлемый уровень отдачи от инвестиций.

На практике все эти и другие критерии сравнения нескольких альтернативных СУБД, важные с точки зрения контекста ее окружения, будут обусловливать выбор решения, наиболее подходящего для задач из сценариев отдельно взятой компании и/или команды.