Yuriy Gavrilov: posts tagged Streaming

Мир без Kafka: Почему Kafka не подходит для аналитики реального времени, что идет на смену)

Thu, 12 Feb 2026 13:50:00 +0300

Статья описывает переход от традиционных систем обмена сообщениями, таких как Apache Kafka, к специализированным решениям для потоковой аналитики, таким как Apache Fluss.

Основные тезисы:

Проблема Kafka: Kafka — это система хранения на основе *записей* (record-based), не имеющая нативной поддержки схем и аналитических возможностей. Это приводит к избыточному чтению данных и перегрузке сети при аналитических запросах, когда нужны только конкретные колонки, а не всё сообщение целиком.
Эволюция требований: Рынок перешел от простого перемещения данных (ingestion) к сложной аналитике реального времени и AI, что требует более эффективного хранения и доступа к данным.
Решение (Apache Fluss):
- Табличная структура:** Данные хранятся как таблицы (Log Tables для логов и PK Tables для изменяемых данных), что обеспечивает строгую типизацию.
- Колоночное хранение:** Использование формата Apache Arrow позволяет читать только нужные колонки (projection pushdown) и эффективнее сжимать данные, что снижает нагрузку на диск и сеть.
- Интеграция с Lakehouse:** Fluss нативно поддерживает многоуровневое хранение (горячие данные в Fluss, теплые/холодные в S3/Iceberg/Paimon) без лишнего копирования, обеспечивая прозрачный доступ к историческим и оперативным данным.
Вывод: Fluss в связке с Flink предлагает более дешевую, быструю и удобную архитектуру для современной аналитики реального времени, устраняя недостатки Kafka в этой области.

