Charles Weyland,

SSIS - не очень удобный инструмент разработки. Мягко говоря. Но со временем появляется сноровка в обращении с инструментом.
Блок Slowly Changing Dimension - это хрень (имхо).
Блок "сортировка" - опасная на больших объемах вещь. Поэтому почти всегда сортирую в источнике.
Типизация внутри ETL обычно более строга, чем для SQL.

А все ради производительности и эффективности выполнения характерных для ETL задач.

Я имею возможность на своем опыте сравнивать SSIS с другими средствами ETL. У которых есть десятки и сотни компонент из коробки, копирование метаданных (схем), трассировка полей по потоку, вменяемый лог, менее глючный интерфейс и другие вкусности.

Но нет в жизни идеала, у каждой зверушки свои погремушки...

Формально говоря, SSIS-ом.

А де-факто у меня половина компонент (включая источники и приемники) - это Script Task, пакеты шлют друг другу данные напрямую, и т.п. Это явно не SSIS здорового человека, а мутант и химера. Нормальные программисты БД обычно тяготеют к ELT, а я наоборот - все трансформации затягиваю в SSIS. И мне это почему-то нравится...

Претензии автора указанной темы для меня выглядят во многом странно и вызывают четкую ассоциацию с хейтом (не вижу сейчас смысла углубляться).

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

Своя dll действительно сильно упрощает жизнь.
Из коробки параметры передаются действительно не очень удобно, но есть способы упрощения. Своя dll в помощь.
Скрипт отлаживается аналогично обычному проекту C#, если вы не меняли для скрипта версию .Net. И даже в этом случае вы можете, например, писать отладочную информацию в лог SSIS.

Ну почему однозначно-то?
(Даже не говорю о множестве причин, по которым в живой системе источники или приемники могут быть в любой момент вынесены из общей БД).

В конечном счете там жалоба на плохую масштабируемость трансформации SCD в сравнении с производительностью SQL-ных Set Base operations. Дополнительная ссылка на Microsoft (известный рассадник кимболловщины) - тоже не слишком убедительна. Нашли на кого сослаться - на мачеху Золушки, у которой до сих пор нет полноценного курса по SSIS (20767 лишь наполовину относится к SSIS и не поднимается выше начального уровня), и которая гонит клиентов от собственных инфраструктур ETL в свое светло-ажурное будущее.

Это будет уже оффтоп. Скажу так: я не увидел у MS иного места для SSIS, кроме как необязательного средства для облегчения построения ХД по Кимболлу.

Вы в потрохах SSIS копались, всякие PipelineBuffer и add_data_tap знакомы?
Вот про это должен быть продвинутый курс. Про автоматизацию создания пакетов посредством biml и C#. И т.п.
Я на онлайн ХД с минимальной задержкой.

На всякий случай сообщаю, что высказываю свою личную точку зрения.

Кимболл воспринимает ETL как средство для подготовки кубов (точнее, таблиц измерений и фактов), он много пишет о том, какие данные хочет увидеть, но не углубляется в то, как именно это делать.

С другой стороны, якорная модель представляет собой квинтэссенцию упрощения ETL, благодаря чему сравнительно легко автоматизируется. Шерифа не волнуют проблемы индейцев, по малейшему поводу собирающих множество таблиц.

Ни те, ни другие не ставят в центр средство ETL и его возможности. Что оно может делать эффективно (и какими способами), а что - нет? Как разделить типичные задачи ETL между СУБД, ETL, вставками на C#/Java/etc?

У меня есть такая необходимость, и она привела меня к более глубокому пониманию функционирования SSIS, нежели было ранее.

У меня все данные low latency (с поправкой на застрявшие невалидные).

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

Для моего DWH ненормальна задержка поступления данных более 30 секунд (обычно она измеряется секундами). За это время все новые данные раскладываются по сущностям ХД, разрешаются все идентификаторы на суррогатные, выполняются проверки качества и применяется стратегия обновления. Объемы сущностей ХД - до миллиарда строк.

del

Не ODS, а DDS.

Как полный скоп детальных данных. Причем (в моем случае) отличающийся по структуре от данных исходных систем (на твоей картинке это Data Warehouse). Я уже писал выше, что у меня нет потребности в отдельных оперативных данных.

Detail Data Store, вполне себе гуглится.
На данном этапе консолидируются все данные ХД на максимально необходимом уровне детализации согласно внутренней модели данных ХД.
Агрегация - это по определению ( Detail Data Store) не очень типичная задача для данного слоя, хотя и возможная.

Основные отличия от ODS - это полное временное покрытие (а не узкий временной срез) и собственная модель данных (а не приближенная к источникам).

Я говорил выше про якорную модель - она упрощает загрузку, но усложняет получение данных. Я не строил ODS таким образом, поэтому не стану говорить про связанные с этим проблемы.

Я избегаю сайты, запрещающие AdBlock.
Архитектура области хранения данных базы данных корпоративного хранилища, как правило, состоит из следующих областей:

область временного хранения данных (Staging Area) – предназначена для временного хранения данных, извлеченных из систем-источников; является промежуточным слоем между операционными системами компании и хранилищем данных;
область постоянного хранения данных, которая включает:
детальные данные (System of records) – область хранения детальных данных, приведенных к структуре модели данных корпоративного хранилища, прошедших очистку и обогащение;
агрегаты (Summary area) – сгруппированные по времени (чаще просуммированные) детальные данные;
витрины данных (Data Marts) – тематические наборы данных, хранящиеся в виде пригодном для их анализа (например, схема «звезда»); ориентированны на поддержку конкретных бизнес-процессов, приложений, подразделений компании, бизнес-целей;
...

Детальные данные (System of records)
Данная область является основной хранилища данных. В этой области хранятся преобразованные и очищенные детальные данные, полученные из систем-источников, и основные классификаторы. Хорошо спроектированная модель данной области является залогом дальнейшего успешного функционирования базы данных и BI-приложения.

Данная область содержит следующие типы сущностей:

справочники и классификаторы;
сущности, содержащие фактические значения;
сущности, описывающие связи.
Справочники и классификаторы определяют:

участников основных бизнес-процессов – клиентов, поставщиков, филиалы, услуги, продукты и т.п.
базовые справочники – дата и время, валюта, страны и т.п.
прочие справочники – отражающие потребности бизнеса в необходимой аналитике данных, определяющие в разрезе каких справочников необходимо анализировать фактические данные.
Сущности, содержащие фактические значения, – транзакционные данные из систем источников. Например, информация о совершенных телефонных звонках, выставленных счетах, проводках, проданных товарах и т.п.

Сущности, содержащие связи, определяют взаимосвязи между остальными сущностями. Например, Клиент-Услуга.

Область детальных данных не содержит никаких агрегатов. Только детальные, очищенные и структурированные в соответствии с моделью данные. Ссылка