如何處理ETL任務？

Question

我應該執行ETL，其中源是一個大型且設計不佳的sql 2k數據庫和一個設計得更好的sql 2k5數據庫。我認爲SSIS是要走的路。任何人都可以提出一個待辦事項清單或清單或要注意的事情，以便我不會忘記任何事情嗎？我應該如何解決這個問題，以便它不會在後面咬我。

Answer 1

那麼我正在爲我所在的公司開發一個ETL。

我們正在與SSIS合作。 使用api來生成和構建我們自己的dtsx包。

SSIS它不適合管理錯誤。有時你會得到一個「OleDb錯誤」，根據上下文可能會有很多不同的含義。

閱讀API文檔（他們不多說）。

一些鏈接來幫助你開始有： http://technet.microsoft.com/de-de/library/ms135932(SQL.90).aspx

http://msdn.microsoft.com/en-us/library/ms345167.aspx

http://msdn.microsoft.com/en-us/library/ms403356.aspx

http://www.codeproject.com/KB/database/SSISProgramming.aspx?display=PrintAll&fid=382208&df=90&mpp=25&noise=3&sort=Position&view=Quick&fr=26&select=2551674

http://www.codeproject.com/KB/database/foreachadossis.aspx

http://wiki.sqlis.com/default.aspx/SQLISWiki/ComponentErrorCodes.html

http://www.new.facebook.com/inbox/readmessage.php?t=1041904880323#/home.php?ref=logo

http://technet.microsoft.com/en-us/library/ms187670.aspx

http://msdn.microsoft.com/ja-jp/library/microsoft.sqlserver.dts.runtime.foreachloop.foreachenumerator.aspx

http://www.sqlis.com/post/Handling-different-row-types-in-the-same-file.aspx

http://technet.microsoft.com/en-us/library/ms135967(SQL.90).aspx

http://msdn.microsoft.com/en-us/library/ms137709(SQL.90).aspx

http://msdn.microsoft.com/en-us/library/ms345164(SQL.90).aspx

http://msdn.microsoft.com/en-us/library/ms141232.aspx

http://www.microsoft.com/technet/prodtechnol/sql/2005/ssisperf.mspx

http://www.ivolva.com/ssis_code_generator.html

http://www.ivolva.com/ssis_wizards.html

http://www.codeplex.com/MSFTISProdSamples

http://www.experts-exchange.com/Microsoft/Development/MS-SQL-Server/SSIS/Q_23972361.html

http://forums.microsoft.com/MSDN/MigratedForum.aspx?siteid=1&PostID=1404157

http://msdn.microsoft.com/en-us/library/aa719592(VS.71).aspx

http://forums.microsoft.com/MSDN/MigratedForum.aspx?siteid=1&ForumID=80

http://blogs.conchango.com/jamiethomson/archive/2005/06/11/SSIS_3A00_-Custom-Logging-Using-Event-Handlers.aspx

http://blogs.conchango.com/jamiethomson/archive/2007/03/13/SSIS_3A00_-Property-Paths-syntax.aspx

http://search.live.com/results.aspx?q=%s&go=Buscar&form=QBJK&q1=macro%3Ajamiet.ssis

http://toddmcdermid.blogspot.com/2008/09/using-performupgrade.html?showComment=1224715020000

http://msdn.microsoft.com/en-us/library/ms136082.aspx

http://support.microsoft.com/kb/839279/en-us

對不起， 「垃圾郵件」，但他們對我非常有用的。

Answer 2

我們正在做一個巨大 ETL（移動從傳統AS400應用到Oracle EBS客戶端），而我們實際上有一個過程，（有修改），我可以推薦：

1. 確定關鍵目標 表/字段。
2. 確定關鍵的 源表/字段。
3. 與 商業用戶合作將源映射到 目標。
4. 分析 質量問題的源數據。
5. 確定誰是 負責數據質量問題 確定。
6. 有責任方 清理源中的數據。
7. 從步驟開發基於 信息的實際ETL 1 - 3

最棘手的步驟是在我的經驗2 & 3 - 它有時很難得到企業用戶正確識別所有的位，他們需要一次通過，並且可能更難以正確識別數據來自哪裏（雖然這可能與我看到的神祕文件和字段名稱有關）。但是，這個過程應該可以幫助你避免重大失誤。

Answer 3

我對ETL過程有經驗，每天，每週，每月和每年將數據從200多個分佈式數據庫提取到中央數據庫。這是一個大量的數據，並且我們有很多問題具體到我們的情況。但在我看來，有幾個項目去想不管形勢：

• 確保你把文件鎖定的考慮，無論在源和目標端。確保其他進程沒有鎖定文件（並在必要時刪除這些鎖，這很有意義）非常重要。

• 爲自己鎖定文件。請確保，特別是在您拔出數據時鎖定文件的源代碼，以避免中途更新數據。

• 如果可能的話，拉動deltas，而不是所有的數據。獲取數據的副本，然後只取出已更改的行而不是所有的行。數據集越大，這變得越重要。如果需要的話，查看期刊和觸發器，但由於在某種基礎上獲取這些數據變得更重要，這可能是我會給你的頭號建議。即使它爲項目增加了大量時間。

• 執行日誌。確保你知道什麼時候工作，什麼時候沒有工作，並且在過程中拋出特定的錯誤可以真正幫助調試。

