ETL的一些概念和問題（轉）

1. What is a logical data mapping and what does it mean to the ETL team?

什麼是邏輯數據映射？它對ETL項目組的作用是什麼？

答：

邏輯數據映射（Logical Data Map）用來描述源系統的數據定義、目標數據倉庫的模型以及將源系統的數據轉換到數據倉庫中需要做操作和處理方式的說明文檔，通常以表格或Excel的格式保存如下的信息：

目標表名：

目標列名：

目標表類型：註明是事實表、維度表或支架維度表。

SCD類型：對於維度表而言。

源數據庫名：源數據庫的實例名，或者連接字符串。

源表名：

源列名：

轉換方法：需要對源數據做的操作，如Sum(amount)等。

邏輯數據映射應該貫穿數據遷移項目的始終，在其中說明了數據遷移中的ETL策略。在進行物理數據映射前進行邏輯數據映射對ETL項目組是重要的，它起着元數據的作用。項目中最好選擇能生成邏輯數據映射的數據遷移工具。

2. What are the primary goals of the data discovery phase of the data warehouse project?

在數據倉庫項目中，數據探索階段的主要目的是什麼？

答：

在邏輯數據映射進行之前，需要首先對所有的源系統進行分析。對源系統的分析通常包括兩個階段，一個是數據探索階段（Data Discovery Phase），另一個是異常數據檢測階段。

數據探索階段包括以下內容：

1．收集所有的源系統的文檔、數據字典等內容。

2．收集源系統的使用情況，如誰在用、每天多少人用、佔多少存儲空間等內容。

3．判斷出數據的起始來源（System-of-Record）。

4．通過數據概況（Data Profiling）來對源系統的數據關係進行分析。

數據探索階段的主要目的是理解源系統的情況，爲後續的數據建模和邏輯數據映射打下堅實的基礎。



3. How is the system-of-record determined?

如何確定起始來源數據？

答：

這個問題的關鍵是理解什麼是System-of-Record。System-of-Record和數據倉庫領域內的其他很多概念一樣，不同的人 對它有不同的定義。在Kimball的體系中，System-of-Record是指最初產生數據的地方，即數據的起始來源。在較大的企業內，數據會被冗 餘的保存在不同的地方，在數據的遷移過程中，會出現修改、清洗等操作，導致與數據的起始來源產生不同。

起始來源數據對數據倉庫的建立有着非常重要的作用，尤其是對產生一致性維度來說。我們從起始來源數據的越下游開始建立數據倉庫，我們遇到垃圾數據的風險就會越大。



Architecture



4. What are the four basic Data Flow steps of an ETL process?

在ETL過程中四個基本的過程分別是什麼？

答：

Kimball數據倉庫構建方法中，ETL的過程和傳統的實現方法有一些不同，主要分爲四個階段，分別是抽取（extract）、清洗（clean）、一致性處理（comform）和交付（delivery），簡稱爲ECCD。

1．抽取階段的主要任務是：

讀取源系統的數據模型。

連接並訪問源系統的數據。

變化數據捕獲。

抽取數據到數據準備區。

2．清洗階段的主要任務是：

清洗並增補列的屬性。

清洗並增補數據結構。

清洗並增補數據規則。

增補複雜的業務規則。

建立元數據庫描述數據質量。

將清洗後的數據保存到數據準備區。

3．一致性處理階段的主要任務是：

一致性處理業務標籤，即維度表中的描述屬性。

一致性處理業務度量及性能指標，通常是事實表中的事實。

去除重複數據。

國際化處理。

將一致性處理後的數據保存到數據準備區。

4．交付階段的主要任務是：

加載星型的和經過雪花處理的維度表數據。

產生日期維度。

加載退化維度。

加載子維度。

加載1、2、3型的緩慢變化維度。

處理遲到的維度和遲到的事實。

加載多值維度。

加載有複雜層級結構的維度。

加載文本事實到維度表。

處理事實表的代理鍵。

加載三個基本類型的事實表數據。

加載和更新聚集。

將處理好的數據加載到數據倉庫。

從這個任務列表中可以看出，ETL的過程和數據倉庫建模的過程結合的非常緊密。換句話說，ETL系統的設計應該和目標表的設計同時開始。通常來說，數據倉庫架構師和ETL系統設計師是同一個人。



5. What are the permissible data structures for the data staging area? Briefly describe the pros and cons of each.

在數據準備區中允許使用的數據結構有哪些？各有什麼優缺點？

答：

1．固定格式的文本文件。（Flat File）

