要進入開發(fā)階段，了解不同的ETL產(chǎn)品。

整個ETL系統(tǒng)中，時間或更精確的，吞吐量是主要關(guān)心的內(nèi)容。這種轉(zhuǎn)換處理任務(wù)設(shè)計的主要目的歸根結(jié)底是使得數(shù)據(jù)裝載到展現(xiàn)表中最快并使得最終用戶能快速的從這些表中得到響應(yīng)。

推或者拉：推，是源系統(tǒng)主動把文件推向ETL服務(wù)器，拉是ETL服務(wù)器主動從文件服務(wù)器上抽取文件。無論是推拉都得保證數(shù)據(jù)沒有錯誤，傳輸完成，確保傳輸完全的一個簡單的標志是使用標志（信號）文件。標志僅僅表示它相關(guān)的文件的可讀性。

預(yù)裝載中的數(shù)據(jù)排序

源數(shù)據(jù)在數(shù)據(jù)庫中的時候，排序很容易通過數(shù)據(jù)庫，查詢數(shù)據(jù)的order by來實現(xiàn)，但是如果源數(shù)據(jù)來自平面文件，那么開始ETL處理之前需要一個排序的程序：在主機系統(tǒng)中排序

使用數(shù)據(jù)庫的塊加載工具加速數(shù)據(jù)插入

用排序，抽取，聚合等方法把數(shù)據(jù)源的數(shù)據(jù)盡快的加載到ETL服務(wù)器之后，你將面臨把大量的必要的數(shù)據(jù)加載到數(shù)據(jù)倉庫。這個時候用到了數(shù)據(jù)庫管理系統(tǒng)中的塊加載功能。在數(shù)據(jù)庫交互方面，塊加載器比普通的sql語句效率更高。

Oracle 的sql loader如何提升的性能：1 SQL Loader對表使用一個排他鎖，防止其他的操作 2 在直接模式中不能強制使用數(shù)據(jù)庫約束（主鍵和唯一鍵約束，外鍵約束等）如果發(fā)生沖突，相關(guān)的索引將處于不穩(wěn)定的狀態(tài)，在重建索引之前需要手動清除 3 外鍵約束在直接加載過程中不可用，在加載后才可以重新啟用 4 在直接模式中，插入觸發(fā)器在行插入時候不被啟動

Oracle 是 sql loader SQL Server是 BulkCopyProgram

盡管在使用塊加載夾在數(shù)據(jù)到數(shù)據(jù)倉庫之前，你必須花費更多的IO性能來將數(shù)據(jù)寫到物理文件中，但是他比數(shù)據(jù)直接訪問數(shù)據(jù)庫并用insert語句來加載要塊的多

管理數(shù)據(jù)特性來提高性能

數(shù)據(jù)庫有強大的特性 如索引，視圖，觸發(fā)器，主外鍵約束等，區(qū)別于平面文件。當數(shù)據(jù)庫增長時管理這些特性將消耗大量的系統(tǒng)資源，結(jié)果是大大降低了ETL裝載過程的性能。

提高裝載性能的選項：

1 加載數(shù)據(jù)之前去除 主外鍵（參考完整性）約束。在外鍵約束的時候，每一行加載到數(shù)據(jù)庫系統(tǒng)的外鍵列的數(shù)據(jù)都要與其浮標的主鍵值進行比較。通過去除多外間約束的事實表中的外鍵約束可以大大提高性能。（當加載完數(shù)據(jù)之后啟用外鍵約束時數(shù)據(jù)庫校驗表中的每一行）

2保持數(shù)據(jù)庫統(tǒng)計表詳細到天。（數(shù)據(jù)庫統(tǒng)計表由數(shù)據(jù)庫管理系統(tǒng)管理，他跟蹤所有表的大小，索引中唯一值的大小和數(shù)量以及其他關(guān)于數(shù)據(jù)如何有效存儲在數(shù)據(jù)庫中的事實，當一個sql語句提交到數(shù)據(jù)庫管理系統(tǒng)，他使用這些統(tǒng)計表來判斷提供請求的數(shù)據(jù)的最快的訪問路徑，最理想的是每次加載完之后更新統(tǒng)計表）加載處理是經(jīng)常性的。分區(qū)存儲大表能提高更新統(tǒng)計表的速度，因為統(tǒng)計表不必刷新所有的靜態(tài)分區(qū)而僅僅是當前的分區(qū)

3在數(shù)據(jù)庫中重組碎片數(shù)據(jù)，當經(jīng)常性的更新或者刪除會使得表變成碎片，導(dǎo)致響應(yīng)時間變慢。處理大事實表的時候，最小化發(fā)生類似碎片的一種方法是創(chuàng)建分區(qū)表。一般根據(jù)時間分區(qū)

次序

當加載一個數(shù)據(jù)倉庫的時候，一個批處理中作業(yè)的排列次序是至關(guān)重要的，主要原因是ETL需要在數(shù)據(jù)倉庫中強制參考完整性（RI）。ETL處理要避免在數(shù)據(jù)倉庫中創(chuàng)建孤兒（外建不存在主建）

