Yuriy Gavrilov: posts tagged Data

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 без установки проприетарных драйверов.

Действительно ли данные готовы к ИИ

Sat, 14 Mar 2026 00:19:28 +0300

Автор: Джейкоб Мэтсон

https://motherduck.com/blog/bird-bench-and-data-models

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

Теперь они у меня есть.

Все началось с вопроса одного из наших инвесторов: *“Как различные модели справляются с BIRD при использовании MotherDuck MCP?”* Поэтому я провел эксперимент. Три передовые LLM модели (`Claude Opus 4.5`, `GPT-5.2` и `Gemini 3 Flash`), каждая из которых подключена к базе данных через сервер `MotherDuck MCP`, были запущены на наборе данных `BIRD Mini-Dev`.

Пояснение:

MCP (Model Context Protocol):** Стандарт, позволяющий ИИ-моделям безопасно и стандартизировано подключаться к внешним источникам данных и инструментам.

BIRD (BIg Bench for Large-scale Database Grounded Text-to-SQL):** Популярный и сложный бенчмарк (набор тестов) для оценки того, насколько хорошо нейросети умеют переводить естественный язык в SQL-запросы.

Mini-Dev:** Это официальная выборка из 500 вопросов для разработки из бенчмарка BIRD. Она охватывает 11 баз данных в сферах финансов, спорта, образования и здравоохранения.

Модели данных здесь простые. В среднем 7 таблиц на базу данных. Ни в одной нет больше 13 таблиц. Объединения (joins) в основном «один-ко-многим», максимальная глубина — два или три перехода, ноль отношений «многие-ко-многим». Это тот тип схемы, который можно понять за пять минут, прочитав `DDL`.

Пояснение: `DDL` (Data Definition Language) — это часть SQL, используемая для описания структуры базы данных (создание таблиц, колонок, связей).

Результат? 95% точности. Никакого семантического слоя. Никакой истории запросов. Никакого специального контекста. Только схема базы данных.

Но это число требует «звездочки» (примечания), и, честно говоря, эта звездочка — самая интересная часть.

Что на самом деле означают 95%

Вот что я измерял на самом деле.

Бенчмарк BIRD оценивает точность, используя Execution Accuracy (EX): запускается предсказанный SQL и «золотой» (эталонный) SQL, сравниваются наборы результатов, и ставится бинарная оценка «сдал/не сдал». При этих строгих правилах текущий уровень развития технологий (SOTA) составляет около 76. Мои модели набрали 64 на тренировочной выборке и 58 на тестовой.

Звучит плохо. Но у строгой оценки BIRD есть хорошо задокументированная проблема. В статье 2025 года, представляющей метрику `FLEX`, было обнаружено, что точность выполнения (execution accuracy) BIRD совпадает с оценками экспертов-людей только в 62% случаев. Почти 4 из 10 суждений ошибочны, в основном это ложноотрицательные результаты, когда бенчмарк отвергает ответы, которые люди бы приняли.

Эти 62 бросились мне в глаза, потому что они почти точно совпадают с моей смешанной точностью при строгой оценке в 60.5 (64 обучение / 58 тест). То же наблюдение, но с другой стороны. Метрика `FLEX` пришла к этому с помощью проверяющих людей. Я пришел к этому, ослабив условия тестирования.

Подумайте, что это значит для таблицы лидеров. Если бенчмарк согласен с людьми только в 62 случаев, то чтобы набрать выше 62 по строгим правилам, вы должны начать воспроизводить ошибки бенчмарка. Вы перестаете учиться писать правильный SQL. Вы начинаете учиться соответствовать специфической, иногда ошибочной интерпретации каждого вопроса в BIRD. Системы с рейтингом 76 закрепили эти ошибки суждения в своем обучении. Они получают более высокие баллы, становясь *хуже* в выполнении реальной задачи.

Поэтому я построил более реалистичную оценку. Я разделил 500 вопросов на тренировочный набор (151 вопрос) и тестовый набор (349 вопросов).

Я использовал тренировочный набор (train) для калибровки оценки: вручную пересматривал ошибки, создавал исправленные «платиновые» ответы там, где «золотой» SQL BIRD был ошибочным, и настраивал правила частичного совпадения. Тестовый набор (test) был контрольным.

Вот как выглядит точность, если смягчать критерии оценки уровень за уровнем:

Уровень оценки (Scoring Tier)	Train	Test	Что добавляется
Только совпадение с Gold (≈ офиц. BIRD)	64.0	58.2	Строгое равенство наборов результатов
+ Платиновые ответы	73.1	58.5	Исправляет известные ошибки в «золотом» SQL BIRD (см. примечание ниже)
+ Допуск форматирования	78.8	65.5	Различия в `DISTINCT`, лишние колонки, округление
+ Судья LLM	94.9	94.4	“Принял бы человек этот ответ?”

Примечание: «Платиновые» исправления существуют только для тренировочного набора, так как я вручную проверил эти 151 вопрос. Вот почему уровень «Платина» почти не меняется на тесте +0.3 pp против +9.1 pp на тренировке). Но посмотрите на уровень с судьей: 94.9 на тренировке и 94.4 на тесте. Разница всего в половину процентного пункта. Оценка держится на контрольной выборке даже без моих исправлений вручную.

Результаты тренировочной выборки (151 вопрос, все 3 модели):

Модель	STRICT (≈ BIRD EX)	REALISTIC	Общая стоимость	Вызовы инструментов (P5 / Median / P95)
`Gemini 3 Flash`	68.2	94.0	1.80	3 / 6 / 9
`Claude Opus 4.5`	64.9	95.4	26.37	4 / 6 / 9
`GPT-5.2`	58.9	95.4	6.87	4 / 7 / 12

Результаты тестовой выборки (349 вопросов, 2 модели):

Модель	STRICT (≈ BIRD EX)	REALISTIC	Общая стоимость	Вызовы инструментов (P5 / Median / P95)
`Gemini 3 Flash`	60.7	94.6	3.96	4 / 6 / 9
`GPT-5.2`	55.6	94.3	15.32	4 / 7 / 11

*Примечание: `Claude Opus` не запускался на тестовом наборе. После того как все три модели сошлись на ~95% на тренировке, тратить еще 60+, чтобы доказать то же самое на 349 вопросах, показалось нецелесообразным.*

Медианная модель делает 6-7 вызовов инструментов MCP на вопрос при лимите в 10 итераций. Типичный вопрос выглядит так: изучить схему, просмотреть некоторые колонки, набросать запрос, проверить результаты, уточнить, готово. Некоторые модели, такие как `GPT-5.2`, делают несколько вызовов инструментов за итерацию, поэтому его показатель P95, равный 12, превышает лимит итераций.

Все три модели достигают 94-95% при реалистичной оценке, независимо от того, где они начинают при строгой оценке. На тренировочной выборке разрыв между «лучшим» и «худшим» сокращается с 12.6 процентных пунктов до 1.4. На тесте — с 5.1 до 0.3. Берите любую передовую модель.

Бенчмарк иногда ошибается

BIRD — хороший бенчмарк. Но в нем есть баги. Только в тренировочном наборе (151 вопрос) я нашел 49 случаев, где «золотой» SQL явно неверен. Я не проверял вручную тестовый набор, поэтому реальное число для всех 500 вопросов, вероятно, выше.

Вот пример, который мне запомнился. Вопрос просит список школ, чей совокупный балл превышает 1500. «Золотой» SQL проверяет `count` (количество) студентов, набравших более 1500 баллов. Совершенно другой запрос, совершенно другой ответ. Вы читаете вопрос, читаете «правильный» ответ и думаете: подождите, но спрашивали-то не об этом.

Я создал исправленные «платиновые» ответы для этих случаев. В среднем около 14 из 151 вопроса тренировочной выборки для каждой модели совпали с платиновым ответом вместо золотого, добавив 9.1 процентных пунктов.

Людей не волнует форматирование

На тренировочной выборке еще +5.7 pp получается за счет принятия результатов, которые верны по существу, но не проходят проверку на строгое равенство:

Лишние колонки (30 случаев): Модель вернула запрошенные данные плюс дополнительный контекст. Человек сказал бы «спасибо, это полезно». Бенчмарк говорит «провал».
Несовпадения `DISTINCT` (41 случай): Модель использовала `SELECT DISTINCT`, когда в золотом ответе этого не было, или наоборот. Уникальные значения совпадают идеально. Человек бы даже не заметил.
Различия в округлении (3 случая): Золотой ответ 24.67, ответ модели 24.6667. То же число, разная точность.

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

Человек (LLM)-в-петле (The LLM-in-the-Loop)

Оставшийся разрыв (16 pp на тренировке, 29 pp на тесте) закрывается судьей LLM. Я использовал `Gemini 3 Flash` для проверки каждого «проваленного» ответа с вопросом: *действительно ли этот SQL отвечает на вопрос?*