Flat File指的是一種保存在系統上的一種文本文件格式，它以類似數據庫的表的方式用行和列來保存數據。這種文件格式經常用來進行數據交換。用於保存數據不太合適。

2．XML數據集。

多用於數據交換，用戶保存數據不太合適。

3．關係數據庫的表。

保存數據的較理想選擇。

4．獨立的數據庫表。

獨立的數據庫表一般指建立的表和其他表沒有外鍵約束關係。這樣的表多用於數據處理。

5．三範式或者關係型模型。

6．非關係型數據源。

非關係型數據源一般包括COBOL copy books、VSAM文件、Flat文件、Spreadsheets等。

7．維度模型。

8．原子事實表和聚集事實表。

9．代理鍵查找表。



6. When should data be set to disk for safekeeping during the ETL?

簡述ETL過程中哪個步驟應該出於安全的考慮將數據寫到磁盤上？

答：

Staging的意思就是將數據寫到磁盤上。出於安全及ETL能方便重新開始，在數據準備區（Staging Area）中的每個步驟中都應該將數據寫到磁盤上，即生成文本文件或者將建立關係表保存數據，而不應該以數據不落地方式直接進行ETL。

例如，在數據抽取階段，我們需要連接到源系統，爲了對源系統的影響儘量小，我們需要將抽取的數據保存成文本文件或者放入數據準備區的表中，這樣，當ETL過程出現錯誤而失敗時，我們就可以從這些文本文件開始ETL，而不需要再次影響源系統。



Extract



7. Describe techniques for extracting from heterogeneous data sources.

簡述異構數據源中的數據抽取技術。

答：在數據倉庫項目中，需要抽取的數據經常來自不同的數據源，它們的邏輯結構和物理結構都可能不同，即稱之爲異構數據源。

在對異構數據源進行整合抽取時，我們需要做的事情依次是標識出所有的源系統，對源系統進行概況分析，定義數據匹配邏輯，建立篩選規則，生成一致性維度。

對於源數據的操作系統平臺和數據平臺各不相同的情況，我們需要根據實際情況來確定如何進行數據抽取，通常的方法有建立ODBC連接、定義接口文件、建立DBLINK等方法。



8. What is the best approach for handling ERP source data?

從ERP源系統中抽取數據最好的方法是什麼？

答：ERP系統的產生是爲了解決企業內異構數據的整合。這個問題也是數據倉庫系統面臨的主要問題。ERP的解決方案是將企業內的各個應用（包括銷 售、會計、人力資源、庫存和產品等）建立在相同的平臺和相同的應用框架下，即在應用操作層將企業內的數據進行了一致性處理。而數據倉庫是在應用操作層之上 建立一致性的規則並進行一致性處理。目前比較流行的ERP系統有SAP、PeopleSoft、Oracle、Baan和J.D.EDwards（大部分 沒接觸過）。

如果企業內只有一套ERP系統，那麼數據就已經是一致的了，爲數據抽取提供了方便。如果企業內除了ERP外還有其他系統，則數據抽取會變得複雜。 因爲目前的ERP系統的數據模型都非常複雜，可能有幾百幾千個表，並且較難理解。直接在ERP系統上建立數據捕獲和抽取是非常複雜的。最好的辦法是購買能 針對ERP系統數據抽取提供功能的ETL工具，將ERP內部的複雜性留給ETL廠商處理。



9. Explain the pros and cons of communicating with databases natively versus ODBC.

簡述直接連接數據庫和使用ODBC連接數據庫進行通訊的優缺點。

答：通常連接數據庫的方式分爲兩類，一類是直接連接，另一類是通過ODBC連接。

直接連接的方式主要是通過COBOL、PL/SQL、Transact-SQL等方式連接數據庫。這種方式的優點是運行性能高，可以使用DBMS提供的一些特殊功能。缺點是通用性差。

ODBC是爲windows應用程序訪問數據庫提供的一組接口。ODBC的優點是靈活性，通過改變驅動和連接方式可以使用不同的數據庫。ODBC 方式的缺點是性能差。使用ODBC連接方式實現ETL的話，在ETL程序和至少要有兩層，分別是ODBC Manager層和ODBC Driver層。另外，使用ODBC方式不能使用DBMS提供的一些特殊的功能。



10. Describe three change data capture (CDC) practices and the pros and cons of each.

簡述出三種變化數據捕獲技術及其優缺點。

答：

變化數據捕獲（CDC）技術是ETL工作中的重點和難點，通常需要在增量抽取時完成。實現變化數據捕獲時最理想的是找到源系統的DBA。如果不能找到，就需要ETL項目組自己進行檢測數據的變化。下面是一些常用的技術。

