Как реализовать процесс качества данных

Качество данных (DQ) в системах хранения данных становится все более и более важным. Растущие нормативные требования, а также растущая сложность решений для хранилищ данных вынуждают компании усиливать (или запускать) инициативу по обеспечению качества данных.

Основное внимание в этой статье будет уделено «традиционным» хранилищам данных, но качество данных также является проблемой в более «современных» концепциях, таких как озера данных. В нем будут показаны некоторые основные моменты, которые следует учитывать, а также некоторые распространенные ловушки, которых следует избегать при реализации стратегии обеспечения качества данных. Он не охватывает часть выбора правильной технологии/инструмента для создания структуры DQ.

Одной из самых мешающих проблем проекта DQ является тот факт, что на первый взгляд он создает много работы для бизнес-подразделений, не предоставляя никакой дополнительной функциональности. Инициатива по обеспечению качества данных обычно имеет сильных сторонников только в том случае, если:

• Существуют проблемы с качеством данных, которые серьезно сказываются на бизнесе.
• Регулирующие органы обеспечивают соблюдение стандартов качества данных (например, BCBS 239 в финансовой сфере).

Обработка DQ аналогична процедуре тестирования при разработке программного обеспечения: если у проекта заканчивается время и/или бюджет, эта часть, как правило, сокращается в первую очередь.

Это, конечно, не вся правда. Хорошая система качества данных помогает обнаруживать ошибки на раннем этапе, тем самым ускоряя процесс предоставления пользователям данных «достаточно хорошего» качества.

Определение терминов

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

Хранилище данных (ХДД)

Хранилище данных (DWH) — это нерабочая система, используемая в основном для поддержки принятия решений. Он объединяет данные операционных систем (всех или меньшего подмножества) и предоставляет оптимизированные для запросов данные для пользователей системы DWH. Хранилище данных должно предоставлять «единую версию правды» внутри предприятия. Хранилище данных обычно состоит из этапов/слоев:

Операционные данные хранятся в основном без изменений на промежуточном уровне . Базовый уровень содержит консолидированные и унифицированные данные. Следующим необязательным этапом является область деривации , предоставляющая производные данные (например, оценку клиентов по продажам) и агрегации. Уровень киоска данных содержит данные, оптимизированные для данной группы пользователей. Витрины данных часто содержат агрегаты и множество производных показателей. Пользователи хранилища данных часто работают только со слоем киоска данных.

Между каждым этапом происходит какое-то преобразование данных. Обычно хранилище данных периодически загружается дельта-извлечениями операционных данных и содержит алгоритмы для хранения исторических данных.

Качество данных

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

Качество данных не означает, что данные должны быть полностью или почти безошибочными — оно зависит от требований пользователей. «Достаточно хороший» подход — хороший выбор для начала. В настоящее время более крупные компании имеют «государственную политику в отношении данных (или информации)», и качество данных является ее частью. Политика управления данными должна описывать, как ваша компания обращается с данными и как она обеспечивает надлежащее качество данных и соблюдение правил конфиденциальности данных .

Качество данных является постоянной темой. Должна быть реализована петля цепи DQ (см. следующую главу). Нормативные требования и правила соответствия также влияют на необходимое качество данных, например, TCPA (Закон США о защите прав потребителей телефонных услуг) или GDPR в Европе по вопросам конфиденциальности, а также отраслевые правила, такие как Solvency II для страхования в ЕС, BCBS 239. и другие для банковского дела и так далее.

Цикл цепи качества данных

Как и в случае со всеми темами качества, DQ — это непрерывная деятельность, предназначенная для поддержания удовлетворительного качества. В результате проекта DQ должна быть реализована петля цепи, аналогичная показанной ниже:

Шаги внутри этого цикла будут описаны в следующих главах.

Роли качества данных

Для успешной реализации инициативы DQ необходимы следующие роли:

• Владелец данных. Владелец данных несет ответственность за качество данных, а также за защиту конфиденциальности данных. Владелец данных «владеет» доменом данных, контролирует доступ и несет ответственность за обеспечение качества данных и принятие мер по исправлению результатов. В крупных организациях обычно бывает несколько владельцев данных. Предметами данных могут быть, например, маркетинговые данные, контрольные данные и т. д. Если в компании существует более одного владельца данных, то должен быть один человек (владелец данных или кто-то еще), ответственный за общий процесс обеспечения качества данных. Владелец данных должен иметь сильные полномочия для обеспечения качества данных и поддержки процесса DQ; поэтому владельцами данных часто являются старшие заинтересованные стороны. Важно хорошее понимание предметной области наряду с хорошими коммуникативными навыками.
• Стюард данных. Распорядитель данных помогает внедрить качество данных на предприятии, помогая пользователям данных в вопросах интерпретации данных/модели данных, проблемах качества данных и т. д. Распорядители данных часто являются сотрудниками владельца данных или могут быть организованы в центре компетенции по качеству данных. или команда DQ. Распорядители данных могут иметь опыт работы в сфере ИТ или бизнеса, но должны знать обе стороны. Аналитические навыки наряду с хорошим пониманием области бизнеса, которую они поддерживают, в сочетании с сильными коммуникативными навыками являются главными предпосылками для успешного управления данными.
• Пользователь данных. Это пользователи хранилища данных, работающие с данными. Пользователи данных обычно работают со слоем киоска данных и несут ответственность за результаты работы с данными. Пользователи данных обеспечивают адекватные проверки качества данных для необходимого им уровня качества. Пользователям данных необходимо четкое понимание своих данных, предметной области бизнеса и необходимые аналитические навыки для интерпретации данных. Разумно найти среди пользователей данных в каждом бизнес-подразделении несколько человек, которые будут отвечать за вопросы качества данных.

Чтобы обеспечить успех, важно, чтобы эти роли были четко определены и широко приняты в вашей организации на ранних этапах вашего проекта DQ. Не менее важно найти на эти роли компетентных специалистов по данным, которые поддерживают проект.

Определите правила

Найдите и внедрите полезные проверки/правила DQ. Определение правил DQ требует хорошего понимания вашего хранилища данных и его использования.

Как найти правила DQ?

Как обсуждалось ранее, пользователи данных (и владелец данных) несут ответственность за использование данных и, следовательно, также за необходимый уровень качества данных. Пользователи данных должны иметь хорошее представление о своих данных, чтобы они могли внести наилучший вклад в полезные правила качества данных.

Они также являются теми, кто анализирует результаты правил качества данных, поэтому всегда полезно позволить им определять свои собственные правила. Это еще больше расширяет возможности проверки и оценки результатов правил DQ, назначенных единице пользователя данных (см. главу «Анализ»).

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

Работа с ошибками

Какие известные ошибки могут возникнуть в хранилище данных?

• Неправильная логика преобразования в хранилище данных
  • Чем сложнее ваш ИТ-ландшафт, тем сложнее может быть логика преобразования. Это наиболее распространенные проблемы DQ, и следствием таких ошибок могут быть «потерянные» данные, дубликаты, неверные значения и т. д.
• Нестабильный процесс загрузки или неправильное обращение с загрузками
  • Загрузка хранилища данных может быть сложным процессом, который может включать ошибки в определении оркестровки заданий (задания начинаются слишком рано или слишком поздно, задания не выполняются и т. д.). Ошибки из-за ручного вмешательства (например, некоторые задания пропускаются, некоторые задания запускаются с неправильной датой выполнения или со вчерашними файлами данных) часто случаются, когда процесс загрузки выходит за пределы диапазона из-за какого-либо сбоя.
• Неправильная передача данных источников данных
  • Передача данных часто реализуется как задача исходной системы. Аномалии или сбои в потоках заданий могут привести к доставке пустых или неполных данных.
• Неверные рабочие данные
  • Данные в операционной системе содержат ошибки, которые до сих пор не распознаны. Это может показаться странным, но в проектах хранилищ данных общеизвестно, что качество рабочих данных часто не видно до тех пор, пока данные не будут включены в DWH.
• Неверная интерпретация данных
  • Данные верны, но пользователи не знают, как правильно их интерпретировать. Это очень распространенная «ошибка», которая не является строго проблемой качества данных, а связана с управлением данными и является задачей распорядителей данных.

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

Параметры качества данных

Измерения DQ — это распространенный способ идентификации и кластеризации проверок DQ. Есть много определений, и количество измерений значительно варьируется: вы можете найти 16 или даже больше измерений. С практической точки зрения проще начать с нескольких измерений и найти общее понимание их среди ваших пользователей.

• Полнота: Все ли требуемые данные имеются и доступны? Все ли необходимые источники доступны и загружены? Были ли потеряны данные между этапами?
• Непротиворечивость: есть ли ошибочные/противоречивые/несогласованные данные? Например, дата расторжения контракта в состоянии «Расторгнут» должна содержать действительную дату, превышающую дату начала контракта или равную ей.
• Уникальность: есть ли дубликаты?
• Целостность: все ли данные связаны правильно? Например, есть ли заказы, связанные с несуществующими идентификаторами клиентов (классическая проблема ссылочной целостности)?
• Своевременность: актуальны ли данные? Например, в хранилище данных с ежедневными обновлениями я ожидаю, что вчерашние данные будут доступны сегодня.

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