Ссылка на оригинал:
Why Kafka Falls Short for Real-Time Analytics (and What Comes Next

У Apache Kafka был замечательный период: она обеспечивала работу событийно-ориентированных архитектур более десяти лет. Но ландшафт изменился, обнажив явные ограничения Kafka для аналитики в реальном времени по мере того, как сценарии использования современной потоковой аналитики и принятия решений становятся всё более требовательными. Kafka все чаще пытаются заставить выполнять функции в архитектуре аналитики реального времени, для поддержки которых она никогда не проектировалась. Чтобы решить сегодняшние проблемы конвейеров потоковой передачи данных и аналитические требования, необходимы новые возможности. Пришло время для «новичка на районе».

Во время перехода от пакетной обработки к потоковой передаче данных в реальном времени значительное внимание и импульс получил проект с открытым исходным кодом, разработанный внутри LinkedIn: Apache Kafka. Цель состояла в том, чтобы упростить перемещение данных из точки А в точку Б масштабируемым и устойчивым способом, используя модель издатель/подписчик. Kafka позволила компаниям создавать ранние конвейеры потоковой передачи данных и открыть новый класс событийно-ориентированных сценариев использования. Постоянно растущая экосистема коннекторов и интеграций ускорила внедрение и утвердила Kafka в качестве предпочтительного слоя потокового хранения. Однако, по мере того как архитектуры аналитики реального времени эволюционировали за пределы простого приема данных (ingestion), ограничения Kafka для аналитических нагрузок становились всё более очевидными.

С архитектурной точки зрения Kafka — это не аналитический движок. Это устойчивая и масштабируемая система хранения на основе записей (record-based storage system) для свежих данных в реальном времени — часто называемая «горячим слоем». Следовательно, аналитические нагрузки должны выполняться за пределами кластера Kafka, постоянно перемещая данные между системами хранения и обработки, что увеличивает сетевой трафик и накладные операционные расходы. Кроме того, Kafka нативно не обеспечивает соблюдение схем для данных, публикуемых в топиках.

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

И последнее, но не менее важное (и, возможно, самый важный аспект): Kafka — это система хранения на основе записей. Это хорошо подходит для использования в качестве очереди сообщений, например, для приема данных в реальном времени или событийно-ориентированных архитектур, но имеет значительные ограничения при решении текущих и будущих задач проектов реального времени. Движки обработки, такие как Spark и Flink, должны потреблять все данные топика, даже если требуется только часть данных события (столбцы). Результатом является ненужный сетевой трафик, снижение производительности обработки и чрезмерные требования к хранилищу.

Компоненты потокового хранения на основе записей по-прежнему будут занимать свое место в архитектуре данных. Такие решения, как Kafka и Pulsar, хорошо подходят для случаев, требующих чтения полных записей. Архитектурные паттерны, основанные на микросервисах, могут использовать вышеуказанные решения для обмена данными, отделяя функции от транспортировки сообщений для повышения производительности, надежности и масштабируемости. Чтение полных записей также полезно для конвейеров приема данных (ingestion pipelines), в которых данные будут храниться в системах долгосрочного хранения, таких как объектное хранилище (Object Storage), для исторических и архивных целей. Узкие места и ограничения возникают, когда они используются для аналитических нагрузок, требующих возможностей, выходящих за рамки простого слоя транспорта данных.

Эволюция потоковых данных

Сегодняшний разговор движим единственным аспектом: Эволюция. Другими словами, новые потребности требуют новых подходов к управлению данными. Kafka удовлетворила первоначальные потребности в потоковой передаче данных. В этой первой волне в основном доминировали конвейеры приема данных в реальном времени и дискретная (SEP, Simple Event Processing) аналитика. По сути, способность перемещать данные из точки А в точку Б и, в некоторых случаях, выполнять простую подготовку и обработку данных между ними. Kafka, в сочетании со Spark Streaming или специальными коннекторами, справлялась с этими ранними сценариями использования.

Перенесемся вперед: вторая волна привнесла сложность в потоковый конвейер. Помимо дискретной подготовки данных, сценарии использования на этом этапе требовали расширенных аналитических функций, таких как агрегация, обогащение и сложная обработка событий (CEP). Микро-батчинг (micro-batching) оказался недостаточным. Требуется новый архитектурный подход, основанный на колоночном хранении с эффективным проталкиванием проекций (projection pushdown) и прозрачным многоуровневым хранением данных (data tiering), в сочетании с движками обработки с задержкой менее секунды. `Apache Fluss` и `Apache Flink` могут выполнить это обещание и вместе составляют будущее и третью волну по шкале зрелости.

Каждая техническая статья сегодня упоминает AI/ML. Эта эволюция «третьей волны» позволяет компаниям создавать AI-конвейеры реального времени, которые внедряют передовые аналитические методы (такие как Generative AI) в потоковые данные. Это увеличивает потребность в современных системах хранения данных в реальном времени с расширенными функциями, которые распределяют данные как по быстрым потоковым, так и по историческим слоям, обеспечивая интегрированный, унифицированный доступ к бизнес-данным.

Новичок на районе

`Apache Fluss` — это современная система хранения потоковых данных в реальном времени для аналитики. Она консолидирует многолетний опыт и уроки, извлеченные из предшественников, отвечая текущим и будущим потребностям организаций. Fluss родился в эпоху, когда для питания моделей машинного обучения требуется больше данных, Лейкхаусы (Lakehouses) являются частью корпоративной экосистемы, а облачная инфраструктура является предпочтительной стратегией для компаний.

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

Ниже приведены основные функции современной аналитики реального времени.

Поток как таблица (Stream as Table)

Fluss хранит данные как схематизированные таблицы. Этот подход подходит для большинства сценариев использования в реальном времени, включая те, которые опираются как на структурированные, так и на полуструктурированные данные. Структурируя потоковые данные, компании могут улучшить управление, повысить качество данных и гарантировать, что издатели и потребители используют общий язык. Fluss определяет два типа таблиц:

Log Tables (Лог-таблицы)** работают только на добавление (append-only), аналогично топикам Kafka. Такие сценарии использования, как мониторинг логов, кликстримы (clickstreams), показания датчиков, журналы транзакций и другие, являются хорошими примерами данных только для добавления. События неизменяемы и не должны изменяться или обновляться.
Primary Key (PK) Tables (Таблицы с первичным ключом)** — это изменяемые таблицы, определенные ключом. Записи сначала вставляются, а затем обновляются или удаляются с течением времени в соответствии с журналом изменений (changelog), который они представляют. Таблица PK хранит последние изменения всей таблицы, обеспечивая паттерн доступа «поиск записи» (record lookup). Сценарии использования журнала изменений, такие как балансы счетов, корзина покупок и управление запасами, могут извлечь выгоду из этого подхода. Kafka не может выполнять такое поведение, требуя внешних баз данных типа «ключ-значение» или NoSQL для отслеживания текущего статуса записи, что приводит к сложным и трудным в обслуживании решениям.

Вкратце, PK Tables обеспечивают уникальность записей на основе первичного ключа, операций `INSERT`, `UPDATE` и `DELETE`, а также предоставляют широкие возможности изменения записей. С другой стороны, Log Tables работают только на добавление; обновления записей не требуются.

Колоночное хранение (Columnar Storage)

То, как Fluss хранит данные на диске, возможно, является наиболее фундаментальным архитектурным сдвигом по сравнению с другими решениями. В отличие от Kafka, Fluss использует формат `Apache Arrow` для хранения данных в колоночном формате, что дает следующие преимущества:

Улучшенное использование хранилища**, так как хранение данных в колоночном формате требует меньше дискового пространства. Степень сжатия зависит от множества характеристик данных, но первоначальные тесты показывают многообещающее улучшение в 5 раз при использовании Apache Arrow в качестве базового формата хранения. Меньше хранилища = меньше затрат. Kafka предоставляет лишь несколько вариантов сжатия данных, которые не сравнимы с теми, что доступны в Apache Arrow «из коробки».
Эффективные запросы с использованием обрезки столбцов (column pruning).** В общем случае запрашивается или доступно менее половины атрибутов данного бизнес-события, т.е. только те имена столбцов, которые вы добавляете в ваше выражение `SELECT FROM`. Проталкивание проекции (projection pushdown) — это метод, который удаляет ненужные атрибуты (также известный как column pruning) при извлечении данных из системы хранения. Kafka работает по принципу «все или ничего» из-за своего формата хранения на основе записей.
И колоночное сжатие, и проталкивание проекции улучшат сетевой трафик — перемещение меньшего количества данных приведет к тому, что сетевые администраторы станут счастливее. С Kafka компании постоянно сталкиваются с перегрузкой сети и потенциально высокими расходами на исходящий трафик (egress costs).

Унификация с Lakehouse

Kafka была создана в эпоху Data Lake (Озер данных). С самого начала проектирования Fluss создавался для Lakehouse. Это создает большую разницу. Компании поняли, что Озера данных (или во многих случаях «Болота данных» — Data Swamps) трудно поддерживать в рабочем состоянии и окупать инвестиции в лицензии, оборудование и персонал для создания решений больших данных. К счастью, Лейкхаусы преодолевают эти проблемы. Лейкхаусы утверждают, что данные должны быть широко и легко доступны независимо от их возраста. Пакетные события и события реального времени перекрываются, и движки обработки должны иметь возможность прозрачно обращаться к обоим слоям.

Вот возможности тиринга данных (распределения по уровням) и унифицированного просмотра, которые может предоставить Fluss, в дополнение к слою горячих/свежих данных:

Теплый слой (Warm layer):** для данных возрастом от минут до часов, в основном хранящихся в решениях объектного хранения (Object Storage).
Холодный слой (Cold layer):** для данных возрастом от дней до лет. Решения Lakehouse, такие как `Apache Paimon` и `Iceberg`, являются предпочтительными платформами для этих исторических данных, питающих модели ML, ретроспективную аналитику и комплаенс.
Zero-copy data tiering (Тиринг данных без копирования):** старение данных из горячего слоя (таблицы Fluss) в теплые/холодные слои (Object Storage и Lakehouse). Это означает, что доступна единственная копия единицы данных, либо в слое реального времени, либо в историческом слое. Fluss управляет переключением между слоями, облегчая запросы и доступ. Подход Kafka опирается на дублирование данных с помощью задания потребителя/издателя, что приводит к увеличению затрат на хранение и необходимости конвертировать топики Kafka в табличный формат Lakehouse.

Светлое будущее впереди

Аналитика данных в реальном времени становится краеугольным камнем современных компаний. Цифровые бизнес-модели должны обеспечивать лучший пользовательский опыт и своевременные ответы на взаимодействия с клиентами, что заставляет компании создавать системы для использования и управления данными в реальном времени, создавая увлекательный и впечатляющий («wow») опыт. Действовать сейчас — это не просто вопрос технической осуществимости; для большинства предприятий это становится уникальным преимуществом для выживания в высококонкурентной глобальной рыночной среде.

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

В то время как Fluss служит слоем хранения в реальном времени для аналитики, Лейкхаусу предоставляется управление, простота и масштабируемость, которые защищают современные архитектуры в будущем.

С операционной стороны он предлагает значительные преимущества за счет снижения сложности управления, хранения и обслуживания как данных реального времени, так и пакетных данных. Эта эффективность трансформируется в прямую экономию средств, достигаемую в первую очередь за счет оптимизированного формата таблиц Fluss, двухуровневой системы хранения, основанной на температуре данных, и, наконец, минимизации общего использования ЦП конвейера с помощью проталкивания предикатов (predicate pushdown) и обрезки столбцов. В совокупности эти архитектурные элементы снижают накладные операционные расходы, связанные с обслуживанием платформы, ускоряют внедрение новых сценариев использования и облегчают бесшовную интеграцию с существующей ИТ-инфраструктурой предприятия.

Создаем Streaming Lakehouse за час: руководство по RisingWave, Lakekeeper и Trino

Sat, 06 Sep 2025 23:03:00 +0300

Вы когда-нибудь мечтали о платформе, где данные, отправленные через простой API-вызов, через секунды становятся доступны для аналитических запросов в вашем озере данных? Мечты сбываются. Эта статья — подробное, основанное на реальном опыте руководство, которое покажет, как построить современный Streaming Lakehouse с нуля.

Доки, которые пригодились:

https://github.com/risingwavelabs/risingwave/blob/main/docker/docker-compose.yml
https://github.com/lakekeeper/lakekeeper/blob/main/examples/minimal/docker-compose.yaml
https://docs.risingwave.com/iceberg/deliver-to-iceberg#rest-catalog

Наши главные герои:

RisingWave: Потоковая база данных, “сердце” нашего пайплайна. Она будет принимать, преобразовывать и материализовывать данные на лету.

Lakekeeper: Современный REST-каталог для Apache Iceberg. Наш “библиотекарь”, который знает все о структуре данных в озере.

Trino: Мощный движок для федеративных запросов. Наше “окно” в озеро данных для выполнения ad-hoc аналитики.

Мы пройдем весь путь: от сравнения технологий и настройки окружения до отправки данных и любования результатами на дашбордах Grafana. И самое главное — мы поделимся всеми “граблями”, на которые наступили, чтобы вы могли их обойти.

Глава 1: Почему RisingWave? Взгляд на альтернативы

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

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

Давайте сравним его с популярными альтернативами.

Сравнительная таблица

Критерий	RisingWave	Связка Debezium + Flink	Apache SeaTunnel
Архитектура	Единая система: хранение состояния (state) и вычисления в одном продукте.	Компонентная: Debezium (CDC), Kafka (очередь), Flink (обработка), отдельное хранилище состояния.	Инструмент для перемещения данных (data mover) с коннекторами.
Основная задача	Создание и поддержка инкрементально обновляемых материализованных представлений.	Гибкая, низкоуровневая обработка потоков общего назначения.	Пакетная и потоковая синхронизация данных между разнородными источниками и приемниками.
Простота использования	Очень высокая. Знание SQL — это 90% успеха. Скрывает сложность управления состоянием.	Низкая. Требует экспертизы в каждом компоненте, написания кода на Java/Scala, управления состоянием.	Средняя. Конфигурация через файлы, но требует понимания особенностей каждого коннектора.
Обработка данных	SQL-ориентированная. `CREATE MATERIALIZED VIEW ... AS SELECT ...`.	Программная. DataStream API, Table API/SQL. Позволяет писать сложную бизнес-логику.	Декларативная. Определяет `source`, `transform`, `sink`. Менее гибкая для сложных трансформаций.
Поддержка SQL	Первоклассная. Совместимость с PostgreSQL на уровне синтаксиса и протокола.	Хорошая (Flink SQL), но не является основным интерфейсом.	Ограниченная. Используется для простых трансформаций, а не для определения логики потока.
Управление состоянием	Встроенное и автоматическое. Использует облачное хранилище (S3) как персистентный слой.	Ручное. Требуется настраивать и управлять чекпоинтами и состоянием (например, RocksDB).	Зависит от движка (Flink/Spark). Не является основной функцией самого SeaTunnel.

Выводы:

Связка Debezium + Flink — это невероятно мощный, но сложный “конструктор”. Он идеален для компаний с большими командами инженеров данных, которым нужна максимальная гибкость для создания кастомной логики.
Apache SeaTunnel — это отличный “швейцарский нож” для перемещения данных. Его сила — в огромном количестве коннекторов. Он идеален для задач ETL/ELT, когда нужно перелить данные из точки А в точку Б с минимальными трансформациями.
RisingWave занимает золотую середину для аналитических задач в реальном времени. Он предлагает простоту и элегантность SQL, скрывая под капотом всю сложность потоковой обработки. Если ваша цель — быстро получить свежие аналитические витрины из потоков данных, RisingWave — ваш выбор.

Глава 2: “Кексы” — фишки RisingWave, которые упрощают жизнь 🍰

Что делает RisingWave таким привлекательным на практике?

PostgreSQL-совместимость: Вы можете подключиться к RisingWave любым клиентом, который “говорит” на протоколе Postgres (например, DBeaver, psql). Синтаксис SQL для создания представлений и запросов вам уже знаком.
Все-в-одном для стриминга: RisingWave объединяет в себе прием данных (коннекторы), их обработку (инкрементальные вычисления) и хранение состояния. Вам не нужно разворачивать и связывать вместе Kafka, Zookeeper, Flink и RocksDB.
Нативные Sink’и и Source’ы: В нашем примере мы использовали встроенный `webhook` коннектор — не нужно писать отдельный сервис для приема данных! RisingWave нативно умеет работать с Kafka/Redpanda, Kinesis, Pulsar, а также писать данные напрямую в Iceberg, Delta Lake и другие системы.
Инкрементальные вычисления “под капотом”: Когда вы создаете материализованное представление, RisingWave строит план потоковой обработки. При поступлении новых данных он не пересчитывает все заново, а инкрементально обновляет результат. Это обеспечивает сверхнизкую задержку.

Глава 3: Практика: Строим наш Streaming Lakehouse шаг за шагом

Теперь перейдем к самому интересному — воссозданию нашего успешного проекта.

Этап 1: Архитектура и подготовка окружения (00:00 – 00:15)

Наша архитектура выглядит так:
`Webhook` → `RisingWave (Source → MView → Sink)` → `Lakekeeper (Catalog) + MinIO (Storage)` ← `Trino (Query)`

Мы используем два `docker-compose` файла:

Для Lakekeeper и его экосистемы (Postgres, MinIO, Trino): lakekeeper/examples/minimal https://github.com/lakekeeper/lakekeeper/tree/main/examples/minimal .
Для RisingWave и его окружения Postgres для метаданных, MinIO для состояния, Grafana): risingwave/docker/docker-compose.yml https://github.com/risingwavelabs/risingwave/blob/main/docker/docker-compose.yml .

