DG
Сервис на данных звучит слишком расплывчато. Что это? Интерфейс с sql к разным источникам (прозрачно для пользователя) или же просто апишечка?
Апишечка точно не сможет витрины подменить.
Апишечка точно не сможет витрины подменить.
Size: a a a
2019 November 24
DG
MPP подменяют не из-за локальности, и даже не из-за перфоманса, а простотпотому что хадуп требует наличия программистов. А mpp часто - нет.
DG
А в DWH исторически, далеко не везде есть программисты (data engineers).
VS
А в DWH исторически, далеко не везде есть программисты (data engineers).
Сейчас табун pl/sql'щиков должен обидеться 😂
DG
На эту тему много говорили на data talk #1
VS
Да и ETL без понимания разработки я еще не видел, если конечно не считать какое-нибудь говно
VS
Ну и самое смешное, как показывает практика, меньше 50% дата инжинеров вообще понимают, что такое хранилище и как его строить
AK
Сейчас табун pl/sql'щиков должен обидеться 😂
И правда обидно
VS
Большинство дата инжинеров делают просто, взяли 100500 источников и переложили как есть куда-нибудь, потом обмазали на сырых данных спарком и выплюнули в витрину.
А потом бизнес/аналитик подключается каким-нибудь bi инструментом и начинает городить велосипед...
А потом бизнес/аналитик подключается каким-нибудь bi инструментом и начинает городить велосипед...
DG
Здесь дело не в обиде, а реальности. Если вы хотите нормальный хадуп и спарк, надо применять подходы и практики из разработки. Или придется тратить до 80% времени на инциденты и баги, на саппорт инфраструктуры.
https://speakerdeck.com/sherman/odnoklassniki-dwh-evolving-meetup-version
https://speakerdeck.com/sherman/odnoklassniki-dwh-evolving-meetup-version
DG
Большинство дата инжинеров делают просто, взяли 100500 источников и переложили как есть куда-нибудь, потом обмазали на сырых данных спарком и выплюнули в витрину.
А потом бизнес/аналитик подключается каким-нибудь bi инструментом и начинает городить велосипед...
А потом бизнес/аналитик подключается каким-нибудь bi инструментом и начинает городить велосипед...
Плохие инженеры. Или хорошие, если все работает стабильно на существующем железе.
ME
А видеозапись есть?:)
DG
Вроде нет)
ME
DG
А это другой доклад. Это про планировщик.
DG
Но он тоже иллюстрирует тезис.
DU
Здесь дело не в обиде, а реальности. Если вы хотите нормальный хадуп и спарк, надо применять подходы и практики из разработки. Или придется тратить до 80% времени на инциденты и баги, на саппорт инфраструктуры.
https://speakerdeck.com/sherman/odnoklassniki-dwh-evolving-meetup-version
https://speakerdeck.com/sherman/odnoklassniki-dwh-evolving-meetup-version
да, спасибо, тезис понятный. вообще вся эта конфа как раз по теме, жаль видео не осталось
DG
Но там было много примеров вполне успешных, когда люди без хадупов вполне обходятся и делают крытые штуки для бизнеса.
DG
Никого не хотел обедить, просто BI специалист (специалист по бизнес аналитике), data engineer, аналитик ( уклоном в продукт) это все разные скиллы, немного разная специфика. Где-то это вообще один человек, а где-то разные. Есть универсальные солдаты. Чем сложнее инфраструктура, тем больше нужно скиллов в data engineering. Hadoop-based безусловно одна из самых сложных.
АЖ
Никого не хотел обедить, просто BI специалист (специалист по бизнес аналитике), data engineer, аналитик ( уклоном в продукт) это все разные скиллы, немного разная специфика. Где-то это вообще один человек, а где-то разные. Есть универсальные солдаты. Чем сложнее инфраструктура, тем больше нужно скиллов в data engineering. Hadoop-based безусловно одна из самых сложных.
hadoop это еще не предел, вот когда тебя на s3 + kubernetes выгоняют...