Представьте, что у вас только что появилось классное озеро данных с прикольными пайплайнами, которые собирают данные со всей компании. А теперь представьте свой шок, когда команды бизнес-специалистов поймут, что в озере данных — не данные, а мусор.
Команда VK Cloud перевела статью о том, как следить за данными на каждом этапе и повысить их качество для грамотного использования.
1. Сбор данных
Это первая линия обороны: сотрудники магазинов, колл-центров или службы поддержки, формы онлайн-регистрации или бумажные документы, данные с которых сотрудники вручную вводят в ваши системы. Как бы компания ни собирала данные от клиентов, крайне важно, чтобы на этом этапе они были полными, уникальными и допустимыми.
Правильный сбор в три-четыре раза экономит силы на корректировку на следующих этапах. Так что обратите внимание на следующие параметры качества данных:
- Полнота. Данные, которые вы собираете, являются полными (не содержат значения NULL). Информация добавлена во все обязательные поля и не теряется ни в каких ключевых точках данных.
- Уникальность. Стремитесь обеспечить максимальную уникальность данных. Например, если у клиента уже есть учетная запись, не заводите ему вторую. Если в системе уже есть этот номер мобильного, текущий заказ привязывается к предыдущим заказам, и так далее.
- Допустимость. Собираемые данные соответствуют корпоративным стандартам. Например, номер учетной записи состоит из восьми цифр и начинается с 9, что соответствует стандартам, действующим на момент сбора данных.
2. Передача данных
Инженерам всегда нужно помнить о том, откуда и куда они передают данные. Для бизнеса неважно, происходит ли передача данных в составе процесса ETL или просто в виде файла. Не каждый механизм передачи данных может проверить их полноту и допустимость. Но эти инструменты должны проверять их согласованность.
Согласованность. Во всех таблицах должны содержаться согласованные данные с одними и теми же значениями. В результате в источнике и точке назначения данные не должны быть противоречивы: если 100 записей отправлено, то 100 записей получено. Или если в таблице содержатся конкретные значения вроде даты рождения, в ней не должно быть противоречий с другими таблицами, в которых содержится такая же или похожая информация. Потерянные записи, которые есть в A, но нет в B, должны подсвечиваться, отслеживаться и исправляться.
3. Хранение данных
Независимо от того, что ждет данные — преобразование или использование, — они проведут большую часть своей жизни именно на этом уровне. Как только данные поступили на хранение, о них забывают до тех пор, пока они не понадобятся для конкретного использования в дальнейших операциях. Разумно потратить это время и заблаговременно повысить качество данных, чтобы избежать паники, когда сроки начнут поджимать.
Сосредоточьтесь на следующих критически важных параметрах данных:
Полнота. Сколько столбцов содержат значение Null и почему? Можно ли изменить процесс сбора данных, чтобы исправить положение дел?
Уникальность. Уникальны ли необязательные атрибуты? Повлияют ли дублирующиеся данные на отчетность на дальнейших этапах?
4. Преобразование данных
Переходим к пайплайнам данных и процессам ETL. На этом этапе в данные вносят изменения: добавляют агрегаты и счетчики, увеличивают степень детализации посредством нормализации. В этой фазе довольно трудно поддерживать адекватный lineage данных.
В идеале качество данных должно быть приемлемым еще до создания пайплайна. Но в реальной жизни такое случается достаточно редко. Большую часть времени на этапе пайплайна происходит именно работа с качеством данных.
Вот на что нужно обратить внимание:
- Актуальность. Нельзя выполнить пайплайн без актуальных данных, так что критически важно оперативно обеспечивать доступность данных в соответствии с оговоренными SLA.
- Согласованность. Для этого нужна сверка данных в источнике и точке назначения, в том числе с помощью интеллектуального анализа данных. Возьмем для примера проверки допусков для обрабатываемых таблиц: обычно мы получаем 100 записей, а сегодня получили только две. Как оповестить пользователя об этом расхождении?
- Допустимость. Прежде чем запустить дорогостоящий пайплайн данных, разумно проверить допустимость данных. Если они не соответствуют требованиям допустимости, их преобразование и последующее использование могут оказаться бесполезными. Это особенно важно, если на этапе сбора данных не применялись надежные средства контроля.
5. Использование данных
На этом уровне на первый план выходит ценность данных для бизнеса. Все, что делалось ранее, — это просто их подготовка для этого этапа. Чтобы убедиться, что данные решают поставленную бизнес-задачу, на этом уровне имеет смысл проверить два критически важных параметра качества:
- Точность. В отчетность попадают достаточно точные данные, например, метрики для отчетов для руководства. Номера аккаунтов связаны с правильными сегментами клиентов, а дата рождения отличается от значения по умолчанию 01/01/1901.
- Актуальность. Данные доступны на момент подготовки отчетности. Они не устарели и включают последние записи. Они поступили без задержки, угрожающей сорвать оговоренные сроки. Все согласованные SLA должны соблюдаться, чтобы на этапе использования данные были доступны в нужный момент и подходили для решения конкретных задач.
Заключение
Качество данных характеризуется такими параметрами как релевантность, соответствие требованиям и целостность. Однако я рекомендую применять перечисленные проверки на разных этапах: так вы получите максимум пользы за потраченные деньги. Возможно, осознав эти преимущества, вы решите скорректировать выбранную стратегию.
Команда VK Cloud развивает собственные Big Data-решения. Будем признательны, если вы их протестируете и дадите обратную связь. Для тестирования пользователям при регистрации начисляем 3000 бонусных рублей.