Yuriy Gavrilov

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

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

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

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

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

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

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

T classic = B / Dc

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

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

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

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

минимальный

docker-compose.yml

version: '3.8'

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

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

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

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

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

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

CREATE CATALOG

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

config.properties

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

catalog.management=dynamic

spooling-manager.properties

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

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

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

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

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

CREATE SCHEMA test_warehouse.test_schema;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Результат:

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

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

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

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

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

49 Мегабайт Боли: Экономика враждебного веб-дизайна

Sun, 12 Apr 2026 13:22:50 +0300

Ссылка на оригинальную публикацию есть тут The 49MB Web Page.

Опубликовано: 12 апреля 2026 г. | Оригинал: 12 марта 2026 г.

МненИИе 🤖

Если бы отвлечение внимания пользователей было олимпийским видом спорта, новостные издания забирали бы все золотые медали. Зайдя на сайт крупного новостного портала вроде New York Times, чтобы просто прочитать пару заголовков, вы столкнетесь с лавиной: 422 сетевых запроса и 49MB загруженных данных. После того как страница наконец-то «успокоится» спустя пару минут, отпадает любой вопрос о том, почему каждый уважающий себя IT-специалист устанавливает блокировщики рекламы на все устройства своих близких.

Чтобы осознать масштаб феномена «49-мегабайтной веб-страницы», давайте вернемся в прошлое. Размер этой страницы превышает объем операционной системы Windows 95 (которая помещалась на 28 дискетах!). В эпоху расцвета iPod стандартный MP3-трек высокого качества (битрейт 192 kbps) занимал около 4-5MB. Таким образом, одна современная статья весит как полноценный музыкальный альбом из 10–12 песен.

Время загрузки в 2006 году ≈ 1.5 Mbps 49 MB×8 бит ≈ 261 секунда

Спустя 20 лет аппаратное обеспечение шагнуло далеко вперед, но современные рекламные технологии (ad-tech) полностью нивелировали этот прогресс своей плохой архитектурой и бесконечным раздуванием кода.

Почему так происходит? Экономика Hostile Architecture

Издатели не злодеи, они просто в отчаянии. Попав в «смертельную спираль» programmatic-рекламы, они жертвуют долгосрочной лояльностью читателей ради сиюминутных копеек с показов (CPM). Современная рекламная индустрия разделила создателя контента и рекламодателя.

Каждое враждебное UX-решение проистекает из одной формулы: чем дольше вы заперты на странице взаимодействия, тем выше доход. Ваше разочарование — это их продукт. Мы можем описать общую стоимость взаимодействия (Interaction Cost) как математическую сумму:

C total =∑ ( C mental + C physical)

Вместо комфортного чтения пользователи сталкиваются с системой, которая максимизирует $C_{total}$, чтобы выжать максимум метрик из человеческого когнитивного ресурса.

Технические детали враждебного дизайна (CLS, Z-Index, Трекинг)

Z-Index Warfare (Предварительная засада): При загрузке страницы вас встречает баннер файлов cookie (занимает 30% экрана), затем всплывающее окно «Подпишитесь на рассылку», и одновременно браузер спамит запрос на отправку уведомлений. Доступ к 5 KB текста статьи превращается в полосу препятствий.
CLS-катастрофа (Cumulative Layout Shift): Вы начали читать, как вдруг текст прыгает на 250 пикселей вниз. Почему? Рекламная сеть завершила фоновые торги и встроила `iframe` над видимой областью. Это вызывает дезориентацию и напрямую ведет к высокому проценту отказов (bounce rate).
Невидимые аукционы и перегрузка Mobile CPU: Пока вы читаете абзац, браузер вынужден обрабатывать десятки параллельных ставок от `fastlane.json` или систем Amazon. Разбор мегабайтов `JS` монополизирует основной поток браузера.
Прилипающие видео и закон Фиттса: При прокрутке видео открепляется и закрепляется в углу экрана. Кнопка закрытия «X» делается микроскопической, что нарушает Закон Фиттса, согласно которому время достижения цели зависит от расстояния до нее и ее размера:
T = a + blog 2 ( 1 + WD)
Налог на «Толстый палец» (Fat-finger tax): Расположение кнопок закрытия вплотную к кликабельной зоне рекламы — это математически просчитанный риск рекламных команд для генерации случайных кликов. Это не баг, это фича.

Альтернативные решения для разработчиков

Если маркетинговая команда настаивает на автовоспроизведении видео, разработчики обязаны использовать `IntersectionObserver`. Это позволит уважать ресурсы пользователя (батарею и CPU) при прокрутке страницы:

// Пример базовой реализации для паузы видео вне зоны видимости
const videoElement = document.querySelector('video.ads-player');

const observer = new IntersectionObserver((entries) => {
  entries.forEach(entry => {
    if (entry.isIntersecting) {
      videoElement.play();
    } else {
      videoElement.pause(); // Уважаем выбор пользователя!
    }
  });
});

observer.observe(videoElement);

Также шапки сайтов следует скрывать при событии `scrollDown` и показывать только при `scrollUp`, освобождая драгоценное вертикальное пространство на мобильных устройствах.

Критические комментарии к проблеме

Оригинальная статья поднимает важную проблему UI/UX, однако дискуссию стоит разбавить долей конструктивной критики:

Однобокий взгляд на монетизацию: Журналистика стоит денег. Расследования, сервера, зарплаты редакторов — всё это требует финансирования. Падение доходов от печатной прессы заставило издания полагаться на рекламные сети. Хотя 49 MB — это абсурд, сама по себе агрессивная реклама является следствием того, что пользователи массово отказываются платить за подписки (Paywalls).
Эффект домино от Ad-blockers: Существует парадокс: чем больше продвинутых интернет-пользователей устанавливают блокировщики, тем меньше инвентаря остается у издателя. Чтобы компенсировать потери, издания вынуждены внедрять ещё более агрессивные скрипты и “липкие” видео для оставшейся, менее технически грамотной аудитории.
Асинхронность и реальный пользовательский опыт: Измерять “зло” веб-страницы исключительно её «боевым весом» (49MB) некорректно. Большинство современных трекеров браузеры загружают асинхронно или отложенно (с атрибутом `defer`). Трудность вызывает не сам объем загружаемых байтов, а именно блокировка главного потока браузера и смещение макета (CLS).

Итог

