про Data Contracts в подкасте dbt
Chad Sanderson из Convoy (heavy modern data staсk users 🥸) делится своим кейсом: занимаются бизнесом, который truly ML driven, т.е. эм-эль не просто где-то сбоку, а без него не было бы самого бизнеса.
Начали работать, сначала всё шло хорошо, а потом начали появляться сообщения от коллег, что мол в колонках до 25% пропусков, где бизнесово их быть не должно — для обучения моделей приходится вычищать четверть датасета.
И так из других отделов тоже, общий тренд такой, что «мы не доверяем данным». Так начали развивать Data Quality (и до сих пор в этом процессе).
⌘⌘⌘
Ещё раз звучала аналогия, что датасеты (по крайне мере те которые «свои») — это как API. Подразумевается, что нельзя просто так вносить изменения без обратной совместимости.
С другой стороны, разработчики — не демоны. У них нет цели сломать процессы, нижестоящие по пайплайну данных. Они могут быть просто не в курсе, что ИХ ДАННЫМИ пользуется кто-то ещё.
С источниками надо коммуницировать. Причём делать это лучше заранее, а не так чтобы прибегать к ним с криками «ВЫ ЛОМАЕТЕ НАМ ДЕШИ!», когда уже всё сломалось. На это они могут резонно ответить, что типа с чего это вы вешаете продакшен-критичные зависимости без предупреждения, мы не подписывались на это.
Ещё обсуждали, что дата-контракты могут «подписывать» только со стороны источника. Это в ответ на реплику в дбт-шном Слаке, что бывают producer-side и consumer-side контракты. Участники подкаста сходятся в том, что пользователи могут только обвешать входные данные чеками и алертами, но влиять на них не могут.
Ссылки на послушать на сайте подкаста:
https://roundup.getdbt.com/p/ep-34-why-youll-need-data-contracts
#послушано
Post #286
921