На тестовой выборке судья выполняет больше тяжелой работы, потому что там нет «платиновых» исправлений для предварительного отлова багов бенчмарка. Что именно он спасал?

Причина	Кол-во	Что произошло
Больше отфильтровано (Missing rows)	57	Модель отфильтровала строже, чем золотой стандарт, но это обоснованно.
Лишние строки (Extra rows)	33	Модель интерпретировала вопрос более широко.
Близкие значения (Values close)	19	Числовые результаты в пределах допуска.
Пустой результат	14	Модель ничего не вернула, но логика была верной (данных нет).
Пропущенные колонки	11	Возвращено меньше колонок, но ответ на вопрос дан.

Это оценочные суждения. Должен ли запрос «перечислите все школы в районе» включать чартерные школы? Разумные люди могут не согласиться. Строгий бенчмарк выбирает одну интерпретацию и наказывает за все остальные. Судья просто спрашивает, можно ли обосновать интерпретацию модели.

Если вы создаете ИИ-аналитику, это важно. Никто не выпускает продукт text-to-SQL, где пользователь видит сырые результаты без этапа проверки. Всегда есть человек или LLM, проверяющий выходные данные. Эти 94-95% отражают то, как эти продукты работают на самом деле. 58-64% отражают то, как работают бенчмарки.

А как насчет контекста?

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

Я протестировал это. Те же 500 вопросов, все модели, с комментариями к колонкам каждой таблицы и без них.

Схема	Train	Test
Без комментариев	94.9	94.4
С комментариями	96.0	94.6
Дельта	1.1 pp	0.2 pp

Один процентный пункт на тренировке, почти ничего на тесте. В большинстве вопросов правильность не изменилась.

Если разбить по базам данных, становится интересно. Чем сложнее схема, тем больше помогают комментарии (усредненно по train и test):

База данных	Базовая точность	Эффект комментариев
`debit_card_specializing`	85.5 (самая сложная)	8.7 pp
`european_football_2`	93.2	3.4 pp
`california_schools`	95.7 (самая легкая)	2.9 pp

Комментарии помогают, когда схема действительно запутанная. Таблица `debit_card_specializing` (попробуйте угадать, как выглядит эта схема) получила самый большой прирост. Но схемы с интуитивными названиями и очевидными связями? Там комментарии сделали только хуже. У моделей уже сформировалась правильная ментальная модель, а комментарии внесли шум.

Каждый разработчик знает это о комментариях в коде. Полезны при реальной неоднозначности. Вредны, когда констатируют очевидное. `// увеличить i на 1` еще никому не помогло.

Почему простые модели данных работают

Базы данных BIRD — это не корпоративные хранилища данных. Они простые:

7 таблиц в среднем.
9 внешних ключей в среднем, в основном «один-ко-многим».
Ноль связей «многие-ко-многим».
Глубина join макс. 2-3 перехода, нет глубоких иерархий.

LLM читают эти схемы так же, как опытный аналитик читает DDL. Они видят таблицу `schools` с колонками `school_name`, `district` и `enrollment`, и они знают, что делать. Внешний ключ от `schools` к `scores`? Они знают, как их соединить (join). Никому не нужен семантический слой, чтобы объяснить, что “enrollment” означает «количество студентов».

Хорошее моделирование данных — это и есть семантический слой. Когда ваши таблицы названы хорошо, а объединения прямолинейны, у LLM есть всё необходимое.

Во что я бы инвестировал в первую очередь

Каждая среда уникальна, но вот как бы я расставил приоритеты, основываясь на том, что увидел:

Начните с модели данных. Чистые таблицы, понятные названия, простые объединения. Если опытный аналитик может посмотреть на вашу схему и понять ее за несколько минут, то и LLM сможет.
Затем добавьте целевой контекст. Комментарии к колонкам и метаданные, но только там, где действительно существует путаница. Документируйте таблицы типа `debit_card_specializing`, а не `schools`.
История запросов идет следом. Она становится важнее по мере усложнения предметной области, особенно для обнаружения недокументированных бизнес-правил (вроде “abnormal GOT > 60”). Базы данных BIRD имеют простые правила. Но я работаю над (проектом) `DABstep`, у которого простая модель данных, но очень сложные правила предметной области. Тот вид знаний, который живет в головах людей, а не в названиях колонок. Там история запросов и подобранный контекст будут значить гораздо больше. Но даже тогда чистая модель данных стоит на первом месте.

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

Начните сейчас

Планка для «данных, готовых к ИИ», ниже, чем вам говорит индустрия.

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

Разрыв между «точностью бенчмарка» и «примет ли это человек?» составил 31 pp на тренировочной выборке и 36 pp на тестовой. Это огромный разрыв, и он закрывается в тот момент, когда вы включаете человека или LLM в цикл проверки. Именно так и работает любой продукт ИИ-аналитики.

Если ваша модель данных чиста, начните сегодня. Направьте LLM на вашу схему и задавайте вопросы. Если ваша модель данных не чиста, теперь вы знаете, с чего начать.

***

Итоги статьи

Проблема: Принято считать, что для работы ИИ с базами данных (Text-to-SQL) нужны сложные семантические слои, история запросов и контекст.
Эксперимент: Автор протестировал работу современных LLM (Claude, Gemini, GPT) на известном наборе данных BIRD.
Открытие 1: Формальные бенчмарки занижают качество работы ИИ. Они требуют строгого совпадения SQL-запросов, хотя люди принимают ответы с правильными данными, но другим форматированием (лишние колонки, другой порядок сортировки). Истинная (“реалистичная”) точность моделей достигает 95%, тогда как бенчмарк показывает около 60%.
Открытие 2: “Готовность данных к ИИ” сводится к понятной структуре базы данных. Чистые таблицы, внятные названия колонок и простые связи работают лучше, чем нагромождение комментариев.
Открытие 3: Дополнительные комментарии (контекст) нужны только для реально запутанных схем. В простых случаях они даже мешают, создавая шум.
Вывод: Не тратьте ресурсы на сложные семантические надстройки. Инвестируйте в чистоту модели данных (понятные имена таблиц и полей). Хорошая модель данных — это и есть лучший семантический слой для ИИ.

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

Data Contracts — соглашение между производителями и потребителями данных

Sun, 08 Feb 2026 00:29:11 +0300

о книге «Data Contracts» или как договориться о данных в эпоху хаоса и вернуть им ценность

Введение: Кризис доверия в мире данных
Книга Чада Сандерсона и Марка Фримена «Data Contracts» выходит в момент глубокого кризиса в индустрии данных. Несмотря на триллионы долларов инвестиций в Modern Data Stack, облака и ИИ, компании всё чаще сталкиваются с парадоксом: данных больше, чем когда-либо, а извлекаемая ценность — под вопросом. Дашборды врут, модели ML ошибаются, а инженеры данных погребены под лавиной инцидентов. Авторы дают диагноз этой болезни: «данные долг» (data debt), и предлагают радикальное лечение: «данные контракты» (data contracts).

Часть 1: Диагноз — Эпидемия данных долга
Авторы проводят читателя через историческую эволюцию, объясняя, как мы пришли к текущему хаосу.

Золотой век и падение Хранилищ Данных: Раньше централизованные хранилища данных, созданные архитекторами, обеспечивали «единый источник истины». Это было медленно, дорого, но надежно.
Agile, микросервисы и «дамп данных»: Софтверные компании, движимые скоростью, убили роль архитектора данных. Данные перестали проектировать — их начали «сливать» в data lakes. Разрыв между командами, создающими данные (продуктовые разработчики, OLTP) и использующими их (аналитики, дата-сайентисты, OLAP), стал пропастью.
Иллюзия Modern Data Stack: Такие инструменты как Snowflake, Fivetran и dbt решили проблему «как» работать с данными, но усугубили проблему «что» и «почему». Они упростили перемещение и трансформацию беспорядочных данных, легализовав отсутствие дисциплины. Результат — взрывные затраты, непонятные SQL-запросы-монстры и полная потеря доверия.

Ключевой вывод: Данные долг — это не техническая проблема, а организационная и коммуникационная. Он накапливается, когда команды, меняющие данные, не знают, кто и как их использует, а потребители данных не могут доверять их стабильности.

Часть 2: Новый императив — Data-Centric AI
Авторы блестяще связывают кризис данных с новой парадигмой в машинном обучении. Эндрю Нг провозгласил сдвиг от model-centric AI (бесконечная настройка алгоритмов) к data-centric AI (систематическое улучшение качества данных для обучения).

Почему это важно? Модели, особенно с появлением больших языковых моделей (LLM), становятся товаром. Любой может вызвать мощнейшую модель через API. Конкурентное преимущество теперь создается не алгоритмом, а качественными, уникальными данными, на которых он обучается и работает.
Парадокс: В момент, когда бизнесу как никогда нужны чистые, надежные данные для ИИ, его инфраструктура данных наименее к этому готова. Data-Centric AI требует фундамента, которого нет — управляемого, контрактного подхода к данным.

