Yuriy Gavrilov: posts tagged Data Engineer

Архитектура Client Spooling: Как быстро выгружать гигантские датасеты в Trino и Apache DataFusion

Sun, 12 Apr 2026 19:11:05 +0300

Работа с Big Data часто упирается в классическое “узкое горлышко”: кластер может обработать терабайты данных за секунды, но передача результатов (Result Set) обратно на сторону клиента (например, в Jupyter или скрипт) занимает часы. На дворе апрель 2026 года, и современные аналитические движки предлагают эффективные методы обхода этой проблемы — концепцию Spooling.

Немного душноты:

Архитектура Client Spooling в Trino создавалась с параноидальным акцентом на безопасность, в S3 выкидываются куски сырых, возможно, чувствительных данных.

Когда Trino решает сбросить данные в объектное хранилище, он всегда шифрует их на лету.
Для этого используется механизм S3 SSE-C (Server-Side Encryption with Customer-provided keys). Trino генерирует уникальный случайный AES-ключ для каждого запроса, отправляет его в MinIO вместе с данными, а клиенту (вашему Jupyter) отдает ссылку + этот же ключ для расшифровки.
Если мы используем локальный MinIO по адресу http://minio:9000 (без SSL/TLS), сервер MinIO видит, что ему пытаются передать секретный пароль (SSE-C ключ) по открытому незащищенному HTTP-каналу.
MinIO (как и настоящий AWS S3) строго запрещает это по спецификации. Он возвращает HTTP 400 Bad Request с ошибкой: “Requests specifying Server Side Encryption... must be made over a secure connection”. Поэтому тестировать лучше на реальном s3. И еще

Мгновенное удаление (Сборка мусора)

Главное правило Client Spooling: Trino удаляет файлы сразу же, как только они были прочитаны клиентом.
Как только ваш Python-скрипт или Jupyter получает ссылку на файл, скачивает его и отправляет координатору Trino HTTP-сигнал (ACK), что кусок получен, координатор дает команду немедленно удалить этот объект из S3.
Если запрос отменен или упал с ошибкой, Trino тоже моментально зачищает за собой fs.location. Вы просто не успеете их там увидеть.

Данных слишком мало (Thresholds)

Писать 10 строк в S3, генерировать для них Pre-signed URLs и отдавать клиенту — это дольше, чем просто плюнуть эти 10 строк текстом через координатор. Trino использует эвристику: если Result Set маленький, он отдается “инлайн” (внутри JSON-ответа самого координатора), и S3 не задействуется.

В этой статье мы разберем, как передавать результаты запросов через промежуточное S3-хранилище, на примере движков Trino и Apache DataFusion.

Физика проблемы и математика Spooling

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

Если D — это объем результирующей выборки, а B c — пропускная способность сети координатора, то время выгрузки данных клиенту без спулинга равно:

T classic = B / Dc

В режиме Spooling координатор не гоняет данные через себя. Воркеры напрямую, параллельно пишут куски результата в дешевое объектное хранилище (S3/MinIO). Клиент получает лишь ссылки на эти файлы и скачивает их напрямую. Если у нас N файлов в S3, доступных для многопоточного скачивания с пропускной способностью клиента B client: T spooling ≈ min(N×B s3,B client)D

Это позволяет ускорить выгрузку в десятки раз, так как $B_{client}$ и распределенный $B_{s3}$ обычно значительно больше ограничений одного координатора.

Подготовка минимальной инфраструктуры

Для демонстрации двух подходов мы убрали из нашего кластера все тяжелые клиентские среды (Jupyter, Spark) и оставили только “голое” ядро: хранилище S3, REST-каталог и SQL-движок.

минимальный

docker-compose.yml

version: '3.8'

services:
  minio:
    image: minio/minio:latest
    ports:
      - "19000:9000"
      - "19001:9001"
    environment:
      MINIO_ROOT_USER: "minio-root-user"
      MINIO_ROOT_PASSWORD: "minio-root-password"
    command: server /data --console-address ":9001"

  minio-setup:
    image: minio/mc:latest
    depends_on:
      - minio
    entrypoint: >
      /bin/sh -c "
      sleep 5;
      mc alias set myminio http://minio:9000 minio-root-user minio-root-password;
      mc mb myminio/warehouse || true;
      "

  lakekeeper:
    image: dalongrong/lakekeeper:latest
    ports:
      - "8181:8181"
    environment:
      - S3_ENDPOINT=http://minio:9000
      - S3_REGION=us-east-1
      - S3_ACCESS_KEY_ID=minio-root-user
      - S3_SECRET_ACCESS_KEY=minio-root-password
    depends_on:
      - minio-setup

  trino:
    image: trinodb/trino:latest
    ports:
      - "8080:8080"

Шаг 1. Настройка каталога и генерация данных (Trino)

Сначала мы генерируем данные в Trino. Запрос

CREATE CATALOG

использует динамическое подключение к Lakekeeper REST API. Скрипт записывает файлы в формате Parquet в MinIO:

config.properties

protocol.spooling.enabled=true
# 256-битный ключ в формате base64. Вы можете сгенерировать свой с помощью команды `openssl rand -base64 32`
protocol.spooling.shared-secret-key=jxTKysfCBuMZtFqUf8UJDQ1w9ez8rynEJsJqgJf66u0=

catalog.management=dynamic

spooling-manager.properties

spooling-manager.name=filesystem
# Включаем чтение/запись в S3 для Spooling
fs.s3.enabled=true
# Путь внутри MinIO (указываем через s3://)
fs.location=s3://warehouse/client-spooling/

# Системные настройки S3 (MinIO)
s3.endpoint=http://minio:9000
s3.region=us-east-1
s3.aws-access-key=minio-root-user
s3.aws-secret-key=minio-root-password
s3.path-style-access=true

-- 1. Подключение каталога Iceberg

CREATE CATALOG test_warehouse USING iceberg
WITH (
    "iceberg.catalog.type" = 'rest',
    "iceberg.rest-catalog.uri" = 'http://lakekeeper:8181/catalog/',
    "iceberg.rest-catalog.warehouse" = '00000000-0000-0000-0000-000000000000/test_warehouse',
    "iceberg.rest-catalog.security" = 'OAUTH2',
    "iceberg.rest-catalog.nested-namespace-enabled" = 'true',
    "iceberg.rest-catalog.vended-credentials-enabled" = 'true',
    "fs.native-s3.enabled" = 'true',
    "s3.region" = 'us-east-1',
    "s3.path-style-access" = 'true',
    "s3.endpoint" = 'http://minio:9000'
);

-- 2. Создание структуры

CREATE SCHEMA test_warehouse.test_schema;

CREATE TABLE test_warehouse.test_schema.my_table (
    id BIGINT,
    data VARCHAR
) WITH (format = 'PARQUET');

-- 3. Запись данных

INSERT INTO test_warehouse.test_schema.my_table VALUES (1, 'hello'), (2, 'world');

Если написать Select – должно быть как-то так

Аналог Spooling в Apache DataFusion (Через экспорт)

Trino поддерживает протокол *Client Spooling* “из коробки” — когда Python-клиент запрашивает огромный `SELECT`, Trino сам незаметно пишет куски в S3 и отдает клиенту готовые ссылки.

В Apache DataFusion (который часто работает как локальный движок `datafusion-cli` или встраиваемая библиотка поверх S3) применяется более прозрачный паттерн делегирования (Explicit Spooling). Мы вручную инструктируем движок сохранить результаты агрегации в распределенное хранилище, чтобы позже забрать их в удобном формате — например, упаковав их в `JSON` и сжав алгоритмом `ZSTD`.

1. Подключение к S3 и маппинг исходной таблицы

Запускаем `datafusion-cli`, передав доступы как переменные среды (для предотвращения ошибок парсинга опций):

AWS_ACCESS_KEY_ID="minio-root-user" \
AWS_SECRET_ACCESS_KEY="minio-root-password" \
AWS_ENDPOINT="http://localhost:19000" \
AWS_REGION="us-east-1" \
AWS_ALLOW_HTTP="true" \
datafusion-cli

Внутри консоли подключаем директорию с Parquet-файлами, сгенерированными Trino:

CREATE EXTERNAL TABLE my_parquet_data 
STORED AS PARQUET 
LOCATION 's3://warehouse/019d81a3-c2d6-7ed2-ab15-070becf62582/my_table-13e4b91a2b4e47d98f312b1384263880/data/';

2. Массовая конвертация и выгрузка (DataFusion COPY)

Вместо того чтобы тянуть миллионы строк на локальный терминал, мы просим DataFusion выполнить преобразование и записать итог запроса обратно в MinIO.

Мы выбираем построчный JSON с экстремальным сжатием:

COPY (
    -- Тут может быть любая сложная агрегация:
    -- SELECT id, count(data) FROM my_parquet_data GROUP BY id
    SELECT * FROM my_parquet_data
) 
TO 's3://warehouse/019d81a3-c2d6-7ed2-ab15-070becf62582/my_table-13e4b91a2b4e47d98f312b1384263880/json_export/' 
STORED AS JSON
OPTIONS (
    'format.compression' 'zstd'
);

Результат:

+-------+
| count |
+-------+
| 2     |
+-------+
1 row(s) fetched. 
Elapsed 0.270 seconds.

За миллисекунды (0.270 sec) DataFusion прочитал партиции, трансформировал бинарные столбцы в текст и сжал его.

В чем преимущество подхода DataFusion?

Описанный паттерн выполнения команды `COPY TO` с сохранением `.json.zst` в MinIO полностью воспроизводит механику Spooling:

Отсутствие OOM (Out Of Memory): Клиент получает только метаданные `count`, а не гигабайты сырых данных в оперативную память.
Параллелизм: Если исходных файлов много, DataFusion будет писать множество потоков `part-0.json.zst`, `part-1.json.zst` в бакет параллельно.
Удаленное потребление: Вы можете запустить легкий Python-скрипт (Pandas) на дешевой машине, который просто прочитает эти сжатые легковесные JSON объекты напрямую из MinIO, минуя дорогостоящие вычислительные кластеры.

Еще немного про Fault-Tolerant Execution (FTE), нужно провести важную границу между архитектурой Trino (готовый распределенный кластер) и архитектурой DataFusion (ядро/библиотека выполнения запросов).

В самом “голом” ядре DataFusion (которое вы запускаете в `datafusion-cli` или в Jupyter) нет встроенного механизма Task Retries, потому что процессы выполняются на одной машине в рамках одного приложения. Если сервер падает — запрос прерывается.

Однако, в экосистеме DataFusion есть механизмы отказоустойчивости, которые делятся на два уровня: локальный (Spilling) и распределенный (Apache Ballista / Ray).

1. Локальная отказоустойчивость (защита от OOM)

В Trino частой причиной падения задач является нехватка памяти (Out of Memory). В DataFusion реализован мощный механизм управления памятью.

Если DataFusion понимает, что оперативной памяти для агрегации или JOIN’а не хватает, он не “роняет” задачу, а начинает сбрасывать промежуточные данные на диск (Spill to Disk).

Это настраивается через конфигурацию `datafusion.execution.disk_manager`.
Это аналог локального `spill-enabled = true` в Trino. Запрос замедлится, но выполнится до конца, не упав с ошибкой.

2. Распределенная отказоустойчивость (Аналог Trino FTE)

Trino использует архитектуру Fault-Tolerant Execution (FTE), при которой промежуточные результаты (Shuffle Exchange) пишутся в S3, а упавшие воркеры заменяются, и их задачи (Tasks) перезапускаются координатором.

В мире DataFusion эту задачу решает не само ядро, а распределенные планировщики, построенные поверх него:

А. Apache Ballista (Официальный распределенный DataFusion)

Ballista — это надстройка над DataFusion, превращающая его в полноценный кластер (с Coordinator и Executors), архитектурно очень похожая на Apache Spark и Trino.

Task Retries: Если один из Executor’ов теряется из-за сбоя сети или железа, Ballista Coordinator замечает это и переназначает задачу (Task) другому воркеру.
Shuffle Spilling: Промежуточные данные между стадиями (Stages) записываются во временные файлы. Следовательно, если упала только последняя стадия, кластеру не нужно пересчитывать весь запрос с нуля — он прочитает промежуточные Shuffle-файлы и повторит только упавший кусок.

Б. DataFusion on Ray (datafusion-ray)

Сейчас огромную популярность набирает запуск DataFusion поверх кластера Ray.
Ray — это супер-устойчивый распределенный фреймворк. Интеграция `datafusion-ray` позволяет разбить SQL-запрос на граф задач прямо в Ray.

За отказоустойчивость, Retry-логику и восстановление упавших узлов (Actor/Task) здесь отвечает сам Ray, который делает это на уровне индустриального стандарта.
Это максимально близко к концепции отказоустойчивого кластера.

Резюме: Как получить “Trino-like” Fault Tolerance в DataFusion?

Если вы используете локальный DataFusion (в Python или CLI): Отказоустойчивости уровня узлов нет, но есть защита от падений по памяти (Spill to Disk). Если упадет процесс — нужно перезапускать запрос руками.
Если вам нужен настоящий Task Repeat / Fault Tolerance на сотнях серверов, где падение серверов — норма: вы используете движок DataFusion вместе с кластерным менеджером Apache Ballista или Ray, которые прозрачно обеспечат перезапуск задач (Retries) и сохранение промежуточных состояний (Shuffle), полностью повторяя логику Trino FTE.

StarRocks: Архитектура, Практика и место в современном Data Stack

Sun, 15 Mar 2026 19:06:01 +0300

StarRocks — это аналитическая MPP-база данных нового поколения.
Если коротко, она пытается решить трилемму аналитики: объединить скорость ClickHouse (за счет векторизации и C++), гибкость Trino (поддержка сложных JOIN-ов) и простоту использования MySQL (совместимый протокол).

Это короткое руководство проведет вас от понимания архитектуры до построения простого конвейера загрузки данных (ETL) в домашнем продакшене.

Часть 1. Архитектура: FE и BE

В отличие от PostgreSQL (монолит) или ClickHouse (где узлы часто одноранговые), StarRocks имеет четкое разделение ролей. Это критически важно для понимания масштабирования и эксплуатации.

1. FE (Frontend) — “Мозг”

Написан на Java.

Роль: Управляющий слой.
Функции:
- Принимает подключения клиентов (по протоколу MySQL).
- Хранит метаданные (схемы таблиц, права доступа).
- Парсит SQL и строит план выполнения запроса (Query Plan).
- Управляет транзакциями загрузки данных.
Масштабирование: Обычно запускают 1 или 3 узла для обеспечения высокой доступности (HA).
Важно: Клиенты (DBeaver, BI, сurl) подключаются только к FE.

2. BE (Backend) — “Мускулы”

Написан на C++ (использует SIMD-инструкции процессора).

Роль: Слой хранения и вычислений.
Функции:
- Физически хранит данные (в колоночном формате).
- Выполняет “тяжелую” работу: фильтрацию, агрегацию, JOIN-ы.
- Управляет репликацией данных.
Масштабирование: Можно добавлять узлы линейно. Чем больше BE, тем быстрее выполняются запросы и тем больше данных можно хранить.

В Docker All-in-One: Оба компонента упакованы в один контейнер для удобства, но слушают разные порты:

`9030`: FE (SQL интерфейс, сюда идет DBeaver).

`8030`: FE (HTTP API для загрузки Stream Load, сюда идет curl).

`8040`: BE (HTTP API метрик и логов).

Часть 2. Быстрый старт (Docker Compose)

Мы поднимем стек StarRocks и MinIO (S3-совместимое хранилище), используя bridge-сеть для связности.

Файл `docker-compose.yml` (Полностью рабочий пример):

version: "3.9"

networks:
  starrocks-stack-network:
    driver: bridge

services:
  starrocks:
    image: starrocks/allin1-ubuntu:4.0-latest
    container_name: starrocks
    hostname: starrocks.local.com
    platform: "linux/amd64"
    restart: unless-stopped
    ports:
      - "9030:9030" # MySQL Protocol (SQL клиенты)
      - "8030:8030" # FE HTTP (Stream Load)
      - "8040:8040" # BE HTTP (Logs/Metrics)
    environment:
      - TZ=UTC
    networks:
      starrocks-stack-network:
    volumes:
      # Персистентность данных (чтобы данные не исчезли после рестарта)
      - ${HOME}/dv/starrocks/be/storage:/data/deploy/starrocks/be/storage
      - ${HOME}/dv/starrocks/be/log:/data/deploy/starrocks/be/log
      - ${HOME}/dv/starrocks/fe/meta:/data/deploy/starrocks/fe/meta
      - ${HOME}/dv/starrocks/fe/log:/data/deploy/starrocks/fe/log

  minio:
    image: quay.io/minio/minio
    container_name: minio
    platform: "linux/amd64"
    hostname: minio.local.com
    restart: unless-stopped
    ports:
      - "9000:9000" # S3 API
      - "9001:9001" # Web UI
    networks:
      starrocks-stack-network:
    environment:
      MINIO_ROOT_USER: root
      MINIO_ROOT_PASSWORD: rootroot
    volumes:
      - ${HOME}/dv/minio/data:/data
    command: server /data --console-address ":9001"

Запуск:
`docker-compose up -d`

Часть 3. Моделирование данных (Table Design)

В StarRocks нельзя просто “создать таблицу”. Нужно выбрать тип ключа (Key Model), который определит, как база будет хранить и обновлять данные.

Подключение (DBeaver): `localhost:9030`, User: `root`, Password: (пусто).

CREATE DATABASE IF NOT EXISTS demo_db;
USE demo_db;

1. Primary Key Model (Для изменяемых данных)

Это “флагманская” возможность StarRocks. Она поддерживает быстрые Upsert (вставка новых или обновление старых записей по ID) в реальном времени.

CREATE TABLE IF NOT EXISTS users (
    user_id INT NOT NULL,
    username VARCHAR(50),
    email VARCHAR(100),
    register_date DATE, 
    city VARCHAR(50)
)
PRIMARY KEY (user_id) -- Уникальный ключ
DISTRIBUTED BY HASH(user_id) -- Распределение данных
PROPERTIES (
    "replication_num" = "1" -- Для локального теста ставим 1 реплику
);

2. Aggregate Key Model (Для витрин данных)

База автоматически агрегирует данные при вставке. Если вы вставите новую продажу с *существующими* датой и категорией, StarRocks не создаст новую строку, а прибавит суммы к уже существующей строке. Это экономит место и ускоряет `GROUP BY`.

CREATE TABLE IF NOT EXISTS daily_sales (
    report_date DATE NOT NULL,
    category VARCHAR(50) NOT NULL,
    
    -- Метрики с функцией агрегации:
    total_amount BIGINT SUM DEFAULT "0", 
    items_sold INT SUM DEFAULT "0"       
)
AGGREGATE KEY (report_date, category)
DISTRIBUTED BY HASH(report_date) BUCKETS 3
PROPERTIES (
    "replication_num" = "1"
);

Часть 4. загрузка данных users (Stream Load)

Для загрузки данных в продакшене мы используем Service Account (Техническую учетную запись). Это стандарт безопасности: мы не используем `root` и не используем токены в конфигах (так как они требуют перезагрузки кластера для смены).

Шаг 1. Создание сервисного пользователя (SQL)

Выполнять под `root`:

-- 1. Создаем пользователя-бота
CREATE USER IF NOT EXISTS 'etl_loader'@'%' IDENTIFIED BY 'SecretPass123!';

-- 2. Даем права ТОЛЬКО на вставку и чтение в базе demo_db
GRANT INSERT, SELECT ON demo_db.* TO 'etl_loader'@'%';

-- Права применяются мгновенно.

Шаг 2. Загрузка сложного JSON через CURL

Stream Load — это самый быстрый способ загрузки (до 100 МБ/сек на узел). Он поддерживает транзакционность (ACID).

Пример файла `users.json`:

{
  "users": [
    {"user_id": 101, "username": "alex", "email": "a@test.com", "city": "NY"},
    {"user_id": 102, "username": "bob", "email": "b@test.com", "city": "LA"}
  ]
}

Команда загрузки (Terminal):

curl --location-trusted \
    -u etl_loader:SecretPass123! \
    -H "Expect: 100-continue" \
    -H "format: json" \
    -H "strip_outer_array: true" \
    -H "json_root: $.users" \
    -H "jsonpaths: [\"$.user_id\", \"$.username\", \"$.email\", \"$.city\"]" \
    -H "columns: user_id, username, email, city" \
    -T "users.json" \
    -XPUT http://localhost:8030/api/demo_db/users/_stream_load

Ответ

{
    "TxnId": 9596,
    "Label": "a9a37ab6-3678-4c08-95b7-2fd8b6ae973e",
    "Db": "demo_db",
    "Table": "users",
    "Status": "Success",
    "Message": "OK",
    "NumberTotalRows": 2,
    "NumberLoadedRows": 2,
    "NumberFilteredRows": 0,
    "NumberUnselectedRows": 0,
    "LoadBytes": 177,
    "LoadTimeMs": 153,
    "BeginTxnTimeMs": 2,
    "StreamLoadPlanTimeMs": 2,
    "ReadDataTimeMs": 0,
    "WriteDataTimeMs": 26,
    "CommitAndPublishTimeMs": 121
}%

Шаг 3. Загрузка в Aggregate Table (Example)

Давайте “дольем” данные в таблицу продаж. Агрегация произойдет на лету.
Файл sales.json (простой список):

[
    {"dt": "2023-11-01", "cat": "Electronics", "amt": 100, "qty": 1},
    {"dt": "2023-11-01", "cat": "Electronics", "amt": 50,  "qty": 1}
]

curl --location-trusted \
    -u etl_loader:SecretPass123! \
    -H "format: json" \
    -H "Expect: 100-continue" \
    -H "strip_outer_array: true" \
    -H "jsonpaths: [\"$.dt\", \"$.cat\", \"$.amt\", \"$.qty\"]" \
    -H "columns: report_date, category, total_amount, items_sold" \
    -T "sales.json" \
    -XPUT http://localhost:8030/api/demo_db/daily_sales/_stream_load

Ответ:

{
    "TxnId": 9613,
    "Label": "bce0721a-dc2d-4927-be93-e0979a57873d",
    "Db": "demo_db",
    "Table": "daily_sales",
    "Status": "Success",
    "Message": "OK",
    "NumberTotalRows": 2,
    "NumberLoadedRows": 2,
    "NumberFilteredRows": 0,
    "NumberUnselectedRows": 0,
    "LoadBytes": 143,
    "LoadTimeMs": 52,
    "BeginTxnTimeMs": 3,
    "StreamLoadPlanTimeMs": 2,
    "ReadDataTimeMs": 0,
    "WriteDataTimeMs": 24,
    "CommitAndPublishTimeMs": 20
}%

Разбор заголовков:

`-u ...`: Авторизация сервисным пользователем.
`Expect: 100-continue`: Критически важно для надежности передачи больших файлов.
`json_root: $.users`: Указывает базе, что данные лежат внутри ключа `users`.
`strip_outer_array: true`: Говорит базе, что внутри лежит массив `[...]` и его нужно “развернуть” в отдельные строки.

Часть 5. Совместимость и Trino Dialect

Одна из сильных сторон StarRocks — способность “притворяться” другими базами данных для облегчения миграции.

Если у вас есть дашборды, написанные на диалекте Trino (Presto), вам не нужно переписывать все SQL-запросы.

Пример трансляции функций:

-- Функция Trino, которой нет в StarRocks
SELECT doy(date '2022-03-06'); 
-- Ошибка: No matching function...

-- Проверяем, как StarRocks переведет этот запрос
TRANSLATE TRINO select doy(date '2022-03-06');
-- Результат: SELECT dayofyear('2022-03-06')

-- Включаем режим автоматической трансляции в сессии
SET sql_dialect = 'trino'; 

-- Теперь запрос выполняется корректно, но это не правда. а вот так SELECT dayofyear('2022-03-06') работает. Может бага или у меня версия не та. 
SELECT doy(date '2022-03-06');   

-- Возвращаем нативный режим
SET sql_dialect = 'starrocks';

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

Итог: Сравнение и Выбор решения ( грубо )

Характеристика	StarRocks	ClickHouse	Trino (Presto)
Основной сценарий	OLAP-витрины с JOIN-ами и обновлениями данных	Сбор логов, событий, метрик (Append-only)	Федерация данных (запрос к S3 + Postgres + Kafka одновременно)
JOIN производительность	⭐⭐⭐ (Excellent, CBO оптимизатор)	⭐ (Слабо, требует денормализации)	⭐⭐⭐ (Excellent)
Обновление (UPDATE)	⭐⭐⭐ (Работает как в OLTP, Primary Key)	⭐ (Тяжелые асинхронные ALTER)	❌ (Обычно только полная перезапись партиций), iceberg не в счёт :)
Язык Engine	C++ (SIMD Vectorized)	C++ (SIMD Vectorized)	Java (JVM)
Место в стеке	Serving Layer (Быстрый доступ для BI)	Storage Layer (Хранение логов)	Query Engine (Ad-hoc запросы к Data Lake)

Выбирайте StarRocks, если:

Вам нужна “витрина” для BI (Superset/Tableau), где данные должны быть всегда свежими (Real-time updates).
Ваш бизнес требует сложных аналитических запросов с множеством JOIN-ов, и ClickHouse не справляется/падает по памяти.
Вы хотите использовать стандартный протокол MySQL без установки проприетарных драйверов.

Битва титанов аналитики реального времени: StarRocks против ClickHouse

Fri, 06 Mar 2026 01:26:35 +0300

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

Часть 1: Обзор технологий и кейс Netflix

StarRocks: Субсекундная аналитика нового поколения

StarRocks — это высокопроизводительный аналитический движок (MPP database) нового поколения, разработанный для сценариев, где скорость имеет решающее значение. Будучи проектом Linux Foundation, он позиционирует себя как самый быстрый открытый движок запросов для субсекундной аналитики как внутри собственного хранилища, так и поверх архитектуры Data Lakehouse.

Ключевые особенности StarRocks:

Универсальность:** Поддерживает почти любые сценарии — от многомерной OLAP-аналитики и realtime-дэшбордов до ad-hoc запросов аналитиков.
Скорость:** Использует векторизованный движок исполнения, CBO (Cost-Based Optimizer) и пайплайновый параллелизм, что позволяет обгонять конкурентов на сложных запросах с JOIN-ами.
Архитектура:** Native cloud-ready, легко масштабируется горизонтально. Умеет работать “on and off the lakehouse” — то есть быстро читать данные напрямую из S3/HDFS (форматы Parquet, ORC, Iceberg, Hudi) без необходимости их обязательной загрузки внутрь базы.

Кейс Netflix: Как оптимизировать логирование петабайтного масштаба с ClickHouse

*( адаптация материала из блога ClickHouse)* https://clickhouse.com/blog/netflix-petabyte-scale-logging

В Netflix масштаб диктует всё. Инженер Дэниел Муино поделился инсайтами о том, как их система логирования справляется с 5 петабайтами логов ежедневно, обрабатывая в среднем 10.6 миллионов событий в секунду и отвечая на запросы быстрее, чем за секунду.

Для достижения такой производительности потребовалось не просто выбрать правильную базу данных (ClickHouse), но и внедрить три критических инженерных оптимизации.

Архитектура: Горячее и холодное

Netflix использует гибридный подход:

Горячий слой (ClickHouse):** Хранит недавние логи, где критична скорость для интерактивной отладки. Данные поступают через Kafka/Kinesis в ClickHouse практически мгновенно.
Холодный слой (Apache Iceberg):** Обеспечивает экономичное долговременное хранение исторических данных на S3.
Единый API автоматически решает, к какому слою обращаться, скрывая сложность от инженеров.

Результат: логи доступны для поиска через 20 секунд после генерации (при SLA в 5 минут), а сложные аналитические запросы выполняются почти мгновенно.

Три главные оптимизации

1. Ingestion: Свой лексер вместо Regex
Изначально Netflix использовал регулярные выражения для группировки похожих логов (fingerprinting). На скорости 10 млн событий/сек это стало узким местом.

Решение:* Команда переписала логику, создав сгенерированный лексер с помощью JFlex.
Результат:* Рост пропускной способности в 8-10 раз. Время обработки одного события упало с 216 до 23 микросекунд.

2. Сериализация: Отказ от JDBC
Стандартные JDBC-вставки через Java-клиент создавали оверхед на согласование схем. Переход на низкоуровневый формат `RowBinary` помог, но потребление CPU оставалось высоким.

Решение:* Дэниел реверс-инжинирил протокол Go-клиента ClickHouse (который поддерживает нативный формат) и написал собственный энкодер. Он генерирует LZ4-сжатые блоки в нативном протоколе ClickHouse.
Результат:* Снижение нагрузки на CPU и памяти при той же пропускной способности.