Ключевое действие: Мы запускаем оба стека, но для RisingWave вносим изменения, чтобы он мог взаимодействовать с Lakekeeper и Trino. Мы объединяем их в одну сеть, добавив в `docker-compose.yml` от RisingWave следующие строки:

# risingwave/docker/docker-compose.yml

services:
  risingwave-standalone:
    # ...
    # Открываем порт для вебхука, по умолчанию он не открыт наружу
           .....
        --webhook-listen-addr 0.0.0.0:4567 \ 
           .....
    ports:
      - "4566:4566". 
      # ... другие порты
      - "4567:4567"   # <--- Это важно для рабочего webhook 
    networks:
      - trino_network
# ... и для других сервисов, которые должны общаться с внешним стеком ...

networks:
  trino_network:
    name: minimal_iceberg_net # Имя сети из docker-compose Lakekeeper
    external: true

Важный момент: По умолчанию RisingWave не выставляет порт `4567` для вебхуков наружу. Мы добавили его в секцию `ports`, чтобы иметь возможность отправлять `curl` запросы с хост-машины.

Этап 2: Настройка каталогов (00:15 – 00:25)

“Озеро” без каталога — это просто “болото”. Lakekeeper будет нашим каталогом, а Trino — первым, кто научится им пользоваться.

Создаем динамический каталог в Trino:

