Платформа данных: сменить самолёт в полёте

Сергей представляется коротко: он отвечает за всё техническое развитие централизованной платформы данных банка. Дальше разговор уходит в начало: родился под Харьковом, вырос в Гатчине, десятый и одиннадцатый классы закончил в кадетском корпусе пограничной службы, но в военную стезю не пошёл и поступил на программирование в питерский электротехнический вуз. Отец звал в хирурги, а Сергей решил, что там слишком большая ответственность, и выбрал профессию, где результат труда виден невооружённым глазом. Стажёром он вышел на работу примерно в 2006 году: брали на C++, но вакансия закрылась, и директор отправил его писать на .NET. В этой компании он проработал восемь лет — сначала отвечал за систему репортинга, потом попал в команду оптимизации приложения, где узкое место чаще всего оказывалось в слое работы с данными. База в 800 000 таблиц и около двух терабайт казалась тогда ультрабольшой. Из стажёра он дорос до тимлида команды в семь-восемь человек.

В Одноклассники он пришёл за объёмом: хотелось посмотреть, как живёт сервис, где логируется каждый клик, логин и просмотр видео. Задача была отказаться от двух с лишним сотен серверов MS SQL, на которых считалась вся статистика с отставанием в пять минут: Microsoft запросил слишком много денег, а отдельные таблицы уже не принимал даже сервер с самым свежим железом. Команда называлась DWH, человек десять мультистаночников: дежурства, закупка железа, ETL-фреймворк, дашборды, код на Java и .NET. Через пару лет людей с такой шириной знаний перестало хватать, и команду разделили на три — инфраструктурную, которая и стала называться платформой данных, DWH и аналитиков. Сергей возглавил платформу: больше ста петабайт в HDFS в семи дата-центрах, петабайтные Kafka и ClickHouse, и всё это держали до восьми человек. Каждый подолгу вёл своё направление, дежурили все за всё, учения по отказу дата-центра были нормой, а на красивый интерфейс времени не оставалось.

Хранилище было ближе всего к даталейку: метаданных почти не строили, Hive-метастором не пользовались, логи по дням превращались в агрегаты, а сложные слои вроде Data Vault и якорных моделей на таких объёмах позволить себе не могли. Граф считал около двух тысяч расчётов в сутки, ежедневно крутилось за сотню экспериментов и сотни метрик. Интерфейсом A/B-платформы была Jira: заводишь таску, описываешь сплит и методологию, жмёшь кнопку, а отчёт прилетает комментарием в ту же таску; детали смотрели в Grafana. Сергей формулирует тезис: если компания сильно упарывается в эксперименты, её бизнес, скорее всего, растёт не так резко — когда всё зелёное, это было бы видно и на графиках. Интересное начинается, когда половина метрик красная и кто-то должен признать размен приемлемым: лояльность против денег в моменте. Отдельная история — красная ссылка на распродажу подарков: если цвет не менять, она становится белым шумом, если менять часто — рекламой, а редкая резкая смена жёстко бустит выручку.

Скачка в Одноклассниках не произошло — росли объёмы, парк железа и качество, а новых концепций не появлялось. Дальше Сергея назначили директором и отдали ему не только платформу Одноклассников, но и платформу ВКонтакте с центральным дата-офисом. ВК он описывает как сильно федерализованную структуру, где бизнесы почти не пересекаются и не хотят знать друг о друге, а данным это мешает. Про назначение говорит без романтики: позиции открылись, кто-то уехал, что-то разваливалось, а его платформа работала. Работа оказалась прежде всего тушением пожаров — команда в Одноклассниках сменилась полностью, и её нужно было заместить. Ушёл он, когда сменился прямой руководитель и решения стали приходить сверху, без его технической экспертизы; полтора месяца собирал офферы и выбрал T-Bank. Адопшен он сравнивает так: данных в Одноклассниках было больше, но инструментами пользовались триста-четыреста человек, а в банке счёт идёт на 15 000 и 12 000 пользователей двух систем.

Масштаб платформы банка Сергей описывает цифрами: около 230 разработчиков, порядка 152 петабайт в разных стораджах и примерно 100 000 ядер компьюта. Подкупила его централизованность — после ВК это казалось кайфом — и понятный предстоящий чейндж: архитектура стояла на Greenplum, и команда уже знала, что дальше не масштабируется. Устройство он объясняет так: классическая MPP, равные хосты, на каждом сегменты, сегмент — по сути один PostgreSQL; запрос через мастер разлетается сразу на все сегменты, поэтому идёт со скоростью самого медленного узла, а данные приходится разливать максимально ровно. Чем больше хостов, тем выше вероятность отказа: потолок — 72 крупные ноды, плюс ограничение примерно в сотню параллельных сессий, поэтому кластеры почковали, и сейчас их около десяти, от 30 до 72 нод, с шиной данных и резервом. Александр переводит это на язык архитектуры: бласт-радиус растягивается на весь кластер, а резерв — наследие корпоративного мира, потому что под той же нагрузкой он ложится следом.

Новая платформа разводит компьют и сторедж: данные в S3 от внутренних коллег, Spark и Trino как движки в кубах смежной команды, паркет с Iceberg поверх, чтобы пользователи по-прежнему работали с табличками. Сергей сравнивает это с самолётом: старый летит, все бизнес-процессы работают, а рядом строится новый, куда людей нужно перевести так, чтобы никто не упал на землю. Сложнее всего не построить, а перевезти 20 000 источников и тысячи регламентных процессов, не сломав отчётность. Аналитики с разовыми запросами почти не замечают перехода — правят синтаксис и спрашивают, почему новое медленнее; ответ в том, что новое масштабируемее и предсказуемее. Второй чейндж — датаконтракты на все поставки, идущие второй год: поставщик сначала меняет контракт, потом данные. Дата-инженеров за прошлый год раздали по доменам, а железо пока осталось на платформе, хотя честная платформа, по словам Сергея, должна отдавать кубики как внутреннее облако.