Введение: Инновационный путь, объединяющий озера данных и хранилища
В эпоху цифровых финансов данные стали ключевой компетенцией финансовых учреждений. Bank of Hangzhou Consumer Finance, являясь лицензированной организацией потребительского финансирования, всегда сохраняла сильный дух технологических инноваций, занимая второе место в отрасли по количеству патентов. Столкнувшись с вызовами, связанными с быстрым ростом бизнеса, компания начала трансформацию своей инфраструктуры данных, кульминацией которой стало создание платформы GLH Lakehouse на базе Mirrorship.
Платформа GLH представляет собой результат исследований и практического внедрения архитектуры Lakehouse, служа критически важным мостом, соединяющим бизнес-операции с передовыми технологиями.
I. Предпосылки создания платформы GLH: Инновации, продиктованные «болевыми точками» в данных
Требования бизнес-сценариев
Как организация, чья деятельность основана на «данных, сценариях, управлении рисками и технологиях», компания столкнулась с тем, что ее традиционная архитектура обработки данных больше не могла справляться с растущими потребностями. Эти потребности влияли не только на повседневные операции, но и напрямую на стратегические решения и соблюдение нормативных требований.
Актуальность данных для стратегий: Стратегии управления финансовыми рисками требуют своевременных данных для принятия решений. Задержка даже в несколько минут может привести к сбою в контроле рисков.
Консистентность данных между таблицами: Синхронизация данных между различными базами и таблицами должна поддерживать консистентность на определенный момент времени. Любое расхождение могло нарушить бизнес-логику.
Точность бизнес-данных: Ежедневные отчеты для руководства должны быть точными и своевременными, так как они напрямую влияют на стратегическое направление компании.
Потребности в сверке данных: Внутридневные данные необходимы для процессов сверки, и традиционные ETL-процессы не могли обеспечить требуемую оперативность.
Соблюдение нормативных требований: Данные, предоставляемые регуляторам, должны соответствовать строгим стандартам своевременности и точности.
Анализ ключевых «болевых точек»
При использовании традиционной архитектуры данных компания столкнулась с несколькими критическими проблемами:
Проблема 1: Сложность отслеживания данных (Data Traceability)
Аномалии при передаче данных могли приводить к их потере. Если проблемы не обнаруживались вовремя, стоимость восстановления и отслеживания истории данных была непомерно высокой.
Проблема 2: Отсутствие детализированных записей об изменениях
Для регуляторной отчетности требовалось сообщать о каждом изменении информации о клиенте в течение дня. Однако производственная система сохраняла только конечное состояние на конец дня, не фиксируя промежуточные изменения и не удовлетворяя требованиям полной отчетности.
Проблема 3: Неточность данных на определенный момент времени (Point-in-Time Data)
Из-за ограничений ресурсов задания по извлечению данных могли выполняться с задержкой или не выполняться вовсе, что приводило к временным лагам в синхронизации. Это вызывало несоответствие статусов одних и тех же бизнес-сущностей в разных таблицах, порождая хаос в бизнес-логике.
Проблема 4: Проблемы с ежедневным закрытием операционного дня (Daily Cut-off) между системами
В сценариях сверки транзакций по погашению платежей разные системы (например, транзакционная и бухгалтерская) обрабатывали одну и ту же операцию в разное время. Это приводило к серьезным неточностям в данных на момент закрытия дня, что напрямую влияло на сверку.
Эти «болевые точки» были не просто техническими трудностями; они создавали прямую угрозу для развития бизнеса. Невозможность синхронизировать данные в реальном времени снижала эффективность бизнес-стратегий, несогласованность данных затрудняла сверку, низкое качество данных создавало риски для комплаенса, а сложность отслеживания делала аудиты долгими и дорогостоящими.
II. Построение архитектуры Lakehouse с помощью Mirrorship
1.Техническая архитектура платформы GLH
Платформа GLH была спроектирована с использованием четырехуровневой архитектуры:
Уровень приложений (Application Layer): Включает узел управления (Manager Node), узлы выполнения (Execute Nodes), кастомные плагины и узел оповещений (Alerting Node).
Уровень технических компонентов (Technical Component Layer): Использует экосистему Spring Framework, MyBatis, собственный RPC-фреймворк, Log4j и др.
Уровень промежуточного ПО (Middleware Layer): Задействует ZooKeeper, Kafka и MySQL.
Уровень эксплуатации (DevOps Layer): Основан на Git, Jenkins, Docker & Kubernetes и Maven.
Эта архитектура не только отвечала функциональным требованиям, но и обеспечивала стабильность, масштабируемость и удобство сопровождения системы, заложив прочный фундамент для платформы Lakehouse.
2. Почему для замены GreenPlum была выбрана Mirrorship?
Выбор хранилища данных был критически важным решением. После всесторонней оценки и тестирования команда выбрала Mirrorship (корпоративную версию StarRocks) в качестве основного движка для хранения и аналитики. Решение было продиктовано насущными проблемами — производительность существующего 26-узлового кластера GreenPlum снижалась по мере роста объема бизнеса, а расширение требовало значительных инвестиций.
Снижение затрат и повышение эффективности: Лицензионные платежи и стоимость горизонтального масштабирования GreenPlum были высокими. Mirrorship предложила более экономически эффективное решение, соответствующее стратегической цели компании.
Возможности ingest-а данных в реальном времени: В отличие от традиционных инструментов, таких как Hive, Mirrorship поддерживает real-time ingest и транзакционные запросы, что дает ей естественное преимущество в сценариях с данными реального времени.
Единая платформа данных: Данные были разбросаны по разным системам, создавая «острова данных». Mirrorship предоставила единую платформу для хранения и вычислений, консолидировав данные и упростив доступ к ним.
Дизайн архитектуры Lakehouse на базе Mirrorship
В новой архитектуре платформа GLH глубоко интегрирована с Mirrorship для создания истинной Lakehouse.
Архитектура с разделением хранения и вычислений (Shared-Storage): В качестве базового хранилища используется HDFS (с планами миграции на S3), что обеспечивает гибкость для управления ростом данных при контроле затрат и сохранении производительности.
Использование нескольких моделей таблиц: Используя возможности Mirrorship для работы с детализированными (Detail tables) и широкими таблицами (Wide tables), команда разработала кастомные структуры таблиц, поддерживающие анализ временных рядов и отслеживание данных для различных бизнес-задач.
Унифицированная обработка данных: Придерживаясь принципа «сбор один раз, обработка многократно», все данные управляются через единый конвейер обработки. Это позволило избежать дублирования разработки, значительно повысив эффективность и консистентность данных.
Гибкое распределение данных: Платформа поддерживает распределение данных в другие системы через Kafka, что обеспечивает работу сценариев, таких как Flink CDC, и создает открытую, гибкую экосистему данных.
III. Значительные результаты: Баланс между производительностью и экономической эффективностью
В ходе внедрения команда накопила ценный опыт:
Оптимизация времени пакетной обработки: Команда применила дифференцированную стратегию синхронизации данных, настраивая интервалы в зависимости от бизнес-потребностей — от 5 секунд для одних таблиц до нескольких минут для других.
Оптимизация партиционирования и бакетирования: Анализ бизнес-характеристик позволил переработать стратегию партиционирования, чтобы уменьшить накладные расходы на уплотнение (compaction) мелких файлов, что привело к значительному повышению производительности.
Рациональное распределение ресурсов: Было оптимизировано соотношение ресурсов между вычислительными узлами и узлами хранения. Мониторинг показал, что кластер стабильно работает с загрузкой ЦП ниже 50%, легко справляясь с пиковыми нагрузками.
Значимые бизнес-результаты
Платформа GLH достигла впечатляющих результатов:
Полный охват данных: Более 3800 таблиц из всех бизнес-систем компании подключены к real-time потоку данных.
Синхронизация на минутном уровне: Время от генерации данных до их доступности сократилось до минут, что многократно повысило скорость реакции бизнеса по сравнению с традиционной моделью T+1.
Увеличение мощности пакетной обработки: Платформа обрабатывает более 6500 заданий в день, включая более 800 задач для хранилища данных, со значительным ростом эффективности.
Углубление интеграции с бизнесом: Было снято ограничение на выполнение только пакетных запросов благодаря открытию real-time query API, что позволило бизнес-системам напрямую получать доступ к актуальным данным.
Эти достижения — не просто цифры; они трансформировались в ускорение реакции бизнеса и улучшение клиентского опыта, внеся ощутимый вклад в повышение основной конкурентоспособности компании.
IV. Перспективы развития
Платформа GLH завершила разработку основного функционала. Будущее развитие будет сосредоточено на следующем:
Более открытые интерфейсы: Поддержка интеграции с более широким спектром вычислительных и движков хранения.
Богатая экосистема плагинов: Разработка большего количества плагинов для обработки данных.
Более глубокая интеграция с бизнес-процессами: Дальнейшая интеграция с бизнес-системами для предоставления более точных данных.
Постоянное технологическое развитие: Отслеживание развития технологий хранения с запланированной миграцией на объектное хранилище S3.
Заключение
Платформа GLH Lakehouse, построенная на базе Mirrorship, не только решила критические проблемы Bank of Hangzhou Consumer Finance в области управления данными, но и заложила прочный фундамент для цифровой трансформации компании. Создав архитектуру Lakehouse, компания успешно интегрировала свои данные, раскрыла их ценность и обеспечила мощную поддержку для бизнес-инноваций.