執(zhí)行參考完整性：數(shù)據(jù)倉庫的數(shù)據(jù)是通過一個可控的過程-ETL系統(tǒng)以塊的方式加載的。數(shù)據(jù)進入數(shù)據(jù)倉庫的入口是可控的和可管理的環(huán)境，數(shù)據(jù)庫級別的RI約束一般在數(shù)據(jù)倉庫中不起作用，因為數(shù)據(jù)倉庫以來ETL來保證其完整性。RI在數(shù)據(jù)倉庫中一般不用的另外一個原因是這樣會在數(shù)據(jù)庫級最小化管理費用來增加加載性能。當數(shù)據(jù)庫中的RI啟用的時候，每行數(shù)據(jù)在插入之前都要測試是否符合RI，也就是每一個外建都有一個父在他所要參考的表中。數(shù)據(jù)倉庫的RI比交易系統(tǒng)的簡單，交易系統(tǒng)中每個表和其他的表相關(guān)，引起相關(guān)表的復(fù)雜網(wǎng)。在緯度的數(shù)據(jù)倉庫中規(guī)則很簡單：事實表的每一個外建都必須在緯度表中有一個相關(guān)的主建，緯度表中的每個主建不必再事實表中有一個相關(guān)的外建。實際上，事實可能與一個緯度中的多個記錄向關(guān)聯(lián)（緯度可能是雪花形）

以下的列表提供一個對一個假設(shè)的數(shù)據(jù)集市的加載過程的順序位置的指導(dǎo)。1 子維度(支架) 2維度3橋連接表4事實表5層次映射6聚合(縮小的)維度7聚合事實表

子緯度： 一個子緯度，是直接將一個緯度附加到另外一個緯度上，這個時候可以叫做雪花模型。子緯度一般地一個加載到數(shù)據(jù)倉庫中，因為依賴關(guān)系鏈始于最遠的表，也就是子緯度。事實表依賴惟獨，而惟獨依賴子緯度。

緯度：一旦子惟獨加載了，你就可以加載惟獨了，唯獨需要用子惟獨中的代理建來做對照，因此它可以在加載過程中插入到惟獨中。緯度家在必須在繼續(xù)處理之前完全成功，如果失敗，調(diào)度程序必須在那個失敗點上停止加載過程來阻止剩下的作業(yè)的加載。

橋連接表：當一個事實表的記錄對應(yīng)多個緯度記錄的時候，橋連接表位于惟獨表和事實表之間，橋連接表也可以用在唯獨表和多個子惟獨表關(guān)系中。這些標在惟獨表完成之hou事實表加載之前開始立即加載

事實表：在這里RI是強制的，因此必須確保事實表中每一個外建都有來自相關(guān)緯度或者橋連接表的相應(yīng)的主建。事實表一般在數(shù)據(jù)倉庫加載中是各種表類型中最耗時的；你應(yīng)該在所有與這個事實表相關(guān)的表都已經(jīng)加載后才開始加載事實表。不要等到數(shù)據(jù)倉庫中所有的維度表加載完成才開始進行事實表的加載。由于存儲在事實表中的數(shù)據(jù)容量一般非常大，以并行處理來加載是不錯的思路。調(diào)度程序應(yīng)該將ETL 過程分為多個線程，這樣可以同時運行并從并行處理獲益。

層次影射表：層次影射表專門設(shè)計來在惟獨中的層次中來回移動。層次影射表不依賴于事實或者橋連接表（除非事實表包本身含層次）。一般來說，層次表可以緊跟在與之相關(guān)的惟獨表后加載。無論層次在批處理中物理位置如何，他的成功失敗都不影響這個皮處理中的其他的處理。不要因為層次影射表失敗就終止已經(jīng)開始的事實表的處理，影射表可以獨立的重新開始任何事實表的加載。

聚合和分組對性能的影響：聚合函數(shù)和group by語句要求數(shù)據(jù)庫利用大量的臨時表空間。臨時表空間是DBMS管理的一個特殊的區(qū)域，用來存儲需要處理的某些包含排序查詢的工作表。SQL在執(zhí)行它的服務(wù)器上進行處理。這就意味著如果你試圖在你的抽取查詢中進行數(shù)據(jù)聚合，你將很可能撐破源交易系統(tǒng)分配的臨時表空間。當你需要建立一個聚合表時，比較好的處理是利用ETL 引擎或第三方工具的特殊功能來加快排序數(shù)據(jù)的速度。你應(yīng)該使用支持增量更新到聚合的專門工具來逐步調(diào)整你的聚合。

不要試圖用帶Group By 語句的SQL 在你的數(shù)據(jù)抽取查詢中執(zhí)行聚合。GroupBy語句用語句中所有的列來建立一個隱含排序。交易系統(tǒng)一般不會配置來處理巨大的排序操作，因為這樣的查詢可能摧毀源數(shù)據(jù)庫。抽取必要的原子級數(shù)據(jù)并隨后在ETL 管道中利用ETL 引擎或?qū)Ｓ?/strong>排序程序來聚合