基于OSGI的ETL設計與實現(xiàn)

程聰

【摘 要】隨著信息化以及大數(shù)據(jù)快速發(fā)展，結構化、半結構化、非結構化的數(shù)據(jù)越來越多，結構越來越繁雜，傳統(tǒng)的ETL已經(jīng)在數(shù)據(jù)整合方面存在很大的瓶頸，在可擴展性以及穩(wěn)定性方面存在很大的弊端。文章介紹了OSGI框架的技術特性，基于OSGI框架Equinox開發(fā)實現(xiàn)的hbust ETL的體系結構，最后詳細、著重地論述了hbust ETL核心bundle及其插件擴展點的設計與實現(xiàn)方法。hbust ETL具備很好的數(shù)據(jù)整合可擴展性以及穩(wěn)定性，特別在處理當下的大數(shù)據(jù)方面，具備很大的優(yōu)勢，不同bundle處理不同版本的hadoop、hive、hbase等等，不同版本大數(shù)據(jù)處理，可通過開發(fā)可擴展的bundle，發(fā)布于OSGI容器，不用修改ETL源代碼，即可進行該版本數(shù)據(jù)整合處理。

【關鍵詞】SOGI ?bundle;插件擴展點;ETL;數(shù)據(jù)處理

中圖分類號： TP311.52;TP399-C1 文獻標識碼： A 文章編號： 2095-2457（2019）03-0001-007

DOI：10.19694/j.cnki.issn2095-2457.2019.03.001

OSGI-based ETL design and implementation

CHENG Cong

（Hubei university of science and technology，School of computer science and technology，Hubei Xianning 437000， China）

【Abstract】With the rapid development of informatization and big data， there are more and more structured， semi-structured and unstructured data， and the structure is more and more complex. The traditional ETL has great bottlenecks in data integration， and great drawbacks in scalability and stability.The technical features of the OSGI framework， the architecture of the hbust ETL developed based on the OSGI framework Equinox， and the design and implementation of the hbust ETL core bundle and its plug-in extension points are discussed in detail and emphatically.hbust ETL has good expansibility and stability for data integration， especially in dealing with the current big data， have a lot of advantages， different bundle deal with different versions of the hadoop， hive， hbase， and so on， different versions of the data processing， but by developing extensible bundle， released on OSGI container， don't need to modify the ETL source code， this version can be made data integration process.

【Key words】SOGI; Bundle; Plug-in extension point; ETL; Data process

0 引言

ETL（Extract-Transform-Load）作為現(xiàn)在一種通用的數(shù)據(jù)遷移、裝載的數(shù)據(jù)處理工具，面對當今大數(shù)據(jù)、人工智能飛速發(fā)展的時代，ETL必須具備可擴展性，對接各種類型的關系數(shù)據(jù)庫、NoSQL數(shù)據(jù)庫、Hadoop、hive以及hbase等等繁雜存儲結構的數(shù)據(jù)以及各種各樣的基于規(guī)則的數(shù)據(jù)清洗。這些數(shù)據(jù)包括結構化、半結構化、非結構化數(shù)據(jù)，并且非結構化的數(shù)據(jù)越來越多。OSGI框架本身支持模塊化的動態(tài)部署，模塊的動態(tài)擴展，這種框架應用于ETL，各種類型數(shù)據(jù)在OSGI的框架容器的bundle中能夠獨立處理，使得ETL的動態(tài)可擴展性、系統(tǒng)穩(wěn)定性大大提高。

1 OSGI框架

