Look up:
Look up组件做的事情和SQL SERVER中的inner和outer hash join差不多。
但是look up每次只能有两张表参与。
在FULL-CACHE模式下，两个source的其中一个会被完整地load进内存，然后另一个source每次load一部分数据进到缓冲区再做匹配。
Look up可以有三个输出：1）matched rows；2）unmatched rows；3）error rows；
Cache Connection Manager (CCM)可以把Look up的cache存起來
在使用Look up的时候，因为Look up在cache其中一张表的时候是会block整个flow的执行的，也就是说整个执行的过程需要等待这张表的数据都被加载到内存里面才会继续往下走，这种情况下，当出现一张dim表和一张fact做look up的时候，或者说一张小表和一张大表做look up的时候，确保小表被cache。
Look up本身是没有多线程跑的：
There is no opportunity for the Lookup Transformation to implicitly perform in an SMP (or
scale-out) manner. The same applies to the Merge Join Transformation — on suitable hardware
it will run on a separate thread to other components, but it will not utilize multiple threads
within itself. --《Professional SQL Server Integration Services 2012》
其实Merge Join和Look up各有各的优劣。Merge Join虽然不要求某张表的数据都加载到内存，但是数据要事先排序，这个耗了CPU而且数据排序的过程也是要在内存中进行的。而look up的hash其实也是一个计算过程，而且重要的是这个hash join的运算必须要求整张表的数据都进到内存里面，这样会占用很大内存空间。根本没有说那个好那个坏。Merge Join寄希望于sort栏位有索引而节省CPU开销，而look up寄希望于cache的那张表不要太大，不然内存压力很大。就跟SQL Server的hash join和merger join一个道理，一般在没有索引的情况下，大表间的join都是hash优于merge，sort的开销太大了。
------------------------------------------------------------------------------------------------------------------------------------------
Merge Join:
Merge Join做的事情差不多和sql server的inner join、outer join一样，但是它不会和look up预先加载数据到内存，也不会有cache mode，它要求输入的两个源需要事先排序。你需要把源的IsSorted选项设置为True以及两个源的SortKeyPosition配置成和你要Join的key的位置一致，而且源数据的排序也必须要一致，不然数据不可能对上的，这个Merge Join就可以跑了。它不会有look up那样提供了三个输出，如果要实现look up那种unmatched的数据分流，就需要在merge后面加一个Conditional Split组件来实现。
Merge Join要比Look up节省更多的内存使用，因为Look up在Full-Cache模式下需要把其中一个输入的数据都加载到内存里面。但是Merge join两个输入源在Merge Join开始连接匹配之前要求双方把数据都准备好，这样一个缺点就是，如果A输入只有5行数据，B输入有1000000行数据，即便A输入的所有数据在B输入的前5行中已经找到了匹配，这种情况下B输入剩下的所有数据行还是需要再被继续加载。
这里有篇博文专门讲Look up：http://www.cnblogs.com/biwork/p/4245978.html
还有一篇讲了Merge Join：http://www.cnblogs.com/biwork/p/3308846.html