3. Запросы: Шардирование карт тегов (Tag Maps)
Инженеры Netflix активно используют кастомные теги (фильтры по microservice_id, request_id). Изначально они хранились как `Map(String, String)`. В ClickHouse это реализовано как два параллельных массива, что требует линейного сканирования при поиске. При 25 000 уникальных ключей в час запросы тормозили.

Решение:* Шардирование карты. Ключи тегов хешируются в 31 меньшую карту. Запрос сразу “прыгает” в нужный шард вместо перебора всех ключей.
Результат:* Время фильтрующих запросов упало с 3 секунд до 1.3, а сложных проекций — с 3 секунд до 700 мс.

Часть 2: ClickHouse vs StarRocks — Битва за Lakehouse

Обе системы являются лидерами в мире OLAP (On-Line Analytical Processing), используют MPP-архитектуру и колоночное хранение. Однако их философия и степень готовности к современной концепции Lakehouse (аналитика данных непосредственно в озере данных без копирования) различаются.

1. Архитектурные корни и специализация

ClickHouse:**
- ДНК:* Изначально создавался для Яндекс.Метрики. Король единой широкой таблицы.
- Сильная сторона:* Непревзойденная скорость записи и чтения на одной таблице. Идеален для логов (как у Netflix), телеметрии, событийных данных.
- Слабая сторона:* JOIN-ы (соединения таблиц). ClickHouse умеет их делать, но исторически это не его конек. Оптимизатор запросов долгое время был рудиментарным, требуя от пользователя ручной оптимизации порядка таблиц.

StarRocks:**
- ДНК:* Эволюционировал из Apache Doris. Создавался с прицелом на сложные сценарии аналитики.
- Сильная сторона:* CBO (Cost-Based Optimizer) уровня Oracle или Teradata. StarRocks блестяще справляется со сложными SQL-запросами, включая многотабличные JOIN-ы “звезда” и “снежинка”.
- Специфика:* Ориентирован на обновление данных в реальном времени (Primary Key table engine) и векторизованную обработку сложных вычислений.

2. Степень готовности к Lakehouse (Работа с S3, HDFS, Iceberg)

Здесь наблюдается главное стратегическое расхождение.

StarRocks: Native Lakehouse Engine
StarRocks позиционирует себя как движок, который может вообще не хранить данные у себя, а выступать только быстрым вычислительным слоем поверх S3/MinIO.

Кэширование:** Имеет продвинутый локальный кэш данных (Local Data Cache), который подтягивает горячие данные из S3 на диски воркеров, обеспечивая скорость, сравнимую с нативным хранением.
Каталоги:** Бесшовная интеграция с Hive Metastore, AWS Glue, Iceberg, Hudi, Delta Lake. Вы просто подключаете каталог и пишете `SELECT` к таблицам в S3 без `CREATE TABLE`.
Вердикт: StarRocks **полностью готов к Lakehouse. Это один из лучших выборов для сценария “данные лежат в S3 в формате Parquet/Iceberg, а нам нужен быстрый SQL поверх них”.

ClickHouse: Storage First, Lakehouse Second
ClickHouse исторически — это система хранения. Хотя поддержка S3 и Data Lakes активно развивается (особенно в 2024-2025 годах), подход отличается.

Интеграция:** ClickHouse может читать из S3 (`s3()` table function или S3 table engine). Поддерживает Iceberg и Hudi.
Производительность:** Чтение “холодных” данных из S3 в ClickHouse часто медленнее, чем в StarRocks, из-за особенностей реализации сканирования и работы с метаданными внешних форматов.
Кейс Netflix подтверждает: Netflix использует ClickHouse **как горячее хранилище, копируя туда данные. А для лекхоуса (Iceberg) они используют отдельные движки (вероятно, Trino или Spark), а ClickHouse выступает именно как акселератор для свежих данных.
Вердикт: ClickHouse движется в сторону Lakehouse (разделение Storage и Compute, S3-backed MergeTree), но его главная суперсила по-прежнему раскрывается, когда данные **импортированы в его родной формат.

Пример использования ClickHouse (из статьи выше)

В примере Netflix мы видим классический паттерн использования ClickHouse, где он силен максимально:

*“ClickHouse находится в сердце системы как горячий слой (hot tier). Он хранит недавние логи, где скорость критична... Для исторических данных Netflix использует Apache Iceberg.”*

Это подтверждает тезис: ClickHouse идеален, когда вы загружаете данные в него (Ingest heavy). StarRocks же часто выигрывает там, где данные уже лежат в озере, и вы не хотите их никуда копировать, либо, когда вам нужны сложные JOIN-ы поверх этих данных.

Итог и рекомендации

Выбор между StarRocks и ClickHouse больше не стоит в плоскости “кто быстрее сканирует одну колонку”. Обе системы феноменально быстры. Вопрос в архитектуре ваших данных.

Рекомендации:

Выбирайте ClickHouse, если:
- Ваша главная задача — работа с логами, метриками, clickstream (как у Netflix).
- У вас плоская структура данных (одна широкая таблица), и JOIN-ы редки.
- Вам нужна максимальная скорость вставки (ingestion) и максимальное сжатие данных на диске.
- У вас есть ресурсы на инженерию: ClickHouse гибок, но, как показал кейс Netflix, требует “прямых рук” для тонкой настройки (кастомные кодеки, шардирование тегов).

Выбирайте StarRocks, если:
- Вы строите Data Lakehouse: данные лежат в S3 (Iceberg/Parquet), и вы хотите анализировать их без ETL/копирования.
- У вас сложная модель данных (схема “Звезда” или “Снежинка”) и много JOIN-ов в запросах.
- Вам нужны обновления данных (UPSERT/DELETE) в реальном времени с использованием Primary Keys.
- Вы хотите упростить поддержку и получить оптимизатор запросов, который многое сделает за вас “из коробки”.

Приложение:

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

1. Сферы деятельности компаний

Вот краткое описание того, чем занимается каждая компания из вашего списка:

Технологии, Интернет и E-commerce:

Alibaba:** Крупнейший китайский холдинг электронной коммерции и облачных вычислений.
Shopee:** Ведущая платформа электронной коммерции в Юго-Восточной Азии и Тайване.
Trip.com:** Одно из крупнейших в мире онлайн-турагентств.
Airbnb:** Онлайн-площадка для размещения, поиска и краткосрочной аренды жилья.
Xiaohongshu (RedNote):** Китайская социальная сеть и платформа электронной коммерции (аналог Instagram + Pinterest).
Zepto:** Сервис быстрой доставки продуктов (quick commerce) из Индии.
Naver:** Ведущая южнокорейская интернет-компания (поисковик, карты и др.).

Социальные сети и Медиа:

Pinterest:** Фотохостинг, социальная сеть для обмена идеями.
Tencent (Games & LLM):** Технологический гигант, владелец WeChat, крупнейший в мире издатель видеоигр.
iQiyi:** Крупная китайская платформа онлайн-видео (аналог Netflix).
SmartNews:** Агрегатор новостей (популярен в Японии и США).

Финтех и Криптовалюты:

Coinbase:** Крупнейшая американская криптовалютная биржа.
Intuit:** Американская компания, разработчик финансового ПО (QuickBooks, TurboTax).
TRM Labs:** Блокчейн-аналитика, порядочность в криптосфере и compliance.
Yuno:** Финтех-оркестратор платежей.

B2B SaaS и Корпоративное ПО:

Airtable:** Облачный сервис для работы с базами данных и таблицами (no-code).
Celonis:** Лидер в области Process Mining (анализ бизнес-процессов).
Cisco:** Мировой лидер в области сетевых технологий и кибербезопасности.
Demandbase:** Платформа для ABM-маркетинга (Account-Based Marketing).
Eightfold.ai:** Платформа для управления талантами на базе ИИ.
Freshа:** Платформа для бронирования услуг в сфере красоты и здоровья.
SplitMetrics:** Платформа для A/B тестирования и оптимизации мобильных приложений.
Verisoul:** Платформа для выявления фейковых пользователей и ботов.

Транспорт и Логистика:

Didi:** Китайский агрегатор такси (аналог Uber).
Grab:** Супер-приложение из Юго-Восточной Азии (такси, доставка еды, платежи).

Игры:

PlaySimple Games:** Разработчик мобильных словесных игр.

Сельское хозяйство:

HerdWatch:** ПО для управления фермерскими хозяйствами.

Энергетика:

Haezoom:** Южнокорейская платформа в сфере солнечной энергетики (Energy AI).

Ритейл (Merchandise):

Fanatics:** Мировой лидер по продаже лицензионной спортивной атрибутики.

2. Ранжирование по степени использования (Use Case Depth)

Это ранжирование основано на публично доступных кейсах (case studies), объемах данных и критичности систем, переведенных на StarRocks.

Уровень 1: Heavy Users / Mission Critical (Ключевые внедрения)

Эти компании заменили устаревшие хранилища данных (Snowflake, ClickHouse, Druid) на StarRocks для критически важных задач с огромными объемами данных.

Airbnb: Используют StarRocks для метрик реального времени и “умного” ценообразования (Minerva). Огромные объемы данных, строгие требования к задержке.
Tencent (Games & LLM): Один из самых масштабных пользователей. Унифицировали аналитику (заменив Hive/Spark/Druid), что позволило анализировать данные сотен игр в реальном времени.
Trip.com: Полностью отказались от ClickHouse и частично от Hive в пользу StarRocks для ускорения отчетов. Обрабатывают петабайты данных, высокая конкуренция запросов.
Shopee: Используют StarRocks для Data Service (API), ускорив запросы в 3 раза по сравнению с Presto. Критически важно для работы их E-commerce платформы.
Didi: Масштабное использование для логистики в реальном времени и анализа поездок.
Fanatics: Сократили расходы на 90%, перейдя с Snowflake на связку StarRocks + Iceberg.
Coinbase: Заменили Snowflake для аналитики, обращенной к клиенту (customer-facing). Требовались быстрые JOIN-ы на терабайтных масштабах, чего не давали другие системы.

Уровень 2: Strategic Users (Важные продуктовые внедрения)

Компании, использующие StarRocks для конкретных, высоконагруженных продуктов или функций.

Pinterest: Используют для аналитики, но акцент сделан на Lakehouse-архитектуре и join-ах больших таблиц.
Xiaohongshu (RedNote): Аналитика поведения пользователей в реальном времени (user behavior analysis) с высочайшей кардинальностью данных.
Fresha: Аналитика для партнеров (салонов красоты). Важна скорость отклика дэшбордов для тысяч внешних пользователей.
Grab: Аналитика для супер-приложения. Замена Druid/Pinot для более гибких SQL-запросов.
Celonis: Использование в движке Process Mining, где требуются сложные JOIN-операции, с которыми StarRocks справляется лучше колоночных аналогов.

Уровень 3: Adopters (Специфические сценарии)

Компании, использующие StarRocks для внутренних BI-систем, маркетинговой аналитики или замены медленных компонентов.

Airtable, Cisco, Intuit, Zepto, PlaySimple Games:** Вероятнее всего, использование для внутренней ускоренной аналитики и BI-отчетов, где традиционные DWH стали слишком медленными или дорогими.

3. Ранжирование по степени влияния на проект (Contribution & Influence)

StarRocks — это Open Source проект. Влияние оценивается по вкладу в код (Pull Requests), участию в техническом комитете (TSC) и архитектурном развитии.

1. Лидеры (Архитекторы и основные контрибьюторы):

Alibaba и Tencent:** Эти техногиганты не просто используют проект, они предоставляют огромное количество коммитов, тестируют его на экстремальных нагрузках и формируют roadmap развития. Многие фичи для “реального времени” и интеграции с Data Lake пришли благодаря требованиям и коду инженеров этих компаний.
Didi:** Активные контрибьюторы в области стабильности и оптимизации планировщика запросов под высокие нагрузки.
Airbnb:** Их вклад значителен в области интеграции с экосистемой данных (например, улучшения для Apache Iceberg и метрик), так как они строят сложные платформы данных (Minerva).

2. Инноваторы (Драйверы конкретных фич):

Trip.com: Сильно повлияли на развитие функций для работы с **Data Lakehouse (прямые запросы к Hive/Iceberg без импорта данных), так как их основной кейс — отказ от миграции данных.
Shopee: Влияют на развитие функционала **Materialized Views (материализованных представлений), так как активно используют их для ускорения API.
Pinterest и Coinbase:** Их кейсы (быстрые JOIN-ы на S3) подталкивают развитие кеширования и оптимизатора для “холодных” данных.

3. Евангелисты (Популяризаторы):

Celonis, Fanatics, Grab:** Активно выступают на конференциях, пишут технические блоги о миграции с конкурентов (Snowflake, Druid), тем самым привлекая новых пользователей и валидируя технологию на западном рынке.

ClickHouse — это колоночная аналитическая СУБД с открытым кодом, позволяющая выполнять аналитические запросы в режиме реального времени на структурированных больших данных. Изначально разработанная в Яндексе для Яндекс.Метрики, она стала мировым стандартом для задач логирования, телеметрии и продуктовой аналитики благодаря феноменальной скорости вставки и сжатия данных.

1. Сферы деятельности компаний

Список компаний, использующих ClickHouse, охватывает почти все отрасли, где генерируются “Big Data”.

Технологии, Интернет и Облачные сервисы:

Yandex:** Родительская компания. Поисковик, такси, e-commerce, облачные сервисы.
Cloudflare:** Глобальная сеть доставки контента (CDN) и защита от DDoS.
Uber:** Мировой агрегатор такси и доставки.
eBay:** Один из старейших и крупнейших аукционов и маркетплейсов в мире.
VK (ВКонтакте):** Крупнейшая социальная сеть в СНГ.
GitLab:** Платформа для DevOps и управления жизненным циклом ПО.

Стриминг, Медиа и Развлечения:

Spotify:** Глобальный аудио-стриминговый сервис.
Netflix:** Крупнейший в мире онлайн-кинотеатр (стриминг видео).
Twitch:** Видеостриминговый сервис, специализирующийся на компьютерных играх.
Disney+ (Disney Streaming):** Стриминговая платформа медиа-конгломерата Disney.

Финансы и Финтех:

Bloomberg:** Поставщик финансовой информации для профессиональных участников рынков.
Deutsche Bank:** Крупнейший банковский концерн Германии.
Revolut:** Британский финтех-стартап и необанк.

Мониторинг, Observability и SaaS:

Datadog:** Платформа мониторинга и безопасности для облачных приложений.
Grafana Labs:** Разработчик популярнейшей платформы визуализации данных.
Sentry:** Платформа для отслеживания ошибок в приложениях.
Segment (Twilio):** Платформа клиентских данных (CDP).

Телеком:

Comcast:** Крупнейшая телекоммуникационная компания США.
Verizon:** Один из лидеров американского рынка мобильной связи.

---

2. Ранжирование по степени использования (Use Case Depth)

Это ранжирование отражает масштаб данных, критичность системы для бизнеса и сложность архитектуры.

Уровень 1: Heavy Users / Hyper-scale (Экстремальные нагрузки)

Компании, обрабатывающие триллионы строк, где ClickHouse является ядром инфраструктуры.

Cloudflare: Пожалуй, один из самых впечатляющих кейсов в мире. Используют ClickHouse для аналитики HTTP-трафика и DNS-запросов. Обрабатывают десятки миллионов событий в секунду (более 100 млрд строк в день) для предоставления аналитики клиентам в личном кабинете.
Yandex (Метрика): Исторический “reference implementation”. Крупнейшая система веб-аналитики в Европе, работающая на кластерах из сотен серверов. Именно для этой нагрузки (>1 триллиона строк в базе) ClickHouse и был создан.
Uber: Используют ClickHouse для своей платформы логирования (более 4 петабайт данных), заменив Elasticsearch в ряде задач ради экономии ресурсов и скорости.
Lyft: Используют для аналитики поездок и Geo-данных в реальном времени, обрабатывая огромные потоки телеметрии с автомобилей и приложений.
Bytedance (TikTok): (До миграции части нагрузок на другие системы) Один из крупнейших пользователей в Китае, использовавший ClickHouse для анализа поведения пользователей (User Behavior Analysis) на гигантских масштабах.

Уровень 2: Strategic Users (Ключевой компонент продукта)

Компании, которые строят свой основной продукт или критически важные внутренние сервисы на базе ClickHouse.

Sentry: Вся аналитика ошибок и производительности в их SaaS-продукте построена на ClickHouse. Они хранят миллиарды событий ошибок, позволяя разработчикам мгновенно фильтровать их.
GitLab: Используют ClickHouse для feature “Observability” внутри своего продукта, предоставляя пользователям аналитику по их CI/CD пайплайнам.
Spotify: Используют для внутренней аналитики экспериментов (A/B тесты) и логов воспроизведения треков.
eBay: Используют для OLAP-аналитики логов приложений и мониторинга, добиваясь снижения затрат по сравнению с традиционными коммерческими решениями.
Segment: Платформа позволяет клиентам делать сложные выборки по аудитории, и ClickHouse здесь выступает в роли “движка” для мгновенной сегментации пользователей.

Уровень 3: Adopters (Специализированные задачи)

Использование для конкретных департаментов, внутренней бизнес-разведки (BI) или замены старых компонентов.

Deutsche Bank:** Анализ рыночных тиков и высокочастотная финансовая аналитика.
Comcast:** Мониторинг качества видеопотока и сети.
Bloomberg:** Аналитика взаимодействия пользователей с терминалом Bloomberg.

---

3. Ранжирование по степени влияния на проект (Contribution & Influence)

ClickHouse имеет огромное сообщество. Влияние оценивается не только по использованию, но и по вкладу в кодовую базу (PR), разработке драйверов и организации митапов.

1. Создатели и Архитекторы:

ClickHouse Inc:** После выделения в отдельную компанию в 2021 году, основные разработчики (включая Алексея Миловидова) работают здесь. Именно они определяют roadmap, развивают ClickHouse Cloud и ядро системы.
Yandex:** Исторический создатель. До сих пор вносят огромный вклад, поддерживают свои форки и используют систему на пределе возможностей, что помогает выявлять баги производительности.

2. Технологические Партнеры и Контрибьюторы:

Cloudflare:** Внесли огромный вклад в оптимизацию работы с сетью, TLS и безопасность, так как их требования к защищенности и нагрузке экстремальны. Часто пишут глубокие технические статьи о внутренностях ClickHouse.
Altinity:** Компания, оказывающая консалтинг и поддержку ClickHouse. Сделали огромный вклад в экосистему Kubernetes (ClickHouse Operator), драйверы и интеграцию с экосистемой Hadoop/MySQL.
Contentsquare:** Активно участвуют в оптимизации ядра для специфических аналитических функций (session analysis).

3. Евангелисты Экосистемы:

Uber и Lyft:** Публикуют детальные инженерные блоги о том, как переводить логирование с ELK стека на ClickHouse, чем вдохновили сотни других компаний на миграцию.
Grafana Labs:** Разрабатывают и поддерживают официальный плагин ClickHouse для Grafana, делая СУБД доступной для визуализации миллионам пользователей.

R2 SQL: Глубокое погружение в наш новый движок для распределенных запросов

Wed, 18 Feb 2026 21:56:56 +0300

Введение

В современном мире объемы данных растут экспоненциально, и хранение петабайтов информации в объектных хранилищах (как Amazon S3 или Cloudflare R2) стало стандартом. Однако просто хранить данные мало — их нужно анализировать. Традиционно для этого требовалось поднимать сложные кластеры (например, Spark или Trino), что долго и дорого.

Компания Cloudflare представила R2 SQL — бессерверный (serverless) движок, который позволяет выполнять SQL-запросы прямо к данным, лежащим в объектном хранилище R2, без необходимости управлять инфраструктурой. Эта статья подробно описывает архитектуру этого решения: как они добились высокой скорости, используя формат таблиц Apache Iceberg, умное планирование запросов и свою глобальную сеть.

Ссылка на оригинал статьи А ранее я уже писал про их анонс тут https://gavrilov.info/all/cloudflare-anonsiruet-platformu-dannyh/

R2 SQL: Глубокое погружение в наш новый движок для распределенных запросов

Авторы: Yevgen Safronov, Nikita Lapkov, Jérôme Schneider. ( Привет Никита и Евген :)

Как выполнить SQL-запросы над петабайтами данных… без сервера?
У нас есть ответ: R2 SQL, бессерверный движок запросов, который может просеивать огромные наборы данных и возвращать результаты за секунды.

В этом посте подробно описывается архитектура и методы, которые делают это возможным. Мы пройдемся по нашему Планировщику запросов (Query Planner), который использует `R2 Data Catalog` для отсечения терабайтов данных еще до чтения первого байта, и объясним, как мы распределяем работу по глобальной сети Cloudflare, используя `Workers` и `R2` для массивного параллельного выполнения.

От каталога к запросу

Во время Developer Week 2025 мы запустили `R2 Data Catalog` — управляемый каталог `Apache Iceberg`, встроенный непосредственно в ваш бакет Cloudflare R2. Iceberg — это открытый формат таблиц, который предоставляет критически важные функции баз данных (такие как транзакции и эволюция схемы) для объектного хранилища петабайтного масштаба. Он дает вам надежный каталог ваших данных, но сам по себе не предоставляет способа их запрашивать.

До сих пор чтение вашего каталога `R2 Data Catalog` требовало настройки отдельного сервиса, такого как `Apache Spark` или Trino. Эксплуатация этих движков в большом масштабе непроста: вам нужно создавать кластеры, управлять использованием ресурсов и отвечать за их доступность — ничто из этого не способствует главной цели: получению ценности из ваших данных.

`R2 SQL` полностью устраняет этот этап. Это бессерверный движок запросов, который выполняет SQL-запросы на чтение (retrieval) к вашим таблицам Iceberg прямо там, где живут ваши данные.

поясненИИе: Что такое Apache Iceberg?

Представьте, что у вас есть огромная куча файлов (CSV, Parquet, JSON) в облачном хранилище. Это “озеро данных”. Проблема в том, что если вы начнете менять один файл, пока кто-то другой его читает, все сломается. Трудно понять, какая версия данных актуальна.

Apache Iceberg — это слой управления поверх этих файлов. Он работает как библиотекарь: он не хранит сами книги (данные), но ведет идеальный учет (метаданные). Он точно знает: “Таблица ‘Пользователи’ сейчас состоит из вот этих 100 файлов”.
Это позволяет делать с обычными файлами в облаке то, что раньше умели только дорогие базы данных:

ACID-транзакции: Гарантия того, что данные не запишутся “наполовину”.
Time Travel: Возможность сделать запрос “Как выглядела таблица вчера в 14:00?”.
Ecosystem: Единый стандарт, который понимают разные инструменты аналитики.

Проектирование движка запросов для петабайтов

Объектное хранилище фундаментально отличается от хранилища традиционной базы данных. База данных структурирована по своей природе; `R2 `— это океан объектов, где одна логическая таблица может состоять из миллионов отдельных файлов, больших и маленьких, и новые поступают каждую секунду.

Apache Iceberg предоставляет мощный слой логической организации поверх этой реальности. Он работает, управляя состоянием таблицы как неизменяемой серией мгновенных снимков (snapshots), создавая надежное, структурированное представление таблицы путем манипулирования “легкими” файлами метаданных вместо перезаписи самих файлов данных.

Однако эта логическая структура не меняет физической проблемы, лежащей в основе: эффективный движок запросов всё равно должен найти конкретные данные, необходимые ему, в этой огромной коллекции файлов. Это требует преодоления двух основных технических барьеров:

Проблема ввода-вывода (I/O problem): Главная проблема эффективности запросов — минимизация объема данных, считываемых из хранилища. Подход “в лоб” с чтением каждого объекта просто нежизнеспособен. Основная цель — читать только те данные, которые абсолютно необходимы.
Проблема вычислений (Compute problem): Объем данных, которые *действительно* нужно прочитать, все равно может быть огромным. Нам нужен способ выделить запросу, который может быть массивным, необходимое количество вычислительной мощности всего на несколько секунд, а затем мгновенно снизить его до нуля, чтобы избежать лишних трат.

Наша архитектура для `R2 SQL` разработана для решения этих двух проблем с помощью двухэтапного подхода: Планировщик запросов (Query Planner), который использует метаданные для интеллектуального отсечения (pruning) пространства поиска, и система Выполнения запросов (Query Execution), которая распределяет работу по глобальной сети Cloudflare для параллельной обработки данных.

Планировщик запросов (Query Planner)

Самый эффективный способ обработки данных — не читать их вовсе. Это ключевая стратегия планировщика `R2 SQL`. Вместо исчерпывающего сканирования каждого файла планировщик использует структуру метаданных, предоставляемую каталогом `R2 Data Catalog`, чтобы “подрезать” пространство поиска, то есть избежать чтения огромных массивов данных, не относящихся к запросу.

Это расследование “сверху вниз”, где планировщик перемещается по иерархии слоев метаданных Iceberg, используя статистику (stats) на каждом уровне для построения быстрого плана, точно указывающего, какие диапазоны байтов должен прочитать движок.

Что мы подразумеваем под “статистикой”?

Когда мы говорим, что планировщик использует “статы”, мы имеем в виду сводные метаданные, которые Iceberg хранит о содержимом файлов данных. Эта статистика создает грубую карту данных, позволяя планировщику принимать решения о том, какие файлы читать, а какие игнорировать, даже не открывая их.

Есть два основных уровня статистики, которые планировщик использует для отсечения (pruning):

Статистика уровня раздела (Partition-level stats): Хранится в списке манифестов (manifest list) Iceberg. Эти статы описывают диапазон значений разделов для всех данных в определенном файле манифеста Iceberg. Для раздела по `day(event_timestamp)` это будут самый ранний и самый поздний дни, присутствующие в файлах, отслеживаемых этим манифестом.
Статистика уровня столбца (Column-level stats): Хранится в файлах манифестов. Это более детальная статистика о каждом отдельном файле данных. Файлы данных в `R2 Data Catalog` отформатированы с использованием `Apache Parquet`. Для каждого столбца файла Parquet манифест хранит ключевую информацию, такую как:
- Минимальное и максимальное значения. Если запрос запрашивает `http_status = 500`, а статистика файла показывает, что в столбце `http_status` минимум 200 и максимум 404, этот файл можно пропустить целиком.
- Количество null-значений. Это позволяет планировщику пропускать файлы, когда запрос ищет конкретно non-null значения (например, `WHERE error_code IS NOT NULL`), а метаданные файла сообщают, что все значения для `error_code` являются null.

Отсечение пространства поиска (Pruning)

Процесс отсечения — это расследование “сверху вниз”, которое происходит в три основных этапа:

Метаданные таблицы и текущий снимок (snapshot):
Планировщик начинает с запроса к каталогу о местоположении текущих метаданных таблицы. Это JSON-файл, содержащий текущую схему таблицы, спецификации разделов и журнал всех исторических снимков. Затем планировщик выбирает последний снимок для работы.

Список манифестов и отсечение разделов:
Текущий снимок указывает на единый *список манифестов* (manifest list) Iceberg. Планировщик читает этот файл и использует статистику уровня разделов для каждой записи, чтобы выполнить первый, самый мощный шаг отсечения, отбрасывая любые манифесты, чьи диапазоны значений разделов не удовлетворяют запросу. Например, для таблицы, партиционированной по дням, планировщик может отбросить манифесты за ненужные даты.

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

Отсечение групп строк (Row-group pruning) внутри файла:
Наконец, для конкретных файлов данных, которые всё еще являются кандидатами, Планировщик использует статистику, хранящуюся внутри *футеров* (footers) файлов Parquet, чтобы пропускать целые группы строк (row groups).

Результатом этого многослойного отсечения является точный список файлов Parquet и групп строк внутри этих файлов. Они становятся рабочими единицами (work units), которые отправляются в систему Выполнения запросов.

поясненИИе: Формат Parquet и Row Groups

Apache Parquet — это колоночный формат хранения данных. В отличие от CSV, где данные хранятся строка за строкой, в Parquet данные хранятся столбец за столбцом. Это идеально для аналитики (когда вам нужно посчитать среднее по одной колонке, не читая остальные 50).

Внутри себя файл Parquet делится на Row Groups (группы строк). Представьте файл на 1 миллион строк. Он может быть разбит на 10 групп по 100,000 строк. У каждой группы есть свой мини-заголовок со статистикой (min/max значения).

Пример: Вы ищете `id = 950,000`.
Движок читает футер файла и видит:

Row Group 1: id 1-100,000 -> Пропускаем.
...
Row Group 10: id 900,001-1,000,000 -> Читаем только эту часть файла.

Это называется “I/O skipping” и экономит огромное количество времени и денег на трафике.

Конвейер планирования (The Planning pipeline)