Часть 3: Лечение — Data Contracts как API для доверия
Data Contracts — это ядро предлагаемого решения. Это не юридические документы, а машиночитаемые соглашения, оформленные как код.

Что это такое? Контракт между производителем данных (например, сервис, который генерирует события о покупках) и потребителем данных (например, команда аналитики, строящая отчет по выручке).
Что в него входит? Схема данных (типы, имена полей), семантика (что означает каждое поле, бизнес-правила), соглашения об уровне обслуживания (SLAs — частота обновления, задержка), правила обработки конфиденциальных данных (PII).
Как работает? Контракт устанавливается через API. При попытке изменить источник данных (удалить поле, изменить тип) система проверяет все зависимые контракты и либо блокирует изменение, либо требует скоординированной миграции. Это автоматизирует коммуникацию и создает «защитные ограждения».

Часть 4: Практика — Качество данных как измеримый процесс
Авторы уходят от утопии «идеальных данных» к прагматичному управлению качеством. Они предлагают измерять его через:

Опережающие индикаторы: Наличие владельцев у источников данных, уровень доверия команд к данным (измеряется через опросы), объем данных долга (сложность запросов, количество backfill-задач).
Запаздывающие индикаторы: Время простоя данных (data downtime), количество инцидентов с реальным бизнес-влиянием (например, ошибочный отзыв товара).

Главная мысль: нужно говорить с бизнесом не о «качестве», а о рисках и потерях денег из-за его отсутствия.

Заключение: Возвращение к дисциплине через инновации
«Data Contracts» — это манифест за возвращение инженерной дисциплины в мир данных, но на новом уровне. Это не призыв вернуться к медленным централизованным хранилищам. Это предложение создать децентрализованную, но управляемую экосистему данных, где скорость микросервисов сочетается с надежностью контрактов.

Книга является обязательным чтением для:

Руководителей данных (CDO, Head of Data), чтобы понять стратегический ответ на вызовы data debt и Data-Centric AI.
Инженеров данных и архитекторов, ищущих практические методы наведения порядка.
Продуктовых менеджеров и разработчиков, которые должны осознать, что их данные — это продукт для внутренних клиентов.
Дата-сайентистов и аналитиков, уставших от нестабильных данных.

Data Contracts — это больше, чем технология. Это философия сотрудничества, которая превращает данные из источника постоянных проблем в настоящий актив, способный обеспечить конкурентное преимущество в эпоху ИИ.

Приложение пример полей и контракта данных

Атрибуты контракта (обязательные и опциональные)

Атрибут	Тип	Обязательный	Описание
domain	string	Да	Домен Data Mesh
data_product	string	Да	Название дата-продукта
owner	string	Да	Контакт команды-владельца
schema	object	Да	Схема данных (Avro/JSON/Parquet)
slas	object	Да	Требования к свежести, доступности
security	object	Нет	Поля ПДн, политики доступа
quality_checks	array	Нет	Список проверок качества
consumers	array	Нет	Список команд-потребителей
lifecycle	object	Нет	Правила хранения, архивации

version: 1.0
domain: sales
owner: team-sales@company.com
data_product: customer_events
schema:
  type: avro/json
  definition: { ... }
slas:
  freshness: "5m"
  completeness: "99.9%"
security:
  pii_fields: ["email", "phone"]
  masking: dynamic
quality_checks:
  - type: null_check
    columns: ["user_id"]
  - type: range_check
    column: "amount"
    min: 0
consumers:
  - analytics_team
  - ml_team
lifecycle:
  retention_days: 365
  archive_after: 90

Еще один дата каталожик – Marmot

Sun, 08 Feb 2026 00:06:32 +0300

https://github.com/marmotdata/marmot

Marmot is an open-source data catalog designed for teams who want powerful data discovery without enterprise complexity. Built with a focus on simplicity and speed, Marmot helps you catalog assets across your entire data stack – from databases and APIs to message queues and data pipelines.

Unlike traditional catalogs that require extensive infrastructure and configuration, Marmot ships as a single binary with an intuitive UI, making it easy to deploy and start cataloging in minutes.

Built for Modern Data Teams

Deploy in Minutes: Single binary, Docker, or Kubernetes – no complex setup required
Powerful Search: Powerful query language with full-text, metadata, and boolean operators
Track Lineage: Interactive dependency graphs to understand data flows and impact
Flexible Integrations: CLI, REST API, Terraform, and Pulumi – catalog assets your way
Lightweight: PostgreSQL-backed with minimal resource requirements

Анатомия невидимости: гид по рекламным идентификаторам (2025+)

Tue, 20 Jan 2026 22:16:15 +0300

В современном маркетинге данные — это новая нефть, а рекламный идентификатор (Advertising ID) — это трубопровод, по которому эта нефть течет. От смартфона в кармане до умного телевизора в гостиной: каждое устройство имеет свой цифровой паспорт.

В этой статье мы разберем не только скрытую механику «рекламной слежки», но и юридические риски для бизнеса в РФ, новые технологии обхода блокировок и то, как клиентский опыт (CX) меняется в эпоху тотальной приватности.

1. Зоопарк идентификаторов: Кто есть кто

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

📱 Мобильные устройства (MAID — Mobile Advertising IDs)

Это самые ценные идентификаторы, так как смартфон является наиболее персональным (“интимным”) устройством.

IDFA (Identifier for Advertisers): Стандарт Apple (iOS). После внедрения *App Tracking Transparency (ATT)* в iOS 14.5 доступ к нему закрыт по умолчанию.
> Важно: Лишь 20-30% пользователей в мире нажимают «Разрешить» (Allow Tracking). Это создало огромную «слепую зону» в аналитике.
GAID (Google Advertising ID) / AAID: Аналог для Android. Позволяет связывать активность пользователя между разными приложениями. Google также движется в сторону ограничения доступа через инициативу Privacy Sandbox on Android.

📺 Телевизоры и Set-Top Box (CTV IDs)

С ростом Smart TV и стримингов маркетологи теперь трекают пользователей «на диване».

Примеры: TIFA (Samsung), Roku ID, Amazon Fire TV ID.
Логика Household (Домохозяйство): В отличие от личных смартфонов, эти ID часто привязаны к семье.
- *Инсайт эксперта по данным:* Это создает проблему «шумных данных». Если вы рекламируете женские духи, а телевизор смотрит муж или ребенок, атрибуция будет ошибочной. Для очистки данных используются Cross-Device графы, связывающие TV ID с мобильными телефонами, находящимися в той же Wi-Fi сети.

🌐 Веб-идентификаторы

Third-Party Cookies: Старейший и умирающий стандарт. Текстовые файлы, оставляемые рекламными сетями (не владельцем сайта) в браузере.
Stable IDs / Hashed Emails: Новая валюта рынка. Это зашифрованные (хэшированные) адреса электронной почты или номера телефонов. Используются в таких решениях, как *Unified ID 2.0*.

🔍 Юридический комментарий: Персональные данные в РФ

Согласно 152-ФЗ «О персональных данных» normativ.kontur.ru и позиции Роскомнадзора, любые данные, которые позволяют (даже косвенно) идентифицировать личность, могут считаться персональными данными (ПДн).

Является ли IDFA/GAID персональными данными? Формально — нет, это псевдонимизированные данные. НО: Как только вы обогащаете этот ID номером телефона из вашей CRM или связываете его с профилем конкретного клиента, он становится ПДн.
Риски: Хранение баз с “просто ID” безопаснее, но как только происходит «склейка» (matching) с реальным человеком, вы обязаны иметь согласие на обработку (и часто — на передачу третьим лицам, т.е. рекламным сетям).
Штрафы: За нарушение правил обработки ПДн штрафы для юрлиц могут достигать 18 млн рублей (при повторном нарушении при локализации), а за утечки — вплоть до оборотных штрафов (обсуждаемые поправки). Подробнее о сборе данных adesk.ru.

2. Механика: Как они строятся и живут

Формула генерации

Большинство мобильных ID (GAID, IDFA) представляют собой UUID (Universally Unique Identifier) версии 4. Это 128-битное число.

$$ P(collision) \approx \frac{n^2}{2 \times 2^{128}} $$

Вероятность совпадения двух таких ID астрономически мала.

Пример: `123e4567-e89b-12d3-a456-426614174000`
Генерация: Алгоритм использует криптографически стойкий генератор случайных чисел (CSPRNG) + энтропию системы (время запуска, «шум» железа).

Жизненный цикл и безопасность

Главное отличие рекламного ID от аппаратного (IMEI) — возможность сброса (Resettability).