1．採用審計列

審計列指表中如“添加日期”、“修改日期”、“修改人”等信息的字段。應用程序在對該表的數據進行操作時，同時更新這些字段，或者建立觸發器來更 新這些字段。採用這種方式進行變化數據捕獲的優點是方便，容易實現。缺點是如果操作型系統沒有相應的審計字段，需要改變已有的操作型系統的數據結構，以保 證獲取過程涉及的每張表都有審計字段。

2．數據庫日誌

DBMS日誌獲取是一種通過DBMS提供的日誌系統來獲得變化的數據。它的優點是對數據庫或訪問數據庫的操作系統的影響最小。缺點是要求DBMS支持，並且對日誌記錄的格式非常瞭解。

3．全表掃描

全表掃描或者全表導出文件後進行掃描對比也可以進行變化數據捕獲，尤其是捕獲刪除的數據時。這種方法的優點是，思路清晰，適應面廣，缺點是效率比較差。



Data Quality



11. What are the four broad categories of data quality checks? Provide an implementation

technique for each.

數據質量檢查的四大類是什麼？爲每類提供一種實現技術。

答：數據質量檢查是ETL工作中非常重要的一步，主要關注一下四個方面。

1．正確性檢查（Corret）

檢查數據值及其描述是否真實的反映了客觀事務。例如地址的描述是否完全。

2．明確性檢查（Unambiguous）

檢查數據值及其描述是否只有一個意思或者只有一個解釋。例如地名相同的兩個縣需要加區分方法。

3．一致性檢查（Consistent）

檢查數據值及其描述是否統一的採用固定的約定符號來表示。例如幣別中人民幣用'CNY'。

4．完全性檢查（Complete）

完全性有兩個需要檢查的地方，一個是檢查字段的數據值及其描述是否完全。例如檢查是否有空值。另一個是檢查記錄的合計值是否完全，有沒有遺忘某些條件。



12. At which stage of the ETL should data be profiled?

簡述應該在ETL的哪個步驟來實現概況分析？

答：數據概況分析是對源數據內容的概況進行分析，應該在項目的開始後儘早完成，它會對設計和實現有很大的影響。在完成需求收集後就應該立即開始數據概況分析。

數據概況分析不光是對源系統的數據概況的定量描述，而且爲ETL系統中需要建立的錯誤事件事實表（Error Event Table）和審計維度表（Audit Dimension）打下基礎，爲其提供數據。



13. What are the essential deliverables of the data quality portion of ETL?

ETL項目中的數據質量部分核心的交付物有那些？

答：ETL項目中數據質量部分的核心的交付物主要有下面三個：

1．數據概況分析結果

數據概況分析結果是對源系統的數據狀況的分析產物，包括如源系統中有多少個表，每個表有多少字段，其中多少爲空，表間的外鍵關係是否存在等反映源系統數據質量的內容。這些內容用來決定數據遷移的設計和實現，並提供給錯誤事件事實表和審計維度表需要的相關數據。

2．錯誤事件事實表

錯誤事件事實表及相關的一系列維度表是數據質量檢查部分的一個主要交付物。粒度是每一次數據質量檢查中的錯誤信息。相關維度包括日期維度表、遷移 信息維度表、錯誤事件信息維度表，其中錯誤事件信息維度表中檢查的類型、源系統的信息、涉及的表信息、檢查使用的SQL等內容。錯誤事件事實表不提供給前 臺用戶。

3．審計維度表

審計維度表是給最終用戶提供數據質量說明的一個維度表。它描述了用戶使用的事實表的數據來源，數據質量情況等內容。



14. How can data quality be quantified in the data warehouse?

如何來量化數據倉庫中的數據質量？

答：在數據倉庫項目中，通常通過不規則數據的檢測工作（Anomaly Detection）來量化源系統的數據質量。除非成立專門的數據質量調查項目組，否則這個工作應該由ETL項目組完成。通常可以採用分組SQL來檢查數據是否符合域的定義規則。

對於數據量小的表，可以直接使用類似下面的SQL完成。

select state, count(*) from order_detail group by state

對於數據量大的表，一般通過採樣技術來減少數據量，然後進行不規則數據檢測。類似SQL如下。

select a.* from employee a, (select rownum counter, a.* from employee a) B where a.emp_id = b.emp_id and mod(b.counter, trunc((select count(*) from employee)/1000,0)) = 0

如果可以採用專門的數據概況分析工具進行的話，可以減少很大的工作量。