В `R2 SQL` описанное выше многослойное отсечение не является монолитным процессом. Для таблицы с миллионами файлов метаданные могут быть слишком большими, чтобы обработать их полностью до начала реальной работы. Ожидание полного плана внесет значительную задержку (latency).

Вместо этого `R2 SQL` рассматривает планирование и выполнение как единый конкурентный конвейер (pipeline). Работа планировщика — производить поток рабочих единиц (work units), которые исполнитель (executor) потребляет, как только они становятся доступны.

Начало выполнения как можно раньше

С этого момента запрос обрабатывается в потоковом режиме. По мере того как Планировщик читает файлы манифестов (и, следовательно, файлы данных, на которые они указывают) и отсекает их, он немедленно отправляет любые подходящие файлы данных/группы строк как рабочие единицы в очередь выполнения.

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

На вершине этой модели конвейера планировщик добавляет критически важную оптимизацию: преднамеренное упорядочивание (deliberate ordering). Файлы манифестов не стримятся в случайной последовательности. Вместо этого планировщик обрабатывает их в порядке, соответствующем условию `ORDER BY` вашего запроса, руководствуясь статистикой метаданных. Это гарантирует, что данные, которые с наибольшей вероятностью содержат желаемые результаты, обрабатываются первыми.

Ранняя остановка: как закончить, не читая всё

Благодаря тому, что Планировщик передает рабочие единицы в порядке, соответствующем `ORDER BY`, система выполнения сначала обрабатывает данные, которые с наибольшей вероятностью попадут в итоговый набор результатов.

Например, для запроса типа `... ORDER BY timestamp DESC LIMIT 5`: по мере того как движок выполнения обрабатывает рабочие единицы и отправляет результаты обратно, планировщик одновременно делает две вещи:

Поддерживает ограниченную “кучу” (heap) из лучших 5 результатов, увиденных на данный момент.
Следит за “ватерлинией” (high-water mark) самого потока. Благодаря метаданным он всегда знает абсолютно самый поздний `timestamp` любого файла данных, который *еще не был* обработан.

В момент, когда самая старая временная метка в нашей “Топ-5 куче” оказывается новее, чем “ватерлиния” оставшегося потока (максимально возможная дата в еще не прочитанных файлах), весь запрос может быть остановлен.

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

Выполнение запросов (Query Execution)

Планировщик передает работу кусочками, называемыми Row Groups. Сервер, который получает запрос пользователя, берет на себя роль координатора запроса. Он распределяет работу между воркерами (query workers) и агрегирует результаты.

Сеть Cloudflare огромна. Координатор связывается с внутренним API Cloudflare, чтобы убедиться, что для выполнения выбираются только здоровые серверы. Соединения между координатором и воркерами проходят через `Cloudflare Argo Smart Routing` для обеспечения быстрой и надежной связи.

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

Внутреннее устройство: Apache DataFusion

Внутри каждый воркер использует `Apache DataFusion` для выполнения SQL-запросов к группам строк. `DataFusion` — это аналитический движок запросов с открытым исходным кодом, написанный на Rust.

Разделы (partitions) в `DataFusion` идеально ложатся на модель данных `R2 SQL`, поскольку каждая группа строк (row group) может рассматриваться как независимый раздел. Благодаря этому каждая группа строк обрабатывается параллельно.
Поскольку группы строк обычно содержат как минимум 1000 строк, `R2 SQL` выигрывает от векторизованного выполнения. Каждый поток DataFusion может выполнять SQL-запрос сразу на множестве строк за один проход, амортизируя накладные расходы на интерпретацию запроса.

Поддержка Parquet и Arrow

`DataFusion` имеет первоклассную поддержку Parquet. Используя ranged reads (чтение диапазонов) в R2, он способен считывать только части файлов Parquet, содержащие запрошенные столбцы, пропуская остальные.

Оптимизатор `DataFusion` также позволяет нам “проталкивать” фильтры (push down filters) на самые низкие уровни плана запроса. Другими словами, мы можем применять фильтры прямо в момент чтения значений из файлов Parquet.

Когда воркер заканчивает вычисления, он возвращает результаты координатору через протокол gRPC. `R2 SQL` использует `Apache Arrow` для внутреннего представления результатов. Это формат в оперативной памяти (in-memory), который эффективно представляет массивы структурированных данных. Arrow также определяет формат сериализации `Arrow IPC`, который идеально подходит для передачи данных между процессами по сети.

поясненИИе: Векторизация и Apache Arrow
Векторизованное выполнение (Vectorized execution): Традиционные базы данных обрабатывали одну строку за раз (Row-at-a-time). Это медленно, потому что процессор постоянно переключается. Векторизация означает обработку данных “пачками” (например, сложить сразу 1000 чисел из колонки А с 1000 чисел из колонки Б). Это использует современные возможности CPU (SIMD инструкции) и работает в разы быстрее.

Apache Arrow: Это стандарт того, как хранить эти “пачки” данных в оперативной памяти, чтобы процессору было максимально удобно их читать.
Главный плюс Arrow: Zero-copy. Если один инструмент (DataFusion) передает данные другому (по сети координатору), и оба понимают Arrow, им не нужно тратить время на перекодирование (сериализацию/десериализацию) данных. Они просто “передают указатель” или копируют сырые байты как есть.

Будущие планы

Хотя `R2 SQL` и так хорош в фильтрации, мы планируем быстро добавлять новые возможности:

Поддержка сложных агрегаций (GROUP BY) в распределенном и масштабируемом виде.
Инструменты для визуализации выполнения запросов (explain analyze), чтобы помочь разработчикам улучшать производительность.
Поддержка многих конфигурационных опций Apache Iceberg.
Возможность запрашивать каталоги прямо из панели управления Cloudflare (Dashboard).

Мы также исследуем различные виды индексов, чтобы сделать запросы еще быстрее, и планируем добавить полнотекстовый поиск, геопространственные запросы и многое другое.

Попробуйте сейчас!

Это ранние дни для `R2 SQL`, но он уже доступен в открытой бете! Переходите к нашему руководству по началу работы, чтобы создать сквозной конвейер данных. Мы ждем вашей обратной связи в нашем Discord для разработчиков.

***

Итог и СоображенИИя

Итог: Cloudflare выпустила мощный инструмент, который превращает их объектное хранилище (R2) в полноценную аналитическую базу данных. Используя открытые стандарты (Iceberg, Parquet, Arrow, DataFusion) и свою глобальную сеть периферийных вычислений (Edge), они решили главную проблему Big Data — необходимость платить за простой серверов. Здесь вы платите только за время выполнения конкретного SQL-запроса.

СоображенИИя:

Коммодитизация аналитики: Cloudflare делает с Big Data то же, что ранее сделала с CDN и защитой от DDoS — делает сложные энтерпрайз-технологии доступными “по кнопке”. Использование открытого стека (Rust + Arrow + DataFusion) — это сейчас золотой стандарт построения современных СУБД (по этому пути идут такие гиганты как InfluxDB 3.0, LanceDB и др.). Cloudflare не изобретает велосипед, а собирает очень быструю ракету из лучших деталей.
Убийца Snowflake/Databricks для “бедных”? Для огромных корпораций Snowflake и Databricks останутся стандартом из-за богатого функционала. Но для стартапов и среднего бизнеса, у которых данные лежат в R2 (чтобы не платить за egress трафик AWS), появление R2 SQL делает переезд на сторонние аналитические платформы бессмысленным. Зачем гонять данные туда-сюда, если можно выполнить SQL прямо “на месте”?
Синергия с ИИ: Упоминание планов на “индексы” и “геопространственные запросы” намекает на векторный поиск в будущем. Если Cloudflare добавит возможность делать векторный поиск по данным в R2 так же нативно, это станет киллер-фичей для всех, кто строит RAG (Retrieval-Augmented Generation) приложения на базе LLM. Хранишь документы в R2 -> R2 SQL ищет контекст -> Workers AI генерируют ответ. Весь цикл внутри одной экосистемы с минимальными задержками.

Еще можно почитать про https://vegafusion.io и про формат https://lance.org – он как раз и добавит векторочков.

Data Stack 2.0: Закат Lambda-архитектуры и восход Fluss с Lance

Fri, 13 Feb 2026 01:59:35 +0300

Data Stack 2.0: Закат Lambda-архитектуры и восход Fluss с Lance

В мире инфраструктуры данных происходит “тектонический сдвиг”, описанный в отчетах a16z.com. Индустрия отходит от сложной Lambda-архитектуры (где batch и streaming живут отдельно) к унифицированным решениям, которые называют Streamhouse.

Два ключевых игрока, меняющих правила игры в этом переходе:

Apache Fluss — управляемое хранилище для потоковой обработки (Streaming Storage).
Lance — формат данных нового поколения для AI и Data Lake.

1. Проблема: Почему одной Kafka больше недостаточно?

Долгое время Apache Kafka была стандартом де-факто для передачи данных. Однако, как отмечают эксперты Ververica в статье Мир без Kafka, Kafka была спроектирована как *распределенный лог*, а не как база данных.

Перевод есть тут, у меня: https://gavrilov.info/all/mir-bez-kafka-pochemu-kafka-ne-podhodit-dlya-analitiki-realnogo/

Фундаментальные ограничения брокеров сообщений (Kafka/Pulsar) для аналитики:

Слабая работа с обновлениями (Updates): Kafka — это `append-only` система. Реализация `UPDATE` или `DELETE` требует использования *Compact Topics*, что не дает гарантий мгновенной консистентности и сложно в эксплуатации.
Медленное чтение истории: Чтобы найти запись годичной давности, вам часто нужно прочитать весь лог последовательно (Scan). Сложность операции — $O(N)$.
Row-based природа: Данные хранятся строками (Message bytes). Для аналитики (OLAP), где нам нужен средний чек по столбцу `price`, системе приходится распаковывать и читать *все* поля сообщения, что неэффективно.

2. Apache Fluss: Недостающее звено для Flink

Apache Fluss создан, чтобы решить проблему “разделения” между потоком и таблицей. Это нативное хранилище для Apache Flink, которое поддерживает концепцию Fluss.

Архитектурные прорывы:

Гибридная модель чтения (Stream-Table Duality): Fluss позволяет читать данные и как бесконечный поток (Log), и как изменяемую таблицу с первичными ключами (Primary Key Table). Это делает реализацию CDC (Change Data Capture) тривиальной: обновления перезаписывают старые значения по ключу.
Колоночная проекция (Columnar Projection): В отличие от Kafka, Fluss может отдавать аналитическому движку (Flink) только нужные колонки. Это снижает нагрузку на сеть (`I/O`) в разы.
Real-Time Lookups: Fluss поддерживает точечные запросы (Point Lookup) по первичному ключу с задержкой порядка миллисекунд.
$$Latency_{Fluss} \ll Latency_{Kafka Scan}$$
Это позволяет использовать его как *Serverless State* для приложений, избавляясь от необходимости ставить рядом Redis или RocksDB.
Tiered Storage в Data Lake: Fluss работает в паре с Apache Paimon (ранее Flink Table Store). Горячие данные живут в Fluss (на быстрых дисках/RAM), а по мере устаревания автоматически конвертируются в формат Lakehouse (Paimon/Parquet/ ну или Iceberg) и уходят в S3.

3. Lance: Новый стандарт для AI в Data Lake

Если Fluss отвечает за доставку и горячее состояние, то Lance меняет подход к хранению холодных данных для задач машинного обучения (ML).

Традиционный формат Parquet великолепен для аналитики (сканирование больших диапазонов), но ужасен для AI, где требуется случайный доступ (Random Access) для формирования батчей обучения.

Lance решает эти проблемы:

Случайный доступ:** Lance позволяет извлекать строки по индексу в ~100 раз быстрее Parquet.
Векторный поиск:** Это формат со встроенным векторным индексом (IVF-PQ). Вы можете хранить эмбеддинги прямо в файлах на S3 и выполнять поиск ближайших соседей (ANN) без отдельной VectorDB (вроде Pinecone или Milvus).
Zero-Copy версионирование:** Эффективное управление версиями датасетов без дублирования данных.

4. Сборка пазла: Как это работает вместе

Современный Streamhouse (см. примеры архитектуры]

выглядит как-то так:

Схема потока данных (Workflow):

Ingestion:
Приложения (на Go, Java, Python) пишут данные.

Важно:* Поскольку Fluss совместим с протоколом Kafka, можно использовать существующие Kafka-клиенты в Go-сервисах для записи в Fluss, не дожидаясь нативных библиотек. Но это пока только теория. Сходу я не нашел примеров быстро, но можно использовать GO и Arrow Flight SQL.

Streaming Storage (Fluss):
Fluss принимает данные, индексирует первичные ключи и хранит “горячее” окно (например, 24 часа).

Flink* выполняет `JOIN` и агрегации прямо поверх Fluss, используя `Lookup Join` (обогащение данных без сохранения большого стейта внутри Flink).

Archiving & AI (Paimon/Lance):
Исторические данные сбрасываются в S3.

Для классической BI-аналитики используется формат Apache Paimon или Iceberg.
Для ML-задач данные конвертируются или хранятся в Lance.

Unified Analytics (Trino):
Движок Trino позволяет делать SQL-запросы ко всем слоям одновременно. Аналитик пишет один `SELECT`, а Trino забирает свежие данные из Fluss, а исторические — из S3 (Lance/Parquet/iceberg).

Пример интеграции (концептуальный)

Поскольку прямого клиента Go для Fluss нет, использование в микросервисах чаще всего выглядит как работа через Kafka-протокол или HTTP-прокси, а основная логика ложится на Flink (Java/Python/ или еще чего):

// Flink SQL example: Создание таблицы, управляемой Fluss
CREATE TABLE user_behavior (
    user_id BIGINT,
    item_id BIGINT,
    action STRING,
    ts TIMESTAMP(3),
    PRIMARY KEY (user_id) NOT ENFORCED
) WITH (
    'connector' = 'fluss',
    'bootstrap.servers' = '...:9092', // Fluss совместим с Kafka-адресацией
    'table.log.consistency' = 'eventual' // Оптимизация под высокую пропускную способность
);

Надо пробовать и тестировать... все таки еще инкубационный и это только теория.

5. Выводы и рекомендации

Не используйте Kafka как базу данных. Если вашей архитектуре требуются частые обновления (`UPSERT`) и точечные запросы (`Lookup`), Apache Fluss — это более подходящий инструмент в экосистеме Flink.
Lance для AI. Если вы строите RAG (Retrieval-Augmented Generation) или RecSys, рассмотрите формат Lance вместо связки “Parquet + внешняя VectorDB”. Это упростит инфраструктуру.
Следите за совместимостью. Интеграции Lance с Trino и Fluss с не-JVM языками (например, Go, Rust или еще чего) находятся в активной разработке. Используйте проверенные пути (Kafka Protocol для Ingestion, DataFusion/Java/Python для Querying).

Полезные ресурсы для изучения:

Мир без 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) и обрезки столбцов. В совокупности эти архитектурные элементы снижают накладные операционные расходы, связанные с обслуживанием платформы, ускоряют внедрение новых сценариев использования и облегчают бесшовную интеграцию с существующей ИТ-инфраструктурой предприятия.

Рейтинг Open Source Графовых СУБД для AdTech

Sun, 14 Dec 2025 14:24:45 +0300

Для задач AdTech сегментации (профилирование пользователей, identity resolution, поиск look-alike аудиторий) набор требований к графовой базе данных специфичен: нужна высокая скорость операций чтения/записи (real-time bidding/serving) и горизонтальная масштабируемость (миллиарды событий и связей).

Учитывая популярность текущего стека (ClickHouse, Trino, Qdrant), идеальная графовая база должна уметь интегрироваться в аналитический контур (через Trino или прямые коннекторы) и дополнять ClickHouse (который хранит логи событий), взяв на себя хранение топологии связей.

Ниже представлен небольшой обзор и рейтинг Open Source решений на 2024-2025 год с фокусом на масштабируемость.

Рейтинг Open Source Графовых СУБД для AdTech

Разделим 12 решений на 3 эшелона по пригодности для высоконагруженной сегментации.

1 эшелон: Лидеры производительности и масштабирования (Native Distributed)

Эти базы изначально создавались для кластеров и больших объемов данных.

1. NebulaGraph

Тип: Native Distributed Graph Database.
Язык запросов: nGQL (SQL-подобный).
Архитектура: Разделение Compute (GraphD) и Storage (StorageD). Shared-nothing.
Плюсы для вас: Это топ-1 выбор для AdTech масштаба Tencent или Meituan. Спокойно переваривает сотни миллиардов вершин и триллионы ребер. Обеспечивает миллисекундный отклик при обходе графа (hops) на большую глубину.
Минусы: Более крутая кривая обучения, чем у Neo4j. Сообщество меньше, но растет.
Связь со стеком: Отлично дополнит ClickHouse (CH хранит атрибуты, Nebula — связи). Есть коннекторы для Spark/Flink. А через Spark можно дойти до Trino.

2. Dgraph

Тип: Native Distributed Graph.
Язык запросов: GraphQL (модифицированный DQL).
Архитектура: Распределенная, использует BadgerDB (KV store) под капотом. Поддерживает шардинг и репликацию “из коробки” в open source версии.
Плюсы: Горизонтальное масштабирование. Очень удобна для фронтенд-разработчиков благодаря GraphQL. Высокая пропускная способность.
Минусы: Специфичный язык запросов, если вы привыкли к SQL/Cypher. В последние годы темпы разработки ядра немного снизились относительно конкурентов.

3. Memgraph

Тип: In-Memory Graph Database (написана на C++).
Язык запросов: Cypher (совместим с Neo4j).
Архитектура: Работает в оперативной памяти (с возможностью сброса на диск).
Плюсы: Самая быстрая для задач реального времени (вычисление фичей для RTB). Полная совместимость с экосистемой Neo4j (драйверы, протокол Bolt). Поддерживает Python/Rust процедуры. Отличная работа с Streaming данными (Kafka).
Минусы: Ограничена объемом RAM (хотя есть disk-spill, это снижает скорость).
Связь со стеком: Отлично стыкуется с моделями AI (Qdrant), так как позиционируется для “Graph AI”.

2 эшелон: Классика и Универсалы

4. Neo4j (Community Edition)

Тип: Native Graph.
Язык: Cypher (стандарт индустрии).
Плюсы: Огромное сообщество, лучшая документация, куча плагинов (APOC).
Главный минус для AdTech: Open Source версия (Community) ограничена одним узлом. Нет встроенного кластеризации и шардинга (доступно только в Enterprise за большие деньги). Для “технического задела на вырост” в Open Source варианте — это бутылочное горлышко.

5. ArangoDB

Тип: Multi-model (Graph, Document, Key/Value).
Язык: AQL (похож на SQL).
Плюсы: Гибкость. Можно хранить сложные JSON-документы (как в Mongo) и связывать их.
Минусы: При глубоких обходах графа (“друзья друзей друзей”) проигрывает специализированным Native Graph базам по скорости. Это компромиссное решение.

6. JanusGraph

Тип: Layered Graph Database.
Плюсы: Работает поверх мощных бэкендов (Cassandra, HBase, ScyllaDB) и использует Elasticsearch для индексации. Масштабируемость ограничена только бэкендом.
Минусы: Очень “тяжелая” инфраструктура (JVM based). Сложна в настройке и эксплуатации. Медленнее на простых запросах из-за сетевых хопов между слоями. Часто считается “устаревающей” архитектурой по сравнению с Nebula/Dgraph.

7. Apache AGE (PostgreSQL Extension)

Тип: Extension.
Суть: Превращает PostgreSQL в графовую БД с поддержкой Cypher.
Плюсы: Если вы знаете Postgres, вы знаете AGE. Не нужно новой инфраструктуры.
Минусы: Производительность ограничена движком Postgres. Сложно масштабировать горизонтально на запись (проблема шардинга PG).

3 эшелон: Нишевые и Новые игроки

8. HugeGraph (Baidu) — аналог JanusGraph, популярен в Китае, очень мощный, но документация местами страдает.
9. OrientDB — мультимодельная, была популярна, но сейчас развитие замедлилось.
10. FalkorDB — форк закрывшегося RedisGraph (Redis module). Очень быстрый, использует разреженные матрицы. Интересен, если уже есть Redis.
11. Cayley — написана на Go (Google), простая, работает с триплетами (Linked Data), но для сложной AdTech логики может не хватить функционала.
12. TerminusDB — интересная база с концепцией “Git для данных”, но специфична для версионирования знаний, а не высоконагруженной сегментации.

Сравнительная таблица (ТОП-7 для выбора)

СУБД	Язык запросов	Архитектура	Масштабирование (Open Source)	Скорость (Read/Traverse)	Сложность эксплуатации	Идеально для
NebulaGraph	nGQL (SQL-like)	Distributed Native	Отличное (Sharding+Replication)	🔥 Очень высокая	Средняя/Высокая	Big Data, AdTech, Fraud
Memgraph	Cypher	In-Memory (C++)	Вертикальное / Репликация	🚀 Топ-1 (Low Latency)	Низкая (как Docker)	Real-time features, Streaming
Dgraph	GraphQL	Distributed Native	Отличное	Высокая	Средняя	App Backend, 360 Customer View
Neo4j (CE)	Cypher	Native	Нет (только 1 нода)	Высокая (локально)	Низкая	R&D, малые проекты
ArangoDB	AQL	Multi-model	Хорошее (Cluster mode)	Средняя	Средняя	Гибридные данные (Docs+Graph)
JanusGraph	Gremlin	Layered (over NoSQL)	Бесконечное (зависит от Backend)	Низкая/Средняя	☠️ Высокая	Если уже есть HBase/Cassandra
Apache AGE	Cypher	Postgres Ext	Только Read Replicas	Средняя	Низкая (если знают PG)	Гибрид SQL + Graph

Интеграция с текущим стеком (Qdrant, Trino или ClickHouse)

Qdrant + Graph DB = GraphRAG / Semantic Search:
- Сегментация пользователей часто требует поиска не только по связям (“кто кликал то же, что и я”), но и по похожести векторов (“чей профиль похож на мой”).
- Memgraph и **Neo4j имеют встроенные модули для работы с векторами, но так как у вас уже есть Qdrant, вам нужна база, которая *не пытается заменить Qdrant*, а позволяет хранить ID векторов в узлах графа.
- NebulaGraph** позволяет хранить embedding в свойствах узла, но поиск лучше делегировать Qdrant.

Trino:
- Вам захочется делать SQL-запросы сразу к ClickHouse (события) и Графу (профиль).
- У Neo4j и NebulaGraph есть коннекторы, позволяющие Trino (через JDBC или нативные коннекторы) запрашивать данные. Это мощнейшая связка для аналитиков. Отдельно нативного конектора к Trino пока не найти, но скоро может появится поддержка iceberg https://github.com/vesoft-inc/nebula/discussions/5902 или пока можно использоваться связку через Spark.

ClickHouse:
- Паттерн: ClickHouse хранит “сырые” логи (миллиарды строк). Агрегаты и связи (User Graph) пересчитываются и заливаются в Графовую БД для быстрого lookup.
- NebulaGraph** имеет Exchange (инструмент на основе Spark) для массовой заливки данных из Warehouse.

Итоговая рекомендация

Учитывая, что вы хотите Open Source и вам нужен технический задел (масштабирование) для AdTech:

🏆 Выбор №1: NebulaGraph

Это наиболее близкий аналог “ClickHouse в мире графов”.

Почему:** Он создан для хранения миллиардов вершин (пользователей/устройств) и работы в кластере. У него shared-nothing архитектура, которая необходима для роста. Язык nGQL будет понятен вашим аналитикам, знающим SQL (ClickHouse/Trino).
Для AdTech:** Идеально решает проблемы *Identity Resolution* (склеивание cookie, device_id, user_id и других атрибутов в единый граф) на больших объемах.

🥈 Выбор №2: Memgraph

Если ваши графы помещаются в память (сотни миллионов узлов, но не десятки миллиардов) и критична задержка (latency) менее 10 мс для *real-time* принятия решений.

Почему:** Он безумно быстр. Он совместим с Cypher (легко нанимать людей или переезжать с Neo4j). Написан на C++, очень эффективен.
Интеграция:** Идеально, если вы планируете стримить данные из Kafka, обновлять граф и сразу выдавать сегменты.

🥉 Выбор №3: Apache AGE (или ArangoDB)

Только если объем графа невелик, и вы хотите минимизировать зоопарк технологий, оставаясь в рамках “почти SQL” решений. Но для серьезного AdTech они не рекомендуется как *основное* хранилище графа пользователей.

Совет: Начните пилот (PoC) с NebulaGraph. Попробуйте загрузить туда выгрузку из ClickHouse и сравнить скорость выполнения запросов “найти всех пользователей, связанных через устройство X на глубину 3 шага” с тем, как это делается сейчас (вероятно, через JOINs в реляционке или CH). Если сложность эксплуатации Nebula покажется высокой, можно посмотреть в сторону Memgraph как более легкой альтернативы и применять их не на одном большом графе например, а на нескольких малых в реальном времени, а готовые расчеты уже хранить в привычных местах.

Еще можно почитать:

Вот еще мысль и про языки немного. Если проект большой с единым графом для разных нужд, то NebulaGraph выглядит лучшим решением, но архитектурно можно выбрать много средних и малых графов. Для второго подхода хорошо Memgraph с его языком Cypher

1. Семейство Cypher (OpenCypher / ISO GQL)

Базы: *Neo4j, Memgraph, FalkorDB, Apache AGE.*

Cypher — это «SQL для графов». Это декларативный язык, использующий ASCII-арт для визуализации связей в коде (например, `(User)-[:CLICKS]->(Ad)`).

Функциональность: Очень богатая. Поддерживает сложные паттерны (Pattern Matching), агрегации, пути переменной длины. В апреле 2024 года ISO утвердила стандарт GQL (Graph Query Language), который во многом основан на Cypher.
Плюсы:
- Интуитивность: Код читается как предложение на английском. Самая низкая кривая входа.
- Экосистема: Стандарт де-факто. Если вы знаете Cypher, вы можете переключаться между Neo4j, Memgraph и AGE без переобучения.
- Выразительность: Идеален для глубокой аналитики и поиска сложных паттернов (Fraud Detection).
Минусы:
- Изначально создавался для одноузловых систем. В распределенных системах (шардинг) некоторые конструкции Cypher могут быть сложны для оптимизации движком.
Оценка для стека:
- Memgraph/Neo4j: Работает идеально.
- Apache AGE: Cypher оборачивается внутри SQL запросов Postgres, что немного громоздко, но функционально.
- FalkorDB: Реализует подмножество Cypher, очень быстро благодаря Redis, но функционал беднее, чем у Neo4j.

2. Семейство Gremlin (Apache TinkerPop)

Базы: *JanusGraph, HugeGraph, OrientDB (частично), Azure CosmosDB.*

Gremlin — это императивный язык обхода графа (Traversals). Вы пишете не «что найти» (как в SQL/Cypher), а «куда идти» шаг за шагом.

Функциональность: Тьюринговская полнота. Можно написать алгоритм любой сложности прямо внутри запроса. Это скорее язык программирования потоков данных, чем язык запросов.
Плюсы:
- Контроль: Вы точно указываете базе, как обходить граф. Это важно для сверхбольших графов (как в JanusGraph/HugeGraph), где неверный план запроса может “положить” кластер.
- Абстракция: Работает поверх любой БД, поддерживающей TinkerPop.
Минусы:
- Сложность: Кривая обучения очень крутая. Код получается вербозным и сложным для отладки («write once, read never»).
- Устаревание: С появлением стандарта ISO GQL популярность Gremlin падает. Для новых проектов в 2025 году его выбирают редко, если только не привязаны к JanusGraph.
Пример AdTech: «Найти всех пользователей, кликнувших на этот баннер» на Gremlin будет длинной цепочкой вызовов методов (`g.V().has(‘Banner’...).out(‘CLICKS’)...`).

3. nGQL (NebulaGraph Query Language)

Базы: *NebulaGraph.*

Собственный язык Nebula, который синтаксически мимикрирует под SQL, но логически работает с графами.

Функциональность: Заточена под распределенный Massive Parallel Processing (MPP).
Плюсы:
- SQL-подход: Разработчикам, привыкшим к MySQL/ClickHouse, синтаксис `GO FROM ... OVER ...` будет понятнее, чем Gremlin.
- Скорость: Спроектирован так, чтобы не позволять писать «плохие» запросы, которые убивают распределенный кластер. Вынуждает думать о том, где лежат данные (VID).
- Пайпы: Удобный синтаксис передачи результата одного шага в другой через `|` (как в Bash).
Минусы:
- Vendor Lock-in: Это не стандарт. Переехать с Nebula на другую базу потребует переписывания всех запросов.
- Не поддерживает полную гибкость Pattern Matching, как Cypher (хотя добавили поддержку `MATCH`, она менее производительна, чем нативный `GO`).