Действие пользователя: В настройках конфиденциальности нажимается «Сбросить рекламный ID».
Реакция ОС: Генерируется новый UUID.
Результат: Для рекламных сетей устройство становится «чистым листом». История интересов разрывается.

3. E-commerce: Сквозь экраны к покупке

В интернет-коммерции ID — это клей, собирающий разрозненные клики в путь покупателя (Customer Journey Map).

Сквозная аналитика (Cross-Device)

Как понять, что телефон `User_A` и ноутбук `Cookie_B` — это один человек?

Deterministic (Точный метод): «Золотой стандарт». Пользователь залогинился в магазине под своим Email на обоих устройствах. Связка 100% достоверна.
Probabilistic (Вероятностный метод): Система видит, что телефон и ноутбук ежедневно выходят в сеть с одного IP-адреса Wi-Fi в одно время, имеют похожие паттерны посещения сайтов. Алгоритмы с вероятностью 90%+ «склеивают» профили в один Household.

Механика таргетинга (RTB – Real Time Bidding)

Процесс показа рекламы занимает менее 100 миллисекунд:

Вы смотрите кроссовки в приложении (система фиксирует ваш `GAID`).
Вы открываете новостной сайт. Сайт отправляет ваш `GAID` на рекламную биржу.
DSP (платформа закупки) узнает ваш ID в базе сегментов: *«Это тот же, кто смотрел Nike 5 минут назад!»*.
Происходит мгновенный аукцион, ставка выигрывает, и вам показывается баннер.

4. Феномен Amazon Ads и Retail Media

Amazon (и его аналоги в РФ) стоит особняком. Это закрытая экосистема (Walled Garden), чья сила не в технологиях трекинга, а в транзакционных данных. Им не нужно *угадывать*, что вы хотите купить, они *знают*, что вы покупаете.

Идентификатор Amazon

В основе лежит не «летучий» UUID устройства, а Internal Customer ID, жестко привязанный к аккаунту.

Формула матчинга: Для обмена данными с внешним миром используется Hashed Email (HEM). Ваш email превращается в необратимую строку (обычно SHA-256).
Clean Rooms (AMC): Amazon Marketing Cloud позволяет крупным брендам загружать свои CRM-данные в защищенную среду, где они пересекаются с данными Amazon. Рекламодатель получает инсайты (например, “Клиенты, купившие кофемашину у нас на сайте, покупают капсулы на Amazon”), но не видит персональных данных конкретных людей.

5. Война за приватность и обходные пути

Индустрия находится в состоянии холодной войны между запросом на приватность и эффективностью.

Главные сложности

Apple ATT: Обрушение эффективности рекламы Facebook на iOS. Стоимость привлечения клиента (CAC) выросла на 40-60%.
Смерть Cookies: Google Chrome (хоть и откладывает полное отключение) внедряет Privacy Sandbox, заменяя индивидуальные куки на FLoC/Topics API (группировку по интересам).
Блокировщики: AdBlock режет запросы к доменам трекеров. (на уровне DNS, например AdGuard)

Как рынок обходит блокировки? Технический Deep Dive

Server-Side Tracking (S2S / CAPI):
Вместо отправки данных пикселем из браузера (JS), данные о покупке отправляются напрямую с бэкенда магазина на сервер рекламной системы (например, через Facebook Conversions API).

Плюс:* Не блокируется AdBlock и браузерами. Точность данных выше.
Минус:* Сложная техническая реализация. Требует согласия пользователя на передачу данных.

Fingerprinting (Серый метод):
Сбор уникальных параметров устройства без использования cookie:

`Screen Resolution` + `User Agent` + `Battery Level` + `System Fonts` + `AudioContext`
Такой “цифровой отпечаток” уникален для 95% пользователей. Apple и Google активно борются с этим методом, считая его нарушением приватности.

Итог: Тренды 2025+ и рекомендации

Эра «дикого запада», когда можно было незаметно следить за каждым шагом, заканчивается. Мы переходим в эру агрегированных данных и доверительного маркетинга (Zero-Party Data).

Ключевые тренды:

First-Party Data — король: Компании, владеющие собственными данными и прямым контактом с клиентом (Email, App), выигрывают. Зависимость от Facebook становится токсичной.
Retail Media Networks: Бум рекламных сетей маркетплейсов. Они обладают данными о деньгах, а не о кликах.
AI вместо Cookies: Алгоритмы машинного обучения будут «достраивать» потерянные данные. Например, Google GA4 уже использует моделирование конверсий для пользователей, отказавшихся от трекинга.

✅ Рекомендация

Инвестируйте в CDP (Customer Data Platform): Собирайте все данные (CRM, сайт, приложение) в одном месте.
Внедряйте Server-Side трекинг: Это единственный способ сохранить точность аналитики в будущем.
Тестируйте новые каналы: Telegram Ads (работает без кук, на контексте каналов) или Retail Media.
Аудит согласий: Проверьте формы сбора данных на сайте. Галочка «Согласен на рекламную рассылку» должна быть отделена от «Согласен на обработку ПДн». Но мне, если честно, не нравится такой подход. Я бы сделал так – Типа Посмотри 10 рекламных роликов, и спи спокойно сегодня до 12, больше показывать сегодня не буду типа)))
Обезличивание: Используйте методы обезличивания (деперсонализации) при передаче данных партнерам, как того требуют новые правила consultant.ru.
Цели обработки: Четко прописывайте цели в политике конфиденциальности (например, не просто “маркетинг”, а “таргетирование рекламы в сетях Яндекса”) rppa.pro. Кстати, хороший справочник.

Apache Iceberg V3: Готов ли он?

Thu, 18 Dec 2025 22:06:36 +0300

Apache Iceberg V3: Готов ли он?

Автор: Guy Yasoor (Ryft Blog)
Перевод и дополнения: Gemini 3 Pro Preview и я кофе носил

Оригинал: https://www.ryft.io/blog/apache-iceberg-v3-is-it-ready

Выход Apache Iceberg V3 — это огромный шаг вперед для экосистемы лейкхаусов (lakehouse). Спецификация V3 была финализирована и ратифицирована в начале этого года, привнеся в ядро формата несколько долгожданных возможностей: эффективные удаления на уровне строк (row-level deletes), встроенное отслеживание происхождения строк (row lineage), улучшенная обработка полуструктурированных данных и зачатки нативного шифрования.

Этим новым возможностям уделяется много внимания, но в разговорах часто упускают вопрос, который важен не меньше: Насколько V3 готов на практике?

Честный ответ: это полностью зависит от ваших движков обработки данных (engines). Некоторые среды, такие как Spark и Flink, уже хорошо поддерживают V3. Другие — пока отстают.

Основные возможности V3

Deletion Vectors (Векторы удаления)

Векторы удаления прикрепляют информацию об удалении строк непосредственно к файлам данных в виде битовых карт, избегая накопления позиционных файлов удалений (positional delete files).

>**поИИснение:**
>В предыдущих версиях (V2) использовались **Positional Delete Files** — это отдельные Parquet-файлы, содержащие пути и позиции удаленных строк. При чтении (Merge-on-Read) движку приходилось считывать файл данных, считывать файл удалений и делать между ними `JOIN`, чтобы отфильтровать ненужное. Это требует много памяти и ввода-вывода (IO).
>
>**Deletion Vector (V3)** — это, по сути, компактная битовая карта (bitmap), хранящаяся внутри или рядом с файлом данных. Движку достаточно прочитать этот маленький массив битов пропустить удаленные строки "на лету", без дорогостоящих операций слияния. Это критически ускоряет чтение активно изменяемых таблиц.

Статус:
- Принято в большинстве движков, реализующих V3.
- Стабильное чтение/запись в `Apache Spark`, `Apache Flink`.
- Вероятно, самая готовая к продакшену функция.

Row Lineage (Происхождение строк)

Row lineage вводит стабильные идентификаторы строк и метаданные версий. Это упрощает инкрементальную обработку, CDC, аудит и отладку.

>**поИИснение:**
>Без Row Lineage, если вы обновляете таблицу, строки часто физически перезаписываются, и их "личность" теряется. Чтобы понять, что изменилось, приходилось сравнивать полные копии данных (expensive diff).
>V3 присваивает строкам суррогатные ID. Это позволяет реализовать дешевый CDC (Change Data Capture): вы точно знаете, что "Строка #123" была обновлена, и можете каскадно обновить только связанные с ней агрегаты в витринах данных, вместо пересчета всей витрины.

Статус:
- Принято в большинстве движков V3.
- Достаточно зрелая технология для V3-совместимых стеков.

Тип данных VARIANT

`VARIANT` — это нативный тип для полуструктурированных данных, замена хранению JSON в виде простых строк. Однако текущая поддержка частичная: не хватает “шреддинга” (shredding).

