Если мысленно вернуться в 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 и т. д.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Apache Paimon + Flink

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 больше нет» перестаёт быть фантазией.

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

Продолжение экспериментов с данными, торговыми системами и инфраструктурой - в моём Telegram-канале https://t.me/bylabdata

Источники и материалы