Ломай дату полностью: сравниваем подходы к качеству данных у крупных компаний (Lyft, Shopify) на Data Quality Meetup

Привет, Хабр! Современный высокотехнологичный бизнес немыслим без глубокой аналитики и отработки гипотез с помощью ML. Однако это накладывает особые требования на качество данных: все мы знаем, что ерунда на входе = ерунда на выходе. Прекрасно понимая, что стоит на кону у большого бизнеса, мы организовали большой митап, посвящённый подходам к качеству данных в больших компаниях уровня Lyft и Shopify. 

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

Далее краткий пересказ докладов Datafold, Lyft, Shopify и HealthJoy. Текст будет интересен в первую очередь дата-инженерам и тем, кто обеспечивает хранение, предоставление и тестирование данных.

Когда деревья были большими, а данные маленькими и не было машинного обучения, проблема автоматизации контроля не стояла так остро. Сейчас, с развитием ML-технологий и улучшением BI-инструментов, увеличился и объём обрабатываемых данных, и количество отслеживаемых взаимосвязей.

Типичное хранилище данных (DWH) современной компании, вовлечённой в сферу аналитики, состоит из десятков тысяч связанных таблиц, в которых информация растекается каскадами по сложным взаимосвязям. Эти данные ложатся в основу ML-моделей и бизнес-отчётов, на базе которых принимаются стратегические решения. Неверные/неполные данные на входе этих критически важных моделей приведут к неверным решениям.

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

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

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

DATAFOLD [стартап из Кремниевой долины с российскими корнями, организатор митапа, специализируется на мониторинге и тестировании данных]

В докладе Глеб привёл несколько причин, по которым данные могут быть сломаны. Эти причины можно сгруппировать в две категории:

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

   • разработчики изменяют код отслеживания событий (ивент-трекера);

   • поставщики программных решений не соблюдают контракт данных;

   • ломается инфраструктура.

2. Данные собственные, но мы неправильно с ними работаем. Сюда относятся:

   • изменение бизнес-логики обработки данных;

   • изменение самой схемы данных (здравствуй, ночная смена для дата-инженера, стихи, можно сказать);

   • ликвидация части функционала / отказ от дальнейшей поддержки.

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

С точки зрения Datafold, второй подход выгоднее, потому что «лучший способ обеспечить качество данных — это их не портить». Когда неверные данные поступили в работу, ущерб уже нанесён. Вместо того чтобы развиваться, команда занимается поиском ошибок и корневых проблем, при этом «поломки» идут каскадом. 

Как же заботиться о целостности данных ещё до того, как они попали в продакшен? Глеб выделяет три последовательных шага, помогающих не ломать данные.

Шаг первый: версионирование всего, что дотрагивается до данных. Современный стек обработки данных позволяет версионировать весь код, схемы и процедуры обработки, от трекинга до BI. В результате вы можете изолировать проблему, быстро откатить проблемное изменение назад, отслеживать историю изменений. Всё как у взрослых софтверных разработчиков.

Предлагаемые инструменты: трекинг — Avo; DWH — Delta Lake, BigQuery; трансформирование — dbt (о нём чуть подробнее в докладе ниже), Dagster, Airflow; бизнес-аналитика — Looker, Hex.

Шаг второй: оценка влияния. Здесь пригодятся инструменты: 

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

• Data Diff (отслеживание изменений). Данный подход позволяет увидеть, в каких именно данных произошли изменения, и понять, какой процесс мог их поменять. Подход активно используют такие единороги, как Uber, Lyft и др.

  

• Lineage (отслеживание взаимосвязей). При анализе данных бывает полезно понимать родословную данных. Т. е. то, из каких таблиц берутся финальные данные, как появляются данные на предыдущем шаге и так далее.

  

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

LYFT [один из крупнейший агрегаторов такси из США, конкурент Uber, обработка 23 миллионов поездок в квартал до пандемии, анализ данных — критическая составляющая бизнеса]

В настоящий момент под управлением команды Data Platform находятся:

• 110 000 датасетов, 

• 40 петабайт данных, 

• 1100+ пользователей Presto каждый день. 

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

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

 

Система имеет статус DQaaS (Data Quality as a Service — качество данных как сервис). Она позволяет конфигурировать проверки и активно ими управлять. Более того, в системе предусмотрены опосредованные методы проверки качества, к примеру Verity может контролировать количество строк, которые добавляются в таблицу ежедневно с помощью Z-теста, или проверять столбец на уникальность. Тесты конфигурируются с помощью нехитрого DSL (domain-specific language) и управляются через веб-интерфейс. 

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

В завершение Джейсон рассказал, что в последнее время «Лифт» удвоил свои инвестиции в контроль качества данных. В настоящий момент реализовано более 1000 проверок, а над Verity работает 10 продуктовых команд. Процент охвата проверяемых датасетов компании составляет 65 %. К концу года их объём будет доведён до 100 %. 

SHOPIFY [платформа для создания интернет-магазинов, обслуживает около 500 миллионов покупателей, общая выручка за 2020 г. — 3 миллиарда долларов]

