В прошлом уроке мы говорили про загрузку данных из источников в хранилище (ETL) и уже упомянули вопрос качества данных.

ETL процесс отработал идеально, если:

• В хранилище загрузилось ровно столько данных, сколько пришло из источника
• Данные не исказились в процессе выгрузки-загрузки (например, мы не перепутали форматы)
• Данные выгрузились и загрузились по расписанию

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

Сегодня мы поговорим про другой аспект качества данных — бизнес-качество.

И снова про качество

Предположим, что у нас идеально настроен ETL-процесс.

Мы точно знаем, когда система-источник заканчивает расчет таблиц и готова отдавать нам данные. Расчет на источнике закончился по расписанию. Мы забрали данные из источника. У нас не произошло никаких сбоев при транспортировке данных по сети. Данные в полном объеме загрузились в хранилище. Мы посчитали все контрольные суммы, выполнили все проверки и все индикаторы системы-мониторинга контроля качества данных горят зеленым цветом. При этом база у нас не упала, все таблицы целые, ссылки не нарушены и технических дублей по Primary Key нет. С техническим качеством данных все идеально.

Но в этот день на работу вышел стажер. И он целый день вносил в систему-источник данные с ошибками. Например, он мог иногда путать поля «Имя» и «Фамилия», вносить суммы с НДС, там, где нужно без НДС, не заполнял некоторые поля, потому что не знал, как, а еще у него была тройка с минусом по русскому языку, и он страдает хронической невнимательностью. Он сделал миллион грамматических ошибок и миллиард опечаток. Его куратор был занят подготовкой к совещанию и не проверил результат работы в конце дня. В итоге все данные оказались в хранилище. Можно ли считать эти данные качественными?

На самом деле этот вопрос не риторический — на него нет однозначного ответа.
Все зависит от задачи, для которой мы собираемся использовать данные.

Рассмотрим на примере:

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

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

Задача 2: Но если мы подаем отчет в налоговую, то эта допустимая погрешность будет гораздо меньше. Мы уже не можем не посчитать канцелярию и воду для кулера. Если мы ошибемся в нашем отчете для налоговой даже на 1 рубль, то нам придется сдавать уточнения.

Поэтому для одной задачи расходы, забитые в Excel с округлением до 1 тысячи рублей могут быть качественными, а для другой задачи — такие данные не подходят, а качественными данными будут расходы с точностью до копейки из 1С: Бухгалтерия.

Качество данных — характеристика, которая показывает на сколько данные в их текущем виде могут решить нашу задачу. Если данные могут решить нашу задачу — значит они качественные, если не могут — значит не качественные.

Как мы и говорили в начале этой части — не бывает 100% идеальных данных.

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

В следующей части нашего лонгрида поговорим, про инструменты, которые позволяют управлять качеством данных в системах-источниках и в хранилище — профилирование, MDM и DataGovernance.

У вас могут быть самые идеальные данные.

Но если пользователи не знают, как их найти, как получить к ним доступ и как ими воспользоваться. Можно сказать, что качество данных нулевое — данных для пользователей просто нет.

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

Для того, чтобы решить эту проблему, компании внедряют инструменты DataGovernance — решения для документирования и поиска данных.

6. И еще один важный критерий качества данных — доступность

Данные могут быть полными, точными, согласованными и валидными. Но доставленными с опозданием, или наоборот слишком рано.

Например, если клиент поменял свой номер телефона, а у курьера, который уже доставляет заказ, старые контактные данные — такие данные не качественные для этой задачи. Данные запаздывают. Значит они не валидны.

С другой стороны, если мы забрали данные из платежной системы раньше, чем закончился отчетный период, то не все платежи попали в наш квартальный отчет. Это тоже не своевременно — данные не полны.

Своевременность — критерий качества данных, который может снижать другие характеристики качества.

Данные могут быть не валидными, если они не соответствуют заданному формату, не соответствуют разумному представлению о действительности или не корректны.

Например, при вводе данных в форму легко проверить формат e-mail адреса, формат телефона или даты. Но нельзя автоматически проверить, что данные корректны. Если записали некорректный телефон и почту, то сложно будет связаться с клиентом. Поэтому часто компании просят подтвердить почту, перейдя по ссылке, и мобильный телефон по СМС.

Также для проверки валидности данных часто вводятся диапазоны значений. Например, возраст можно ограничить диапазоном от 0 до 100.

Кроме того, данные могут быть не корректны, если содержат ошибки и опечатки. Опечатка в ФИО может превратить одного человека в другого, а опечатка в адресе может запутать курьера. А технические сбои могут превратить данные в мусор.

