В нашем мире проблемы с данными делятся на два типа: предсказуемые (известные неизвестные) и непредсказуемые (неизвестные неизвестные). Вот какой комплексный подход применяют лучшие специалисты по работе с данными для решения этих проблем в крупномасштабных системах. Команда VK Cloud Solutions перевела статью о новых способах повышения качества данных с помощью тестирования и наблюдаемости (observability).
Ситуация с Data Quality
В последние годы команды по анализу данных стали использовать аналог юнит-тестирования для обнаружения проблем с качеством данных. В 2021 году на фоне все увеличивающегося потока обрабатываемых данных пайплайны становятся сложнее, — и подход, основанный на выявлении единой точки отказа, перестал работать.
Тестировать самые важные данные надо — без этого нельзя выявить конкретные, лежащие на поверхности известные проблемы в пайплайне. Для этой задачи есть прекрасные инструменты. Например, данные из того же Segment или Salesforce извлекаются с помощью Fivetran, поступают в хранилище данных Snowflake, трансформируются с помощью dbt и в конечном счете оказываются на дашборде Looker, который ваш CEO использует для просмотра квартальных финансовых отчетов. Сразу же, без всяких проверок.
Но даже если вы автоматизировали тестирование, у вас все равно остается немало задач: обновлять имеющиеся тесты и пороговые значения, писать новые и удалять старые — потому что экосистема данных развивается, а данные меняются. Со временем этот процесс становится утомительным, занимает все больше времени и приводит к образованию технического долга, по которому придется расплачиваться позже.
Одна заказчица из компании, занимающейся онлайн-торговлей, — назовем ее Ребекка — рассказала мне, что в свое время команда дата-инженеров выявляла проблемы с данными в критически важных пайплайнах исключительно с помощью пользовательских тестов… а потом вдруг перестала.
Ребекка и ее команда крайне тщательно тестировали все свои пайплайны, но хватило всего одного случая (неизвестное неизвестное, а именно аномальное распределение данных), чтобы отправить компанию в пике (или в штопор). Дела в компании рухнули. Они потеряли прибыль на транзакциях, которые не могли обработать, и руководство утратило доверие к данным.
Ее команда могла отследить известные неизвестные («Мы знаем, что здесь может быть проблема, давайте это проверим»), но у них не было комплексного подхода к поиску неизвестных неизвестных.
Неизвестные неизвестные в пайплайне данных
Неизвестные неизвестные — это проблемы с Data Quality, которые нельзя предсказать. Они чаще проявляются через влияние на работу систем, следующих за ними в технологической цепочке, — и к этому моменту ваш бизнес, скорее всего, уже понес убытки.
Неизвестные неизвестные — это недоступность данных, которая не объясняется даже наиболее полным тестированием, проблемы, возникающие во всем пайплайне данных, а не только в разделах, которые можно проверить конкретными тестами. Например:
-
Аномальное распределение в критически важном поле, из-за которого возникает сбой в работе дашборда Tableau.
-
Сделанное другой командой изменение JSON-схемы, из-за которого 6 столбцов превращаются в 600.
-
Случайное изменение ETL (или, если вам угодно, Reverse ETL), из-за которого перестают выполняться тесты и, соответственно, не выявляются плохие данные.
-
Неполные или устаревшие данные, которые удается заметить только через несколько недель, когда они уже повлияли на ключевые маркетинговые метрики.
-
Изменение кода, из-за которого API перестает собирать данные, необходимые для важного нового продукта.
-
Трудновыявляемые дрейфы данных во времени. Особенно если тесты охватывают только данные, записываемые в момент выполнения ETL, без учета данных, уже находящихся в таблице.
И это только верхушка айсберга. Так что же делать, чтобы эти неизвестные неизвестные не ломали идеально настроенные пайплайны?
Так же, как разработчики приложений не ограничиваются только модульным и комплексным тестированием, чтобы обнаружить код с ошибками, так и дата-инженерам нужно перенять похожий подход, превратив Data Observability (наблюдаемость данных) в ключевой компонент стека.
Новый подход к Data Quality
Как и в случае с программным обеспечением, для стабильной надежности данных нужны и тестирование, и наблюдаемость. Фактически современные команды по работе с данными должны относиться к данным как к динамичной, постоянно меняющейся сущности, и применять скорее непрерывное наблюдение, а не скрупулезное тестирование. Данные могут «выходить из строя» миллионами разных способов (вот они, «неизвестные неизвестные»), так что для этих крайних случаев можно применять те же DevOps-принципы.
Наблюдаемость данных помогает выявить неизвестные неизвестные благодаря:
- автоматическому мониторингу;
- правилам на базе машинного обучения;
- масштабируемой проверке качества всего стека данных;
- отказу от настроек пороговых значений вручную.
Вот что включает в себя надежный комплексный подход к наблюдаемости данных:
-
Агрегирование и каталогизация метаданных. Если вы не знаете, какие данные у вас есть, откуда вам знать, полезны ли они? Каталоги данных часто встраивают в современные платформы наблюдаемости, которые обеспечивают централизованное прозрачное представление экосистемы данных. На таких платформах на единой панели видна полная информация о lineage, схеме, истории изменений, объеме данных, пользователях, запросах и многом другом.
-
Автоматический мониторинг и оповещение о проблемах с данными. Благодаря современному подходу к наблюдаемости данных вы первым будете узнавать о проблемах с данными и решать эти проблемы. Теперь вы сможете устранять недоступность данных сию же минуту, а не несколько месяцев спустя. Плюс ко всему, для такого решения требуется минимум конфигурирования и настройки пороговых значений.
-
Lineage для отслеживания зависимостей по всей траектории движения. Благодаря комплексному надежному подходу к lineage команды по работе с данными могут отслеживать всю траекторию движения данных от приема до аналитики, по которой они проходят трансформацию, моделирование и прочие этапы.
-
Пользовательские и автоматически генерируемые правила. Большинству команд по работе с данными нужен подход, вобравший в себя основные преимущества разных методов работы: и с помощью машинного обучения выявлять аномалии данных, основываясь на истории их изменений, и задавать правила с учетом уникальных характеристик данных. В отличие от ad-hoc-запросов, встроенных в пайплайны, или SQL-оберток такой мониторинг не ограничивается формулировками «Сегодня значения в поле T таблицы R ниже, чем в S».
-
Совместная работа аналитиков, дата-инженеров и дата-сайентистов. Специалисты по работе с данными должны быть готовы в любой момент решать проблемы, задавать новые правила и разбираться с состоянием данных.
Каждая команда аналитиков уникальна. И все же мы обнаружили, что этот подход к тестированию и наблюдаемости помогает справиться с наиболее вероятными проблемами с данными, а еще — с миллионами других причин «сломанных» пайплайнов.
Команда VK Cloud Solutions развивает собственные Big Data-решения. Будем признательны, если вы их протестируете и дадите обратную связь. Для тестирования пользователям при регистрации начисляем 3 000 бонусных рублей.
Что почитать по теме:
korjavin
О чем статья?