Building mappings



15. What are surrogate keys? Explain how the surrogate key pipeline works.

什麼是代理鍵？簡述代理鍵替換管道如何工作。

答：在維度表的遷移過程中，有一種處理方式是使用無意義的整型值分配給維度記錄並作爲維度記錄的主鍵，這些作爲主鍵的整型值稱爲代理鍵（Surrogate Key）。使用代理鍵有很多好處，如隔離數據倉庫與操作環境，歷史記錄的保存，查詢速度快等。

同時，在事實表的遷移過程中，爲了保證參照完整性也需要進行代理鍵的替換工作。爲了代理鍵替換的效率高一些，我們通常在數據準備區中建立代理鍵查 找表（Surrogate Mapping Table or Lookup Table）。代理鍵查找表中保存最新的代理鍵和自然鍵的對應關係。在對事實表進行代理鍵替換時，爲了保證效率高，需要把代理鍵查找表中的數據加載到內存 中，並可以開多線程依次替換同一記錄的中的不同代理鍵，使一條事實記錄在所有的代理鍵都替換完後再寫如磁盤中，這樣的替換過程稱爲代理鍵替換管道 （Surrogate Key Pipeline）。



16. Why do dates require special treatment during the ETL process?

爲什麼在ETL的過程中需要對日期進行特殊處理？

答：在數據倉庫的項目中，分析是主導需求，而基於日期和時間的分析更是佔了很大的比重。而在操作型源系統中，日期通常都是SQL的 DATETIME型的。如果在分析時，使用SQL對這種類型的字段臨時處理會出現一些問題，如效率很差，不同的用戶會採用不同的格式化方法導致報表不統 一。所以，在數據倉庫的建模時都會建立日期維度表和時間維度表，將用到的和日期相關的描述都冗餘到該表中。

但是，並不是所有的日期都被轉化爲日期維度表的外鍵。日期維度表中的記錄是有限的，有些日期如生日等可能會比日期維度表中記錄的最小日期還要早， 這類字段可以直接在數據倉庫中保存SQL的DATETIME型。而像購買日期等與分析的業務緊密相關的通常都需要轉化爲日期維度表的外鍵，可以用日期維度 表中統一的描述信息進行分析。



17. Explain the three basic delivery steps for conformed dimensions.

簡述對一致性維度的三種基本的交付步驟。

答：數據整合的關鍵就是生成一致性維度，再通過一致性維度將來自不同數據源的事實數據合併到一起，供分析使用。通常來說，生成一致性維度有如下三個步驟：

1.標準化（Standardizing）

標準化的目的是使不同數據源的數據編碼方式，數據格式等相同，爲下一步數據匹配打下基礎。

2.匹配（Matching and Deduplication）

數據匹配的工作有兩種，一種是將不同數據源的標識同一事物的不同屬性匹配到一起，是數據更完善；另一種是將不同數據源的相同數據標識成重複，爲下一步的篩選打下基礎。

3.篩選（Surviving）

數據篩選的主要目的是選定一致性維度作爲主數據（Master Data），也就是最終交付的一致性維度數據。



18. Name the three fundamental fact grains and describe an ETL approach for each.

簡述三種基本事實表，並說明ETL的過程中如何處理它們。

答：事實表從粒度的角色來劃分可以分爲三類，分別是交易粒度事實表（Transaction Grain）、週期快照粒度事實表（Periodic Snapshot）和累計快照粒度事實表（Accumulating Snapshot）。在事實表的設計時，一定要注意一個事實表只能有一個粒度，不能將不同粒度的事實建立在同一張事實表中。

交易粒度事實表的來源伴隨交易事件成生的數據，例如銷售單。在ETL過程中，以原子粒度直接進行遷移。

週期快照事實表是用來記錄有規律的，固定時間間隔的業務累計數據，例如庫存日快照。在ETL過程中，以固定的時間間隔生成累計數據。

累積快照事實表用來記錄具有時間跨度的業務處理過程的整個過程的信息。在ETL過程中，隨着業務處理過程的步驟逐步完善該表中的記錄。



19. How are bridge tables delivered to classify groups of dimension records associated to a singlefact?

簡述橋接表是如何將維度表和事實表進行關聯的？

答：橋接表（Bridge Table）是維度建模中的一類比較特殊的表。

在數據倉庫的建模時，會遇到具有層次結構的維度表，對於這樣的表有一種建模方式是建立父子表，即每條記錄上包括一個指向其父記錄的字段。這種父子 表的建立在層級深度可變時尤其有用，是一個緊湊而有效的建模方式。但是這種建模方式也有缺點，就是用標準SQL很難對遞歸結構進行操作。

