ETL面試

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是指最初産生資料的地方，即資料的起始來源。在較大的企業内，資料會被備援的儲存在不同的地方，在資料的遷移過程中，會出現修改、清洗等操作，導緻與資料的起始來源産生不同。

起始來源資料對資料倉庫的建立有着非常重要的作用，尤其是對産生一緻性次元來說。我們從起始來源資料的越下遊開始建立資料倉庫，我們遇到垃圾資料的風險就會越大。

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，而不需要再次影響源系統。

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．全表掃描

全表掃描或者全表導出檔案後進行掃描對比也可以進行變化資料捕獲，尤其是捕獲删除的資料時。這種方法的優點是，思路清晰，适應面廣，缺點是效率比較差。

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

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

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型次元的事實記錄需要在插入前判斷該事實記錄的發生日期到目前為止，次元記錄是否發生過變化，如果有變化，該事實記錄需要對應到事實發生時的次元記錄上。其次，在事實記錄插入完成後，與該事實表相關的聚集事實表和合并事實表需要做相應的處理。

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

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.

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

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

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

1. 子次元表加載成功後，再加載次元表。
2. 次元表加載成功後，再加載橋接表。
3. 子次元表、次元表和橋接表都加載成功後，再加載事實表。

這個加載順序可以通過主外鍵的關系來确定。（注意，此回答為總線架構的資料倉庫的表的加載順序。）

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．采用點對點的方式還是集中的方式。

原文位址

http://blog.sina.com.cn/s/blog_5745722a0100t9cn.html

http://blog.sina.com.cn/s/blog_5745722a0100t9ct.html

http://blog.sina.com.cn/s/blog_5745722a0100t9d5.html