Дата-платформа в 2026 году: Lakehouse, миграция и AI-агенты

Первая граница проходит между операционными и аналитическими задачами. OLTP-система оптимизирована для коротких конкурентных операций и точечных чтений с задержкой в миллисекунды, тогда как аналитика сканирует большие объёмы и соединяет наборы данных. Гости приводят конкретный ориентир: в TPC-H на Postgres два из двадцати запросов не завершились за час уже на таблицах до сотни миллионов строк. Поэтому рост аналитики в какой-то момент требует специализированного движка, а не только более мощного сервера.

Классическое MPP-хранилище хорошо работает до определённого масштаба, но связанные хранение и вычисления создают пределы. Один медленный узел задерживает весь распределённый запрос, конкурирующие пользователи усложняют изоляцию и QoS, а расширение кластера требует перераспределять все данные. Гости называют ориентир до 20–30 узлов, после которого эксплуатационная цена быстро растёт. Современные сети, компрессия и чтение только нужных колонок сделали удалённое объектное хранение практичным и открыли путь к разделению хранения и вычислений.

Минимальный Lakehouse включает S3-совместимое хранилище, Iceberg как табличный и транзакционный слой, каталог метаданных, вычислитель и управление доступом. Под реальной нагрузкой появляются повторные попытки, конкурентные записи, уплотнение мелких файлов, очистка потерянных файлов, совместимость компонентов и тысячи запросов диапазонов байтов к S3. Trino при этом сохраняет MPP-распараллеливание и чувствительность к задержкам хранилища. Подход Tengri другой: лёгкий изолированный вычислитель можно поднять для сессии, повторные чтения ускоряет кэш с учётом структуры запроса, а тяжёлым запросам добавляется ситуативный параллелизм.

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

Для аналитики на естественном языке одного доступа к SQL недостаточно. Агенту нужен семантический слой и детерминированные проверки типовых ошибок: неверного фильтра или соединения, которое незаметно размножает строки. В Tengri уже есть Теодор, отвечающий на вопросы по данным, и Даша, строящая дашборды. Они могут уточнять бизнес-вопрос, исследовать таблицы и выполнять проверочные запросы, но удобный интерфейс не снимает требований к корректности результата.

Аналитик с агентом, по оценке Николая, генерирует примерно в пять раз больше запросов, причём среди них встречаются декартовы произведения огромных таблиц и даже разрушительный SQL. Поэтому права должны реально запрещать недопустимые действия, а изоляция — не позволять одному запросу остановить отдел или руководительские дашборды. Собственный контур проверок Tengri подтверждает, что агент не просто написал SQL, а выполнил его, прочитал результат и использовал только разрешённые операции. Фиксированные дашборды при этом останутся: за проверяемый результат всё равно должен отвечать человек.