與這種遞歸結構的父子表不同，橋接表採用不同的建模方式也可以表示這種層級結構。橋接表是建立在維度表和事實表中間的一個具有較多冗餘信息的表，其中的記錄包含層級結構中節點到其下面每個節點的路徑。表結構如下所示：

父關鍵字

子關鍵字

父層數

層名

底端標識

頂端標識

在橋接表中，節點與其下面的任意一個節點都建立一個關聯記錄保存在表中，即父子關係不再侷限在相鄰層，如第一層與第三層同樣有父子關係，通過父層數可以區分相隔了幾層。這樣，可以通過父層數和父子關係來進行層級結構的查詢。

當然，橋接表也不是一個完備的解決方案，它只能是在某些情況下是查詢變得容易。



20. How does late arriving data affect dimensions and facts? Share techniques for handling each.

遲到的數據對事實表和維度表有什麼影響？怎樣來處理這個問題？

答：遲到的數據分爲兩種，一種是遲到的事實表數據，另一種是遲到的維度表數據。

對於遲到的事實記錄，我們可以插入到相應的事實表中。在插入的同時，還需要做一些處理。首先，對於具有SCD TYPE 2型維度的事實記錄需要在插入前判斷該事實記錄的發生日期到目前爲止，維度記錄是否發生過變化，如果有變化，該事實記錄需要對應到事實發生時的維度記錄 上。其次，在事實記錄插入完成後，與該事實表相關的聚集事實表和合並事實表需要做相應的處理。

對於遲到的維度記錄，我們需要做的處理要複雜一些。首先，如果遲到的維度記錄是第一次進入數據倉庫中，那麼需要在維度表中生成一條維度記錄，並將 與該維度記錄對應的事實記錄的外鍵進行更新。其次，如果遲到的維度記錄是對原維度進行的修改，那麼我們在維度表中生成一條新記錄的同時，還需要找到維度本 次變化到下次變化間的事實行，並將其維度外鍵更新爲新加維度的代理關鍵字。



Metadata



21. Describe the different types of ETL metadata and provide examples of each.

舉例說明各種ETL過程中的元數據。

答：元數據是ETL項目組面對的一個非常重要的主題，對於整個數據倉庫項目也是非常重要的一部分。對於元數據的分類和使用沒有很確定的定義。

通常來說，我們可以把元數據分爲三類，分別爲業務元數據（Business Metadata），技術元數據（Technical Metadata）和過程處理元數據（Process Execution Metadata）。

業務元數據，是從業務的角度對數據的描述。通常是用來給報表工具和前端用戶對數據進行分析和使用提供幫助。

技術元數據，是從技術的角度對數據的描述。通常包括數據的一些屬性，如數據類型、長度、或者數據概況分析後一些結果。

過程處理元數據，是ETL處理過程中的一些統計數據，通常包括有多少條記錄被加載，多少條記錄被拒絕接受等數據



22. Share acceptable mechanisms for capturing operational metadata.

簡述獲取操作型元數據的方法。

答：操作型元數據（Operational Metadata），也就是過程處理元數據，記錄的是ETL過程中數據遷移情況，如上次遷移日期，加載的記錄數等信息。這部分元數據在ETL加載失敗時會非常重要。

一般來說，對於使用ETL工具的數據加載，像遷移調度時間、遷移調度順序，失敗處理等內容都可以在由在遷移工具中定義生成。像上次遷移日期等數據可以建表保存。

如果是手工編寫ETL程序的話，操作型元數據的處理會麻煩一些，需要自己來獲取和存儲。獲取的方式，不同的編程方式會不盡相同。



23. Offer techniques for sharing business and technical metadata.

Optimization/Operations

簡述共享業務元數據和技術元數據的方法。

答：爲了能共享各種元數據，在數據倉庫的構建過程中必須要有一些元數據標準，並在實際開發中遵守這些標準。這些標準包括元數據命名規則、存儲規則 及共享規則等內容。有關元數據標準的內容可以參看公共倉庫元模型（Common Warehouse Metamodel，CWM）的相關資料 。

在最基本的層面上，企業應該在下面三個方面制定好標準。

1．命名規則

命名規則應該在ETL組開始編碼前制定好，範圍包括表、列、約束、索引等等數據庫對象以及其他一些編碼規則。如果企業有自己的命名規則，ETL組 應該遵守企業的命名規則。當企業的命名規則不能完全滿足需求時，ETL組可以制定補充規則或者新的規則。對企業命名規則的改變需要有詳細的文檔記錄，並提 交企業相關部門審覈。

