Инфраструктура данных 2052: что, если у данных больше не будет «прода» и «истории»?

Содержание статьи

Если мысленно вернуться в 1980-е, аналитика во многом находилась буквально над production

Данные появлялись в операционных системах, затем из них строились отчёты, выгрузки и аналитические витрины. Постепенно мы начали выносить аналитику подальше от production: появились отдельные хранилища, ETL, data warehouse, затем data lake, lakehouse и, наконец, огромный набор специализированных систем для streaming, batch, realtime и research

Каждый раз мы решали вполне реальные проблемы своего времени. Но вместе с этим постепенно привыкли к довольно странной модели:

production хранит настоящее, data lake — прошлое, Kafka — поток, а research живёт где-то ещё

И вот здесь мне стало интересно немного заглянуть вперед…

А что, если в 2052 году мы перестанем воспринимать всё это как разные сущности?

Опираясь не на фантазии, а на то, что смог найти в технических блогах — не концепты, а реальные прототипы

Если не хотите много читать, в конце статьи вся суть одной картинкой

Сначала важное уточнение

Сразу оговорюсь: я не придумал эту идею с нуля

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

В частности, похожие идеи нашел в работах Jay Kreps о логах и Kappa Architecture

Поэтому ниже не попытка открыть новый фундаментальный принцип

Мне интересно другое: что будет, если довести эту идею до предела и попробовать построить на её основе инфраструктуру, где история и production вообще перестают быть разными сущностями, а основным потребителем данных становится автономный агент

Определим требования

Прежде чем выбирать технологии, нужно понять, кто и как будет потреблять данные.

Чтобы не писать про абстракции, будем собирать инфраструктуру под биржу.

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

Это могут быть торговые агенты, risk-системы, исследовательские агенты, backtesting и аналитика

Но у этой инфраструктуры будет одно принципиальное отличие от привычной модели

Мы не будем разделять настоящее и историю

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

Production — это просто его текущая точка
История — тот же самый поток, но с курсором, установленным в прошлом

Поэтому у нас нет отдельного «production data» и отдельного «historical data». Есть один источник истины, из которого разные потребители могут читать данные в нужной им точке времени

Это не совсем фантастика: похожее направление уже появляется в современных data-платформах. Например, подход Kafka + Iceberg рассматривается как способ объединить streaming и durable analytics вокруг единого слоя данных. А более радикальный вариант — zero-copy доступ к Kafka и Iceberg как к единому логическому набору данных, без постоянного перемещения данных между ними.

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

Границы данных

Чтобы не строить архитектуру в вакууме, зададим ей достаточно экстремальные входные условия

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

Будем считать, что у нас есть:

100 связанных потоков данных;
каждый поток — до 100 000 событий/сек;
размер одного события — 4–10 КБ;
потоки связаны между собой ключами: instrument_id, timestamp, order_id, trade_id и т. д.

Метрика

На 1 поток

На 100 потоков

Событий/сек

100 тыс.

10 млн

Размер события

4-10 КБ

4–10 КБ

Raw throughput

0,4-1 ГБ/с

40–100 ГБ/с

В сутки

34,6–86,4 ТБ

3,46–8,64 ПБ

В год

12,6–31,5 ПБ

1,26–3,15 ЭБ

За 10 лет

126–315 ПБ

12,6–31,5 ЭБ

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

Архитектура

Основная проблема

Хранилище за 10 лет

Стоимость хранения в год

Kafka + бесконечный retention

Kafka превращается в гигантский persistent log

12,6–31,5 ЭБ

$3,5–8,7 млрд

Lambda: Kafka + Data Lake

Два хранилища + ETL/копирование

12,6–31,5 ЭБ

$3,5–8,7 млрд+

Kafka + Flink + Iceberg

Лучший современный вариант, но масштаб всё равно экстремальный

12,6–31,5 ЭБ

$3,5–8,7 млрд+

Kafka Tiered Storage

Снижает объём hot storage, но не общий объём данных

12,6–31,5 ЭБ

$3,5–8,7 млрд

S3/Iceberg напрямую

Дешёвое хранение, но нет требуемого realtime

12,6–31,5 ЭБ

$3,5–8,7 млрд

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

А хочется получить всё сразу: дешёвое хранение, realtime и возможность в любой момент вернуться в прошлое

Начинаем строить: единый поток и курсор во времени

Вместо того чтобы разделять данные на realtime, production, history, backtest и research, представим, что у нас существует один непрерывный поток событий

У каждого потребителя есть cursor — курсор во времени.

Торговый агент находится в NOW и получает события практически в realtime

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

Backtesting может поставить курсор на конкретный момент и воспроизвести события вплоть до нужного timestamp.

То есть history больше не является отдельной сущностью.

Есть только поток. А «настоящее» — это просто его последний доступный timestamp.

А что происходит со стоимостью?

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

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

В результате стоимость становится прозрачной:

данные — общий ресурс, а compute — расход конкретного потребителя

