请批评设计

Question

我想从位于欧洲和亚洲的不同数据服务器收集数据。而不是运行会阻塞海底网络的普通数据查询任务，而是考虑在本地站点上为我提供的几台机器。

我正在考虑设计主包，以便我可以：

1. 运行远程设置任务
2. 使用psexec dtexec ...
在本地启动数据收集包
3. 获取本地存储在多个原始文件中的数据（每种数据类型1个）
4. 拉链并拉回
5. 解压缩并批量上载到本地服务器

数据收集是通过自定义脚本源处理的，因为数据可以通过一个奇怪的类库获得。

任务可能无法预测地失败。如果成功捕获特定类型的数据而其他数据在特定位置失败，我不想再次运行它。

如果可能，我如何简化此设计并使其更加强大？

Answer 1

通过缓慢或昂贵的广域网链接进行提取

我认为你所描述的听起来合适。对于缓慢或昂贵的WAN链接，您可能希望减少数据传输量。一些方法是：

• 更改了数据捕获。
• 压缩。

如果您可以在源代码轻松识别新事务或更改数据，则只需发送更改即可减少数据量。如果您在源头上有资源但无法轻松识别已更改的数据，则可以执行以下操作（如果需要，可以为此构建一个通用框架）：

• 从源中提取
• 使用生日附加概率较低的算法计算哈希值（例如MD5，SHA-1）
• 使用表单中的哈希值维护数据库或文件（源系统密钥，所有非密钥属性的哈希值）
• 使用无法匹配的哈希值捆绑任何内容并通过WAN链接发送。
• 更新哈希数据库。

强大的分布式提取

像这样的分布式系统有许多故障模式，因此您需要为此实现一个相当强大的错误处理机制。失败模式的示例可能是：

• 其中一个源系统或网络连接可能会按计划停机。
• 其中一个数据包迟到
• 数据以某种方式损坏。
• 瞬态负载或其他问题会导致超时，因此必须进行转移。

根据仓库系统的要求，您可能需要容忍单个Feed的失败。您需要为此设计一个强大的错误处理策略。

合并提取与合并转换

如果系统相同（例如零售商店链中的POS系统），您可能会通过在转换阶段之前合并数据来获得更简单的架构。这意味着暂存区域需要知道数据源，至少是出于审计目的。

如果您有少量系统或多个异构数据源，则应在转换过程中进行数据合并。在这种情况下，对于至少某些进程，ETL可能会为每个源系统分别设置例程。

我们需要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

Answer 2

我可能会避免为所有位置创建一个主程序包。相反，创建一个可配置的包，为一个位置执行这些步骤（使用SSIS变量指定特定于位置的属性）。

现在可以从.cmd脚本运行此程序包，或者如果需要，可以创建具有多个执行进程任务的主SSIS包，每个包都使用适当的变量值启动第一个包。

P.S。是的，在主程序包中，您应该使用启动DTEXEC的执行进程任务，而不是执行包任务 - 遗憾的是，执行包不是很容易配置 - 请参阅http://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=295885。