微软BI 之SSIS 系列 - 再谈Lookup 缓存

开篇介绍

关于 Lookup 的缓存其实在以前的一篇文章中已经提到了  微软BI 之SSIS 系列 - Lookup 组件的使用与它的几种缓存模式 - Full Cache, Partial Cache, NO Cache 可是仍是可能遗漏的部份内容，所以在这里从新总结并补充一下。这是第一篇，仍是从理论的角度来讨论 Lookup 缓存的问题；后面有空还会再写一篇，从后台 SQL 执行的状况来理解 Lookup 的工做过程。

 

而且关于 Lookup 缓存还有其它比较有意思的话题，好比个人这些帖子，你们均可以关联起来看看：

• 微软BI 之SSIS 系列 - Lookup 中的字符串比较大小写处理 Case Sensitive or Insensitive

咱们仍是从 OLE DB Connection Manager 下的这三种缓存模式来讨论：Full Cache 彻底缓存，Partial Cache 部分缓存，NO Cache 不缓存

在下面示例中， FF_SRC_INTERNET_SALES 是文件数据输入源，LKP_SALES_ORDER_NUMBER 是 Lookup 组件。

Full Cache 彻底缓存

彻底缓存 - Lookup 的默认缓存。

第一步：在这种模式下，在数据流预执行 Pre-Execute 即执行以前就会将查询发送给数据库服务器并将数据查询后返回，并缓存到 SSIS 运行时内存中。以后，右侧数据库中的数据即 Lookup 中配置的视图或表 【T032_SALESORDER】中的数据发生任何变化跟缓存中的数据是没有任何关系的。

第二步：数据流此时才开始执行，缓存中已经含有数据了，这时来自于 FF_SRC_INTERNET_SALES中数据就会经过以前配置好的匹配规则使用列 SalesOrderNumber 和 列SalesOrderLineNumber 的值到缓存中查找有没有匹配的 SalesOrderNumber 和 SalesOrderLineNumber。

第三步：若是在缓存中匹配到了相应的数据，那么上图中 Available Input Column (即文件源中的列) 和 Available Lookup Column (即缓存中的列 - 视图或表 T032_SALESORDER 中的列) 中被打勾的列 (此示例中无勾选上的选项) 共同造成一个输出列组：Available Input Column + Available Lookup Column 选中的列向下输出，输出的名称默认叫作  Lookup Match Output。

第四步：若是在缓存中找不到相应的数据，那么根据不匹配的规则（这里选择的是 Redirect rows to no match output）将 Available Input Columns 中的数据做为不匹配数据往下输出，输出名称叫作 Lookup No Match Output。注意：错误数据的内容就不是 Available Input Columns 中的数据了。

那么上面的几个步骤就是在 OLE DB Connection 下的 Lookup 的彻底缓存模式与查找输出的流程。

主要特色

• 数据流启动以前（甚至更早，在包执行以前）完成数据查询与缓存动做，查询结果集缓存起来。
• 消耗内存大，增长了数据流启动的时间。
• 在数据流执行的时候很是快，源数据直接和缓存数据作比较，不用再次查询数据库。
• 缓存数据源中的数据变动将也再也不影响到缓存中的数据。
• 若是缓存的数据容量超过了内存的大小，那么会出现内存不足报错 Out Of Memory，由于缓存不会主动把数据写入到磁盘上。

什么时候使用彻底缓存 Full Cache 

• 引用数据集中的数据量不管大小，只要不超过内存大小，特别当数据源的数据和引用数据集匹配程度高的时候，一次缓存能够反复使用。
• 数据库服务器不在本地，或者数据库服务器压力很大，为了减小反复的链接反复的查询对数据库服务器形成更大的压力。

使用彻底缓存 Full Cache 中的关键点

• 数据所有缓存在内存中，若是内存不够并不会将超出部分的数据缓存到磁盘上，而是直接报错 - Run out of memory。
• 因为数据集缓存在内存中，因此在使用 Lookup 的时候不该该直接使用表对象，而应该经过写 SELECT 语句来减小没必要要的列输出而且能够加上 WHERE 条件来限定一下数据集的大小，简而言之缓存的数据应该只包含有用的数据。
• 数据一旦缓存，那么在数据流执行过程当中就不会再去检测以前源数据是否发生改变或者更新等等，除非数据流从新启动执行。

Partial Cache 部分缓存