CREATE CATALOG risingwave USING iceberg
    WITH (
        "iceberg.catalog.type" = 'rest',
        "iceberg.rest-catalog.uri" = 'http://lakekeeper:8181/catalog',
        "iceberg.rest-catalog.warehouse" = 'demo',
        "s3.region"= 'dummy',
        "s3.path-style-access" = 'true',
        "s3.endpoint" = 'http://minio:9000',
        "fs.native-s3.enabled" = 'true'
    );

Создаем “пустую” таблицу в Trino: Этот шаг создает метаданные в Lakekeeper. RisingWave будет находить эту таблицу и наполнять ее данными.

CREATE TABLE risingwave.trino_namespace.product_view_events (
       event_id varchar,
       user_id varchar,
       event_name varchar,
       product_id varchar,
       category varchar,
       price double,
       event_timestamp timestamp(6) with time zone,
       raw_data varchar
    );

Этап 3: Магия RisingWave (00:25 – 00:45) 🚀

Подключаемся к RisingWave через DBeaver (используя порт `4566` и стандартный драйвер PostgreSQL) и начинаем творить магию.

Создаем источник-вебхук:

CREATE TABLE wbhtable1 (
      data JSONB
    ) WITH (
      connector = 'webhook'
    ) VALIDATE AS secure_compare(
      headers->>'authorization',
      'TEST_WEBHOOK'
    );