Если бы систему такого типа строили сегодня, нам больше всего подходит стек:

Apache Paimon + Flink

Требование нашей архитектуры

Что закрывает Apache Paimon + Flink

Чего не хватает

Единый поток данных

Paimon умеет работать как streaming table: Flink может читать таблицу как непрерывный unbounded stream и получать новые изменения.

Поток всё ещё концептуально привязан к table/snapshot-модели, а не к универсальной временной шкале событий всего рынка

Настоящее + история в одном слое

Paimon объединяет batch и streaming: можно читать актуальный snapshot и продолжать получать изменения.

Нет нашей абстракции «production = cursor на последнем timestamp» для всех типов workloads

Time travel

Есть чтение snapshot по ID или timestamp.

Нам нужен не просто снимок таблицы, а воспроизводимый поток событий с произвольного момента T

Cursor во времени

Есть scan.timestamp-millis, streaming time travel и consumer progress.

Нет единого market-wide cursor, который синхронно позиционирует десятки/сотни связанных потоков

Независимые consumers

Paimon имеет consumer-id: consumer сохраняет прогресс и защищает нужные snapshots от удаления.

Consumer — это всё ещё потребитель таблицы. Нам нужен универсальный механизм агент → cursor → dataset → compute budget

Replay

Можно начать streaming consumption с определённой точки и продолжить изменения.

Нужен полноценный replay одинакового event stream, пригодный одновременно для backtest, research и production

Realtime latency

Paimon + Flink поддерживают streaming processing.

Для нашего экстремального realtime это не обязательно лучший транспорт: lake-oriented storage не должен автоматически становиться ultra-low-latency event bus

100 связанных потоков

Можно моделировать данные таблицами, ключами и временными полями.

Нет встроенной концепции единого temporal coordinate system для синхронного чтения 100 потоков

Много агентов

Flink позволяет масштабировать обработку, Paimon поддерживает множество consumers.

Нам нужна модель, где добавление consumer не требует копирования данных и не создаёт пропорциональный storage overhead

Data хранится один раз

Paimon — lake format, позволяющий использовать один слой данных для batch/streaming workloads.

Нужно довести это до принципа: один physical dataset → множество temporal views → разные compute workloads

Compute отдельно от данных

Flink отделяет computation от storage.

Нет нативной модели cost attribution: сколько конкретный агент прочитал данных + сколько compute потребил

Стоимость research

Можно читать только нужные данные через фильтры и оптимизации.

Нужен явный data/compute budget на каждый research/job и прозрачный Cost-to-Value

10 лет истории

Paimon поддерживает snapshots, time travel и streaming history.

В нашей постановке объём настолько огромен, что нужен принципиально другой подход к retention, физическому хранению и представлению данных

Apache Paimon + Flink уже близки к тому, что мы хотим построить

Здесь уже есть streaming, batch, time travel, snapshots и независимое потребление данных.

Но пока это всё ещё lakehouse с возможностями streaming, а мы хотим представить систему, где сама временная шкала становится главным интерфейсом к данным

Не table → snapshot → query, а:

dataset → time cursor → consumer → compute

И вот это уже будет нашей архитектурой

Когда это может стать реальностью?

Я бы условно разделил развитие на три этапа.

2026-2032 Unified Streaming Lakehouse

Fluss, Paimon, Iceberg и похожие проекты будут всё сильнее сближать streaming и lakehouse: единые метаданные, tiering, union reads, time travel. Это уже происходит сегодня.

Но при экстремальных масштабах, которые мы задали выше, стоимость хранения и перемещения данных всё ещё остаётся главным ограничением.

То есть мы научились объединять realtime и history на уровне архитектуры, но пока не научились сделать это экономически прозрачным для множества потребителей

2032-2042 Temporal Data Platform

Вероятно, главным объектом системы станет уже не table и не topic, а временной dataset.

Storage, streaming и replay начнут восприниматься как разные способы работы с одним объектом.

И здесь меняется сама модель стоимости:

Данные становятся общим ресурсом, а compute — расходом конкретного потребителя.

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

Это позволяет наконец честно ответить на вопрос: «Сколько нам стоит конкретный research?»

2042-2052 Agent-native data infrastructure

И вот здесь появляется самое интересное.

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

«Возьми этот dataset, поставь cursor на 17 марта 2048 года, воспроизведи рынок до нужного состояния и выдели мне $X compute budget».

А система сама решает:

где физически лежат данные;
какую часть поднять в hot storage;
что прочитать;
что пересчитать;
что закэшировать;
сколько это стоило.

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

Она становится частью самого интерфейса данных

То есть технологический прогресс здесь не обязательно должен прийти в виде одного нового продукта

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

streaming storage + lakehouse + time travel + cheap object storage + zero-copy/columnar formats + distributed compute + AI agents

И тогда наша идея «history больше нет» перестаёт быть фантазией.

Есть один поток событий. Есть его временная шкала. А всё остальное — просто разные потребители с разными курсорами и разными вычислительными бюджетами