Платформы данных

Николай описывает себя просто: всю жизнь он собирает данные в большую кучу, садится сверху и начинает раздавать. Начинал с моделей — кредитный скоринг, прогнозирование, «искусственный интеллект ещё до того, как это стало модным», — и всякий раз упирался в одно: модель делается быстро, а подключение её к данным организации тянется годами, из-за чего проекты выходили не очень успешными. Отсюда интерес к платформе данных, поверх которой живут отчётность, машинное обучение и антифрод. Классика — большой проектный DWH: цели, задачи, витрины, посаженная команда; после запуска остаются дата-инженеры, которые заливают данные и чинят хранилище, и аналитики с дашбордами. Служба одного окна, куда заказчики приносят заявки и слышат «через месяц, через два, в следующем году»: сложное под присмотром — плюс, бутылочное горлышко — минус.

Стандартом это было ещё в прошлом веке, объясняет Николай: и доставка данных, и база, и BI-инструмент были платными и очень дорогими. Но для небольшой организации с парой грамотных людей и десятком аналитиков схема, по его мнению, до сих пор идеальна, хотя большинство так уже не делает: в ManyChat, где он работает, несколько сотен человек и около двадцати аналитиков — и там как раз централизованная команда дата-инженеров и команда аналитиков сбоку. Лет десять назад стал популярен гибрид: единая платформа остаётся, а аналитики расходятся по продуктовым командам и делают дашборды внутри спринта, потому что ждать пару месяцев в чужой очереди несовместимо со скрамом. Так делали в Авито; Александр рассказывает, что в Т-Банке инженеры сидели в структуре DWH, нарезанной по стримам — кредитные, дебетовые, платёжные, маркетинговые, — и их были сотни.

Гибрид держится, пока центральная база тянет нагрузку: в Авито его идеальная форма жила, пока аналитиков не стало примерно пятьдесят, — дальше платформа перестала справляться с параллельными подключениями. Полная децентрализация — это Data Mesh: у каждого домена свои дата-инженеры, аналитики и хранилище, хотят — строят своё, хотят — выгружают всё в Excel. Николай предупреждает, что излагает собственное понимание и ему можно оппонировать: концепция выросла из продуктового подхода и Domain-Driven Design, а дата-продукт неплохо ложится на привычную витрину. Александр добавляет две другие части — федеративное управление со стандартами, чтобы продукты можно было связывать между собой, и платформенный слой, снимающий когнитивную сложность. Автор концепции, как отмечают участники, сама была консультантом и понимала, что в чистом виде это не полетит; дальше начинается фаза «покупайте наших слонов».

Чаще зоопарк вырастает сам: ClickHouse тянет часть сырых данных, сбоку кластеры Spark считают своё, всё перевязано друг с другом. Компании считают это бардаком, а консультант говорит, что у них прото-Data Mesh с ответственностью команд за свои базы; Александр замечает, что такой зоопарк вырастает внутри одной централизованной команды, а Николай возражает: он же вырастает и из доменов — кредитные риски на ClickHouse, кредитование с прогнозами на Spark, — и тогда, отвечает Александр, accidental complexity оказывается внутри продуктовых команд. Цена — критический путь: аналитик спрашивает про отставание своей цифры и слышит «двое суток», потому что дата-продукт на Spark считается после продуктов в Greenplum и PostgreSQL, а ошибка в чужой витрине чинится «через три месяца, пишите письма». В европейской дата-инженерной тусовке шутят, что Data Mesh превращается в Data Mash, пюре: метрику писал уволившийся сотрудник, до него другой, и разбираться никто не хочет. Лечение — базовый домен с клиентами, деньгами, сотрудниками и подразделениями, чтобы путь стал два-три шага.

Отдельная линия — что происходит с самими базами. Стартапы считают аналитику прямо на боевой базе микросервиса и не парятся; из опасного в приемлемое это переводит аналитическая реплика — слейв и так свободен, процессоры простаивают, аналитика считается там. С этим Николай ходил в X5 Digital, когда они в реплику упёрлись; Александр слышал про визит от Кости, но не про саму концепцию. Раньше конец наступал на аналитических таблицах в 10–20 миллионов строк, сейчас порог ближе к сотне миллионов; PostgreSQL и Oracle одномастерные, слейвы берут чтение, а запись — нет. На смену идут MPP-базы: снаружи база, внутри кольцо серверов — ClickHouse и Vertica, разработку которой, по последним новостям, остановили. Но их потолок не в объёме, а в параллелизме: из-за синхронизации по центральному каталогу «select … limit 10» стоит не меньше тяжёлого запроса с оконными функциями, а вставки упираются в десяток в секунду против тысяч и десятков тысяч у PostgreSQL. Лекарство одно — полная копия кластера за миллионы долларов: в Авито её сделали при 50–60 аналитиках.

Дальше — очередной виток: разделение compute и storage. Александр вспоминает статью, где это объясняли тем, что сеть по скорости обогнала диски; Николай считает, что дело было скорее в борьбе со страхом. Первое решение, Athena, устроено грубо: на запрос к данным в S3 с нуля поднимается кластер, качает данные, отдаёт результат и умирает, а ты ждёшь три часа — и оказалось, что аналитикам нормально, им не нужна миллисекундная задержка. Николай считает вслух: миллиард строк и сто столбцов в паркете сжимаются впятеро, нужных столбцов пять из ста — остаётся около десяти гигабайт, которые по стогигабитной сети уезжают почти мгновенно. Отсюда картинка: S3 как хранилище, сверху ClickHouse, Trino и другие движки, таблицы забираются из Iceberg, слои раскладываются медальонной архитектурой. В ManyChat для аналитики везде Snowflake; в компаниях на Databricks у каждого домена свой Spark-кластер, и аналитикам не дают писать запросы самим — один креативный запрос съедает ресурсы всех. Будущее, по Николаю, за персональными расчётными модулями, а мир тем временем сделал два оборота: то же обещали Hadoop с Hive, только вместо HDFS теперь S3, а SQL вернулся на векторных движках.