• Таблицы с отброшенными данными. В вашем хранилище данных могут быть процессы для пропуска/задержки данных, которые не могут быть загружены из-за технических проблем (например, преобразование формата, отсутствие обязательных значений и т. д.).
• Регистрация информации. Заметные проблемы могут быть записаны в таблицы журналов или файлы журналов.
• Накладная о доставке. Некоторые системы используют «накладные» для данных, предоставляемых операционными системами (например, количество записей, количество отдельных ключей, суммы значений). Их можно использовать для проверки согласования (см. ниже) между хранилищем данных и операционными системами.

Имейте в виду, что каждая проверка качества данных должна быть проанализирована как минимум одним пользователем данных (см. главу «Анализ») на случай обнаружения ошибок, для чего вам потребуется ответственный и доступный человек, который будет следить за каждой реализованной проверкой.

В сложном хранилище данных вы можете столкнуться с множеством (иногда тысячами) правил DQ. Процесс выполнения правил качества данных должен быть надежным и достаточно быстрым, чтобы справиться с этим.

Не проверяйте факты, гарантированные технической реализацией. Например, если данные хранятся в реляционной СУБД, нет необходимости проверять:

• Столбцы, определенные как обязательные, содержат значения NULL.
• Значения полей первичного ключа уникальны в таблице.
• В таблице с включенными проверками реляционной целостности нет существующих внешних ключей.

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

Домашнее хозяйство очень важно. Правила, определенные различными единицами пользователей данных, могут перекрываться и должны быть объединены. Чем сложнее ваша организация, тем больше потребуется хозяйственных операций. Владельцы данных должны внедрить процесс консолидации правил как своего рода «качество данных для правил качества данных». Кроме того, проверки качества данных могут стать бесполезными, если данные больше не используются или изменилось их определение.

Классы правил качества данных

Правила качества данных можно классифицировать в зависимости от типа теста.

• Проверка качества данных. «Обычный» случай — проверка данных в одном уровне хранилища данных (см. рис. 1) либо в одной таблице, либо в наборе таблиц.
• Примирение. Правила, проверяющие правильность переноса данных между уровнями хранилища данных (см. рис. 1). Эти правила в основном используются для проверки измерения DQ «полноты». Согласование может использовать одну строку или обобщенный подход. Проверка отдельных строк гораздо более детализирована, но вам придется воспроизвести этапы преобразования (фильтрация данных, изменение значений полей, денормализация, объединение и т. д.) между сравниваемыми слоями. Чем больше слоев вы пропустили, тем более сложная логика преобразования должна быть реализована. Таким образом, рекомендуется выполнить согласование между каждым уровнем и его предшественником, а не сравнивать промежуточный уровень со слоем витрины данных. Если преобразования должны быть реализованы в правилах согласования, используйте спецификацию, а не код хранилища данных! Для сводного согласования найдите значимые поля (например, суммирование, количество различных значений и т. д.).
• Мониторинг. Хранилище данных обычно содержит исторические данные и загружается дельта-выдержками операционных данных. Существует опасность медленно увеличивающегося разрыва между хранилищем данных и операционными данными. Построение сводных временных рядов данных помогает выявить подобные проблемы (например, сравнение данных за последний месяц с данными за текущий месяц). Пользователи данных, хорошо знающие свои данные, могут предоставить полезные меры и пороговые значения для правил мониторинга.

Как количественно оценить проблему качества данных

После того как вы определили, что проверять, вам нужно указать, как количественно определить выявленные проблемы. Такая информация, как «пять строк данных нарушают правило DQ с идентификатором 15», не имеет большого значения для качества данных.

Отсутствуют следующие части:

• Как количественно определить/подсчитать обнаруженные ошибки. Вы можете подсчитать «количество строк», но вы также можете использовать денежную шкалу (например, экспозицию). Имейте в виду, что денежные значения могут иметь разные знаки, поэтому вам придется выяснить, как осмысленно суммировать их. Вы можете использовать обе единицы количественного анализа (количество строк и суммирование) для правила качества данных.
• Население. Какое количество единиц проверяется правилом качества данных? «Пять строк данных из пяти» отличаются качеством от «пяти из 5 миллионов». Популяцию следует измерять с использованием тех же количественных оценок, что и для ошибок. Обычно результат правила качества данных отображается в процентах. Население не должно совпадать с количеством строк в таблице. Если правило DQ проверяет только подмножество данных (например, только расторгнутые контракты в таблице контрактов), тот же фильтр следует применять для измерения совокупности.
• Определение результата. Даже если проверка качества данных обнаруживает проблемы, это не всегда должно вызывать ошибку. Для качества данных очень полезна система светофора (красный, желтый, зеленый), использующая пороговые значения для оценки результатов. Например, зеленый: 0-2%, желтый: 2-5%, красный: выше 5%. Имейте в виду, что если единицы пользователей данных используют одни и те же правила, они могут иметь очень разные пороговые значения для данного правила. Маркетинговое подразделение может не возражать против потери нескольких заказов, в то время как бухгалтерское подразделение может не обращать внимания даже на центы. Должна быть предусмотрена возможность определения пороговых значений в процентах или в абсолютных цифрах.
• Соберите образцы строк ошибок. Это помогает, если правило качества данных предоставляет выборку обнаруженных ошибок — обычно ключей (бизнес!) и проверенных значений данных достаточно, чтобы помочь исследовать ошибку. Рекомендуется ограничить количество записанных строк ошибок для правила качества данных.
• Иногда вы можете обнаружить «известные ошибки» в данных, которые не будут исправлены, но будут обнаружены с помощью полезных проверок качества данных. В этих случаях рекомендуется использовать белые списки (ключи записей, которые должны быть пропущены при проверке качества данных).

Другие метаданные

Метаданные важны для маршрутизации «Анализа» и мониторинга этапов цикла контроля качества данных.

• Проверенные предметы. Это помогает назначить проверенные таблицы и поля правилу качества данных. Если у вас есть расширенная система метаданных, это может помочь автоматически назначать пользователей данных и владельца данных для этого правила. По нормативным причинам (например, BCBS 239) также необходимо доказать, как данные проверяются DQ. Однако автоматическое назначение правил пользователям/владельцам данных через линию передачи данных (*) может быть обоюдоострым мечом (см. ниже).
• Пользователь данных. В каждом правиле DQ должен быть хотя бы один пользователь данных/подразделение пользователя данных, назначенное для проверки результата на этапе «Анализ» и принятия решения о том, влияет ли результат на их работу с данными и если да, то каким образом.
• Владелец данных. Для каждого правила DQ должен быть назначен владелец данных.

(*) Линия передачи данных показывает поток данных между двумя точками. С помощью наследования данных вы можете найти все элементы данных, влияющие на заданное целевое поле в вашем хранилище.

Использование линии передачи данных для назначения пользователей правилам может быть проблематичным. Как упоминалось ранее, бизнес-пользователи обычно знают только уровень витрины данных (и операционную систему), но не более низкие уровни хранилища данных. При отображении через родословную данных пользователям данных будут назначены правила, с которыми они не знакомы. Для более низких уровней может потребоваться ИТ-персонал для оценки качества данных. Во многих случаях может помочь ручное сопоставление или смешанный подход (сопоставление по происхождению данных только в пределах витрины данных).

Измерение качества данных

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

В идеальном мире хранилище данных будет загружаться только в том случае, если все данные не содержат ошибок. В реальном мире это бывает редко (на самом деле почти никогда). В зависимости от общей стратегии загрузки вашего хранилища данных процесс качества данных должен или не должен (последнее гораздо более вероятно) управлять процессом загрузки. Хорошей схемой является параллельное проведение процессов качества данных (рабочих сетей) и их привязка к «обычным» процессам загрузки хранилища данных.

Если существуют определенные соглашения об уровне обслуживания, убедитесь, что проверки качества данных не мешают загрузке хранилища данных. Ошибки/сбои в процессах качества данных не должны останавливать процесс обычной загрузки. Следует сообщать о непредвиденных ошибках в процессах контроля качества данных и отображать их на этапе «Анализ» (см. следующую главу).

Имейте в виду, что правило качества данных может дать сбой из-за непредвиденных ошибок (возможно, само правило было неправильно реализовано или базовая структура данных изменилась с течением времени). Было бы полезно, если бы ваша система качества данных предоставила механизм деактивации таких правил, особенно если ваша компания выпускает несколько выпусков в год.

Процессы DQ должны выполняться и сообщаться как можно раньше — в идеале, сразу после загрузки проверенных данных. Это помогает обнаруживать ошибки как можно раньше во время загрузки хранилища данных (некоторые сложные загрузки системы хранилища имеют продолжительность в несколько дней).

Анализировать

