Качество данных в хранилище

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

Ответственность за качество данных

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

Корпоративная культура

• Заинтересованы ли сами работники в производстве хорошего качества?
• Если нет, то почему? Может быть присутствует конфликт интересов.
• Может быть есть корпоративные правила, которые определяют ответственных за качество?

Процессы

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

За качество данных в отчётных системах ответственны все в организации.

Определение и значение

Качество — это подтверждённое удовлетворение ожиданий клиента.

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

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

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

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

Улучшение качества данных

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

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

Инструменты

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

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

Совет

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

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

Пример

Запрос написан для базы Oracle. В данном примере тесты возвращают числовое значение, которое можно нужным образом интерпретировать. Значениями T_MIN и T_MAX можно регулировать степень тревоги. Поле REPORT когда-то использовалось как сообщение в комерческом ETL продукте, который не умел достойно отправлять емейлы, поэтом rpad — это «костыль».

В случае большой таблицы можно добавить, например, AND ROWNUM <= 10, т.е. если набралось 10 ошибок, то этого достаточно для тревоги.

CREATE OR REPLACE VIEW V_QC_DIM_PRODUCT_01 AS
SELECT
  CASE WHEN OUTPUT>=T_MIN AND OUTPUT<=T_MAX
  THEN 'OK' ELSE 'ERROR' END AS RESULT,
  DESCRIPTION,
  TABLE_NAME, 
  OUTPUT, 
  T_MIN,
  T_MAX,
  rpad(DESCRIPTION,60,' ') || rpad(OUTPUT,8,' ') || rpad(T_MIN,8,' ') || rpad(T_MAX,8,' ') AS REPORT
FROM (-- Test itself
  SELECT
    'DIM_PRODUCT' AS TABLE_NAME,
    'Count of blanks' AS DESCRIPTION,
    COUNT(*) AS OUTPUT,
    0 AS T_MIN,
    10 AS T_MAX
  FROM DIM_PRODUCT
  WHERE DIM_PRODUCT_ID != -1 -- not default value
  AND ATTRIBUTE IS NULL ); -- count blanks

В публикации использованы материалы книги
Ronald Bachmann, Dr. Guido Kemper
Raus aus der BI-Falle
Wie Business Intelligence zum Erfolg wird

Источник: habr.com