Современный новостной веб-дизайн оказался в заложниках у метрик. Системы, созданные для вовлечения, трансформировались в «цифровую враждебную архитектуру», доводящую пользователя до ментального истощения. Страницы, превышающие по объему старые операционные системы, использование «тёмных паттернов» (модальные окна, микроскопические крестики закрытия) и беспощадная нагрузка на процессор телефона убивают самое главное — доверие между читателем и изданием.

Создателям контента следует помнить: если пользователь тратит свой когнитивный бюджет на то, чтобы закрыть 4 баннера до прочтения первого слова, никакая «оптимизация конверсии» не заставит его оформить платную подписку. Лучший веб-дизайн — это тот, который уважает время и внимание читателя.

Ventoy: Мультизагрузочная флешка нового поколения

Sun, 12 Apr 2026 12:59:51 +0300

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

Зачем это нужно?

Традиционные инструменты (например, Rufus или UltraISO) извлекают содержимое ISO-образа и записывают его на флешку, форматируя её. Если вам нужна другая операционная система, весь процесс приходится повторять.

Преимущества Ventoy:

Экономия времени: Не нужно форматировать флешку снова и снова. Вы делаете это лишь один раз при установке самого Ventoy.
Мультизагрузочность: Вы можете закинуть на одну флешку десятки образов (Windows, Ubuntu, различные антивирусные LiveCD, инструменты для восстановления). При загрузке Ventoy покажет удобное меню со списком всех найденных образов.
Поддержка форматов: Работает не только с ISO, но и с WIM, IMG, VHD(x) и EFI файлами.
Сохранение обычных данных: Оставшееся свободное место на флешке можно использовать для хранения обычных файлов (документов, фотографий, портативных программ).

Как использовать

Процесс использования максимально прост и состоит из нескольких шагов:

Скачивание и установка: Скачайте программу с официального сайта и запустите. Выберите вашу флешку в списке и нажмите кнопку `Install` (Установить). Внимание: все данные на флешке будут удалены!
Копирование образов: После установки флешка разделится на скрытый загрузочный раздел и видимый раздел для данных. Просто скопируйте нужные вам ISO-файлы (или другие поддерживаемые форматы) в видимый раздел через проводник.
Загрузка: Вставьте флешку в компьютер, в BIOS/UEFI выберите загрузку с USB. Появится меню Ventoy, где вы с помощью стрелочек на клавиатуре сможете выбрать нужный образ и запустить его.

Какие есть ограничения и особенности?

Несмотря на всю свою гениальность, у Ventoy есть несколько нюансов, о которых стоит знать:

список ограничений

Secure Boot (Безопасная загрузка): Хотя Ventoy поддерживает Secure Boot, на некоторых компьютерах при первой загрузке может потребоваться ручное добавление ключа сертификата (enroll key). Процесс описан на официальном сайте, но для новичков это может стать небольшим препятствием. Для обхода проблемы Secure Boot в BIOS можно временно отключить.
Специфичные ОС: Хотя Ventoy тестировался на более чем 1000 различных ISO-образов и поддерживает 99% популярных дистрибутивов, некоторые экзотические или очень старые системы могут не загрузиться корректно.
Фрагментация файлов: Если вы часто записываете и удаляете образы, они могут фрагментироваться. Ventoy не поддерживает загрузку сильно фрагментированных ISO-файлов на файловой системе exFAT. В таких случаях может потребоваться дефрагментация флешки.
Зависимость от BIOS/UEFI: Успешная загрузка иногда зависит от конкретной реализации прошивки материнской платы. Некоторые старые устройства с кривым BIOS могут не распознать загрузчик.

Итог

Ventoy — это инструмент категории “must-have” для системных администраторов, энтузиастов и всех, кому приходится периодически переустанавливать операционные системы или пользоваться загрузочными инструментами. Один раз подготовив такую флешку, вы забудете о рутине с форматированием навсегда.

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 19:44:16 +0300

Юрген Хабермас (18 июня 1929 — 14 марта 2026) — немецкий философ и социолог, крупнейший представитель второго поколения Франкфуртской школы, чье творчество оказало глубокое влияние на политическую философию, теорию права, этику и социальную теорию второй половины XX — начала XXI века . Его часто называли «самым главным философом Германии», наследником традиций Иммануила Канта и Карла Маркса . Он ушел из жизни 14 марта 2026 года в возрасте 96 лет.

Основные идеи и определения

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

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

2. Этика дискурса
Развитая совместно с Карлом-Отто Апелем, эта концепция предлагает новый взгляд на мораль. Место кантовского категорического императива, монологического по своей природе, занимает принцип дискурса: значимыми могут считаться только те нормы, с которыми согласились бы все участники дискуссии в условиях свободного от принуждения обсуждения .

3. Публичная сфера (Öffentlichkeit)
В своей ранней работе «Структурная трансформация публичной сферы» (1962) Хабермас описал, как в Новое время возникло пространство (салоны, кофейни, пресса), где частные лица могли собираться и обсуждать вопросы, представляющие общий интерес, формируя общественное мнение, способное контролировать власть . В конце жизни он вернулся к этой теме, анализируя кризис публичной сферы в эпоху цифровых платформ и социальных сетей .

4. Проект модерна и полемика с постмодернистами
Хабермас, в отличие от Жана-Франсуа Лиотара и других постмодернистов, отказывался считать проект модерна завершенным. Он видел в модерне «незавершенный проект», основанный на вере в силу разума. По его мнению, проблемы современности связаны не с провалом разума как такового, а с его искажением — доминированием одной лишь инструментальной рациональности, которая «колонизирует» «жизненный мир» (мир повседневного общения, семьи, культуры) .

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

6. Постсекулярное общество
В поздний период творчества Хабермас активно исследовал роль религии в современном мире, вводя понятие «постсекулярного общества». Это общество, в котором религия не исчезает, а продолжает существовать наряду с наукой и требует к себе толерантного отношения, при этом религиозные высказывания должны быть «переведены» на общедоступный язык для участия в общемировоззренческом дискурсе.

Что ему удалось?

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

Его главная удача — построение мощной альтернативы как пессимизму ранней Франкфуртской школы (Адорно, Хоркхаймер), так и релятивизму постмодернистов. Он предложил позитивную программу: вместо тотальной критики разума — его «перезагрузку» на коммуникативных основах .

Ему удалось ввести в академический и политический оборот понятия, ставшие общеупотребительными («коммуникативное действие», «публичная сфера», «делиберативная демократия»). Его идеи стали теоретической основой для развития гражданского общества и дискуссий о будущем Европейского Союза .

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

Что ему не удалось?

