https://dataproducts.substack.com/p/the-rise-of-data-contracts
Сегодня будет горячая для меня тема: контракты данных. Начнем прямо с главного:
*Today, engineers have almost no incentive to take ownership of the data quality they produce outside operational use cases. This is not their fault. They have been completely abstracted away from analytics and ML.*
И это в большинстве случаев правда. Разработчики не особо парятся про то, что происходит с их данными за пределами базы их сервисов. А нам потом с этим работать и недовольный пользователь первым делом кидается какашкой в нас, владельцев платформы.
Рассмотрим пример: есть GDPR процесс, по которому пользователь может у вас запросить удалить все PII данные про него. Разработчики сервиса решают особо не парится, и просто делают все PII данные NULL, потому что им так удобней и проще (их право, их сервис, про других не подумали). А вот то, что потом эти нули приедут в DWH и там поедут метрики и дашборды, не говоря уже про проверки качества. И будем мы бегать и пытаться понять “А тут NULL почему? Потому что у сервиса что-то пошло не так? Или у нас? Или это GDPR?”
P.S. хорошим решением было бы вместо нулей положить что-то в стиле
Дата контракты становятся такой-же важной вещью, как и контракты по API между сервисами, фронтом и беком. Договоренности о том, как нам отдают данные, в каком формате, с использованием простого интерфейса и валидацией на входе - сильно упрощает понимание того, что происходит с данными. Разрабы смогут спокойно работать со своими базами не боясь того, что какие-то изменения у них поломают продакшен.
Напишите в комменты, есть ли у вас data contracts?
@ohmydataengineer
Сегодня будет горячая для меня тема: контракты данных. Начнем прямо с главного:
*Today, engineers have almost no incentive to take ownership of the data quality they produce outside operational use cases. This is not their fault. They have been completely abstracted away from analytics and ML.*
И это в большинстве случаев правда. Разработчики не особо парятся про то, что происходит с их данными за пределами базы их сервисов. А нам потом с этим работать и недовольный пользователь первым делом кидается какашкой в нас, владельцев платформы.
Рассмотрим пример: есть GDPR процесс, по которому пользователь может у вас запросить удалить все PII данные про него. Разработчики сервиса решают особо не парится, и просто делают все PII данные NULL, потому что им так удобней и проще (их право, их сервис, про других не подумали). А вот то, что потом эти нули приедут в DWH и там поедут метрики и дашборды, не говоря уже про проверки качества. И будем мы бегать и пытаться понять “А тут NULL почему? Потому что у сервиса что-то пошло не так? Или у нас? Или это GDPR?”
P.S. хорошим решением было бы вместо нулей положить что-то в стиле
’GDPR_deleted_’ + md5(), флаг is_gdpr_deleted и время манипуляции gdpr_deleted_timestamp.Дата контракты становятся такой-же важной вещью, как и контракты по API между сервисами, фронтом и беком. Договоренности о том, как нам отдают данные, в каком формате, с использованием простого интерфейса и валидацией на входе - сильно упрощает понимание того, что происходит с данными. Разрабы смогут спокойно работать со своими базами не боясь того, что какие-то изменения у них поломают продакшен.
Напишите в комменты, есть ли у вас data contracts?
@ohmydataengineer