В этом контексте «анализировать» означает реагировать на результаты проверки качества данных. Это задача назначенных пользователей данных и владельца данных.

Способ реагирования должен быть четко определен вашим проектом по обеспечению качества данных. Пользователи данных должны быть обязаны комментировать правила с выводами (по крайней мере, правила с красным светом), объясняя, какие меры принимаются для обработки выводов. Владелец данных должен быть проинформирован и должен принять решение вместе с пользователем (пользователями) данных.

Возможны следующие действия:

• Серьезная проблема: необходимо устранить проблему и повторить загрузку данных.
• Проблема допустима: попытайтесь исправить ее для будущих загрузок данных и устраните проблему в хранилище данных или в отчетах.
• Дефектное правило DQ: исправьте проблемное правило DQ.

В идеальном мире все проблемы с качеством данных были бы исправлены. Однако нехватка ресурсов и/или времени часто приводит к обходным путям.

Чтобы иметь возможность вовремя реагировать, система DQ должна информировать пользователей данных о «своих» правилах с выводами. Использование панели мониторинга качества данных (возможно, с отправкой сообщений о том, что что-то произошло) — хорошая идея. Чем раньше пользователи будут проинформированы о результатах, тем лучше.

Панель мониторинга качества данных должна содержать:

• Все правила, назначенные данной роли
• Результаты правил (светофор, показатели и примеры строк) с возможностью фильтрации правил по результату и предметной области.
• Обязательный комментарий, который пользователи данных должны ввести для выводов
• Возможность опционального «отмены» результата (например, если правило качества данных сообщает об ошибках из-за дефектной реализации). Если одно и то же правило качества данных назначено более чем одному бизнес-подразделению, «отмена» допустима только для бизнес-подразделения пользователя данных (а не для всей компании).
• Отображение невыполненных или нарушенных правил

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

Владелец данных несет ответственность за то, чтобы каждый вывод был прокомментирован, а статус качества данных (исходный или отмененный) был по крайней мере желтым для всех пользователей данных.

Для быстрого обзора было бы полезно построить своего рода простые KPI (ключевые показатели эффективности) для пользователей/владельцев данных. Иметь общий светофор для результатов всех связанных правил довольно легко, если каждому правилу присваивается одинаковый вес.

Лично я думаю, что вычисление общего значения качества данных для заданной области данных довольно сложно и имеет тенденцию быть каббалистическим, но вы могли бы, по крайней мере, показать количество общих правил, сгруппированных по результату для области данных (например, «100 правил DQ). с 90% зелеными, 5% желтыми и 5% красными результатами»).

Задача владельца данных — гарантировать, что выводы будут зафиксированы, а качество данных улучшено.

Улучшение процессов

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

Владелец данных всегда должен заботиться о следующих моментах:

• Держите его в курсе. Изменения в хранилище данных необходимо фиксировать в системе качества данных.
• Усиливать. Внедрите новые правила для ошибок, на которые еще не распространяются правила качества данных.
• Оптимизация. Отключите правила качества данных, которые больше не нужны. Объедините пересекающиеся правила.

Мониторинг процессов качества данных

Мониторинг всего процесса качества данных помогает улучшить его с течением времени.

На что стоит обратить внимание:

• Охват ваших данных правилами качества данных
• Процент результатов проверки качества данных в рамках активных правил с течением времени
• Количество активных правил качества данных (следите за ним — я видел, как пользователи данных решали свои проблемы, просто отключая все больше и больше правил качества данных).
• Время, необходимое в рамках загрузки данных для оценки и фиксации всех выводов.

Заключение

Многие из следующих пунктов важны для любого проекта.

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

Найдите спонсора. Как отмечалось выше, DQ не является быстро продаваемым товаром, поэтому необходим мощный спонсор/заинтересованное лицо — чем выше в руководстве, тем лучше.

Найдите союзников. Как и в случае со спонсором, любой, кто разделяет идею высокого качества данных, будет очень полезен. Цикл цепи DQ — это непрерывный процесс, и для его поддержания в рабочем состоянии нужны люди.

Начните с малого. Если до сих пор не было стратегии DQ, найдите бизнес-подразделение, которому требуется более высокое качество данных. Создайте прототип, чтобы показать им преимущества более качественных данных. Если ваша задача состоит в том, чтобы улучшить или даже заменить заданную стратегию качества данных, обратите внимание на то, что хорошо работает/приемлемо в организации, и сохраните ее.

Не упускайте из виду всю картину. Хотя вы начинаете с малого, имейте в виду, что некоторые моменты, особенно роли, являются предпосылками для успешной стратегии DQ.

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