Эта команда создает эндпоинт, который принимает JSON и кладет его в таблицу `wbhtable1`. `VALIDATE AS` обеспечивает простую, но эффективную аутентификацию.

Создаем материализованное представление:

CREATE MATERIALIZED VIEW product_view_events AS
    SELECT
      (data->>'event_id')::VARCHAR AS event_id,
      (data->>'user_id')::VARCHAR AS user_id,
      (data->>'event_name')::VARCHAR AS event_name,
      (data->'properties'->>'product_id')::VARCHAR AS product_id,
      (data->'properties'->>'category')::VARCHAR AS category,
      (data->'properties'->>'price')::DOUBLE PRECISION AS price,
      (data->>'timestamp')::TIMESTAMP WITH TIME ZONE AS event_timestamp,
      data::VARCHAR AS raw_data
    FROM wbhtable1;

Это ядро нашей логики. Мы на лету парсим входящий `JSONB`, приводим типы и создаем структурированное представление `product_view_events`, которое обновляется автоматически.

Создаем синк (Sink) в Iceberg:

CREATE SINK rest_sink FROM product_view_events
    WITH (
        connector = 'iceberg',
        type = 'upsert',
        primary_key = 'event_id',
        catalog.type = 'rest',
        catalog.uri = 'http://lakekeeper:8181/catalog',
        warehouse.path = 'demo',
        database.name = 'trino_namespace',
        table.name = 'product_view_events',
        s3.endpoint = 'http://minio:9000',
        s3.path.style.access = 'true',
        s3.access.key = 'minio-root-user',
        s3.secret.key = 'minio-root-password',
        s3.region = 'dummy'
    );