>**поИИснение:**
>В чем суть **Shredding (измельчения)**? Если вы храните JSON как строку (String), базе данных нужно парсить весь JSON для каждого запроса, чтобы достать одно поле `{"user": "Ivan", ...}`. Это медленно.
>Тип `VARIANT` хранит данные в бинарном формате. А **Shredding** — это оптимизация, когда движок замечает, что поле `user` встречается в 95% записей. Он автоматически вытаскивает это поле в отдельную физическую колонку Parquet, сохраняя при этом логическую структуру JSON. Это позволяет читать поле `user` так же быстро, как обычную колонку, но сохранять гибкость схемы (schema evolution), не делая `ALTER TABLE` при добавлении новых полей в JSON.

Статус:**
- Поддерживается в Spark, Flink, Databricks SQL.
- Parquet стандартизирует кодировки, что даст общее представление для оптимизации.

Геопространственные типы и Шифрование

V3 вводит типы для гео-данных и блоки для шифрования на уровне таблицы.

Статус: Гео-типы доступны через расширения (`Apache Sedona`), шифрование находится на ранней стадии (только Spark/Flink).

Поддержка движками: Где V3 реально работает?

Движок	Статус V3	Комментарий
Apache Spark	✅ Отличный	Начиная с v4.0 — самая надежная платформа для V3.
Apache Flink	✅ Хороший	Идеален для стриминга, поддерживает основные фичи.
Databricks	⚠️ Beta	Работает, но есть ограничения по типам данных.
AWS (Glue/EMR)	⚠️ Частичный	Зависит от версии движка под капотом.
Amazon Athena	❌ Нет	Главный блокер для пользователей AWS.
Trino / Starburst	🔸 Смешанный	Starburst (коммерческий) поддерживает, OSS Trino — нет.
Snowflake	⏳ Ожидание	Активно разрабатывали спецификацию, но публичной поддержки V3 в Managed Iceberg пока нет.

Итог: Переходить ли на V3?

Для большинства: пока нет.
Ключевые игроки (Athena, Trino OSS, Snowflake) не готовы. Переходите, только если ваш стек состоит исключительно из Spark или Flink.

🔮 МненИИе и гаданИИе на кофейной гуще

Прогноз на год вперед

Аспект	Прагматичный прогноз (Реализм)	Супер-прогноз (Оптимизм/Хайп)
Принятие	Крупный энтерпрайз начнет пилоты к концу года. Основная масса ждет Athena/BigQuery.	V3 станет стандартом для всех greenfield проектов весной. Утилиты миграции ускорят отказ от Hive/Delta.
Каталоги	REST Catalog убивает Hive Metastore. Появление managed REST сервисов.	Universal Catalog Protocol: один каталог для Iceberg, Delta и Hudi. Формат станет прозрачным для пользователя.
Скорость	+30-50% к скорости MERGE операций благодаря векторам удаления.	Нейросетевые оптимизаторы запросов и p2p кэширование сделают “холодный” Iceberg по скорости равным in-memory СУБД.
Python	`PyIceberg` получит полную поддержку записи (Write).	Python-стек (DuckDB + PyIceberg) начнет вытеснять Spark в задачах малого/среднего объема.

Roadmap: 10 шагов развития

Аудит совместимости: Проверить всех потребителей данных. Если есть Athena — V3 откладывается.
Переход на REST Catalog: Отказ от Hive Metastore.
>поИИснение:
>REST Catalog отвязывает клиента (Spark/Trino) от прямого доступа к файловой системе (S3/HDFS). Это безопаснее (можно выдавать временные креды “Vended Credentials”) и позволяет менять физическое расположение данных, не ломая настройки клиентов.
Апгрейд Spark/Flink: Только свежие версии (Spark 3.5+/4.0) умеют работать с V3 корректно.
Внедрение “Puffin” статистики:
>поИИснение:
>Puffin — это формат файлов-спутников для Iceberg, которые хранят продвинутую статистику, например, эскизы (sketches) для оценки уникальных значений (`count distinct`) без чтения данных. Внедрение этого шага ускоряет планирование запросов.
Изолированный пилот: Запуск V3 на одной стриминговой джобе для проверки Deletion Vectors.
Оптимизация CDC: Использование Row Lineage для дедупликации потоков.
PyIceberg для легких ETL: Замена тяжелых JVM-джоб на Python там, где объемы небольшие.
Миграция JSON в VARIANT: Как только движки поддержат шреддинг, это сэкономит гигабайты и часы CPU.
Отказ от позиционных удалений: Полное переключение write-конфигурации на векторы.
Масштабирование: Перевод основных витрин на V3.

💡 Было бы круто, если бы еще сделали...

Нативную поддержку самоорганизации данных (Z-Order / Clustering) без внешних компакторов.

Почему: Сейчас, чтобы запросы “летали” и пропускали ненужные файлы (data skipping), данные нужно сортировать (Z-Order). Это делают отдельные тяжелые джобы (`maintenance jobs`).
Было бы круто, если бы спецификация позволяла писателям (writers) автоматически поддерживать приближенную кластеризацию при вставке данных (opportunistic clustering), либо если бы формат поддерживал Secondary Indexes (вторичные индексы на основе B-деревьев или Bitmap), хранящиеся прямо в слое метаданных. Это позволило бы Iceberg конкурировать с ClickHouse и Druid в сценариях интерактивной аналитики (sub-second latency), убрав необходимость в постоянном “обслуживании” таблиц.

Рейтинг 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 никуда не деваются.

Эпоха «Толстого» браузера и революция локальных данных на WASM

Sat, 13 Dec 2025 01:20:55 +0300

В истории IT-архитектуры маятник всегда качался между двумя крайностями: централизацией и децентрализацией. Сначала были мейнфреймы (центр), затем «толстые» клиенты на ПК (локальные вычисления), а потом пришла эра веб-приложений, и индустрия массово мигрировала в Облака.

Мы привыкли считать браузер лишь «тонким окном», интерфейсом, где вся магия, сложные вычисления и хранение происходят где-то далеко — на серверах AWS или Google. Но сегодня правила игры меняются. Благодаря технологиям WebAssembly (WASM), современному «железу» и новым подходам, браузер превращается в полноценную операционную систему для анализа данных или еще чего-то blog.openreplay.com. Посмотрите статью о “Руководство по Разработке Local-First Приложений”.

Почему мы уходили в облака и почему возвращаемся?

Эра миграции в облака:
В 2010-х локальные машины были «бутылочным горлышком». Чтобы обработать гигабайты данных, требовались серверные стойки. Облака давали бесконечную масштабируемость. Архитектура сводилась к простой формуле: *данные пользователя → загрузка через сеть (latency) → обработка на сервере ($$$) → результат обратно клиенту*.

Проблемы сегодняшнего дня:

Избыточность мощностей: Современный ноутбук аналитика (даже базовый MacBook Air на M-чипе) обладает вычислительной мощностью, сопоставимой с сервером десятилетней давности. Эти ресурсы простаивают, пока компании платят за облачные CPU.
Сетевые задержки и стоимость: Передать CSV-файл на 2 ГБ в облако для простой фильтрации или агрегации — это долго и дорого (ingress/egress трафик).
Приватность: Передача чувствительных отчетов или персональных данных на чужой сервер для разового анализа всегда несет риски утечки и нарушений регуляторики.

Решение: Приложения Local-First

Технология WebAssembly (WASM) позволила запускать нативный код (C++, Rust, Go) прямо в песочнице браузера со скоростью, близкой к нативной habr.com. Это породило новый класс ПО, которое выглядит как веб-сайт, но работает как десктопное приложение. Вы заходите на страницу, она загружает легковесный движок, и далее вы можете отключить интернет — приложение продолжит «перемалывать» ваши данные локально.

Новые герои: Сервер внутри вкладки

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

1. DataKit — Швейцарский нож аналитика

Проект DataKit.page — яркий пример такой архитектуры. Это не просто “просмотрщик файлов”, это полноценная ETL/Analytics платформа, живущая в вашем браузере.

Как это работает: Вы перетаскиваете массивные файлы (CSV, JSON, Excel, Parquet) в окно. Они не загружаются на внешний сервер. Браузер получает доступ к файлу через `File System Access API`, а движок (основанный на DuckDB WASM) монтирует их виртуально.
Функционал:
- SQL и Python в одном окне: Внутри работает не только SQL-движок, но и Python (через Pyodide). Вы можете использовать `pandas`, `polars`, `numpy` и строить графики `matplotlib`, обращаясь к данным прямо с вашего диска.
- AI на борту: Интеграция с локальными LLM (через Ollama) или облачными провайдерами позволяет писать запросы на естественном языке, при этом сама схема и данные остаются у вас.
- Умные форматы и коннекторы: Платформа «нативно» понимает Parquet и вложенные JSON, автоматически определяя типы данных и аномалии. Кроме того, она может подключаться к S3, Google Sheets и базам данных PostgreSQL, выполняя федеративные запросы.