OSGI（Open Service Gateway Initiative）技術是Java動態(tài)化模塊化系統(tǒng)的一系列規(guī)范，Java平臺的模塊層。OSGI框架一般具備的基礎功能：（1）支持模塊化的動態(tài)部署?；贠SGI而構建的系統(tǒng)可以以模塊化的方式動態(tài)地部署至框架中，從而增加、擴展或改變系統(tǒng)的功能。（2）支持模塊化的封裝和交互。每個工程（模塊）可通過聲明Export-Package對外提供訪問此工程的類和接口。（3）支持模塊的動態(tài)擴展?；贠SGI提供的面相服務的組件模型的設計方法，以及OSGI實現(xiàn)框架提供的擴展點方法可實現(xiàn)模塊的動態(tài)擴展。（4）模塊化的設計。在OSGI中模塊由一個或多個bundle構成，模塊之間的交互通過Import-Package、Export-Package以及OSGI Service的方式實現(xiàn)。（5）動態(tài)化的設計。動態(tài)化的設計是指系統(tǒng)中所有的模塊必須支持動態(tài)的插拔和修改，“即插即用，即刪即無”。（6）可擴展的設計。通常使用定義擴展點的方式。按照Eclipse推薦的擴展點插件的標準格式定義bundle中的擴展點，其它要擴展的bundle可通過實現(xiàn)相應的擴展點來擴展該bundle的功能。（7）每個bundle擁有獨立的classloader，通過它來完成本bundle類的加載。（8）穩(wěn)定、高效的系統(tǒng)?；贠SGI的系統(tǒng)采用的是微核機制，微核機制保證了系統(tǒng)的穩(wěn)定性，微核機制的系統(tǒng)只要微核是穩(wěn)定運行的，那么系統(tǒng)就不會崩潰，也就是說基于OSGI的系統(tǒng)不會受到運行在其中的bundle的影響，不會因為bundle的崩潰而導致整個系統(tǒng)的崩潰。

目前比較成熟、流行的OSGI框架有Equinox、felix。Equinox是Eclipse的項目，并作為OSGI R4 RI而知名，目前隨著Eclipse的版本而發(fā)布的，同時也提供獨立的下載。Equinox除了完整實現(xiàn)OSGI R4規(guī)范以外，還吸取了Eclipse的插件擴展點機制，bundle通過發(fā)布擴展點的方式來定義bundle可擴展部分，當需要擴展bundle的時候只需要實現(xiàn)bundle提供的擴展點的接口就可以了，通過這樣的方式就可以完成bundle的擴展。

2 hbust ETL

傳統(tǒng)的ETL工具模塊可擴展性差，一般只內(nèi)置幾種常見的數(shù)據(jù)處理組件。信息化數(shù)據(jù)中心建設中，結構化數(shù)據(jù)、半結構化數(shù)據(jù)、非結構化數(shù)據(jù)等各種存儲結構的數(shù)據(jù)，越來越繁雜，也越來越多，通常就是我們現(xiàn)在所說的大數(shù)據(jù)。傳統(tǒng)ETL在處理各種結構類型的數(shù)據(jù)，具有不適應性，一般只能通過修改源代碼內(nèi)置需要整合處理的數(shù)據(jù)處理方案，可擴展性、穩(wěn)定性得不到保障，也影響系統(tǒng)數(shù)據(jù)處理的性能。

本文介紹的ETL（hbust ETL）正是基于OSGI框架的Equinox進行開發(fā)，每個模塊作為一個獨立的bundle，bundle內(nèi)部可以定義擴展點，本bundle或其它bundle可以擴展實現(xiàn)該擴展點。整體大的模塊bundle分為engine bundle、database handler bundle、file handler bundle、transform rule bundle、 hadoop bundle、hbase bundle、hive bundle以及common bundle、other bundles等等。

2.1 hbust ETL設計：

圖1，服務器：采用OSGI的體系結構，每個功能模塊都是一個OSGI bundle。其中執(zhí)行引擎bundle定義了流程節(jié)點擴展點，數(shù)據(jù)清洗轉(zhuǎn)換規(guī)則bundle定義了基于規(guī)則的數(shù)據(jù)清洗擴展點，數(shù)據(jù)庫讀寫處理器bundle定義了數(shù)據(jù)庫讀寫處理擴展點，大數(shù)據(jù)處理bundle定義了大數(shù)據(jù)處理擴展點等等。系統(tǒng)內(nèi)置的組件和用戶擴展的組件都統(tǒng)一通過擴展點的方式實現(xiàn)，流程執(zhí)行時通過查詢系統(tǒng)擴展點信息來加載相應的類并執(zhí)行。

2.2 hbust ETL執(zhí)行引擎

hbust ETL中的流程包括數(shù)據(jù)流和控制流，其流程的結構是任意的，即任何結構的流程，只要其屬性配置正確即可被執(zhí)行。hbust ETL中的流程表示為一個節(jié)點和邊組成的有向無環(huán)圖。流程的執(zhí)行就是遍歷有向圖的過程。一個典型的流程圖如圖2所示，方框表示活動節(jié)點，帶有箭頭的線表示節(jié)點活動之間的關系。

