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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

***

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