你可能对扩展性这个概念非常的熟悉，当然在SSIS中也有这个概念。这里有几个很有特色的属性，这一个小节的内容中将介绍如何在SSIS中使用可扩展性特性。
扩展内存
在设计SSIS之初，数据传输的操作都发生在内存中，这样会使数据传输和转换更加的快，一个设计目标是数据传输只有一条路径。这样消除了多次读取或者写入数据造成的时间消耗。这样有一个缺点是你需要大量的数据和复杂的数据转换要吃掉大量的内存，所以需要合适的对内存使用进行调优。
默认情况下32位的操作系统的虚拟内存是2GB。当然我们可以修改boot.ini文件把它修改成3GB，不过这样做会导致内存不够的现象。在执行单个的package的时候经常会出现这种情况，通过将一个package切分成多个package的方法可以是每个小的package占用较少的内存，这样就可以充分利用2-3GB虚拟内存带来的便利。最常用的差分package的方法是使用Execute Package任务来调用其他的package，这样就可以将一部分子package放在另外一个进程中处理。要说明的是需要设置ExecuteOutOfProcess属性来达到这个目的。
和SQL Server数据库引擎不同的是SSIS不支持地址窗口扩展，通过切分package的方法是唯一可以提高内存利用率的方法。如果还需要更多的内存的话就要考虑使用64位的操作系统了。
使用staging数据扩展
分段数据是为了降低数据的数量，在可以一次处理所有数据的情况下为什么还要分段地读取或写入数据呢？在SSAS中包含了Dimension和Partition Processing Destination之后不再需要数据库数据作为数据源了。尽管这是另外一个话题，问题是我们需要在SSIS中使用分阶段的数据吗？可能这不是技术上的目标，但是在可靠性和可扩展性方面还是很多的可取之处。
这里的staging也可以称作Partition。一个data flow在一个进程中执行，但是如果考虑下面的原因这种分段就很有必要了。这些小的单元可以包含在一个小的package中或者通过下面讨论的方法来分发。分段数据只能被另外一个package来使用，不能通过其他的常规接口来使用。所以最理想的选择是原文件适配器。这可以被称之为横向分段，也可通过执行多个平行的package的方式来竖向分段。
原文件适配器允许你在磁盘上保留本地缓存。内存中的缓存结构从文件中读取或者写入，避免从其他的进程中读取或写入使得这些适配器的处理速度是最快的。可以利用这些特点在磁盘中设置一个检验点，这样就可以扫描多个数据流和package 。
原文件的关键作用是将一个任务切分成最少两个任务，主要的任务以原文件目标结束，第二个任务以原文件开始，必须保证这二者之间的缓存结构是一致的，这样拆分就被认为是一个完整的数据流任务，提供了更好的性能。
重置数据流
在前面的章节中我们已经看到检验点提供重启package的功能，但是在Data Flow中不能使用这个功能。如果把Data Flow切分成两个或更多的单个的任务，他们之间通过原文件连接起来，就可以重启整个数据流。
从哪里划分一个Data Flow要看个人的经验，有两个经常需要切分的地方，一个是分离之后，一个是转换之后，载入之前。
在分离之后进行切分有一些好处。很多情况下数据源都是远程的，所以在分离过程中网络连接可能不那么理想。在分离之后进行切分，当需要重启就不需要重复这个缓慢的步骤了。
转换之后的切分只是用来保证数据不表不可用的情况下转换不被丢弃。
你可能会在数据流中添加额外的中间转换，这样通常会耗费更多的资源，也会增加执行那个失败的风险。尽管可以使用错误输出处理可以预见的问题，还可以使用重置点来减少重新执行的工作。
如图1实例了一个例子
图1
在这个例子中数据源连接着远程数据库，由于抽取数据要耗费很多时间以及对数据源的影响，如果分支上的处理流程失败，影响到主流程需要重新执行整个流程是不可接受的。这样可以选择在源文件后面使用一个原文件来保存数据，使用原数据转换，如下图2所示。
图2
Flat文件是通过局域网中的计算机获得的，需要在它被重新写入之间获得里面的数据。如果数据量非常大，排序转换也是一个非常昂贵的操作。所以我们需要将原文件转换放在排序转换之后，如图3
图3
最后可以再添加一个Data Flow任务来放置staging之后的转换，如图4
图4
这样一个数据流转换被分割成3个，如果想重启正果处理，可以使用一个单独的包并且在三个分支中使用检验点。
跨机器扩展
将任务分割成不同的包，可以跨机器运行包。如果一个包有一些和其他的不同的配置，这样做会很有利。有可能有些机器的配置适合做数据抽取，而有些适合处理数据，他们分布在不同的网段中，不能直接从一台机器上执行这些任务。这样先通过一台机器来抽取数据放在原数据中，然后从另一台机器中处理数据。这是一种以组织为向导的而非以架构设计为向导的思想。
还有一种扩展是使用水平分割。一种简单的场景是使用两个包，第一个包从数据源中抽取数据，然后通过条件分割产生来给你个或者更多的数据分支 ， 将这些分支中的数据写入到不同的原数据转换中。最常见的分割时根据时间来进行水平分割。目的是将抽取的数据分割成不同的块。例如在数据源中有一个连续的时间数据列，这是最好不过的。在T-SQL中有个ROW_NUMBER()函数。相似的有一个第三方转换ROW NUMBER转换用来添加连续不重复的数据列，然后使用条件分割来进行分割操作。可以从www.sqlis.com或者www.konesans.com免费或者这种转换。
在一个排序的数据集中，每个原文件被按照顺序写入，然后流向下游。这样做看上去很费力，这样是假设从开始到结束的执行时间与获得连续数据列带来的效率比起来不那么重要。
获得分割的原文件之后，就可以在后续的包中使用这些原文件了。每一个包在自己的机器中使用这些原文件。通过这种方法可以在不同的机器之间扩展处理那些昂过的转换。对于较小的扩展可以不在多个机器之间，可以放置在一个单独的机器上，这样每个package单独占用一个线程，并单独地访问资源。
数据仓库中也有表分割，或者分析服务中的分割，也可以将他们映射到包中，这样每个包个一个单独的表或者分割关联起来。
如图5展示这种分割的例子。
图5
在这个例子中模糊查找姓名字段，它需要参照一个有很多条数据的表，运行过程中会耗费很多的时间。为了水平低分割它，可以按照姓名的第一个字母来分隔它，尽管在生产环境中这样可能会有一些遗漏。我们我们将姓的首字母从A到M分割到第一个原文件中，从N到Z分割到第二个原文件中。如图7
图7
理想情况下，第二个包有两个实例，如图9-39，将这两个包放置在不同的机器中。然而，不是所有转换任务都是使用表达式，有时候需要动态地控制他们，所以需要两种版本的包，如图8，新建两个视图，一个命名为A到M，另一个命名为N到Z。这两个包将会从这两个视图中模糊查找匹配的数据。
图8
在任何要使用原文件的时候都要权衡I/O，但是对于大规模的实现，原文件提供了一种方法来保证一个package执行过程中数据流不会招致其他的数据格式带来的谬误，进而保证数据正确性。
总结
在这个章节中，介绍了一些SSIS的一些特性用来帮助我们实现可扩展，可靠的设计例如事务和检验点。还可以使用数据流重启和跨机器扩展。虽然这些不是常见的技巧，毫无疑问使用他们可以实现功能强大的包。
