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項目組是重要的，它起着元數據的做用。項目中最好選擇能生成邏輯數據映射的數據遷移工具。
邏輯數據映射分爲兩種:
1 : 模型映射:
從源模型到DW目標模型之間的映射類型有：
一對一：一個源模型的數據實體只對應一個目標模型的數據實體。若是源類型與目標類型一致，則直接映射。若是二者間類型不同，則必須通過轉換映射。
一對多：一個源模型的數據實體只對應多個目標模型的數據實體。在同一個數據存儲空間，經常出現會一個源實體拆分爲多個目標實體的狀況下。在不一樣的存儲空間中，結果會對應到不一樣的存儲空間的實體。
一對零：一個源模型的數據實體沒有與目標模型的數據實體有對應，它不在咱們處理的計劃範圍以內。
零對一：一個目標模型的數據實體沒有與任何一個源數據實體對應起來。例如只是根據設計考慮，時間維表等。
多對一：多個源模型的數據實體只對應一個目標模型的數據實體。
多對多：多個源模型的數據實體對應多個目標模型的數據實體。
2: 屬性映射
一對一：源實體的一個數據屬性列只對應目標實體的一個數據屬性列。若是源類型與目標類型一致，則直接映射。若是二者間類型不同，則必須通過轉換映射。
一對多：源實體的一個數據屬性列只對應目標實體的多個數據屬性列。在同一個實體中，經常出現會一個源屬性列拆分爲目標的多個屬性列狀況。在不一樣實體中，結果會對應到不一樣的實體的屬列。
一對零：一個源實體的數據屬性列沒有與目標實體的數據屬性列有對應，它不在咱們處理的計劃範圍以內。
零對一：一個目標實體的數據屬性列沒有與任何一個源數據屬性列對應起來。例如只是根據設計考慮，維表和事實表中的時間戳屬性，代理健等。
多對一：源實體的多個數據屬性列只對應目標實體的一個數據屬性列。
多對多：源實體的多個數據屬性列對應目標實體的多個數據屬性列。
做用:
1 爲開發者傳送更爲清晰的數據流信息。映射關係包括有關數據在存儲到DW前所經歷的各類變化的信息，對於開發過程當中數據的追蹤審查過程很是重要。
2 把ETL過程的信息概括爲元數據，將數據源結構，目標結構，數據轉換規則，映射關係，數據的上下文等元數據保存在存儲知識庫中，爲元數據消費者提供很好的參考信息，追蹤數據來源與轉換信息，有助於設計人員理解系統環境變化所形成的影響；
開發設計者能夠輕鬆的回答如下的問題：
一、這些數據從那裏來？
二、這樣的結果經過什麼樣的計算和轉化得來？
三、這些數據是如何組織的？
四、數據項之間有什麼聯繫？
五、若是源發生變化，有那幾個系統，目標受影響？前端
2. What are the primary goals of the data discovery phase of the data warehouse project? ios
在數據倉庫項目中，數據探索階段的主要目的是什麼？ 數據庫
答：在邏輯數據映射進行以前，須要首先對全部的源系統進行分析。對源系統的分析一般包括兩個階段，一個是數據探索階段（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過程當中四個基本的過程分別是什麼？
windows
答：Kimball數據倉庫構建方法中，ETL的過程和傳統的實現方法有一些不一樣，
主要分爲四個階段，分別是抽取（extract）、清洗（clean）、一致性處理（comform）和交付（delivery），簡稱爲ECCD。 1．抽取階段的主要任務是： 讀取源系統的數據模型。 鏈接並訪問源系統的數據。 變化數據捕獲。 抽取數據到數據準備區。 2．清洗階段的主要任務是： 清洗並增補列的屬性。 清洗並增補數據結構。 清洗並增補數據規則。 增補複雜的業務規則。 創建元數據庫描述數據質量。 將清洗後的數據保存到數據準備區。 3．一致性處理階段的主要任務是： 一致性處理業務標籤，即維度表中的描述屬性。 一致性處理業務度量及性能指標，一般是事實表中的事實。 去除重複數據。 國際化處理。 將一致性處理後的數據保存到數據準備區。 4．交付階段的主要任務是： 加載星型的和通過雪花處理的維度表數據。 產生日期維度。 加載退化維度。 加載子維度。 加載一、二、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）。
16Why 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．前端展示工具的數據刷新方式如何肯定。