我想从位于欧洲和亚洲的不同数据服务器收集数据。我没有运行会阻塞海底网络的普通数据查询任务，而是考虑在本地站点上为我提供几台机器。
我正在考虑设计主包，以便我可以：
数据收集是通过自定义脚本源处理的，因为数据可以通过一个奇怪的类库获得。
任务可能会意外失败。如果特定类型的数据成功捕获，而其他特定位置的数据失败，我不想再次运行它。
如果可能，我如何简化此设计并使其更健壮？
【问题讨论】：
标签： sql-server sql-server-2008 ssis
通过缓慢或昂贵的 WAN 链接进行提取
我认为你的描述听起来很合适。对于缓慢或昂贵的 WAN 链接，您可能希望减少数据传输量。一些方法是：
如果您可以从源头轻松识别新事务或更改的数据，则可以通过仅发送更改来减少数据量。如果您在源头有资源但无法轻松识别更改的数据，您可以执行以下操作（如果需要，请为此构建通用框架）：
稳健的分布式提取
像这样的分布式系统有许多故障模式，因此您需要为此实施一个相当健壮的错误处理机制。故障模式的示例可能是：
根据仓库系统的要求，您可能需要容忍单个 Feed 的失败。您需要为此设计一个强大的错误处理策略。
Merge-on-Extract vs. Merge-on-Transform
如果系统相同（例如连锁零售店中的 POS 系统），您可能会通过在转换阶段之前合并数据来获得更简单的架构。这意味着暂存区需要了解数据源，至少出于审计目的。
如果您有少量系统或多个异构源，则应在转换过程中进行数据合并。在这种情况下，您的 ETL 可能会为每个源系统至少为某些过程提供单独的例程。
我们需要 ODS 吗？
数据仓库领域的一场重大宗教战争是是否应该拥有 ODS。我已经完成了有和没有 ODS 结构的系统，在个别情况下，设计决策是有原因的。我对此的看法是，这个决定的任何一方都没有普遍令人信服的论据，这首先是宗教战争存在的通常原因。
对于 50,000 英尺的视图，我对此的看法是，源系统越多，数据越同质，ODS 的情况就越强。可以为此绘制一个 gartner 式象限：
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
【讨论】：
我可能会避免为所有位置创建一个主包。相反，创建一个可配置的包，为 一个 位置执行这些步骤（使用 SSIS 变量指定特定位置的属性）。
您现在可以从 .cmd 脚本运行此程序包，或者如果您愿意，可以创建具有多个执行进程任务的主 SSIS 程序包，每个任务都使用适当的变量值启动第一个程序包。
附：是的，在主包中，您应该使用启动 DTEXEC 的 Execute Process 任务，而不是 Execute Package 任务 - 不幸的是，Execute Package 不是很可配置 - 请参阅http://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=295885。
【讨论】：