“Грабли”, которые мы собрали: На пути к этому финальному запросу мы столкнулись с несколькими ошибками, которые стоили нам времени. Вот они, чтобы вы не повторяли наших ошибок:

`catalog.uri`: Должен указывать на полный путь к REST API каталогу, в случае Lakekeeper это `http://lakekeeper:8181/catalog`.
`warehouse.path`: Должен содержать логическое имя хранилища (`demo`), а не его физический путь в S3.
`s3.region`: Критически важный параметр! S3-клиент внутри RisingWave требует его обязательного указания, даже для MinIO. Хотя само значение (`us-east-1` или любое другое) для MinIO не принципиально, его отсутствие приводит к ошибке `region is missing` и сбою записи данных.

Этап 4: Запуск и проверка (00:45 – 01:00)

Время накормить нашу систему данными! Запускаем в терминале скрипт для генерации и отправки 100 событий, а можно и тысячу. Этот скрипт полностью рабочий и готов к копированию:

seq 1 100 | xargs -I {} -P 10 bash -c '
  EVENT_ID=$(uuidgen)
  USER_ID="usr_$(uuidgen | head -c 8)"
  PRODUCT_ID="prod_$(uuidgen | head -c 8)"
  TIMESTAMP=$(date -u +"%Y-%m-%dT%H:%M:%SZ")

  curl -s -o /dev/null -X POST \
    http://localhost:4567/webhook/dev/public/wbhtable1 \
    -H "Content-Type: application/json" \
    -H "Authorization: TEST_WEBHOOK" \
    -d "{
          \"event_id\": \"$EVENT_ID\",
          \"user_id\": \"$USER_ID\",
          \"event_name\": \"product_viewed\",
          \"properties\": {
            \"product_id\": \"$PRODUCT_ID\",
            \"category\": \"electronics\",
            \"price\": 9199.99
          },
          \"timestamp\": \"$TIMESTAMP\"
        }"