Главный упрек в адрес Хабермаса — чрезмерная идеализация «ненарушенной коммуникации». Критики, и с годами он сам это признавал, указывают на то, что его концепция «идеальной речевой ситуации» (свободного от власти и принуждения дискурса) является труднодостижимым идеалом в реальном мире, пронизанном отношениями господства и неравенством доступа к дискурсу .

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

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

Итог и самый большой вклад

Юрген Хабермас на протяжении более чем шести десятилетий оставался «совестью» немецкой и европейской интеллигенции, неизменно выступая с позиций разума и эмансипации. Он оставил после себя не просто собрание сочинений, а целую школу мысли и набор инструментов для анализа общества.

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

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

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

❄️ Очень красивые узоры на машине

Sat, 07 Feb 2026 18:21:29 +0300

Очень красивые и редкие

Пропущенный семестр курса по компьютерным наукам

Thu, 29 Jan 2026 21:14:00 +0300

https://missing-semester-rus.github.io

Может кому надо?

Анатомия невидимости: гид по рекламным идентификаторам (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. Кстати, хороший справочник.

Личный бюджет – open source (actualbudget)

Mon, 19 Jan 2026 20:54:58 +0300

куча разного софта есть, но этот очень похож на YNAB – который кстати удобный, но платный

https://github.com/actualbudget/actual

Пробуйте ...

Мне еще нравится https://ledger-cli.org но это для особо упоротых и командной строки. :)

Базы данных в 2025: Год PostgreSQL, AI-агентов и слияний

Tue, 06 Jan 2026 21:07:37 +0300

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

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

Оригинал тут: https://www.cs.cmu.edu/~pavlo/blog/2026/01/2025-databases-retrospective.html?utm_source=tldrdev или на интересном канале https://t.me/five_minutes_of_data

🚀 Главные тренды 2025 года

1. Доминирование PostgreSQL и его экосистемы

PostgreSQL окончательно закрепил за собой статус “стандарта де-факто”. Выход PostgreSQL 18 в ноябре 2025 года принес долгожданную подсистему асинхронного ввода-вывода (AIO), что позволяет базе данных меньше зависеть от кэша операционной системы. Также была добавлена поддержка *skip scans*, что значительно ускоряет запросы по B-Tree индексам, даже если пропущены ведущие ключи (префиксы).

Но главный “движ” происходил не в ядре, а вокруг него:

Распределенный Postgres: В этом году развернулась настоящая битва за горизонтальное масштабирование (шардинг). Проекты вроде Multigres (от Supabase) и Neki (от PlanetScale) нацелились на решение проблемы масштабирования записи, бросая вызов таким ветеранам, как Citus и YugabyteDB.
Война поглощений: Крупнейшие игроки скупали Postgres-стартапы. Databricks заплатил 1 млрд долларов за Neon, а Snowflake выложил 250 млн долларов за Crunchy Data. Это показывает, что облачные гиганты хотят владеть своими собственными “движками” Postgres, а не просто хостить open-source.

Подробнее о слияниях и поглощениях (M&A) (спойлер)

Рынок M\&A в 2025 году был невероятно горячим. Помимо упомянутых сделок с Postgres:

IBM купила DataStax (Cassandra) за ~$3 млрд и Confluent (Kafka). IBM явно строит массивный стек для работы с данными в реальном времени.
Salesforce приобрела ветерана ETL Informatica за $8 млрд.
Databricks также купила Mooncake (для работы с Iceberg) и Tecton (AI-агенты).
Fivetran и dbt Labs объявили о слиянии, создавая единый мощный ETL/ELT конгломерат перед выходом на IPO.

2. Взлет MCP (Model Context Protocol)

Если 2023-й был годом векторных индексов, то 2025-й стал годом MCP от Anthropic. Это стандартизированный протокол (на базе JSON-RPC), позволяющий LLM взаимодействовать с внешними инструментами и базами данных без написания кастомного связующего кода (glue code).

Практически все вендоры (MongoDB, Neo4j, Redis, Snowflake, ClickHouse) выпустили свои MCP-серверы. Теперь AI-агент может самостоятельно “изучить” схему базы данных и выполнить SQL-запрос.

Важно: Это открывает огромные возможности, но и создает риски безопасности. Агент с правами администратора может случайно выполнить `DROP DATABASE`. Внедрение MCP требует жесткого разграничения прав доступа и использования прокси с защитными механизмами.

3. Битва форматов файлов и “Смерть Parquet”?

Неожиданно обострилась конкуренция в области файловых форматов для аналитики. Старый добрый Parquet столкнулся с новыми претендентами: Vortex (от SpiralDB), Nimble (Meta), Lance и другие.
Причина — рост использования GPU для аналитики и необходимость в более быстрых декодерах. Parquet, созданный более 10 лет назад для Hadoop, начинает отставать в эпоху современного “железа” и случайного доступа к данным.

Появление DuckLake указывает на попытки переосмыслить архитектуру Data Lakehouse.

4. Рост локальных и Edge баз данных

На фоне развития Local AI (запуск нейросетей на устройствах пользователя) вырос спрос на базы данных, работающие “на краю” (on-device). Такие решения, как Turso (на базе libSQL/SQLite) и оптимизированные версии DuckDB, позволяют обрабатывать данные прямо на ноутбуке или смартфоне пользователя, снижая задержки и повышая приватность. AI больше не обязан жить только в облаке.

☠️ Кладбище технологий 2025

Не все пережили этот год. Рынок безжалостен к тем, кто не нашел свою нишу или бизнес-модель.

Voltron Data: “Супергруппа” разработчиков (создатели Apache Arrow, Ibis и др.), собравшая $110 млн, не смогла выпустить коммерчески успешный продукт Theseus (GPU-ускоренная база). Они закрылись.
PostgresML: Идея запускать ML прямо внутри Postgres была хорошей, но убедить компании мигрировать на их платформу оказалось сложно.
Fauna (прекращение поддержки собственного языка?): Хоть компания и жива, игнорирование SQL в начале пути стоило им дорого. В 2025 году стало окончательно ясно: если у тебя нет SQL — ты теряешь рынок.
Derby: Один из старейших Java-движков (экс-IBM Cloudscape) перешел в режим “read-only” (архивации). Эпоха ушла.

🏆 Интересные технические новинки

Технология	Суть	Почему это важно
Multigres / Neki	Middleware для шардинга PG	Попытка сделать Postgres таким же масштабируемым, как NoSQL, сохраняя SQL.
Vortex	Новый колоночный формат	Оптимизирован для современного “железа” и векторных операций лучше, чем Parquet.
pg_vector + DiskANN	Векторный поиск	Алгоритмы приблизительного поиска (ANN) теперь работают с данными, превышающими объем RAM, прямо в Postgres.
AI-native DBs	Встроенный ML	Базы данных сами становятся хостами для LLM (пример: PostgreSQL + PL/Python + локальные модели).

🔥 Скандал года: MongoDB против FerretDB

Судебный иск MongoDB против FerretDB стал самым громким юридическим событием. FerretDB предлагает open-source прокси, который конвертирует запросы MongoDB в SQL для PostgreSQL. MongoDB обвинила их в нарушении прав на торговую марку и патенты.
Это дело ставит под вопрос саму возможность создания совместимых API. Если Oracle проиграла Google в битве за Java API, то исход битвы за API баз данных пока не ясен.

МненИИе: Что нас ждет в 2026

*Раздел подготовлен на основе анализа трендов и экстраполяции текущих событий.*

“Агентификация” баз данных:
В 2026 году базы данных перестанут быть пассивными хранилищами. Мы увидим первые промышленные внедрения Autonomous DBA Agents — AI-агентов, которые живут внутри базы, сами строят индексы, оптимизируют запросы в реальном времени и даже исправляют простые ошибки в данных без участия человека. MCP станет стандартом для всех Enterprise-решений.

GPU становится стандартом для OLAP:
Неудача Voltron Data не остановит тренд. Просто GPU-ускорение станет не отдельным продуктом (“GPU Database”), а опцией внутри существующих гигантов (Snowflake, Databricks, PostgreSQL). Запросы будут прозрачно делегироваться на видеокарты там, где это эффективно. Традиционные CPU-only аналитические системы начнут проигрывать в соотношении цена/производительность.

Кризис “Open Source” лицензий:
На фоне исков (как у MongoDB) и желания облачных провайдеров (AWS, Azure) забирать себе всю прибыль от open-source проектов, мы увидим появление новых, более жестких лицензий (наподобие BSL), которые фактически запрещают конкуренцию со стороны облаков, но остаются открытыми для пользователей. Понятие “Open Source” будет размываться в сторону “Source Available”.

Смерть специализированных векторных баз:
Векторные базы данных как отдельный класс продуктов (Pinecone, Weaviate и т.д.) столкнутся с экзистенциальным кризисом. PostgreSQL, Oracle, MongoDB и Elasticsearch уже интегрировали векторный поиск достаточно хорошо для 95% задач. Большие специализированные игроки будут куплены (как Pinecone готовился к продаже в 2025), а мелкие — исчезнут.

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

Управление организационными системами с коалиционным взаимодействием и модели оптимизации иерархических структур

Tue, 06 Jan 2026 00:28:41 +0300

Что то вспомнилось мне, решил посмотреть и дополнить. Как то давно был на лекции Губко, очень интересно рассказывал о фракталах. Оригинал тут есть: https://www.klex.ru/1yt1

М.В. Губко «Управление организационными системами с коалиционным взаимодействием участников» (ИПУ РАН, 2003).

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

1. Анализ

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

Ключевая проблема: Классическая теория управления (в частности, теория активных систем — ТАС) часто рассматривает взаимодействие «Центр — Агент» как игру, где агенты действуют индивидуально (равновесие Нэша). Однако в реальности сотрудники договариваются, обмениваются ресурсами или информацией (образуют коалиции), что может разрушать планы Центра.

Методология: Аппарат кооперативной теории игр (C-ядро, вектор Шепли, решения в угрозах и контругрозах) интегрированный в задачи управления (стимулирование, распределение ресурсов).

2. Краткое содержание по главам

Глава I. Модели коалиционного взаимодействия

Автор проводит ревизию теории кооперативных игр для нужд управления.

Выбор концепции решения: В качестве основного критерия устойчивости коалиции выбрано C-ядро (Core). Если C-ядро не пусто, существует такое распределение выигрыша, что ни одной группе не выгодно отделяться.
Проблема: Для многих игр C-ядро пусто (система неустойчива). В таких случаях автор предлагает использовать концепцию решения в угрозах и контругрозах (уточнение переговорного множества), чтобы предсказать, какие коалиции наиболее вероятны.

Глава II. Взаимодействие при полной информации (Стимулирование)

Здесь рассматриваются ситуации, где Центр знает параметры агентов, но агенты могут кооперироваться.

Веерные структуры: В простой структуре (один начальник — много подчиненных) показано, что если технологии позволяют агентам перераспределять работу, они могут «оптимизировать» выполнение плана так, что Центру это безразлично (он получает результат), но агенты выигрывают за счет перераспределения усилий.
Матричные структуры: Рассмотрена проблема двойного подчинения. Доказано, что полная кооперация менеджеров среднего звена (проектов и отделов) часто невозможна без специального согласования интересов с высшим руководством.
Формирование состава: Интересный вывод: агенты могут сами исключать неэффективных участников из системы («увольнять» коллег), перераспределяя их задачи и зарплату между собой, если это выгодно коалиции.

Глава III. Взаимодействие с сообщением информации (Распределение ресурсов)

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

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

3. Дополнительные знания (контекст)

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

Связь с Mechanism Design: Работа Губко лежит в русле мировой теории *Mechanism Design* (Гурвич, Маскин, Майерсон). Однако западная школа чаще фокусируется на *Coalition-Proof Nash Equilibrium* (равновесие, устойчивое к коалициям), в то время как Губко адаптирует понятие C-ядра.
Эффект «Зайца» (Free Rider Problem): В работе мало акцента на поведенческую экономику, но коалиции часто разваливаются не из-за математической невозможности деления выигрыша, а из-за недоверия и желания отдельных участников «проехать зайцем» за счет усилий коллектива.
Блокчейн и DAO: Современные децентрализованные автономные организации (DAO) сталкиваются ровно с теми же проблемами, что описаны в Главе III. Механизмы голосования и распределения токенов часто атакуются именно коалициями пользователей (sybil attacks или сговор «китов»). Математика из этой книги применима к криптоэкономике.
Асимметрия информации: Книга подтверждает фундаментальный закон кибернетики: эффективность управления ограничена степенью информированности Центра. Уменьшение неопределенности (знание диапазонов пиков функций полезности) прямо конвертируется в устойчивость системы.

4. Итог

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

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

---

5. Рекомендации и переосмысленные выводы

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

Переосмысленные выводы:

Коалиция — не враг, а инструмент: Традиционно считается, что сговор сотрудников — это плохо (коррупция, саботаж). Однако анализ (особенно Глава II) показывает, что коалиция может действовать как *распределенный вычислитель*. Агенты внутри группы могут решать задачи перераспределения нагрузки эффективнее, чем удаленный Центр.
Самоочищение системы: Математически обосновано (Глава II), что устойчивая коалиция стремится избавиться от «балласта» (неэффективных агентов). Центру не всегда нужно проводить аттестации — достаточно создать механизм, где фонд оплаты труда фиксирован на группу, и группа сама вытеснит слабых игроков (при условии трансферабельной полезности).
Прозрачность ограничений: В Главе III показано: если Центр знает хотя бы границы потребностей агентов, он может гарантировать устойчивость. Отсюда вывод — инвестиции в мониторинг и прозрачность данных о ресурсах важнее, чем усложнение формул премирования.

1. Анализ материала и методологии

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

Особенности подхода:

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

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

2. Краткое содержание по главам

Глава 1. Постановка задачи

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

Исполнители имеют «меру» (сложность работы, объем задач).
Менеджеры имеют функцию затрат $c(\mu_1, \dots, \mu_r)$, зависящую от мер подчиненных групп.
Вводятся понятия сужающих (выгодно нанимать помощников, ведет к многоуровневости) и расширяющих (выгодно увольнять промежуточных начальников, ведет к плоской структуре) функций затрат.

Глава 2. Обзор литературы

Автор критически анализирует существующие модели (Бекманн, Вильямсон, Кальво-Веллиц, Раднер).

*Вывод:* Большинство классических экономических моделей рассматривают только симметричные иерархии с фиксированным числом уровней. Подход Губко более гибок, так как ищет оптимальную структуру без ограничений на симметрию.

Глава 3. Оптимальные деревья (Ядро книги)

Здесь содержится главный теоретический результат.

Доказано, что для однородных функций затрат оптимальная иерархия стремится быть однородным деревом. Это значит, что на каждом уровне менеджеры имеют примерно одинаковую норму управляемости (число подчиненных).
Выведена формула нижней оценки затрат $C_L(N)$. Это теоретический минимум расходов, к которому нужно стремиться.
Предложены алгоритмы построения субоптимальных деревьев (Bottom-Up и Top-Down), которые дают результат, очень близкий к идеальному.

Глава 4. Примеры и приложения

Теория применяется к практике:

Сборочное производство: Доказано, что при определенных условиях последовательная сборка (конвейер) экономически выгоднее параллельной.
Обработка информации (приказы): Моделируется процесс, где менеджер детализирует приказ сверху для подчиненных. Анализируется баланс между квалификацией менеджера и степенью его специализации.
Пределы роста фирмы: Исследуется зависимость затрат на управление от размера фирмы ($n$).
- Если степень однородности затрат $\gamma < 1$, фирма может расти бесконечно (эффект масштаба положительный).
- Если $\gamma > 1$, затраты на управление растут быстрее доходов, фирма становится неэффективной при превышении критического размера.

Глава 5. Обобщения

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

3. Дополнение новыми знаниями и современный контекст

Книга написана в 2006 году. С позиции сегодняшнего дня (2024+) анализ можно дополнить следующими аспектами:

Цифровизация и AI: В моделях Губко функция затрат менеджера $c(\mu)$ — это «черный ящик», зависящий от человеческих когнитивных способностей. Сегодня внедрение AI и ERP-систем меняет эту функцию. IT-системы увеличивают норму управляемости (снижают затраты на контроль), что делает иерархии более плоскими (расширяющий эффект).
Сетевые структуры и Agile: Книга фокусируется на *древовидных* иерархиях. Современный менеджмент часто использует матричные или сетевые структуры (двойное подчинение, кросс-функциональные команды). Модель Губко считает такие связи «дорогими» и неоптимальными, но в условиях высокой неопределенности (VUCA-мир) гибкость сети может окупать излишние затраты на коммуникацию, чего статические модели не учитывают.
Человеческий фактор: Модель предполагает *анонимность* менеджеров (все менеджеры одного уровня одинаковы). В реальности «звездный» менеджер может эффективно управлять 20 людьми, а слабый — только 3. Современный HR-анализ требует ввода индивидуальных коэффициентов в функцию затрат.
Трансакционные издержки: В главе про сборочное производство неявно затрагивается тема трансакционных издержек (Коуз). Современные платформенные экономики (Uber, маркетплейсы) показывают, что алгоритм может заменить целые слои иерархии, сводя функцию затрат менеджера к нулю или константе (стоимость сервера).

4. Итог, рекомендации и переосмысленные выводы

Итог

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

Практические рекомендации (на основе моделей книги):

Правило «7 ± 2» имеет математическое обоснование: Если работа менеджеров однотипна (однородная функция затрат), то норма управляемости должна быть одинаковой по всей иерархии. Если у вас в одном отделе начальник руководит 2 людьми, а в соседнем таком же — 15, ваша структура математически неэффективна. Нужно перебалансировать нагрузку.
Диагностика предела роста: Оцените, как растут зарплаты и расходы на управление при росте отдела.
- Если расходы на управление растут быстрее, чем линейно (степень $\gamma > 1$), вашу организацию нельзя масштабировать простым добавлением людей — она «схлопнется» под весом бюрократии.
- Решение:* Либо дробить компанию на независимые юниты (рыночные отношения внутри фирмы), либо внедрять IT (менять саму функцию $c(\mu)$, снижая $\gamma$).
При слияниях и поглощениях: Используйте алгоритм «Bottom-Up» (снизу-вверх). Сначала объединяйте мелкие подразделения в кластеры, потом кластеры в департаменты. Это дешевле, чем пытаться натянуть новую структуру сверху.
Квалификация vs Специализация: В главе 4 показано, что при низкой квалификации управленцев выгоднее делать структуру более многоуровневой (узкая норма управляемости). Если вы нанимаете дорогих профи, делайте структуру более плоской. Это математически обоснованный трейд-офф.

Переосмысленные выводы (Insight):

Иерархия — это компрессор информации. Главный вывод из главы 4.3: смысл иерархии не во власти, а в сжатии информации при передаче снизу вверх и детализации приказов сверху вниз. Оптимальная структура — это оптимальный алгоритм сжатия данных. Если данные не сжимаются (каждый чих сотрудника требует внимания гендиректора), иерархия парализуется.
Симметрия — признак здоровья. Теоретически доказано, что для выпуклых функций затрат оптимальное дерево стремится к симметрии. Сильные перекосы («флюсы») в оргструктуре — верный признак неэффективности расходов.
Цена контроля. Стоимость иерархии — это цена, которую мы платим за невозможность одного человека управлять всем сразу. Главная задача организационного дизайна — не «красиво нарисовать квадратики», а минимизировать эту цену через подбор такой нормы управляемости $r$, при которой производная затрат равна нулю. Для большинства стандартных задач это $r \approx 5..9$.

Зря я ему память ставил больше 🥲 ... проект – “Монолит”

Sat, 03 Jan 2026 19:30:34 +0300

вот же блин, не ждал я тут подвоха 😭

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

🥹

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

ну прям мечта сисадмина и не только))) это по сути 4 в одном. через proxmox 4 виртуалки. Первая True Nas Scale для массива, вторая ubuntu server для докеров и Portainer тоже с gpu и третья виндовая для gpu в виндовой среде. Встречайте...