В таблице мы привели разные примеры не валидных данных. Найдете их самостоятельно?

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

Это пример не согласованных данных — в одной системе клиент записан «Петр», а в другой «Пьер». Как к нему обращаться в письма, СМС и во время звонков?

Для согласованности такой информации внутри компаний разрабатываются целые процессы — клиент имеет право ошибиться при вводе своего имени, имеет право поменять имя, телефон и адрес. С этим работают системы класса CDI — Customer Data Intagration.

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

Этот критерий требует, чтобы данные не противоречили друг другу.

Обратимся к нашей любимой таблице с клиентами.

У нас есть поле «адрес». В одном случае адрес указан с точность до квартиры, в другом — до дома.

Если у Петра Иннокентьевича частный дом, то данные точные. Но подобный формат записи адреса не позволяет сделать 100% вывод. И если это адрес в многоквартирном доме, то такая точность не позволит их использовать для некоторых задач. Например, для доставки корреспонденции почтой.

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

Точность данных обычно также контролируется на уровне интерфейса ввода информации.

Рассмотрим ту же самую таблицу с данными о клиентах

Данные будут полными, если:

• Присутствуют все данные о заказах — у нас не произошел сбой на сайте, и не потерялись какие-то заказы
• У нас есть все данные — и ФИО, и телефон, и e-mail, и адрес, и сам заказ.

Если эти условия соблюдены, то данные будут полными на 100%. Если где-то не заполнены ФИО, где-то телефон, где-то почта — то процент полноты будет снижаться.

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

Например, у нас есть таблица данных о клиентах, подавших заявки на сайте:

Нужно понимать — не бывает 100% идеальных данных. Даже в данных, которые собираются с датчиков и IoT устройств, встречаются ошибки. Например, датчики могут мерить температуру и влажность с определенной погрешностью. А в данных, которые вносят люди руками, ошибки будут всегда.

Чтобы работать с качеством данных и предъявлять требования к качеству, нужно понимать, что это такое. Давайте разберемся с основными критериями качества данных.

Можно сказать, что инструменты профилирования — это набор тестов, которые проверяют данные на соответствие заданным правилам:

• Соответствие пороговым значениям (возраст, сумма, количество)
• Соответствие формату (даты, телефоны, e-mail)
• Соответствие справочникам (пол, образование)
• Наличие пустых значений (заполнение поле ФИО)
• Зависимость атрибутов (дата рождения раньше, чем дата выдачи паспорта)

Также тесты профилирования данных могут выявлять аномалии.

Например, среднее количество заказов в наших офисах продаж — 100 штук в день. Если к нам приходят данные с количеством продаж — 2000 в одном из офисов, это повод уделить таким данным дополнительное внимание. Возможно, это результат эффективной рекламы, а возможно ошибка в данных.

Кроме того, тесты профилирования могут реагировать на граничные значения.

Если у нас установлен лимит на текстовое поле — 100 символов, и у нас есть записи в 100 символов — возможно часть текста не поместилась и была утеряна. Это повод увеличить длину поля и перезалить данные.

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

Что делают с данными, когда в них нашли ошибки после профилирования?

Какие-то данные можно исправить автоматически, например, сменить формат, или до обогатить данные из других источников. Например, если у нас потерялся индекс у адреса — эту задачу решить легко.

Какие-то ошибки потребуют изменения систем-источников. Например, доработки интерфейса сайта — чтобы адрес выбирался из справочника, или на карте.
Какие-то ошибки можно исправить по словарям и справочникам. Если в адресе написали «Масква» вместо «Москва» — это легко поправить алгоритмом. Но с именами и фамилиями так поступить не получится (Наталья и Наталия — это разные люди) и большинство ошибок все-таки придется исправлять вручную. Большая часть из них так и останется не исправленной.

Цель инструментов профилирования — не улучшить качество на 100%, а отслеживать текущее состояние качества данных, сигнализировать об ухудшении качества данных, отслеживать причины и помогать итеративно улучшать качество данных. Точнее поддерживать качество на приемлемом уровне.

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

Цель справочников — сократить количество ошибок при вводе данных в систему. Если мы вводим данные вручную, то количество вариантов написания даже самого простого понятия велико. В графе пол можно написать: «мужской», «м.», «м», «муж», «МУЖ», «муж-й». А если дело касается адреса — вариантов столько, что тысячам почтальонов приходится несладко.

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

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

Рассмотрим это на простом примере.

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