4. DQL (ранее GraphQL+-)

Базы: *Dgraph.*

Это модифицированный GraphQL.

Функциональность: Идеальна для API. Вы запрашиваете данные в формате JSON-дерева, и база возвращает JSON.
Плюсы:
- Frontend-first: Фронтендерам не нужен бэкенд-прослойка, они могут (теоретически) ходить в базу почти напрямую.
- Работа с атрибутами: Поскольку Dgraph — это по сути распределенный Key-Value, DQL очень быстро достает атрибуты нод.
Минусы:
- Слабая аналитика: Графовые алгоритмы и сложные обходы (traversals) на DQL писать сложнее и менее эффективно, чем на Cypher/nGQL. Это язык выборки данных, а не язык аналитики графов.

5. AQL (ArangoDB Query Language)

Базы: *ArangoDB.*

Гибридный язык, объединяющий возможности SQL (JOINs), работы с JSON (как в Mongo) и графовых обходов.

Функциональность: Одна из самых мощных среди “универсалов”. Позволяет в одном запросе сделать JOIN трех коллекций, отфильтровать JSON и пройтись по графу друзей.
Плюсы: Гибкость.
Минусы: Синтаксис `FOR u IN users FILTER ...` специфичен и многословен. Для чистых графовых задач (deep hopping) он медленнее нативных решений [ArangoDB vs Native Graph].

6. Другие / Устаревающие