'

И вот он, момент истины. Идем в DBeaver, открываем подключение к Trino и выполняем:

select * from risingwave.trino_namespace.product_view_events;

Результат перед вами:

Данные, только что сгенерированные и отправленные по HTTP, уже лежат в озере данных в формате Parquet и доступны для анализа. Ура!

Глава 4: Наблюдаемость: Смотрим на систему под нагрузкой

RisingWave поставляется с готовыми дашбордами для Grafana. Взглянем на них после нашей нагрузки.

Можно листать стрелками -->>

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

Задержка барьеров (Barrier Latency): Это ключевой показатель здоровья потоковой системы. Он показывает время, необходимое для создания контрольной точки (чекпоинта). Значения в десятки миллисекунд говорят о том, что система абсолютно здорова и справляется с нагрузкой без задержек.

Ресурсы (CPU/Memory): Графики показывают стабильное и предсказуемое потребление ресурсов.

Эти метрики доказывают, что система не просто работает, а работает стабильно и эффективно.

Заключение

Мы сделали это! Меньше чем за час мы развернули и настроили полноценный Streaming Lakehouse. Мы доказали, что современные инструменты, такие как RisingWave, могут кардинально упростить создание сложных систем обработки данных в реальном времени.

Путь от ошибки `Table does not exist` до работающего пайплайна был непростым, но каждая решенная проблема углубляла мое понимание системы. Теперь есть не просто набор инструкций, а проверенный в бою рецепт, учитывающий все “подводные камни”.

Путь к аналитике в реальном времени открыт. Хорошего стриминга и бурного потока с домом у озера, главное что бы избушку не смыло :)

UPD: Проверил еще пару штук

Создаем сурс из Кафки

CREATE SOURCE kafka_src (
  action VARCHAR
) WITH (
  connector = 'kafka',
  topic = 'query_complete',
  properties.bootstrap.server = 'broker1:29092'
);

создаем синк в другую кафку

CREATE SINK kafka_sink from kafka_src WITH (
  connector = 'kafka',
  topic = 'query_complete',
  properties.bootstrap.server = 'broker2:29092'
) FORMAT PLAIN ENCODE JSON

Еще вебхук

CREATE TABLE wbhtable2 (
      data JSONB
    ) WITH (
      connector = 'webhook'
    ) VALIDATE AS secure_compare(
      headers->>'authorization',
      'TEST_WEBHOOK'
    );

Делаем материализацию

CREATE MATERIALIZED VIEW events AS
    SELECT
      (data->>'action')::VARCHAR AS action
    FROM wbhtable2;

делаем синк из материализации в кафку

CREATE SINK kafka_sink2 FROM events WITH (
  connector = 'kafka',
  topic = 'query_complete',
  properties.bootstrap.server = 'broker2:29092'
) FORMAT PLAIN ENCODE JSON (force_append_only='true');

Без материализации сообщения прилетают так: {“data”:“{\”action\“: \”55555\“}”}
А с материализацией: {“action”:“99999”}

Пример запроса