Проект “Монолит”: Как собрать домашний сервер мечты за миллион (и зачем это вообще нужно)

Говорят, что универсальных инструментов не бывает. Что “Швейцарский нож” режет хуже скальпеля, а универсальная шина хуже зимней. Мы решили бросить вызов этому утверждению. Ну я и мой электронный друг Gemini.

Задача звучала амбициозно: собрать в одном компактном корпусе устройство, которое заменит целый IT-отдел. Оно должно быть:

AI-станцией для запуска “тяжелых” нейросетей (LLM) локально.
Графическим ПК топового уровня (4K/8K видео).
Корпоративным хранилищем (NAS) на 100+ ТБ с надежностью банка.
Лабораторией виртуализации для Docker, Kubernetes и DevOps-экспериментов.

И всё это должно работать 24/7, стоять дома и не напоминать шумом взлетающий Боинг. Спойлер: у нас получилось.

Почему не Mac Pro и не облака?

Первый вопрос, который задают рациональные люди: *“Зачем тратить 1.2 млн рублей на самосбор, если есть MacBook Pro, AWS и простая дисковая шуршалка в углу?”*

MacBook M4 Max прекрасен, но это “золотая клетка”. На нем не развернешь серьезный кластер виртуализации, в нем нет 100 ТБ памяти, и он все еще слабее в AI-обучении, чем топовые GPU. Ну и закрыл крышку – прод упал.
Облака — это игла подписки. Аренда мощностей уровня нашей сборки (A100/H100) будет стоить те же деньги за год-полтора, но в итоге у вас не останется ничего.