OrientDB (SQL-extended): Пытались расширить SQL для графов. Сейчас проект стагнирует, язык считается тупиковой ветвью эволюции по сравнению с Cypher/GQL.
SQL Graph (MS SQL / PG SQL): В [статье про SQL Server](https://learn.microsoft.com/ru-ru/sql/relational-databases/graphs/sql-graph-sample?view=sql-server-ver17) показан синтаксис `MATCH`, который Microsoft внедрила в T-SQL. Это попытка “догнать” Cypher, оставаясь в рамках реляционной модели. Удобно, если вы намертво привязаны к MS SQL, но неудобно для сложной аналитики.
Cayley (Gizmo/MQL): Очень нишевый язык на базе Go или JS. Для AdTech продакшена слишком экзотичен.

Сводная таблица сравнения

Язык	Базы данных	Порог входа	Для AdTech/High-load	Стандартность (2025)	Примечание
nGQL	NebulaGraph	Средний	Идеально (Tencent scale)	Низкая (Vendor specific)	Топ для сотен млрд связей и кластерной архитектуры.
Cypher	Memgraph, Neo4j, AGE	Низкий	Хорошо (Memgraph) / Средне (Neo4j)	Высокая (основа ISO GQL)	Самый удобный для аналитиков и Data Science.
DQL	Dgraph	Низкий (для Web-dev)	Хорошо (для OLTP)	Низкая	Лучший выбор, если граф — это бэкенд для UI.
Gremlin	JanusGraph, HugeGraph	Высокий	Отлично (если настроить)	Падает (Legacy)	Слишком сложен в поддержке, проигрывает современным языкам.
AQL	ArangoDB	Средний	Средне	Низкая	Хорош, если нужна “Document Store + Graph” в одном.

Итоговая рекомендация

Если приоритет — производительность на масштабе (AdTech, сегментация 100M+ пользователей):
Вам нужен NebulaGraph и его nGQL.

*Почему:* В AdTech сценариях (как у Meituan/Tencent) критичны latency на “хопах” (hops). nGQL архитектурно заставляет писать запросы так, чтобы они эффективно параллелились. Он менее удобен, чем Cypher, но более предсказуем в нагрузке.

Если приоритет — Real-time аналитика, ML-фичи и скорость разработки:
Вам нужен Memgraph на Cypher.

*Почему:* Вы получаете совместимость с самой популярной экосистемой (Neo4j), стандартный язык Cypher (легко найти специалистов) и скорость C++ in-memory движка.

Если приоритет — дешевое горизонтальное масштабирование “для бедных” (в хорошем смысле):
Вам нужен Dgraph (DQL) или NebulaGraph.

У Dgraph отличный шардинг из коробки и DQL закрывает 90% задач продуктовой разработки, но может буксовать на тяжелой аналитике.

От чего стоит отказаться:

Neo4j Community: Язык Cypher прекрасен, но ограничения лицензии (отсутствие кластера) убьют проект на росте.
JanusGraph/HugeGraph (Gremlin): В 2025 году начинать проект на Gremlin — это создавать себе технический долг, так как индустрия движется в сторону ISO GQL (Cypher Style).
Apache AGE: Пока слишком сыро для High-load, проблемы с горизонтальным масштабированием Postgres никуда не деваются.

Обзор pg_clickhouse: Как объединить мощь ClickHouse и удобство PostgreSQL

Fri, 12 Dec 2025 23:27:54 +0300

Недавно компания ClickHouse представила новый инструмент — расширение pg_clickhouse. Это событие стало ответом на одну из самых частых болей разработчиков: сложность миграции аналитических запросов из классических реляционных баз данных в колоночные аналитические СУБД.

Оригинал статьи: A Postgres extension for querying ClickHouse

или берем сразу тут: https://github.com/ClickHouse/pg_clickhouse/releases

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

Проблема: Данные переехали, а запросы остались

Типичный сценарий роста стартапа выглядит так: приложение строится на PostgreSQL. В какой-то момент данных (логов, метрик, транзакций) становится так много, что аналитические отчеты начинают тормозить. Обычные реплики для чтения (read replicas) перестают спасать.

Команда принимает решение внедрить ClickHouse. Перенос данных сейчас решается просто (например, с помощью ClickPipes), но возникает другая проблема:
Как быть с тысячами строк SQL-кода в ORM, дашбордах и скриптах, которые написаны под синтаксис Postgres?

Переписывание всей логики приложения под диалект ClickHouse — это месяцы работы и риск новых багов. Именно эту проблему решает `pg_clickhouse`.

Что такое pg_clickhouse?

pg_clickhouse — это расширение для PostgreSQL (Foreign Data Wrapper — FDW), которое позволяет создавать в Postgres «внешние таблицы», фактически ссылающиеся на таблицы в ClickHouse.

Суть технологии: Вы пишете запросы на привычном SQL диалекте PostgreSQL, обращаясь к этим таблицам. Расширение на лету транслирует запрос в диалект ClickHouse, отправляет его на исполнение в аналитическую базу и возвращает результат обратно в Postgres.

Для приложения это выглядит прозрачно: таблицы ClickHouse могут находиться просто в отдельной схеме (schema). Достаточно изменить путь поиска (`search_path`), и старые запросы начнут работать с данными, лежащими в ClickHouse.

В чем «соль»: Технология Pushdown

Главная ценность и сложность такого расширения заключается не просто в соединении двух баз, а в эффективности этого соединения. Этот механизм называется Pushdown (спуск или делегирование вычислений).

Если вы делаете запрос `SELECT sum(price) FROM orders`, есть два пути его выполнения:

Плохой путь: Postgres выкачивает *все* миллионы строк из ClickHouse и сам считает сумму. Это уничтожает весь смысл аналитической базы.
Путь pg_clickhouse: Расширение понимает, что это агрегация, и отправляет в ClickHouse команду «посчитай сумму». Обратно по сети возвращается только одна цифра.

Умная трансляция функций

Авторы `pg_clickhouse` пошли дальше простой трансляции. Они научили расширение переводить специфические функции Postgres в аналоги ClickHouse, даже если синтаксис кардинально отличается.

*Пример:*
В Postgres есть функция для расчета медианы: `percentile_cont(0.5) WITHIN GROUP (ORDER BY price)`.
В ClickHouse такой синтаксис не поддерживается.
`pg_clickhouse` автоматически переписывает это в нативную функцию ClickHouse: `quantile(0.5)(price)`.

Также поддерживается трансляция конструкции `FILTER (WHERE ...)` в специфичные для ClickHouse комбинаторы `-If` (например, `sumIf`).

Ускорение подзапросов (Semi-Join)

В версии 0.1.0 была реализована поддержка SEMI JOIN Pushdown. Это критически важно для запросов с конструкцией `WHERE ... IN (SELECT ...)` или `EXISTS`. Тесты на бенчмарке TPC-H показали, что благодаря этому время выполнения сложных запросов сократилось с нескольких секунд (или даже минут) до миллисекунд, так как фильтрация теперь происходит на стороне ClickHouse.

Планы развития (Roadmap)

Проект находится в стадии активной разработки (версия 0.1.0), и команда ClickHouse нацелена на полное покрытие аналитических сценариев.

Ключевые пункты плана:

Полное покрытие TPC-H и ClickBench: Оптимизация планировщика, чтобы все стандартные аналитические бенчмарки выполнялись с максимальным pushdown-ом.
Расширенная поддержка функций: Трансляция *всех* агрегатных и обычных функций PostgreSQL в их эквиваленты в ClickHouse.
DML операции: Поддержка легковесных удалений (`DELETE`) и обновлений (`UPDATE`), а также пакетной вставки данных через `COPY`.
Управление настройками: Возможность передавать настройки ClickHouse (settings) через команды создания пользователей или серверов в Postgres.
Passthrough-режим: Возможность отправить произвольный SQL-запрос (на диалекте ClickHouse) и получить результат в виде таблицы, обходя парсер Postgres.

Заключение

`pg_clickhouse` — это попытка построить «лучшее из двух миров»: взять скорость колоночной СУБД и объединить её с богатой экосистемой и инструментарием PostgreSQL. Это позволяет разработчикам плавно мигрировать нагрузку, не переписывая приложение с нуля, и оставляет Postgres в качестве единой точки входа для данных.

Сравнительный анализ self-hosted S3-совместимых хранилищ

Mon, 08 Dec 2025 00:50:17 +0300

Четкое сравнение семи self-hosted S3-совместимых решений для хранения данных.

Оригинал тут: Команда RepoFlow. 9 августа 2025 г.

Локальное (self-hosted) объектное хранилище — это отличный выбор для разработчиков и команд, которые хотят иметь полный контроль над хранением и доступом к своим данным. Независимо от того, заменяете ли вы Amazon S3, размещаете внутренние файлы, создаете CI-конвейер или обслуживаете репозитории пакетов, уровень хранения может значительно повлиять на скорость и стабильность.

Мы протестировали семь популярных решений для объектного хранения, поддерживающих протокол S3. Цель состояла в том, чтобы сравнить их производительность в идентичных условиях, используя реальные операции загрузки и скачивания.

Тестируемые решения

Каждое из следующих решений было развернуто с помощью Docker на одном и том же сервере без монтирования томов и без специальной настройки:

`MinIO`
`Ceph`
`SeaweedFS`
`Garage`
`Zenko` (Scality Cloudserver)
`LocalStack`
`RustFS`

Скорость последовательного скачивания

Средняя скорость скачивания одного файла разного размера.

[Изображение: График скорости последовательного скачивания для малых файлов размером 50 КБ и 200 КБ. По оси Y — скорость в МБ/с, по оси X — размер файла. Сравниваются Garage, Localstack, Minio, Zenko, Ceph, RustFS, SeaweedFS.]

[Изображение: График скорости последовательного скачивания для больших файлов размером 10 МБ, 50 МБ, 100 МБ и 1 ГБ. По оси Y — скорость в МБ/с, по оси X — размер файла. Сравниваются те же решения.]

Скорость последовательной загрузки

Средняя скорость загрузки одного файла разного размера.

[Изображение: График скорости последовательной загрузки для малых файлов размером 50 КБ и 200 КБ. По оси Y — скорость в МБ/с, по оси X — размер файла. Сравниваются те же решения.]

[Изображение: График скорости последовательной загрузки для больших файлов размером 10 МБ, 50 МБ, 100 МБ и 1 ГБ. По оси Y — скорость в МБ/с, по оси X — размер файла. Сравниваются те же решения.]

Производительность листинга

Измеряет время, необходимое для получения списка всех 2000 тестовых объектов в бакете с использованием разных размеров страницы (100, 500 и 1000 результатов на запрос).

[Изображение: График производительности листинга. По оси Y — время в мс, по оси X — количество результатов на страницу (100, 500, 1000). Сравниваются те же решения.]

Скорость параллельной загрузки

Измеряет время, необходимое для параллельной загрузки нескольких файлов одинакового размера. Скорость загрузки рассчитывается по формуле:

(number of files × file size) ÷ total time

Скорость параллельной загрузки – файлы 1 МБ

[Изображение: График скорости параллельной загрузки файлов размером 1 МБ. По оси Y — скорость в МБ/с, по оси X — количество параллельных потоков (5, 10, 20). Сравниваются те же решения.]

Скорость параллельной загрузки – файлы 10 МБ

[Изображение: График скорости параллельной загрузки файлов размером 10 МБ. По оси Y — скорость в МБ/с, по оси X — количество параллельных потоков (5, 10, 20). Сравниваются те же решения.]

Скорость параллельной загрузки – файлы 100 МБ

[Изображение: График скорости параллельной загрузки файлов размером 100 МБ. По оси Y — скорость в МБ/с, по оси X — количество параллельных потоков (5, 10, 20). Сравниваются те же решения.]

Скорость параллельного скачивания

Измеряет время, необходимое для параллельного скачивания нескольких файлов одинакового размера. Скорость скачивания рассчитывается по формуле:

(number of files × file size) ÷ total time

Скорость параллельного скачивания – файлы 1 МБ

[Изображение: График скорости параллельного скачивания файлов размером 1 МБ. По оси Y — скорость в МБ/с, по оси X — количество параллельных потоков (5, 10, 20). Сравниваются те же решения.]

Скорость параллельного скачивания – файлы 10 МБ

[Изображение: График скорости параллельного скачивания файлов размером 10 МБ. По оси Y — скорость в МБ/с, по оси X — количество параллельных потоков (5, 10, 20). Сравниваются те же решения.]

Скорость параллельного скачивания – файлы 100 МБ

[Изображение: График скорости параллельного скачивания файлов размером 100 МБ. По оси Y — скорость в МБ/с, по оси X — количество параллельных потоков (5, 10, 20). Сравниваются те же решения.]

Как проводились тесты

Для каждого решения мы:

Загружали и скачивали файлы 7 различных размеров: 50 КБ, 200 КБ, 1 МБ, 10 МБ, 50 МБ, 100 МБ и 1 ГБ.
Повторяли каждую загрузку и скачивание 20 раз для получения стабильных средних значений.
Измеряли среднюю скорость загрузки и скачивания в мегабайтах в секунду (МБ/с).
Выполняли все тесты на одной и той же машине, используя стандартный Docker-контейнер для каждой системы хранения, без внешних томов, монтирования или кешей.

Все решения тестировались в одноузловой конфигурации для обеспечения согласованности. Хотя некоторые системы (например, `Ceph`) спроектированы для лучшей производительности в кластерной среде, мы использовали одинаковые условия для всех решений, чтобы гарантировать справедливое сравнение.

Заключительные мысли

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

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

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

Просто duckdb 🦆 ну красота же 😍

Mon, 24 Nov 2025 21:21:17 +0300

echo "cnt\n1\n2\n3" | duckdb -c "SELECT count(distinct cnt) FROM read_csv('/dev/stdin')"
┌─────────────────────┐
│ count(DISTINCT cnt) │
│        int64        │
├─────────────────────┤
│          3          │
└─────────────────────┘

echo "cnt\n1\n2\n3" | duckdb -c "SELECT sum(cnt) FROM read_csv('/dev/stdin')" 
┌──────────┐
│ sum(cnt) │
│  int128  │
├──────────┤
│    6     │
└──────────┘

А тут еще много всякой дополнительно утиной косметики https://query.farm/duckdb_extensions.html

Обработка логов Trino из Kafka с помощью Vector для удаления полей

Fri, 21 Nov 2025 01:27:16 +0300

В современных архитектурах данных, построенных на Kafka, часто возникает задача обработки или фильтрации потока событий “на лету”. Один из распространенных кейсов — удаление чувствительной информации из логов перед их передачей в следующую систему (например, в SIEM или систему долгосрочного хранения).

Kafka: https://hub.docker.com/r/apache/kafka
Vector: https://vector.dev/docs

Рассмотрим реальный пример:

Кластер Trino (или Presto) пишет подробные логи о каждом выполненном запросе в топик Kafka.
Эти логи содержат как полезные метаданные (пользователь, время, объем данных), так и полную текстовую версию самого SQL-запроса в поле, например, `query`.
Задача: Переложить эти логи в другой топик Kafka, но уже без** поля `query`, чтобы система-подписчик не имела доступа к потенциально конфиденциальной информации в текстах запросов.

Для решения этой задачи мы воспользуемся Vector — легковесным и сверхбыстрым инструментом для обработки данных.

План действий

Создадим два топика в Kafka: `trino-logs-raw` (для сырых логов) и `trino-logs-cleaned` (для очищенных).
Настроим Vector для чтения из первого топика, удаления поля `query` и всех служебных метаданных.
Настроим Vector на запись результата во второй топик.
Запустим всю цепочку в Docker и протестируем.

Шаг 1: Подготовка Kafka

Предполагается, что у вас уже запущен Kafka-брокер в Docker. На основе нашего примера, у вас есть контейнер с именем `broker1`, который является частью Docker-сети `minimal_iceberg_net`.

Откройте терминал и подключитесь к контейнеру Kafka, чтобы создать топики:

Создадим сеть 

docker network create my_net 

Запускаем брокер broker:

docker run -d \
  --name broker3 \
  --network=my_net \
  -p 8893:9092 \
  -e KAFKA_NODE_ID=3 \
  -e KAFKA_PROCESS_ROLES='broker,controller' \
  -e KAFKA_CONTROLLER_QUORUM_VOTERS='3@broker3:9093' \
  -e KAFKA_LISTENERS='INTERNAL://0.0.0.0:29092,EXTERNAL://0.0.0.0:9092,CONTROLLER://broker3:9093' \
  -e KAFKA_ADVERTISED_LISTENERS='INTERNAL://broker3:29092,EXTERNAL://localhost:8893' \
  -e KAFKA_LISTENER_SECURITY_PROTOCOL_MAP='INTERNAL:PLAINTEXT,EXTERNAL:PLAINTEXT,CONTROLLER:PLAINTEXT' \
  -e KAFKA_INTER_BROKER_LISTENER_NAME='INTERNAL' \
  -e KAFKA_CONTROLLER_LISTENER_NAMES='CONTROLLER' \
  -e KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR=1 \
  -e KAFKA_TRANSACTION_STATE_LOG_REPLICATION_FACTOR=1 \
  -e KAFKA_TRANSACTION_STATE_LOG_MIN_ISR=1 \
  apache/kafka:latest


docker exec --workdir /opt/kafka/bin/ -it broker3 sh

Теперь, находясь внутри контейнера, выполните команды:

# Создаем "сырой" топик для входящих логов Trino
./kafka-topics.sh --create --topic trino-logs-raw --bootstrap-server localhost:29092 --partitions 1 --replication-factor 1

# Создаем "чистый" топик для обработанных логов
./kafka-topics.sh --create --topic trino-logs-cleaned --bootstrap-server localhost:29092 --partitions 1 --replication-factor 1

*Обратите внимание: я использую внутренний порт брокера `29092`, который узнали ранее.*

Выйдите из контейнера командой `exit`.

Шаг 2: Конфигурация Vector

На вашей локальной машине создайте структуру папок:

vector-trino-processor/
└── config/
    └── vector.toml

Поместите в файл `vector.toml` следующую конфигурацию. Это сердце нашего решения.

# vector-trino-processor/config/vector.toml

# ==================================
#          ИСТОЧНИК ДАННЫХ
# ==================================
# Читаем сырые логи из Kafka
[sources.trino_raw_logs]
  type = "kafka"
  # Подключаемся к брокеру по имени контейнера и внутреннему порту
  bootstrap_servers = "broker3:29092"
  # Указываем, какой топик слушать
  topics = ["trino-logs-raw"]
  group_id = "vector-trino-cleaner"
  # Vector автоматически распарсит входящие сообщения как JSON
  decoding.codec = "json"

# ==================================
#             ТРАНСФОРМАЦИЯ
# ==================================
# Удаляем поле `query` и служебные метаданные Vector
[transforms.clean_trino_log]
  type = "remap"
  # Получаем данные от нашего источника
  inputs = ["trino_raw_logs"]
  # Скрипт на языке Vector Remap Language (VRL)
  source = '''
  # 1. Удаляем чувствительное поле "query" из лога.
  del(.query)

  # 2. Удаляем все служебные поля, которые Vector добавляет
  #    при чтении из Kafka, чтобы на выходе был чистый JSON.
  del(.headers)
  del(.message_key)
  del(.offset)
  del(.partition)
  del(.source_type)
  del(.timestamp)
  del(.topic)
  '''

# ==================================
#           ПРИЕМНИК ДАННЫХ
# ==================================
# Пишем очищенные логи в новый топик Kafka
[sinks.trino_cleaned_logs]
  type = "kafka"
  # Принимаем на вход данные, прошедшие трансформацию
  inputs = ["clean_trino_log"]
  bootstrap_servers = "broker3:29092"
  # Указываем топик для записи
  topic = "trino-logs-cleaned"
  # Кодируем итоговое событие обратно в JSON
  encoding.codec = "json"

Шаг 3: Запуск и Тестирование

Нам понадобится три терминала.

В Терминале №1 — Запустим Vector

Перейдите в папку `vector-trino-processor` и выполните команду:

docker run \
  -d \
  --name vector-processor \
  -v "$(pwd)/config:/etc/vector/" \
  --network=my_net \
  --rm \
  timberio/vector:latest-alpine --config /etc/vector/vector.toml

Эта команда:

Запускает контейнер Vector в фоновом режиме (`-d`).
Дает ему имя `vector-processor`.
Монтирует ваш локальный конфиг (`-v`).
Подключает его к той же сети, что и Kafka (`--network`).
Явно указывает, какой файл конфигурации использовать (`--config`).

В Терминале №2 — Симулируем отправку лога Trino

Запустим интерактивный Kafka-продюсер.

docker exec --workdir /opt/kafka/bin -it broker3 ./kafka-console-producer.sh --topic trino-logs-raw --bootstrap-server localhost:29092

Теперь вставьте в этот терминал JSON, имитирующий лог от Trino, и нажмите Enter:

{"user":"yuriy","source":"trino-cli","queryId":"20231120_123456_00001_abcde","query":"SELECT * FROM sensitive_table a JOIN other_table b ON a.id = b.id WHERE a.credit_card = '1234-5678-9012-3456'","state":"FINISHED"}

В Терминале №3 — Проверяем результат

Запустим Kafka-консьюмер, который будет слушать очищенный топик `trino-logs-cleaned`.

docker exec --workdir /opt/kafka/bin -it broker3 ./kafka-console-consumer.sh --topic trino-logs-cleaned --bootstrap-server localhost:29092 --from-beginning

Вы практически мгновенно увидите результат работы Vector — тот же самый лог, но уже без поля `query`:

{"user":"yuriy","source":"trino-cli","queryId":"20231120_123456_00001_abcde","state":"FINISHED"}

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

dbt открывает исходный код MetricFlow: Управляемые метрики для AI и аналитики

Sat, 01 Nov 2025 01:03:55 +0300

Компания dbt Labs объявила о важном изменении в своей стратегии: `MetricFlow`, ключевая технология, лежащая в основе `dbt Semantic Layer`, становится полностью открытой. Проект переводится под лицензию Apache 2.0, что позволяет любому использовать, изменять и встраивать его в свои продукты. Это стратегический шаг, направленный на создание единого отраслевого стандарта для определения бизнес-метрик, особенно в свете бурного развития AI-систем.

Оригинал тут: https://www.getdbt.com/blog/open-source-metricflow-governed-metrics
А гит тут: https://github.com/dbt-labs/metricflow

Еще кстати есть https://github.com/memiiso/opendbt ( Make dbt great again! :) Может они сольются с метриками, интересно.

Проблема: почему семантический слой стал критически важен

Концепция семантического слоя, который служит промежуточным слоем для определения бизнес-логики (метрик, измерений, связей), не нова. Она уже много лет используется в BI-системах для обеспечения согласованности отчетов. Однако с появлением больших языковых моделей (LLM) и инструментов в стиле “Chat with your data” проблема вышла на новый уровень.

Когда AI-агент или LLM пытается ответить на вопрос, обращаясь напрямую к базе данных, он вынужден самостоятельно генерировать SQL-запрос. При этом модель “угадывает”, какие таблицы нужно соединить (`JOIN`), как правильно отфильтровать данные, какую использовать гранулярность по времени и какие оконные функции применить.

Проблемы такого подхода:

Несогласованность: Две разные модели (или даже одна и та же, но с другим запросом) могут сгенерировать разный SQL для расчета, казалось бы, одной и той же метрики. Это приводит к разным цифрам в отчетах.
Ошибки: LLM может не знать о тонкостях бизнес-логики, например, о том, что при расчете выручки нужно учитывать возвраты или использовать специальный финансовый календарь.
Потеря доверия: Когда пользователи получают противоречивые или неверные данные, доверие ко всей системе аналитики быстро падает.

Метрики не должны быть вероятностными, зависящими от “догадок” LLM при каждом вызове. Они должны быть детерминированными.

`MetricFlow` решает именно эту задачу.

Что такое MetricFlow и как он работает

`MetricFlow` — это движок, который преобразует семантические определения бизнес-понятий в готовый к выполнению и оптимизированный SQL-код. Аналитик один раз определяет метрику “Валовая маржа” на языке `MetricFlow`, и после этого любая система (BI-инструмент, AI-агент, Python-скрипт) может запросить эту метрику по имени, будучи уверенной, что получит корректный и одинаковый результат.

Ключевые изменения и их значение

Лицензия Apache 2.0: Это одно из главных нововведений. Apache 2.0 — это разрешительная лицензия, которая позволяет другим компаниям свободно встраивать `MetricFlow` в свои коммерческие и открытые продукты. Это снимает барьеры для принятия технологии и способствует ее распространению как стандарта.
Сотрудничество с Open Semantic Interchange (OSI): dbt Labs будет развивать `MetricFlow` совместно с такими партнерами, как Snowflake и Salesforce, в рамках инициативы OSI. Цель — создать единый стандарт для семантической совместимости между разными платформами, чтобы метрики, определенные один раз, одинаково работали во всех инструментах.

Как MetricFlow обеспечивает надежность AI

`MetricFlow` предоставляет открытый стандарт для метаданных и расширяемый движок, который превращает намерение (“покажи валовую маржу”) в SQL-запрос для хранилища данных.

Пример работы:

Предположим, пользователь задает AI-агенту вопрос:

“Покажи валовую маржу (%) по месяцам за прошлый квартал для Северной Америки (за вычетом скидок и возвратов, по финансовому календарю).”

Без семантического слоя LLM пришлось бы конструировать сложный запрос с нуля. С `MetricFlow` процесс выглядит так:

Агент распознает намерение и запрашивает у `MetricFlow` метрику `gross_margin_pct` с нужными измерениями (`region`, `fiscal_month`) и фильтрами.
`MetricFlow`, на основе заранее созданных определений, строит план запроса:
- Находит нужные таблицы: `orders`, `discounts`, `returns`, `cogs` (себестоимость).
- Применяет правильные `JOIN` между ними.
- Применяет фильтр по региону (`North America`).
- Группирует данные по месяцам финансового, а не календарного, года.
- Рассчитывает числитель (выручка) и знаменатель (себестоимость) с учетом того, что популяция данных для них должна быть одинаковой.
- Вычисляет итоговое соотношение.
`MetricFlow` компилирует этот план в оптимизированный SQL-запрос, специфичный для диалекта конкретного хранилища (Snowflake, BigQuery, Databricks и т.д.).
Запрос выполняется в хранилище, и результат возвращается пользователю.

При этом весь сгенерированный SQL доступен для проверки, что обеспечивает прозрачность и объяснимость вычислений.

Основные возможности движка:

Единое определение, выполнение где угодно: Метрики и измерения определяются один раз, а `MetricFlow` компилирует их в SQL для разных диалектов.
Оптимизация производительности: Движок строит эффективные запросы, чтобы избежать лишних сканирований и снизить нагрузку на хранилище данных.
Поддержка сложных вычислений: `MetricFlow` из коробки обрабатывает сложные соединения, оконные функции, расчеты по когортам и полуаддитивные метрики (например, остатки на счетах, которые нельзя просто суммировать по времени).

`MetricFlow` vs. `dbt Semantic Layer`

Важно понимать различие между двумя компонентами:

`MetricFlow` — это движок с открытым исходным кодом для определения и вычисления метрик. Это “сердце” системы, которое выполняет всю сложную работу по генерации SQL.
`dbt Semantic Layer` — это коммерческий продукт dbt Labs, построенный *поверх* `MetricFlow`. Он добавляет функциональность корпоративного уровня:
- Управление доступом (`RBAC`).
- Версионирование определений метрик.
- Аудит и отслеживание происхождения данных (`lineage`).
- Надежные API и коннекторы для интеграции с BI- и AI-инструментами.

Таким образом, `MetricFlow` становится общедоступным строительным блоком, а `dbt Semantic Layer` — готовым решением для его безопасного и управляемого внедрения в компаниях.

Итог

dbt Labs сделала `MetricFlow` (движок для расчета метрик) полностью открытым под лицензией Apache 2.0. Это позволяет всем желающим использовать его без ограничений.
Главная цель — создать открытый стандарт для определения бизнес-метрик. Это особенно актуально для AI-систем, которые часто ошибаются при самостоятельной генерации SQL.
`MetricFlow` позволяет AI и BI-инструментам запрашивать данные по имени метрики (например, `revenue`), получая детерминированный и корректный SQL-запрос. Это повышает надежность и согласованность данных.
Этот шаг способствует совместимости инструментов (`interoperability`) и снижает зависимость от конкретного вендора (`vendor lock-in`). Метрики, определенные один раз, будут работать одинаково в разных системах.
Коммерческий продукт `dbt Semantic Layer` продолжит развиваться как решение для управления жизненным циклом метрик в корпоративной среде (безопасность, контроль версий, аудит).

Сравнение Apache Iceberg, Delta Lake и Apache Hudi: Глубокий анализ (2025)

Sat, 01 Nov 2025 00:53:55 +0300

С ростом популярности архитектуры Data Lakehouse усилился интерес к трём основным открытым проектам в этой области: Apache Hudi, Delta Lake и Apache Iceberg. Все три технологии продолжают активно развиваться, и в этой статье представлено актуальное сравнение их возможностей по состоянию на октябрь 2025 года.

Оригинал тут: https://www.onehouse.ai/blog/apache-hudi-vs-delta-lake-vs-apache-iceberg-lakehouse-feature-comparison

Примечание: Если выбор формата вызывает сложности, обратите внимание на проект Apache XTable (Incubating), который обеспечивает интероперабельность между Hudi, Delta и Iceberg, позволяя использовать несколько форматов одновременно.

Сравнение возможностей

Функциональность записи

Функция	Apache Hudi (v1.0.2)	Delta Lake (v4.0.0)	Apache Iceberg (v1.10.0)
ACID-транзакции	✅	✅	✅
Copy-on-Write	✅	✅	✅
Merge-on-Read	✅ Полнофункциональный	❌ Векторы удалений (эксперимент.)	❌ Векторы удалений (огранич.)
Эффективная bulk-загрузка	✅ Bulk_Insert	✅	✅
Индексирование	✅ 8+ типов индексов	❌ Bloom-фильтр проприетарный	✅ Метаданные для статистики
Частичные обновления	✅ Partial Updates	❌	❌
Миграция таблиц	✅ Bootstrap	✅ Convert to Delta	❌
Управление конкуренцией	✅ OCC, MVCC, NBCC	✅ OCC	✅ OCC
Неблокирующая конкуренция	✅ NBCC	❌ OCC с перезапуском	❌ OCC с перезапуском
Менеджеры блокировок	✅ ФС, DynamoDB, Hive, Zookeeper	✅ Только внешний DynamoDB	✅ Каталог или внешние провайдеры
Дедупликация	✅ Ключи, Precombine	❌ Нет первичных ключей	❌ Нет первичных ключей
Зависимость от каталога	❌ Не требуется	❌ Не требуется	✅ Обязателен

Ключевые отличия:

Hudi предлагает наиболее продвинутые механизмы управления конкуренцией, включая неблокирующий контроль (NBCC)
Только Hudi поддерживает настоящий Merge-on-Read без компромиссов производительности
Hudi предоставляет встроенные инструменты для дедупликации через первичные ключи

Метаданные таблиц

Функция	Apache Hudi	Delta Lake	Apache Iceberg
Масштабируемость метаданных	✅ LSM-дерево + HFile (100x ускорение)	❌ Parquet чекпойнты (медленно)	❌ Avro манифесты (медленно)
Управление индексами	✅ Асинхронное многомодальное	❌	❌
Эволюция схемы	✅ Добавление, переупоряд., удаление	✅	✅
Эволюция партиций	✅ Кластеризация + индексы выражений	✅ Эволюция партиций	❌
Первичные ключи	✅	❌ Только в проприетарной версии	❌
Статистика столбцов	✅ HFile (до 50x ускорение)	✅ Parquet чекпойнт	✅ Avro манифест

Важные особенности:

Hudi использует оптимизированный формат HFile для метаданных, что значительно ускоряет поиск
Только Hudi поддерживает настоящие первичные ключи как в реляционных БД
Hudi предлагает более гибкий подход к партиционированию через кластеризацию

Функциональность чтения

Функция	Apache Hudi	Delta Lake	Apache Iceberg
Time Travel	✅	✅	✅
Merge-on-Read запросы	✅ Snapshot Query	❌ Сложная поддержка	✅ Все запросы мержат векторы удалений
Инкрементальные запросы	✅ + CDC запросы	✅ CDF (эксперимент.)	❌ Только аппенды
CDC запросы	✅ + before/after images	❌	❌
Вторичные индексы	✅	❌	❌
Предикаты для пропуска данных	✅ Индексы выражений	✅ Логические предикаты	✅ Трансформации таблиц

Сервисы таблиц

Функция	Apache Hudi	Delta Lake	Apache Iceberg
Авторазмер файлов	✅	✅	❌ Ручное управление
Компактизация	✅ Управляемая	❌ 2-этапное обслуживание	❌ Ручное обслуживание
Очистка	✅ Управляемая	❌ VACUUM вручную	❌ Ручное удаление снапшотов
Кластеризация	✅ Авто + Z-order/Hilbert	❌ Z-order в OSS, авто – проприетар.	❌ Z-order вручную

Поддержка экосистемы

Все три формата имеют широкую поддержку в экосистеме данных:

Apache Spark, Flink, Trino, DBT – полная поддержка чтения/записи во всех форматах
Kafka Connect – Hudi и Iceberg имеют нативную поддержку, Delta – только проприетарную
Облачные платформы (AWS, GCP, Azure) – все три формата поддерживаются с некоторыми ограничениями
Snowflake – нативная поддержка Iceberg, Hudi через XTable

Производительность: TPC-DS бенчмарки

Согласно независимым тестам:

Hudi и Delta показывают сопоставимую производительность
Iceberg consistently отстаёт по скорости выполнения запросов

Важно: При сравнении производительности учитывайте, что Hudi по умолчанию оптимизирован для mutable-нагрузок (upsert), в то время как Delta и Iceberg – для append-only. Для честного сравнения используйте `bulk-insert` режим в Hudi.

Ключевые дифференцирующие возможности

Инкрементальные пайплайн

Hudi предлагает наиболее зрелую поддержку инкрементальной обработки с трекингом всех изменений (вставки, обновления, удаления) и предоставлением их в виде change streams. Это позволяет строить эффективные ETL-пайплайны без перевычисления полных наборов данных.

Управление конкуренцией

В то время как все три системы поддерживают оптимистический контроль конкуренции (OCC), только Hudi предлагает:

Неблокирующий контроль конкуренции (NBCC)
Файл-уровневую гранулярность блокировок
Возможность работы с асинхронными сервисами таблиц без остановки записи

Merge-on-Read

Только Hudi предоставляет полнофункциональный Merge-on-Read, который позволяет:

Балансировать между производительностью записи и чтения
Использовать row-ориентированные форматы для стриминга и column-ориентированные для аналитики
Выполнять компактизацию асинхронно

Кластеризация vs Эволюция партиций

Iceberg: Partition Evolution – изменение схемы партиционирования для новых данных
Hudi: Гибридный подход – coarse-grained партиционирование + fine-grained кластеризация с возможностью эволюции без перезаписи данных

Многомодальное индексирование

Только Hudi предлагает асинхронную подсистему индексирования, поддерживающую:

Bloom, hash, bitmap, R-tree индексы
10-100x ускорение point lookup запросов
10-30x общее ускорение запросов в реальных нагрузках

Реальные кейсы использования

Peloton

Увеличение частоты ингестии с 1 раза в день до каждых 10 минут
Снижение времени выполнения снапшот-заданий с 1 часа до 15 минут
Экономия затрат через оптимизацию использования EMR-кластеров

ByteDance/TikTok

Обработка таблиц объемом 400+ PB
Ежедневный прирост данных на уровне PB
Пропускная способность >100 GB/s на таблицу
Выбор Hudi из-за открытости экосистемы и поддержки глобальных индексов

Walmart

Использование Merge-on-Read для снижения задержек
Нативная поддержка удалений для GDPR/CCPA compliance
Row versioning для обработки out-of-order данных

Инновации сообщества

Многие ключевые функции data lakehouse были впервые реализованы в Hudi:

Инновация Hudi	Год	Аналог в других проектах
Транзакционные обновления	2017	Delta OSS (2019)
Merge-on-Read	2017	Iceberg (2021)
Инкрементальные запросы	2017	Delta Change Feed (2022)
Z-order/Hilbert кривые	2021	Delta OSS (2022)
Многомодальное индексирование	2022	❌ Нет аналогов
Контроль конкуренции без блокировок	2024	❌ Нет аналогов

Заключение

Критерии выбора

Выбирайте Apache Hudi если:

Ваши workload’ы содержат значительное количество обновлений и удалений
Требуется низкая задержка от конца в конец
Нужны продвинутые возможности управления конкуренцией
Важна производительность point lookup запросов
Требуется гибкое управление layout данных через кластеризацию

Рассмотрите Delta Lake если:

Вы используете экосистему Databricks
Workload’ы преимущественно append-only
Достаточно базовых возможностей управления конкуренцией

Apache Iceberg может подойти если:

Основная задача – работа с очень большими объемами данных в cloud storage
Требуется скрытое партиционирование с эволюцией
Workload’ы в основном аналитические с минимальными обновлениями

Итоговые рекомендации

Для зрелых production-нагрузок с frequent updates, high concurrency и low latency требованиями Apache Hudi предлагает наиболее полный набор возможностей.

Не ограничивайтесь сравнением “галочек” – оценивайте производительность на своих данных и workload’ах.

Рассмотрите Apache XTable если невозможно определиться с одним форматом или требуется интероперабельность между системами.

Учитывайте roadmap проекта – Hudi продолжает лидировать в инновациях, что может быть важно для долгосрочных инвестиций.

Технологии data lakehouse продолжают быстро развиваться, и выбор должен основываться на конкретных требованиях ваших use cases, а не только на текущем состоянии функциональности.

Искусство скорости: Руководство по оптимизации для аналитики в Data Lakehouse с DuckDB

Tue, 09 Sep 2025 01:48:12 +0300

DuckDB завоевал огромную популярность как “SQLite для аналитики”. Это невероятно быстрый, встраиваемый, колоночный движок, который не требует отдельного сервера. Однако его мощь по-настоящему раскрывается, когда он получает доступ к данным эффективно. Просто натравить DuckDB на петабайтный дата-лейк без подготовки — это рецепт для медленных запросов и высоких затрат.

Как же построить мост между огромным хранилищем данных и молниеносной интерактивной аналитикой, которую обещает DuckDB?

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

Большая картина: Подготовка данных с помощью Trino

Данные в вашем Lakehouse не появляются из ниоткуда. Они поступают из операционных баз данных, потоков событий (Kafka), логов и десятков других источников. Прежде чем DuckDB сможет их эффективно запросить, эти данные нужно собрать, очистить, трансформировать и, что самое важное, организовать в надежный и производительный формат.

Здесь на сцену выходит Trino (ранее известный как PrestoSQL).

Что такое Trino? Это мощный распределенный SQL-движок, созданный для выполнения запросов к гетерогенным источникам данных. Его суперсила — способность “на лету” объединять данные из PostgreSQL, Kafka, Hive, MySQL и многих других систем.

Роль Trino в Lakehouse: В современной архитектуре Trino часто выступает в роли “фабрики данных”. Он выполняет тяжелую работу по ETL/ELT (Extract, Transform, Load), подготавливая данные для аналитических инструментов вроде DuckDB.

Типичный сценарий использования:

Источники: У вас есть события о прослушивании треков в Kafka, а информация о пользователях — в базе данных PostgreSQL.
Задача: Создать единую, денормализованную таблицу Iceberg для аналитики.
Решение с Trino: Вы настраиваете в Trino коннекторы к Kafka и PostgreSQL. Затем вы запускаете периодический SQL-запрос, который читает данные из обоих источников, объединяет их и записывает результат в новую или существующую таблицу Iceberg.

-- Этот запрос выполняется в Trino, а не в DuckDB!
    INSERT INTO iceberg_catalog.analytics.daily_user_activity
    SELECT
        u.user_id,
        u.country,
        e.event_timestamp,
        e.track_id,
        e.duration_ms
    FROM
        postgres_catalog.public.users u
    JOIN
        kafka_catalog.raw_data.listen_events e ON u.user_id = e.user_id
    WHERE
        e.event_date = CURRENT_DATE;

Как отмечается в одном из руководств, именно такой `INSERT INTO ... SELECT ...` является типичным способом перемещения данных в Iceberg с помощью Trino.

Итог: Trino работает “глубоко в машинном отделении” вашего Lakehouse. Он берет на себя тяжелые, распределенные задачи по преобразованию данных, а DuckDB получает на вход уже чистые, структурированные и оптимизированные для чтения таблицы Iceberg.

Теперь, когда данные готовы, давайте рассмотрим, как их лучше всего потреблять.

Подход 1: Табличные форматы (Iceberg) — Читайте только то, что нужно

Это самый продвинутый и рекомендуемый подход для серьезной аналитики, особенно в serverless-архитектуре.

Как это работает: Вместо того чтобы работать с “россыпью” файлов Parquet, вы работаете с логической таблицей, управляемой Apache Iceberg. Расширение `iceberg` в DuckDB использует метаданные Iceberg для интеллектуального отсечения ненужных файлов (partition pruning) и блоков данных (predicate pushdown), читая с диска минимально необходимый объем информации.
Архитектура: `Данные на S3 -> Trino (ETL) -> Таблица Iceberg -> DuckDB (Аналитика)`

Назначение и сценарии использования:

Serverless-аналитика: Основной кейс. AWS Lambda или Google Cloud Function, оснащенная DuckDB, выполняет SQL-запрос к озеру данных. Благодаря Iceberg, функция читает всего несколько мегабайт вместо гигабайт, что делает ее выполнение быстрым (<1 сек) и дешевым.
Локальная разработка и BI: Аналитик данных или инженер открывает Jupyter Notebook на своем ноутбуке. С помощью DuckDB он подключается напрямую к производственному Lakehouse и выполняет исследовательский анализ, не создавая копий данных и не перегружая кластеры.
Встраиваемая аналитика: Backend-сервис на Python или Node.js, которому нужно быстро отвечать на аналитические вопросы (например, “показать статистику пользователя за последний месяц”). Он использует DuckDB для прямого запроса к Lakehouse без обращения к промежуточной базе данных.

Подход 2: RPC-стриминг (Apache Arrow Flight) — Прямой канал к данным

Иногда вам не нужна вся мощь Iceberg, а нужно просто эффективно выполнить запрос на удаленном экземпляре DuckDB и получить результат.

Как это работает: Вы запускаете сервер, который инкапсулирует DuckDB. Клиент и сервер общаются по протоколу Arrow Flight — высокопроизводительному фреймворку для стриминга колоночных данных в формате Apache Arrow без затрат на сериализацию.
Архитектура: `Клиент -> Arrow Flight RPC -> Сервер с DuckDB -> Данные (любой источник)`

Назначение и сценарии использования:

Интерактивные дашборды: Веб-интерфейс (React, Vue) должен строить графики в реальном времени. Он отправляет SQL-запросы на Flight-сервер и получает данные для отрисовки практически мгновенно, без “тяжести” HTTP/JSON.
API-шлюз для данных: Централизация доступа к данным для множества внутренних микросервисов. Вместо того чтобы каждый сервис имел свои креды и логику подключения к БД, они обращаются к единому, стабильному Flight API.
Кросс-языковое взаимодействие: Сервис на Java должен получить результаты вычислений из BI-системы, построенной на Python и DuckDB. Arrow Flight обеспечивает эффективный и стандартизированный мост между ними.

Подход 3: “API поверх данных” (ROAPI & DataFusion) — Декларативная альтернатива

Что, если вам не нужна вся гибкость SQL, а нужен стандартный REST или GraphQL API поверх ваших данных без строчки кода? Здесь на сцену выходит ROAPI.

Как это работает: ROAPI — это инструмент, который автоматически создает API, читая конфигурационный YAML-файл, где вы описываете ваши данные (Parquet, CSV и т.д.). Под капотом он использует Apache Arrow DataFusion, движок запросов, написанный на Rust, являющийся идейным братом DuckDB.
Архитектура: `Клиент (HTTP/GraphQL) -> ROAPI Server -> Данные (файлы)`

Назначение и сценарии использования:

Быстрое прототипирование: Вам нужно за 5 минут предоставить команде фронтенда API для нового набора данных. Вы пишете 10 строк в YAML, запускаете ROAPI — и API готов.
Простые микросервисы данных: Сервис, единственная задача которого — раздавать данные из файла с поддержкой фильтрации и пагинации. ROAPI делает это из коробки, избавляя вас от написания рутинного кода на FastAPI или Express.js.
Дата-фиды для внешних систем: Предоставление стандартизированного API для партнерской системы, которая умеет работать с REST, но не умеет читать Parquet.

и еще немного про DuckDB

1. Читайте меньше данных (Золотое правило)

Используйте Iceberg: Это лучший способ.
Проекция колонок (`SELECT col1, col2...`): Никогда не используйте `SELECT *`.
Проталкивание предикатов (`WHERE`): Пишите максимально конкретные фильтры. DuckDB автоматически проталкивает их в сканеры Parquet и Iceberg. Используйте `EXPLAIN` для проверки того, что фильтры применяются на этапе сканирования.

2. Оптимизация SQL-запросов

Материализация промежуточных результатов: Если вы делаете несколько агрегаций над одним и тем же отфильтрованным срезом, сохраните его во временную таблицу с помощью `CREATE TEMP TABLE ... AS`.
Используйте `COPY` для массовой загрузки: При загрузке данных в DuckDB `COPY` на порядки быстрее, чем `INSERT`.
Предварительная агрегация: Для сверхбольших данных создавайте “витрины” с помощью Trino (см. выше) или DuckDB, а запросы стройте уже по ним.

3. Настройка окружения DuckDB

Управление памятью: `SET memory_limit = ‘1GB’;` — обязательная настройка в Lambda и контейнерах.
Параллелизм: `SET threads = 4;` — адаптируйте количество потоков под vCPU вашего окружения.
Настройка `httpfs` для S3: Настройте регион (`s3_region`), креды и включите кэширование метаданных, чтобы не перечитывать их при каждом запуске. ( Это комьюнити дополнение -cache_httpfs, см. ниже “Проблема Шторм” )

Еще вот тут можно почитать: https://duckdb.org/docs/stable/guides/performance/how_to_tune_workloads

Заключение: Какой подход выбрать?

Выбор архитектуры зависит от вашей задачи. Каждая из них занимает свою нишу в стеке современной инженерии данных.

Подход	Ключевая технология	Когда использовать
Табличный формат	Trino (Подготовка) + DuckDB/Iceberg (Потребление)	Стандарт для Lakehouse. Нужна строгая структура, надежность и максимальная производительность для аналитических SQL-запросов от различных инструментов.
RPC-стриминг	DuckDB + Arrow Flight	Нужен быстрый интерактивный SQL-доступ к удаленному экземпляру DuckDB, например, для дашборда или кастомного клиента.
API поверх данных	ROAPI + DataFusion	Нужно быстро и без кода поднять стандартный `REST`/`GraphQL` API поверх наборов данных для прототипирования или простых микросервисов.

Проблема Шторм из GET-запросов к S3

Давайте представим, что вы выполняете запрос к таблице Iceberg или просто к набору из 1000 файлов Parquet на S3:

SELECT count(*)
FROM read_parquet('s3://my-bucket/data/*.parquet')
WHERE event_type = 'click';

Чтобы выполнить этот запрос с максимальной эффективностью (с “проталкиванием предиката”), DuckDB должен сделать следующее, *прежде чем* читать основные данные:

Получить список всех 1000 файлов.
Для каждого из 1000 файлов прочитать его метаданные (футер). Футер Parquet-файла — это небольшой блок в конце файла, содержащий схему и, что самое важное, статистику по колонкам (min/max значения).
Проанализировав футер, DuckDB понимает, может ли в этом файле вообще содержаться `event_type = ‘click’`. Если статистика говорит, что в файле есть только типы `’view’` и `’purchase’`, утка его пропустит.

Проблема в том, что для чтения футера каждого файла DuckDB должен отправить отдельный HTTP `GET` запрос с указанием диапазона байт (range request) к S3. То есть, один SQL-запрос порождает 1000+ мелких HTTP-запросов. Это может быть медленно и может быть дорого, так как в S3 вы платите за каждый `GET` запрос.

Кэширование метаданных решает именно эту проблему: оно сохраняет результаты этих мелких запросов на локальный диск, чтобы при повторном обращении к тем же файлам DuckDB брал их из локального кэша, а не летел снова в S3.

Решение: Комьюнити-расширение `cache_httpfs`

Для реализации постоянного, дискового кэширования в DuckDB используется специальное комьюнити-расширение `cache_httpfs`. Оно работает как “обертка” над стандартным `httpfs`.

Основная идея: Вы говорите DuckDB использовать `cache_httpfs` в качестве клиента для HTTP-запросов. Этот клиент сначала проверяет, нет ли уже нужного блока данных (например, футера Parquet-файла) в локальном кэше. Если есть — отдает его мгновенно. Если нет — идет в S3, скачивает блок, сохраняет его в кэш и отдает DuckDB.

Вот как это настроить:

Шаг 1: Установка и загрузка расширений

Вам понадобятся три расширения: `httpfs` (для работы с S3), `cache_httpfs` (для кэширования) и, если вы работаете с Iceberg, то и `iceberg`.

INSTALL httpfs;
INSTALL cache_httpfs;
LOAD httpfs;
LOAD cache_httpfs;

Шаг 2: Активация кэширующего клиента

Это ключевой шаг. Вы должны указать DuckDB использовать `cache_httpfs` для всех HTTP-операций.

SET httpfs_client = 'cached_httpfs';

Шаг 3: Настройка пути к кэшу (критически важно для Serverless)

По умолчанию `cache_httpfs` сохраняет кэш в директорию `~/.cache/duckdb/`. Это хорошо работает на локальной машине, но в serverless-окружениях (AWS Lambda, Cloud Functions) эта папка либо недоступна для записи, либо является эфемерной.

В serverless-среде единственное гарантированно доступное для записи место — это директория `/tmp`.

SET cache_httpfs_cache_path = '/tmp/duckdb_cache';

Этот кэш в `/tmp` будет “жить” между “теплыми” вызовами вашей Lambda-функции. Если одна и та же функция вызывается несколько раз подряд, второй и последующие вызовы будут использовать уже заполненный кэш, что кардинально ускорит выполнение запросов к одним и тем же данным.

Полный пример конфигурации (Python)

import duckdb

# Подключаемся к базе данных
con = duckdb.connect()

# Устанавливаем и загружаем расширения
con.execute("INSTALL httpfs;")
con.execute("INSTALL cache_httpfs;")
con.execute("LOAD httpfs;")
con.execute("LOAD cache_httpfs;")

# --- Настройка S3 и кэша ---

# 1. Настройте креды для S3 (если не используются IAM-роли)
# con.execute("SET s3_access_key_id='YOUR_KEY';")
# con.execute("SET s3_secret_access_key='YOUR_SECRET';")
con.execute("SET s3_region='us-east-1';")

# 2. Активируем кэширующий http-клиент
con.execute("SET httpfs_client = 'cached_httpfs';")

# 3. Указываем путь к директории кэша (обязательно для serverless)
con.execute("SET cache_httpfs_cache_path = '/tmp/duckdb_http_cache';")

# --- Выполняем запрос ---

# Первый запуск этого запроса будет медленнее,
# так как он заполнит кэш метаданными файлов.
result1 = con.execute("SELECT count(*) FROM 's3://my-bucket/data/*.parquet'").fetchone()
print(f"Первый запуск: {result1[0]}")

# Второй запуск будет на порядки быстрее,
# так как все метаданные будут прочитаны из локального кэша в /tmp.
result2 = con.execute("SELECT count(*) FROM 's3://my-bucket/data/*.parquet'").fetchone()
print(f"Второй запуск (с кэшем): {result2[0]}")

Сравнение: Встроенный кэш vs `cache_httpfs`

Стоит отметить, что стандартный `httpfs` тоже имеет небольшой *внутренний, оперативный кэш*, но его возможности ограничены.

Параметр	Встроенный кэш `httpfs`	Расширение `cache_httpfs`
Тип	Внутренний, в памяти	Явный, на диске
Жизненный цикл	Живет в рамках одного соединения (connection). При переподключении кэш пуст.	Живет между сессиями и процессами. Сохраняется на диске до очистки.
Назначение	Ускорение повторных запросов в одной и той же длительной сессии.	Радикальное ускорение для любых повторных запросов, особенно в serverless (warm starts) и при локальной разработке.
Активация	Включен по умолчанию	Требует `SET httpfs_client = ‘cached_httpfs’;`
Настройка	Не настраивается	Настраивается путь (`cache_httpfs_cache_path`) и максимальный размер.

Для серьезной работы с данными на S3, особенно в serverless-архитектуре, использование расширения `cache_httpfs` является приятным дополнением и зачастую обязательным. Это та самая “серебряная пуля”, которая убирает узкое место в виде задержек сети и большого количества API-вызовов к облачному хранилищу.

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

pic. Krenskiy Dmitriy

Новая эра трансформации данных: dbt против Bruin и aaC

Sat, 23 Aug 2025 16:04:02 +0300

В мире данных произошла тихая, но фундаментальная революция. На смену традиционному подходу ETL (Extract, Transform, Load), где данные преобразовывались до загрузки в хранилище, пришла новая парадигма — ELT (Extract, Load, Transform). Благодаря мощности современных облачных хранилищ (таких как Snowflake, BigQuery, Databricks, Starburst\Trino) стало выгоднее сначала загружать сырые данные, а уже затем трансформировать их непосредственно в хранилище.

Этот сдвиг породил потребность в инструментах, которые специализируются на последнем шаге — трансформации (T). Именно в этой нише dbt (data build tool) стал безоговорочным лидером, но на его поле появляются и новые сильные игроки, такие как Bruin. Давайте разберемся, что это за инструменты, какой подход они олицетворяют и в чем их ключевые различия.

Подход «Аналитика как код»

И dbt, и Bruin являются яркими представителями движения “Analytics as Code” (аналитика как код). Это не просто инструменты, а целая философия, которая переносит лучшие практики разработки программного обеспечения в мир аналитики данных.

Основные принципы и идеи:

Версионирование: Все трансформации данных описываются в виде кода (в основном SQL), который хранится в системе контроля версий, такой как Git. Это позволяет отслеживать изменения, совместно работать и откатываться к предыдущим версиям.
Модульность и переиспользование (DRY – Don’t Repeat Yourself): Сложные трансформации разбиваются на небольшие, логически завершенные модели, которые могут ссылаться друг на друга. Это делает код чище, понятнее и позволяет повторно использовать уже написанную логику.
Тестирование: Код трансформаций должен быть протестирован. Инструменты позволяют автоматически проверять качество данных после преобразований: на уникальность ключей, отсутствие `NULL` значений, соответствие заданным условиям и т.д.
Документация и прозрачность: Процесс трансформации становится самодокументируемым. Инструменты могут автоматически генерировать документацию и строить графы зависимостей моделей (data lineage), показывая, как данные текут и преобразуются от источника к конечному виду. element61.be
CI/CD (Continuous Integration / Continuous Deployment): Изменения в коде трансформаций могут автоматически тестироваться и разворачиваться в продуктивную среду, что значительно ускоряет циклы разработки.

Решаемые проблемы:

“Черные ящики” ETL: Заменяют сложные, трудноподдерживаемые и непрозрачные ETL-процессы на понятный и документированный код.
Рассинхронизация команд: Стирают границы между инженерами данных и аналитиками, позволяя аналитикам, владеющим SQL, самостоятельно создавать надежные модели данных.
Низкое качество данных: Встроенные механизмы тестирования помогают обеспечить надежность и согласованность данных.

---

dbt (data build tool): Золотой стандарт трансформации

dbt — это инструмент с открытым исходным кодом, который позволяет аналитикам и инженерам трансформировать данные в их хранилищах с помощью простых SQL-запросов. Важно понимать, что dbt не извлекает и не загружает данные. Он специализируется исключительно на шаге “T” в ELT vutr.substack.com. dbt git.

Он работает как компилятор и исполнитель: вы пишете модели данных в `.sql` файлах, используя шаблонизатор Jinja для добавления логики (циклы, условия, макросы). Затем dbt компилирует этот код в чистый SQL и выполняет его в вашем хранилище данных element61.be.

Плюсы dbt

Огромное сообщество и экосистема: dbt стал де-факто стандартом индустрии. Существует огромное количество статей, курсов, готовых пакетов (библиотек) и экспертов.
Фокус на SQL: Низкий порог входа для аналитиков, которые уже знают SQL. Это демократизирует процесс трансформации данных.
Мощное тестирование и документирование: Встроенные команды для тестирования данных и автоматической генерации проектной документации с графом зависимостей.
Зрелость и надежность: Инструмент проверен временем и используется тысячами компаний по всему миру.
Гибкость: Благодаря шаблонизатору Jinja можно создавать очень сложные и переиспользуемые макросы, адаптируя dbt под любые нужды.

Минусы dbt

Только трансформация: dbt не занимается извлечением (E) и загрузкой (L). Для этого вам понадобятся отдельные инструменты (например, Fivetran, Airbyte), что усложняет стек технологий.
Кривая обучения: Хотя основы просты, освоение продвинутых возможностей Jinja, макросов и структуры проекта требует времени.
Зависимость от Python-моделей: Хотя недавно появилась поддержка моделей на Python, она все еще не так нативна и проста, как основной SQL-подход, и требует дополнительных настроек.

---

Bruin Data: Универсальный боец

Bruin — это более новый игрок на рынке, который позиционирует себя как инструмент для создания “end-to-end” пайплайнов данных. В отличие от dbt, он не ограничивается только трансформацией, а стремится охватить больше этапов работы с данными, включая их загрузку (ingestion) https://github.com/bruin-data/bruin.

Bruin разделяет ту же философию “Analytics as Code”, но предлагает более интегрированный опыт, где SQL и Python являются равноправными гражданами.

Плюсы Bruin

Универсальность: Один инструмент для определения всего пайплайна: от загрузки из источников до финальных витрин данных. Это может упростить стек технологий.
Нативная поддержка SQL и Python: Позволяет легко комбинировать задачи на разных языках в одном пайплайне без дополнительных настроек. Это идеально для задач, где чистый SQL громоздок (например, работа с API, машинное обучение).
Простота конфигурации: Зачастую требует меньше шаблонного кода (boilerplate) для определения ассетов и пайплайнов по сравнению с dbt.
Встроенное качество данных: Как и dbt, делает акцент на проверках качества на каждом шаге.

Минусы Bruin

Пока маленькое сообщество: Как у нового инструмента, у Bruin гораздо меньше пользователей, готовых решений и обсуждений на форумах по сравнению с dbt. Найти помощь или готовый пакет для решения специфической задачи сложнее.
Незрелость: Инструмент моложе, а значит, наверное, потенциально менее стабилен и может иметь меньше интеграций по сравнению с проверенным dbt. Пока нет облачных функция за деньги. Я так думал, но все же есть https://getbruin.com.
“Мастер на все руки — эксперт ни в чем?”: Стремление охватить все этапы (E, L, T) может означать, что в каждом отдельном компоненте Bruin может уступать лучшим в своем классе специализированным инструментам (например, Fivetran в загрузке, dbt в трансформации), но это конечно субъективно.

Сводное сравнение

Характеристика	dbt (data build tool)	Bruin Data
Основная задача	Трансформация (T в ELT)	Весь пайплайн (E, L, T)
Ключевые языки	SQL с шаблонизатором Jinja	SQL и Python как равноправные
Экосистема	Огромная, стандарт индустрии	Маленькая, развивающаяся
Зрелость	Высокая, проверен временем	Низкая/Средняя
Стек инструментов	Требует отдельных E/L инструментов	Стремится быть самодостаточным

Итого

Выбор между dbt и Bruin — это выбор между двумя стратегиями построения современного стека данных.

Выбирайте dbt, если:

Вы строите гибкий стек из лучших в своем классе инструментов (“best-of-breed”): один для загрузки, другой для хранения, третий для трансформации.
Ваша команда в основном состоит из аналитиков, сильных в SQL.
Для вас критически важны поддержка сообщества, стабильность и наличие готовых решений.
Вы работаете в большой организации, где принятие отраслевых стандартов является преимуществом.
Вы готовы переехать к ним в платное облако, когда нибудь. Большая часть функционала доступна там.

Выбирайте Bruin, если:

Вы предпочитаете единый, интегрированный инструмент для управления всеми пайплайнами, чтобы упростить архитектуру
Вы любите open source и End-to-end дата framework: фор data ingestion + transformations + кволити. :)
Ваши пайплайны требуют тесной связки SQL и Python для трансформаций (например, обогащение данных через вызовы API или модели ML).
Вы начинаете новый проект или работаете в небольшой команде и цените скорость настройки и меньшее количество движущихся частей.
Вы Go’шник :) – Bruin написан на Go почти на 100%.

