Дополнительная нагрузка на два разных сервера с разными исходными БД - PullRequest
0 голосов
/ 05 июня 2018

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

Вот как выглядит инфраструктура источника данных:

У нас есть два производственных сервера (для двух разных продуктов), скажем, P1 и P2 P1 нашими источниками данных являются две базы данных: DB1 и DB2 , расположенные на связанном сервере S1 .На P2 существует только одна база данных DB3 на связанном сервере S1 .В будущем будет добавлена ​​еще одна база данных DB4 для P2 и продукт P3.На сервере S1 есть представления SQL, представляющие все данные.

И наш ETL:

Два разных проекта SSIS для P1 и P2, которые фактически отличаются только строками подключения.DB1 и DB2 объединены с помощью Union ALL компонента SSIS непосредственно в задачах потока данных.В настоящее время пакеты служб SSIS выполняют запросы SQL, хранящиеся внутри задач, изменение в ETL для P1 приводит к повторному изменению того же изменения в ETL для P2.Данные загружаются два раза в день на P1 и каждые 5 минут на P2, при загрузке данных все усекается и загружается в промежуточные таблицы в обоих хранилищах данных.

Цель:

Наша цель - создать один универсальный процесс ETL с параметризацией, который позволит нам использовать DB3, когда SQL выполняется на сервере P2, и DB1 + DB2, когда он выполняется на сервере P1, свозможность расширить это до P3 + DB4 и DB3.Мы также хотели бы переместить код SQL из пакетов в хранимые процедуры, чтобы с точки зрения разработчика было проще обслуживать его.
Нам также нужно, чтобы ETL происходил чаще на P1, но в то же время нам не разрешается запрашивать весьнабор данных несколько раз за короткий период времени на связанном сервере это будет проблемой на P2, как только набор данных будет увеличиваться со временем.

Чего мы хотим избежать: динамический SQL.

Каковы наилучшие практики для создания дополнительных загрузок данных и такой параметризации в службах SSIS?Мы находимся в постоянном контакте с разработчиком, отвечающим за сервер S1, и если нам понадобится какой-либо вид, он сможет его предоставить.

1 Ответ

0 голосов
/ 06 июня 2018

Общий шаблон, который я выбрал бы, был бы примерно таким:

Мой поток управления определит базы данных на сервере, связанном с нашим проектом (Connection Manager = Source)

enter image description here

Здесь я показываю запрос к sys.databases, потому что, возможно, вы можете применить критерии, подобные AND D.Name IN ('DB1', 'DB2', 'DB3');

На S1, этот запрос будет возвращать 2 значения, наS2, только 1.

Мы использовали бы этот список баз данных как источник перечислителя циклов ForEach для «измельчения» результатов.Для каждого значения, которое мы указали в исходном запросе (DB1, DB2), мы собираемся обновить свойство InitialCatalog нашего Source ConnectionManager.В приведенных ниже справочных ответах я установил свойство ConnectionString, но вам нужно только изменить InitialCatalog.Таким образом, каждый цикл, на который указывает база данных, будет меняться.

Поток данных внутри перечислителя ForEach затем упрощается, чтобы иметь дело только с текущей базой данных, и не нужно беспокоиться о том, имеет ли этот сервер 3 исходные базы данных или 1.

enter image description here

Предостережения

Исходный запрос и типы данных должны быть совместимыми со всеми соответствующими базами данных.Структура потока данных устанавливается во время разработки и не может быть изменена во время выполнения.

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

Вам нужно будет указать начальное значение строки подключения источника при запуске пакета.Это можно выполнить с помощью атрибута SET при вызове.

Справочные ответы

Некоторые соответствующие ответы служб SSIS, в которых рассматриваются эти понятия

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...