Так и работают MDM системы — есть «мастер запись» продукта в MDM, есть справочники в других системах с записями о том же продукте, которые могут называться по-другому, но они связаны по ключу и все системы могут общаться, и понимать друг друга однозначно.

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

MDM (Master Data management) — система управления нормативно-справочной информацией.

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

• Что это за данные?
• Когда они обновлялись?
• За какой период они есть?
• Насколько они полные?
• В каком формате они лежат?
• Какая система их произвела?
• В каких отчетах и процессах используются?
• Кто с ними работает напрямую?
• Содержат ли они персональные данные, соответствуют ли законам?
• Кто за них отвечает?

Инструменты DataGovernance позволяют пользователям найти ответы на вопросы:

Системы DataGovernance используют технические специалисты и бизнес-пользователи.

Для технарей DataGovernance — инструмент для документирования (ведения метаданных) по отчетам, витринам, исходным данным из систем-источникам и другим инфосервисам. Обычно инструменты DataGovernance позволяют загружать и техническую мета-информацию (когда загружены данные, какие атрибуты они содержат, статус проверок контроля качества и др.), и вводить описание в бизнес-терминах.

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

Для бизнес-пользователей DataGovernance — удобный интерфейс для поиска данных и инфосервисов, способных решить бизнес-задачу. Это единая точка входа, в которой можно быстро найти все данные компании, даже если они реализованы в разных инструментах и разными командами.

Какую информацию обычно содержат инструменты DataGovernance?

Информацию о трансформациях и преобразованиях данных (Data Lineage). Описания потоков данных на физическом уровне — от источника до слоев хранилища. Как преобразовывались типы? Какие именно таблицы и атрибуты загружались? Какие формулы и алгоритмы использовались для расчета?

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

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

Повысить качество данных один раз — не сложно. О технических подходах к работе с качеством данных мы говорили в этом уроке. Нужно провести профилирование, найти ошибки и исправить.

Если мы после этого закроем все системы-источники, то сможем повесить на хранилище табличку — 100% качественные данные.

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

Как можно повысить качество данных?

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

От качества клиентских данных напрямую зависит количество продаж — если мы не сможем связаться с клиентом из-за ошибки в номере телефона, значит мы не сможем продать ему услуги.

А за качеством финансовых данных пристально следит налоговая и акционеры. Если мы не смогли учесть какие-то затраты, или поступления денежных средств — это большая проблема. Это может грозить штрафами и репутационными рисками.

Качество каких данных чаще всего повышают?

Дедубликация — процесс удаления дублей. Этот процесс может быть простым и автоматическим. Когда мы находим записи, которые совпадают на 100% мы можем оставить только одну, а вторую удалить.
Но чаще дедубликация — это сложный процесс. Большая часть записей будет похожа на свои дубли не на 100%, а чуть меньше — 60−90%. Принимать решение, что делать с записями, придется экспертам.

Наверняка у каждого была ситуация, когда вы пытаетесь скопировать в папку файл, а система вам сообщает — файл с таким названием уже есть. Если файлы полностью совпадают по размеру, дате последнего изменения, и последнему редактору — это дубли на 100%.

Если файлы чем-то отличаются, то их нужно предварительно сравнить и принять решение — оставить обе версии файла, объединить файлы в один, или оставить только один файл, а другой удалить.

Что такое дедубликация?

Данные в БД хранят в нормализованном виде (3-я нормальная форма) — в виде набора связанных таблиц, чтобы избежать дублирования и избыточности информации. Мы уже говорили про это в предыдущих лонгридах. Чтобы связывать таблицы друг с другом — клиента с его заказами, менеджера с его продажами — используются ключи.

Ключи (можно представить, как последовательность целых чисел) — создаются алгоритмами. Случается, что алгоритмы дают сбой и создается две записи с одинаковым ключом. Это нарушает целостность данных и создает ошибки при работе с таблицами. Такая неприятная ситуация и называется дубли по Primary Key.

Что такое дубли по Primary Key?

Что такое дубли?

Дубли — это информация об одном и том же объекте или событии, которая занесена в справочник несколько раз.

Например, в компанию мог позвонить клиент с разных телефонных номеров, и разные операторы могли занести его ФИО и контактные данные в клиентскую базу. Если мы будем создавать справочник клиентов, и выгрузим несколько карточек одного и того же клиента с разными номерами — это будут дубли.

В итоге должна остаться одна карточка клиента с его ФИО и всеми известными контактными данными.

Рубрика: 5 вопросов от джуна