2．架構

在ETL組開始工作前，架構應該先被設計好。例如ETL引擎是和數據倉庫放在同一臺服務器上還是單獨設立服務器；數據準備區是建立成臨時的還是持久的；數據倉庫是基於維度建模的還是3NF建模的。並且這些內容應該有詳細的文檔記錄。

3．基礎結構

系統的基礎結構也應該先確定好。例如解決方案是基於Windows的還是基於UNIX的。這些企業基礎結構元數據應該在ETL組開始工作前制定好。這些內容也應該有詳細的文檔記錄。

在ETL的開發中，制定好元數據標準並能很好的遵守，那麼建立好的數據倉庫的元數據就可以很好的完成共享功能。



24. State the primary types of tables found in a data warehouse and the order which they must be loaded to enforce referential integrity.

簡述數據倉庫中的表的基本類型，以及爲了保證引用完整性該以什麼樣的順序對它們進行加載。

答：數據倉庫中的表的基本類型有維度表、事實表、子維度表、橋接表等幾類。其中子維度表即雪花模型由支架維度技術處理，橋接表用來處理多值維度或層級結構。

數據倉庫中需要加載的各類表之間有相互依賴的關係，所以加載時需要以一定的順序進行加載。下面是一些加載的基本原則：

子維度表加載成功後，再加載維度表。

維度表加載成功後，再加載橋接表。

子維度表、維度表和橋接表都加載成功後，再加載事實表。

這個加載順序可以通過主外鍵的關係來確定。

（注意，此回答爲總線架構的數據倉庫的表的加載順序。）



25. What are the characteristics of the four levels of the ETL support model?

簡述ETL技術支持工作的四個級別的特點。

答：數據倉庫上線後，ETL組需要爲保證ETL工作的正常運行提供技術支持。通常這種技術支持工作分爲四個級別。

1．第一級別的技術支持通常是電話支持人員，屬於技術支持服務窗口（Help Desk）類型。如果數據遷移出現錯誤或者用戶發現數據有問題，問題通過電話反映到第一級別的技術支持處。第一級別支持人員通過ETL項目組提供的一些問 題的解決辦法儘可能的解決發現的問題，阻止問題升級。

2．第二級別的技術支持通常是系統管理員和DBA。如果第一級別不能解決問題，問題反映到第二級別。第二級別的人員通常技術上比較強，硬件基礎結構和軟件架構上的問題都可以解決。

3．第三級別的技術支持通常是ETL項目負責人。如果第二級別不能解決問題，問題反映到第三級別。ETL項目負責人應該具備足夠的知識，能夠解決 生產環境中的絕大部分問題。ETL項目負責人在必要時可以和開發人員或者外部產品提供商對某些問題進行交流，以便找出解決問題的辦法。

4．第四級別的技術支持通常是ETL的實際開發人員。如果第三級別不能解決問題，問題反映到第四級別。ETL的實際開發人員可以對代碼進行跟蹤分析並找到問題的解決辦法。如果問題出現在產品供應商的應用中，還需要供應商提供技術支持。

在小一些的數據倉庫環境中，也是通常的情況下，第三級別和第四級別可以合併在一起。合併後對第二級別的要求會高一些。不建議每次出現問題都找ETL的開發人員。第一級別的技術支持人員不應該僅僅提供電話支持服務，在將問題反映給下一個級別前，要儘自己的能力去解決問題。



26. What steps do you take to determine the bottleneck of a slow running ETL process?

如果ETL進程運行較慢，需要分哪幾步去找到ETL系統的瓶頸問題。

答：ETL系統遇到性能問題，運行很慢是一件較常見的事情，這時要做的是逐步找到系統的瓶頸在哪裏。

首先要確定是由CPU、內存、I/O和網絡等產生的瓶頸，還是由ETL處理過程產生的瓶頸。

如果環境沒有瓶頸，那麼需要分析ETL的代碼。這時，我們可以採用排除的方法，需要隔離不同的操作，並分別對它們進行測試。如果是採用純手工編碼 方式的ETL處理，隔離不同的操作要麻煩一些，這時需要根據編碼的實際情況來處理。如果是採用ETL工具的話，目前的ETL工具應該都有隔離不同處理的功 能，隔離起來相對容易一些。

分析最好從抽取操作開始，然後依次分析各種計算、查找表、聚集、過濾等轉換環節的處理操作，最後分析加載操作。

實際的處理中，可以按照下面的七個步驟來查找瓶頸。

