medoed,
точно помню что коннектился на домашнем компе к скл-2014 на локлахост
не понмю версию пентахо - год назад была последней
и да качал jar и помню были заморочки но подробностей не помню - все решил с помощью гугла

м.б это
https://stackoverflow.com/questions/48581898/pentaho-kettle-cannot-connect-to-ms-sql-server-express

вот вроде неплохая ссылка
https://scribesroom.wordpress.com/2018/08/28/creating-a-pentaho-database-connection-to-a-microsoft-sql-server/


зы для чисто мс-скл я бы SSIS юзал
если есть и другие БД - то да возможны варианты
в принципе пентахо (kettle) бесплатный и рабочий тул

Есть Pull и есть Push архитектуры,
подписчики могут либо сами периодически запрашивать есть-ли изменения,
либо получать уведомление от master что пора запросить обновлённые данные
в случае Push в том-же SSIS есть CDC и Multicast.
если на микро-сервисах для параллельности: то просто вектор (массив) получателей отправить - а там уже под каждого автоматом выделить свой контейнер.
так что в такой формулировке пока всё это скорее пере-изобретение велосипеда через восхождение на кактус.

medoed,

https://www.mssqltips.com/sqlservertip/5082/synchronize-table-data-using-a-merge-join-in-ssis/

Ну лучше применять ELT-архитектуру, так издержки на разработку меньше получаются

Господи, что за порнография по ссылке! За такие решения я бы настаивал на депортации "SQL Server database professional with 10+ years of experience" на историческую родину...

Во-первых, сортировка на стороне SSIS сколь-либо значимых объемов данных - весьма рискованное мероприятие. У SSIS есть очень неприятная особенность: он может до бесконечности пытаться забрать память, которой ему типа не хватает. Не возникает ни ошибок, ни алертов, ни тем более попыток как-то адаптировать свою работу к текущим условиям существования (только запись в логе - спустя какое-то время и ради которой надо парсить лог).
Оптимальный вариант - сортировка на стороне БД или иными средствами.

Во-вторых, построчная обработка обновляемых и удаляемых записей. Вот из-за таких "профессионалов" многие программисты не пытаются делать средствами ETL чего-то сверх простейшей перекладки данных.
Оптимальный вариант - вставка данных в 3 промежуточных таблицы (или одну с полем Update Strategy), затем Insert + Update + Delete основной where exists промежуточная, обернутые в транзакцию. Вместо tran(I+U+D) можно использовать SQL Merge, но надо смотреть план и блокировки, поэтому предпочитаю первый вариант.

По основной теме: использую связку шины RabbitMQ (интеграция) <-> SSIS (трансформация) <-> СУБД (хранение). Слияние через Merge (правильное) использовал ранее, сейчас - практически отказался в пользу более эффективных нестандартных возможностей SSIS.

medoed,

Да, обновляемая порция во время работы пакета будет храниться в БД. Однако медленную работу построчного слияния той же порции вы заметите намного раньше.

Безусловно, прямой коннект потенциально быстрее обмена через шину. Однако у шины есть свои преимущества. Во-первых, с ее помощью гораздо проще маршрутизировать потоки данных, без каких-либо доработок и деплоев m пакетов на n серверов, все делается централизованно и с буферизацией. Во-вторых, сообщения могут содержать внутри себя обработанные данные (например, форматированные параметры сделки), а не голые таблицы источника, которые могут черти-как документироваться, соединяться, индексироваться, блокироваться, меняться со временем...

Эти преимущества для меня часто более значимы, но не всегда. Например, у меня есть реализованные на прямом доступе сверки данных между системами.