Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Статистика уровня раздела (Partition-level stats): Хранится в списке манифестов (manifest list) Iceberg. Эти статы описывают диапазон значений разделов для всех данных в определенном файле манифеста Iceberg. Для раздела по `day(event_timestamp)` это будут самый ранний и самый поздний дни, присутствующие в файлах, отслеживаемых этим манифестом.
2. Статистика уровня столбца (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)

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

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

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

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

4. Отсечение групп строк (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`: по мере того как движок выполнения обрабатывает рабочие единицы и отправляет результаты обратно, планировщик одновременно делает две вещи:

1. Поддерживает ограниченную “кучу” (heap) из лучших 5 результатов, увиденных на данный момент.
2. Следит за “ватерлинией” (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-запроса.

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

1. Коммодитизация аналитики: Cloudflare делает с Big Data то же, что ранее сделала с CDN и защитой от DDoS — делает сложные энтерпрайз-технологии доступными “по кнопке”. Использование открытого стека (Rust + Arrow + DataFusion) — это сейчас золотой стандарт построения современных СУБД (по этому пути идут такие гиганты как InfluxDB 3.0, LanceDB и др.). Cloudflare не изобретает велосипед, а собирает очень быструю ракету из лучших деталей.
2. Убийца Snowflake/Databricks для “бедных”? Для огромных корпораций Snowflake и Databricks останутся стандартом из-за богатого функционала. Но для стартапов и среднего бизнеса, у которых данные лежат в R2 (чтобы не платить за egress трафик AWS), появление R2 SQL делает переезд на сторонние аналитические платформы бессмысленным. Зачем гонять данные туда-сюда, если можно выполнить SQL прямо “на месте”?
3. Синергия с ИИ: Упоминание планов на “индексы” и “геопространственные запросы” намекает на векторный поиск в будущем. Если 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

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

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

1. Apache Fluss — управляемое хранилище для потоковой обработки (Streaming Storage).
2. 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.

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

1. Гибридная модель чтения (Stream-Table Duality): Fluss позволяет читать данные и как бесконечный поток (Log), и как изменяемую таблицу с первичными ключами (Primary Key Table). Это делает реализацию CDC (Change Data Capture) тривиальной: обновления перезаписывают старые значения по ключу.
2. Колоночная проекция (Columnar Projection): В отличие от Kafka, Fluss может отдавать аналитическому движку (Flink) только нужные колонки. Это снижает нагрузку на сеть (`I/O`) в разы.
3. Real-Time Lookups: Fluss поддерживает точечные запросы (Point Lookup) по первичному ключу с задержкой порядка миллисекунд.
   $$Latency_{Fluss} \ll Latency_{Kafka Scan}$$ 
   Это позволяет использовать его как *Serverless State* для приложений, избавляясь от необходимости ставить рядом Redis или RocksDB.
4. 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):

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

2. Streaming Storage (Fluss):
   Fluss принимает данные, индексирует первичные ключи и хранит “горячее” окно (например, 24 часа).
• Flink* выполняет `JOIN` и агрегации прямо поверх Fluss, используя `Lookup Join` (обогащение данных без сохранения большого стейта внутри Flink).

3. Archiving & AI (Paimon/Lance):
   Исторические данные сбрасываются в S3.
• Для классической BI-аналитики используется формат Apache Paimon или Iceberg.
• Для ML-задач данные конвертируются или хранятся в Lance.

4. 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. Выводы и рекомендации

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

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

• Emerging Architectures for Modern Data Infrastructure (a16z)
• Introducing Fluss (Ververica)
• Fluss for Flink (BigDataSchool)
• Lance & Trino Integration Issue (GitHub

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

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

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

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

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

1. Золотой век и падение Хранилищ Данных: Раньше централизованные хранилища данных, созданные архитекторами, обеспечивали «единый источник истины». Это было медленно, дорого, но надежно.
2. Agile, микросервисы и «дамп данных»: Софтверные компании, движимые скоростью, убили роль архитектора данных. Данные перестали проектировать — их начали «сливать» в data lakes. Разрыв между командами, создающими данные (продуктовые разработчики, OLTP) и использующими их (аналитики, дата-сайентисты, OLAP), стал пропастью.
3. Иллюзия 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 — это больше, чем технология. Это философия сотрудничества, которая превращает данные из источника постоянных проблем в настоящий актив, способный обеспечить конкурентное преимущество в эпоху ИИ.

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

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

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

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

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

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

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

В современном маркетинге данные — это новая нефть, а рекламный идентификатор (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*.

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).

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

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

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

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

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

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

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

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

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

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

1. Server-Side Tracking (S2S / CAPI):
   Вместо отправки данных пикселем из браузера (JS), данные о покупке отправляются напрямую с бэкенда магазина на сервер рекламной системы (например, через Facebook Conversions API).
• Плюс:* Не блокируется AdBlock и браузерами. Точность данных выше.
• Минус:* Сложная техническая реализация. Требует согласия пользователя на передачу данных.

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

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

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

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

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

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

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

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

https://github.com/actualbudget/actual

Пробуйте ...

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

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.

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” (архивации). Эпоха ушла.

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

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

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

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

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

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

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

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

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

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