Всем привет. На связи Дмитрий Немчин из Т-Банка. Снова буду говорить про Greenplum, но в необычном контексте.
С 2015 года занимаюсь Greenplum: развитием, эксплуатацией, автоматизацией и всем, что обычно появляется вокруг большой аналитической платформы.
Когда я пришел, у нас было два production-кластера Greenplum и десятки терабайтов данных. Сейчас production-кластеров около 20 и объемы данных измеряются петабайтами. За это время Greenplum прошел путь от небольшого DWH до центра крупной Дата Платформы. И сейчас это система, которая все еще держит большую часть нагрузки, но постепенно перестает быть точкой будущих инвестиций.
Переход к такому состоянию системы часто воспринимается болезненно. Особенно если технология долго была центральной для команды и бизнеса. Но сам факт перехода в legacy не означает, что система была плохой или что работа команды обесценилась. Чаще наоборот: legacy становятся решения, которые долго работали, выдержали рост и успели стать частью критичной инфраструктуры.
В статье хочу разобрать переход на примере Greenplum: что я называю legacy, почему технология начала ограничивать следующий этап роста, какие варианты были у команды и что происходит с людьми, когда привычная система постепенно уходит из фокуса развития.
Что такое legacy
Под legacy я понимаю не мертвую систему и не то, что завтра нужно выключить (строго говоря legacy != EOL). В нашем случае Greenplum продолжает работать, на нем остаются критичные процессы, пользователи запускают запросы, а команда отвечает за доступность и производительность.
Legacy начинается тогда, когда технология остается важной для текущей работы, но перестает быть основным направлением развития. Ее продолжают поддерживать и развивать там, где это приносит практическую пользу, но новые крупные инвестиции постепенно уходят в другое направление.
Обычно технология переходит в состояние legacy после долгого периода успеха. Вокруг нее успевают вырасти процессы, инструменты, автоматизация, накапливается опыт и экспертные знания команды. Поэтому разговор о legacy часто получается эмоциональным: формально речь идет об архитектуре, а на практике — о многих годах инженерной работы.
Greenplum — великий и ужасный
Greenplum был хорошим выбором для своего времени. Мы искали MPP СУБД, которая могла обрабатывать большие объемы данных и выдерживать тяжелые аналитические запросы, и Greenplum был отличным ответом на наш запрос. По сравнению с предыдущими подходами, это был серьезный шаг вперед: появилась горизонтальная масштабируемость, больше возможностей для роста нашего DWH, нормальная база для ETL и аналитики.
Сначала архитектура выглядела прямолинейно. Были источники данных, загрузка и Greenplum как основной движок обработки, поверх него строились ELT-процессы, витрины, отчеты, пользовательская аналитика. В общем, «сюда данные заливаем, тут перемешиваем, отсюда забираем». По мере роста компании росли и данные, и число пользователей, и количество сценариев.
Потом кластеров стало больше. Появились сложные механизмы доставки данных между ними (с подписками и информацией об актуальности, все для людей). Появилась автоматизация, внутренние инструменты для мониторинга, эксплуатации, балансировки, работы с инцидентами. Greenplum перестал быть просто базой данных в центре DWH, а стал ядром большой платформенной экосистемы.
В этой точке важно не перепутать причину и следствие. Greenplum начал становиться legacy не потому, что плохо работал. Он долго работал хорошо и позволил платформе вырасти до текущего масштаба. Проблемы начались там, где изменился сам масштаб и характер нагрузки.
Почему Greenplum начал становиться ограничением
Сначала рост нагрузки выглядел привычно и предсказуемо: больше пользователей, больше отчетов, больше витрин, больше ETL, больше разовых аналитических запросов. В такой ситуации первая реакция понятна: добавить ресурсов, оптимизировать запросы, развести нагрузки, добавить кластер, улучшить мониторинг.
Некоторое время это работало: один кластер разгружался за счет другого. Часть процессов переехала, для популярных данных появились копии, пользователи распределились по группам. Команда улучшила доставку данных и автоматизацию. Но постепенно симптомы вернулись.
Главная проблема была в связанности. В одном контуре сходились разные типы нагрузки: регулярные ETL-процессы, BI-отчеты, пользовательские ad-hoc-запросы, витрины, тяжелые расчеты. Эти нагрузки отличаются по профилю и ожиданиям. ETL может быть тяжелым и долгим, BI ждет предсказуемого времени ответа, аналитик запускает нерегламентный запрос и не всегда заранее понимает его стоимость. Все это конкурировало за одни ресурсы.
Отдельная боль — большое число одновременных запросов. Greenplum хорошо подходит для тяжелой аналитической обработки, но при высокой конкуренции за ресурсы начинают расти очереди, увеличивается время ответа, пользователи чаще сталкиваются с ошибками и разрывами сессий. Один неудачный запрос может занять значимую долю ресурсов и повлиять на соседние сценарии.
У одного кластера есть практический предел роста. Теоретически можно добавлять узлы, но вместе с этим растет сложность эксплуатации: больше сегментов, больше сетевых и дисковых эффектов, сложнее обслуживание, выше цена инцидента, тяжелее обновления и восстановление. В какой-то момент большой кластер становится слишком крупной единицей отказа и слишком неудобной единицей масштабирования.
Мультикластерность помогла пройти следующий этап. Она позволила разводить пользователей и нагрузки, выделять отдельные контуры, снижать давление на конкретные инстансы. Но и у этого решения есть своя цена.
Если пользователи живут на разных кластерах, а данные нужны одним и тем же командам, объекты начинают дублироваться. Популярные таблицы и витрины приходится раскладывать по нескольким местам. В отдельных случаях число копий становится само по себе проблемой: дублировать данные до 20(!) раз не самое бюджетное решение. Растет объем хранения, усложняется обновление, труднее контролировать свежесть и консистентность.
Доставка данных между кластерами превращается в отдельный слой платформы. Нужно понимать, где объект создается, куда он должен приехать, кому он нужен, с какой свежестью, что будет при ошибке, какие зависимости сломаются, как это мониторить и кому разбирать инцидент. Чем больше кластеров, тем больше такой логики оказывается между пользователем и данными.
Появилась и экономическая проблема. Масштабирование крупными кластерами плохо совпадает с реальной формой нагрузки. Нагрузка растет неравномерно: где-то нужен мощный compute, где-то надо много хранить, где-то интерактивная аналитика. При этом расширение кластера или ввод нового — крупный инфраструктурный шаг. В результате часть ресурсов перегружена, часть используется не полностью, а дублирование данных увеличивает стоимость.
Отдельно проявился рост самих объектов данных. Некоторые таблицы становились настолько большими, что с трудом помещались в один GP-кластер без дополнительных компромиссов по хранению и скорости обработки данных.
В какой-то момент стало понятно, что мы уперлись не в отдельную настройку Greenplum и не в конкретный неудачный паттерн запросов. Ограничение оказалось в архитектурной модели: хранение, вычисления и пользовательская нагрузка слишком сильно связаны внутри MPP-кластеров. Для следующего этапа роста нужна была схема, где слои хранения данных и вычислений можно масштабировать независимо.
Технологический аспект
Когда технология начинает ограничивать рост, есть несколько вариантов.
Вкладываться в сам Greenplum. Оптимизировать эксплуатацию, писать новые инструменты, дорабатывать автоматизацию, участвовать в развитии open source, давить на вендора или искать другие способы продлить срок активного развития. Для команды, которая хорошо знает технологию, это понятный и комфортный путь. Он действительно может дать результат, особенно если ограничения лежат в конкретных местах.
Но в нашем случае проблема стала шире. Улучшения внутри Greenplum помогали бы поддерживать текущий контур, но не снимали связанность хранения и вычислений. Мы могли выиграть время, но не изменить принцип масштабирования, по крайней мере не вложив сотни человеко-часов в переписывание Greenplum изнутри.
Развивать мультикластерную модель. Этот путь тоже не выглядит странным: он уже работал, команда умела его эксплуатировать, вокруг него были инструменты и опыт. Можно было добавлять новые кластеры, улучшать доставку данных, лучше распределять пользователей, аккуратнее управлять копиями.
Ограничение здесь в том, что сложность росла вместе с решением. Каждый новый кластер помогал с нагрузкой, но добавлял больше маршрутизации, больше копий, больше зависимостей, больше эксплуатационных правил. Такая модель постепенно начинает требовать слишком много усилий на поддержание самой себя.
Менять архитектурный подход. Сместить фокус с MPP-кластера как центра платформы к модели, где есть общий слой хранения и разные вычислительные движки под разные сценарии. В такой схеме тяжелая обработка, интерактивные запросы и другие профили нагрузки не обязаны жить внутри одного и того же контура.
Именно этот путь мы выбрали как целевой. Не буду подробно разбирать новую архитектуру: это отдельная большая тема. Зафиксируем само направление перехода.
Новая архитектура платформы
Старая модель начала ограничивать нас из-за того, что вся платформа была завязана на Greenplum: ingest приходил в GP-кластеры, внутри них жили ETL и основные вычисления, оттуда данные расходились в notebooks, отчетность и другие сервисы. На таком устройстве в одном контуре оказываются хранение, вычисления и разные типы нагрузки. Пока масштаб умеренный, это работает. При росте платформы начинаются знакомые проблемы: конкуренция разных нагрузок (уже в рамках отдельных групп пользователей), предел масштабирования отдельных кластеров, дублирование данных между кластерами и сложная доставка объектов туда, где они нужны.
Рядом с Greenplum растет DLH (DataLakeHouse) — общий слой хранения и новые движки обработки, а Greenplum продолжает обслуживать существующую нагрузку.
Мы идем к тому, что DLH становится центральным звеном нашей платформы, забирая эту роль у Greenplum. Данные выносятся в общий слой хранения, а обработка распределяется между разными движками под разные профили нагрузки. Это позволяет отдельно масштабировать хранение, отдельно — вычисления, аккуратнее разводить ETL, интерактивные запросы и другие сценарии.
Подробно устройство DLH и саму миграцию разберем уже в другой статье.
Человеческий аспект
С технической стороны переход от технологии, ставшей legacy, к чему-то новому можно описать довольно сухо: есть ограничения текущей модели, целевая архитектура, план миграции. Но для команды это всегда сложнее, чем замена одного компонента другим.
Когда люди много лет работают с одной технологией, вокруг нее формируется профессиональная идентичность. Далеко ходить не надо: я себя ассоциировал с Greenplum много лет. Инженеры знают слабые места системы, типовые инциденты, поведение под нагрузкой, особенности пользователей, опасные запросы, внутренние инструменты. Все это не появляется быстро, а накапливается через эксплуатацию, аварии, оптимизации, спорные решения и долгую поддержку продакшена.
Поэтому переход технологии в legacy может восприниматься людьми как риск остаться за бортом. Если сказать только «теперь развиваем другое», часть команды услышит: прошлый опыт больше не нужен. Это опасная трактовка. На практике опыт Greenplum-команды остается ценным, потому что речь идет не только о знании конкретной базы. Речь идет об умении работать с большой платформой: нагрузкой, отказами, производительностью, пользователями, эксплуатацией и сложными зависимостями. И не в последнюю очередь — с тем, как устроено все это именно у нас в компании со всеми «так принято» и «исторически сложилось».
Главная управленческая задача в таком переходе — не потерять накопленные знания и опыт. Greenplum нельзя просто выключить: на нем остается критичная нагрузка. При этом нельзя делать вид, что ничего не меняется. Нужно честно разделить задачи.
Есть критическая поддержка: доступность, инциденты, безопасность, регуляторные требования, стабильность пользовательского сервиса. Это нельзя бросать, даже если технология постепенно уходит из фокуса развития.
Есть улучшения, которые снимают текущую боль: автоматизация ручных операций, доработка мониторинга, снижение числа типовых инцидентов, исправление узких мест, которые мешают пользователям прямо сейчас. Такие задачи все еще имеют смысл, потому что старый контур будет жить не месяцы, а годы.
А есть развитие, которое имело бы смысл только при долгом будущем технологии. Здесь фильтр становится жестче. Не каждую интересную идею стоит реализовывать, если стратегически нагрузка будет переезжать в другой контур.
Внезапный бонус: в число улучшений, снимающих боль, часто входят задачи, которые нужны, но руки до них вечно не доходят. А если убрать задачи на развитие — можно найти время на более вдумчивую работу со стабильностью и эти самые задачи наконец-то сделать.
Отдельно нужно готовить людей к новой платформе. Это не значит, что все должны одномоментно бросить Greenplum и стать экспертами по новому стеку. Лучше работает постепенный переход: новые инструменты, общие практики разработки, CI/CD, IaC, наблюдаемость, работа с другими compute-движками, участие в миграционных задачах.
В таких изменениях важно управлять не только стеком, но и ожиданиями. Команда должна понимать, какие задачи остаются в Greenplum, какие постепенно уходят, где будет применяться ее опыт и как меняется роль инженера. Иначе legacy-мышление может начаться раньше, чем сама технология реально станет legacy: люди перестают улучшать систему, которая еще держит бизнес-критичную нагрузку, — «оно никому уже не нужно, нас все равно завтра уволят».
Заключение
Greenplum не стал для нас плохой технологией. Он сделал свою работу: помог платформе вырасти, выдержал рост данных, пользователей и внутренних инструментов. Именно поэтому вокруг него возникла большая экосистема, которую теперь нельзя заменить быстро и безболезненно. Даже сейчас при некоторых условиях я бы вполне мог рекомендовать Greenplum (или его open-source-аналоги) к внедрению в компаниях.
Но успешная технология тоже может стать ограничением. На нашем масштабе старый подход начал упираться в concurrency, связанность хранения и вычислений, сложность мультикластерности, дублирование данных, стоимость доставки и цену отказа крупных кластеров.
Переход в legacy в такой ситуации — не приговор, а смена режима управления.
Greenplum остается частью нашей платформы и частью опыта команды. Его переход в legacy не отменяет того, что было сделано: именно эта технология позволила вырастить нашу платформу до текущего масштаба. Дальше меняется фокус, но не уходит ключевой вопрос — стабильность работы. Старый контур должен оставаться надежным, новая архитектура — постепенно забирать подходящие сценарии, а инженерный опыт и знания команды — переходить туда, где они будут нужнее всего.