2. DuckDB Local UI — SQL без инсталляции

Команда DuckDB в сотрудничестве с MotherDuck выпустила официальный локальный UI, работающий через расширение. Это прямой ответ на боль пользователей консольных утилит и отличный пример гибридного подхода habr.com.

Сценарий: Раньше, чтобы поработать с локальной базой данных, нужно было либо мучиться в CLI, либо ставить тяжелый DBeaver. Теперь одной командой `duckdb -ui` или SQL-вызовом `CALL start_ui();` запускается локальный веб-сервер и открывается современный Notebook-интерфейс.
Гибридность: Вы работаете локально, но интерфейс имеет встроенную бесшовную интеграцию с облачным сервисом MotherDuck. Если для разового анализа локальных ресурсов достаточно, вы делаете это приватно. Как только требуется коллаборация или более мощные вычисления, вы можете переключить контекст выполнения в облако в том же окне.

3. Marimo – тетрадки, почти тот же подход имеет

https://gavrilov.info/all/tetradki-nashe-vsyo-marimo-io-i-utochkadb/

3. PGlite и PondPilot — Postgres и SQL-песочницы

PGlite: Этот проект идет еще дальше и компилирует полноценный PostgreSQL в WASM, позволяя запускать его в браузере или Node.js без эмуляции ОС habr.com. Это идеально для тестирования, прототипирования и создания приложений, которые требуют совместимости с Postgres.
PondPilot: Пример open-source SQL-редактора, построенного вокруг DuckDB-WASM habr.com. Он позволяет быстро анализировать локальные файлы (CSV, Parquet, JSON), сохраняет историю, поддерживает вкладки и даже предлагает виджет для встраивания интерактивных SQL-примеров в блоги и документацию.

Сдвиг парадигмы: От DBeaver к Браузеру

Многие аналитики и инженеры привыкли к классическим клиентам баз данных (DBeaver, DataGrip). Это мощные, но «тяжелые» инструменты, требующие установки, настройки драйверов и обновлений. Новый WASM-тренд предлагает более гибкую альтернативу.

Сценарий «Мгновенной аналитики»:
Представьте, что вам прислали ссылку на лог-файл в S3 размером 5 ГБ или Parquet-дамп.

Старый путь: Скачать файл → Установить/открыть DBeaver → Настроить драйвер → Импортировать → Ждать загрузки → Писать SQL.
Новый путь (WASM): Открыть ссылку веб-приложения → Перетащить файл (или указать S3 URL) → Мгновенно писать SQL.

Еще вариант, лог 30ГБ и вы заказали функционал в другой команде, она с радостью сказала, что через два спринта сделает пайплайн за неделю, но ей надо требования. Вы их конечно написали на основе небольшого семпла строк из excel или на основе документации и отдали в разработку. А через месяц получили отличный пайплайн или, который не нужен или его нужно еще доработать.

Технологическая магия за кулисами:

Apache Arrow: Это скрытый герой революции. Бинарный колоночный формат Arrow позволяет передавать данные из SQL-движка (DuckDB) в JavaScript-интерфейс или Python-ячейку без копирования и сериализации памяти (Zero-copy). Это обеспечивает мгновенную реакцию интерфейса на миллионах строк — то, чего раньше было невозможно добиться при работе с DOM. (все помним D3JS)
Федеративные запросы: Локальное приложение умеет «ходить» в интернет. Вы можете написать `SELECT * FROM ‘s3://my-bucket/file.parquet’` прямо из браузера. Движок скачает только нужные байты (range requests), обработает их локально и покажет результат. Данные не оседают на промежуточных серверах разработчика софта.

Органическое масштабирование и новая экономика

Для архитекторов платформ данных этот тренд открывает удивительную экономическую модель «Bring Your Own Compute» или «Client-side computing» (Принеси Свои Вычисления).

Масштабирование без усилий: Вам не нужно создавать сложный кластер, чтобы тысячи пользователей могли фильтровать свои Excel-файлы. Вы просто хостите статические JS/WASM файлы на CDN.
Органическая нагрузка: Вычислительная мощность вашего “облака” растет линейно с количеством пользователей, потому что каждый новый пользователь приносит свой CPU и RAM. Пользователи выключают компьютеры — ваше “облако” естественным образом уменьшается.
Коллаборация и Воспроизводимость:**
- *Разовая задача:* Сделал анализ локально, закрыл вкладку — данные исчезли из памяти (полная приватность).
- *Командная работа:* Написал SQL/Python код локально, сохранил его (текст скрипта весит килобайты) и отправил коллеге. Коллега открыл ту же ссылку, подгрузился код, и магия вычислений произошла уже на его машине над теми же данными (если они в общем S3) или над его локальной копией.

Итого

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

Разработчикам и Архитекторам:

Присмотритесь к Serverless 2.0: Истинный `serverless` — это не AWS Lambda, за которую вы платите. Это когда сервера нет вообще, а код исполняется на клиенте (`client-side computing`). Это дешевле, быстрее для пользователя и безопаснее, удобно разрабатывать и обновлять код.
Privacy-first как преимущество: Позиционируйте такие решения как безопасные по умолчанию. Аргумент “Ваши данные никогда не покидают ваш компьютер” становится решающим для Enterprise-сектора.
Гибридная архитектура: Не отказывайтесь от сервера полностью. Пусть браузер берет на себя интерактивную работу, парсинг и предобработку, а сервер подключается для тяжелых “батчей” или работы с петабайтами данных в том же привычном окне.

Пользователям и Аналитикам:

Осваивайте инструменты: Попробуйте https://datakit.page, https://app.pondpilot.io или DuckDB WASM Shell для разведочного анализа данных. Это часто быстрее, чем запускать локальный Jupyter.
Используйте облачные хранилища напрямую: Учитесь подключать S3, Google Sheets и другие облачные источники напрямую к таким инструментам. Это дает мощь облачного хранения в сочетании со скоростью и приватностью локального интерфейса.

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

Обзор 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 в качестве единой точки входа для данных.

Сводная таблица exchange-compression: LZ4 vs NONE vs ZSTD в Trino

Tue, 02 Dec 2025 00:08:08 +0300

Сводная таблица: LZ4 vs NONE vs ZSTD (простые запросы + дополнение для сложных запросов)

Простые запросы (шарфл ~42 MB)

Метрика	NONE 🚀	LZ4	ZSTD 📦
Wall Time	0.95 s	1.68 s	1.47 s
Network	42.0 MB (1.0x)	24.8 MB (1.7x)	12.8 MB (3.3x)
Total CPU	7.52 s	7.56 s	7.49 s
Processed Input	1.86 GB	1.86 GB	1.86 GB

Сложные запросы (шарфл ~11.7 GB, 3 JOIN + DISTINCT, ~732M строк, 5.9 GB input)

Метрика	NONE	LZ4	ZSTD 📦
Wall Time	13.49 s	13.93 s	12.27 s 🚀
Network	11.69 GB (1.0x)	6.87 GB (~1.7x)	3.54 GB (~3.3x)
Total CPU	214 s	~220 s	214 s
Processed Input	13.19 GB	13.19 GB	13.19 GB

Коэф. сжатия рассчитан относительно NONE по `internalNetworkInputDataSize` (шарфл-трафик):

NONE: 11.686 GB
LZ4: ~6.87 GB (коэф. 1.7x, как в простых тестах; точные данные из логов подтверждают пропорцию)
ZSTD: ~3.54 GB (коэф. 3.3x)

Анализ результатов (простые + сложные запросы)

ZSTD — король сжатия (подтверждено на больших объемах)

Простые запросы (малый шарфл 42 MB): ZSTD сжал до 12.8 MB (3.3x лучше NONE).
Сложные запросы (большой шарфл 11.7 GB): ZSTD сжал до ~3.54 GB (экономия ~8.15 GB на узел). Если шарфл 400 GB, ZSTD сэкономит ~300 GB трафика по сети — критично для кластера.

Производительность (Speed vs Overhead)

NONE: Быстрее на малых объемах (0.95s), но на сложных — 13.49s (сетевой bottleneck).
ZSTD: На простых 1.47s (лучше LZ4), на сложных 12.27s (🚀 быстрее всех). Сильное сжатие сокращает сетевой IO, компенсируя CPU overhead.
LZ4: На простых худший (1.68s, возможно шум), на сложных 13.93s (хуже ZSTD). Быстрое сжатие, но слабое (1.7x).

CPU (Процессор)

Все варианты: ~7.5s (простые), ~214s (сложные). Сжатие (LZ4/ZSTD) не увеличивает CPU на фоне чтения Parquet/ORC + JOIN (732M строк).

Ключевые insights из сложных тестов