Мы выбрали путь “Digital Sovereignty” (Цифровой суверенитет). Своё железо, свои данные, свои правила.

Анатомия Монстра: Разбор “железа”

Каждый компонент здесь — результат компромиссов и долгих споров. Вот наша “Золотая конфигурация”:

1. Сердце: Архитектура “Всё в одном”

Мы отказались от серверных Threadripper в пользу AMD Ryzen 9 9950X3D.

*Зачем?* Нам важна однопоточная производительность для графики и отзывчивости системы. 16 ядер Zen 5 — это избыточно для дома, но идеально для виртуализации. А X3D-кэш делает этот “сервер” лучшим графическим ПК в мире.
*Материнская плата:* MSI MAG X870E Tomahawk. Надежная база с хорошим VRM, способная переварить этот процессор 24/7. Есть еще Eco режим, что позволит немного снизить мощность, но выиграть в теплоотдач и работе 24x7.

2. Мозг AI: Революция 5090 D

Сначала мы смотрели на RTX 4090. Но потом решили взглянуть на NVIDIA RTX 5090 D (32GB).
Это “Game Changer”.

Потребительские карты обычно имеют 24 ГБ памяти. Этого мало для серьезных языковых моделей (LLM). Llama-3-70B туда влезает только “порезанной”.
32 ГБ GDDR7 памяти у 5090 D открывают портал в мир взрослого AI.
Двухслотовая турбина выбрасывает горячий воздух из корпуса, спасая остальные компоненты от перегрева. Да, это стоит 340 000 рублей, но альтернатива (профессиональные карты RTX 6000) стоит в 3 раза дороже. Это отличный истребитель, но не космический крейсер enterprise уровня.