И dbt, и Bruin — мощные инструменты, воплощающие современные подходы к инженерии данных. dbt предлагает проверенный, сфокусированный и невероятно мощный движок для трансформаций, ставший стандартом. Bruin же предлагает более универсальный и интегрированный подход, который может быть привлекателен для команд, стремящихся к простоте и нативной поддержке Python.

А что такое “Аналитика как код” (Analytics as Code, AaC)?

Аналитика как код — это подход к управлению аналитическими процессами, при котором все компоненты аналитики — от моделей данных и метрик до отчетов и правил доступа — определяются в виде кода в человекочитаемых файлах. Эти файлы затем управляются так же, как исходный код любого другого программного обеспечения: с помощью систем контроля версий, автоматизированного тестирования и развертывания medium.com.

Самая близкая и известная аналогия — это Infrastructure as Code (IaC). Как IaC (например, с помощью Terraform) позволил инженерам описывать серверы, сети и базы данных в коде вместо ручной настройки через веб-интерфейсы, так и AaC позволяет описывать в коде всё, что связано с данными medium.com.

Идея проста и убедительна: “настройте свои системы один раз, выразите это в виде кода, а затем поместите в систему контроля версий” holistics.io.

Проблема: Как было раньше?

Чтобы понять ценность AaC, нужно посмотреть на проблемы, которые он решает. В традиционном подходе аналитика часто была разрозненной и хрупкой:

Логика в “черных ящиках”: Сложные преобразования данных были скрыты внутри GUI-интерфейсов старых ETL-инструментов или непосредственно в настройках BI-платформы (например, Tableau, Power BI). Никто, кроме автора, не мог легко понять, как рассчитывается та или иная метрика.
Разрозненные SQL-скрипты: Аналитики хранили важные SQL-запросы на своих локальных машинах, в общих папках или на wiki-страницах. Не было единой версии правды, код дублировался и быстро устаревал.
Отсутствие контроля версий: Невозможно было отследить, кто, когда и почему изменил логику расчета ключевого показателя. Откат к предыдущей работающей версии был настоящей головной болью.
“Ручное” тестирование: Проверка качества данных после изменений была ручным, подверженным ошибкам процессом. Часто о проблемах узнавали уже от бизнес-пользователей, которые видели неверные цифры в отчетах.
Рассинхронизация: Инженеры данных готовили сырые таблицы, а аналитики строили свою логику поверх них. Любые изменения с одной стороны могли сломать всю цепочку, не будучи замеченными вовремя.

Этот хаос приводил к главному — недоверию к данным. Никто не мог быть уверен, что цифры в дашборде верны.

Ключевые принципы “Аналитики как код”

AaC решает эти проблемы, внедряя практики из мира разработки ПО.

Декларативное определение: Все аналитические артефакты описываются в файлах.
- Модели данных:** `SELECT * FROM ...` в `.sql` файлах.
- Тесты:** `not_null`, `unique` в `.yml` файлах.
- Документация:** Описания таблиц и полей в `.yml` файлах.
- Метрики и дашборды:** Определения в `.yml` или специализированных файлах medium.com.

Контроль версий (Git): Весь код хранится в репозитории (например, на GitHub или GitLab).
- Прозрачность:** Каждое изменение — это `commit` с понятным описанием.
- Совместная работа:** Аналитики работают в отдельных ветках, а изменения вносятся через `Pull Request` (или `Merge Request`), что позволяет проводить ревью кода (code review).
- Восстанавливаемость:** Если что-то пошло не так, можно легко откатиться к предыдущей версии.

Автоматизированное тестирование: Тесты являются неотъемлемой частью кода. Они запускаются автоматически при каждом изменении, чтобы гарантировать, что данные по-прежнему соответствуют ожиданиям (например, `user_id` всегда уникален и не равен `NULL`).

CI/CD (Непрерывная интеграция и развертывание): Процессы полностью автоматизированы.
- Когда аналитик вносит изменения в `Pull Request`, автоматически запускаются тесты.
- После одобрения и слияния ветки изменения автоматически развертываются в продуктивной среде (например, dbt Cloud или Jenkins запускает команду `dbt run`).

Модульность и переиспользование (DRY – Don’t Repeat Yourself): Сложные потоки данных разбиваются на небольшие, логичные и переиспользуемые модели. Одна модель может ссылаться на другую, создавая четкий граф зависимостей (lineage), который можно визуализировать.

Преимущества подхода AaC

Принятие этой философии дает компании ощутимые выгоды:

Надежность и доверие: Благодаря автоматическому тестированию и ревью кода значительно повышается качество данных, а вместе с ним и доверие бизнеса к аналитике.
Скорость и гибкость: Аналитики могут вносить изменения гораздо быстрее. Цикл от идеи до готового отчета сокращается с недель до дней или даже часов.
Масштабируемость: Кодовая база легко поддерживается и расширяется. Новые члены команды могут быстро разобраться в проекте благодаря документации и прозрачности.
Прозрачность и обнаруживаемость: Автоматически сгенерированная документация и графы зависимостей позволяют любому сотруднику понять, откуда берутся данные и как они рассчитываются.
Демократизация: AaC дает возможность аналитикам, владеющим SQL, самостоятельно создавать надежные и протестированные модели данных, не дожидаясь инженеров данных. Это стирает барьеры между командами.

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

Apache SeaTunnel – Движение к мультимодальной интеграции данных

Sun, 17 Aug 2025 11:32:24 +0300

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

Оригинал тут: https://apacheseatunnel.substack.com/p/apache-seatunnel-new-positioning

Введение

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

Проблемы предыдущей архитектуры

Изначально Apache SeaTunnel был разработан как плагин, работающий поверх вычислительных движков, таких как Apache Spark и Apache Flink. Такой подход имел свои преимущества, позволяя использовать мощность этих движков, но также порождал ряд проблем:

Зависимость от сторонних движков: Для выполнения даже самых простых задач по пересылке данных требовалось развертывание и поддержка тяжеловесных кластеров Spark или Flink. Это увеличивало накладные расходы, усложняло настройку и повышало порог входа для новых пользователей.
Сложность конфигурации: Пользователям приходилось разбираться не только в конфигурации самого SeaTunnel, но и в настройках Spark/Flink, что часто приводило к так называемому “конфигурационному аду”.
Ограничения коннекторов: Разработка коннекторов была тесно связана с API Spark и Flink, что затрудняло создание универсальных коннекторов, работающих в обеих средах без изменений.
Низкая производительность для простых задач: Использование мощных, но громоздких движков для элементарных задач ETL (Extract, Transform, Load) было избыточным и неэффективным с точки зрения ресурсов и времени запуска.

Новое видение: унифицированная платформа с собственным движком

Чтобы решить эти проблемы и соответствовать современным требованиям, сообщество Apache SeaTunnel представило новую архитектуру, в основе которой лежит собственный вычислительный движок — SeaTunnel Engine.

Этот стратегический шаг позволил отделить SeaTunnel от обязательной зависимости от Spark и Flink. Теперь SeaTunnel может работать в самостоятельном режиме, что обеспечивает следующие ключевые преимущества:

Легковесность и быстрота: `SeaTunnel Engine` специально оптимизирован для задач интеграции данных. Он запускается быстрее и потребляет значительно меньше ресурсов, чем полноценные кластеры Spark или Flink, что делает его идеальным для широкого круга задач.
Унификация пакетной и потоковой обработки: Новая архитектура изначально спроектирована для бесшовной работы как с пакетными (batch), так и с потоковыми (streaming) данными. Пользователям больше не нужно поддерживать два разных стека для разных типов задач — SeaTunnel предоставляет единый интерфейс и модель выполнения.
Упрощенная разработка коннекторов: С введением унифицированного API коннекторов (`Connector API`), разработчикам стало проще создавать новые интеграции. Коннектор, написанный для `SeaTunnel Engine`, будет работать одинаково для всех сценариев, что ускоряет расширение экосистемы.

Мультимодальная интеграция данных

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

Структурированные данные: Традиционная область для SeaTunnel. Поддерживается множество реляционных баз данных (MySQL, PostgreSQL), аналитических СУБД (ClickHouse, Doris) и хранилищ данных.
Полуструктурированные данные: Эффективная работа с NoSQL базами данных (MongoDB, Elasticsearch) и потоками событий (Kafka, Pulsar).
Неструктурированные данные: Расширение поддержки для озер данных (Data Lakes) и файловых систем (HDFS, S3, OSS). Это включает интеграцию с форматами вроде Apache Hudi, Iceberg и Delta Lake.

Особое внимание уделяется критически важным функциям, таким как Захват изменяемых данных (CDC) и синхронизация всей базы данных целиком. SeaTunnel теперь может считывать журналы транзакций (например, binlog в MySQL) для захвата изменений в реальном времени и применять их к целевой системе. Функция полной синхронизации позволяет в одной задаче перенести схему и все данные из одной базы в другую, что значительно упрощает миграцию.

Будущее развитие

Дорожная карта проекта включает в себя:

Расширение экосистемы коннекторов: Добавление поддержки еще большего числа источников и приемников, включая современные SaaS-платформы и векторные базы данных для задач ИИ.
Улучшенная поддержка озер данных: Углубление интеграции с форматами Hudi и Iceberg, поддержка эволюции схем и транзакционных операций.
Пользовательский интерфейс: Разработка визуального интерфейса для создания и мониторинга заданий, что сделает инструмент более доступным для широкого круга пользователей.
Повышение производительности и стабильности: Непрерывная оптимизация `SeaTunnel Engine` для еще более быстрой и надежной обработки данных.

Заключение

Apache SeaTunnel совершает важный переход от зависимого инструмента к самостоятельной, легковесной и унифицированной платформе для интеграции данных. Отказ от обязательной привязки к Spark/Flink и внедрение собственного `SeaTunnel Engine` открывают новые возможности для пользователей, которым нужно простое, но мощное решение для пакетной и потоковой обработки разнородных данных. Новое позиционирование делает SeaTunnel сильным конкурентом в мире современных ETL/ELT инструментов.

---

Выводы

Проанализировав направление развитие Apache SeaTunnel, можно сделать несколько ключевых выводов:

Стратегическая зрелость: Переход на собственный движок (`SeaTunnel Engine`) — это признак зрелости проекта. Команда осознала, что зависимость от универсальных, но тяжеловесных движков (Spark/Flink) является узким местом для основного сценария использования — интеграции данных. Создание специализированного движка позволяет оптимизировать производительность и снизить накладные расходы именно для этих задач.
Соответствие трендам: Этот шаг полностью соответствует общему тренду в индустрии данных — движению от монолитных, “умеющих все” платформ к более легковесным и специализированным инструментам. Для многих задач по перемещению и простой трансформации данных запуск Spark-кластера является избыточным. SeaTunnel теперь предлагает “золотую середину”.
Конкурентное позиционирование:
- Против коммерческих SaaS ETL (Fivetran, Airbyte): SeaTunnel является мощной open-source альтернативой. Он привлекателен для компаний, которые хотят полного контроля над своей инфраструктурой, стремятся избежать зависимости от поставщика (vendor lock-in) и имеют техническую экспертизу для самостоятельного развертывания и поддержки.
- Против специализированных CDC-инструментов (Debezium): SeaTunnel не просто захватывает изменения (CDC), а встраивает эту функциональность в полноценный конвейер интеграции. Это решение “все в одном”, которое позволяет не только извлечь данные, но и доставить их в целевую систему (например, озеро данных или хранилище) в рамках одного инструмента.
Фокус на “мультимодальности” — это задел на будущее. Поддержка не только реляционных баз и Kafka, но и озер данных (Hudi, Iceberg) и, в перспективе, векторных баз, говорит о том, что проект нацелен на обслуживание современных стеков данных, включая аналитику в реальном времени и конвейеры для машинного обучения (MLOps).

iceberg-kafka-connect

Sun, 17 Aug 2025 11:07:00 +0300

Крутой блог по всей экостистеме кафка, примеры по iceberg которые разобраны ниже

https://rmoff.net/2025/07/04/writing-to-apache-iceberg-on-s3-using-kafka-connect-with-glue-catalog/

небольшой пост про CDC от автора книги гроккаем конкурентность

https://luminousmen.com/post/change-data-capture

дока по iceberg-sink connector

https://github.com/databricks/iceberg-kafka-connect

kafka vizualizer

https://softwaremill.com/kafka-visualisation/

А тут видосик:

Ваш браузер не поддерживает видео.

Описание патерна Slowly Changing Dimensions (SCD)

Sat, 16 Aug 2025 23:24:59 +0300

Slowly Changing Dimensions (SCD), или Медленно меняющиеся измерения, — это концепция и набор методов из области хранилищ данных (Data Warehousing), которые используются для управления изменениями в атрибутах измерений с течением времени. Измерения — это справочные таблицы, которые описывают бизнес-сущности, такие как клиенты, продукты, сотрудники, географические регионы.

Атрибуты этих сущностей (например, адрес клиента или категория продукта) меняются, но обычно не очень часто — отсюда и название “медленно меняющиеся”. Основная задача SCD — решить, как хранить эти изменения, чтобы обеспечить точность исторических отчетов www.datacamp.com.

Например, если вы просто перезапишете адрес клиента, вы потеряете информацию о том, где он жил раньше. Это может исказить анализ продаж по регионам за прошлые периоды. Патерны SCD предлагают различные стратегии для решения этой проблемы.

Основные типы SCD

Существует несколько типов SCD, но самыми распространенными и фундаментальными являются Типы 1, 2 и 3.

---

Тип 1: Перезапись атрибута (Overwrite)

Это самый простой подход. При изменении атрибута старое значение просто перезаписывается новым.

Как работает:** Находится существующая запись в таблице измерения и значение в нужном столбце обновляется.
Когда использовать:** Когда нет необходимости хранить историю изменений. Например, для исправления опечатки в имени клиента.
Преимущества:** Простота реализации, не требует увеличения объема хранилища.
Недостатки: **История изменений полностью теряется. Анализ, основанный на исторических значениях атрибута, становится невозможным.

Пример:
У нас есть клиент Анна Петрова, которая живет в Москве.

*Таблица `DimCustomer` до изменений:*

CustomerKey	FullName	City
:---	:---	:---
101	Анна Петрова	Москва

Анна переезжает в Санкт-Петербург. При использовании SCD Тип 1 таблица будет обновлена:

*Таблица `DimCustomer` после изменений:*

CustomerKey	FullName	City
:---	:---	:---
101	Анна Петрова	Санкт-Петербург

Теперь невозможно узнать, что раньше Анна жила в Москве.

---

Тип 2: Добавление новой строки (Add New Row)

Это самый распространенный и мощный тип SCD, так как он позволяет сохранять полную историю изменений.

Как работает:** Вместо перезаписи существующей записи, создается новая запись для той же сущности (например, того же клиента). Старая запись помечается как неактуальная (истекшая), а новая — как актуальная. Для этого в таблицу измерения обычно добавляют несколько служебных столбцов learn.microsoft.com:
- `StartDate` / `EffectiveDate` — дата, с которой запись стала актуальной.
- `EndDate` — дата, когда запись перестала быть актуальной.
- `IsCurrent` / `CurrentFlag` — флаг (например, ‘Yes’/’No’ или 1/0), показывающий, является ли эта запись текущей.
Когда использовать:** Когда сохранение истории критически важно для анализа. Это стандартный выбор для большинства атрибутов в хранилищах данных.
Преимущества:** Сохраняется полная, точная история. Позволяет проводить корректный point-in-time анализ (анализ на определенный момент времени).
Недостатки:** Увеличивается объем таблицы, так как для одного клиента может быть несколько записей. Запросы могут стать сложнее (нужно фильтровать по флагу `IsCurrent` или по диапазону дат) hevodata.com.

Пример:
Снова используем пример с Анной Петровой.

*Таблица `DimCustomer` до изменений:*

SurrogateKey	CustomerID	FullName	City	StartDate	EndDate	IsCurrent
:---	:---	:---	:---	:---	:---	:---
1	101	Анна Петрова	Москва	2020-01-15	NULL	Yes

Анна переезжает 16 августа 2024 года. При использовании SCD Тип 2 таблица изменится так:

*Таблица `DimCustomer` после изменений:*

SurrogateKey	CustomerID	FullName	City	StartDate	EndDate	IsCurrent
:---	:---	:---	:---	:---	:---	:---
1	101	Анна Петрова	Москва	2020-01-15	2024-08-15	No
2	101	Анна Петрова	Санкт-Петербург	2024-08-16	NULL	Yes

Теперь мы сохранили всю историю перемещений Анны.

---

Тип 3: Добавление нового атрибута (Add New Attribute)

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

Как работает:** Создается новый столбец, например, `PreviousCity`. Когда атрибут `City` меняется, его старое значение копируется в `PreviousCity`, а новое записывается в `City`.
Когда использовать:** Когда важно отслеживать только предыдущее состояние для сравнения, а более глубокая история не нужна.
Преимущества:** Простота реализации, не увеличивает количество строк, легко запрашивать текущее и предыдущее значения.
Недостатки:** Сохраняет историю только на один шаг назад. Не масштабируется, если нужно хранить более двух-трех последних значений.

Пример:
Анна переезжает из Москвы в Санкт-Петербург.

*Таблица `DimCustomer` до изменений:*

CustomerKey	FullName	CurrentCity	PreviousCity
:---	:---	:---	:---
101	Анна Петрова	Москва	NULL

*Таблица `DimCustomer` после изменений:*

CustomerKey	FullName	CurrentCity	PreviousCity
:---	:---	:---	:---
101	Анна Петрова	Санкт-Петербург	Москва

Если Анна переедет снова, значение “Москва” будет потеряно.

Другие типы SCD

Существуют и более сложные гибридные типы:

Тип 4 (History Table):** Основная таблица измерения хранит только текущие данные (как Тип 1), а вся история изменений выносится в отдельную таблицу. Это полезно, когда изменения происходят часто в очень больших таблицах измерений medium.com.
Тип 6 (Hybrid):** Комбинирует подходы Типов 1, 2 и 3. Например, в таблице хранятся поля для полной истории (SCD2) и одновременно поле для текущего значения (SCD1 для быстрого доступа) и предыдущего значения (SCD3 для сравнения).

Тип 4: Добавление исторической таблицы (History Table / Audit Table)

Идея: Разделить текущие данные и исторические данные в разные таблицы для оптимизации производительности.

Как работает:** Создаются две таблицы:
1. Таблица измерения (Dimension Table): Хранит *только* текущие, самые последние данные. Эта таблица по своей сути работает как SCD Тип 1 (данные просто перезаписываются). Она маленькая, быстрая и идеально подходит для большинства запросов, где история не нужна.
2. Историческая таблица (History Table): Хранит всю историю изменений. Каждый раз, когда в основной таблице происходит изменение, старая версия строки (до обновления) добавляется в историческую таблицу. Эта таблица часто содержит служебные поля, как в SCD Тип 2 (`StartDate`, `EndDate`, `Version`), для отслеживания временного периода.
Когда использовать:** Когда у вас есть очень большая таблица измерений (например, десятки миллионов клиентов), и большинство аналитических запросов относится только к текущим данным. Разделение таблиц позволяет сделать эти частые запросы очень быстрыми, не жертвуя при этом возможностью проводить глубокий исторический анализ при необходимости.
Преимущества:**
- Высокая производительность для запросов к текущим данным.
- Логическое разделение данных: актуальные и исторические.
Недостатки:**
- Усложнение ETL/ELT процесса, так как нужно управлять двумя таблицами.
- Анализ, требующий одновременного доступа к историческим и текущим данным, усложняется, так как требует `JOIN` или `UNION` между двумя таблицами.

Пример:
Клиент Анна Петрова переезжает из Москвы в Санкт-Петербург.

*Таблицы до изменений:*

`DimCustomer` (основная таблица)

CustomerID	FullName	City
:---	:---	:---
101	Анна Петрова	Москва

`HistoryCustomer` (историческая таблица) – *пустая*

*Процесс изменения:*

Перед обновлением основной таблицы, текущая строка (Анна в Москве) копируется в `HistoryCustomer`.
Затем основная таблица `DimCustomer` обновляется новым значением.

*Таблицы после изменений:*

`DimCustomer` (всегда хранит только актуальные данные)

CustomerID	FullName	City
:---	:---	:---
101	Анна Петрова	Санкт-Петербург

`HistoryCustomer` (накапливает историю)

HistoryID	CustomerID	FullName	City	StartDate	EndDate
:---	:---	:---	:---	:---	:---
1	101	Анна Петрова	Москва	2020-01-15	2024-08-15

Тип 5: Гибридный подход (Mini-Dimension + Type 1 Outrigger)

Идея: Вынести часто меняющиеся атрибуты из большой таблицы измерений в отдельную “мини-таблицу”, чтобы избежать “раздувания” основной таблицы.

Как работает:**
1. Из основной таблицы измерения (например, `DimCustomer`) выделяется группа атрибутов, которые часто меняются вместе (например, “Тарифный план”, “Статус подписки”).
2. Создается отдельная таблица — “мини-измерение” (например, `DimSubscriptionProfile`) — только для этих атрибутов. Эта мини-таблица управляется по SCD Тип 2 (добавление новой строки для каждого уникального набора значений).
3. В основной таблице `DimCustomer` эти атрибуты удаляются, и вместо них добавляется один внешний ключ (например, `SubscriptionProfileKey`), который ссылается на мини-измерение.
4. Этот ключ в основной таблице `DimCustomer` обновляется по принципу SCD Тип 1 (просто перезаписывается), указывая на *актуальную* запись в мини-измерении.
Когда использовать:** В очень больших (широких и/или с большим количеством строк) таблицах измерений, где лишь небольшая группа атрибутов меняется относительно часто. Это позволяет отслеживать историю этих атрибутов, не создавая новую многомиллионную запись в основной таблице при каждом изменении.
Преимущества:**
- Экономия места и контроль над ростом основной таблицы измерения.
- Позволяет вести детальную историю для подгруппы атрибутов.
Недостатки:**
- Более сложная модель данных, требующая дополнительных `JOIN`.
- Может быть сложнее для понимания конечными пользователями.

Пример:
Клиент Иван меняет свой тарифный план.

*Таблицы до изменений:*

`DimCustomer`

CustomerKey	FullName	SubscriptionProfileKey
:---	:---	:---
202	Иван Иванов	55

`DimSubscriptionProfile` (мини-измерение, управляется по SCD2)

ProfileKey	Plan	Status	IsCurrent
:---	:---	:---	:---
55	Basic	Active	Yes

*Процесс изменения:* Иван переходит на план “Premium”.

В `DimSubscriptionProfile` добавляется новая строка для “Premium”, а старая помечается как неактуальная.
В `DimCustomer` у Ивана обновляется ключ `SubscriptionProfileKey`.

*Таблицы после изменений:*

`DimCustomer` (здесь изменился только ключ)

CustomerKey	FullName	SubscriptionProfileKey
:---	:---	:---
202	Иван Иванов	56

`DimSubscriptionProfile` (здесь хранится вся история)

ProfileKey	Plan	Status	IsCurrent
:---	:---	:---	:---
55	Basic	Active	No
56	Premium	Active	Yes

Тип 6: Гибридный (Комбинация Типа 1, 2 и 3)

Идея: Обеспечить максимальную гибкость для анализа, объединив сильные стороны трех основных типов в одной таблице.