curl -s -o /dev/null -X POST \
    http://localhost:4567/webhook/dev/public/wbhtable2 \
    -H "Content-Type: application/json" \
    -H "Authorization: TEST_WEBHOOK" \
    -d "{\"action\": \"11111\"}"

Еще про s3 подобные архитектуры: https://gavrilov.info/all/bitva-novyh-arhitektur-sravnivaem-arc-gigapi-i-ducklake/

Ошибки в версии 2.4 – какая то пакость была, но поставил 2.6.1 и все заработало

-- 0. устанавливаем последнюю версию risingwave ( 2.6.1 )


-- 1 Создаем вебхук 

CREATE TABLE wbhtable5 (
      data JSONB
    ) WITH (
      connector = 'webhook'
    ) VALIDATE AS secure_compare(
      headers->>'authorization',
      'TEST_WEBHOOK'
    );

-- 2 Создаем материализацию 

CREATE MATERIALIZED VIEW product_view_events5 AS
    SELECT
      (data->>'event_id')::VARCHAR AS event_id,
      (data->>'user_id')::VARCHAR AS user_id,
      (data->>'event_name')::VARCHAR AS event_name,
      (data->'properties'->>'product_id')::VARCHAR AS product_id,
      (data->'properties'->>'category')::VARCHAR AS category,
      (data->'properties'->>'price')::DOUBLE PRECISION AS price,
      (data->>'timestamp')::TIMESTAMP WITH TIME ZONE AS event_timestamp,
      data::VARCHAR AS raw_data
    FROM wbhtable5;

-- 3 создаем подключение к iceberg 

CREATE CONNECTION my_iceberg_conn5 WITH (
    type = 'iceberg',
    warehouse.path = 'risi',  -- s3://my-bucket/warehouse/
   -- database.name = 'risi_space',  оказалось не нужна 
    s3.region = 'dummy',
    s3.access.key = 'ЧЧЧ', -- Ваши ключи
    s3.secret.key = 'ЧЧЧ',   -- Ваши ключи
    catalog.type = 'rest',
    s3.endpoint = 'https://gateway.storjshare.io',
    s3.path.style.access = 'true',
    
    -- ИСПОЛЬЗУЕМ ИМЯ СЕРВИСА И ЕГО ВНУТРЕННИЙ ПОРТ!
    catalog.uri = 'http://lakekeeper:8181/catalog'
)

-- 4 Устанавливаем его по умолчанию 

SET iceberg_engine_connection = 'public.my_iceberg_conn5';


-- Создаем таблицу ( обязательно с ключами )

CREATE TABLE public.my_iceberg_table5 (
       event_id VARCHAR PRIMARY KEY,
       user_id varchar,
       event_name varchar,
       product_id varchar,
       category varchar,
       price double,
       event_timestamp Timestamptz,
       raw_data varchar
) ENGINE = iceberg;

 
-- 5 создаем синк 

CREATE SINK to_sales_events5 INTO my_iceberg_table5 AS
SELECT * FROM product_view_events5;

--- Тут можно curl запустить 

seq 1 10 | xargs -I {} -P 10 bash -c '
  EVENT_ID=$(uuidgen)
  USER_ID="usr_$(uuidgen | head -c 8)"
  PRODUCT_ID="prod_$(uuidgen | head -c 8)"
  TIMESTAMP=$(date -u +"%Y-%m-%dT%H:%M:%SZ")

  curl -s -o /dev/null -X POST \
    http://localhost:4567/webhook/dev/public/wbhtable5 \
    -H "Content-Type: application/json" \
    -H "Authorization: TEST_WEBHOOK" \
    -d "{
          \"event_id\": \"$EVENT_ID\",
          \"user_id\": \"$USER_ID\",
          \"event_name\": \"product_viewed\",
          \"properties\": {
            \"product_id\": \"$PRODUCT_ID\",
            \"category\": \"electronics\",
            \"price\": 9199.99
          },
          \"timestamp\": \"$TIMESTAMP\"
        }"
'


-- 6 проверяем 

SELECT * FROM product_view_events5;

-- 7 проверяем ( появляются не сразу ) 

select * from my_iceberg_table5

И в keeper она есть

И на S3