ноги, крылья ... главное хвост !
судя по всему майкрософт как минимум в свой реляционный огрызок в аналитике совсем не верит. теперь мс делает ставку на spark+hadoop. на замену всяких олапов и ролапов в mssql2019 прикрутили полноценную hdfs и spark2. если они сделают spark как энжин мсскл это будет хорошая заявка на успех.

vikkivна замену это когда одно прикрутили, а другое откручивают,
так что это явно не "на замену", а в дополнение, расширение горизонтов/возможностей

вангую что это такая же замена как олап->ролап

vikkivя конечно не спец по этому вопросу - но в чём преимущества и нужны-ли они?
дешевое дисковое пространство и в родной MS среде не проблема,
разнести запрос по множеству расчётных нод и собрать для выдачи клиенту на главной
- тоже давно решалось без затруднений на родных MPP (PDW, APS, Azure DWH) или elastic query.
скорость (передачи/чтения)? латентность? пропускная способность? цена? надёжность? в чём суть/польза то?
(native/optimized c++ vs scala/java по тестам производительности вроде-бы не сильно различаются)
эдак ради сложности да мудрёности можно ведь и дюжину и сотню прослоек наставить..
в общем конечно зависит от приоритета решения - но по балансу факторов лучше стек технологий поуже держать да без лишних прослоек..
у спарка есть киллер фичи и он сейчас по сути отраслевым стандартом становится. спарк есть у хадупа, в любом облаке, есть у оракла (в виде bigdata applience), будешь смеятся но спарк есть даже на мейнфрейме. т.е. готовые тучи спецов знакомые с технологией и заказчик думающий что это спасет от вендор лока. изучать всякую муть только лишь от майкрософта и для майкрософта с каждым годом будет сложней, особенно если эта муть уже лет 10 так и не может сформулировать, что оно может противопоставить, причем за неслабые деньги.

что касается спарка, то концептуально там есть прикольные фичи. правда оговорюсь, у нас на cloudera hadoop, где спарк на каждую киллер фичу генерит киллер хрень.
так вот, там не только и не сколько SQL. там можно писать жава код с датафреймами в стиле
dataframe1.select("col1", "col2");
dataframe1.select("col1").filter ...;
obj1.process(dataframe1);
т.е. то что ты в классике жанра вынужден пихать в один многостраничный и не читаемый SQL тут можно раскладывать по разным классам, передавать в методы. при этом операции с датафреймами это лишь декларация о хотелках, которые выполнятся только когда от датафрейма попросили некой терминальной операции. типа вывести на экран или записать в файл.
внутрь датафрейма можно втыкать вызовы любой жаба библиотеки. т.е. внутри датафрейма можно хоть гугловский тензерфлоу приладить и получится что процесс что читает данные и эти же данные скармливает либе. в классике у тебя пол любому данные доступны лишь встроенным в скл движок функциям. в случае с мсскл если надо что-то большее чем встроено - данные из скл ядра копируются в .Net машину со всеми вытекающими.
плюс там все кластеризуется из коробки, есть понятие спарк стриминга, что в связке с кафкой тоже слегка меняет подходы к обработке инфы. поскольку это по сути галимая жава, то можно писать полноценные юнит и интегрейшен тесты. вобщем если это заработает у мс как задумано, это будет новая эпоха. концепции там заложены обалденные, сыро только очень ...