Как работает: Этот тип строится на основе **SCD Тип 2 (добавление новой строки для истории), но с добавлением атрибутов из SCD Тип 1 (перезапись) для упрощения некоторых запросов.
- Основная структура — это SCD Тип 2: есть строки для каждой исторической версии с полями `StartDate`, `EndDate` и `IsCurrent`. Поле атрибута (например, `City`) хранит значение, актуальное на тот исторический период.
- Дополнительно в таблицу добавляется столбец `CurrentCity`. Этот столбец для *всех* записей одного клиента (и исторических, и текущей) всегда хранит актуальное на данный момент значение (поведение SCD Тип 1).
Когда использовать:** Когда аналитикам часто нужно отвечать на два типа вопросов:
1. “Каким был город клиента на момент продажи?” (Используется историческое поле `City`).
2. “Каковы продажи всем клиентам, которые *сейчас* живут в Москве, за всю историю?” (Используется поле `CurrentCity` для фильтрации).
Преимущества:**
- Невероятная гибкость анализа без сложных `JOIN` или подзапросов для определения текущего состояния.
Недостатки:**
- Усложнение ETL/ELT. При изменении адреса нужно не только создать новую строку и закрыть старую, но и обновить поле `CurrentCity` во всех предыдущих строках для этого клиента. Это может быть ресурсозатратно.

Пример:
Снова Анна, переезжающая из Москвы в Санкт-Петербург.

*Таблица `DimCustomer` до изменений:*

SurrogateKey	CustomerID	City	CurrentCity	StartDate	EndDate	IsCurrent
:---	:---	:---	:---	:---	:---	:---
1	101	Москва	Москва	2020-01-15	NULL	Yes

*Процесс изменения:*

Старая строка “закрывается” (обновляется `EndDate`, `IsCurrent` = ‘No’).
Создается новая актуальная строка.
Во всех строках для CustomerID=101 поле `CurrentCity` обновляется до “Санкт-Петербург”.

*Таблица `DimCustomer` после изменений:*

SurrogateKey	CustomerID	City	CurrentCity	StartDate	EndDate	IsCurrent
:---	:---	:---	:---	:---	:---	:---
1	101	Москва	Санкт-Петербург	2020-01-15	2024-08-15	No
2	101	Санкт-Петербург	Санкт-Петербург	2024-08-16	NULL	Yes

Теперь можно легко отфильтровать по `City` для исторического анализа или по `CurrentCity` для анализа в разрезе текущего состояния.

Ссылки для дальнейшего изучения

Microsoft Fabric:** Slowly changing dimension type 2 https://learn.microsoft.com/en-us/fabric/data-factory/slowly-changing-dimension-type-two — Хорошее описание и пример реализации SCD Тип 2.
DataCamp:** Mastering Slowly Changing Dimensions (SCD) https://www.datacamp.com/tutorial/mastering-slowly-changing-dimensions-scd — Комплексный учебник по основным типам SCD.
HevoData:** Slowly Changing Dimensions(SCD): Types with Examples https://hevodata.com/learn/slowly-changing-dimensions/ — Детальное объяснение всех основных типов с примерами.
ThoughtSpot:** Slowly Changing Dimensions (SCD): 4 Types & How to ...https://www.thoughtspot.com/data-trends/data-modeling/slowly-changing-dimensions-in-data-warehouse — Еще один ресурс с обзором и сравнением типов SCD.

Идея: Концептуальная архитектура: SCD на стеке Lakehouse + Data Mesh + dbt

Основная идея заключается в создании надежных, версионируемых и децентрализованных “продуктов данных”, одним из которых является таблица измерений с полной историей (SCD). (Автоматическая)

Вот как компоненты взаимодействуют друг с другом:

Lakehouse (Основа): Это наша физическая среда. Мы используем открытое озеро данных (например, S3, ADLS) для хранения, а поверх него — табличный формат Apache Iceberg. Iceberg предоставляет нам ACID-транзакции, эволюцию схемы и, что самое важное для SCD, атомарные и эффективные операции `MERGE` (`UPDATE`/`INSERT`/`DELETE`) на уровне строк прямо в озере данных.

Data Mesh (Философия организации): Вместо централизованной команды данных, мы принимаем философию Data Mesh. A “Команда домена Клиенты” несет полную ответственность за все данные, связанные с клиентами. Их задача — предоставить остальной компании высококачественный продукт данных под названием `dim_customers`. Этот продукт должен включать полную историю изменений (SCD Type 2).

ETL/ELT (Процесс): Это конвейер, по которому данные текут от источника к потребителю.
- Extract & Load: Исходные данные (например, изменения в базе данных клиентов) захватываются с помощью CDC (Change Data Capture) инструментов типа Debezium и попадают в **Kafka. Оттуда они загружаются (Load) в “бронзовый” слой нашего Lakehouse (в сыром виде, в таблицы Iceberg).
- Transform: Здесь в игру вступает **dbt. Команда домена использует `dbt` для преобразования сырых данных из бронзового слоя в готовую к использованию модель в “серебряном” слое — нашу таблицу `dim_customers`.

dbt (Инструмент автоматизации SCD): `dbt` является сердцем автоматизации. Он не просто выполняет SQL-скрипты. У него есть встроенный функционал для реализации SCD Type 2, который называется `Snapshots`.

---

Сценарий 1: Автоматическое формирование SCD с помощью `dbt snapshots`

Это наиболее распространенный, надежный и идиоматический способ реализации идеи.

Как это работает:

Источник: У нас есть “бронзовая” таблица `bronze_customers`, которая содержит текущее состояние всех клиентов. Эта таблица обновляется периодически (например, раз в час) новыми данными из Kafka.
dbt Snapshot: В проекте `dbt` команда домена создает файл “снэпшота” (`snapshot/customers_snapshot.sql`). Внутри него описывается, как `dbt` должен отслеживать изменения.

{% snapshot customers_snapshot %}

    {{
        config(
          target_schema='silver',
          unique_key='customer_id',
          strategy='check',
          check_cols=['address', 'email', 'phone_number'],
          updated_at='last_modified_at',
        )
    }}

    select * from {{ source('bronze', 'customers') }}

    {% endsnapshot %}

Автоматизация: Оркестратор (например, Airflow) запускает команду `dbt snapshot` по расписанию.
Что делает dbt “под капотом”:
- Он сравнивает записи из исходной таблицы (`bronze_customers`) с текущими записями в целевой таблице (`silver.customers_snapshot`).
- Используя `unique_key` (`customer_id`), он находит совпадающие записи.
- С помощью стратегии `check` он проверяет, изменилось ли значение в любом из столбцов, перечисленных в `check_cols`.
- Если изменение обнаружено:
  - Он обновляет старую запись в целевой таблице, проставляя ей дату окончания актуальности (`dbt_valid_to`).
  - Он вставляет новую строку с обновленными данными и датой начала актуальности (`dbt_valid_from`).
- `dbt` генерирует одну атомарную операцию `MERGE` для таблицы Iceberg, которая эффективно выполняет все эти обновления и вставки за одну транзакцию.

Результат: В `silver.customers_snapshot` мы получаем идеальную таблицу SCD Type 2, которая обновляется автоматически и надежно, без написания сложной логики `MERGE` вручную.

Книга “I ♥ Logs” Джея Крепса

Wed, 06 Aug 2025 00:37:25 +0300

Часть 1: Книга “I Love Logs” EVENT DATA, STREAM PROCESSING, AND DATA INTEGRATION

Джей Крепс

Оригинал тут: I_Heart_Logs-Jay_Kreps.pdf

Оригинальные идеи и рекомендации книги:

Лог как фундаментальная абстракция:
- Ключевая идея: лог — это не просто текстовый файл для отладки, а упорядоченная, неизменяемая (append-only) последовательность записей (событий), снабженная уникальными, последовательно увеличивающимися номерами (offset’ами), которые служат “временем” в распределенной системе.
- Он является “источником истины” (`source of truth`) и позволяет восстановить состояние системы.
- State Machine Replication Principle: Если два детерминированных процесса начинают в одном состоянии и получают одинаковые входные данные в одном и том же порядке, они произведут одинаковый вывод и закончат в одном и том же состоянии. Лог обеспечивает этот “одинаковый порядок”.

Роль логов в базах данных:
- Логи лежат в основе работы ACID-баз данных (commit log, transaction log) для обеспечения атомарности, изоляции и долговечности.
- Используются для репликации данных между мастером и репликами (Change Data Capture – CDC).

Применения логов:
- Интеграция данных (Data Integration): Лог становится центральной “магистралью данных” или единой “шиной событий” для всей организации. Он решает проблему интеграции “N систем с N системами” (N²) путем преобразования ее в “N систем с одним логом” (N). Крепс приводит “Иерархию потребностей Маслоу для данных” (сбор/аквизиция данных, семантика, понимание, автоматизация), подчеркивая, что без надежного сбора данных невозможно ничего другого.

Организационная масштабируемость**: Ответственность за чистоту и формат данных лежит на *производителе* данных, а не на потребителях или центральной команде ETL.
Потоковая обработка в реальном времени (Real-time Stream Processing): Лог — это естественное представление потока данных. Любое событие в реальном времени, база данных, изменяющаяся с течением времени, — всё это логи.
Крепс выступает за Kappa-архитектуру как альтернативу Lambda-архитектуре.
Критика Lambda: Дублирование логики (один и тот же расчет в batch и stream слоях), сложность оперирования.
Альтернативная модель репроцессинга: Вместо двух отдельных фреймворков (batch и stream) — использовать единую потоковую систему, которая может пересчитывать историю, используя лог как источник исторических данных. Когда логика меняется, запускается новый потоковый Job с начала лога, записывающий результат в новую таблицу, и после догона старая таблица заменяется новой.
Проектирование распределенных систем: Лог упрощает дизайн. Вместо того, чтобы каждая система занималась согласованностью, репликацией и восстановлением, эти функции можно передать логированию.
Паттерн “Сервис = Лог + Serving Layer”: Лог хранит все изменения (source of truth), а “serving layer” (например, поисковая система, key-value хранилище) строит индексированные или материализованные представления на основе лога для быстрых запросов.

Технические особенности и оптимизации:
- Партиционирование лога: Для горизонтального масштабирования (Kafka). Позволяет обрабатывать записи независимо, не требует глобального порядка. Порядок гарантируется только в пределах одной партиции.
- Батчинг (Batching): Соединение мелких операций в крупные для повышения пропускной способности.
- Zero-Copy Data Transfer: Передача данных между слоями памяти без их копирования, что улучшает производительность.
- Log Compaction (Компактирование лога): Оптимизация хранения для “лагов изменений” (changelogs). Вместо хранения всех версий записи, оставляется только последняя версия для каждого ключа. Это позволяет восстановить *текущее* состояние, но не *всю* историю.

Дуальность таблиц и событий (Tables and Events Are Dual):
- Крепс проводит аналогию с системами контроля версий (Git): история изменений (патчи) — это лог, а текущая рабочая копия — это таблица.
- Данные могут свободно “перетекать” между состоянием (таблица) и потоком изменений (лог).

Стоило бы дополнить (2023-2024):

Эволюция экосистемы:
- Книга вышла в 2014 году. С тех пор Kafka стала де-факто стандартом. Появились альтернативы Apache Pulsar его, кстати, умеет читать и писать Seatunnel :) и множество надстроек/фреймворков (Kafka Streams, Flink SQL, Materialize).
- Рост Serverless-архитектур и их интеграция с логами (AWS Lambda, Google Cloud Functions, Azure Functions как потребители логов).
- Повсеместное использование Kubernetes и операторов для развертывания и управления Kafka-кластерами.

