Пожалуйста, оцените дизайн

Я, вероятно, не стал бы создавать главный пакет, который делает это для местоположений все. Вместо этого создайте настраиваемый пакет, который выполняет эти шаги для местоположения один (с переменными SSIS, указывающими свойства, зависящие от местоположения).

Теперь вы можете запустить этот пакет либо из сценария .cmd, либо, если хотите, создать главный пакет SSIS с несколькими задачами «Выполнить процесс», каждая из которых запускает первый пакет с соответствующими значениями переменных.

P.S. Да, в главном пакете вы должны использовать задачу Execute Процесс, которая запускает DTEXEC, а не задачу Execute Package - к сожалению, Execute Package не очень настраивается - см. http://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=295885.

Извлечение по медленному или дорогому каналу WAN

Думаю, то, что вы описываете, звучит уместно. Для медленного или дорогостоящего канала WAN вам может потребоваться уменьшить объем передачи данных. Вот некоторые подходы к этому:

• Изменен сбор данных.
• Сжатие.

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

• Выписка из первоисточника
• Вычислить хеш-значение, используя алгоритм с низкой вероятностью прикрепления ко дню рождения (например, MD5, SHA-1)
• Поддерживать базу данных или файл с хеш-значениями в форме (ключ исходной системы, хеш-значение всех неключевых атрибутов)
• Свяжите что-нибудь с непревзойденным значением хэша и отправьте его по ссылке WAN.
• Обновите базу хешей.

Надежное распределенное извлечение

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

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

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

Слияние при извлечении против слияния при преобразовании

Если системы идентичны (например, POS-системы в сети розничных магазинов), вы, вероятно, получите более простую архитектуру, объединив данные перед фазой преобразования. Это означает, что промежуточная область должна знать об источнике данных, по крайней мере, для целей аудита.

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

Нужен ли нам ОРВ?

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

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

High+--------------------------+--------------------------+
    |                          |                          |
    | Kimball Model (low/high) | Enterprise Data Warehouse|
H   | Unified ODS model hard   |        (high/high)       |
e   | to meaningfully design.  | ODS both difficult and   |
t   | Flat star schemas easier | probably necessary to    |
e   | to fit disparate         | make a manageable system |
r   | data into.               | Better to separate trans-|
g   |                          | formation ahd history.   |
e   +--------------------------+--------------------------+
n   |                          |                          |
e   |                          |  Consolidated Reporting  |
a   |   Data Mart (low/low)    |       (high/low)         |
i   |                          |  ODS easy to implement   |
t   |   ODS probably of        |  and will simplify the   |
y   |   little benefit         |  overall system          |
    |                          |  architecture            |
    |                          |                          |
Low +--------------------------+--------------------------+
Low                  Number of data sources            High