Сетевой трафик: ZSTD выигрывает на 70% (3.3x), LZ4 на 41% (1.7x). На больших шарфлах (JOINы генерируют GB) сеть — bottleneck для NONE/LZ4.
Время выполнения: ZSTD быстрее (12.27s vs 13.49s NONE, 13.93s LZ4). Компенсация сжатием > overhead.
Dynamic Filters: Работают одинаково (df_1013/1014), сжатие не влияет.
Memory: Peak ~25 GB (user), сжатие снижает пики на exchange.

Итог

ZSTD доминирует: Лучшее сжатие (3.3x), минимальный Wall Time на больших данных, нулевой CPU-штраф. На простых — баланс скорости/сжатия, на сложных — разгружает сеть.
LZ4: Средний вариант (быстрее сжатие, слабее компрессия). Хуже ZSTD по всем метрикам.
NONE: Только для микрокластерами/очень малых шарфлов (<10 MB).

Просто 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"}

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

Nimtable: Единая панель управления для зоопарка Iceberg-каталогов

Wed, 19 Nov 2025 22:44:53 +0300

В современных компаниях, активно использующих данные, часто возникает проблема “зоопарка” технологий. Данные хранятся в озере данных (Data Lake), а метаданные об этих данных — в каталогах. Со временем таких каталогов становится много: один `Hive Metastore` для унаследованной аналитики, другой — `REST Catalog` для новой платформы на Trino, третий — `JDBC Catalog` для специфичного микросервиса, а где-то в среде разработки таблицы вообще создаются напрямую в S3. Каждая система решает свою задачу, но вместе они создают хаос.

https://github.com/nimtable/nimtable

Платформенным дата-командам становится сложно управлять этим разнообразием, отслеживать состояние таблиц, проводить оптимизацию и обеспечивать единые стандарты. Именно для решения этой проблемы и был создан open-source проект Nimtable. Это не просто очередной каталог для Iceberg, а полноценная платформа для наблюдения и управления (*observability platform*) существующими каталогами из одного окна.

Что такое Nimtable?

Nimtable — это легковесная веб-платформа с открытым исходным кодом, предназначенная для исследования и управления каталогами и таблицами Apache Iceberg. Его ключевая идея — предоставить единый интерфейс для подключения к различным существующим каталогам, агрегируя метаданные и предоставляя инструменты для их анализа и обслуживания.

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

Ключевая функциональность

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

пы: картинки можно листать, если что) там много, почти все меню.

Агрегация каталогов: Это главная особенность проекта. Nimtable позволяет в одном интерфейсе подключить и работать с несколькими типами каталогов Apache Iceberg, включая:
- `REST Catalog`
- `AWS Glue`
- `PostgreSQL` (через JDBC)
- Каталоги на основе S3 (`S3 Tables`)

Исследование и визуализация: Платформа предоставляет удобный UI для навигации по метаданным:
- Просмотр каталогов, пространств имен (схем) и таблиц.
- Анализ схемы таблиц, их партиций, снэпшотов и манифестов.
- Визуализация распределения файлов и снэпшотов, что помогает быстро находить таблицы, требующие оптимизации (например, с большим количеством мелких файлов).

Управление оптимизацией: Nimtable не просто показывает проблемы, но и помогает их решать. Он интегрируется с внешними вычислительными движками, такими как Apache Spark или RisingWave, позволяя запускать и отслеживать задачи по обслуживанию таблиц (например, `compaction` или `expire_snapshots`) прямо из веб-интерфейса.

Встроенный SQL-редактор: Для быстрой проверки данных или метаданных в Nimtable встроен простой SQL-редактор, позволяющий выполнять запросы к таблицам напрямую из браузера.

Собственный REST API: Помимо агрегации других каталогов, Nimtable сам может выступать в роли стандартного Iceberg REST-каталога. Это позволяет использовать его как единую точку входа для различных движков запросов (Trino, Spark, Flink).

Варианты использования в большой компании

Представим себе компанию, где исторически сложился разнородный ландшафт данных:

Прод-кластер Hadoop использует `Hive Metastore` для аналитических витрин.
Аналитическая платформа на Trino работает с CedrusData Catalog, который реализует `Iceberg REST API` habr.com.
Команда разработки для своих экспериментов использует таблицы, зарегистрированные напрямую в S3, чтобы не “загрязнять” общие каталоги.
Какой-то сервис использует собственную `PostgreSQL` базу как JDBC-каталог.

В такой среде Nimtable становится незаменимым инструментом:

Единая точка входа: Платформенная команда подключает все четыре каталога к Nimtable. Теперь для мониторинга состояния всех Iceberg-таблиц в компании достаточно зайти на один дашборд, не переключаясь между разными консолями и инструментами.
Централизованная оптимизация: Инженер замечает, что в одной из таблиц на прод-кластере накопилось тысячи мелких файлов. Прямо из интерфейса Nimtable он может запустить `compaction-job` на общем Spark-кластере, выбрав нужную таблицу, независимо от того, в каком каталоге она зарегистрирована.
Упрощение доступа: Вместо того чтобы объяснять новому аналитику, как настроить 4 разных подключения, ему можно дать доступ к Nimtable, где он сможет исследовать все доступные данные в едином, понятном интерфейсе.
Контролируемая миграция: Если команда решит перенести таблицы из `Hive Metastore` в новый `REST Catalog`, Nimtable позволит одновременно наблюдать за источником и приемником, контролируя процесс и сверяя метаданные.

Архитектура и развертывание

Архитектурно Nimtable располагается между конечными пользователями (или движками запросов) и нижележащими каталогами метаданных.

Проект очень прост в развертывании. Самый быстрый способ начать работу — использовать Docker:

# Переходим в директорию с docker-файлами в репозитории проекта
cd docker
# Запускаем сервисы в фоновом режиме
docker compose up -d

После этого веб-интерфейс будет доступен по адресу `http://localhost:3000`.

Сравнение с другими решениями

Чтобы понять нишу, которую занимает Nimtable, сравним его с другими популярными решениями для управления метаданными.

Параметр	Nimtable	Project Nessie	Hive Metastore	CedrusData Catalog
Основное назначение	Платформа для наблюдения и управления несколькими каталогами.	Каталог с Git-подобным версионированием данных.	Хранилище метаданных для экосистемы Hadoop.	Высокопроизводительный Iceberg REST каталог.
Поддержка нескольких каталогов (агрегация)	Да (ключевая функция)	Нет (является самостоятельным каталогом)	Нет (является самостоятельным каталогом)	Нет (является самостоятельным каталогом)
Встроенный UI для управления	Да, с фокусом на агрегацию и оптимизацию.	Да, с фокусом на ветки, теги и коммиты.	Нет (обычно управляется через CLI или сторонние UI).	Управляется через API; UI не является основной частью docs.cedrusdata.ru.
Управление оптимизацией (Compaction)	Да, через интеграцию с внешними движками.	Нет, это задача движков запросов.	Нет, это задача движков запросов (Spark/Hive).	Нет, это задача движков запросов.
Git-подобные операции	Нет	Да (ключевая функция)	Нет	Нет

Как видно из таблицы, Nimtable не конкурирует напрямую с каталогами вроде Nessie или Hive и другими, а дополняет их, выступая в роли “менеджера менеджеров”.

Заключение

Nimtable — это многообещающий проект, который пока не собрал много звёзд, но уже готов решать реальную боль платформенных дата-команд в крупных организациях. Вместо того чтобы создавать еще один стандарт каталога, он предлагает удобный слой абстракции для управления уже существующим “зоопарком”. Возможность в одном месте видеть, анализировать и оптимизировать таблицы из разных систем (`Hive`, `JDBC`, `REST`) делает его уникальным и крайне полезным инструментом для построения зрелой и управляемой платформы данных на базе Apache Iceberg.

Кстати, у меня после запуска он сначала жутко тупил, а потом прочихался, на третий день работы в докере))) я уже даже не надеялся, а он смог. ниче не делал) оно само) Но, видимо, если таблиц очень много, то первый запуск надо как то отдельно планировать. В общем зверь интересный и полезный, а запускать не сложно. Ну почти не сложно и баги есть. вот эту нашел например? https://github.com/nimtable/nimtable/issues/200 но это не критично.

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

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

Да точно, дело в ресурсах, теперь 16 файлов.

Теперь кстати хочет оптимизации)), хороший тула, можно и сломать табличку им))

Ранее писал о разных каталогах тут: https://gavrilov.info/all/rukovodstvo-po-rest-katalogam-dlya-trino-i-iceberg/

Новые архитектуры современной инфраструктуры данных: a16z

Tue, 04 Nov 2025 17:02:04 +0300

Источник: Emerging Architectures for Modern Data Infrastructure
Авторы: Matt Bornstein, Jennifer Li, and Martin Casado
PDF: Тут

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

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

Обновленные эталонные архитектуры

Статья предлагает два общих взгляда на современный стек данных.

1. Единая инфраструктура данных (Unified Data Infrastructure 2.0)