Управление схемами (Schema Management):
- Книга упоминает структурированные логи, но не углубляется в детали. Сегодня критически важен Schema Registry (например, Confluent Schema Registry или http://apicur.io) для обеспечения совместимости схем данных в логах и управления их версиями. Это предотвращает “data swamp” и делает логи действительно надежным источником данных.

Качество данных и Observability:
- Помимо “структуры”, важна *семантика* и *качество* данных. Мониторинг “data quality”, “data lineage” (происхождение данных) и “data governance” становятся ключевыми.
- Observability: Трассировка событий через лог-пайплайн (например, OpenTelemetry), сбор метрик (lag потребителей, пропускная способность, ошибки) с Prometheus/Grafana.

Безопасность (Security):
- Шифрование данных в пути (TLS) и в состоянии покоя (at-rest encryption).
- Аутентификация и авторизация (RBAC) для продюсеров и потребителей Kafka.
- Аудит доступа к логам.

Паттерны микросервисной архитектуры:
- Event Sourcing и CQRS стали стандартными паттернами.
- Saga Pattern для координации распределенных транзакций между микросервисами, часто реализуемых через лог.
- Data Mesh: Принцип, что данные должны рассматриваться как продукт. Команда-владелец домена отвечает за свой “дата-продукт” и предоставляет его через лог, который является частью этого “продукта”.

Real-time Analytics и ML:
- Пайплайны с логами используются для обучения и инференса ML-моделей в реальном времени. Например, логи кликов для рекомендательных систем.
- Появление GPU-ускоренных фреймворков для потоковой обработки (например, NVIDIA RAPIDS).

Антипаттерны и ошибки: Конкретные примеры из практики, как неправильное внедрение логов может привести к проблемам.

---

Часть 2: Современный взгляд Логи: Кровеносная система Data-Driven компаний

Представьте себе, что данные – это жизненная сила вашей компании, а IT-инфраструктура – ее тело. Тогда логи, как это ни парадоксально, стали бы ее кровеносной системой. Они несут информацию от каждой клетки к каждому органу, обеспечивая слаженность и жизнеспособность всего организма.

В эпоху распределенных систем, микросервисов, Big Data и искусственного интеллекта, когда скорость обработки информации определяет конкурентное преимущество, традиционные подходы к интеграции и обработке данных трещат по швам. Книга, которая у вас в руках – это переосмысление ключевых идей Джея Крепса, соавтора Apache Kafka, о том, как “скромный” лог превратился из технической детали в центральный архитектурный примитив.

Мы пройдем путь от понимания природы лога до его применения в масштабных системах, интеграции данных, потоковой обработке и построении отказоустойчивых архитектур. Эта книга не только сохранит оригинальные прозрения, но и дополнит их новейшими практиками, инструментами и опытом, накопленным IT-индустрией за последнее десятилетие. Вы узнаете, как избежать распространенных ошибок и построить по-настоящему гибкую и масштабируемую систему, где данные действительно “текут” свободно.

---

Глава 1: Лог: Недооцененный фундамент современных систем

Когда речь заходит о логах, большинство инженеров представляют себе длинные текстовые файлы с отладочной информацией. Однако, как показал Джей Крепс, истинная природа лога гораздо глубже.

Что такое Лог? Глубже, чем кажется.
Представьте себе не просто текстовый файл, а упорядоченную, неизменяемую последовательность записей. Каждая запись добавляется в конец. Это фундаментальное отличие от базы данных, где данные можно изменять “на месте”. В логе ни одна запись не удаляется и не меняется. Вместо этого, новые изменения *добавляются* как новые записи.

Каждая запись в логе имеет уникальный, последовательно возрастающий номер, который можно считать её “временем” или “позицией” в потоке. Это ключевое свойство: оно дает нам гарантию порядка.

Принцип State Machine Replication: Волшебство порядка
Это краеугольный камень распределенных систем. Он гласит:

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

В этом принцип “лога” критически важен: он обеспечивает “одинаковый порядок” входных данных для всех реплик. Если у вас есть лог всех изменений (событий), вы можете “воспроизвести” этот лог на разных машинах, чтобы они достигли идентичного состояния.

*Пример из практики*: Банковский счет. Вместо хранения одного числа (текущий баланс), мы храним лог всех транзакций: “снятие 1000 руб.”, “поступление 5000 руб.”. Текущий баланс – это всего лишь функция, которая суммирует все записи в логе до текущего момента. Если банк “забудет” состояние баланса, он всегда может его восстановить, проиграв лог всех транзакций.

Логи в базах данных: Невидимый двигатель
Внутри любой надежной реляционной базы данных или NoSQL-хранилища уже давно работает лог: `commit log` или `transaction log`. Он гарантирует, что даже при сбое системы, транзакции не будут потеряны, а данные останутся согласованными (свойства ACID). Механизмы репликации баз данных (например, бинарные логи MySQL или WAL PostgreSQL) – это по сути потоковая передача записей из такого лога. Это и есть Change Data Capture (CDC) – захват изменений данных.

Дополнение (2023-2024):

Структурированные логи и схемы: Для машинного чтения и обработки логам необходим строгий формат. Сегодня это почти всегда JSON, Apache Avro или Google Protocol Buffers.
- Рекомендация: Используйте Schema Registry**. Это централизованное хранилище ваших схем, которое позволяет эволюционировать схемы логов, не ломая обратную совместимость. Оно критически важно для долгосрочной жизнеспособности вашей data-инфраструктуры. Без Schema Registry ваши логи быстро превратятся в “data swamp” – болото неструктурированных, непонятных данных.
Лог как Event Stream: В современных архитектурах каждый чих в системе – это событие. Логи веб-сервера, действия пользователя, метрики микросервисов, изменения в БД – все это может быть представлено как лог событий.

Ошибки, которых стоит избегать:

“Лог для людей, а не для машин”: Если вы используете логи только для чтения человеком при отладке, вы упускаете их колоссальный потенциал как источника данных для других систем.
Отсутствие структурированности: Произвольные текстовые сообщения в логах делают их крайне сложными для автоматического анализа и интеграции. Всегда! используйте структурированные форматы.
Игнорирование порядка: Если события записываются без гарантии порядка, вы никогда не сможете надежно воспроизвести состояние системы или построить корректные агрегаты.

---

Глава 2: Данные как потоки: Интеграция через Логи

Одна из самых болезненных проблем в больших компаниях – это интеграция данных. Исторически это решалось кастомными ETL (Extract, Transform, Load) пайплайнами, где каждая система “говорила” с каждой. Такая модель приводит к экспоненциальному росту сложности (N² соединений для N систем).

Централизованная шина событий: Революция в интеграции
Идея Крепса: вместо N² соединений, создайте универсальный централизованный лог, который будет выступать в роли “шины событий” или “артерии данных”.

Производители данных: Системы, генерирующие данные, публикуют их в этот центральный лог.
Потребители данных: Системы, которым нужны эти данные, подписываются на соответствующие части лога (топики) и потребляют их независимо, в своем темпе.

```mermaid
graph LR
A[Система 1 (Продюсер)] -- Публикует --> C(Центральный Лог)
B[Система 2 (Продюсер)] -- Публикует --> C
C -- Потребляет --> D[Система A (Потребитель)]
C -- Потребляет --> E[Система B (Потребитель)]
C -- Потребляет --> F[Система C (Потребитель)]
```

Вместо множества прямых соединений между A-D, A-E, A-F, B-D, B-E, B-F, мы получаем лишь несколько соединений к центральному логу. Сложность снижается с N² до N.

Иерархия потребностей данных по Маслоу (адаптировано Крепсом):

Аквизиция/Сбор данных: Самый важный базовый уровень. Без надежного, полного и структурированного сбора данных не имеет смысла говорить о чём-то другом. Многие компании пытаются “прыгнуть” сразу к ИИ и машинному обучению, имея хаотично собираемые данные. Это обратная логика.
Семантика: Понимание значения данных, их контекста, метаданных.
Понимание: Способность строить отчеты, визуализации.
Автоматизация: Реализация сложных алгоритмов, прогнозов.

Задача интеграции данных лежит в основе этой иерархии. Логи — это инструмент для её решения.

Дополнение (2023-2024):

Data Mesh и Data Products: Эта концепция идеально ложится на идею центрального лога. Каждая команда-владелец домена (например, “Клиенты”, “Заказы”) становится ответственной за свой “Data Product”. Этот продукт включает в себя данные (часто в виде топиков лога), их схемы, качество, доступность и документацию.
- Рекомендация: Внедряйте `Data Contracts`. Это соглашения между командами о структуре и семантике данных, которые они передают через лог, аналогично API-контрактам.
Cloud-Native решения:
- Managed Kafka: Облачные провайдеры предлагают управляемые сервисы Kafka (Confluent Cloud, AWS MSK, Azure Event Hubs). Это снимает бремя операционного управления.
- CDC: Инструменты вроде Debezium позволяют легко интегрировать изменения из традиционных баз данных (PostgreSQL, MySQL, MongoDB) напрямую в Kafka в реальном времени, превращая их в логи событий.
Трансформации данных: Где делать ETL?
- Source-side: Продюсер должен публиковать максимально чистые, канонические данные.
- Stream-side: Для добавления обогащённых данных или агрегатов могут быть использованы потоковые процессоры (см. Глава 3), создающие новые, производные топики лога.
- Sink-side: Минимальные трансформации при загрузке в целевые системы (например, для специфичных схем БД хранилища).

Ошибки, которых стоит избегать:

“Big Ball of Mud”: Не пытайтесь создавать слишком сложные ETL-пайплайны внутри самого лога. Идеально, если лог остаётся “сырым” источником событий, а трансформации и обогащения происходят в отдельных потоковых приложениях.
Отсутствие ownership: Если нет четкой ответственности за данные, опубликованные в логе, они быстро теряют качество. Команда-производитель должна быть “владельцем” своих данных в логе.
Blindly копирование всего: Не все данные нужны всем. Фильтруйте и маршрутизируйте данные к нужным потребителям, чтобы не перегружать системы и сократить расходы.

---

Глава 3: Потоковая обработка в реальном времени и не только

Логи и потоковая обработка неотделимы друг от друга. Лог — это естественная модель для потока событий.

Что такое потоковая обработка? Шире, чем кажется.
Крепс расширил определение потоковой обработки. Это не просто “обработка данных по мере их поступления и затем отбрасывание”. Это непрерывная обработка данных, способная выдавать результаты с низкой задержкой, но при этом иметь дело с историческими данными (то есть, лог можно переиграть).

От Lambda к Kappa: Парадокс репроцессинга
Традиционная Lambda-архитектура предполагала два параллельных пути обработки:

Batch-слой (партия): Высокая задержка, высокая точность, обработка всей истории (например, Hadoop MapReduce).
Speed-слой (скорость): Низкая задержка, возможно, меньшая точность, обработка только новых данных (например, Storm).
Результаты из обоих слоев объединяются для получения полной картины.

Проблема Lambda: Дублирование бизнес-логики. Один и тот же расчет должен быть написан и поддерживаться дважды, на двух разных фреймворках (например, HiveQL/Spark для batch и Flink/Storm для stream). Это приводит к ошибкам, задержкам в разработке и высоким операционным издержкам.

Kappa-архитектура (Преимущество лога): Изобретая колесо заново, но лучше.
Крепс предложил элегантную альтернативу — Kappa-архитектуру, которая устраняет необходимость в отдельном batch-слое. Идея проста:

Храните все сырые данные в логе (Kafka): Настройте достаточно длинный `retention` (срок хранения), например, 30, 90 дней или даже дольше, если это необходимо для исторического анализа.
Единый потоковый процессор: Используйте один фреймворк (например, Apache Flink, Kafka Streams) для обработки данных. Этот же код обрабатывает как новые, так и исторические данные.
Репроцессинг без боли: Если вам нужно изменить логику обработки или исправить ошибку:
- Запустите новый экземпляр потокового Job.
- Он начинает читать данные с начала лога.
- Результаты записываются в новую целевую таблицу/топик.
- Как только новый Job “догонит” текущее время, переключите потребителей с “устаревшей” целевой таблицы на “новую”.
- Остановите и удалите старый Job и старую таблицу.

```mermaid
graph TD
    A[Исходный Лог (Kafka)]
    B[Старый Processing Job (v1)]
    C[Новый Processing Job (v2)]

    A -- Читает с offset 0 --> C
    A -- Читает с текущего offset --> B

    B -- Записывает в --> D[Старая Выходная Таблица]
    C -- Записывает в --> E[Новая Выходная Таблица]

    F[Приложение]-->D
    subgraph Reprocessing
        C
    end
    subgraph Switch
        direction LR
        F --> G[Переключить на E]
        G --> H[Удалить D, остановить B]
    end
```

Дополнение (2023-2024):

Фреймворки:
- Apache Flink**: Де-факто стандарт для сложных stateful-вычислений с `exactly-once` семантикой. Поддерживает `event time`, `watermarks` (для обработки событий, пришедших не по порядку) и гибкие окна агрегации.
- Kafka Streams / ksqlDB**: Для более простых задач обработки в рамках экосистемы Kafka. Идеально для микросервисов.
- Apache Spark Streaming / Structured Streaming**: Позволяет использовать привычные API Spark для потоков.
Работа с состоянием (Stateful Processing): Многие потоковые задачи требуют сохранения состояния (например, подсчёт уникальных пользователей за час). Современные фреймворки (Flink) позволяют хранить это состояние отказоустойчиво, часто используя RocksDB локально и чекпоинты в удаленном хранилище (S3/HDFS).
Real-time OLAP / Data Warehousing: Появляется класс решений, которые строят агрегаты и индексы напрямую из логов для интерактивных аналитических запросов (например, ClickHouse, Apache Druid, Materialize).
GPU-ускорение: Для ML-инференса и сложных расчетов на потоках, где время критично (например, обнаружение аномалий, фрод-мониторинг), начинают использоваться GPU-ускоренные библиотеки (NVIDIA RAPIDS).

Ошибки, которых стоит избегать:

Игнорирование late data: События в реальном мире не всегда приходят по порядку. Используйте `watermarks` и `event time` для корректной обработки “поздних” данных.
Репроцессинг “на потом”: Откладывание возможности репроцессинга приводит к накоплению технического долга и невозможности быстро исправлять ошибки в логике. Заложите её в архитектуру с самого начала.
Чрезмерное усложнение: Не пытайтесь написать собственный потоковый движок. Используйте проверенные фреймворки, они уже решили большинство проблем с распределенностью, отказоустойчивостью и производительностью.

---

Глава 4: Логи как фундамент для отказоустойчивых систем

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

Паттерн “Сервис = Лог + Serving Layer”
В этом паттерне логика сервиса разделяется на две основные части:

Лог (The Log): Выступает как *единственный источник истины* для всех изменений состояния сервиса. Все записи (события, команды) сначала попадают в лог.
Serving Layer (Слой обслуживания/запросов): Это набор вычислительных узлов, которые подписываются на лог и строят локальные, оптимизированные для запросов, представления данных (индексы).
- Пример: Пользователь хочет обновить свой профиль. Запрос на обновление фиксируется как событие в логе. Serving Layer, потребляя это событие, обновляет свою локальную копию данных (например, в базе данных или поисковом индексе Elasticsearch). Когда пользователь запрашивает профиль, запрос идет в Serving Layer.
- Преимущество: Serving Layer может быть оптимизирован под конкретный тип запроса (например, Elasticsearch для полнотекстового поиска, Redis для быстрого key-value доступа), но при этом получать все данные из единого, надежного лога.

```mermaid
graph TD
    A[Client] --> B[API Gateway/Микросервис записи]
    B -- Записывает событие/изменение --> C(Центральный Лог)

    C -- Подписывается --> D[Serving Layer 1 (напр. Elasticsearch)]
    C -- Подписывается --> E[Serving Layer 2 (напр. Redis Cache)]
    C -- Подписывается --> F[Serving Layer 3 (напр. Data Warehouse)]

    A -- Читает --> D
    A -- Читает --> E
```

Преимущества такой архитектуры:

Отказоустойчивость и восстановление: Если Serving Layer упадет, он может полностью восстановить свое состояние, “проиграв” лог с самого начала или с последнего чекпоинта. Лог является его бэкапом.
Изоляция сбоев: Падение одного Serving Layer не влияет на способность других Serving Layer’ов продолжать работу.
Детерминированность: Гарантия порядка из лога обеспечивает согласованность данных во всех Serving Layer’ах.
Горизонтальное масштабирование: Лог можно партиционировать (делим данные на части), и каждый Serving Layer может обрабатывать одну или несколько партиций, что позволяет добавлять узлы по мере роста нагрузки.
Отсутствие блокировок: Поскольку записи идут в лог, а чтение происходит из Serving Layer, это значительно снижает конкуренцию и улучшает параллелизм.

Log Compaction: Компактирование истории
Не всегда нужно хранить полную историю каждого изменения. Например, если вы отслеживаете текущее местоположение курьера, вам нужна только *последняя* координата, а не весь его путь.

Log Compaction (компактирование лога) – это процесс, при котором для каждого ключа в логе сохраняется только его *последнее* значение, а все предыдущие дубликаты удаляются.
Это позволяет логу действовать как changelog (журнал изменений), который, будучи проигранным с начала, воссоздаст *текущее* состояние распределенной таблицы.
Пример: Kafka умеет выполнять компактирование топиков, что идеально подходит для хранения состояния Key-Value пар (например, текущие балансы счетов, последние известные IP-адреса).

Дополнение (2023-2024):

Event Sourcing: Паттерн, при котором основное состояние приложения сохраняется как последовательность событий в логе, а не как изменяемое состояние в базе данных. Состояние агрегатов получается путем применения всех событий.
Command Query Responsibility Segregation (CQRS): Часто используется вместе с Event Sourcing. Команды (изменения) записываются в лог, а запросы (чтения) обслуживаются из оптимизированных для чтения материализованных представлений, построенных из того же лога.
Saga Pattern: Для координации долгих распределенных транзакций между множеством микросервисов, лог событий часто используется как механизм асинхронной связи и координации. Каждый сервис публикует событие о завершении своей части работы, а координатор Саги реагирует на эти события.
Kubernetes Operators: Для управления сложностью распределенных лог-систем, таких как Kafka, существуют Kubernetes Operators, которые автоматизируют развертывание, масштабирование, восстановление и обновление кластеров.
Observability (наблюдаемость): Логи — это не только данные, но и инструмент для понимания поведения системы. Добавьте трассировку (`trace_id` в события) для отслеживания пути запроса через множество микросервисов и логов. Анализируйте `consumer lag` (отставание потребителей) как ключевую метрику здоровья потоковой системы.

Ошибки, которых стоит избегать:

“Я напишу свою Kafka”: Построение надежной распределенной лог-системы чрезвычайно сложно. Используйте проверенные решения (Kafka, Pulsar).
Забыть о версионировании: Изменения в структуре событий могут сломать старых потребителей. Используйте Schema Registry и стратегии совместимости схем (backward/forward compatibility).
Ручное управление состоянием: Не пытайтесь управлять состоянием stateful-приложений вручную. Доверьте эту задачу фреймворкам потоковой обработки, которые используют лог для отказоустойчивости.

---

Глава 5: Безопасность, Надежность и Операционная Эффективность

Лог, будучи “источником истины” и “кровеносной системой” данных, требует самого высокого уровня внимания к безопасности, надежности и операционной эффективности.

Безопасность (Security): Доверяй, но проверяй

Шифрование данных:
- В пути (In-transit Encryption): Всегда используйте TLS (Transport Layer Security) для обмена данными между клиентами (продюсерами/потребителями) и брокерами лога, а также между самими брокерами.
- В состоянии покоя (At-rest Encryption): Шифруйте данные на диске, где хранятся логи. Это может быть реализовано на уровне операционной системы, файловой системы или диска (LUKS, AWS EBS Encryption).
Аутентификация и Авторизация (Authentication & Authorization – RBAC):
- Аутентификация: Убедитесь, что только доверенные клиенты могут подключаться к лог-системе (например, с помощью SASL/Kerberos, SSL-сертификатов или OAuth 2.0).
- Авторизация (RBAC): Применяйте принцип наименьших привилегий. Контролируйте, кто может записывать в конкретные топики, а кто может читать из них. Отдельные приложения могут иметь разрешения только на чтение из определённых топиков и запись в свои собственные выходные топики.
Аудит (Auditing): Включите логи аудита для всех действий в лог-системе (кто, когда, что изменил или прочитал).

Надежность (Reliability): Будьте готовы ко всему

Репликация данных: Для обеспечения надежности критически важные данные должны быть реплицированы. В Kafka это достигается за счет репликации партиций между брокерами. Определите `replication factor` (фактор репликации) в зависимости от критичности данных (обычно 3).
Диспетчер сбоев (Disaster Recovery):
- Внутрикластерная отказоустойчивость: Лог-система должна быть способна выдержать отказ отдельных узлов или зон доступности (Availability Zones) без потери данных.
- Географическая репликация: Для защиты от сбоев целых дата-центров используйте мульти-кластерные развертывания с гео-репликацией (например, MirrorMaker2 для Kafka).
Idempotence Producers: Убедитесь, что продюсеры могут повторно отправлять сообщения при сбоях без создания дубликатов, достигая `at-least-once` или `exactly-once` семантики.
At-least-once, At-most-once, Exactly-once Semantics: Понимайте и выбирайте подходящую семантику доставки сообщений для каждого пайплайна. `Exactly-once` сложнее всего, но обеспечивает максимальную точность.

Операционная Эффективность (Operational Efficiency): Не замедляйтесь

Партиционирование: Правильное партиционирование топиков критически важно.
- Должно быть достаточно партиций для параллельной обработки.
- Ключи партиционирования должны распределять нагрузку равномерно.
- Ошибка: Недостаточное количество партиций может привести к узким местам. Слишком много партиций усложняет управление и увеличивает нагрузку на брокеры.
Батчинг (Batching): Соединяйте мелкие записи в большие “пакеты” перед отправкой в лог. Это значительно уменьшает накладные расходы на I/O и сетевые операции.
Zero-Copy: Используйте механизмы, позволяющие передавать данные из лога напрямую в сетевой сокет, минуя буферы приложения для копирования. Это снижает нагрузку на CPU.
Мониторинг: Ключ к здоровой системе.
- Метрики брокеров: CPU, память, диск I/O, сетевой трафик, количество сообщений, пропускная способность.
- Метрики топиков: Размер, количество партиций, скорость записи/чтения.
- Метрики потребителей: Consumer Lag (отставание потребителей) — это самая важная метрика. Если `consumer lag` растет, значит, потребитель не справляется с нагрузкой, и данные накапливаются.
- Алерты: Настройте оповещения на критические метрики (высокий `consumer lag`, ошибки записи/чтения, недоступность брокеров).
Логирование и Трассировка: Стандартизируйте форматы логов приложений, отправляющих и потребляющих данные из лога. Включите корреляционные ID (`trace_id`, `span_id`) для отслеживания событий через всю распределенную систему (например, с помощью OpenTelemetry).
Управление ресурсами: Убедитесь, что у брокеров лога достаточно ресурсов (CPU, RAM, диск I/O) для обработки пиковых нагрузок. Используйте быстрые диски (SSD/NVMe).

Дополнение (2023-2024): Chaos Engineering

Для проверки устойчивости вашей лог-инфраструктуры к сбоям, регулярно проводите эксперименты в контролируемой среде.
Примеры**: Имитация отказа брокера (убиваем процесс), сетевые проблемы (Partition), перегрузка диска, увеличение задержки для потребителя. Это помогает выявлять слабые места *до* того, как они проявятся в продакшене.

---

Заключение: пошаговый план к Data-Driven Будущему

Мы проделали большой путь, от понимания фундаментальной природы лога до его роли в современных распределенных системах, интеграции данных и потоковой обработке. Лог — это не просто техническая деталь, а стратегический актив, который позволяет вашей компании быть по-настоящему “data-driven”.

Краткие выводы:

Лог — это источник истины: Он хранит историю изменений в гарантированном порядке.
Лог упрощает: Он решает проблемы интеграции (N² → N), репликации и восстановления.
Лог масштабирует: Благодаря партиционированию и оптимизациям, таким как батчинг и zero-copy.
Лог — это кровь в организме данных: Без него невозможно построить гибкую, реактивную и отказоустойчивую архитектуру.
Kappa лучше Lambda: Одна кодовая база для realtime и batch обработки.

Ваш пошаговый план к Data-Driven Архитектуре, управляемой логами:

Начните с аудита источников данных:
- Определите, какие данные генерируются вашими системами, какие из них критически важны, какие меняются со временем.
- Поймите, где находятся “узкие места” в текущей интеграции.

Выберите платформу логов:
- Выбор: Apache Kafka — это де-факто стандарт. Рассмотрите Apache Pulsar как альтернативу, если вам нужна расширенная гибкость.
- Развертывание: Для начала можно использовать управляемые облачные сервисы (Confluent Cloud, AWS MSK, Azure Event Hubs) или самостоятельно развернуть Kafka в Kubernetes с помощью операторов. Не пытайтесь строить свой велосипед.

Внедрите Schema Registry:
- Это не опция, а обязательное условие.
- Соберите команды, которые генерируют данные, и начните совместно разрабатывать строгие схемы для каждого типа событий (Avro/Protobuf).
- *Рекомендация*: Внедрите процесс `data contract` – соглашения между командами о формате и семантике данных.

Инструментируйте ключевые сервисы для публикации в лог:
- Начните с одного или двух высоконагруженных сервисов.
- Используйте Change Data Capture (CDC) (например, Debezium) для выгрузки изменений из баз данных в лог.
- Для новых сервисов и пользовательских действий изначально проектируйте их как Event Sourcing-системы, публикующие события в лог.

Настройте базовых потребителей и хранилища:
- Автоматизируйте загрузку данных из лога в ваше основное аналитическое хранилище (Data Warehouse, Data Lake, например, S3/HDFS + Spark/Hive).
- Подключите первый “реальный” потребитель, например, систему мониторинга, которая отслеживает ключевые показатели бизнеса на основе событий из лога.

Разверните платформу потоковой обработки:
- Начните с Apache Flink или Kafka Streams. Они позволят вам обрабатывать данные из лога, обогащать их, агрегировать и создавать новые, производные потоки данных.
- *Рекомендация*: Сначала решайте простые задачи (агрегаты, фильтрация), затем переходите к более сложным (stateful processing, windowing).

Сосредоточьтесь на Observability и Автоматизации:
- Внедрите комплексный мониторинг всей лог-инфраструктуры (брокеры, топики, потребители) с ключевыми метриками (consumer lag!).
- Настройте алерты.
- Автоматизируйте процессы развертывания, масштабирования и восстановления лог-компонентов.

Имплементируйте принципы безопасности:
- Шифрование, аутентификация, авторизация. Пусть это будет часть каждого нового внедрения.

Готовьтесь к репроцессингу:
- Убедитесь, что ваши логи хранят достаточно истории (длительный retention).
- Проектируйте свои потоковые приложения с учетом возможности запуска нового экземпляра для пересчета исторических данных.

Примите философию Data Mesh:
- Меняйте культуру: поощряйте команды владеть своими данными как продуктами.

---

Эпилог: Лог – это не просто техническая деталь, а отражение бизнес-процессов. Каждая запись – атом вашей организационной ДНК. Превратите хаос данных в нарратив, где каждая транзакция – это предложение, а каждый поток – глава вашей бизнес-истории, благодаря надежной и гибкой кровеносной системе, управляемой логами.

Кликозявый эластикозавр обзёрнообразный – ClickStack

Thu, 05 Jun 2025 21:41:03 +0300

Представляем ClickStack

Сегодня мы рады анонсировать ClickStack — новое опенсорсное решение для обсервабилити, созданное на базе ClickHouse. ClickStack предоставляет полноценное решение «из коробки» для работы с логами, метриками, трейсами и воспроизведением сессий. Оно работает на основе производительности и эффективности ClickHouse, но спроектировано как полноценный стек для обсервабилити — открытый, доступный и готовый для всех.

Оригинал статья тут: https://clickhouse.com/blog/clickstack-a-high-performance-oss-observability-stack-on-clickhouse

Подробнее тут: https://clickhouse.com/use-cases/observability?loc=o11y
Попробовать тут: https://clickhouse.com/docs/use-cases/observability/clickstack/getting-started

В течение многих лет крупные инженерные команды, такие как в Netflix и eBay, выбирали ClickHouse в качестве основной базы данных для обсервабилити. Её колоночная структура, сжатие и высокопроизводительный векторизованный движок запросов сделали её идеальной для хранения «широких событий» — записей с богатым контекстом и высокой кардинальностью, которые объединяют логи, метрики и трейсы. Этот современный подход к обсервабилити (некоторые называют его «Observability 2.0») отходит от традиционной модели «трёх столпов» и устраняет сложность объединения разрозненных источников телеметрии.

До сих пор все преимущества этой модели были в основном доступны только командам, обладавшим ресурсами для создания специализированных решений для обсервабилити на базе ClickHouse. А все остальные? Они полагались на универсальные инструменты визуализации или сторонние проприетарные платформы, созданные на ClickHouse. Хотя эти инструменты предоставляли базовые интерфейсы для ClickHouse, они иногда требовали длинных SQL-запросов для рутинных задач обсервабилити или не в полной мере использовали производительность и открытую архитектуру ClickHouse.

Сегодня всё меняется. С выпуском ClickStack на базе HyperDX мы уравниваем шансы. Этот полностью опенсорсный стек включает в себя готовый коллектор OpenTelemetry, пользовательский интерфейс, разработанный для «широких событий», запросы на естественном языке, воспроизведение сессий, оповещения и многое другое.

И всё это работает на том же высокопроизводительном движке ClickHouse с высоким уровнем сжатия, которому доверяют крупнейшие имена в сфере обсервабилити.

Раньше командам часто приходилось выбирать между дорогими проприетарными SaaS-продуктами и сборкой собственных решений из опенсорсных альтернатив. Поисковые движки предлагали быстрые и гибкие запросы, но их эксплуатация в больших масштабах и достижение высокой производительности агрегации оказывались сложными. Хранилища метрик обеспечивали лучшую производительность агрегации, но требовали жёсткой предварительной агрегации и не имели возможностей для глубокого поиска. Ни один из подходов не справлялся хорошо с данными высокой кардинальности, а их объединение добавляло сложности, не решая основной проблемы.

С ClickStack вам не придётся выбирать — наслаждайтесь быстрым поиском и быстрыми агрегациями по данным высокой кардинальности в формате «широких событий». В больших масштабах. С открытым исходным кодом. И теперь — для всех.

Эволюция ClickHouse для обсервабилити

Всего лишь очередная задача по работе с данными

Первые пользователи ClickHouse осознали нечто фундаментальное: обсервабилити — это задача по работе с данными. Выбранная вами база данных определяет стоимость, масштабируемость и возможности вашей платформы для обсервабилити, поэтому её выбор часто является самым важным архитектурным решением при создании собственного решения или запуске компании в этой сфере.

Именно поэтому ClickHouse уже много лет находится в основе стеков обсервабилити. От отраслевых гигантов, таких как Netflix и eBay, до стартапов в сфере обсервабилити, таких как Sentry и Dash0, ClickHouse обеспечивает работу с логами, метриками и трейсами в огромных масштабах. Её колоночное хранилище, агрессивное сжатие и векторизованный движок выполнения запросов значительно снижают затраты и обеспечивают выполнение запросов за доли секунды, что необходимо инженерам для отладки систем в реальном времени без ожидания медленных инструментов.

Всё, что вам нужно, — это «широкие события»… и колоночное хранилище

В нашей предыдущей статье «Состояние обсервабилити на основе SQL» и последующих публикациях мы подробно исследовали этот тренд. Хотя тогда мы не дали ему названия, он идеально совпадает с сегодняшним движением «Observability 2.0»: единая модель, построенная вокруг «широких событий», а не «столпов». Слишком долго команды полагались на отдельные хранилища для логов, метрик и трейсов, что приводило к фрагментации, ручной корреляции и ненужной сложности. «Широкие события» устраняют эти разрозненные хранилища, объединяя все сигналы обсервабилити в единую, запрашиваемую структуру.

«Широкое событие» фиксирует полный контекст приложения в одной записи — пользователя, сервис, HTTP-путь, код состояния, результат кеширования и многое другое. Эта унифицированная структура является ключом к устранению разрозненности и обеспечению быстрого поиска и агрегации по данным высокой кардинальности — при условии, что у вас есть движок хранения, способный эффективно их сжимать и хранить!

Хотя NoSQL-решения, такие как поисковые движки, приняли эту структуру, им не хватало производительности агрегации, чтобы реализовать её потенциал — они отлично подходили для поиска и «нахождения иголок в галактиках», но не для агрегации по широким диапазонам. Секретный ингредиент ClickHouse для решения этой проблемы остаётся неизменным: колоночное хранение, богатая библиотека кодеков для глубокого сжатия и массивно-параллельный движок, оптимизированный для аналитических нагрузок.

Эффективность ресурсов и масштабируемость

В ClickHouse Cloud мы пошли дальше и внедрили объектное хранилище, чтобы обеспечить разделение хранения и вычислений, что крайне важно, если вам нужно масштабировать вашу систему обсервабилити до петабайт и более, а также эластично масштабироваться. Для поддержки ещё более требовательных сценариев мы также ввели разделение вычислений, позволяя пользователям выделять вычислительные ресурсы для конкретных нагрузок (например, для приёма данных и для выполнения запросов), читая при этом одни и те же данные.

По мере усложнения потребностей в обсервабилити мы поняли, что нативная поддержка JSON для полуструктурированных событий стала необходимым минимумом. ClickHouse развивался, чтобы удовлетворить эту потребность, добавив первоклассную поддержку полуструктурированных данных, сохраняя при этом преимущества колоночной обработки. Колонки создаются автоматически по мере поступления данных, и ClickHouse автоматически управляет повышением типов и ростом колонок. Это та самая «схема при записи» (schema-on-write), которая вам нужна для обсервабилити, с производительностью, сжатием и гибкостью, ожидаемыми от современного аналитического движка.

Рост популярности OpenTelemetry

Эта эволюция совпала с ростом популярности OpenTelemetry (OTel), который сейчас является стандартом де-факто для сбора телеметрии, включая логи, метрики и трейсы. Мы начали официально поддерживать и вносить вклад в OpenTelemetry Exporter для ClickHouse.

OpenTelemetry стал большим прорывом для нашей экосистемы. Он предлагает стандартизированный, независимый от поставщика способ сбора и экспорта данных обсервабилити, а его коллектор можно настроить для отправки данных напрямую в ClickHouse с помощью экспортёра, который мы теперь помогаем поддерживать. Мы тесно сотрудничали с сообществом, чтобы убедиться, что экспортёр надёжен, масштабируем и соответствует основным принципам ClickHouse.

Одной из самых сложных проблем, которую мы решили на раннем этапе, был дизайн схемы. Не существует универсальной схемы для обсервабилити; у каждой команды свои паттерны запросов, потребности в хранении и архитектуры сервисов. Поэтому экспортёр поставляется со схемами по умолчанию для логов, метрик и трейсов, которые хорошо подходят большинству пользователей, но мы призываем команды настраивать их в соответствии со своими собственными нагрузками.

Недостающие элементы

Но, как мы быстро поняли, просто иметь отличную базу данных, хорошую схему и надёжные средства сбора и приёма данных недостаточно. Инженерам нужен готовый к использованию приём данных, визуализация, оповещения и пользовательский интерфейс, адаптированный под их рабочий процесс. До сих пор это означало использование OpenTelemetry для сбора и Grafana для дашбордов.

Это работало достаточно хорошо — даже наша собственная команда по обсервабилити заменила Datadog стеком на базе ClickHouse, сэкономив миллионы и добившись снижения затрат более чем в 200 раз. Сегодня наша внутренняя система логирования хранит более 43 петабайт данных OpenTelemetry, со схемами и первичными ключами, настроенными специально для такого масштаба. Это доказало производительность и экономическую эффективность подхода, но мы знали, что опыт может быть проще.

Мы хотели чего-то более продуманного. Более простого способа для начала работы. Но самое главное — интерфейс, созданный для ClickHouse. И не просто любой интерфейс, а тот, который понимает, как строить эффективные запросы, выявлять паттерны в «широких событиях» и обеспечивать исключительный пользовательский опыт, не скрывая при этом мощь базы данных.

Наконец, хотя мы считаем, что обсервабилити на основе SQL сыграла важную роль в укреплении модели «широких событий», мы также понимали, что должны пойти навстречу пользователям. Поисковые движки, такие как стек ELK, добились успеха, потому что они предлагали нечто интуитивно понятное: естественный язык для запроса логов. Мы хотели предоставить такой же опыт нашим пользователям, но на базе ClickHouse.

Добро пожаловать, HyperDX

Именно тогда мы нашли HyperDX — опенсорсный слой для обсервабилити, специально созданный на ClickHouse. Когда HyperDX открыл исходный код своего интерфейса v2 в конце 2024 года, мы протестировали его внутри компании и быстро поняли, что это и есть недостающий элемент. Настройка была бесшовной, опыт разработчика — превосходным, и мы знали, что наши пользователи заслуживают того же.

HyperDX принёс всё, что мы искали: https://github.com/hyperdxio/hyperdx

Сбор данных на основе стандартов:** HyperDX с самого начала использовал OpenTelemetry, что идеально совпало с нашими инвестициями в экспортёр OpenTelemetry для ClickHouse.
Опенсорс в первую очередь:** Мы считаем, что надёжные инструменты для обсервабилити должны быть доступны всем, и HyperDX разделяет эту философию. Его облачно-нативная архитектура обеспечивает простую и экономичную эксплуатацию.

Помимо соответствия стандартам, HyperDX создан с учётом особенностей ClickHouse. Команда серьёзно относится к оптимизации запросов, так что вам не придётся об этом думать. Пользовательский интерфейс тесно связан с движком, обеспечивая быструю и надёжную производительность там, где миллисекунды имеют значение, особенно во время расследования инцидентов.

В сочетании со встроенным шлюзом для коллектора OpenTelemetry и схемой, оптимизированной для интерфейса HyperDX, ClickStack объединяет приём, хранение и визуализацию данных в единое решение. Схема по умолчанию спроектирована так, чтобы работать «из коробки», поэтому пользователям не нужно о ней думать — если только они не захотят настроить её под свои конкретные нужды.

Простота ClickStack означает, что каждый слой масштабируется независимо. Нужна более высокая пропускная способность приёма данных? Просто добавьте больше шлюзов коллектора OpenTelemetry. Нужно больше ресурсов для запросов или хранения? Масштабируйте ClickHouse напрямую. Эта модульная конструкция позволяет легко расти вместе с вашими данными и вашей командой — без полной перестройки стека.

С момента приобретения HyperDX мы сосредоточились на упрощении продукта и расширении его гибкости. Вы можете использовать схему по умолчанию для бесшовной настройки «из коробки» или использовать собственную схему, адаптированную под ваши нужды. Как и в случае с самим ClickHouse, мы понимаем, что универсального решения не существует, и гибкость — ключ к масштабированию.

Ваш браузер не поддерживает видео.

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

Ваш браузер не поддерживает видео.

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

Ваш браузер не поддерживает видео.

Возможно, самое важное — стек стал проще. С утверждением OpenTelemetry в качестве повсеместного стандарта все данные теперь поступают через OTel-коллектор. Настройка по умолчанию использует продуманную схему для быстрого старта, но пользователи могут изменять или расширять её по мере необходимости. Стек является нативным для OpenTelemetry, но не эксклюзивным для него: благодаря открытой схеме HyperDX может работать и с вашими существующими пайплайнами данных и схемами.

Заключение и взгляд в будущее

ClickStack представляет собой следующий этап развития инвестиций ClickHouse в экосистему обсервабилити, предлагая интуитивно понятное и продуманное полностековое решение на базе открытого исходного кода и открытых стандартов. Объединяя высокопроизводительный колоночный движок ClickHouse, стандарты инструментирования OpenTelemetry и специализированный интерфейс HyperDX в единое решение, мы наконец делаем современный подход к обсервабилити доступным для всех.

Наша приверженность открытому исходному коду гарантирует, что ClickStack останется доступным для всех — от развёртываний с одним сервисом до систем объёмом в несколько петабайт. Мы продолжим инвестировать как в ядро базы данных для высокопроизводительной обсервабилити, так и в интеграции с уже зарекомендовавшими себя инструментами, такими как Grafana, обеспечивая бесшовную совместимость с существующими стеками.

С ClickStack мы предлагаем больше, чем просто очередной инструмент — мы предоставляем единую основу, где все телеметрические сигналы сходятся в высокопроизводительной колоночной базе данных, дополненной запросами на естественном языке, воспроизведением сессий и возможностями оповещения прямо «из коробки».

Начните свой путь с ClickStack, ознакомившись с нашим руководством по началу работы в документации.

Начните работать с ClickHouse Cloud сегодня и получите $300 в виде кредитов. По окончании 30-дневного пробного периода вы можете продолжить работу по плану с оплатой по мере использования или связаться с нами, чтобы узнать больше о наших скидках за объём. Посетите нашу страницу с ценами для получения подробной информации.

----

Что предлагается?

Высокопроизводительный опенсорсный стек для обсервабилити

Молниеносные запросы и мощные агрегации по логам, метрикам, трейсам, воспроизведениям сессий и ошибкам с непревзойденной эффективностью использования ресурсов даже для данных с самой высокой кардинальностью. Всё в одном стеке — на базе ClickHouse.

---

Поиск, дашборды и оповещения

ClickStack объединяет логи, метрики, трейсы и воспроизведение сессий на одной платформе с помощью интерфейса HyperDX. Оптимизированный для ClickHouse, он поддерживает быстрый поиск в стиле Lucene и полный доступ по SQL для углубленного анализа с использованием более 100 встроенных функций.
Создавайте дашборды и оповещения с минимальной настройкой. Выявляйте аномалии с помощью дельт событий и ускоряйте анализ первопричин, используя паттерны событий.

Хранилище на базе ClickHouse

Работая на базе ClickHouse, HyperDX выполняет поиск по терабайтам данных за секунды и ежедневно принимает миллиарды событий высокой кардинальности. ClickStack поставляется с оптимизированными схемами, что устраняет необходимость в ручной настройке и позволяет вам сосредоточиться на получении инсайтов.

В ClickHouse Cloud ClickStack получает эластичное масштабирование и экономическую эффективность благодаря полному разделению хранения и вычислений. Приём данных и запросы могут выполняться независимо на выделенных ресурсах благодаря разделению между вычислительными мощностями, что обеспечивает стабильную производительность при любом масштабе.

Сбор данных

ClickStack нативно поддерживает стандарт OpenTelemetry, собирая логи, метрики и трейсы в виде «широких событий» — записей с богатым контекстом, которые объединяют данные обсервабилити в ClickHouse.
Благодаря нативной поддержке JSON, ClickHouse эффективно обрабатывает развивающиеся, полуструктурированные данные. Поля создаются автоматически при приёме данных, а сжатое колоночное хранилище обеспечивает быстрые запросы и высокую степень сжатия без необходимости предварительного определения схемы.

---

Хотите собрать свой собственный стек?

Нужен собственный пайплайн или схема? Интерфейс HyperDX не зависит от схемы и работает с любым пайплайном телеметрии, подключаясь к любому экземпляру ClickHouse для полного контроля над вашими данными обсервабилити.
Создаёте свой собственный стек? ClickHouse предоставляет все необходимые инструменты: высокопроизводительный движок SQL, приём данных по HTTP, масштабируемое хранилище MergeTree и материализованные представления для трансформации данных в реальном времени. Для гибкой работы с дашбордами используйте плагин для Grafana, чтобы сопоставлять данные из ClickHouse с другими источниками.

---

Снизьте ваши затраты на обсервабилити

ClickHouse обеспечивает исключительную экономическую эффективность, избегая накладных расходов систем на базе JVM, благодаря аппаратно-оптимизированной колоночной структуре, которая сокращает объём хранения до 90% без ущерба для скорости.
Бесшовное масштабирование от одной машины до сотен ядер, с автоматическим ярусным хранением данных между локальными дисками и объектным хранилищем для максимальной производительности и эффективности.

✨ Простое развертывание и обслуживание

Оцените простоту эксплуатации благодаря однородной архитектуре ClickHouse — один исполняемый файл справляется со всем, от автономных развертываний до огромных кластеров.
Для нулевых накладных расходов выберите ClickStack в ClickHouse Cloud для автоматического масштабирования, резервного копирования и обслуживания. Разделение хранения и вычислений обеспечивает как бесконечную масштабируемость, так и производительность запросов менее чем за секунду благодаря интеллектуальному кэшированию.

📄 Откройте для себя обсервабилити в реальном времени

ClickHouse спроектирован для обработки огромных объёмов непрерывных потоков входящих данных, поддерживая скорость приёма данных в гигабайты в секунду, при этом обеспечивая доступность новых данных для поиска с задержкой менее секунды.
Созданный для самых интенсивных нагрузок в реальном времени, HyperDX использует мощный набор функций агрегации и анализа ClickHouse с глубокими оптимизациями для обеспечения молниеносных запросов в системе обсервабилити.

💡 Не только для обсервабилити

ClickHouse — это не просто хранилище для обсервабилити, это высокопроизводительная SQL база данных, созданная для быстрой аналитики.
Обсервабилити — это просто еще одна задача по работе с данными, и с ClickHouse вы можете бесшовно объединять данные обсервабилити, бизнес-данные и данные безопасности в одной системе, получая более глубокие инсайты по всему вашему стеку с помощью вашего любимого инструмента визуализации.

Инструментируйте ваши приложения

Отслеживайте каждый лог, API-запрос, запрос к БД и многое другое всего несколькими строками кода. Инструментируйте и наблюдайте за своим стеком за считанные минуты с ClickStack.