【IT168 专稿】当所需要抽取的数据量越来越大，中间的计算越来越复杂的时候我们当初的ETL程序很有可能不能在窗口时间内完成了。这个时候我们就需要对ETL进行优化。当然如果能在设计之初就考虑到优化是最好的。

    在讨论ETL优化之前我们应该首先讨论的是当前程序的性能。首先要定义ETL过程的基线标准。在建立了基线标准的基础上我们再来讨论该如何对已有过程进行优化。

    基线标准也应该包括标准情况下网络传输速度，硬盘读取速度等等的硬件指标。在此之上测量多次ETL过程得到比较稳定的 数据量(M)/时间(s) 的比值作为基线标准。当然前提是在一定的范围内数据量的增长和计算量的增长一定要呈线性关系。一种比较理想的假设就是每条数据都经过相同的计算/转换过程。

    建立基线的好处在于有了调试以及优化的依据。最大程度地避免了人的主观感觉所造成的错误判断。
“经过优化，现在的ETL性能好了一些！”这种话应该换成“经过优化，现在性能比基线性能提升了1%”

    当然我们最终的目的是进行ETL过程的优化。优化的方面包括索引的调整，数据抽取的并行处理，复杂运算的程序处理等手段。编写出高效的SQL则应该是必备的条件了！

    笔者当初经历过一个项目。用的SQL SERVER自带的DTS作为ETL工具。在项目设计阶段没有考虑ETL的性能问题。但项目本身对时间要求还比较严格。要求每半小时同步一次。在原形阶段根本体现不出问题，只重点讨论了展现的方式和内容，确认了ETL过程的逻辑。但随着开发过程中实现的功能越来越多，算法越来越复杂，需要处理的数据也是越来越多 每次ETL过程所需要的时间不断增长，无法满足每半小时同步一次的需求。没办法减少需求和数据量，只好着手开始优化。

    开始优化之前先分析了一下整个ETL过程。发现大致可以分为两类操作。一类操作是直接从数据源拷备数据到目的数据库，一类是从数据源获得原始数据在ETL过程中进行计算再把结果存到目的数据库中。

    从传输的数据量来看直接拷备的部分数据量比较小，需要计算的部分数据量较大。两者比例大概 30% / 70%。

    我们首先从直接拷备的数据开始入手。先测试了一下网络环境，因为两台服务器在一个局域网里，网络很稳定。再分析两边的数据库情况。数据源是Oracle没法动。目的数据库是SQL SERVER目的表建立了多种索引是为了提高前端展现时的效率。