R
(Еще и пиццу-то фиговую...)
((ой, опасно, как бы тут холивар не начался) это ведь дело вкуса))
Size: a a a
2020 December 02
VS
При изменении схемы данных продуктоунер и команда, изменяющая схему данных, должны ждать пока Data Engineering допишет код, необходимый чтобы изменения поддерживались.
VS
на этом моменте закрадывается вопрос, а правильно ли они работают с хранилищем и данными...
VS
хотя это скорее проблема продуктовнера и аналитиков, почему у них выстроен зависимый, а не парарллельный процесс
VP
Тут ключевое слово "должно".
В идеале должно быть, в идеале все должны ему следовать. Но:
1) иногда может возникнуть кейс связи данных из разных доменов, которых не входит в кросс доменные правила и все.
2) в реале вряд ли это будет работать в больших командах (
В идеале должно быть, в идеале все должны ему следовать. Но:
1) иногда может возникнуть кейс связи данных из разных доменов, которых не входит в кросс доменные правила и все.
2) в реале вряд ли это будет работать в больших командах (
Моё имхо, но в таких кампаниях как netflix (она там упоминмается) по другому просто никак в силу кол-ва источников и объёмов, даже несмотря на большее кол-во - чем +. Другое дело когда его начинают копировать кампании в которых традиционный "монолит" мог бы быть более дешёвым и правильным... (это не к Додо если что, просто философия ) )
VS
Vitaly Pismarev
Моё имхо, но в таких кампаниях как netflix (она там упоминмается) по другому просто никак в силу кол-ва источников и объёмов, даже несмотря на большее кол-во - чем +. Другое дело когда его начинают копировать кампании в которых традиционный "монолит" мог бы быть более дешёвым и правильным... (это не к Додо если что, просто философия ) )
А где эта граница по количеству источников и объемов?
PD
Vitaly Pismarev
Моё имхо, но в таких кампаниях как netflix (она там упоминмается) по другому просто никак в силу кол-ва источников и объёмов, даже несмотря на большее кол-во - чем +. Другое дело когда его начинают копировать кампании в которых традиционный "монолит" мог бы быть более дешёвым и правильным... (это не к Додо если что, просто философия ) )
Ну, у Нетфликса очень много специфических вещей, которые копировать не стоит. Начиная со среднего качества сотрудников (и способов его достижения).
VS
И как предоставить компетенцию в каждую команду, для насыщения хранилища?
R
Vitaly Pismarev
Моё имхо, но в таких кампаниях как netflix (она там упоминмается) по другому просто никак в силу кол-ва источников и объёмов, даже несмотря на большее кол-во - чем +. Другое дело когда его начинают копировать кампании в которых традиционный "монолит" мог бы быть более дешёвым и правильным... (это не к Додо если что, просто философия ) )
Да, я согласен с вами, что в больших компаниях это вполне рабочая схема, но только, если её придерживаются. Т.е. компания должна быть большой и культура/дисциплина(может быть не самое удачное слово) раьоты с данными. По сути должно быть очень много компетентный людей по работе с данными, как минимум в каждой команде. А это очень трудно реализовать, но не значит, что невозмодно
VS
это очень дорого, как минимум
PD
И как предоставить компетенцию в каждую команду, для насыщения хранилища?
Ну, если хранилище - это просто СУБД или Вертика, то поменять код insert-ов не сложно, а при проблемах - дойти до "центра компетенции".
PD
Да, я согласен с вами, что в больших компаниях это вполне рабочая схема, но только, если её придерживаются. Т.е. компания должна быть большой и культура/дисциплина(может быть не самое удачное слово) раьоты с данными. По сути должно быть очень много компетентный людей по работе с данными, как минимум в каждой команде. А это очень трудно реализовать, но не значит, что невозмодно
А что значит "компетентных людей с дисциплиной работы с данными"? Тут же не про "строить схему", а про "чуть-чуть изменять схему".
PD
На общем фоне обычных проблем с изменением схемы хранения - доработать ETL кажется небольшой частью
VS
Ну, если хранилище - это просто СУБД или Вертика, то поменять код insert-ов не сложно, а при проблемах - дойти до "центра компетенции".
ну вообще-то сложно, начиная от деплоя структуры на хранилище, блокировок загрукзи и доступа, ну и конечно же SLA
VS
ну и самое веселое, как быть, когда один DE уходит от одной команды, кто будет дописывать все, пока ищут человека?
VS
Получается все сведется к тому, что все равно остается одна общая команда DE, которая и лезет в источники и никак не связана с продуктовой разработкой
VS
Потом выяснится, что один DE может поддерживать не один источник, а 100500 и все возвращается на круги своя
PD
ну вообще-то сложно, начиная от деплоя структуры на хранилище, блокировок загрукзи и доступа, ну и конечно же SLA
С нуля - конечно сложно. При обычных простых правках - можно написать алгоритм-чеклист для команды.
С пунктом "а если что-то еще - то обратитесь к датаинженеру".
Это масштабируется гораздо лучше
С пунктом "а если что-то еще - то обратитесь к датаинженеру".
Это масштабируется гораздо лучше
VS
И это я еще не поднимал вопрос бюджета продуктовых команд, когда лид скажет "идите в Ж со своим хранилищем, у меня сроки горят и я найму лучше еще одного разраба"
VP
А где эта граница по количеству источников и объемов?
Её нет ессно,но такие подходы рождаются не потому что кому-то захотелось, а предварительно посчитав затраты и попробовав на каких-то проектах и потом уже распространив на всю кампанию. Ну по крайней мере я верю в нетфликсе и ему подобных так и есть )