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.採用點對點的方式還是集中的方式。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/26613085/viewspace-1128041/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- p8架構師分享:支付寶三面Java面試題:JVM+快取+效能+架構架構Java面試題JVM快取
- BAT面試架構師的人都在找的java技術框架題BAT面試架構Java框架
- 架構師面試的幾個小技巧 - nickbulljs架構面試JS
- 377頁的Android 架構師面試題精編解析大全,請收下!Android架構面試題
- Java架構師面試題全集:Java基礎+技術框架+系統架構+分散式系統Java架構面試題框架分散式
- 看了上千道面試題後,我總結出了這本Android架構師面試題精編解析大全!面試題Android架構
- 2018年最全的23個阿里架構師面試題(特別推薦)阿里架構面試題
- 2021-03-25 「PHP架構師」面試準備PHP架構面試
- Java和大資料架構師面試通關要點Java大資料架構面試
- 「不能說的祕密」BAT資深面試官整理Java架構面試題BATJava架構面試題
- python工程師面試題Python工程師面試題
- 高併發架構訊息佇列面試題解析架構佇列面試題
- BAT面試經典送送送命題——微服務架構BAT面試微服務架構
- 走向架構師——1~3年java程式設計師面試必備的技能架構Java程式設計師面試
- 面試架構師太南?這份求職指南送給你面試架構求職
- 阿里JAVA架構師面試136題含答案:JVM+spring+分散式+併發程式設計!阿里Java架構面試JVMSpring分散式程式設計
- 吃透這份Java高階工程師面試497題解析,Java微服務架構訓練營Java工程師面試微服務架構
- 架構面試題—大併發量的訂單的解析架構面試題
- 架構師修煉之道(二)——架構?設計?架構師?架構
- ETL架構中的38個子系統架構
- 網際網路 Java 工程師面試題(Spring 面試題一)Java工程師面試題Spring
- 面試集錦(十六)架構設計面試架構
- c++工程師面試問題C++工程師面試
- 面試過了,總結測試工程師面試題(含答案)工程師面試題
- 資料整合的兩種架構:ELT和ETL架構
- 轉載 -這些年背過的面試題——架構設計篇面試題架構
- 2020面試必知:中高階工程師面試題集整理(題目+答案)工程師面試題
- 面試系列-Spring Cloud 的核心架構原理面試SpringCloud架構
- 企業架構師、解決方案架構師和技術架構師的異同 - Briqi架構
- 架構師之路架構
- 前端工程師面試題(html+css)前端工程師面試題HTMLCSS
- 前端工程師面試題彙總(轉)前端工程師面試題
- 力扣 面試題 17.16. 按摩師力扣面試題
- 看阿里P9架構師如何向你定義架構及架構師阿里架構
- 面試題-測試工程師常見的基礎問題面試題工程師
- web前端工程師面試題10條必會筆試題Web前端工程師面試題筆試
- 【200人面試經驗】,程式設計師面試,常見面試題解析程式設計師面試題
- 又面試了Python爬蟲工程師,碰到這麼幾道面試題,Python面試題No9Python爬蟲工程師面試題
- 資料結構面試100題資料結構面試