Качество данных в хранилище является важной предпосылкой к получению ценной информации. Плохое качество ведёт к негативной цепной реакции в долгосрочной перспективе.
Сначала теряется доверие к предоставленной информации. Люди начинают меньше использовать 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