Гавриленко Сергей АлексеевичНе может условный join работать вне сервера быстрее, чем внутри.
Может и легко. У SSIS намного меньшие издержки, ему не нужно поддерживать транзакционность, лог, статистику выполнения и т.п.

Разрабатываю всю загрузку ХД посредством SSIS, начиная от получения данных из шины (напрямую), файлов, таблиц БД. Пакеты крутятся на выделенном сервере ETL и минимально нагружают основной сервер ХД. Работает быстро, потребляет мало.

invmSSIS умеет забирать данные из MSSQL мимо транзакционности и статистики выполнения?Чем нагружается лог при чтении?
Я отвечал на вопрос о join-е. Давайте не будем произвольно расширять вопрос и притворяться глупее, чем мы есть.
invmКак выполнить соединение на клиенте не выкачав все данные в нем участвующие?
ETL-средство не может оптимизировать непосредственно выкачку данных из таблиц и очень ограниченно - вставку, за счет разбиения на порции. Основная выгода получается за счет операций над выкачанными наборами данных (начиная с декомпозиции запросов к источникам).

TaPaKрадует, мышкопрограммисты атакают
Вы напомнили мне одного моего дальнего родственника, программиста на плюсах. Как-то раз он мимоходом сказал, что SQL - это не программирование, а так. Я в ответ хмыкнул, пожал плечами и подумал: молодой еще, авось потом поймет.
Лично я комбинирую внутри SSIS квадратики, SQL и C#, выбирая то, что проще и эффективнее решит конкретную потребность. У меня три инструмента, у других один.
TaPaKмы поставили второй сервер что бы сказать что теберь всё быстрее на первом
Именно так. И это очень хорошая практика, когда нагрузку можно разнести по разным машинам в зависимости от ее типа, изолировать постоянно работающий ETL от аналитических запросов.
invmА мои вопросы к чему относятся?
Или join в SSIS - это некая магия?
Не магия, по сути это обычный merge join.
Как только вы захотите изменить данные посредством join внутри СУБД, вы сталкиваетесь с теми самыми издержками, о которых я говорил выше. Без изменения данных это не ETL и потому оффтопик.
invmЕсть тут на форуме один персонаж, который некоторое время назад утверждал, что "мержить" данные из БД в SSIS гораздо выгоднее, чем на сервере. Доказать не смог.
У вас пока что тоже с доказательствами беда...
Если рассматривать понятие "мержить" максимально широко, то я соглашусь с тезисом этого персонажа. Доказываю это своим работающим решением моему руководству и работодателю. Доказывать лично вам... ну, если вежливо попросите.

invmА входные данные для merge кто будет сортировать?
Либо сервер БД, либо SSIS.
invmКак интересно.
Оказывается SSIS еще и писать умеет в БД минуя транзакционность и статистику выполнения. Не говоря уже о том, что посредством join данные в БД изменить нельзя.
Вы цепляетесь к словами, что, на мой взгляд, не имеет разумной цели. Если вам так не нравится слово "посредством", я напишу "с применением join". Вопрос исчерпан?

В одном случае транзакция блокирует таблицы-источники, а также ресурсы для преобразований данных.
В другом - отдельные и независимые (опционально) транзакции на чтение и изменение (обычно bulk insert).
invmРаботоспособность решения не есть доказательство его превосходства над другими работоспособными решениями.
Согласен с вами. Более того, я считаю это очевидным не только для нас, но и для моего руководства.

Кесарь,

до 500 xml сообщений (по 1-100 кб) в секунду, таблицы до нескольких сотен млн записей, задержка обновления данных до пары минут (от появления сообщения в шине), минимальное влияние на сервер ХД (короткие insert и update). Посредственное виртуальное железо. Реализованы разрешение идентификаторов без ограниченного окна загрузки; СККД и автоматическая загрузка после исправления ошибки (например, элемент справочника пришел позже ссылающегося на него факта).

Кесарь,

в общем-то у меня нет затыка. На вход загрузки подается в разы меньше данных, чем она способна обработать (средняя нагрузка около 100 сообщений/сек).

Аналог микросервисов реализован пакетами SSIS. Одна посредственная виртуалка, без контейнеров, кластеров и прочей атрибутики для лентяев.

Бизнес-логику, удовлетворяющую заданным требованиям, посредством одного SQL реализовать невозможно (мое личное мнение). Если не углубляться, то не получится совместить минимальные задержку и влияние.
TaPaKserver broker курильщика
Уже был RabbitMQ.
Кроме того, я не видел решение, позволяющее парсить такой поток сообщений на таком железе. Поэтому сделал так, как сделал.