Внедрять Data Governance пора, когда топ-менеджеры перестают доверять отчетам
Время просмотра: 3.5 мин.
Компания «Инфосистемы Джет» является надежным поставщиком решений IBM. Стратегическое партнерство компаний, ознаменованное наличием у «Инфосистемы Джет» высшего статуса IBM Platinum Business Partner и специализациями в области аппаратного и программного обеспечения, построения динамической инфраструктуры и облачных решений, насчитывает уже не один год.
Почему правильный подход к Data Governance улучшает доверие к аналитике?
Основные предпосылки внедрения этих технологий?
Чем подписка на решения Data Governance может быть лучше традиционной лицензии?
Под Data Governance (DG) принято понимать набор методологий и технологий для хранения, обработки и управления данными. Как правило, данные компании могут быть распределены по разным облачным средам, разрозненным приложениям и даже ЦОДам в разных странах, а также по дочерним организациям. Это затрудняет их объединение и анализ. Расположение данных в разных местах предполагает, что они должны соответствовать различным нормативным требованиям и требованиям конфиденциальности. Это, в свою очередь, означает, что объединение данных в единое хранилище для операций над ними может быть затруднительным процессом или просто невозможным.
Data Governance дает возможность технологически свести данные воедино и подготовить для решения бизнес-задач, в том числе при помощи систем искусственного интеллекта. IBM считает, что, благодаря инновациям в таких областях, как федерализация данных и управление ИИ, способность обучать и управлять моделями данных и ИИ в гибридной облачной среде будет расширяться, стимулируя внедрение ИИ в последующие несколько лет.
Data Governance с точки зрения инструментов — это единое окно, которое позволяет свести данные из всех систем на один экран. Если мы нарисуем ландшафт ИТ-систем, которые хранят в себе данные, получится обширная карта: источники данных, как минимум одно хранилище, различные интеграционные слои и точки отчетности, например, BI-инструменты. Между всеми этими сущностями есть точки конвертации данных. Data Governance в этом ландшафте — своего рода спрут, который охватывает своими щупальцами абсолютно все узлы. Благодаря этому пользователь получает доступ ко всем данным из одного интерфейса.
Мы считаем понятия «Data Governance» и «озеро данных» смежными. Самое важное отличие: озеро не приносит прямой практической пользы. Информацию оттуда можно использовать, но в первую очередь оно нацелено на ее накопление.
Data Governance иногда путают с Data Management. Последний термин постепенно выходит из употребления. Раньше под ним понимали совокупность систем, которые манипулируют информацией, но не всегда ею управляют. Агрегация и хранение, конвертация и миграция данных — все это называлось Data Management. Data Governance же подразумевает методологические инструменты, которые позволяют управлять этими процессами.
Data Governance иногда путают и с Big Data. Зонтичный термин Big Data, которым в свое время называли чуть ли не все, связанное с данными, в первую очередь касается конкретных кейсов. Как выстроить индивидуальную работу с клиентами, какой набор товаров и услуг им предложить — вот поле для обработки Big Data. Data Governance же — это инструменты моделирования, отчетности и построения гипотез.
Еще пять лет назад DG был прерогативой исключительно ИТ-службы. Этим занимались дата-стюарды — сотрудники, которые управляли данными внутри компании: следили за соблюдением правил работы с ними, обрабатывали и предоставляли бизнесу. Со временем запросы бизнеса (к примеру, сокращение времени выхода на рынок или повышение эффективности маркетинговых кампаний) привели к новым ИТ-потребностям. Теперь данные были нужны срочно, вот прямо сейчас. Но на деле все выглядело так: маркетинг пишет письмо в ИТ-службу, она в своем режиме начинает работать с источниками, собирает информацию и отправляет обратно. «Прямо сейчас» не получалось. Это замедляло работу бизнес-подразделений, поэтому они начали вникать в вопрос работы с данными.
Статьи по теме
Поделиться
Есть пример компании в России, которая научила SQL сотни бизнес-сотрудников, прежде не имевших никакого отношения к программированию. А всё для того, чтобы они могли работать с базами данных напрямую, не нагружая этим ИТ-службу.
Как внедрять
В 2016 г. подавляющее число проектов IBM по внедрению Data Governance в мире относилось к финансовому сектору. Дело в том, что Data Governance — в первую очередь про упорядочивание данных. Если представители фискальных ведомств, к примеру налоговой службы или казначейства, во время внешнего аудита найдут в разных источниках противоречивые значения одного параметра, они могут выставить немалую претензию. Это одна из причин востребованности Data Governance в финансовом секторе.
Сейчас инструменты DG легче «приземлить» на реальный бизнес, поэтому их используют в телекоме, логистике, на производстве. Технологии стали проще, доступнее и дешевле. Совокупная стоимость их владения (TCO) за последние годы снижается. Сейчас Data Governance включает в себя создание каталога метаданных, физическую и логическую модели, data lineage (отслеживает происхождение данных) и data quality (контролирует их качество). Выбирая нужные блоки, вы фактически формируете стоимость решения. Внедрение всего и сразу обойдется дороже, но, если вести работу поэтапно, получится не такая большая единовременная нагрузка на бюджет.
Не каждая компания готова управлять данными. Решение IBM InfoSphere Information Governance Catalog известно на рынке, поэтому нередко заказчики сами приходят к нам с запросом на внедрение. Когда мы начинаем общаться, то понимаем, что у них нет необходимой оргструктуры, ответственного за данные, даже цели DG зачастую не определены. Есть своего рода энтропия данных, которыми бизнес хочет управлять, но не знает как. Осознание проблемы присутствует, и это отлично, но с такими вводными сложно начинать проект.
Топ-менеджер крупной компании как-то сказал на рабочей встрече, что не доверяет двум третям данных в отчетах. Это признак того, что DG-проект нужен компании и решение будет успешно использоваться. Для внедрения необходимы две составляющие. Первая: в компании должна быть методология работы с информацией, формируется офис директора по работе с данными (Chief Data Officer). Вторая, самая главная: представитель топ-менеджмента (уровня директора или вице-президента) осознает необходимость внедрения инструмента управления данными. Это работает во всех случаях. Когда нет спонсора на высшем уровне, который включит зеленый свет и будет продвигать проект, внедрение может забуксовать. Если такой есть, останется решить технические задачи. Вместе с бизнес-партнером мы готовы помочь выбрать методологию и спланировать внутреннюю инфраструктуру. Главное, чтобы руководство компании осознавало всю важность будущего проекта — для чего они внедряют Data Governance.
Своеобразная фабрика данных, поддерживаемая процессами Data Governance, поможет устранить разрозненность и автоматизировать интеграцию данных, чтобы обеспечить их доступность для просмотра и анализа всеми пользователями. Данные можно обрабатывать, управлять ими и сохранять их по мере обработки, поэтому бизнес-пользователи получают единую точку доступа для поиска, формирования и использования данных в масштабах всей компании.
Data Governance и ритейл: отношения неизбежны
Розничным сетям уже не обойтись без Data Governance. Ритейл, как и телеком, ориентирован на массовых потребителей и корпоративных клиентов и занимает лидирующие позиции по объемам накопления данных и вариативности кейсов. Чековая аналитика, сегментация товаров, ценообразование, рентабельность операций — все эти аналитические задачи ритейлеры решали поэтапно, шаг за шагом. Со временем у них возникла потребность в централизованном подходе, то есть в инструментарии DG.
Для ритейла вполне привычна лоскутная система сбора данных. Например, у ритейловой сети может быть 20 разрозненных источников данных. То есть 20 потенциальных точек отказа, 20 точек администрирования и лицензирования и 20 типов информации, из которых в итоге формируются 20 разных моделей хранения данных. Это распространенная проблема. Но как всем этим разнообразием управлять?
Краеугольное правило для ритейла — высокое качество данных. Достоверная информация в отчетах позволяет строить качественные гипотезы, в том числе для маркетинговых кампаний. Согласитесь, будет неловко, если специальное предложение по мясу будет направлено вегетарианцу, который никогда не совершал подобных покупок. А это возможно, если работа с данными выстроена некорректно.
Ритейл — высокооборотная и коммодитизированная отрасль, поэтому решение, которое может повысить доход от чека даже на доли процента, может быть выгодным для бизнеса. Наш недавний кейс в российском ритейле — внедрение инструментов Data Governance в X5 Retail Group.
DataGovernance своими силами
Данные — это ценнейший актив компании. Об этом заявляет чуть ли не каждая компания с цифровым уклоном. С этим сложно спорить: без обсуждения подходов управления, хранения и обработки данных сейчас не проходит ни одна крупная IT-конференция.
Данные к нам поступают снаружи, также они формируются внутри компании, а если говорить о данных телеком-компании, то это для внутренних сотрудников кладезь информации о клиенте, его интересах, привычках, месторасположении. При грамотном профилировании и сегментации рекламные предложения выстреливают наиболее эффективно. Однако, на практике не все так радужно. Те данные, которые хранят компании, могут быть безнадежно устаревшими, избыточными, повторяющимися, либо об их существовании никому не известно, кроме узкого круга пользователей. ¯\_(ツ)_/¯
Одним словом, данными нужно эффективно управлять – только в таком случае они станут активом, приносящим бизнесу реальную пользу и прибыль. К сожалению, для решения вопросов управления данными нужно преодолеть довольно много сложностей. Обусловлены они в основном как историческим наследием в виде «зоопарков» систем, так и отсутствием единых процессов и подходов к управлению ими. Но что означает «управлять данными»?
Именно мы об это мы и поговорим под катом, а также о том, как нам помог opensource-стек.
Концепция стратегического управления данными Data Governance (DG) уже достаточно известна на российском рынке, и цели, достигаемые бизнесом в результате ее внедрения, понятны и четко декларированы. Наша компания не стала исключением и поставила перед собой задачу внедрения концепции управления данными.
Итак, с чего мы начали? Для начала мы сформировали для себя ключевые цели:
Но после детального анализа и изучения решений мы зафиксировали для себя ряд критичных замечаний:
Реестр отчётов
По результатам внутренних исследований в крупных компаниях, решая задачи, связанные с данными, сотрудники тратят 40—80% времени на их поиск. Поэтому мы поставили перед собой задачу сделать открытой информацию о существующих отчётах, которые ранее были доступны только заказчикам. Тем самым мы сокращаем время на формирование новой отчётности и обеспечиваем демократизацию данных.
Реестр отчётов стал единым окном отчётности для внутренних пользователей из различных регионов, департаментов, подразделений. В нем консолидирована информация по инфосервисам, созданным в нескольких корпоративных хранилищах компании, а их в Ростелекоме немало.
Но реестр — это не просто сухой список разработанных отчётов. Для каждого отчёта мы предоставляем информацию, необходимую пользователю для самостоятельного знакомства с ним:
Разработка этого модуля стала важным шагом в части демократизации данных и значительно сократила время поиска требуемой информации. Кроме сокращения времени поиска, снизилось и количество обращений к команде сопровождения на предоставление консультаций. Нельзя не отметить еще один полезный результат, которого мы добились, разработав единый реестр отчётов – предотвращение разработки дублирующих отчётов для разных структурных единиц.
Бизнес-глоссарий
Все вы знаете, что даже в рамках одной и той же компании бизнес говорит на разных языках. Да, используют одни и те же термины, но понимают под ними совсем разные вещи. Решить данную проблему призван бизнес-глоссарий.
Для нас бизнес-глоссарий — не просто справочник с описанием терминов и методологией расчета. Это полноценная среда разработки, согласования и утверждения терминологии, построения взаимосвязей терминов с другими информационными активами компании. Перед тем как попасть в бизнес-глоссарий, термин должен пройти все этапы согласования с бизнес-заказчиками и центром качества данных. Только после этого он становится доступным для использования.
Как я уже написал выше, уникальность данного инструмента в том, что он позволяет проводить связи от уровня бизнес-термина до конкретных пользовательских отчётов, в которых он используется, а также до уровня физических объектов баз данных.
Это стало возможным посредством использования идентификаторов терминов глоссария в детальном описании отчётов из реестра и описании физических объектов баз данных.
Сейчас в Глоссарии определено и согласовано уже более 4000 терминов. Его использование упрощает и ускоряет обработку поступающих запросов на изменение в информационных системах компании. Если требуемый показатель уже реализован в каком-либо отчёте, то пользователь сразу увидит набор готовых отчётов, где этот показатель использован, и сможет принять решение об эффективном повторном использовании имеющейся функциональности или о её минимальной доработке, не инициируя новых запросов на разработку нового отчёта.
Модуль описания технических трансформаций и DataLineage
Вы спросите, что это за модули? Мало просто внедрить Реестр отчёта и Глоссарий, необходимо ещё приземлить все бизнес-термины на физическую модель баз данных. Тем самым мы смогли завершить процесс формирования жизненного цикла данных от систем источников до BI-визуализации через все слои хранилища данных. Иными словами — построить DataLineage.
Мы разработали интерфейс, в основе которого лежал используемый ранее в компании формат описания правил и логики трансформации данных. Посредством интерфейса заводится всё та же информация, что и раньше, но обязательным условием стало определение идентификатора термина из бизнес-глоссария. Так мы и выстраиваем связь между бизнес- и физическими слоями.
Кому это нужно? Чем не устроил старый формат, с которым работали несколько лет? Насколько увеличились трудозатраты на формирование требований? С такими вопросами нам приходилось сталкиваться в процессе внедрения инструмента. Здесь ответы достаточно просты – это нужно всем нам, дата-офису нашей компании и нашим пользователям.
Действительно, сотрудникам пришлось перестраиваться, поначалу это привело к незначительным увеличениям трудозатрат на подготовку документации, но с этим вопросом мы разобрались. Практика, выявление и оптимизация проблемных мест сделали свое дело. Мы добились главного — повысили качество разрабатываемых требований. Обязательные для заполнения поля, унифицированные справочники, маски ввода, встроенные проверки – всё это позволило в разы повысить качество описаний трансформаций. Мы ушли от практики передачи скриптов в виде требований на разработку, расшарили знания, которые были доступны только команде, занимающейся разработкой. Сформированная база метаданных сокращает в разы время на проведение регресс-анализа, обеспечивает возможность оперативной оценки влияния изменений на любом из слоев ИТ-ландшафта (отчёты витрины, агрегаты, источники).
А причём здесь обычные пользователи отчётов, какие плюсы для них? Благодаря возможности построения DataLineage наши пользователи, даже далекие от SQL и других языков программирования, оперативно получают информацию об источниках и объектах, на основе которых формируется тот или иной отчёт.
Модуль контроля качества данных
Всё, о чём мы говорили выше в части обеспечения прозрачности данных, не важно без понимания того, что данные, которые мы отдаём пользователям, — корректные. Один из важных модулей нашей концепции Data Governance — модуль контроля качества данных.
На текущем этапе это каталог проверок по выборочным сущностям. Ближайшая цель по развитию продукта – это расширение перечня проверок и интеграция с реестром отчётов.
Что это даст и кому? Для конечного пользователя реестра будет доступна информация о плановых и фактических датах готовности отчёта, результаты отработанных проверок с динамикой, сведения по загруженным в отчёт источникам.
Для нас интегрированный в рабочие процессы модуль качества данных это:
Data governance: добавление сторонних метаданных в Apache Atlas
Управление и устойчивая обработка данных являются важнейшим фактором успеха практически во всех организациях. В то время как платформа Cloudera Data Platform (CDP) уже поддерживает весь жизненный цикл данных от ‘Периферии до ИИ’, мы в Cloudera полностью осознаем, что предприятия имеют больше систем за пределами CDP. Очень важно избегать того, чтобы CDP становилась ещё одной обособленной платформой в вашем ИТ-ландшафте. Чтобы исправить это, она может быть полностью интегрирована в существующую корпоративную ИТ-среду, какой бы разнообразной она ни была, и даже помогать отслеживать и классифицировать широкий спектр существующих активов данных, чтобы обеспечить полную картину от начала и до конца. В этом блоге мы выделим ключевые аспекты CDP, которые обеспечивают управление данными и lineage, и покажем, как их можно расширить, чтобы включить в них метаданные из не связанных с CDP систем со всего предприятия.
SDX (Shared Data Experience)
Apache Atlas как фундаментальная часть SDX в CDP обеспечивает согласованную защиту данных и управление ими во всем спектре аналитических инструментов, развернутых в гибридной архитектуре, благодаря технологии Shared Data Experience (SDX). Как и сама CDP, SDX построена на проектах с открытым исходным кодом, где Apache Ranger и Apache Atlas играют главные роли. Atlas предоставляет возможности управления метаданными и создания единого дата каталога, а также классификации и управления этими активами данных. SDX в CDP использует все возможности Atlas для автоматического отслеживания и управления всеми активами данных со всех инструментов на платформе.
Использование возможностей Atlas для активов данных за пределами CDP
Все построено вокруг основной структуры модели метаданных, состоящей из определений типов (type definitions) и объектов (entities) (подробнее см. документацию Atlas):
Определения каждого типа (typedef)
может быть выведено из определения супертипа
может быть частью высшего класса, позволяя создавать древовидное, структурированное хранилище для активов данных
может иметь неограниченное количество характеристик (атрибутов) для сохранения всех нужных описаний
может определить допустимый набор классификационных определений, которые впоследствии могут быть добавлены к каждой сущности данного typedef. В следующем примере мы используем определенный сервер для типа ‘database_server’. Классификации могут также использоваться для указания, содержит ли таблица Персональную идентифицируемую информацию (PII).
Объекты являются примерами определенного typedef и:
могут быть связаны друг с другом
могут быть связаны с любым количеством классификаций. Например, каждому приложению или случаю использования может быть присвоена уникальная классификация; в примере ниже используется «xyz» в качестве приложения. После добавления, связанные объекты могут быть непосредственно привязаны к классификации, что дает четкое представление об артефактах и о том, как они соотносятся друг с другом.
Наконец, Atlas предоставляет богатый набор REST API, которые могут использоваться для:
управления основными typedef и классификациями
управления объектами (сущности typedef )
управления отношениями между объектами
Расширение модели метаданных в Атласе
Следующие шаги описывают, как Atlas может быть расширен для добавления метаданных из третьих источников. На различных этапах используются готовые скрипты из репозитория Github.
Эскиз сквозной линии передачи данных.
Ниже приведен очень простой, но распространенный сценарий ETL пайплайна:
Исходная система (например, транзакционное приложение для банковского приложения) отправляет файл с данными в CSV на какое-то хранилище (не HDFS). Затем ETL-процесс считывает файл, выполняет некоторые проверки качества и загружает проверенные записи в СУБД, а также в таблицу Hive. Проблемные записи сохраняются в отдельном файле ошибок.
Чтобы запечатлеть этот сквозной поток данных в Атласе, нам нужны следующие typedef’ы:
Активы (typedef):
— Файлы
— Таблица в СУБД
— таблица Hive *обратите внимание, что этот актив уже доступен в Атласе в CDP в качестве неотъемлемой части платформы CDP. Нет необходимости создавать typedef, но мы покажем, как сторонние активы могут подключаться к активам CDP для построения сквозного прослеживания.
Процессы:
— Процесс передачи файлов
— процесс загрузки ETL/DB
2. Определение требуемых определений типов (typedef’s).
С точки зрения дизайна, typedef аналогичен определению класса. Существуют предопределенные определения типов (typedefs) для всех активов, которые используются в CDP, например, таблицы Hive. Определения, которые не существуют из коробки, могут быть определены с помощью следующего синтаксиса в простом JSON-файле. В примере 1_typedef-server.json описывается сервер typedef, используемый в этом блоге.
Тип: сервер
Производная форма: ENTITY
Специальные характеристики для этого typedefа:
— имя хоста (host_name)
— ip_адрес (ip_address)
— зона (zone)
— платформа (platform)
— стойка (rack_id)
3. Добавление typedef’ов через REST API в Атлас
Примечание: При желании вы можете использовать локальную установку на базе докера для первых шагов:
Typedef JSON запрос хранится в файле 1_typedef-server.json, и мы вызываем конечную точку REST следующей командой:
Для создания всех требуемых typedef’ов для всего конвейера данных можно также использовать следующий bash скрипт (create_typedef.sh):
4. Проверка интерфейса Atlas после добавления типов и классификации внешних источников, чтобы убедиться, что новые сущности были добавлены
Новые типы сгруппированы под обьектом «3party».
Также были добавлены новые классификации:
5. Создание сущности «server»
Чтобы создать субъект, используйте REST API «/api/atlas/v2/entity/bulk» и обратитесь к соответствующей типизации (например, «typeName»: «server»).
Полезно знать: Create vs Modify. Каждый типдеф определяет, какие поля должны быть уникальными. Если вы отправите запрос, в котором эти значения не являются уникальными, существующий экземпляр (с одинаковыми значениями) будет обновлен, а не вставлен.
Следующая команда показывает, как создать субъект сервера:
Скрипт create_entities_server.sh из репозитория github иллюстрирует создание субъекта сервера с помощью общего сценария с некоторыми параметрами. На выходе получается GUID созданного/измененного артефакта (например, SERVER_GUID_LANDING_ZONE=f9db6e37-d6c5-4ae8-976c-53df4a55415b).
6. Создание сущности типа «datafile»
Аналогично созданию субъекта сервера, снова используйте REST API «/api/atlas/v2/entity/bulk» и обратитесь к типу «dataset».
Скрипт create_entities_file.sh из репозитория github показывает, как создать сущность dataset и вернуть GUID для каждого файла.
7. Поддерживание информации о классификациях, связанных с приложениями
Чтобы не потерять информацию о том, какая сущность является какой, если их существует много, мы можем создать дополнительную классификацию для каждого приложения. Скрипт create_classification.sh поможет нам создать дополнительную классификацию для каждого приложения, которая может быть использована для привязки всех активов к нему.
Вызов REST endpoint:
8. Построение отношения между активами
Для активов конвейера данных, которые мы спроектировали и создали выше, нам нужны два разных типа для процессов, которые их соединяют:
9. Собераем все вместе
Теперь у нас собраны все кусочки головоломки. Скрипт sample_e2e.sh показывает, как собрать их вместе, чтобы создать сквозную линию данных. Пайплайн также может содержать активы, которые уже были CDP, нужно просто установить между ними связь (как показано выше).
Создайте уникальную классификацию для данного приложения
Создайте необходимые сущности серверов
Создайте необходимые сущности датасетов на ранее созданных серверах (Mainframe, Landing zone).
Создайте необходимые сущности таблиц БД на ранее созданном сервере БД
Создайте процесс с типом ‘transfer’ между набором данных Mainframe > Landing
Создайте процесс с типом ‘etl_load’ между Landing zone > DB table
Создайте процесс с типом ‘etl_load’ между Landing zone > таблицей HIVE
Создайте процесс с типом ‘etl_load’ между Landing zone > набором данных Error