1．隔離並執行抽取查詢語句。

先將抽取部分隔離出來，去掉轉換和交付，可以將數據直接抽取到文件中。如果這一步效率很差，基本確定是抽取SQL的問題。從經驗來看，未經調優的SQL是一個最常見的導致ETL效率差的原因。如果這步沒有問題進入第二步。

2．去掉過濾條件。

這一條是針對全抽取，然後在ETL處理中進行過濾的處理方式而言。在ETL處理中做過濾處理有時會產生瓶頸。可以先將過濾去掉，如果確定爲這個原因，可以考慮在抽取時進行數據過濾。

3．排除查找表的問題。

參照數據在ETL處理過程中通常會加載到內存中，目的是做代碼和名稱的查找替換，也稱查找表。有時查找表的數據量過大也會產生瓶頸。可以逐個隔離 查找表，來確定是否是這裏出現問題。注意要將查找表的數據量降到最低，通常一個自然鍵一個代理鍵就可以，這樣可以減少不必要的數據I/O。

4．分析排序和聚集操作。

排序和聚集操作都是非常費資源的操作。對這部分隔離，來判斷是否因爲它們引起性能問題。如果確定是因爲這個，需要考慮是否可以將排序和聚集處理移出數據庫和ETL工具，移到操作系統中來處理。

5．隔離並分析每一個計算和轉換處理。

有時轉換過程中的處理操作也會引起ETL工作的性能。逐步隔離移除它們來判斷哪裏出了問題。要注意觀察像默認值、數據類型轉換等操作。

6．隔離更新策略。

更新操作在數據量非常大時是性能非常差的。隔離這部分，看看是否這裏出了問題。如果確定是因爲大批量更新出了性能問題。應該考慮將insert、update和delete分開處理。

7．檢測加載數據的數據庫I/O。

如果前面各部分都沒有問題，最後需要檢測是目標數據庫的性能問題。可以找個文件代替數據庫，如果性能提高很多，需要仔細檢測目標數據庫的加載過程 中的操作。例如是否關閉了所有的約束，關閉了所有的索引，是否使用了批量加載工具。如果性能還沒有提高，可以考慮使用並行加載策略。



27. Describe how to estimate the load time of a large ETL job.

Real Time ETL

簡述如何評估大型ETL數據加載時間。

答：評估一個大型的ETL的數據加載時間是一件很複雜的事情。數據加載分爲兩類，一類是初次加載，另一類是增量加載。

在數據倉庫正式投入使用時，需要進行一次初次加載，而這次初次加載需要的時間一般較難預料。在數據倉庫的日常使用和維護中，每天需要對數據倉庫進行增量加載。增量加載的數據量要比初次加載小很多。

下面以初次加載爲例來談談如何評估大型ETL的數據加載時間。

對初次加載的加載時間進行預估，需要將整個ETL過程分成抽取、轉換和加載三部分，分別對這三部分進行評估。

1．對抽取時間的評估。

抽取通常佔用的ETL的大部分時間，而且對這部分需要時間的評估也是非常困難的。爲了對這部分時間進行評估，我們可以將查詢時間分成兩部分，一部 分是查詢響應時間，另一部分是數據返回時間。查詢響應時間指從查詢開始執行到結果開始返回這段時間。數據返回時間指第一條記錄返回到最後一條記錄返回的時 間。

另外，初次加載的數據量太大，我們可以考慮選擇其中的一部分來評估整體的時間，實際處理中，可以選擇事實表的一個分區。一般來說各個分區的數據量差不多，評估出一個分區的時間，乘上分區數可以作爲整體的評估時間。

2．對數據轉換時間的評估

數據轉換工作通常在內存中完成，一般來說都有着非常快的速度，佔總體時間的比重比較小。如果要評估這部分需要的時間的話，最簡單的評估方法是先評估出抽取時間和加載時間，然後運行整個過程，用整體時間減去抽取時間和加載時間。

3．對加載時間的評估

很多原因都可能影響加載時間，其中最重要的兩個分別是索引和日誌。

對加載時間的評估，也可以像評估抽取時間時一樣，選擇加載數據的一部分，如1/200進行加載，計算出時間後乘以200來作爲整體加載時間。

總之，大型ETL數據的加載時間的評估是很困難的，我們採用的方法主要是類比評估，即選擇一部分數據減少整體時間進行評估。在進行評估時要注意到 測試環境和生產環境的配置等的差別會引起評估結果的偏差。雖然這種對時間的評估一定會有誤差，但是可以做爲整體加載時間的一個參考。



