微軟BI 之SSIS 系列 - 再談Lookup 緩存

時間 2019-11-06

標籤微軟 ssis 系列再談 lookup 緩存欄目 Microsoft 简体版

原文原文鏈接

開篇介紹

關於 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 不緩存

無緩存模式下，每次匹配查詢都會去數據庫查一次。這種緩存模式下，數據量不大而且內存比較緊張的狀況下才會使用，固然它對內存的消耗也相對最小，但效率也最低。html

總結

就我我的而言，目前對 Lookup 的使用配置狀況基本上都默認選擇 Full Cache 模式，由於如今內存的支持徹底不是什麼大問題。一個 10 W 的輸入 Lookup 一個 1 W 多的引用集基本上在徹底緩存模式下幾秒就能夠解決掉；若是換成 Partial Cache 或者 No Cache 至少超過 60秒或者更多。因此，在實際開發中基本上能夠保持默認選擇 Full Cache 就能夠達到一個最優效率的使用，除非內存緊張纔會在緩存分配比率上作文章。