在TechEd 2010上讲了一门如何构建企业级ETL的Session，可能是因为技术方面的东西太多，没有什么太炫的Slides和Demo，听众反映一般，8.08分不太高，这里在把东西解释解释。 当时主要是因为工作比较忙，准备PPT和Demo就用了1天半的时间，确实有点仓促了，但是内容上感觉还是比较丰满的，主要目的就是给听众一个理念上的引导。 目前在企业里面用SSIS的客户还是比较多，但是大多数人还仅仅停留在如何使用SSIS进行转换，很多学习的教程也都是写那些控件的使用方法。实际上工程项目中遇到的一些实际问题是不能通过简单的控件来解决的，必须要有巧妙的设计，这个道理就像写程序一样，否则也就不会有设计模式这个领域了。 SSIS中提供了一个扩展性很强的框架，Control Flow&Data Flow，具体概念我就不多说了，有人反映我讲课的时候经常重复这些东西，其实也不是重复，只是很多人没有深入的理解。我们的设计其实很多地方都会在Control Flow里面进行体现，所以要有好的设计，就必须先理解Control Flow。除了理解Control Flow外，对于Parameter和Configuration的灵活应用也非常重要，这些都是在进行控制的过程中必不可少的连接技术，没有这些东西也无法把不同功能的包和流程组织在一起。另外一个重要的功能就是Script，Script是整个包设计里面的灵魂，很多动态功能都要依赖于此，而且Script中写的不再是vbScript和VB.net，我们可以写C#了，功能上丰富多了，尤其是对象参数和C#的结合。我们可以设置任何Object对象参数，在Script里面就意味着我们可以传递更丰富的内容，而不仅仅局限在基本数据类型，例如int,string等，我们可以传递类似于array,list等更高级的参数类型，提供更灵活的调用。有了Parameter,Configuration,Script，我们可以借助于一些容器控件来实现更多功能，具体能实现什么，就看你想怎么设计了，至少SSIS已经提供了这个框架。 另外对于企业来说SSIS的性能也是需要特殊注意，因为SSIS操作过程中对于系统整体来说都会有短时的压力，需要在规定的时间窗口内完成ETL的过程，否则可能会影响其他业务系统的正常运行。大部分用户都会遇到性能问题，而多数性能问题都是由于下列原因引起的 数据源读取速度 目标写入速度 转换过程设计 数据读取速度 这个部分的原因要看数据源系统的情况。我们都希望对整个系统来说有一个有效的方式进行性能评估及性能优化，所以我建议这个数据源部分使用可以分割边界的系统，也就是说不要用可能过分依赖于网络，远程站点等异步的数据源系统。文件和本地局域网数据库都是比较好的选择，至少网络延时可以忽略不计，否则的话性能上的SLA很难评估，相比局域网数据库或文件系统性能的稳定性比远程HTTP或Web Service要好很多。有了稳定的数据源就要评估这种数据源的极限读取能力，也就是做Baseline，这个很重要，因为你的系统性能的极限和这个有很大关系，但是这个极限并不是不能突破，关键看设计，至少在没有特殊设计的情况下，极限性能就是对于数据源单纯的读取性能。如果数据源是关系型数据库，就需要对数据库或者查询进行优化。 目标写入速度 这方面我就不多说了，微软专门有相应的文章写了如何进行快速的数据装载，主要的问题就是No Log或者Mini Log的设计。这个过程也相对好进行评估。用BCP就能测试出来。 转换过程设计 这个部分相对来说可以做的事情比较多。SSIS的Data Flow就是Pipeline模式，你要做的事情就是让数据能够流动起来，别有堵塞。聚合、排序都会有阻塞，都要慎用。另外Merge Join也要注意，这个需要2个流入的数据源是排序的，这种排序最好考虑在数据源里面实现。如果数据源不支持，例如文件系统，可以通过SQL做一个Staging的数据库，临时排序使用，至少可以利用内存和tempdb排序，而SSIS都是在内存里面排序，你不一定有足够大的内存，至少我遇到在224G内存的服务器上出现内存不足的情况，当时的数据量是1TB。另外就是内存的占用和我们每行数据的长度及数据类型都有关系，要精确设计一下，不能用Select *这种方式，如果文件系统，需要在读取的时候转换一个准确的数据类型。 上面说了3中在Data Flow常见的设计问题和思路，在Control Flow里面的事情比较多，但是最常见的就是并行设计。很多情况下并行设计能大幅度提升你系统的性能。多数情况下，SSIS服务器并没有发挥出系统的整体性能，只要找到不同时期的性能瓶颈，逐步优化后都能有很好的性能提升，但是并行是大家经常忽略的一种情况。如果你发现你的IO，网络，内存都不存在瓶颈的时候，你要提升性能，就要注意看一下CPU了。对于CPU利用率来说，我们不能看整体，因为多核和多CPU情况下，我们必须要看每一个核的利用情况，很有可能一个核已经100%利用率，但是系统只能一个线程，这个时候必须要考虑多线程设计。SSIS设计上并没有直接提供对于线程的控制，真的没有做到与时俱进，目前很多服务器上都是4-6个核，4CPU的服务器也很多，通常每个核提供20MB/s以上的吞吐量，你可以评估一下，你的系统能够做到的性能极限是多少。我在一个测试过程中在96核的系统上可以做到大约1TB/s的数据吞吐，这还是我限制了40个线程。但是线程的设计比较复杂，需要考虑数据源的形式及特征以及Control Flow中流程的关系。基本上都是通过脚本结合流程控制组件来动态控制，目前除了这个没有其他的办法。微软目前可以提供一个Data Flow层面的转换组件RRD(Round Robin Distributor)在Data Flow里面实现多线程，目前这个组件还没有Release。如果大家在项目里面有需求，可以找我联系。 先写到这里，后面有时间在讲讲如何使用Control Flow。
转载于:https://www.cnblogs.com/weisun/archive/2010/12/16/2659284.html