3. Хранилище: Надежность прежде всего

Диски: 8 штук **WD Ultrastar по 22 ТБ. Это 176 ТБ “сырого” объема.
Контроллер: Настоящий серверный HBA-адаптер **LSI 9300-8i в прошивке IT-Mode. Никаких программных RAID на материнской плате, только хардкор.
Файловая система: ZFS в режиме **RAIDZ2 (аналог RAID 6). Могут умереть любые два диска одновременно — данные выживут.

4. Память: Золотая (в прямом смысле) DDR5 ECC

Самая болезненная строка бюджета. 128 ГБ DDR5 ECC.
Из-за бума ИИ цены на память взлетели. Комплект из 4 планок по 32 ГБ сейчас стоит около 200 000+ рублей.

Можно ли сэкономить и взять обычную?* Нет. ZFS активно использует оперативную память. Ошибка в бите памяти может разрушить файловую систему. Для сервера 24/7 ECC (коррекция ошибок) — обязательное требование. Лучше этим не пренебрегать.

5. Корпус: Jonsbo N5

Это магия инженерии. Красивый черный куб, куда помещается E-ATX плата, полноразмерная видеокарта и 8 жестких дисков. Мечта с красивыми деревяшками на лицевой панеле :)

Программная магия: Как этим управлять?

Железо — это только половина дела. Вся мощь раскрывается в софте.
Мы используем Proxmox VE как гипервизор. Это “слоеный пирог”:

VM TrueNAS: Прямой проброс контроллера LSI. Эта виртуалка управляет дисками и раздает файлы по сети.
VM Windows 11: Прямой проброс RTX 5090. Подключаем монитор/клавиатуру — и это мощнейший графический ПК. Или подключаемся удаленно через Moonlight.
VM Ubuntu Server + Docker (Portainer): Здесь живут “слуги”: Home Assistant (умный дом), Plex (кинотеатр), Nextcloud (ваше личное облако) и среды для разработки.

Экономика: Игрушка или Инвестиция?

Цена сборки чуть переваливает за 1 250 000 рублей. Безумие?
Смотря как посмотреть.

Если рассматривать это как консоль для игр — безумие.
Но если вы IT-инженер, DevOps или AI-энтузиаст, это устройство становится активом:

Аренда мощностей: В простое карту 5090 можно сдавать в аренду на площадках типа Vast.ai для обучения чужих нейросетей, отбивая стоимость “железа”.
Обучение и Карьера: Навыки поднятия Kubernetes-кластера дома или тонкой настройки LLM стоят на рынке труда гораздо дороже миллиона.
Свой стартап: Это готовый MVP-стенд для запуска своего AI-сервиса без трат на облака.

Итог

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

Добро пожаловать в клуб владельцев виртуальных “Monolith”. 🤪

UPD: 25.01.2026

Первый шаг к монолиту сделан.

Кстати, конфигурация немного поменялась. Самсунг ssd заменил в плане на Микрон серверный по 960gb, но 4 штуки. У них оказался срок службы гораздо большое. в 5-7 раз где-то. Они будут работать в Raid10 или raidz1 с блоком 32к. Места будет чуть меньше в raidz1, где то 2.7tb.

Почему Micron 7450 MAX 1.6TB лучше Samsung 990 PRO UPD: не подходит, надо 2280, будет или 800gb или найду Trancend с PLP

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

Бессмертие (Endurance):
- Samsung 990 PRO (2TB):** Ресурс ~1,200 TBW.
- Micron 7450 MAX (1.6TB): Ресурс **8,700 TBW (См. Table 3 в инструкции).
- Итог: Micron выносливее **в 7 раз. Вы можете писать на него базы данных и логи круглосуточно, и он переживет сам сервер.

Over-provisioning (Резервная область):
Почему объем такой странный — 1.6 ТБ, а не 2 ТБ?
Micron намеренно “скрыл” около 400 ГБ флеш-памяти. Контроллер использует это скрытое место, чтобы перемещать данные, выравнивать износ и поддерживать высокую скорость, когда диск заполнен.
У Samsung 990 PRO этой резервной области почти нет, поэтому при заполнении на 90% он начнет тормозить. Micron 7450 MAX будет работать на полной скорости даже если вы забьете его под завязку.

Скорость случайной записи (IOPS):
Для виртуалок важна запись мелких файлов (4K Random Write).

Micron 7450 PRO:** 120,000 IOPS.
Micron 7450 MAX: **250,000 IOPS (См. Table 2).
Модель MAX в два раза быстрее обычной серверной PRO-версии на запись. Это идеально для баз данных и ZFS SLOG.

Математика массива на Micron 1.6TB

Если берем 4 таких диска и делаем ZFS RAID10:

$$1.6 \text{ ТБ} \times 4 = 6.4 \text{ ТБ (Сырой объем)}$$
$$\text{Полезный объем (RAID10)} = 3.2 \text{ ТБ}$$

Еще большой плюс: PLP (Power Loss Protection) — Защита от потери питания, которая есть в Micron. На плате распаяны танталовые конденсаторы. Если питание пропадает, у диска есть еще несколько миллисекунд, чтобы сбросить всё из оперативной памяти в ячейки NAND = защита от отключения электропитания и потери данных.

Почему это важно для ZFS, он очень зависит от синхронной записи (Sync Writes) для баз данных и виртуальных машин. Зная, что у диска есть защита PLP, ZFS может безопасно отключать некоторые программные тормоза (O_DSYNC), работая значительно быстрее на мелких операциях записи.

Итого:
3.2 ТБ сверхбыстрого, защищенного от потери питания (PLP), “бессмертного” серверного пространства — это мечта для гипервизора Proxmox.

Короче берем Micron 7450 MAX 1.6TB. Это лучший компонент во всей сборке с точки зрения профессионального подхода. Главное найти его в форм-факторе 2280, а то на материнской плате есть только один длинный порт.

UPD: 22.02.2026

Проц едет.

Диски ssd пришлось заменить на Synology m2 1.6 – других с поддержкой PLP нету в наличии вообще. PLP нужна для защиты от обрывов питания резких. 4 планки будут в 10 массиве, стрейп и зеркало.

Память нашлась в наличии 90к – 48gb ecc ddr5 – но еще не брал(( надо сдать бутылки.

Свой Heroku: запустил Dokku дома и накатил новогоднего :)

Thu, 01 Jan 2026 22:59:46 +0300

Мы привыкли, что для развертывания веб-приложений нужно платить за VPS или разбираться в дебрях Kubernetes. Но если у вас есть домашний сервер (в моем случае — Asustor), вы можете создать свою собственную PaaS-платформу (Platform as a Service), которая работает по принципу *“git push — и готово”*.

Сегодня я расскажу, как настроить Dokku через Portainer, запустить веселое Python-приложение к Новому 2026 году и поделюсь лайфхаками по оптимизации сборки и масштабированию.

Часть 1. Фундамент: Запуск Dokku в Portainer

Dokku — это Docker-контейнер, который управляет другими Docker-контейнерами. Чтобы он заработал на NAS, его нужно правильно запустить. Я использовал Portainer Stack.

Docker Compose конфигурация

Вот рабочий `docker-compose.yml`, который решает главную проблему — доступность приложений из локальной сети.

# version: '3.2'
services:
  agent:
    image: dokku/dokku:${VERSION}
    pid: host.  # ⚠️ важно для работы на NAS
    network_mode: bridge # ⚠️ важно для работы на NAS
    environment:
      DOKKU_HOSTNAME: ${DOKKU_HOSTNAME}
      DOKKU_HOST_ROOT: ${DOKKU_HOST_ROOT}
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ${VOLUME_PATH:-/var/lib/dokku}:/mnt/dokku
    ports:
      - "3022:22" # ⚠️ важно для работы через ssh и что бы не конфликтовал с 22 
      - "80:80"    # Внешний порт 80 -> порт 80 внутри контейнера Dokku
      - "443:443"

Нюансы сети:
Чтобы обращаться к приложениям по красивым домегам типа `my-app.dokku.datahub.mother`, я настроил AdGuard Home в качестве локального DNS-сервера (фильтры получил бонусом – где-то 20% это всякие счетчики, ужас:). Добавил правило Rewrite: `*.dokku.datahub.mother` → `192.168.0.20` (IP моего NAS). Теперь все поддомены (приложения) автоматически ведут на Dokku.

Также для удобства я настроил `~/.ssh/config` на ноутбуке, чтобы не вводить порты вручную:

Host dokku.datahub.mother
  HostName 192.168.0.20
  Port 3022
  User dokku

ну и ключ сам так можно добавить

echo "ВАШ_ПУБЛИЧНЫЙ_КЛЮЧ" | dokku ssh-keys:add dokku

Часть 2. Приложение “my-first-app”: Новогоднее гадание

Для теста я написал простое Flask-приложение, которое рассчитывает ваш возраст в наступающем 2026 году.

Код приложения (`app.py`)

from flask import Flask, request

app = Flask(__name__)

@app.route('/')
def home():
    return """
    <h1>Приветствую в игре Нового 2026 года! 🎉</h1>
    <p>Это веселая интерактивная игра в честь Нового года. Угадай свой возраст на 1 января 2026!</p>
    <p>Введи свой год рождения:</p>
    <form action="/result" method="get">
        <input type="number" name="birth_year" min="1900" max="2025" required>
        <button type="submit">Угадать возраст на Новогодний 2026!</button>
    </form>
    """

@app.route('/result')
def result():
    birth_year = request.args.get('birth_year')
    if not birth_year or not birth_year.isdigit():
        return "Ошибка: введи корректный год рождения!"
    
    birth_year = int(birth_year)
    age_in_2026 = 2026 - birth_year
    return f"""
    <h2>Результат: 🎇</h2>
    <p>В 2026 году тебе будет {age_in_2026} лет!</p>
    <p>Счастливого Нового 2026 года! Пусть все твои желания сбудутся!</p>
    <a href="/">Играть снова</a>
    """

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=5000)