Эта схема дает комплексное представление о стеке данных, охватывая все основные варианты использования — от аналитики до операционных систем.

Notes: Excludes OLTP, log analysis, and SaaS analytics apps.

Схема демонстрирует путь данных от источников (`Sources`) через этапы загрузки и транспортировки (`Ingestion and Transport`), хранения (`Storage`), обработки запросов (`Query and Processing`), трансформации (`Transformation`) до конечного анализа и вывода (`Analysis and Output`).

2. Инфраструктура для машинного обучения (Machine Learning Infrastructure 2.0)

Вторая схема подробно рассматривает сложную и все более независимую цепочку инструментов для машинного обучения.

Здесь показан жизненный цикл ML-модели: от трансформации данных и разработки модели (`Data Transformation`, `Model Training and Development`) до ее развертывания (`Model Inference`) и интеграции в конечные продукты (`Integration`).

Что изменилось? Стабильное ядро и “Кембрийский взрыв”

Что не изменилось: стабильность в ядре

Несмотря на активное развитие рынка, базовые архитектурные паттерны сохранили свою актуальность. По-прежнему существует разделение между:

Аналитическими системами (Analytic Systems), которые помогают принимать решения на основе данных (`data-driven decisions`).
Операционными системами (Operational Systems), которые являются основой для продуктов, использующих данные (`data-powered products`).

Ключевые технологии в ядре стека доказали свою устойчивость и продолжают доминировать:

В аналитике связка `Fivetran` (для репликации данных), `Snowflake`/`BigQuery` (облачные хранилища данных) и `dbt` (для SQL-трансформаций) стала почти стандартом де-факто.
В операционных системах укрепились такие стандарты, как `Databricks`/`Spark`, `Confluent`/`Kafka` и `Airflow`.

Что нового: “Кембрийский взрыв”

Вокруг стабильного ядра наблюдается бурный рост новых инструментов и приложений, которые можно разделить на две категории:

Новые инструменты для поддержки ключевых процессов обработки данных:
- Data Discovery: Каталоги данных для поиска и понимания имеющихся активов (`Amundsen`, `DataHub`, `Atlan`).
- Data Observability: Инструменты для мониторинга состояния и качества конвейеров данных (`Monte Carlo`, `Bigeye`).
- ML Model Auditing: Решения для аудита и валидации ML-моделей.

Новые приложения для извлечения ценности из данных:
- Data Workspaces: Интерактивные среды для совместной работы аналитиков и Data Scientist’ов (`Mode`, `Hex`, `Deepnote`).
- Reverse ETL: Сервисы, которые возвращают обогащенные данные из хранилища обратно в операционные системы (CRM, ERP), такие как `Census` и `Hightouch`.
- ML Application Frameworks: Фреймворки для создания приложений на основе ML-моделей (`Streamlit`).

Три основных архитектурных шаблона (Blueprints)

Шаблон 1: Современная Business Intelligence (BI)

Этот шаблон предназначен для компаний любого размера, которые строят облачную BI-аналитику.

Darker boxes are new or meaningfully changed since v1 of the architecture in 2020; lighter colored boxes have remained largely the same. Gray boxes are considered less relevant to this blueprint.

Что не изменилось: Основой по-прежнему является комбинация репликации данных (`Fivetran`), облачного хранилища (`Snowflake`) и SQL-моделирования (`dbt`). Дашборды (`Looker`, `Tableau`, `Superset`) остаются главным инструментом анализа.
Что нового:
- Metrics Layer: Появился активный интерес к слою метрик — системе, которая предоставляет стандартизированные бизнес-определения поверх хранилища данных (`Transform`, `LookML`). `dbt` также движется в этом направлении. ( dbt кстати открыла в общий доступ свои метрики тут
- Reverse ETL: Этот инструмент позволяет операционализировать аналитику, отправляя результаты (например, скоринг лидов) из хранилища напрямую в `Salesforce` или `Hubspot`. ( теперь мы знаем как эта штука называется по-модному, когда кто-то просит excele’чку всунуть к табличке рядышком :) )
- Data Workspaces: Новые приложения для более гибкого и глубокого анализа, чем стандартные дашборды.

Шаблон 2: Мультимодальная обработка данных

Этот шаблон развивает концепцию “озера данных” (`Data Lake`) для поддержки как аналитических, так и операционных задач. Часто используется компаниями, которые “мигрировали” с `Hadoop`.

Что не изменилось: Ядром остаются системы обработки (`Databricks`, `Starburst`), транспортировки (`Confluent`, `Airflow`) и хранения (`AWS S3`).
Что нового:
- Архитектура Lakehouse: Получила широкое признание концепция `Lakehouse` — гибрид, объединяющий гибкость озера данных и производительность/управляемость хранилища данных. Она позволяет использовать поверх одного и того же хранилища (`S3`) множество движков: `Spark`, `Presto`, `Druid`/`ClickHouse` и др.
- Форматы хранения: Быстрое распространение получают открытые табличные форматы, такие как `Delta Lake`, `Apache Iceberg` и `Apache Hudi`, которые привносят транзакционность и надежность в озера данных.
- Stream Processing: Растет популярность потоковой обработки данных в реальном времени. Появляются новые, более простые в использовании инструменты (`Materialize`, `Upsolver`), а существующие (`Databricks Streaming`, `Confluent`/`ksqlDB`) наращивают функциональность.

Шаблон 3: Искусственный интеллект и машинное обучение (AI/ML)

Стек для разработки, тестирования и эксплуатации ML-моделей.

Note: Darker boxes are new or meaningfully changed since v1 of the architecture in 2020; lighter colored boxes have remained largely the same. Gray boxes are considered less relevant to this blueprint.

Что не изменилось: Инструменты для разработки моделей в целом остались прежними: облачные платформы (`AWS Sagemaker`, `Databricks`), ML-фреймворки (`PyTorch`, `XGBoost`) и системы для отслеживания экспериментов (`Weights & Biases`, `Comet`).
Что нового:
- Data-Centric AI: Произошел сдвиг парадигмы в сторону подхода, ориентированного на данные. Вместо бесконечного улучшения кода модели, фокус сместился на улучшение качества и управления данными для обучения. Это привело к росту сервисов разметки данных (`Scale AI`, `Labelbox`).
- Feature Stores: Увеличилось внедрение хранилищ признаков (`Tecton`, `Feast`) для совместной разработки и использования ML-признаков в production.
- Pre-trained Models: Использование предобученных моделей (особенно в NLP) стало стандартом. Компании, как `OpenAI` и `Hugging Face`, играют здесь ключевую роль.
- MLOps: Инструменты для эксплуатации моделей стали более зрелыми, особенно в области мониторинга (`Arize`, `Fiddler`) на предмет деградации качества и дрифта данных.

Гипотеза о “платформе данных”

Ключевая идея статьи — объяснить наблюдаемые изменения через формирование платформ данных.

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

Применительно к данным, “бэкенд” стека (загрузка, хранение, обработка) консолидируется вокруг небольшого числа облачных вендоров. Эти вендоры (`Snowflake`, `Databricks`) активно инвестируют в то, чтобы сделать данные легкодоступными для других через стандартные интерфейсы (например, SQL).

В свою очередь, “фронтенд” разработчики пользуются этим, создавая множество новых приложений поверх единой точки интеграции, не беспокоясь о сложностях базовой инфраструктуры. Это приводит к появлению нового класса `warehouse-native` (или `lakehouse-native`) приложений, которые работают непосредственно с данными клиента в его хранилище.

Эта модель объясняет, почему поставщики ядра данных (`Snowflake`, `Databricks`) так высоко ценятся (они борются за долгосрочную позицию платформы) и почему наблюдается взрывной рост в экосистеме инструментов (`Reverse ETL`, `Metrics Layer`) — они становятся важными компонентами, встроенными в эту новую платформенную архитектуру.

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

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

Взрывной рост экосистемы. Вокруг стабильного ядра формируется богатая экосистема вспомогательных инструментов (`observability`, `discovery`) и бизнес-приложений (`reverse ETL`, `workspaces`), которые повышают ценность данных.

Платформизация стека данных. Центральные хранилища данных (`Data Warehouse`, `Lakehouse`) превращаются из простых баз данных в полноценные платформы для разработки. Это открывает путь для нового поколения `warehouse-native` SaaS-приложений.

Операционализация данных. Тренд смещается от простой аналитики (посмотреть на дашборд) к активному использованию данных в операционных процессах бизнеса. Технологии `Reverse ETL` являются главным драйвером этого тренда.

Data-Centric AI. В мире машинного обучения фокус окончательно сместился с улучшения алгоритмов на улучшение данных, что стимулирует рынок инструментов для управления жизненным циклом данных в ML (`data labeling`, `feature stores`, `monitoring`).

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, а не только на текущем состоянии функциональности.