• 文件，文件，文件。如果你建立這個權利，你會建立它，然後長時間沒有考慮它。但是你可以保證，你或其他人需要在某個時候回到它來增強它或者修正錯誤。文檔是這些情況下的關鍵。

HTH，如果我想到其他東西，HTH會更新這個。

Answer 4

一些一般性的ETL提示

1. 考慮 目的地組織它（例如，所有的 代碼生成客戶 尺寸住在同一模塊中，無論其來源）。 這有時被稱爲 面向主題的ETL。它使 找到更容易的東西，並將 增加您的 代碼的可維護性。

2. 如果SQL2000數據庫是一個爛攤子， 你可能會發現，SSIS 數據流處理 與數據的笨拙方式。通常，ETL工具 規模較小且複雜; 類似於所有數據的一半 財務倉庫項目 公司已完成存儲 程序代碼作爲明確的 架構決策 - 正是出於這個原因。如果您有 需要在 sprocs中輸入大量代碼，請考慮將代碼中的所有代碼放在sprocs中。
   
   對於涉及大量複雜清理或轉換的系統，100％sproc方法更具可維護性，因爲它是將所有轉換和業務邏輯放在一個位置的唯一可行方法。使用混合的ETL/sproc系統，您必須查看多個位置才能跟蹤，排除故障，調試或更改整個轉換。

3. ETL工具的甜蜜之處在於您擁有大量數據源且具有相對簡單轉換的系統。

4. 使代碼成爲可測試的，因此您可以將 拆開組件並單獨測試 。只能在ETL工具的複雜數據流中執行的代碼很難測試。

5. 使數據提取啞而沒有 業務邏輯，並複製到 臨時區域。如果您的業務邏輯分佈在提取層和 變換層中，那麼您將有 轉換，這些轉換無法孤立地進行測試 ，並且很難 跟蹤錯誤。如果轉換是從分段區域運行的 ，那麼您將減少對源系統的嚴重依賴，從而再次增強可測試性。這是基於sproc架構的一個特別的勝利，因爲它允許幾乎完全同質的代碼庫。

6. 建立一個通用的緩慢變化的 尺寸處理程序或使用一個關閉 貨架（如果可用）。這使得它更易於單元測試這個 的功能。如果這樣可以對單元 進行測試，系統測試並不是 必須測試所有的角落情況， 僅僅是數據呈現給 它是正確的。這並不像聽起來那麼複雜 - 我寫的最後一個是大約600或700行的T-SQL代碼。任何通用清理功能都是一樣的。

7. 如果可能的話，增量加載。

8. 儀器的代碼 - 讓它做日誌條目，可能記錄診斷，如檢查總數或計數。沒有這個，故障排除幾乎是不可能的。此外，斷言檢查是考慮錯誤處理的好方法（在b中的行計數是否相等，A：B關係實際上是1：1）。

9. 使用合成鍵。使用源系統中的自然鍵將您的系統綁定到數據源，並且很難添加額外的源。系統中的關鍵和關係應始終排隊 - 無空位。對於錯誤，「未記錄」，請在維度表中製作特定的「錯誤」或「未記錄」條目並與其匹配。

10. 如果構建Operational Data Store（許多宗教戰爭的主題），請不要回收星型模式中的ODS密鑰。通過一切手段加入ODS鍵來構建維度，但匹配一個自然鍵。這使您可以任意刪除和重新創建ODS - 可能會更改其結構 - 而不會干擾星型模式。擁有這種能力是一個真正的維護勝利，因爲您可以隨時更改ODS結構或在任何時候對ODS進行暴力重新部署。

點1-2和4-5的意思是，你可以建立一個系統，如果對於任何給定子系統的代碼所有（例如一維或事實表）住在一個只有一個地方系統。這種類型的體系結構對於大量的數據源也更好。

點3是點2的對應點。基本上，SQL和ETL工具之間的選擇是轉換複雜性和源系統數量的函數。數據越簡單，數據來源越多，基於工具的方法的情況就越強烈。數據越複雜，轉移到基於存儲過程的體系結構的情況越強烈。一般來說，最好是完全或幾乎完全使用一種或另一種，但不能同時使用兩種。

點6使您的系統更容易測試。測試SCD或任何基於更改的功能都很麻煩，因爲您必須能夠向系統呈現多個版本的源數據。如果將變更管理功能移到基礎結構代碼中，則可以使用測試數據集獨立進行測試。這是測試中的一個勝利，因爲它降低了系統測試要求的複雜性。

第7點是一般性能提示，您需要觀察大量數據。請注意，您可能只需要對系統的某些部分進行增量加載;對於較小的參考表和尺寸，您可能不需要它。

點8與任何無頭過程密切相關。如果它在夜間出現問題，那麼你希望有機會看到第二天出了什麼問題。如果代碼沒有正確記錄正在發生的事情並發現錯誤，那麼對它進行故障排除將會更加困難。

第9點給數據倉庫自己的生活。當倉庫擁有自己的密鑰時，您可以輕鬆添加和刪除源系統。倉庫密鑰也是實現緩慢變化的維度所必需的。

第10點是維護和部署勝利，因爲如果您需要添加新系統或更改記錄的基數，可以重新構建ODS。這也意味着一個維度可以從ODS中的多個位置加載（想想：添加手動會計調整），而不依賴於ODS密鑰。

Answer 5

此線程舊，但我想提請您注意ConcernedOfTunbridgeWells的答案。在所有方面，這是非常好的建議。我可以重申一些，但這會減少其餘的，他們都值得仔細研究。