Подготовка к деплою

Чтобы Dokku понял, как запускать это чудо, нужны два файла в корне проекта:

`requirements.txt` (зависимости):

Flask==2.3.2
gunicorn==20.1.0
Werkzeug==2.3.3

`Procfile` (команда запуска):

web: gunicorn app:app --bind 0.0.0.0:5000

`.python-version` (опционально, явная версия Python):

3.11.14

Процесс деплоя

Все делается через Git, как на “взрослых” платформах:

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

ssh dokku@dokku.datahub.mother apps:create my-first-app

Отправляем код:

git init
    git add .
    git commit -m "Happy New Year 2026 version"
    git remote add dokku dokku@dokku.datahub.mother:my-first-app
    git push dokku master

Если вы до этого еще что-то деплоили, то лучше проверить куда гит смотрит

git remote -v

ну и поменяем еще не верное

git remote remove dokku

git init
    git add .
    git commit -m "Happy New Year 2026 version"
    git remote add dokku dokku@dokku.datahub.mother:my-first-app
    git push dokku master

После пуша Dokku сам скачает Python, установит Flask и запустит Gunicorn. Через минуту-две приложение доступно по адресу `http://my-first-app.dokku.datahub.mother`.

Еще нужно домен установить

ssh dokku@dokku.datahub.mother domains:set my-first-app my-first-app.dokku.datahub.mother

или можно сразу глобально его установить:

ssh dokku@dokku.datahub.mother domains:set-global dokku.datahub.mother
# но тогда придется удалить ручную привязку 
ssh dokku@dokku.datahub.mother domains:clear my-first-app

# не забыть перебрать nginx ( на всякий случай ) 
ssh dokku@dokku.datahub.mother proxy:build-config my-first-app

Сертификат сгенерировать

ssh dokku@dokku.datahub.mother certs:generate my-first-app my-first-app.dokku.datahub.mother

и проверить порты

ssh dokku@dokku.datahub.mother ports:report my-first-app

если порты не корректные, то можно их установить так:

ssh dokku@dokku.datahub.mother ports:set my-first-app http:80:5000 https:443:5000

Часть 3. Уровень PRO: Скорость (uv) и Marimo

Аппетит приходит во время еды. После простого Flask-приложения я решил развернуть что-то посерьезнее — Data Science ноутбук на Marimo, и столкнулся с реальными сложностями и особенностями. Для примера брал их дело ноутбук https://marimo.app

1. Ускорение сборки с `uv`

Стандартный `pip` устанавливает пакеты медленно. Если проект большой, деплой может висеть минутами.
Я перешел на uv — новый менеджер пакетов на Rust.

Вместо `requirements.txt` я использовал `pyproject.toml` и `uv.lock`. Dokku (благодаря современным buildpacks) увидел `uv.lock` и переключился на быстрый режим. Время сборки сократилось в разы.

2. Ловушка масштабирования (Scaling)

Marimo — это stateful приложение (хранит состояние в памяти). Flask, который мы делали выше — stateless.

Когда я задеплоил Marimo, Dokku по умолчанию все было хорошо, но потом я решил масштабировать его и сделал так

ssh dokku@dokku.datahub.mother ps:scale my-marimo-app web=3

далее Dokku запустил 3 копии контейнера (`web=3`).
Начался хаос:

Интерфейс открывался.
При нажатии кнопок вылетала ошибка `Invalid server token`.

Почему? Браузер загружал страницу с *Контейнера 1*, а WebSocket-запрос улетал в *Контейнер 2*, который ничего не знал про мою сессию.

Решение:
Для интерактивных приложений (Streamlit, Marimo, Jupyter) всегда принудительно ставьте одну реплику:
Ну ли придется делать липкие сессии на nginx или еще что-то.

ssh dokku.datahub.mother ps:scale my-marimo-app web=1 # все вернуло в рабочее состояние.

А если не хватает мощности — лучше дайте этому единственному контейнеру больше ресурсов, чем пытаться плодить клонов или дайте каждому запускать свой:

Вот так можно установить лимиты или повысить их:

ssh dokku.datahub.mother resource:limit my-marimo-app --memory 2G --cpu 2

3. SSL в локальной сети

Браузеры блокируют микрофон и иногда WebSockets на HTTP-сайтах. Для локальной сети Let’s Encrypt не сработает (нет публичного IP), ну и его чуть сложнее запускать.
Я решил вопрос генерацией самоподписанного сертификата одной командой Dokku:

ssh dokku.datahub.mother certs:generate my-first-app my-first-app.dokku.datahub.mother

Браузер ругается, но приложение работает полноценно.

Еще я прогнал стресс тесты

ab -n 10000 -k -c 2000 ...

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

Итог

Dokku на домашнем сервере — это отличный инструмент.

Для простых API (Flask/FastAPI): Работает “из коробки” идеально.
Для сложных задач: Использование `uv` делает работу комфортной, а понимание разницы между *Stateless* и *Stateful* приложениями спасает от занудных ошибок и отладки.

Теперь my-first-app готово предсказывать возраст всем гостям на Новый год, а сервер готов к новым экспериментам! 🎄 Пожалуй оставлю его для будущих экспериментов. Прижился как-то быстро. Кстати у Dokku есть коммерческая PRO версия, а точнее не версия, а полноценный UI с кнопочками и стоит он 900$. https://dokku.com/docs/enterprise/pro/

Пора чего-нибудь накатить новогоднего еще :)