SSIS可靠性和擴展性—錯誤輸出

錯誤輸出可以用來提高可靠性，但是它還有一個目的是改善可擴展性。可靠性方面，他們可以用來拷貝出錯誤數據。通過合適的配置可以將錯誤的數據從主要數據流中分離出來輸出到下游系統中。這些數據將會特別處理或者是被清洗然后返回到主數據流中。他們可以被顯示地合并，例如使用Union轉換，或者是隱式地合并數據很少被丟棄，很多時候他們被記入日志中或者在后續步驟中處理。

如果一些數據在析取的時候丟失，但是最終還是需要這些數據，錯誤輸出可以用來解決這個問題。如果可以在其他的數據源中獲得這些錯誤數據，可以使用LookUp轉換找到這些數據。如果不能再其他的地方獲得這些，可以使用默認值選項配置。

在另外一些場景中，數據可能超出處理范圍或者目標容器的范圍，如果這些數據造成完整性驗證錯誤，可以使用一些依賴約束獲得新的數據，進而這些數據可以正常地處理。如果數據類型出現沖突，可以簡單的使用截斷處理，也可以使用一套額外的邏輯來處理，例如將時間轉換成特殊的格式。

當對數據進行類似這樣的假設和處理之后，要進行適當的標記或者解釋說明，這樣當后續有新的需求的時候就可以有所參照，或者其他的使用者參照。
上面所有的場景都是圍繞著恢復臟數據，維持數據流的持續處理，盡量將錯誤數據恢復出來。和DTS比較起來這是一個新的概念，在處理數據的時候實時地處理錯誤數據是一個很有意義的工作。

還有一個問題：為什么不直接在主數據流中對這些數據進行轉化處理進而避免出現錯誤呢？這就意味著所有的數據流只有一個流向，看起來更加簡單，沒有分支。事實上，如果能夠一直使用最少的數據轉換，最簡單的數據流，這樣越簡單，可靠性和可擴展性就越高。

如圖1實例。在這個人為的例子中SpecialtyCode和ConsultantCode列一些數丟失了。數據源中還有一個描述列，所以可以使用lookup來檢索這是丟失的數據。最初的時候可能是使用Conditional Split轉換將丟失的數據設置為NULL。一旦使用LookUp處理了這些Null值，就可以使用Union All轉換來將他們重新合并到主數據流中。用這種方式處理SpecialtyCode和ConsultantCode兩個列保證最終寫入到目的中的數據全部都是合適的數據。這種方法是處理這類問題的最好方法。

圖1

如圖2是兩種可選的數據流設計。在第一種設計中忽略掉SpecialtyCode和ConsultantCode的所有可能出現的問題直接使用LookUp來處理，看上去可能會有點費力，但是所有的步驟更加簡單，他要比圖2中的設計快2%。這個結果是使用1/3缺陷的測試數據得到的，就是3行數據中就有1行數據，SpecialtyCode列或者ConsultantCode列有缺失。如果缺失率是1/6二者的效率是相同的。

圖2

第二種設計假設所有的數據沒有缺陷，所以直接寫入到目的。如果出現錯誤數據會被寫入到錯誤輸出中，OLE DB Destination Error OutPut，然后通過兩個LookUp來處理。這兩種設計的區別是：是否只處理有問題的行還是對所有的列都進行處理。使用1/3缺陷幾率的測試文件，只處理有問題的行會快20%，當缺陷幾率是1/6的時候會有所下降只有10%。

通過上面的例子我們可以看到，具體選擇哪種設計要依據測試文件或者測試數據的缺陷率。

這里矯正數據的性能表現也應考慮在內。在上面的例子中，使用LookUp是一個非常昂貴的轉換。在測試數據中和LookUp參照表中只有6條不重復的數據，這樣見笑對整個測試性能的影響。在參照表中如果有更多的不重復值，對性能的影響更大，更多的數據會需要更多的緩存，會耗費更多的資源。

對數據驗證越嚴格，就要處理更多的缺陷數據。對于缺陷數據較少的，或者昂貴的驗證過程，盡量使判斷流程簡單，使用錯誤輸出來處理那些缺陷數據。

所有數據的行數也會影響數據流的設計，因為任何的優點和缺點都會影響大量的數據。如果數據量較小，肯能占用的資源較少，但在運行的時候任何轉換都會有資源損耗，所以更加復雜的設計在數據量較少的時候則可能得不償失。

這種使用錯誤輸出的方式和在主數據流中糾正數據都可以使用，沒有限制。你盡可以使用圖2中的那種處理方式。保證盡量少的數據流向代價昂貴的處理流程，多數的數據流向主要流程中。

最后，不要拒絕使用錯誤輸出。開發者可能會經常使用那些復雜的，高級的轉換，但要記住，錯誤輸出是一種最簡單的方式處理錯誤的數據，他們不會影響包中的其他轉換，所以不要拒絕使用錯誤輸出。

這里所說的改善性能只是一個引導作用，這里只是介紹設計方式的不同，不要將它作為教條來執行，除非你遇到完全相同的場景，相同的數據，相同的問題。唯一不變的原則是進行對比測試，然后得出更好的設計。