目前市場所看到的ETL工具軟體產品, 大多是以集中式的處理架構為主. 也就是說所有的ETL作業是集中執行在一台或少數幾台的ETL伺服器上. ETL作業通常會使用大量的網路頻寬及磁碟I/O動作. 當有大量的ETL作業同時執行時通常會導致效能問題, 而因為效能問題而需要分散ETL作業時, 意謂著必須購買額外的軟體授權費用.
另一方面, 如果從擴充性來看, 通常使用者所可以連接的資料來源端或目的端, 也都受限於軟體廠商所提供的資料連接程式. 當使用者有特殊的資料來源端或目的端需要連接時. 一是向軟體廠商另外購買所需求的驅動程式. 二是透過軟體提供的API來建置自己所需的功能, 而這個部份通常需要較高的技術門檻.
為了能夠符合效能及擴充性的考量, 我們特別設計了Trinity這項產品. 在執行效能方面是透過JCS的分散式架構來達成, 而其中的Data Management模組是針對ETL的功能及擴充性. 底下我們會介紹Data Management中的各項特點以解釋如何來建置可擴充式的ETL作業架構.
Data Management Software Architecture and Plug-in
Trinity在一開始的其中一項設計目標就是可擴充性, 我們選擇以Java語言來進行開發. 而在Data Management模組當中, 我們也特別利用了Java的延展特性來設計Data Management模組架構. 並開放Plug-in的擴充性讓使用者也可以針對自己的需求來自動開發所需的Plug-in並加入到Data Management模組當中來執行. 如此可避免工具軟體廠商因無法支援客戶本身一些特殊需求而有所限制.
接下來讓我們先了解一下Data Management的軟體設計架構.
軟體架構
Figure-1
上面這張圖所描述的整體Data Management的軟體架構. 在圖中下方部份是核心部份, 對Data Management的核心部份來說可以分成五個部份, 分別是 Wrapper, Data Reader, Data Transformer, Data Writer及Data Queue. 而在圖中的上半部則是Plug-in實做部份.
Wrapper
在Data Management當中, Wrapper是負責啟始並執行一項Data Management的工作(Task). Wrapper 首先會讀取所指定的XML設定檔, 將設定檔中所指定的Reader Plug-In, Transformer Plug-In, Writer Plug-In 及Data Queue物件一一地動態載入進來並進行物件初始化的動作. 在成功完成初始化動作之後會分別啟動Reader Plug-In, Transformer Plug-In及Writer Plug-In各自的Thread來執行. 在執行過程當中, Wrapper會持續的監看各Plug-In的執行狀況並收集執行時期的處理資訊, 例如資料筆數等, 並且Wrapper會將執行時所列印出來的訊息導入到指定的記錄檔中, 直到整個工作結束為止.
Data Reader
Data Reader的目的是從指定的資料來源中將資料讀進來後, 組合成內部可辨識的資料物件(DMRecord), 並將資料物件寫入到設定在Data Reader中的Date Queue. 這裡所指的資料來源可以是任何一種來源, 只要有對應的Reader Plug-In可以處理來源資料, 就可以將之加入到Data Management模組當中來使用. Data Reader 物件所注重的完全是資料的讀取功能面, 並不須要知道後續的資料處理流程或邏輯. 對Data Reader來說, 讀取進來資料的唯一出路就是輸出到Data Queue當中. 而在Data Queue的另一端所連接的可能是任何一個Data Transformer Plug-In或者是Data Writer Plug-In物件.
Data Reader在執行時是在自己的一個獨立Thread當中執行.
Figure-2(Data Reader Design)
Data Transformer
Data Transformer的目的是從一端的輸入Data Queue中讀取資料物件, 經過必需的轉換過濾或處理邏輯後, 將處理過後的資料物件寫入到另一端的輸出Data Queue當中. 對Data Transformer來說, 本身的處理邏輯是完全地與資料來源及資料目的分離的. Data Transformer並不知道所處理的資料從何而來及要往何去. 與Data Transformer所連接的是多個(最多16個)資料輸入的Data Queue及多個(最多16個)資料輸出的Data Queue.
Data Transformer在執行時是在自己的一個獨立Thread當中執行.
Figure-3(Data Transformer Design)
Data Writer
Data Writer的目的是從一端的輸入Data Queue中讀取資料物件, 將資料物件中包含的資料寫入到指定的資料目標中. 對Data Writer來說, 資料的真正來源是那裡並不會影響Data Writer的處理邏輯. Data Writer的資料來源只有一個, 也就是所設定的輸入Data Queue. 而在Data Queue的另一端可能是任何一個Data Reader 的Plug-In或Data Transformer的Plug-In. Data Writer所需要注重的是如何將資料輸出到指定的資料目標當中, 只要有對應的Data Writer Plug-In可以輸出資料到目標, 就可以將之加入到Data Management模組當中來使用.
Data Writer在執行時是在自己的一個獨立Thread當中執行.
Figure-4(Data Writer Design)
Data Queue
Figure-5(Data Queue)
Data Queue 的目的是在Data Management模組當中進行資料傳遞的功能. Data Queue 物件當中有兩個端點, 分別是左端點(Left Endpoint)及右端點(Right Endpoint). 左端點是用來寫入資料物件到Data Queue當中, 而右端點則是用來從Data Queue中讀取資料物件用的. 資料物件是以先進先出(First In, First Out)的方法來決定進行的順序. Data Queue同時是用來連接Data Reader, Data Transformer, 或 Data Writer的橋樑. 可能的使用組合如下:
Data Reader => Data Transformer
Data Reader => Data Writer
Data Transformer => Data Writer
Data Transformer => Data Transformer
Data Queue物件在初始的時候可以指定內部用來存放資料物件的空間大小. 當資料物件來不及被取出而導致內部存放空間都被佔用時, 在此之後透過左端點的寫入動作會被暫停等待直到有資料物件被取出釋放出內部存放空間或者右端點被關閉後才從寫入等待的動作中返回. 而當內部存放空間沒有任何資料物件存在時, 此時透過右端點的讀取動作會被暫停等待直到有新的資料物件被寫入或者左端點被關閉後才會從先前的讀取等待中返回.
應用組合
依照上面所介紹的Data Management軟體架構, 使用者可以彈性的設定組合各式各樣的Plug-In來執行所需的ETL工作. 即使內建的Plug-In沒有符合使用者環境當中的資料來源或資料目標時, 使用者也可以很容易的自行開發所屬的Data Reader Plug-In或Data Writer Plug-In, 並將之整合進Data Management模組當中來使用. 在此架構下, 不但保留了最大的擴充性同時也保障了使用者在軟體建置方面的投資, 避免受到軟體廠商的限制.
繼續閱讀!