В Shopify c данными работают более 200 дата-сайентистов, более 60 инженеров платформы, делается около 100 пулл-реквестов слияний в неделю. Так же как в Lyft, анализ данных является важнейшим процессом, и команде Data Platform были поставлены две задачи: 

1. Демократизировать данные — обеспечить всех пользователей возможностью создавать пайплайны для обработки.

2. Обеспечить контроль качества обрабатываемых данных.

Обе причины обусловили переход на dbt в связке с Google BigQuery. Dbt — фреймворк с открытым исходным кодом, служащий для выполнения тестов и документирования SQL-запросов. На Хабре существует хорошая статья, рассказывающая о его особенностях.

Если вкратце, dbt позволяет:

1. Структурировать SQL-запросы и разложить их по папкам проекта.

2. Ссылаться на другие запросы в SQL-запросах.

3. Упрощать написание SQL-запросов двумя способами: макросы + шаблоны JINJA.

4. Запускать SQL-запросы по расписанию.

Использование dbt позволило Shopify снизить технический порог входа для создания цепочек обработки данных, но для второй задачи —  обеспечения качества данных — штатного фреймворка dbt оказалось недостаточно.

«Из коробки» dbt умеет выполнять простые тесты на уровне столбцов:

Например:

1. Уникальность значений.

2. Отсутствие NULLs.

3. Ссылочная целостность (referential integrity).

Данные тесты, как и тесты Verity у Lyft, выполняются по боевым данным в продакшене или при тестировании изменений (в стейджинге).

 С точки зрения Shopify, данный подход имеет следующие проблемы:

1. Этот способ медленный и дорогой для тестирования при каждом изменении (гоняем десятки тестов по таблицам в миллионы-миллиарды строк).

2. Сложная локализация проблем в редких/пограничных случаях (еdge cases).

Для решения Shopify перешли от прогона тестов по реальным (боевым) данным к тестированию на статических данных. То есть, по сути, к классическим юнит-тестам SQL-кода. Тестирование на статических данных позволяет учесть все крайние случаи, которые, возможно, ещё не запустились в производство. Ну и это значительно дешевле.

Было:

Стало:

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

HEX [Jupyter Notebook на стероидах]

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

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

• SQL-инъекции;

• слишком большие запросы, которые кладут DWH;

• отсутствие правильной авторизации и др. 

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

1. Ограничить ввод возможным списком вариантов на выбор.

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

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

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

HEALTHJOY [агрегатор медицинских услуг, помогающий найти такую медуслугу и по такой стоимости, чтобы её одобрила страховая компания. Звучит немного странно для стран СНГ, но это настоящая головная боль для американцев. Услуги критически зависят от качества данных]

Доклад Алекса был легкой провокацией с заголовком: «Притворяйся, пока не сделаешь, или Обратный подход к работе с данными».

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

В теории логично, но на практике:

1. Заказчик зачастую не знает, что именно ему нужно, и ставит задачу либо слишком широко, либо вообще не ту, что нужна для бизнеса.

2. Часто необходимых данных попросту нет: нет трекинга или объём собранных данных недостаточен.

Поэтому вместо погружения в реальные данные первым делом команда Алекса создаёт прототип на фейковых/неполных данных и показывает результат заказчику (CEO/CFO/продакту и т. д.). Основная цель — получить фидбэк относительно методологии: «Если результат будет выглядеть так — это поможет вам принять решение?». Как правило, уже на данном этапе выявляются критические пробелы в постановке задачи и предпосылках. После нескольких быстрых итераций и утверждения плана действий команда переходит к анализу (или сбору) реальных данных.

Алекс привел два примера, когда такой подход был крайне успешным:

1. При создании модели прогнозирования выручки от подписки (очень много крайних случаев).

2. При разработке фичи, для которой нужны были данные, которых ещё не было.

Что касается бизнеса, HealthJoy исповедуют модель «данные как продукт», а не «данные как сервис». Основная разница состоит в том, что команда аналитики создаёт продукт (фичи, BI-дашборды и т. д.) под ключ, исходя из бизнес-задачи, а не просто выполняет таски (вроде «напиши SQL-запрос, который…»), поставленные другими командами.

Поскольку для HealthJoy данные являются стратегической функцией, в компании плоская структура управления: все инженеры подчиняются непосредственно СЕО. Кроме того, в компании нет чисто аналитиков. Аналитики обладают инженерными скилами и могут сами создавать пайплайны обработки данных и дата-приложения.

Заключение

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

Как видно из докладов, кто-то из крупных игроков разрабатывает собственные решения (вроде Lyft), а кто-то адаптирует опенсорсные решения. В свою очередь мы, Datafold, успешно разрабатываем платформу для наблюдения за данными, и эта работа уже высоко оценена сообществом дата-инженеров. 

Если вам интересна проблема качества данных, мы в Datafold ищем талантливых разработчиков, владеющих английским языком, в нашу распределенную команду, в том числе в России, Европе и СНГ. Описания вакансий здесь.

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