Glebanski,

тут не только в самом питоне дело
(всё равно больше скриптовый, а не компилируемый, соотв. ожидаемые проблемы с производительностью),
DataBricks используется в контекстах
[1] DataLake (прямым mount volume) который всё равно в облаках и полюбому не бесплатен
[2] ML / DS контекст где SQL Server явно не настолько продвинут по функционалу
(ML Services отдельный или встроенный - не настолько мощные чтобы кучу батчей в них кидать,
ну может только SQL Server Big Data Cluster который не так уж и сильно взлетает у MS как продукт из-за конкуренции).

Из SQL Server/Synapse можно mount делать файлам DL как external table для промежуточного ETL этапа (через Java/Polybase)
- но опять-же: вопрос неопределённости схемы из-за неизвестных пока требований..

Кроме того в ETL (для Data Lake) важен не собственно сам DataBricks сколько его масштабируемый Spark Clusters
именно поэтому к ETL на DataBricks идёт требование знаний Scala или хотя-бы PySpark (с его более эффективным API к Spark)
а не стандартные NumPy/Pandas/Matplotlib как для PowerBI
хорошо хоть mapreduce перестали требовать

А так-то в DataBricks есть и DashBoards (с динамическими интерактивными параметрами) для отчётности и свой оркестратор/планировщик

вообще-то да, как раньше писали - последние года 4 может создаться впечатление о шаге назад в прошлое когда сначала потребовались десятилетия чтобы перейти от работы с файлами на базы данных сo строками на миллионы/миллиарды, а теперь вдруг обратно на файловые системы, но на самом деле тут концепция немного другая т.е. данные хранятся в сыром виде, необязательно структурированные, да и какая структура понадобится пока неизвестно (поэтому для DL и schema on read подход)

так что проблема в основном в том что на фоне очередного технологического взрыва - стремительно начинают меняться источники (и форма данных, да и немного - что считать данными), а разработчики рисованного ETL софта начинают сдаваться пытаясь за всем этим угнаться, в том-же SSIS я в основном использовал свой custom code на C# где SSIS был чисто для галочки как формальная среда - элементарно не хватало функционала для решения задач без хождения по граблям их модулей.. для элементарных задач конечно SSIS может и хватает, вот только таких задач в общей массе ну очень мало.

Да, ADF тоже убожество (a года 3 назад вообще был ад), но свою работу вполне делает, понемногу догоняет..

п.с. для некоммерческого использования есть из бесплатных пробных (но ограниченных и тормознутых естественно) те-же kaggle или databricks community (хостится на AWS)

Наверное потому что сам DataBricks вовсе не скил, ну разве что конфигурация кластеров, логи, дашборды
(есть некоторые нюансы, но они довольно просты в освоении чтобы выносить в отдельные требования)..
в вакансиях пишут или Spark/Scala или Python / Notebooks (даже можно без него напрямую указывая
только опыт с необходимыми модулями {к-рых больше 100К} по сфере деятельности: автоматизация
тестирования, бэк/фронт-энд, ML/DS, ETL работа с хранилищами файловыми DL или базами и пр.)
С ETL/ELT кстати немного похожая история - но сам скил намного больше привязан к платформе.

Но при этом PySpark почему-то более популярен..

Есть конечно и для R API в Spark

Наверное из-за собственно распостранённости самого Python, т.е. не приходится учить новый язык
.. естественно в PySpark есть (разумнее использовать) только DataFrame , а DataSet там нет..
(перевожу на новую страницу)