最近項目組里想做一個ETL數據抽取工具,這是一個研發項目,但是感覺公司並不是特別重視,不重視不是代表它不重要,而是可能不會對這個項目要求太高,能滿足我們公司的小需求就行,想從這個項目里衍生出更多的東西估計難。昨天領導讓我寫寫自己的見解,今天寫了點,不過說見解還真不敢,所以取了個名字叫建議了,今天把這個文檔貼到自己博客里和大伙分享分享。
貼文檔之前,我想很多朋友估計並不熟悉ETL,如果接粗過數據挖掘一定對ETL很熟悉了,ETL是數據挖掘里非常重要的一環,具體什么是ETL,大家看下面這段文字:
ETL(Extract-Transform-Load的縮寫,即數據抽取、轉換、裝載的過程)作為BI/DW(Business Intelligence)的核心和靈魂,能夠按照統一的規則集成並提高數據的價值,是負責完成數據從數據源向目標數據倉庫轉化的過程,是實施數據倉庫的重要步驟。如果說數據倉庫的模型設計是一座大廈的設計藍圖,數據是磚瓦的話,那么ETL就是建設大廈的過程。在整個項目中最難部分是用戶需求分析和模型設計,而ETL規則設計和實施則是工作量最大的,約占整個項目的60%~80%,這是國內外從眾多實踐中得到的普遍共識。
ETL是數據抽取(EXTRACT)、轉換(TRANSFORM)、清洗(CLEANSING)、裝載(LOAD)的過程。是構建 數據倉庫的重要一環,用戶從數據源抽取出所需的數據,經過數據清洗,最終按照預先定義好的數據倉庫模型,將數據加載到數據倉庫中去。
我們所要做的ETL工具不是針對數據倉庫,說白了就是要個安全穩定的數據庫數據導出導入工具。下面就是我寫的文檔,希望童鞋們看了后請多多指教。
1.1. 概述
如圖1-1:
ETL工具共分為三大模塊:ETL核心模塊、日志模塊和WEB模塊。
1.1.1. ETL核心模塊
ETL核心模塊是整個ETL工具的核心,它主要的功能是根據事先定義好的規則將源數據庫的數據抽取到目標數據庫。其主要工作流程是:
數據抽取-->數據轉換-->數據清洗-->數據加載
ETL工具里的配置數據庫必須包含兩個方面的數據:
- 元數據:元數據主要是指源數據、目標數據庫以及可以用於抽取的表、字段等等信息,還有一些相關函數的定義等等。
- ETL任務信息:ETL任務在我們ETL工具里稱作job,job是指一個將數據從源數據庫導出,並且按照一定規則導入到目標數據庫的過程,ETL任務信息就是指一個job的相關配置信息。
1.1.2. 日志模塊
良好的系統最重要的特征之一就是它的差錯、容錯以及能正確提供系統運行信息的特性。所以日志模塊是每個系統必不可少的部分,它設計的優劣直接關系到系統后期維護的成本。
ETL工具里的日志模塊,我個人認為應該包含如下的部分:
- 程序運行信息。這個主要是用log4j在代碼里記錄。
- ETL任務(即job)運行失敗的日志信息。一切因為程序所拋出的異常所引起的失敗都要記錄在log4j的運行日志里,如果能精確提煉出的常見異常,最好能記錄在數據庫的日志表,便於快速查找錯誤信息(這個在有WEB系統時候可以做)。
- 審計日志。審計日志是帶有一定業務需求的日志,這個是否要記錄看實際的需求。
- 錯誤告警。一般而言ETL抽取數據的操作都是一件漫長的事情,ETL開發人員不可能長時間堅守在系統旁邊,所以當系統運行出錯能在第一時間通知到相關負責人是很有必要。Log4j里有郵件通知的功能,用起來也不太難,可以考慮在日志模塊加入告警的功能。
1.1.3. WEB模塊
當我們開發好了ETL工具后我們需要一個入口,告訴我們設計的ETL工具你具體做什么樣的任務。WEB模塊的作用就是給用戶操作的入口,我個人認為WEB模塊包含以下功能:
- 元數據管理:主要是向配置數據庫定義源數據庫和目標數據庫的相關信息,例如:數據庫的url,用戶名,密碼,相關的表以及表里字段信息等等。這些信息很重要,如果沒有這些信息,整個ETL作業就是無源之水,根本無法進行。
- ETL任務的配置信息:即job的配置信息,這個就是定義我們ETL的抽取過程,例如ETL需要抽取的源數據庫是那個,抽取那張表那些字段,按照什么規則轉化數據,清洗數據,最終導入到那個目標數據庫等等。
- 查看日志信息:這個功能可選,查看日志信息主要是提高系統的友好程度,便利系統運行信息的查看。
- 用戶管理:這個功能暫時可選,因為我們所開發的ETL工具主要是內部使用,沒有太大必要做復雜的權限管理,但是簡單的用戶信息管理做做應該還是必要的。
整個WEB模塊也是可選的,如果人力和時間不夠是沒必要做一個web系統,ETL入口我們可以手動的配置任務信息。(假如真的做了WEB模塊,對ETL后台的設計和開發要求也會更高)。
1.2. 關於技術開發的一點建議
我之前看過大家寫的ETL需求文檔,大家考慮的非常全面,這里我暫時有兩個技術建議, 建議如下:
1.2.1. Xml技術
Xml技術在企業級系統開發和互聯網開發中使用十分廣泛,xml使用的場景也是非常的多,其中一個特點非常適合我們在ETL工具開發中使用到,那就是它可以存儲復雜的富有變化的數據結構。而我們定義ETL任務信息(job配置信息)就是一個復雜的富有變化的數據。大家看下面的例子:
<?xml version="1.0" encoding="UTF-8"?>
<Job>
<Id>流水號</Id>
<Extract>
<JDBCSource>
<Url>…</Url>
<Username>…</UserName>
<Password>…</Password>
</JDBCSource>
<JDNISource>…</JNDISource>
<Table>…</Table>
<Columns>
<Column>…</Column>
<Column>…</Column>
…
</Columns>
<Where>…</Where>
<Commit>…</Commit>
<OrderBy>…</OrderBy>
<FilePath></FilePath>
</Extract>
<Transform>
<Columns>
<Column>
<SrcColumn> <!-- 抽取的原字段-->
</SrcColumn>
<Methods>
<Method id="1"> <!-- 第一次轉換-->
<Function>...</Function>
</Method>
<Method id="2"> <!-- 第二次轉換-->
<Function>...</Function>
</Method>
</Methods>
<DesColumn> <!-- 加載的目標字段-->
</DesColumn>
</Column>
<Column>...</Column>
</Columns>
<SouceFilePath>...</SourceFilePath>
<TargetFilePath>...</TargetFilePath>
<Commit>...</Commit> <!--每一批次的處理條數 -->
</Transform> <Load> <JDBCSource> <Url>…</Url> <Username>…</UserName> <Password>…</Password> </JDBCSource> <JDNISource>…</JNDISource> <Table>…</Table> <Columns> <Column>…</Column> <Column>…</Column> … </Columns> <Commit>…</Commit> <LoadFilePath></LoadFilePath> </Load></Job>
這是一個job配置信息demo,如果我們把這些數據用數據庫來存儲解析起來一定是非常復雜,數據庫的表結構不適合表現出程序里復雜的數據結構。
在這里我們不應該把XML當做配置文件看待,而是當做一種數據存儲的介質,其作用主要是便於我們讀寫數據。
既然對xml有讀寫操作,因此使用digester解析xml的技術遠遠不夠,這里我建議使用xmlbeans,xmlbeans對於讀寫xml更加的簡便,關於xmlbeans的學習參考如下:
Xmlbeans的使用:
http://blog.163.com/pqg_iloveyou/blog/static/33351875200761811255619/
xsd的學習資料:
http://www.w3school.com.cn/schema/schema_example.asp
xmlbeans官網:
xsd在eclipse開發起來十分的簡便。
使用xmlbeans維護xml的成本也會比較低。
1.2.2. Spring Batch技術
對於spring batch技術我現在還不是特別熟悉,到底能不能被我們使用還需要考察和研究,但現在我知道的它的幾個特點很符合我們ETL工具開發的場景:
- spring batch批量處理框架,我們的抽取數據的過程就是一個批量的過程,因此spring batch是適合我們現在應用的場景。
- 我們抽取的數據先是存儲在臨時文件,現在規定的臨時文件的格式是csv,而spring batch正好有批量操作csv文件的功能,這個也很符合我們應用的場景。
1.3. 總結
因為本人以前做過和ETL工具類似的項目,因此這里大膽的提出一點自己的建議,僅供參考。
不過我在概述里畫的系統結構圖希望大家可以好好看看,也許還有很多不合理的地方,這需要大家集體智慧進行改進,我個人覺得系統的整體架構設計十分重要,我在看需求分析時候雖然感覺大家寫的很全面,但是很難對系統整體結構有一個清晰認識,究其原因是需求里缺乏對系統的整體架構設計的部分,我個人覺得系統整體設計很重要很有必要,整體架構設計會給我們帶來很多好處:
- 整體架構設計會給我們需要做哪些功能有一個清晰的認識,這個認識會避免開發的時候遺漏了功能。
- 整體架構能清晰表現出各個功能模塊的關系,做過開發的人應該都會有這樣的體會,模塊之間的交互的地方很容易產生問題,而且交互產生的問題也是很難查找定位的,整體架構設計會讓我們清晰認識到模塊交互關系,利於我們做模塊之間交互的開發。
- 整體架構能清晰體現出模塊之間的邊界在哪里,這個很重要,不清晰模塊之間的邊界,很容易在把A模塊的功能寫到了B模塊中,最終導致系統的不穩定。
- 整體架構的設計能給項目開發的分工做參考,更合理的安排工作,提高生產效率。