AI и платформа данных

Александр Поломодов начинает разговор с Николаем Головым с практической задачи: подключить AI к данным организации, где уже работает множество отдельных баз. Доступ через MCP сам по себе не даёт ответа, как сопоставить сведения из разных систем. Если совокупность данных не помещается ни в одну из них, агенту недостаточно последовательно получить несколько выборок: нужен способ выполнить общий расчёт и вернуть результат.

Голов предлагает рассматривать архитектурные подходы, а не объявлять единственно правильное решение. Инженер хранилищ привычно посадит агента на готовые витрины, но крупные поставщики ищут и другие пути. Различие между ними — уровень, на котором объединяются данные: поток изменений, общий движок запросов, одна СУБД или единое хранение. Реальные продукты смешивают элементы этих подходов, поэтому схема помогает понять компромиссы, а не раздать окончательные места в рейтинге.

Первый подход собирает данные из исходных систем через CDC или ETL и преобразует их до аналитических витрин. CDC передаёт изменения таблиц; ETL извлекает данные, преобразует и загружает их в целевую систему. Не каждой организации нужен непрерывный поток: иногда достаточно периодически копировать таблицу целиком.

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

Второй подход позволяет запросить несколько баз через один движок. В разговоре его иллюстрируют Presto и Trino: движок знает расположение таблиц, разбирает SQL, обращается к источникам и соединяет полученные части. Привлекательность очевидна — можно начать работать с данными без отдельного проекта по построению хранилища. Для последовательных небольших выборок это действительно удобная модель.

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

На примере Microsoft и AWS Голов показывает развитие первого подхода: поставщик берёт на себя передачу изменений в аналитическое хранение. В Microsoft разговор касается OneLake, в AWS — zero-ETL и открытых таблиц Iceberg. Отказ от ручной сборки каждой интеграции облегчает старт, однако не устраняет инженерных вопросов: как измерить задержку, восстановить пропущенные изменения после переключения базы и проверить поддерживаемый источник.

ClickHouse и Google обсуждаются как гибриды федеративного доступа и репликации. В варианте ClickHouse агент работает с PostgreSQL и аналитическим движком; крупные данные можно заранее перенести туда, где их удобнее соединять. Google связывает операционные системы с BigQuery, в разговоре — на примере Spanner, используя передачу изменений и обратное направление данных. Выбор таблиц для копирования, допустимой задержки и места расчёта всё равно требует архитектурной работы.

Голов отдельно обращает внимание на стоимость облачной обработки. Дополнительные копии и передача данных увеличивают счёт, а неудачный запрос может выполнить огромную бесполезную работу. Его критика мотивации поставщиков — позиция гостя; практический вывод из разговора заключается в необходимости самостоятельно понимать модель оплаты и границы нагрузки. Удобство интеграции не служит доказательством экономичности.

Третий подход обещает выполнять транзакции и аналитику в одной системе. Строчное представление удобно для операционных запросов, колоночное — для аналитических; платформа поддерживает их согласованность и добавляет специализированные индексы. В разговоре появляются Oracle, SAP HANA, SingleStore и TiDB. Это семейство идей обычно связывают с HTAP — совместной транзакционной и аналитической обработкой.

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

Четвёртый подход использует объектное хранилище и открытый табличный формат, поверх которого работают разные движки. Аналитический и транзакционный исполнитель специализируются на своих задачах, а таблицы остаются доступны в общем слое. Голов проводит важное различие с CDC: поток событий ещё надо превратить в актуальное состояние таблицы, тогда как общий слой должен уже предоставлять это состояние. Само наличие S3 под аналитикой не означает, что система реализовала такую модель.

Databricks и Snowflake рассматриваются как направления объединения аналитики и PostgreSQL. В истории Databricks обсуждаются Neon, Mooncake и возможный сценарий: агент находит закономерность, создаёт сервис с операционной базой, а другие агенты анализируют его данные. Голов говорит, что компоненты ещё собираются в общую систему. Snowflake обсуждается через приобретение Crunchy Data и pg_lake — возможность работать из PostgreSQL с данными в Iceberg. Разговор описывает движение поставщиков, а не готовую универсальную платформу.

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

В финале участники возвращаются к выбору подхода. Передача изменений — понятная стартовая точка, после которой остаётся подготовить удобные данные. Федеративный доступ особенно привлекателен для небольшого числа систем и ограниченной нагрузки. Универсальная СУБД переносит ответственность внутрь продукта. Общее хранение обещает больше свободы вычислений, но требует решить сложные вопросы записи и совместной работы движков.

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