Качество данных 2
Приветствую, любители аналитики!
Мы разобрались с тем, что такое качество данных и какие бывают метрики для его измерения.
Далее необходимо организовать регулярный автоматический мониторинг качества данных.
То есть, проверку соответствия метрик желаемым значениям.
Например, мы хотим, чтобы данные были как можно более полными. В идеале, чтобы к нам в аналитическое хранилище добралось 100% данных из источника. Но это не всегда возможно. Скажем, данные систем веб-аналитики добираются до нас с каким-то процентом потерь (банально у кого-то стоит на сайте блокировщик Google Analytics).
Короче, аналитики и их заказчики собираются и решают, какой процент потерь допустим, т.е. какое качество считать приемлемым.
Далее можно сравнить количество доехавших данных (т.е. кол-во строк) с предыдущими объемами. Сегодня пришло 1423 строки, а вчера было 1411, а позавчера 1478. Изучив данные за ощутимый период, мы можем выяснить диапазон, в который должно укладываться это самое число строк.
Если оно выходит за пределы диапазона - выдаем предупреждение. Ну, а если пришло ноль строк - это инцидент!
Неконсистентность, то есть, нелогичность данных проверяется по-другому: тут нужно задать конкретные правила консистентности и проверять их. Например, дата активации пользователя в вашем приложении не может быть раньше даты его регистрации.
О том, как мы организовали автоматический мониторинг качества данных, читайте в моей статье.
Приветствую, любители аналитики!
Мы разобрались с тем, что такое качество данных и какие бывают метрики для его измерения.
Далее необходимо организовать регулярный автоматический мониторинг качества данных.
То есть, проверку соответствия метрик желаемым значениям.
Например, мы хотим, чтобы данные были как можно более полными. В идеале, чтобы к нам в аналитическое хранилище добралось 100% данных из источника. Но это не всегда возможно. Скажем, данные систем веб-аналитики добираются до нас с каким-то процентом потерь (банально у кого-то стоит на сайте блокировщик Google Analytics).
Короче, аналитики и их заказчики собираются и решают, какой процент потерь допустим, т.е. какое качество считать приемлемым.
Далее можно сравнить количество доехавших данных (т.е. кол-во строк) с предыдущими объемами. Сегодня пришло 1423 строки, а вчера было 1411, а позавчера 1478. Изучив данные за ощутимый период, мы можем выяснить диапазон, в который должно укладываться это самое число строк.
Если оно выходит за пределы диапазона - выдаем предупреждение. Ну, а если пришло ноль строк - это инцидент!
Неконсистентность, то есть, нелогичность данных проверяется по-другому: тут нужно задать конкретные правила консистентности и проверять их. Например, дата активации пользователя в вашем приложении не может быть раньше даты его регистрации.
О том, как мы организовали автоматический мониторинг качества данных, читайте в моей статье.