Привет, Хабр! Меня зовут Андрей Боков, я главный архитектор отдела разработки хранилищ данных в «Газпром ЦПС». Если вы хоть раз сталкивались с тем, что информация о сотрудниках не соответствует в различных корпоративных системах, например, 1С, электронный документооборот, корпоративный портал, система управления проектами, – вы понимаете, о чем сейчас пойдет речь. Мы пробовали решить эту проблему точечными интеграциями, но с ростом числа систем увеличивался и хаос в данных. Нам был нужен единый к��нтур, который позволит проследить путь данных от источников до отчета.
Так началась работа над корпоративным хранилищем данных (КХД). Мы выбрали многослойную архитектуру и методологию Data Vault 2.0 – подход, который сохраняет историю изменений и дает возможность подключать новые источники без перепроектирования структур хранилища. В статье я расскажу про наш опыт, который будет полезен специалистам по работе с данными: руководителям, архитекторам, аналитикам и инженерам. Подробно опишу, как мы строили ядро КХД и какие уроки и инсайты вынесли по результатам реализации.
Определение масштабов
Мы для себя обозначили следующее:
Данные – это «жизненная сила» организации, требующая свободного движения для поддержания производственных процессов. Наша главная трудность состояла в том, что эта «жизненная сила» была рассеяна по множеству «сосудов», как правило, изолированных и невзаимосвязанных друг с другом.
В нашей компании у каждого отдела свои источники данных. Для управления по работе с персоналом ключевым поставщиком данных является конфигурация «1С:Зарплата и управление персоналом» и файлы в формате электронных таблиц, для проектного офиса – информационная система управления проектами «Тиметта», а для финансово-экономической службы и бухгалтерии основными инструментами являются «1С:Управление холдингом», а также система электронного документооборота «Tessa».
На практике это привело к очень трудоемким и «ошибкозависимым» процессам. Специалист управления по работе с персоналом вручную вносил в 1С данные о сотруднике, после чего начинался, опять же, ручной процесс оповещения владельцев смежных систем, чтобы они внесли или актуализировали соответствующие данные в корпоративных системах.
Зачастую данная коммуникация и информационный обмен велись средствами электронной почты, а также путем подачи обращений в службу технической поддержки, поэтому информация обновлялась с опозданием.
И вот с чем мы столкнулись:
недостаточный для поддержания качественных производственных процессов уровень синхронизации и обмена сведениями (например, в 1С информация о сотруднике внесена, а в «Тиметте» информация отсутствует);
недостоверность сведений и ошибки (например, при ручном вводе/переносе сведений есть риск опечаток, которые тянутся из системы в систему).
Если в обмене данными участвует небольшое количество корпоративных систем, то их можно контролировать с минимальными затратами, применяя интеграции «точка-точка». По мере увеличения участников обмена и повышения объема передаваемой информации поддерживать бессистемные процессы становилось слишком дорого и неэффективно.
Нам нужен «единый источник правды»
Когда мы говорим и/или упоминаем «хранилища данных», то подразумеваем ценность их применения для BI и аналитики, но при этом ключевая задача и польза КХД заключается в способности превращать «сырые» данные в ценную информацию, которая становится фундаментом для принятия обоснованных бизнес-решений.
«Например, дашборд по ресурсной модели наглядно демонстрирует уровень загруженности персонала в проектах. Хотя ана��итические инструменты и визуализация являются значимыми, они не были первичным драйвером реализации КХД. Главная ценность заключалась в создании надежной основы для трансформации данных в части доступности, достоверности и своевременности».
Итак, с ростом количества данных и систем нам потребовалось наладить информационный обмен. Мы хотели, чтобы КХД стало той самой единой точкой входа, обмена, контроля и обработки данных, которая позволит соблюдать требования достоверности и консистентности.
В нашем представлении новая модель должна работать следующим образом: специалист управления по работе с персоналом вносит изменения в 1С, новые данные поступают в хранилище, и далее обмен с другими корпоративными системами осуществляется автоматически, с минимальным процентом ручных процедур.
Только решив задачу автоматизации сквозных процессов и добившись достоверности данных, мы могли перейти ко второй ступени, где есть возможность строить на этих достоверных и полных данных гибкую аналитику. Нам нужна была надежная основа, которая сможет выдержать и интеграционный обмен данными, и сложные запросы в BI.
Архитектура данных: как мы выбирали методологию
Итак, для системы нужен был фундамент. При проектировании ядра хранилища мы сравнили несколько классических подходов в поиске оптимального для задач компании:
Первый вариант – спроектировать «плоские таблицы» или витрины, т.е. пойти по простому, «кимбалловскому», пути. Если у вас небольшой объем данных и пара простых отчетов – это вполне рабочий вариант. Однако нас такой вариант не устраивал, так как не решал проблемы интеграций и масштабирования.
Второй вариант – «звезды» и «снежинки». Это классические схемы для BI, где есть таблицы фактов и справочники (измерения). Они отлично подходят для презентационного слоя (Data Marts), то есть для витрин, которые отдают данные конечному потребителю. Мы их активно используем, но для ядра хранилища (DDS) эта модель была недостаточно гибкой.
Третий вариант – классическая нормализованная модель (3NF). Это очень популярный подход для построения ядра, который в нашей компании применяется при реализации проектов для ряда заказчиков.
Четвертый вариант – Data Vault 2.0, который мы и выбрали, т.к. требовалась именно модульная структура. В такой большой компании, как наша, регулярно появляются новые источники и потребители, для которых требуется организовать наборы данных без необходимости проектирования модели данных «с нуля», что и определило наш выбор в пользу Data Vault 2.0.
«Data Vault 2.0 – это не просто модель данных, это философия построения хранилища, ориентированная на гибкость и адаптивность. Для организаций, которые работают с постоянно меняющимися источниками данных и нуждаются в прочной основе для управления данными (Data Governance / Data Management), Data Vault 2.0 становится выбором номер один. Он позволяет отделить «историчность» данных от их «бизнес-ключей» и «связей», что упрощает управление изменениями и повышает прозрачность»
Сергей Новиков, главный архитектор «Газпром ЦПС»
Data Vault 2.0 состоит из трех основных типов сущностей: хабы, ссылки и сателлиты, которые формируют комплексную модульную структуру. При появлении новой системы-источника не требуется полного перепроектирования структуры хранения, достаточно расширить состав элементов. В этом случае мы просто можем добавить новые сущности рядом, расширяя хранилище и сохраняя всю историю изменений.
Архитектура КХД и реализация решения
Выбрав методологию, мы реализовали решение в виде многослойной архитектуры данных, которая состоит из трех основных слоев:
Слой сырых данных (RAW). Это первая точка входа, своего рода «карантинная зона». Данные из систем-источников попадают сюда «как есть», без изменений.
Слой детализированных данных (DDS, Detail Data Store). Ядро хранилища, где данные после очистки связываются и хранятся в детальном виде. Именно этот слой построен нами по методологии Data Vault 2.0.
Презентационный слой (DM). Это витрины, которые мы проектируем для потребителей. Здесь формируются те самые «звезды» и «созвездия». Данные объединены и готовы для использования в BI-отчетах, а также для передачи в смежные корпоративные системы.
Определив методологию и подход, мы собрали соответствующий стек для реализации.
Источники и потребители
Наш основной источник – это 1С: «Зарплата и управление персоналом» и «Управление холдингом». Интеграция с ними реализована по «привычной» схеме через встроенный в 1С механизм «Внешний источник данных», который использует принципы всем знакомого ODBC (Open Database Connectivity). Интеграция с системами «Tessa» и «Тиметта» требует отдельного подхода, т.к. у каждой – свой API, обращения к которым осуществляется через HTTPS. Обращения выполняют python-скрипты, реализуя трансформацию табличного формата данных в формат JSON и обратно.
Моделирование
Для проектирования моделей данных мы применяем pgModeler – инструмент, который позволяет визуально «рисовать» модели данных, а потом автоматически генерировать нужные структуры. Поскольку это ПО с открытым кодом, есть возможность осуществлять его доработку, например, настраивать бесшовную интеграцию с системой управления версиями.
«При обеспечении надежности хранилища данных выбор проверенных
технологий является стратегическим решением, гарантирующим стабильность и
предсказуемость».Сергей Новиков, главный архитектор «Газпром ЦПС»
Однако, когда мы собрали вышеописанные инструменты в единое КХД, то почти сразу столкнулись с «нюансами».
Главные инсайты (те самые «нюансы»)
Дьявол, как обычно, кроется в деталях, и в процессе реализации КХД нам пришлось не раз в этом убедиться. За время работы мы с командой сформулировали для себя несколько ключевых правил, которые сильно упростили рабочие процессы:
Инсайт 1. Качество данных – это процесс, а не итоговая проверка
Мы понимаем, что если в КХД попадает «мусор», то вся аналитика и все интеграции будут не просто бесполезными, а скорее даже вредными. Поэтому мы внедрили управление качеством данных (Data Quality) как постоянный сценарий, а не просто как «проверку» на финальном этапе.
Мы проверяем точность, полноту и согласованность данных. Например, есть простое правило: ИНН должен состоять из определенного количества цифр. Если из системы-источника поступают данные, не соответствующие этому правилу, мы или блокируем поступление, или, как минимум, активируем «красную лампочку», сигнализирующую о состоянии и качестве данных.
Но что делать, когда обнаружится ошибка? В дело вступает управление данными (Data Governance). Мы не ограничиваемся «ремонтом» данных на своей стороне, мы идем к владельцу системы-источника и выясняем, где произошло искажение данных – на стороне платформы или в корпоративных системах. Такой сценарий работы с первопричинами позволил нам избежать негативных последствий в дальнейшем, ведь если не организовать управление инцидентами, связанными с качеством данных, и не определить ответственных за поддержание требуемого состояния данных, невозможно говорить об эффективном управлении данными.
Инсайт 2. Data Vault 2.0: можно и нужно автоматизировать
Ручное ведение метаданных (информации о структурах и составах модели данных) – это сложный путь, полный страданий. Вот почему нами было принято решение о необходимости создания собственного каталога метаданных. Для этого мы разработали автоматическую генерацию структур Data Vault 2.0, которая позволяет автоматически пополнять каталог новыми сущностями. На их основе система автоматически генерирует и дополняет нужные таблицы (хабы, ссылки, сателлиты). В итоге такой подход ускоряет подключение новых источников, к тому же, за счет использования pgModeler, мы смогли визуализировать процессы.
Инсайт 3. НСИ – наш главный актив
Опыт реализации больших проектов подсказал нам, что большая часть работы зачастую связана с переиспользованием информации. Например, целесообразно ли десяти разным отчетам по отдельности загружать и обрабатывать список сотрудников или должностей? Чтобы исключить дублирование работ, мы сформировали единую витрину нормативно-справочной информации (НСИ), и теперь все потребители используют ее при необходимости. Хорошая, полная и достоверная витрина НСИ экономит десятки часов работ в части интеграции и аналитики.
Инсайт 4. Self-Service – это не инструмент, а культура
При этом мы осознаем, что наша роль – поддерживать трансформацию, а не ограничивать бизнес. Поэтому мы активно развиваем Self-Service платформу, предоставляя пользователям удобные инструменты и прямой доступ к данным.
Это позволяет им самостоятельно и быстро проверять свои гипотезы, что, в конечном итоге, способствует фундаментальному изменению подхода к работе с данными во всей компании, делая ее более гибкой и клиентоориентированной.
Что мы получили в итоге
Первый этап работы по построению КХД, обеспечивающего прозрачный обмен данными и автоматические интеграции, завершен. Мы частично исключили человеческий фактор и сократили время на выполнение всей цепочки бизнес-процессов.
Мы гордимся тем, что обеспечили актуальность, своевременность и достоверность данных не только для отчетов, но и для ключевых бизнес-систем.
Каковы ключевые выводы, сделанные нами по результатам реализации? Пожалуй, основной тот, который описан в первом инсайте: согласованность данных в крупной компании начинается не с технологий, а с простого вопроса – кто за эти самые данные отвечает и кто ими пользуется?
Мы можем построить идеальную архитектуру. Но если в системе-источнике данные неполные или некорректные, наше КХД может только сигнализировать об этом. Исправлять их должен владелец на своей стороне, поэтому Data Governance – это фундамент, на котором все строится.
Что же касается Data Vault 2.0, наш опыт показал, что выбор этой методологии для ядра оказался правильным. Его модульность – это то, что позволяет нам сейчас относительно просто и безболезненно расширять структуру и смело смотреть в будущее, где планируется подключение новых источников к КХД.
Что дальше?
Корпоративное хранилище данных – не тот проект, который можно один раз построить, сдать и забыть. Это платформа, которая постоянно развивается.
В дальнейшем мы планируем включение в платформу новых важных бизнес-процессов, а также хотим обогатить наши данные за счет интеграции с общефедеральными справочниками. Например, с данными контрагентов или кадастровыми данными. И, конечно, с командой продолжим развивать инструменты Self-Service для наших коллег.
Также в планах проработка возможности применения модели «Data as a Service» (DaaS), в соответствии с которой данные доступны через федеративные и стандартизированные API и/или другие протоколы/сервисы для потребителей компании.
А как вы у себя в компании решаете вопросы управления данными? Кто отвечает за «правду» в источнике? Делитесь в комментариях.