да на спарке свой dbt седалть легко

скорее для того, чтобы можно было BI прикрутить, поэтому анси

ну как бы датафрейм и скуль апи эквивалентны

Ну хзхз, некоторые сложные запросы в df мозг сломать можно

ЭТО ДРУГОЕ

то есть это для того чтобы превратить спарк в пускалку sql кода, больше от него ничего не требуется для этих BI тулов

а потом у вас фукнции на sql , чтоб ip вытащить из поля

Dbt это история про dynamic sql ? Что то ещё она интересное несёт в себе ?

Типизация же не самоцель, это ради safety делается, которую в случае с SQL логикой пытаются достичь ассертами и тестами

Конечно люди не от хорошей жизни это делают, выразительность SQL по сравнению с любым general purpose языком сильно хромает; но писать декларативный type safe DSL не все готовы, какого-то общего пока не появилось, а у SQL низкий порог входа, а СУБД очень шустрые и их мощь хочется использовать

Это же не весь etl, а только трансформации. А вообще sql бывает типизированным?

Но Спарк и не всем подходит, у него понятная область применимости но за рамками это области - очень больно и очень дорого (ну или ждать пока delta engine всем дадут)

как-будто что-то плохое 😃

да и ребята пилят поддержку спарка - https://github.com/fishtown-analytics/dbt-spark

Имеются в виду всякие spark dataset, frameless, такие подходы

Кажется, что сделать декларативный язык нетипизированным гораздо сложнее, чем типизированным

Да, конечно, прошу прощения, я неправильно выразился, я скорее имел ввиду подход к написанию кода (?) в sql. Ну, типа, я же не декларирую тип каждой колонки заранее, я просто делаю select и уже получаю типы колонок на выходе, кроме тех случаев когда явно делаю преобразования типов. Вот и получается, что порой из самого sql кода тип колонки определить явно не получится,  кроме как запустить его и посмотреть тип в итоговой таблице.