Создали озеро данных для одной из самых больших в мире гидрогенерирующих компаний за 7,5 месяцев командой из 11 человек

Мы в SATORI успешно спроектировали и внедрили озеро данных в компанию РусГидро Ит Сервис (РГИТС) в рамках развития единой информационной платформы (ЕИП). Какие решения не сработали, как мы перестроились и почему это крутой кейс как для нас, так и для рынка data-решений в России.

Привет! Я основатель IT-компании Satori. Мы работаем в двух направлениях:

• создаем, развиваем и поддерживаем сложные проекты компаний как IT-компания полного цикла;
• предоставляем компаниям систему DLH, которая автоматизирует весь жизненный цикл управления данными: сбор, обработку, хранение и использование.

О внедрении озера данных и развитии ЕИП задумываются компании, в которых много ИТ-систем в ландшафте. В таком случае часто приходится строить управленческие отчеты по всем филиалам и разбираться, например, в том, какие данные «гуляют» между системами. С помощью ЕИП можно получить ответы в виде понятного графа.

В кейсе покажу, как мы настроили ЕИП — подробно, с техническими деталями. Узнаете, какие решения оказались неудачными, и что помогло нам быстро перестроиться.

Весной 2023 года мы победили на площадке «Росэлторг» в открытом конкурсе и заключили контракт по созданию ЕИП с «РГИТС». Вот какие проблемы мы должны были решить в рамках проекта:

❌ Нет правильно выстроенного единого хранилища данных. А значит, нужно собирать данные из разных источников. На это уходит куча времени, и могут быть ошибки.

Когда есть единое хранилище, то можно сразу создавать на его основе отчеты и отслеживать, чтобы данные в разных системах не противоречили друг другу.

За время работы в «РГИТС» накопилось 80 миллионов записей холодных исторических данных, и в них не было порядка.

❌ Нет понимания атрибутивного состава сообщений, передаваемых между системами. У каждого сообщения, которое «гуляет» между системами, есть определенный набор данных: сами данные и их атрибуты. Без атрибутивного состава не понятно, какие параметры данных каким системам нужны, и почему.

Понимание того, какие данные «гуляют» между системами, позволяет:

• не дублировать информацию;
• понимать, каких данных может не хватать слету;
• понимать, где в общем большом ИТ-ландшафте есть узкие места или, наоборот, все сделано оптимально.

Аналитики «РГИТС» не знали весь атрибутивный состав, который мог передаваться по потоку в сообщениях формата XML и JSON. Даже если он где-то фиксировался, то единого каталога метаданных с бизнесовым описанием не было. Когда в каталоге есть метаданные, то по ним проще искать информацию. Например, добавить метатег «пользователь» и собирать данные о всех пользователях из разных систем.

❌ Строят отчеты и визуализацию данных вручную. Аналитики компании раз в месяц сами строили отчет и визуализацию данных, хранящихся в PostgreSQL. Хотели автоматизировать сбор данных и мониторить потоки в реальном времени в виде графа.

❌ Негибкая ЕИП. Старая ЕИП не позволяет удалять системы или добавлять их в нее — требуется разработка. Новую ЕИП можно настроить так, чтобы системы добавлялись и обменивались между собой данными автоматически.

В РГИТС скептически относились к нашей команде — боялись, что мы не справимся со сложной задачей. Тем более, у заказчика нет компетенций полностью согласовать техническое решение.

Сделать решение на Open Source компонентах. В «РГИТС» хотели, чтобы система попала в реестр отечественного ПО и не зависела от платных вендорских решений. Поэтому концепция использования свободно распространяемого ПО была единственно верным решением. Еще было важно, чтобы используемое ПО не было запрещено Минцифрой, а версии каждого компонента, в идеале, были до 24 февраля 2022 года.

Создать надежную и отказоустойчивую систему:

• доступность для пользователей которых выше 99% процентов от времени его работы,
• в которых есть резервируемые компоненты,
• на которые не влияет отключение сети и другие форс-мажоры.

Попробовать Hadoop-стек. Наш проект был пилотным — в «РГИТС» хотели проверить гипотезу и убедиться, что бизнес будет пользоваться ЕИП и потратит деньги не зря. В перспективе в компании хотели не просто сделать пилот, но еще в рамках него протестировать разные технологии BigData. В том числе самую распространенную.

Получить возможность поддерживать решение после внедрения своими силами. У заказчика и так были компетенции, чтобы самому поддерживать систему, а еще самостоятельная поддержка не требует дополнительных затрат на вендора — это помогает экономить бюджет.

