Фабрики данных производят разнообразные продукты данных для различных внутренних и внешних клиентов, но качество этих продуктов зависит от качества данных, пишет на портале The New Stack Джереми Стэнли, соучредитель и технический директор компании Anomalo.

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

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

  • Производит ли фабрика высококачественные продукты данных?
  • Сколько стоит содержание фабрики?
  • Как быстро можно адаптировать фабрику к изменяющимся потребностям клиентов?

Облачные хранилища данных, такие как Redshift, Snowflake, BigQuery и Databricks, позволили снизить эксплуатационные расходы на фабрику данных. Инструменты оркестровки типа Airflow и фреймворки для преобразования данных, такие как dbt, упростили перепроектирование ее компонентов. Но из виду часто упускаются проблемы с качеством данных, что приводит к неверным решениям и некачественному продукту. Или же конечные пользователи обнаруживают их в последний момент, что приводит к спешке и подрыву доверия.

Приоритеты контроля качества данных

Чтобы контролировать качество данных на нашей условной фабрике, мы можем проводить тестирование в четырех точках:

  • Сырье, которое поступает на нашу фабрику;
  • Производительность машин на каждом этапе линии;
  • Обрабатываемый материал, который передается между этапами преобразования;
  • Конечная продукция, которую мы отправляем внутренним или внешним клиентам.

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

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

  • Вносятся ли дубликаты строк?
  • Приводит ли неправильно сформированный столбец к отсутствующим значениям?
  • Записываются ли временные метки непоследовательно?
  • Влияет ли изменение логики запроса на бизнес-метрики?

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

Недостаточные инвестиции

К сожалению, до сих пор большинство тестирований фабрик данных эквивалентно оценке производительности машин или визуализации планов этажей:

  • Контроль инфраструктуры данных на предмет времени безотказной работы и быстроты реакции;
  • Отслеживание задач Airflow на предмет исключений и времени выполнения;
  • Применение тестов на основе правил с помощью dbt для проверки логики преобразований;
  • Анализ истории данных, чтобы построить сложные карты фабрики данных.

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

  1. Мы используем те инструменты, которые у нас есть под рукой. Инженерные команды имеют надежные инструменты и лучшие практики для мониторинга работы веб- и бэкенд-приложений. Мы можем использовать их для мониторинга инфраструктуры и оркестровки нашей фабрики данных. Однако эти инструменты не способны контролировать сами данные.
  2. Мы поручили контроль за качеством данных операторам машин. Бремя контроля качества данных часто ложится на плечи инженеров по данным и аналитикам, обслуживающих машины на фабрике. Они являются экспертами в инструментах и логике, используемых для преобразования данных. Они умеют писать тесты, чтобы убедиться в правильности своих преобразований, но они могут упустить из виду проблемы, возникающие при обработке данных выше или ниже по течению.
  3. Хорошо протестировать данные сложно. Фабрики данных предприятий генерируют тысячи невероятно разнообразных таблиц данных с сотнями значимых столбцов и сегментов. Данные в них по разным причинам постоянно меняются — от «ожидаемых» до «совершенно не зависящих от нас». Упрощенные стратегии тестирования часто упускают реальные проблемы, а сложные стратегии трудно поддерживать. Плохо откалиброванные тесты могут засыпать пользователей ложно- положительными предупреждениями, что приводит к усталости от предупреждений.

Что нужно для контроле качества данных

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

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

Будущее качества данных

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

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

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