Руководство по качеству корпоративных данных «Кто за что отвечает»
Подробное описание того, как крупным организациям стоит разрабатывать программы качества данных с учетом особенностей современных платформ данных.
Я общался с несколькими специалистами по корпоративным данным в крупнейших мировых корпорациях, и один из самых распространенных вопросов о качестве данных звучит так- «кто за что отвечает?». За ним следуют вопросы «Почему и как именно?».
Этому есть причина. Качество данных похоже на эстафету. Успех каждого этапа - обнаружения, сортировки, размещения и измерения - зависит от предыдущего шага. Каждый раз, когда эстафетная палочка передается следующему участнику, шансы на неудачу резко возрастают.
Практичные вопросы требуют практичных ответов.
Начнем с того, что в каждой организации работа с данными организована по-разному. Я видел организации с 15 000 сотрудников, которые централизовали владение всеми критическими данными, в то время как организации вдвое меньшего размера решили разнести владение данными по разным областям бизнеса.
В рамках этой статьи я буду рассматривать наиболее распространенную архитектуру предприятия, которая представляет собой гибрид этих двух вариантов. К ней стремится большинство команд по работе с данными, она также включает в себя множество обязанностей между командами, что делает ее особенно сложной, но работоспособной.
Просто имейте в виду, что то, что будет написано ниже, - это ОДИН из возможных ответов, а не ЕДИНСТВЕННО ПРАВИЛЬНЫЙ ответ.
Важность продуктов данных
Независимо от того, реализуется ли стратегия data mesh или что-то еще, современные команды, работающие с данными, обычно понимают, что необходимо объединить свои усилия и инвестировать в наиболее ценные продукты данных.
Так называют наборы данных, приложения или сервисы с особенно ценными для бизнеса результатами. Это может быть приложение для машинного обучения, приносящее доход, или набор идей, полученных из хорошо обработанных данных.
По мере роста масштаба и сложности команды по работе с данными все больше различают основополагающие и производные продукты данных. Основополагающие продукты данных обычно принадлежат центральной команде платформы данных (или иногда команде Data Engineering, ориентированной на источник). Они предназначены для обслуживания сотен сценариев использования во многих командах или бизнес-доменах.
Производные продукты данных создаются на основе основополагающих продуктов данных. Они принадлежат командам по работе с данными, ориентированным на конкретный домен, и предназначены для каждого конкретного случая использования.
Например, «Единый взгляд на клиента» - это общий основополагающий продукт данных, который может служить основой для производных продуктов данных, таких как модель повышения продаж продукта, прогнозирование оттока клиентов и корпоративный дашборд.
Существуют различные процессы обнаружения, устранения, разрешения и измерения качества данных для этих двух типов продуктов. Преодоление пропасти между ними жизненно необходимо. Вот один из популярных способов, с помощью которого, по моим наблюдениям, команды разработчиков данных делают это наиболее эффективно.
Обнаружение
Основополагающие продукты данных
До того как данные станут доступными для обнаружения, для каждого основополагающего продукта данных должен быть назначен ответственный за проектирование платформы данных. Именно эта команда отвечает за мониторинг свежести, объема, схемы и базового качества данных на протяжении всего конвейера обработки данных. Хорошее эмпирическое правило, которого придерживается большинство команд, гласит: «Ты его создал, ты им и владеешь».
Говоря о базовом качестве, я имею в виду требования, которые можно обобщить на многие наборы данных и области. Они часто определяются центральной группой управления для критически важных элементов данных и, как правило, соответствуют 6 измерениям качества данных. Такие требования, как «столбцы id всегда должны быть уникальными» или «это поле всегда форматируется как действительный код штата США."
Другими словами, владельцы основополагающих продуктов данных не могут просто обеспечить своевременное поступление данных. Они должны убедиться в том, что исходные данные полны и достоверны, что они согласованы между источниками и последующими загрузками, а в критических полях отсутствуют ошибки. Особенно эффективными в этом отношении могут быть модели обнаружения аномалий на основе машинного обучения.
Более точные и индивидуальные требования к качеству данных, как правило, зависят от конкретного случая использования, и их лучше применять владельцам и аналитикам производных продуктов данных.
Производные продукты данных
Контроль качества данных должен осуществляться и на уровне продуктов производных данных, поскольку плохие данные могут попасть в систему в любой момент жизненного цикла данных.
Даже если качество данных хорошее на уровне основополагающих продуктов, это не значит, что оно не испортится на уровне производных продуктов.
Однако на этом уровне необходимо охватить большую площадь. «Мониторинг всех таблиц на предмет всех возможных вариантов» не является самым оптимальным решением.
Существует множество факторов, определяющих, когда коллекция таблиц должна стать продуктом производных данных, но все они могут быть сведены к оценке устойчивой ценности. Зачастую это лучше всего удается стюардам данных, работающим в домене, которые близки к бизнесу и уполномочены следовать общим рекомендациям по частоте и критичности использования.
Например, один из моих коллег, занимавший ранее должность руководителя платформы данных в национальной медиакомпании, поручил аналитику разработать панель Master Content, которая быстро стала популярной в редакции. После того как она стала неотъемлемой частью рабочего процесса достаточного количества пользователей, они поняли, что ее просто необходимо доработать.
Когда создается или определяется производный продукт данных, у него должен быть владелец, отвечающий за сквозной мониторинг и базовое качество данных. Во многих организациях таким владельцем будут управляющие данными домена, поскольку они лучше всего знакомы с глобальными и локальными политиками. Другие модели владения включают назначение встроенного инженера по данным, который создал конвейер производных данных, или аналитика, который владеет таблицей «последней мили».
Другим ключевым отличием рабочего процесса обнаружения на уровне производных продуктов данных являются бизнес-правила.
Есть некоторые правила качества данных, которые нельзя автоматизировать или генерировать на основе централизованных стандартов. Они могут исходить только от бизнеса. Такие правила, как «поле discount_percentage не может быть больше 10, если тип_аккаунта равен commercial, а регион_клиента равен EMEA».
Эти правила лучше всего применять аналитикам, в частности владельцу таблицы, основываясь на своем опыте и обратной связи с бизнесом. Нет необходимости в том, чтобы каждое правило инициировало создание продукта данных, это слишком тяжелый и обременительный процесс, который должен быть полностью децентрализованным, самообслуживаемым и легким.
Сортировка
Основополагающие продукты данных
В некоторых отношениях обеспечение качества данных для основополагающих продуктов данных менее сложно, чем для производных продуктов данных. Основополагающих продуктов по определению меньше, и они, как правило, принадлежат техническим командам.
Это означает, что владелец продукта данных или дежурный инженер по данным в команде платформы может отвечать за общие задачи по сортировке, такие как реагирование на оповещения, определение вероятной точки происхождения, оценка серьезности и общение с потребителями.
Каждый основополагающий продукт данных должен иметь как минимум один выделенный канал оповещений в Slack или Teams.
Это позволяет избежать тонны оповещений и может служить центральным каналом связи для всех владельцев продуктов производных данных. В той мере, в какой они хотят, они могут оставаться в курсе проблем и быть проактивно информированными о любых предстоящих изменениях схемы или других изменениях, которые могут повлиять на их работу.
Производные продукты данных
Как правило, у инженеров по обработке данных слишком много производных продуктов данных, чтобы они могли правильно сортировать их, учитывая их пропускную способность.
Назначение владельца каждого продукта производных данных ответственным за сортировку оповещений - часто используемая стратегия (см. рисунок ниже), но и она может оказаться неэффективной при росте числа зависимостей.
Например, неудачное задание оркестровки может каскадом обрушиться вниз, создавая десятки предупреждений для нескольких владельцев продуктов данных. Накладывающиеся друг на друга сигналы тревоги - это самый настоящий кошмар!
Одна из лучших практик, которая все чаще используется, - это создание специальной команды сортировщиков (часто называемой dataops) для поддержки всех продуктов в определенном домене.
Это может быть «зона Златовласки», которая позволяет воспользоваться преимуществами специализации, но при этом не становится настолько огромной, что превращается в узкое место, лишенное контекста. Эти команды должны быть обучены и наделены полномочиями для работы между доменами, иначе Вы просто вернетесь к силовым структурам и дублирующим друг друга пожарным инструктажам.
В этой модели владелец продукта данных несет ответственность, но не обязанность.
Разрешение
Компания Wakefield опросила более 200 специалистов по работе с данными, по их словам, средний показатель инцидентов в месяц составил 60, а среднее время на устранение каждого инцидента после его обнаружения - 15 часов. Очевидно, что инженеры по обработке данных просто погрязли в накопившихся проблемах.
Этому способствует множество факторов, но главный из них заключается в том, что мы отделили аномалию от первопричины как технологически, так и процедурно. Инженеры по обработке данных заботятся о своих конвейерах, а аналитики - о своих метриках. Инженеры по обработке данных настраивают оповещения Airflow, а аналитики - правила SQL.
Но конвейеры - источники данных, системы, которые перемещают данные, и код, который их преобразует, и есть первопричина возникновения аномалий в метриках.
Чтобы сократить среднее время решения проблем, этим техническим специалистам необходима платформа для наблюдения за данными или некая центральная плоскость управления, которая свяжет аномалию с первопричиной. Например, решение, которое показывает, как аномалия распределения в поле discount_amount связана с изменением запроса, произошедшим в то же время.
Измерение
Основополагающие продукты данных
Говоря о проактивных коммуникациях, следует отметить, что измерение и распространение информации о состоянии основополагающих продуктов данных имеет жизненно важное значение для их принятия и успеха. Если потребляющие домены не доверяют качеству данных или надежности их доставки, они пойдут прямо к источнику. Каждый. А это все опять же выливается во Время.
Это, конечно, противоречит всей цели основополагающих продуктов данных. Экономия от масштаба, стандартный контроль управления при вводе в эксплуатацию, четкая видимость происхождения и использования - все это теперь за бортом.
Обеспечить общий стандарт качества данных, применимый к различным вариантам использования, может быть непросто. Однако на самом деле команды по работе с данными хотят знать следующее:
- Как часто обновляются данные?
- Насколько хорошо они обслуживаются? Как быстро решаются инциденты?
- Часто ли будут происходить изменения схемы, которые нарушат мои конвейеры?
В этом случае могут помочь команды Data Governance - они могут раскрыть общие требования и критические элементы данных, которые помогут установить и внедрить интеллектуальные SLA на рынке или в каталоге.
Таков подход команды данных Roche ,создавшей одну из самых успешных корпоративных сетей данных в мире, которая, по их оценкам, создала около 200 продуктов данных и оценивается в 50 миллионов долларов.
Производные продукты данных
Для продуктов на основе производных данных следует установить четкие SLA, основанные на определенном сценарии использования. Например, для финансового отчета может потребоваться высокая точность с некоторым запасом на своевременность, в то время как для модели машинного обучения может быть прямо противоположное требование.
Показатели здоровья на уровне таблиц могут быть полезны, но распространенной ошибкой является предположение, что в общей таблице бизнес-правила, установленные одним аналитиком, будут актуальны для другого. Таблица может казаться низкокачественной, но при ближайшем рассмотрении вполне может получиться так, что несколько устаревших правил неоднократно терпели неудачу изо дня в день без каких-либо действий по устранению проблемы или порога правила.
В поисках исключительного качества данных
Мы проделали большой объем работы. Эта статья - скорее марафон, чем эстафета.
Приведенные выше рабочие процессы - это лишь ОДИН из способов добиться успеха в программах обеспечения Качества данных. Если Вы поставите во главу угла четкие процессы по:
- Созданию и владению продуктами данных;
- Самостоятельному созданию бизнес-правил для последующих активов;
- Реагированию на оповещения и их изучению;
- Ускорению анализа первопричин; и
- Укреплению доверия путем информирования о состоянии данных и оперативном реагировании,
… то через некоторое время Вы увидите, как Ваша команда успешно пересекает «финишную черту» и достигает высокого качества данных.
