Сначала теряется доверие к предоставленной информации. Люди начинают меньше использовать 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
ссылка на оригинал статьи https://habr.com/ru/post/459682/