第一步：部分缓存模式下，在数据流执行之初 Lookup 缓存仍是空的。当 Lookup 组件开始读入 FF_SRC_INTERNET_SALES 数据源中的列时，此时由于须要对比才开始检查缓存中是否有匹配的值。

第二步：缓存中若是有，则直接能够做为匹配输出向下输出了。

第三步：缓存中若是没有，这时就会发送查询到数据库中进行查询（查询语句能够配置参数）。若是在数据库中查找了就会将这个已查到的内容缓存在匹配缓存区中，以供下次使用，此次仍是匹配输出。 

第四步：若是缓存中没有，查询数据库后也没有，根据配置能够将此条在缓存中没有在数据库中也没有的数据按照配置放在不匹配缓存区以供下次作不匹配检查。由于都查找不到，所以此次是不匹配输出。

特色

• 数据流启动以前，缓存为空，数据流启动时间要比彻底缓存的状况下要快。
• Lookup 的时候会慢，由于总要检查缓存，若是有的话就直接用，若是没有的话就须要查询数据库，每次查询都是一次开销。若是数据量比较大的话，这种频繁的查询对数据库服务器压力会比较大。因此从 FF_SRC_INTERNET_SALES 到 LKP_SALES_ORDER_NUMBER  数据流的传递明显要慢，传递一批等一会，由于此时 LKP_SALES_ORDER_NUMBER 须要到数据库中去查数据。即时当 FF_SRC_INTERNET_SALES 数据抽取完毕以后，下面的三个控件还要执行半天。
• 能够在 Advanced Options 中设置最大缓存（32位模式和64位模式两种选择），一旦缓存中的实际数据大小超过这个最大值的话，就会自动清理那些对比中较少使用的行以便为新的数据腾出空间。
• 能够在 Advanced Options 中设置不匹配缓存区所占缓存区的比例，这样在一条源数据在匹配缓存中查询不到，在数据库中也查询不到的情形下，这条数据的关键比较列就会存入不匹配缓存区。下次来的数据若是还在匹配缓存区中找不到的时候，就会先看看不匹配缓存区中是否存在，这样就会减小对数据库的反复查询的概率。若是数据源中的数据与 Lookup 引用集中的数据匹配率很低，能够适当的提升不匹配缓存区的比例。
• 当某次查询数据库时发生 Lookup 引用数据表中的数据发生了变化，此时不匹配缓存区将会默认禁用。应该当 Lookup 引用数据表数据相对稳定没有再发生变化的时候，不匹配缓存区将会从新分配。

何时使用 Partial Cache 部分缓存

• 数据源中的数据比较少的时候，这样查询的次数就小。
• 引用数据集中的数据很大，内存没法支持的时候。
• 引用数据集源表的数据发生变化，须要在查询匹配过程当中也能知晓的状况下。
• 当须要使用参数化查询来限制引用集的大小的时候能够考虑使用 Partial Cache。

使用 Partial Cache 部分缓存要注意的地方

• 注意缓存区的大小分配尽可能足够大，上图中 25MB 实在大小。
• 合理的使用不匹配缓存区，不匹配程度高的时候提升不匹配缓存区的占比。

No Cache 不缓存

无缓存模式下，每次匹配查询都会去数据库查一次。这种缓存模式下，数据量不大而且内存比较紧张的状况下才会使用，固然它对内存的消耗也相对最小，但效率也最低。

总结

就我我的而言，目前对 Lookup 的使用配置状况基本上都默认选择 Full Cache 模式，由于如今内存的支持彻底不是什么大问题。一个 10 W 的输入 Lookup 一个 1 W 多的引用集基本上在彻底缓存模式下几秒就能够解决掉；若是换成 Partial Cache 或者 No Cache 至少超过 60秒或者更多。因此，在实际开发中基本上能够保持默认选择 Full Cache 就能够达到一个最优效率的使用，除非内存紧张才会在缓存分配比率上作文章。

跟这篇文章相关的文章还有

• 微软BI 之SSIS 系列 - Lookup 组件的使用与它的几种缓存模式 - Full Cache, Partial Cache, NO Cache 
• 微软BI 之SSIS 系列 - Lookup 中的字符串比较大小写处理 Case Sensitive or Insensitive

更多 BI 文章请参看 BI 系列随笔列表 (SSIS, SSRS, SSAS, MDX, SQL Server)  若是以为这篇文章看了对您有帮助，请帮助推荐，以方便他人在 BIWORK 博客推荐栏中快速看到这些文章。