data будни

🥴 Reverse ETL — антипаттерн или норм?

у меня тут недавно наконец-то сложилась картинка в голове! до этого краем уха слышал этот новый термин, но никак не мог переложить его на реальность. А потом увидел схемку где помимо стандартного направления

источник → двх

была дополнительная стрелочка:

источник → двх → (обратно) источник

в итоге понял, что видел уже два таких кейса и пока ощущения смешанные:

1) считать бонусы определённому срезу сотрудников. был кейс когда ставка зависит от количества и статуса лидов например (или других штук, которые можно посчитать только в двх)

2) сейчас есть задача передавать данные между микросервисами (разные команды): микросервис А производит данные, их сгружаем в ДВХ, там происходит очистка и обогащение; а потом мы эти данные выгружаем в микросервис Б.

по второму кейсу не покидает ощущение «наколеночности» решения: получается, между двумя по-задумке-быстрыми сервисами появляется прослойка в виде батчевого двх с куском логики. двх сюда впилили, потому что там данные уже очищенные и обогащённые (из сервисов В и Г) — чтобы получить такое же вне двх это надо повторять эту логику с тем же набором данных.

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

⌘⌘⌘

что думаете про Reverse ETL? какбэ антипарттерн или норм? есть альтернативы? как «правильно»?

www.tgoop.com/data_days/377

1.7K viewsSasha Mikhailov, Aug 7 at 09:34

🥴 Reverse ETL — антипаттерн или норм?

у меня тут недавно наконец-то сложилась картинка в голове! до этого краем уха слышал этот новый термин, но никак не мог переложить его на реальность. А потом увидел схемку где помимо стандартного направления

источник → двх

была дополнительная стрелочка:

источник → двх → (обратно) источник

в итоге понял, что видел уже два таких кейса и пока ощущения смешанные:

1) считать бонусы определённому срезу сотрудников. был кейс когда ставка зависит от количества и статуса лидов например (или других штук, которые можно посчитать только в двх)

2) сейчас есть задача передавать данные между микросервисами (разные команды): микросервис А производит данные, их сгружаем в ДВХ, там происходит очистка и обогащение; а потом мы эти данные выгружаем в микросервис Б.

по второму кейсу не покидает ощущение «наколеночности» решения: получается, между двумя по-задумке-быстрыми сервисами появляется прослойка в виде батчевого двх с куском логики. двх сюда впилили, потому что там данные уже очищенные и обогащённые (из сервисов В и Г) — чтобы получить такое же вне двх это надо повторять эту логику с тем же набором данных.

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

⌘⌘⌘

что думаете про Reverse ETL? какбэ антипарттерн или норм? есть альтернативы? как «правильно»?

BY data будни