У нас была Kafka, 80 млн исторических данных в одной таблице в PostgreSQL, Apache Nifi, Clickhouse, Apache HDFS, Hive, Spark, Superset и OpenMetaData. Не то чтобы это был необходимый запас для построения озера данных, но раз уж начал использовать apache, то сложно остановиться.

Предупреждаю: дальше много технических деталей, без которых не описать работу по проекту. Если вы здесь не за ними — листайте сразу до выводов и результатов.

Lambda-архитектура позволяет распределять данные по разным слоям в зависимости от частоты их использованиям и требованиями к отклику после запроса.

• Например, исторические данные требуются раз в год — их можно положить на «холодный» слой. Для них мы определили хранилище Stage0. Данные из Kafka попадают в HDFS и хранятся просто как файлики.
• Данные, которые нужны раз в неделю — в «теплый слой». Для них мы выделили хранилище Stage1. В нем происходит потоковая обработка данных: данные из Kafka разделяются на атрибуты и Payload и сохраняются в Apache Hive для последующей обработки. В этом же слое можно извлекать метаданные из Payload и структурировать их с помощью OpenMetaData.
• А данные, которые нужны каждый день, и к которым обращаются по 100 раз в день — переложить в «горячий» слой, Stage2. Здесь определяются идентификаторы потоков данных и строятся количественные агрегаты по этим потокам — это нужно для визуализации и построения отчетов.
  

Дополнительно к слоям добавили:

• справочники;
• извлечение метаданных и их сохранение в OpenMetaData;
• разовую обработку исторических данных из PostgreSQL.

Для Hadoop потребовалось больше аппаратных ресурсов и оперативной памяти, чем мы закладывали. В ходе обсуждения решили, что не хотим разворачивать, использовать и поддерживать гигантский Hadoop-кластер.

Вместо Hadoop решили использовать Clickhouse так:

Использовать два кликхауса, которые реплицируют данные между собой.

Отказаться от Stage0 в первоначальном виде. Вместо него использовать Clickhouse TTL с подключенными внешними томами. Тут пригождается уже развернутый HDFS:

• Таблица содержит все данные. Актуальные данные хранятся на томах самого Clickhouse.
• Исторические данные отправляются в HDFS.
• Дополнительно Clickhouse кеширует горячие исторические данные.
• Stage1 по-прежнему обрабатывает потоковые данные из Kafka.
• Stage2 по-прежнему строит агрегаты.

То есть, от Apache Hive пришлось полностью отказаться.

Если строишь систему на OpenSource-компонентах, будут баги. Придется обновляться, а иногда самим патчить и бэкпортить исправления к себе.

Nifi — мощная и гибкая ETL-система, которую мы будем применять в других проектах. Nifi — это программный API для разработки кастомных процессоров по обработке данных. Мы в проекте с его помощью извлекали метаданные из тел сообщений.

Ckickhouse — мощная, быстрая и очень гибкая СУБД. Точно будем применять в проектах и ее тоже.

С OpenMetaData не все бывает гладко. Эта история тянет на отдельную статью — напишем, если эта соберет больше 30 тысяч просмотров.

По ходу проекта можно менять целевую архитектуру. Мы благодарны заказчику, что он поддержал эту идею.

✅ Выстроили единое хранилище данных. Благодаря этому:

• Заказчик быстрее собирает отчеты.
• Повышается реакция на важные изменения в бизнес-процессах (например, финансовые показатели).
• Повышается управляемость.
• Снижаются затраты на развитие IT-ландшафта.

✅ Создали единый каталог метаданных — так называемый дата-каталог.

✅ Настроили автоматическую отчетность и визуализацию данных. Теперь заказчик еще и видит качество данных, благодаря визуализации агрегатов по данным, которая показывает ошибки в исходных сообщениях.

✅ Выстроили гибкую ЕИП. В ней:

• Высокая скорость обработки поступающих из шины сообщений — 8000 сообщений в минуту.
• Высокая отказоустойчивость — при недоступности одного из узлов ClickHouse, запись происходит на другом узле. При восстановлении узла, данные автоматически реплицируются с работоспособного узла на восстановленный. При недоступности всех узлов Clickhouse и Nifi-pipeline, обработка данных приостанавливается без потери сообщений. При появлении хотя бы одного доступного узла Clickhouse, работа Nifi-pipeline автоматически продолжается.

А главное — от скепсиса РГИТС к концу проекта ничего не осталось. Заказчики довольны, и будут дальше использовать пилот.

РГИТС планирует на основе озера данных строить управленческую отчетность для единых центров обслуживания (аналог бэк-офиса для крупных компаний). В компании много филиалов, и у каждого 1С, CRM, ERP — все как мы любим.

***

Описать задачу на создание озера данных или узнать больше о ЕИП можно у меня в Телеграме.