«Своё, Родное!», Россельхозбанк
Привет, Хабр! Я Владимир, архитектор департамента больших данных в РСХБ. В команде РСХБ.Цифра руковожу проектом по внедрению решения для CDC-репликации данных на базе отечественного программного продукта Датафлот Репликация. Наступила эпоха импортозамещения, и в последние годы большинство компаний столкнулось с необходимостью отказаться от привычных классических инструментов и архитектурных решений. Для нас, Россельхозбанка, 100% которого принадлежат государству, по очевидным причинам проблема импортозамещения особенно актуальна.
Нашей целью было обеспечить бесшовное переключение систем с замещаемых СУБД, миграция их данных, замена cdc-инструментов поставки данных в ХД в рамках задачи импортозамещения иностранного ПО в банке.В этой статье расскажу про наш подход к этому вопросу с практической точки зрения. Про и контра — с точки зрения не маркетинговых фраз, а сугубо практического «вам шашечки или ехать?». Возможно, не все согласятся с приведёнными критериями и аргументами, что повлечёт холивары в комментах, но… тем лучше. Будет больше осознанности при выборе правильного решения.
Требования к системе: чего надо-то?
«Ты скажи, ты скажи, чо те надо, чо те надо…»
Хочется идеального решения. Раз — и всё импортозаместилось! И чтоб всё «Своё Родное». Исключительно из реестра Минцифры. Под отечественный Линукс и российские СУБД, с OpenJDK (а лучше Си), без чужих библиотек и с сертификатом ФСТЭК.
Обычно репликация рассматривается как чисто техническая функция DBA – создание резервной копии базы данных (БД), клона системы для получения тяжёлой отчётности без нагрузки БД источника, но…
…а что, если инструмент даст возможность реплицировать данные между разными СУБД? Обеспечить двухстороннюю репликацию? Да, полезно. Можно просто бэкап в другой СУБД держать.
А это уже МИГРАЦИЯ. Например, в рамках импортозамещения мы хотим перейти с Oracle на Postgres. Не вопрос! ��аботаем на Oracle и тестируем приложения на его Postgres-зеркале. Для этого надо в режиме близком к реальному времени передавать изменения и при этом минимально нагружать источник. Как? Следовательно нужна поддержка CDC.
А возможность отката перехода? А совместимость с ещё не мигрировавшими системами? Ок, перешли на Postgres, включили обратную репликацию и получаем зеркало в старой системе или возможность держать зеркальную реплику источника для получения отчётов не нагружая источник и/или сохраняя тип СУБД источника для BI.
Может потребоваться добавить вычисляемые и технические поля, замаскировать данные. Это уже как ELT будет работать.
Есть ещё идеи?
Много чего хочется. Например, чтобы при импортозамещении миграция данных с одной СУБД на другую происходила в несколько кликов мышкой. И происходила быстро – во много потоков!
И не требовалось бы привлекать разработчиков, которые будут месяцами на долгих совещаниях согласовывать технологию взаимодействия информационных систем и ТЗ, потом долго что-то кодить и отлаживать одним им понятное, развёртывать микросервисы, строить DAG`и или рисовать стрелочки в ETL-системах и передавать это на сопровождение. Тем более разработчик обычно в бизнесе не эксперт, и рядом с ним надо сажать аналитиков от бизнеса, чтобы объяснили, что и как кодить. Может, лучше дать аналитику или даже прожекту простой графический интерфейс, чтобы он сам выбрал, чего и откуда забирать? Выбрать базу-схему-таблицу-поля откуда/куда и по какому расписанию – по нечётным дням чётного месяца или несколько раз в секунду.
И ещё, чтобы нагрузка на источник при всём этом не возникала. Совсем не возникала, поскольку системы критичные, а железо сейчас дорогое и труднодоступное. Да, и в приёмник лучше не всё загружать, а только нужные типы операций или данные конкретного филиала. Желательно сразу в несколько приёмников. В один как события, а в другом – зеркало. И, разумеется, если GreenPlum, то хоть источник, хоть приёмник, не через мастера гонять, а напрямую.
Или вот – в классическое хранилище грузить. SCD1 с soft delete или как историю в SCD3 лучше? Но… хранилище уже не модно. В DataLakе на Hadoop в виде Avro или Parquet. Неее… Это уже тоже не модно! Сразу в Iceberg на S3!!! Но в крайнем случае можно и в Kafka бросить, а там кому надо, сам из топиков заберёт.
Если структура источника измениться, DDL должны скорректировать приёмник – тоже требование нужное…
Надёжность – работа через транзакции. Отказоустойчивость – DR,HA всякие.
А если баг или фича open-source продукта мешают решить проблему? Просить помощи на форумах, получая в ответ RTFM? Ждать, пока забугорное комьюнити в очередной ветке Git`a проголосует за нужный вариант кода? Править самим, расходясь с «ванилью?» Кстати, а «ваниль» есть в списках ПО от Минцифры, про ЗОКИИ ФСТЭК Апачи слыхали?
Что? Свои разработчики? А где вы видели разработчиков, которые готовы поддерживать своё решение годами? И что там у нас на рынке с текучкой кадров? Надоело, новое увлечение, в другой компании зарплата выше. А НИКОГО другого, кто знает потроха нашего единственного и уникального в своём роде решения («аналоговнет»), в мире нет. Всё комьюнити в одной тёплой серверной сидит или на удалёнке в тёплой стране на трёх работах что-то лабает под кофеёк.
Можно ещё подрядчиков нанять. Они точно не откажутся. «Повремёнка» обеспечит на долгие годы кормление и обучение за счёт подрядчика его «молодых специалистов», правда тут вопрос качества поддержки и способности допилить решение вызывает сомнения.
Нет уж! Предпочту полноценную техподдержку от вендора 24/7!
Деньги за готовый продукт/лицензию против своей команды? Содержание своей команды не бесплатное. Сроки разработки полноценного решения измеряются в тысячах человеко-дней и гарантии, что это решение будет ещё актуально к тому времени, когда оно появится, если появится (да, начать делать можно, памятуя про про ишака, Ходжу Насреддина и падишаха или анекдот про три конверта). Кстати, а чем потом занять команду? На поддержку решения перевести? Неее, хороший разработчик скорее уйдёт, чем будет годами тащить старый код. А вот «коробка» от компании, для которой этот продукт основа и смысл существования, это дело другое.
Итак, ждём и надеемся или прямо сейчас просим «коробку»?
Итак, будущее решение должно быть
в реестре Минцифры,
обеспечить миграцию между разными СУБД,
поддерживать захват данных без нагрузки на источник,
загружать данные в хранилище с поддержкой историчности,
коробочным для сокращения сроков внедрения,
отказоустойчивым и иметь полноценную техподдержку.
Требования ясны. Забегая вперёд скажу – наши хотелки сбылись.
А чего же хотят потребители?
Пользователи бывают разные – админы, ��азработчики, бизнес, но обычно все они консервативные.
Для админов продукт должен быть отказоустойчив, прост в развёртывании, совместим с инфраструктурой без плясок с бубном, с мониторингом работы для дежурных смен. Установка и настройка сервера приложений? Нет – давайте простое копирование приложения из tar.gz. Распаковать архив дистрибутива в каталог и запустить. Ничего стороннего доустанавливать не надо. Ну, разве что путь в профайле прописать.
Модное выражение – демократизация данных. Для прикладных пользователей – простой и понятный GUI, работа клиента под Linux и Windows(молчу, молчу), а лучше web-приложение. Быстро и просто, без риска навредить источнику выбрать откуда-куда, в каком режиме реплицировать данные доступные их роли. Не уговаривать разработчиков найти на это ресурсы (о, эти «мифические человеко-дни»).
На самом деле такой шаг предоставления self-service инструмента пользователям и является одной из практик демократизации данных:
Время предоставления данных снижается даже не многократно, а на порядки.
Пользователи могут экспериментировать и применять репликацию в своих гипотезах. Известно, что зачастую хранилище, озеро или Data Lakehouse проще наполнить заново, чем строить внутренние сложные трансформации, в особенности если объем извлекаемых данных расширяется.
Исчезает вся часто бюрократизированная цепочка запросов, согласований, рассмотрений процессов настройки пайплайнов
Огромный выигрыш – время и затраты сил на подготовку спецификации, требований к процессам перегрузки данных и саму разработку. НЕТ больше «интеграции». Банальная настройка зеркалирования схем или таблиц в произвольную БД (или не БД, а в стриминг, в In-memory база данных (IMDB)). Из схемы подготовки Data пайплайнов были исключены разработчики и другие коллеги из команды DataOps, неделями самоотверженно настраивающие и беспрерывно разрабатывающие все новые процессы интеграции.
Когда бизнес-пользователи и аналитики узнали о новых возможностях, которые даёт им новый стандарт репликации, мы получили такие отзывы: «Мы не могли и представить, что так может быть в реальности», «Так это я сам всё могу сделать за 20 минут, а не ждать 2 месяца пока …», «Невероятно!» и другие комплиментарные комментарии. Тут редкое единодушие с администраторами БД – «Огонь!», «Да где вы раньше с этим были, когда мы…».
Выбор есть, но он единственный
«Много в поле тропинок, только правда одна…»
Итак, с требованиями мы определились.
Пытаясь найти тропинку, ведущую нас к правде, пришлось много потоптаться по разным сайтам (ну, ладно, в основном, конечно, это был Хабр, но и по разным страничкам stackoverflow и другим ресурсам немало просерфлено), в обсуждениях с коллегами – вендорами, топами финтеха, телекома, нефтегазоурана принято немало кхм… кофе, разумеется!
В итоге особенного разнообразия вариантов решений не обнаружилось.
Для захвата данных из Postgres в основном используется слот репликации. И для штатных реплик Postgres для пресловутого Debezium, другие решения (перечислять не буду), и даже (!) Oracle GoldenGate for Postgres используют именно его. Для тех, кто в теме CDC, нет необходимости говорить про «переполнение слота» и рассказывать о его последствиях. Достаточно пару раз положить продуктив – и упоминание данного решения станет ругательным. А ещё слоты отъедают 10-20% утилизации процессора. Тем более Postgres требует больше «железа», чем Oracle. На восьмиядерном это можно компенсировать парой ядер, а когда ядер 400 и ещё 400 ядер в отказоустойчивом кластере, это надо уже пару сотен добавить?!
В отрасли встречаются решения на базе Oracle XStream. Но, во-первых, мы говорим про импортозамещение, а Oracle официально ушёл и является продуктом из недружественной державы. Его использование подразумевает наличие лицензии GoldenGate и, с юридической точки зрения как самого Oracle, так и, полагаю, нашего Минцифры, является крайне сомнительной идеей.
Есть достаточно производительные решения, позволяющие конвертировать данные из Oracle в Postgres или из Postgres в Kafka но, как вы помните, мы же мечтали про универсальность и CDC.
В итоге мы рассмотрели и пропилотировали разные варианты решений и сделали свой выбор – приняли ДатаФлот Репликацию как корпоративный стандарт Банка.
Бизнес-эффект
«Капитал боится отсутствия прибыли или слишком маленькой прибыли, как природа боится пустоты. Но раз имеется в наличии достаточная прибыль, капитал становится смелым. Обеспечьте 10 процентов, и капитал согласен на всякое применение; при 20 процентах он становится оживлённым, при 50 процентах — положительно готов сломать себе голову; при 100 процентах он попирает все человеческие законы; при 300 процентах нет такого преступления, на которое он не рискнул бы, хотя бы под страхом виселицы». Томас Джозеф Даннинг.
Ладно, уж, будем честны, мы работаем не только ради идеи. Работа увлекательна, но кушать тоже хочется. На новый проект средства выделят, только если он принесёт прибыль – и это будет очевидно спонсору. Фраза «Нам нужен кэш» может иметь совершенно разный смысл. Бизнесу не интересны протоколы, инструменты разработки и технические фичи.
Сформулируем, что даёт в реализация такого проекта в плане экономического эффекта:
Экономия на «железе».
Минимальные сроки реализации задачи — настройка получения данных в приёмник (а вариантов возможных sql/nosql приёмников много) занимает минуты.
Отсутствие расходов на содержание собственной команды разработки,
Независимость от консалтинга, поддерживающего перемаркированный опенсорс.
Технологический эффект:
Единый универсальный инструмент, позволяющий обеспечить передачу данных между различными комбинациями источников/приёмников.
Простота и доступность для использования не только разработчикам и DBA, но и сотрудникам из бизнес-департаментов как self service.
Отсутствие влияния и нагрузки на источник (работа с онлайн и архивными логами СУБД, что особенно актуально для PostgreSQL).
Источник и приёмник находятся в ведении одной и той же команды, но не профильных ЦК, а единых администраторов инфраструктуры. Сокращение издержек на получение прав доступа и работа с информацией доверенными лицами. При необходимости можно скрыть чувствительную информацию. Админы, которые и без того имеют все права, могут сделать простую обезличку данных при передаче конечному потребителю, установив правила преобразования чувствительного поля или фильтр, например, по типу операции на этапе передачи данных в приёмник.
И что в результате?
Получили и успешно внедрили универсальный отечественный инструмент из реестра Минцифры, имеющий широкую функциональность для миграции и репликации БД, наполнения ХД.
Многократно сократили время на получение данных бизнесом.
Минимизировали расходы и нагрузку на инфраструктуру (в особенности на источники данных Postgres).
Дали пользователям инструмент с понятным интерфейсом без необходимости скриптовых способов настройки и правок конфигураций в vim как единственного способа настройки функционально несложного продукта руками админов-гуру.
Получили возможность извлекать данные из логов СУБД без нагрузки на источник.
В следующих статьях продолжу рассказывать про внедрение CDC-решения Dataflot. I'll be back.