28. Describe the architecture options for implementing real-time ETL.

簡述在架構實時ETL時的可以選擇的架構部件。

答：在建立數據倉庫時，ETL通常都採用批處理的方式，一般來說是每天的夜間進行跑批。

隨着數據倉庫技術的逐步成熟，企業對數據倉庫的時間延遲有了更高的要求，也就出現了目前常說的實時ETL（Real-Time ETL）。實時ETL是數據倉庫領域裏比較新的一部分內容。

在構建實時ETL架構的數據倉庫時，有幾種技術可供選擇。

1．微批處理（microbatch ETL，MB-ETL）

微批處理的方式和我們通常的ETL處理方式很相似，但是處理的時間間隔要短，例如間隔一個小時處理一次。

2．企業應用集成（Enterprise Application Integration，EAI）

EAI也稱爲功能整合，通常由中間件來完成數據的交互。而通常的ETL稱爲數據整合。

對實時性要求非常高的系統，可以考慮使用EAI作爲ETL的一個工具，可以提供快捷的數據交互。不過在數據量大時採用EAI工具效率比較差，而且實現起來相對複雜。

3．CTF（Capture, Transform and Flow）

CTF是一類比較新的數據整合工具。它採用的是直接的數據庫對數據庫的連接方式，可以提供秒級的數據。CTF的缺點是隻能進行輕量級的數據整合。 通常的處理方式是建立數據準備區，採用CTF工具在源數據庫和數據準備區的數據庫之間相連接。數據進入數據準備區後再經過其他處理後遷移入數據倉庫。

4．EII（Enterprise Information Integration）

EII是另一類比較新的數據整合軟件，可以給企業提供實時報表。EII的處理方式和CTF很相似，但是它不將數據遷移入數據準備區或者數據倉庫，而是在抽取轉換後直接加載到報表中。

在實際建立實時ETL架構的數據倉庫時，可以在MB-ETL, EAI, CTF, EII及通常的ETL中作出選擇或者進行組合。



29. Explain the different real-time approaches and how they can be applied in different business scenarios.

簡述幾種不同的實時ETL實現方法以及它們的適用範圍。

答：實時數據倉庫在目前來說還不是很成熟，成功案例也比較少，下面列舉了一些實時數據倉庫架構的實現方法。

1．EII ONLY

使用EII技術來代替實時的數據倉庫，數據延遲可以保證在1分鐘左右，支持數據整合的複雜程度較低。無法保存歷史數據。

2．EII + Static DW

使用EII技術聯合非實時的數據倉庫，數據延遲可以保證在1分鐘左右，1天內的數據整合的複雜程度較低，1天前的數據整合的複雜程度可以較高。可以保存歷史數據。

3．ETL + Static DW

普通的ETL處理，數據延遲在1天。支持複雜程度較高的數據整合。保存歷史數據。

4．CTF + Real-Time Partition + Static DW

使用CTF技術建立實時數據倉庫，數據延遲可保證在15分鐘左右。數據整合的複雜程度較低。保存歷史數據。

5．CTF + MB-ETL + Real-Time Partition + Static DW

使用CTF技術和MB-ETL聯合處理數據遷移，數據延遲可保證在1小時左右，支持數據整合的複雜程度較高，保存歷史數據。

6．MB-ETL + Real-Time Partition + Static DW

直接使用MB-ETL建立實時數據倉庫，數據延遲可保證在1小時左右，支持數據整合的複雜程度較高，保存歷史數據。

7．EAI + Real-Time Partition + Static DW

使用EAI技術建立實時數據倉庫，數據延遲可保證在1分鐘左右，支持數據整合的複雜程度較高。保存歷史數據。

上面列出了一些實時數據倉庫架構的選擇，寫的不是很詳細，只是提出個思路，供大家自己去找資料學習。

30. Outline some challenges faced by real-time ETL and describe how to overcome them.

簡述實時ETL的一些難點及其解決辦法。

答：實時ETL的引入給數據倉庫的建設帶來了很多新的問題和挑戰，下面列舉了一些問題，其中有些問題有具體的解決辦法，有些只能在實際情況下去斟酌。

1．連續的ETL處理對系統可靠性提出更高的要求。

2．離散快照數據的間隔時間變短。

3．緩慢變化維變成快速變化維。

4．如何確定數據倉庫中數據的刷新頻率。

5．目的是隻出報表還是要實現數據整合。

6．做數據整合還是應用整合。

7．採用點對點的方式還是集中的方式。

8．前端展現工具的數據刷新方式如何確定。