https://dropbox.tech/infrastructure/balancing-quality-and-coverage-with-our-data-validation-framework
Любимая шутка в @datajobs это “Ходуб умер”. Вот история от Dropbox, который использует Hadoop в своей аналитике, про что у них происходит в рамках качества данных.
Как обычно, мои мысли после прочтения:
>In the past, different teams at Dropbox had different approaches to validating data, with different standards and different pipelines.
>Dropbox created a dedicated data engineering team to oversee the validation of data in our data lake and to try and catch these problems before they occurred.
Помните шутку про 14 стандартов? Кажется, такая же ситуация. Я считаю, что те, кто данные генерирует, должен быть ответственен за качество генерируемых данных, а не создавать отдельную команду для Data Quality (модная тенденция в энтерпрайзах, появление выделенных Data Stewards, которых, фактически, заставляют быть QA в мире данных, писать тесты, вот это все…)
>When we couldn’t find anything that quite met our needs, we decided to build a solution from scratch
Ребята пишут “Смотрели Great Expectations и dbt, но там для комплексной логики пришлось бы писать SQL”. Поэтому мы решили написать полностью свое! Хороший пример карго-культа. Для любой сложной логики всегда придется что-то допиливать руками, вне зависимости от инструмента. Зачем тогда еще тратить время для создания и поддержки своего собственного тула?
>Our data engineers had experience in SQL, Java, Scala, SchemaPLT, Python, and C, among others, and each had pros and cons. But after much discussion, we chose SQL.
ААААААААААААА. Вы только что выше писали что вам не хочется писать SQL для дополнительной логики!
Справедливости ради, есть одна здравая мысль: последовательность проверок. Очень часто видел ситуацию, когда мы сначала все данные загрузим в прод, потом выполним проверки, и если все хреново - уведомляем пользователей. Тут же, проверки идут поверх стейджа, поэтому в прод говяные данные не попадают.
@ohmydataengineer
Любимая шутка в @datajobs это “Ходуб умер”. Вот история от Dropbox, который использует Hadoop в своей аналитике, про что у них происходит в рамках качества данных.
Как обычно, мои мысли после прочтения:
>In the past, different teams at Dropbox had different approaches to validating data, with different standards and different pipelines.
>Dropbox created a dedicated data engineering team to oversee the validation of data in our data lake and to try and catch these problems before they occurred.
Помните шутку про 14 стандартов? Кажется, такая же ситуация. Я считаю, что те, кто данные генерирует, должен быть ответственен за качество генерируемых данных, а не создавать отдельную команду для Data Quality (модная тенденция в энтерпрайзах, появление выделенных Data Stewards, которых, фактически, заставляют быть QA в мире данных, писать тесты, вот это все…)
>When we couldn’t find anything that quite met our needs, we decided to build a solution from scratch
Ребята пишут “Смотрели Great Expectations и dbt, но там для комплексной логики пришлось бы писать SQL”. Поэтому мы решили написать полностью свое! Хороший пример карго-культа. Для любой сложной логики всегда придется что-то допиливать руками, вне зависимости от инструмента. Зачем тогда еще тратить время для создания и поддержки своего собственного тула?
>Our data engineers had experience in SQL, Java, Scala, SchemaPLT, Python, and C, among others, and each had pros and cons. But after much discussion, we chose SQL.
ААААААААААААА. Вы только что выше писали что вам не хочется писать SQL для дополнительной логики!
Справедливости ради, есть одна здравая мысль: последовательность проверок. Очень часто видел ситуацию, когда мы сначала все данные загрузим в прод, потом выполним проверки, и если все хреново - уведомляем пользователей. Тут же, проверки идут поверх стейджа, поэтому в прод говяные данные не попадают.
@ohmydataengineer