圖1中的開始節(jié)點和結束節(jié)點是系統(tǒng)在流程執(zhí)行之前自動加上的，流程的執(zhí)行從開始節(jié)點啟動，直到結束節(jié)點執(zhí)行完成則整個流程執(zhí)行完成。每個節(jié)點執(zhí)行完自己的功能后再根據(jù)邊的指向找到下一個節(jié)點并啟動。

hbust ETL控制流

控制流的執(zhí)行過程如圖3所示，虛線箭頭代表一個線程，從下圖中可以看出，每個節(jié)點的功能由進入該節(jié)點的線程執(zhí)行，該線程執(zhí)行完當前節(jié)點的功能后，再跟邊的指向執(zhí)行下一個節(jié)點。如果當前節(jié)點有多個輸出則，則每個輸出都有一個對應的線程去執(zhí)行該輸出指向的節(jié)點。如果一個節(jié)點有多個輸入，則該節(jié)點需要等到多個線程都到達時才能開始執(zhí)行，此時該節(jié)點可以歸還一個線程，只保留一個線程繼續(xù)執(zhí)行。

數(shù)據(jù)流的執(zhí)行過程如圖4所示，與控制流相比，數(shù)據(jù)流的節(jié)點的遍歷和執(zhí)行是由不同的線程完成的，數(shù)據(jù)流節(jié)點遍歷的過程和控制流類似，只是對于數(shù)據(jù)流來說，遍歷的過程只是配置節(jié)點屬性和啟動節(jié)點線程，具體的數(shù)據(jù)處理是由每個節(jié)點自己的線程完成的。與控制流不同，數(shù)據(jù)流只有當所有的數(shù)據(jù)都處理完畢或者出錯才結束。

流水線是一個FIFO的同步隊列，上一個節(jié)點的線程將數(shù)據(jù)發(fā)送到隊列中，下一個節(jié)點則從隊列中取數(shù)據(jù)。

數(shù)據(jù)流節(jié)點的結構：

一個數(shù)據(jù)流的節(jié)點由輸入點、輸出點、容器和數(shù)據(jù)處理器4部分組成，如圖6所示：

輸入點和輸出點的個數(shù)決定了節(jié)點可以連接的輸入和輸出數(shù)量。節(jié)點容器實現(xiàn)節(jié)點的通用功能包括節(jié)點屬性的讀取、節(jié)點事件的發(fā)送、日志和統(tǒng)計信息的記錄、故障恢復、數(shù)據(jù)分區(qū)。

數(shù)據(jù)處理器實現(xiàn)具體的數(shù)據(jù)處理邏輯。容器根據(jù)當前節(jié)點的類型創(chuàng)建相應的數(shù)據(jù)處理器的實例后在一個獨立的線程中啟動它，數(shù)據(jù)的讀取、處理和發(fā)送都是數(shù)據(jù)處理器線程中執(zhí)行。

2.3 hbust ETL核心模塊bundle

2.3.1 Engine bundle

定義了擴展點"com.hbust.etl.engine.activities"?？刂屏鞴?jié)點需要擴展節(jié)點類型type和節(jié)點活動類名activityClass;數(shù)據(jù)流節(jié)點需要擴展節(jié)點類型type和節(jié)點活動類名activityClass，以及節(jié)點角色role，角色role分source、transformation以及destination三種，方便數(shù)據(jù)流節(jié)點抽取、轉(zhuǎn)換或裝載數(shù)據(jù)。

（2）擴展實現(xiàn)內(nèi)置的流程活動節(jié)點

2.3.2 database handler bundles

"com.hbust.etl.engine.activities"活動擴展點中，我們看到TableSource以及TableDestination的活動，涉及到數(shù)據(jù)庫讀寫相關的處理，目前不同的ETL使用場景，可能使用不同的數(shù)據(jù)庫，極可能出現(xiàn)場景中的數(shù)據(jù)庫在ETL沒有內(nèi)置，在不修改ETL源代碼的情況下，可以單獨開發(fā)bundle來對應未有內(nèi)置的數(shù)據(jù)庫的訪問處理。所以在數(shù)據(jù)庫讀寫訪問這塊，使用bundle以及插件擴展點的機制，完全可以進行各種數(shù)據(jù)庫讀寫的訪問。

