Команда VK Cloud перевела статью о 15 самых популярных проблемах с Data Quality и способах их смягчения или даже полного избегания.

1. Неполные данные

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

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

2. Значения по умолчанию

Случалось ли вам во время анализа данных найти дату транзакции 01/01/1891? Это как раз случай использования значений по умолчанию — если только у вас в клиентской базе нет тех, кому за сто тридцать. Проблема становится особенно острой, если у вас не хватает документации. 

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

3. Несогласованные форматы данных

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

Решение. Привести в однородный вид, то есть стандартизировать данные в исходной системе. Или хотя бы в пайплайне на этапе, когда данные передаются в озеро или хранилище.

4. Повторяющиеся данные

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

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

5. Несогласованность на уровне систем

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

Решение. Как и в случае с предыдущей проблемой — внедрить управление основными данными, чтобы вся разная информация соответствовала единой записи. Необязательно добиваться абсолютного результата; достаточно указать процент нечеткого соответствия.

6. Кардинальные изменения данных

Представьте себе, что вы каждый день получаете файл с данными — адресами клиентов. Обычно он содержит 5 000 записей, а сегодня только 30. Файл соответствует другим требованиям уникальности, допустимости и точности, и все же данных в нем не хватает. 

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

7. Потерянные данные

Это частный случай проблемы несогласованности, когда данные в одной системе существуют, а в другой — нет. Заказчик есть в таблице A, но его учетной записи нет в таблице B. Это «осиротевший заказчик». С другой стороны, если учетная запись существует в таблице B, но с ней не связан заказчик, это «осиротевшая учетная запись». 

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

8. Нарушения хронологии сохраненных данных

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

Решение. Убедиться, что для определения хронологии используется столбец с корректной датой.

9. Нерелевантные данные

Нет ничего более фрустрирующего, чем сбор ВСЕЙ доступной информации — это дорого и неэкологично.

Решение. Согласовать принципы сбора данных: у каждого атрибута должна быть конечная цель, в противном случае этот атрибут фиксировать не нужно.

10. Неясные определения данных

Поговорите с Сэмом из финансового отдела и с Джесс из службы поддержки клиентов. Они по-разному интерпретируют одну и ту же точку данных — звучит знакомо? Ясность — параметр качества, о котором не так уж много говорят, поскольку в современном стеке данных он относится скорее к терминологии бизнеса или каталога данных. В сущности, это проблема качества.

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

11. Избыточные данные

Разные команды в компании по несколько раз собирают одни и те же данные. Если компания активно присутствует и онлайн, и «на улице»,  из-за неоднократного сбора одной и той же информации данные будут попадать в разные системы. Все это приводит к избыточности, что сказывается не только на рентабельности компании, но и на качестве обслуживания клиентов.

Решение. Использовать единую основную систему, где все представители компании получают данные. Опять же, поможет и управление основными данными.

12. Старые и устаревшие данные

Хранение данных по прошествии определенного времени уже не прибавляет ценности стеку, зато обходится дороже, вносит путаницу в работу дата-инженера и подрывает возможности аналитики, а еще делает данные нерелевантными (см. пункт 9). 

Решение. Применяйте принцип, сформулированный в Общих правилах защиты данных: «Хранить ровно столько, сколько необходимо».

13. Несогласованные ключи

Представьте, что вы создаете новое хранилище данных с первичными и суррогатными ключами для модели Core Data. Хранилище растет, в него каждый день поступают новые данные, в том числе в сезонные пики. И в какой-то момент вы осознаете, что естественные ключи не уникальны. Это открытие подрывает проект модели, нарушая ссылочную целостность.

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

14. Отсутствие доступа к данным

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

15. Данные с опозданием

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

Решение. Согласовать сроки с командой инженеров. Еще имеет смысл вернуться к истокам и убедиться, что исходные системы могут соответствовать этим уровням SLA.

Команда VK Cloud развивает собственные Big Data-решения. Будем признательны, если вы их протестируете и дадите обратную связь. Для тестирования пользователям при регистрации начисляем 3 000 бонусных рублей.

Читать по теме:

• Настоящее и будущее дата-инжиниринга
  
• Hudi, Iceberg и Delta Lake: сравнение табличных форматов для озера данных
  
• Архитектура реальной системы машинного обучения