BI專案中ETL設計與思考(轉)
BI專案中ETL設計與思考(轉)[@more@]
ETL即資料抽取(Extract)、轉換(Transform)、裝載(Load)的過程,它是構建資料倉儲的重要環節。
ETL是將業務系統的資料經過抽取、清洗轉換之後載入到資料倉儲的過程,目的是將企業中的分散、零亂、標準不統一的資料整合到一起,為企業的決策提供分析依據。ETL是BI專案重要的一個環節。通常情況下,在BI專案中ETL會花掉整個專案的1/3的時間,ETL設計的好壞直接關接到BI專案的成敗。
ETL的設計分三部分:資料抽取、資料的清洗轉換、資料的載入。在設計ETL的時候我們也是從這三部分出發。資料的抽取是從各個不同的資料來源抽取到ODS(OperationalDataStore,操作型資料儲存)中——這個過程也可以做一些資料的清洗和轉換),在抽取的過程中需要挑選不同的抽取方法,儘可能的提高ETL的執行效率。ETL三個部分中,花費時間最長的是“T”(Transform,清洗、轉換)的部分,一般情況下這部分工作量是整個ETL的2/3。資料的載入一般在資料清洗完了之後直接寫入DW(DataWarehousing,資料倉儲)中去。
ETL的實現有多種方法,常用的有三種。一種是藉助ETL工具(如Oracle的OWB、SQLServer2000的DTS、SQLServer2005的SSIS服務、Informatic等)實現,一種是SQL方式實現,另外一種是ETL工具和SQL相結合。前兩種方法各有各的優缺點,藉助工具可以快速的建立起ETL工程,遮蔽了複雜的編碼任務,提高了速度,降低了難度,但是缺少靈活性。SQL的方法優點是靈活,提高ETL執行效率,但是編碼複雜,對技術要求比較高。第三種是綜合了前面二種的優點,會極大地提高ETL的開發速度和效率。
一、資料的抽取
這一部分需要在調研階段做大量的工作,首先要搞清楚資料是從幾個業務系統中來,各個業務系統的資料庫伺服器執行什麼DBMS,是否存在手工資料,手工資料量有多大,是否存在非結構化的資料等等,當收集完這些資訊之後才可以進行資料抽取的設計。
1、對於與存放DW的資料庫系統相同的資料來源處理方法
這一類資料來源在設計上比較容易。一般情況下,DBMS(SQLServer、Oracle)都會提供資料庫連結功能,在DW資料庫伺服器和原業務系統之間建立直接的連結關係就可以寫Select語句直接訪問。
2、對於與DW資料庫系統不同的資料來源的處理方法
對於這一類資料來源,一般情況下也可以透過ODBC的方式建立資料庫連結——如SQLServer和Oracle之間。如果不能建立資料庫連結,可以有兩種方式完成,一種是透過工具將源資料匯出成.txt或者是.xls檔案,然後再將這些源系統檔案匯入到ODS中。另外一種方法是透過程式介面來完成。
3、對於檔案型別資料來源(.txt,.xls),可以培訓業務人員利用資料庫工具將這些資料匯入到指定的資料庫,然後從指定的資料庫中抽取。或者還可以藉助工具實現,如SQLServer2005的SSIS服務的平面資料來源和平面目標等元件匯入ODS中去。
4、增量更新的問題
對於資料量大的系統,必須考慮增量抽取。一般情況下,業務系統會記錄業務發生的時間,我們可以用來做增量的標誌,每次抽取之前首先判斷ODS中記錄最大的時間,然後根據這個時間去業務系統取大於這個時間所有的記錄。利用業務系統的時間戳,一般情況下,業務系統沒有或者部分有時間戳。
二、資料的清洗轉換
一般情況下,資料倉儲分為ODS、DW兩部分。通常的做法是從業務系統到ODS做清洗,將髒資料和不完整資料過濾掉,在從ODS到DW的過程中轉換,進行一些業務規則的計算和聚合。
1、資料清洗
資料清洗的任務是過濾那些不符合要求的資料,將過濾的結果交給業務主管部門,確認是否過濾掉還是由業務單位修正之後再進行抽取。不符合要求的資料主要是有不完整的資料、錯誤的資料、重複的資料三大類。
(1)不完整的資料:這一類資料主要是一些應該有的資訊缺失,如供應商的名稱、分公司的名稱、客戶的區域資訊缺失、業務系統中主表與明細表不能匹配等。對於這一類資料過濾出來,按缺失的內容分別寫入不同Excel檔案向客戶提交,要求在規定的時間內補全。補全後才寫入資料倉儲。
(2)錯誤的資料:這一類錯誤產生的原因是業務系統不夠健全,在接收輸入後沒有進行判斷直接寫入後臺資料庫造成的,比如數值資料輸成全形數字字元、字串資料後面有一個回車操作、日期格式不正確、日期越界等。這一類資料也要分類,對於類似於全形字元、資料前後有不可見字元的問題,只能透過寫SQL語句的方式找出來,然後要求客戶在業務系統修正之後抽取。日期格式不正確的或者是日期越界的這一類錯誤會導致ETL執行失敗,這一類錯誤需要去業務系統資料庫用SQL的方式挑出來,交給業務主管部門要求限期修正,修正之後再抽取。
(3)重複的資料:對於這一類資料——特別是維表中會出現這種情況——將重複資料記錄的所有欄位匯出來,讓客戶確認並整理。
資料清洗是一個反覆的過程,不可能在幾天內完成,只有不斷的發現問題,解決問題。對於是否過濾,是否修正一般要求客戶確認,對於過濾掉的資料,寫入Excel檔案或者將過濾資料寫入資料表,在ETL開發的初期可以每天向業務單位傳送過濾資料的郵件,促使他們儘快地修正錯誤,同時也可以做為將來驗證資料的依據。資料清洗需要注意的是不要將有用的資料過濾掉,對於每個過濾規則認真進行驗證,並要使用者確認。
2、資料轉換
資料轉換的任務主要進行不一致的資料轉換、資料粒度的轉換,以及一些商務規則的計算。
(1)不一致資料轉換:這個過程是一個整合的過程,將不同業務系統的相同型別的資料統一,比如同一個供應商在結算系統的編碼是XX0001,而在CRM中編碼是YY0001,這樣在抽取過來之後統一轉換成一個編碼。
(2)資料粒度的轉換:業務系統一般儲存非常明細的資料,而資料倉儲中資料是用來分析的,不需要非常明細的資料。一般情況下,會將業務系統資料按照資料倉儲粒度進行聚合。
(3)商務規則的計算:不同的企業有不同的業務規則、不同的資料指標,這些指標有的時候不是簡單的加加減減就能完成,這個時候需要在ETL中將這些資料指標計算好了之後儲存在資料倉儲中,以供分析使用。
三、ETL日誌、警告傳送
1、ETL日誌
ETL日誌分為三類。一類是執行過程日誌,這一部分日誌是在ETL執行過程中每執行一步的記錄,記錄每次執行每一步驟的起始時間,影響了多少行資料,流水賬形式。一類是錯誤日誌,當某個模組出錯的時候寫錯誤日誌,記錄每次出錯的時間、出錯的模組以及出錯的資訊等。第三類日誌是總體日誌,只記錄ETL開始時間、結束時間是否成功資訊。如果使用ETL工具,ETL工具會自動產生一些日誌,這一類日誌也可以作為ETL日誌的一部分。記錄日誌的目的是隨時可以知道ETL執行情況,如果出錯了,可以知道哪裡出錯。
2、警告傳送
如果ETL出錯了,不僅要形成ETL出錯日誌,而且要向系統管理員傳送警告。傳送警告的方式多種,一般常用的就是給系統管理員傳送郵件,並附上出錯的資訊,方便管理員排查錯誤。
ETL是BI專案的關鍵部分,也是一個長期的過程,只有不斷的發現問題並解決問題,才能使ETL執行效率更高,為BI專案後期開發提供準確的資料。
ETL是將業務系統的資料經過抽取、清洗轉換之後載入到資料倉儲的過程,目的是將企業中的分散、零亂、標準不統一的資料整合到一起,為企業的決策提供分析依據。ETL是BI專案重要的一個環節。通常情況下,在BI專案中ETL會花掉整個專案的1/3的時間,ETL設計的好壞直接關接到BI專案的成敗。
ETL的設計分三部分:資料抽取、資料的清洗轉換、資料的載入。在設計ETL的時候我們也是從這三部分出發。資料的抽取是從各個不同的資料來源抽取到ODS(OperationalDataStore,操作型資料儲存)中——這個過程也可以做一些資料的清洗和轉換),在抽取的過程中需要挑選不同的抽取方法,儘可能的提高ETL的執行效率。ETL三個部分中,花費時間最長的是“T”(Transform,清洗、轉換)的部分,一般情況下這部分工作量是整個ETL的2/3。資料的載入一般在資料清洗完了之後直接寫入DW(DataWarehousing,資料倉儲)中去。
ETL的實現有多種方法,常用的有三種。一種是藉助ETL工具(如Oracle的OWB、SQLServer2000的DTS、SQLServer2005的SSIS服務、Informatic等)實現,一種是SQL方式實現,另外一種是ETL工具和SQL相結合。前兩種方法各有各的優缺點,藉助工具可以快速的建立起ETL工程,遮蔽了複雜的編碼任務,提高了速度,降低了難度,但是缺少靈活性。SQL的方法優點是靈活,提高ETL執行效率,但是編碼複雜,對技術要求比較高。第三種是綜合了前面二種的優點,會極大地提高ETL的開發速度和效率。
一、資料的抽取
這一部分需要在調研階段做大量的工作,首先要搞清楚資料是從幾個業務系統中來,各個業務系統的資料庫伺服器執行什麼DBMS,是否存在手工資料,手工資料量有多大,是否存在非結構化的資料等等,當收集完這些資訊之後才可以進行資料抽取的設計。
1、對於與存放DW的資料庫系統相同的資料來源處理方法
這一類資料來源在設計上比較容易。一般情況下,DBMS(SQLServer、Oracle)都會提供資料庫連結功能,在DW資料庫伺服器和原業務系統之間建立直接的連結關係就可以寫Select語句直接訪問。
2、對於與DW資料庫系統不同的資料來源的處理方法
對於這一類資料來源,一般情況下也可以透過ODBC的方式建立資料庫連結——如SQLServer和Oracle之間。如果不能建立資料庫連結,可以有兩種方式完成,一種是透過工具將源資料匯出成.txt或者是.xls檔案,然後再將這些源系統檔案匯入到ODS中。另外一種方法是透過程式介面來完成。
3、對於檔案型別資料來源(.txt,.xls),可以培訓業務人員利用資料庫工具將這些資料匯入到指定的資料庫,然後從指定的資料庫中抽取。或者還可以藉助工具實現,如SQLServer2005的SSIS服務的平面資料來源和平面目標等元件匯入ODS中去。
4、增量更新的問題
對於資料量大的系統,必須考慮增量抽取。一般情況下,業務系統會記錄業務發生的時間,我們可以用來做增量的標誌,每次抽取之前首先判斷ODS中記錄最大的時間,然後根據這個時間去業務系統取大於這個時間所有的記錄。利用業務系統的時間戳,一般情況下,業務系統沒有或者部分有時間戳。
二、資料的清洗轉換
一般情況下,資料倉儲分為ODS、DW兩部分。通常的做法是從業務系統到ODS做清洗,將髒資料和不完整資料過濾掉,在從ODS到DW的過程中轉換,進行一些業務規則的計算和聚合。
1、資料清洗
資料清洗的任務是過濾那些不符合要求的資料,將過濾的結果交給業務主管部門,確認是否過濾掉還是由業務單位修正之後再進行抽取。不符合要求的資料主要是有不完整的資料、錯誤的資料、重複的資料三大類。
(1)不完整的資料:這一類資料主要是一些應該有的資訊缺失,如供應商的名稱、分公司的名稱、客戶的區域資訊缺失、業務系統中主表與明細表不能匹配等。對於這一類資料過濾出來,按缺失的內容分別寫入不同Excel檔案向客戶提交,要求在規定的時間內補全。補全後才寫入資料倉儲。
(2)錯誤的資料:這一類錯誤產生的原因是業務系統不夠健全,在接收輸入後沒有進行判斷直接寫入後臺資料庫造成的,比如數值資料輸成全形數字字元、字串資料後面有一個回車操作、日期格式不正確、日期越界等。這一類資料也要分類,對於類似於全形字元、資料前後有不可見字元的問題,只能透過寫SQL語句的方式找出來,然後要求客戶在業務系統修正之後抽取。日期格式不正確的或者是日期越界的這一類錯誤會導致ETL執行失敗,這一類錯誤需要去業務系統資料庫用SQL的方式挑出來,交給業務主管部門要求限期修正,修正之後再抽取。
(3)重複的資料:對於這一類資料——特別是維表中會出現這種情況——將重複資料記錄的所有欄位匯出來,讓客戶確認並整理。
資料清洗是一個反覆的過程,不可能在幾天內完成,只有不斷的發現問題,解決問題。對於是否過濾,是否修正一般要求客戶確認,對於過濾掉的資料,寫入Excel檔案或者將過濾資料寫入資料表,在ETL開發的初期可以每天向業務單位傳送過濾資料的郵件,促使他們儘快地修正錯誤,同時也可以做為將來驗證資料的依據。資料清洗需要注意的是不要將有用的資料過濾掉,對於每個過濾規則認真進行驗證,並要使用者確認。
2、資料轉換
資料轉換的任務主要進行不一致的資料轉換、資料粒度的轉換,以及一些商務規則的計算。
(1)不一致資料轉換:這個過程是一個整合的過程,將不同業務系統的相同型別的資料統一,比如同一個供應商在結算系統的編碼是XX0001,而在CRM中編碼是YY0001,這樣在抽取過來之後統一轉換成一個編碼。
(2)資料粒度的轉換:業務系統一般儲存非常明細的資料,而資料倉儲中資料是用來分析的,不需要非常明細的資料。一般情況下,會將業務系統資料按照資料倉儲粒度進行聚合。
(3)商務規則的計算:不同的企業有不同的業務規則、不同的資料指標,這些指標有的時候不是簡單的加加減減就能完成,這個時候需要在ETL中將這些資料指標計算好了之後儲存在資料倉儲中,以供分析使用。
三、ETL日誌、警告傳送
1、ETL日誌
ETL日誌分為三類。一類是執行過程日誌,這一部分日誌是在ETL執行過程中每執行一步的記錄,記錄每次執行每一步驟的起始時間,影響了多少行資料,流水賬形式。一類是錯誤日誌,當某個模組出錯的時候寫錯誤日誌,記錄每次出錯的時間、出錯的模組以及出錯的資訊等。第三類日誌是總體日誌,只記錄ETL開始時間、結束時間是否成功資訊。如果使用ETL工具,ETL工具會自動產生一些日誌,這一類日誌也可以作為ETL日誌的一部分。記錄日誌的目的是隨時可以知道ETL執行情況,如果出錯了,可以知道哪裡出錯。
2、警告傳送
如果ETL出錯了,不僅要形成ETL出錯日誌,而且要向系統管理員傳送警告。傳送警告的方式多種,一般常用的就是給系統管理員傳送郵件,並附上出錯的資訊,方便管理員排查錯誤。
ETL是BI專案的關鍵部分,也是一個長期的過程,只有不斷的發現問題並解決問題,才能使ETL執行效率更高,為BI專案後期開發提供準確的資料。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/7600305/viewspace-923067/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- ETL設計與思考
- feed服務專案設計思考
- 審計專案計劃管理的思考(轉)
- [轉]Web專案管理思考Web專案管理
- 淺談BI專案——為失敗BI專案解惑
- 專案組織結構設計與選擇(轉)
- 專案職務設計(轉)
- 專案計劃與跟蹤(轉)
- 中文程式設計之思考 (轉)程式設計
- 關於ETL工具的思考
- 專案計劃與質量管理(轉)
- 關於專案公司文化的思考(轉)
- [BI專案記]-BUG建立
- 專案回顧:一個開發人員的觀察與思考(轉)
- 專案計劃在專案管理中的重要作用(轉)專案管理
- 趣圖:“大學時學習中的程式設計”與“實際工作專案中的程式設計”程式設計
- 專案經理對營銷的思考(轉)
- 軟體專案管理之系統思考(轉)專案管理
- 對工程專案管理概念的延伸思考(轉)專案管理
- 設計院轉型後專案管理的難點成因與對策分析(轉)專案管理
- 白話講IT系列:BI專案建設怎麼做?
- 工程專案管理與國際慣例接軌的幾點思考(轉)專案管理
- 專案管理與專案經理(轉)專案管理
- React-native專案入門與思考React
- 系統設計與普通設計思考的區別
- 關於專案中 Repository 層的思考
- 用例設計在軟體開發專案計劃中的應用(轉)
- [BI專案記]-新任務建立
- [BI專案記]-BUG處理
- BI專案記筆記索引筆記索引
- ETL+BI結合的資料整合工具
- 軟體專案管理流程分析與設計專案管理
- [BI專案記]-對專案檔案進行規劃
- Quick BI 的模型設計與生成SQL原理剖析UI模型SQL
- 設計院轉型後專案管理的難點成因與對策分析2(轉)專案管理
- ERP專案建設與埋電杆(轉)
- 施工專案管理與專案成本控制(轉)專案管理
- 使用phoenix踩的坑與設計思考