ETL架構師之分析類

本部分的題目來自Kimball的ETL Toolkit著作，原著未直接給出答案。這裡的中文是參考網友整理(Jerome's BI BLOG )加上自己整理而得，不是原創。

第一：分析類
1.什麼是邏輯資料對映？它對ETL專案組的作用是什麼？
答：
邏輯資料對映（Logical Data Map）用來描述源系統的資料定義、目標資料倉儲的模型以及將源系統的資料轉換到資料倉儲中需要做操作和處理方式的說明文件，通常以表格或Excel的格式儲存如下的資訊：
目標表名：
目標列名：
目標表型別：註明是事實表、維度表或支架維度表。
SCD型別：對於維度表而言。
源資料庫名：源資料庫的例項名，或者連線字串。
源表名：
源列名：
轉換方法：需要對源資料做的操作，如Sum(amount)等。

邏輯資料對映應該貫穿資料遷移專案的始終，在其中說明了資料遷移中的ETL策略。在進行物理資料對映前進行邏輯資料對映對ETL專案組是重要的，它起著後設資料的作用。專案中最好選擇能生成邏輯資料對映的資料遷移工具。

評論1：
邏輯資料對映分為兩種:
1 : 模型對映:
從源模型到DW目標模型之間的對映型別有：
一對一：一個源模型的資料實體只對應一個目標模型的資料實體。如果源型別與目標型別一致，則直接對映。如果兩者間型別不一樣，則必須經過轉換對映。
一對多：一個源模型的資料實體只對應多個目標模型的資料實體。在同一個資料儲存空間，常常出現會一個源實體拆分為多個目標實體的情況下。在不同的儲存空間中，結果會對應到不同的儲存空間的實體。
一對零：一個源模型的資料實體沒有與目標模型的資料實體有對應，它不在我們處理的計劃範圍之內。
零對一：一個目標模型的資料實體沒有與任何一個源資料實體對應起來。例如只是根據設計考慮，時間維表等。
多對一：多個源模型的資料實體只對應一個目標模型的資料實體。
多對多：多個源模型的資料實體對應多個目標模型的資料實體。

[@more@]

2: 屬性對映
一對一：源實體的一個資料屬性列只對應目標實體的一個資料屬性列。如果源型別與目標型別一致，則直接對映。如果兩者間型別不一樣，則必須經過轉換對映。
一對多：源實體的一個資料屬性列只對應目標實體的多個資料屬性列。在同一個實體中，常常出現會一個源屬性列拆分為目標的多個屬性列情況。在不同實體中，結果會對應到不同的實體的屬列。
一對零：一個源實體的資料屬性列沒有與目標實體的資料屬性列有對應，它不在我們處理的計劃範圍之內。
零對一：一個目標實體的資料屬性列沒有與任何一個源資料屬性列對應起來。例如只是根據設計考慮，維表和事實表中的時間戳屬性，代理健等。
多對一：源實體的多個資料屬性列只對應目標實體的一個資料屬性列。
多對多：源實體的多個資料屬性列對應目標實體的多個資料屬性列。

作用:
1 為開發者傳送更為清晰的資料流資訊。對映關係包括有關資料在儲存到DW前所經歷的各種變化的資訊，對於開發過程中資料的追蹤審查過程非常重要。
2 把ETL過程的資訊歸納為後設資料，將資料來源結構，目標結構，資料轉換規則，對映關係，資料的上下文等後設資料儲存在儲存知識庫中，為後設資料消費者提供很好的參考資訊，追蹤資料來源與轉換資訊，有助於設計人員理解系統環境變化所造成的影響；

開發設計者可以輕鬆的回答以下的問題：
1、這些資料從那裡來？
2、這樣的結果透過什麼樣的計算和轉化得來？
3、這些資料是如何組織的？
4、資料項之間有什麼聯絡？
5、如果源發生變化，有那幾個系統，目標受影響？

2.在資料倉儲專案中，資料探索階段的主要目的是什麼？
答：
在邏輯資料對映進行之前，需要首先對所有的源系統進行分析。對源系統的分析通常包括兩個階段，一個是資料探索階段（Data Discovery Phase），另一個是異常資料檢測階段。
資料探索階段包括以下內容：
1．收集所有的源系統的文件、資料字典等內容。
2．收集源系統的使用情況，如誰在用、每天多少人用、佔多少儲存空間等內容。
3．判斷出資料的起始來源（System-of-Record）。
4．透過資料概況（Data Profiling）來對源系統的資料關係進行分析。
資料探索階段的主要目的是理解源系統的情況，為後續的資料建模和邏輯資料對映打下堅實的基礎。

評論1：
確定了資料來源，我們必須仔細研究每個資料來源的內容，可獲得性程度等。因為在某個系統中同樣一個目標值的資料來源可能會有多個，這樣這個過程並不能是一個自動化的過程，更多的是依靠經驗，會根據資料量，資料質量，資料內容，資料完整性等方面來確定哪個是我們要使用的資料來源，並選擇需要的資料內容。在這個階段選擇資料來源時必須對業務有深刻的瞭解，如果想取一個資料，在源表中多個表都存在， 如對於一些大表，在業務系統中為了效能的需要，經常會只保留三個月的交易資料，這樣如果我們要分析一個一年以上的資料，這個源表就不能符合我們的需求。 這些都需要IT的資訊專家參與，他們對組織中的資料非常熟悉，瞭解大部分資料來源的歷史。 透過對所有的資料來源進行詳細的分析，瞭解其真實的資料內容。在選定資料來源時，在某種情況下，並非可以隨處捕捉到資料。這些資料必須要考慮它的其他方式的來源。
評論2：
在資料倉儲設計的最早階段上，設計者關注兩樣工作：使用者需求的收集和資料來源分析。設計者必須將使用者需求與現實各種資料來源放在一起通盤考慮， 儘可能深入的瞭解與需求密切相關的資料來源，把其作為下一步研究的基礎。 通常使用者都會說明他們需要有關銷售，庫存，財務等方面的資料，可是他們並不能詳細的說明這些資料的來源與存放在企業的哪個資料庫中。 在這一步驟為每個事實表與維表確定來源，收集有關它的資訊，是靜態的還是動態的，資料是緩慢變化的還是頻繁變化的，資料來源在何處，資料來源所處的平臺等，確定ETL的範圍；並且確認那些是來自正式的資料來源或者是非正式的資料來源。 正式的資料來源是由業務系統進行支援； 而非正式的資料來源，如分析競爭對手時的市場佔有調查報告等，這些是不能有現有的業務系統支援， 而是來自於使用者的收集與使用的，這些資訊往往需要一個獲取資訊的處理過程，將其收集到資料倉儲中。

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

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

評論1：
理解源系統的本質對於建立DW結構，ETL過程結構等非常關鍵。各種工具、連線和服務都部分依賴於資料的來源以及輸出的資料內容。 在資料倉儲設計的最早階段上，設計者關注兩樣工作：使用者需求的收集和資料來源分析。設計者必須將使用者需求與現實各種資料來源放在一起通盤考慮， 儘可能深入的瞭解與需求密切相關的資料來源，把其作為下一步研究的基礎。 通常使用者都會說明他們需要有關銷售，庫存，財務等方面的資料，可是他們並不能詳細的說明這些資料的來源與存放在企業的哪個資料庫中。 在這一步驟為每個事實表與維表確定來源，收集有關它的資訊，是靜態的還是動態的，資料是緩慢變化的還是頻繁變化的，資料來源在何處，資料來源所處的平臺等，確定ETL的範圍；並且確認那些是來自正式的資料來源或者是非正式的資料來源。 正式的資料來源是由業務系統進行支援； 而非正式的資料來源，如分析競爭對手時的市場佔有調查報告等，這些是不能有現有的業務系統支援， 而是來自於使用者的收集與使用的，這些資訊往往需要一個獲取資訊的處理過程，將其收集到資料倉儲中.
確定了資料來源，我們必須仔細研究每個資料來源的內容，可獲得性程度等。因為在某個系統中同樣一個目標值的資料來源可能會有多個，這樣這個過程並不能是一個自動化的過程，更多的是依靠經驗，會根據資料量，資料質量，資料內容，資料完整性等方面來確定哪個是我們要使用的資料來源，並選擇需要的資料內容。在這個階段選擇資料來源時必須對業務有深刻的瞭解，如果想取一個資料，在源表中多個表都存在， 如對於一些大表，在業務系統中為了效能的需要，經常會只保留三個月的交易資料，這樣如果我們要分析一個一年以上的資料，這個源表就不能符合我們的需求。 這些都需要IT的資訊專家參與，他們對組織中的資料非常熟悉，瞭解大部分資料來源的歷史。 透過對所有的資料來源進行詳細的分析，瞭解其真實的資料內容。在選定資料來源時，在某種情況下，並非可以隨處捕捉到資料。這些資料必須要考慮它的其他方式的來源。

4.簡述實時ETL的一些難點及其解決辦法。
答：實時ETL的引入給資料倉儲的建設帶來了很多新的問題和挑戰，下面列舉了一些問題，其中有些問題有具體的解決辦法，有些只能在實際情況下去斟酌。
1．連續的ETL處理對系統可靠性提出更高的要求。
2．離散快照資料的間隔時間變短。
3．緩慢變化維變成快速變化維。
4．如何確定資料倉儲中資料的重新整理頻率。
5．目的是隻出報表還是要實現資料整合。
6．做資料整合還是應用整合。
7．採用點對點的方式還是集中的方式。
8．前端展現工具的資料重新整理方式如何確定。