（1）各種數(shù)據(jù)庫的通用操作，供其它特定的database handler bundle以import package或require bundle方式進行復用。

（2）定義數(shù)據(jù)庫處理擴展點。擴展點的定義與engine bundle的activity擴展點類似，定義數(shù)據(jù)庫的類型、版本以及數(shù)據(jù)庫操作的接口，在各自數(shù)據(jù)庫內(nèi)實現(xiàn)擴展該擴展點，實現(xiàn)數(shù)據(jù)庫操縱的接口的實現(xiàn)。

各種數(shù)據(jù)庫自己的bundle：

各種類型的數(shù)據(jù)庫，包括每種數(shù)據(jù)庫不同版本，實現(xiàn)一個bundle，該bundle內(nèi)部擴展實現(xiàn)該數(shù)據(jù)庫處理擴展點。這樣一來，每個bundle可以加載自己的JDBC，創(chuàng)建自己的數(shù)據(jù)庫連接，供engine bundle的連接池來管理，供engine bundle數(shù)據(jù)處理器使用。

2.3.3 Transform rule bundle：

"com.hbust.etl.engine.activities"活動擴展點中，我們也看到TransformRuleActivity活動，該Activity利用這種各樣的清洗規(guī)則對數(shù)據(jù)進行轉(zhuǎn)換清洗。同樣，我們在系統(tǒng)不可能內(nèi)置所有的清洗規(guī)則，在實際應用場景，必須要擴展注入某些清洗規(guī)則來清洗數(shù)據(jù)。在不修改ETL源代碼的情況下，同樣可以開發(fā)額外的數(shù)據(jù)清洗bundle，這些bundle擴展實現(xiàn)Transform rule bundle中定義的擴展點，實現(xiàn)數(shù)據(jù)清洗轉(zhuǎn)換類。

（1）定義數(shù)據(jù)清洗規(guī)則擴展點。擴展點的定義與engine bundle的activity擴展點類似，定義數(shù)據(jù)清洗規(guī)則類型、數(shù)據(jù)清洗的接口，在各自數(shù)據(jù)清洗bundle內(nèi)實現(xiàn)擴展該擴展點，實現(xiàn)數(shù)據(jù)清洗的接口的實現(xiàn)。

（2）實現(xiàn)數(shù)據(jù)清洗規(guī)則擴展點，然后注冊，供engine bundle數(shù)據(jù)處理器使用。

2.3.4 其它模塊bundle

各種文件的讀寫操作可放在common bundle進行擴展、注冊。當今的大數(shù)據(jù)的處理，比如hadoop、hive、hbase以及nosql數(shù)據(jù)庫的處理，同樣可以使用bundle以及插件擴展點的機制，對它們的各種版本的數(shù)據(jù)操作處理進行注冊，然后根據(jù)版本類型獲取自己的數(shù)據(jù)操縱類，進行數(shù)據(jù)的訪問。篇幅有限，不一一描述擴展點的定義以及擴展實現(xiàn)。

3 結束語

該文介紹了OSGI框架的技術特性，基于OSGI框架Equinox開發(fā)實現(xiàn)的hbust ETL的體系結構，hbust ETL核心bundle及其插件擴展點的設計與實現(xiàn)。hbust ETL利用OSGI bundle以及插件擴展點機制，大大地提升了ETL的可擴展性、系統(tǒng)穩(wěn)定性。面對當今各種復雜的數(shù)據(jù)處理，不修改源代碼的情況下，直接開發(fā)bundle擴展已經(jīng)定義的擴展點，完成各種類型的數(shù)據(jù)處理，包括大數(shù)據(jù)的處理。

【參考文獻】

[1]林昊，曾憲杰.OSGi原理與最佳實踐電子工業(yè)出版社.

[2]林昆.面向數(shù)據(jù)倉庫的ETL工具的研究與實現(xiàn)計算機技術與自動化，2018，01.

[3]王欣.數(shù)據(jù)集成技術若干問題的研究：[博士學位論文].上海交通大學2016.