異構(gòu)調(diào)度環(huán)境下ETL工作流監(jiān)控系統(tǒng)的設(shè)計與實現(xiàn)*

王洪彬， 王純

(1 北京郵電大學網(wǎng)絡(luò)與交換技術(shù)國家重點實驗室， 北京 100876；2 東信北郵信息技術(shù)有限公司， 北京 100191)

異構(gòu)調(diào)度環(huán)境下ETL工作流監(jiān)控系統(tǒng)的設(shè)計與實現(xiàn)*

王洪彬1，2， 王純1，2

(1 北京郵電大學網(wǎng)絡(luò)與交換技術(shù)國家重點實驗室， 北京 100876；2 東信北郵信息技術(shù)有限公司， 北京 100191)

本文提出一種分布式ETL在異構(gòu)調(diào)度環(huán)境下的工作流統(tǒng)一監(jiān)控方法。通過對異構(gòu)調(diào)度系統(tǒng)元數(shù)據(jù)的提取和抽象，采用增量抽取和跟蹤監(jiān)控對象的方式，通過網(wǎng)絡(luò)消息傳送將監(jiān)控對象加載到監(jiān)控數(shù)據(jù)中心并統(tǒng)一管理，實現(xiàn)了分布式ETL工作流在異構(gòu)調(diào)度環(huán)境下的的全局監(jiān)控，提高了數(shù)據(jù)恢復能力和倉庫的數(shù)據(jù)質(zhì)量。

數(shù)據(jù)倉庫；分布式ETL；Oozie；調(diào)度監(jiān)控

隨著計算能力和網(wǎng)絡(luò)存儲能力的不斷提高，傳統(tǒng)的數(shù)據(jù)存儲和數(shù)據(jù)處理能力已經(jīng)無法滿足大數(shù)據(jù)的服務(wù)需求。數(shù)據(jù)倉庫作為一種大數(shù)據(jù)平臺基礎(chǔ)和關(guān)鍵組成部分，被廣泛應(yīng)用在數(shù)據(jù)挖掘和分析領(lǐng)域。數(shù)據(jù)倉庫在整個大數(shù)據(jù)生態(tài)系統(tǒng)中通常承擔數(shù)據(jù)源的角色，所以數(shù)據(jù)倉庫的質(zhì)量直接影響著整個決策支持系統(tǒng)的服務(wù)質(zhì)量。

ETL（Extraction Transformation Loading)作為數(shù)據(jù)倉庫構(gòu)建的核心組件，貫穿于數(shù)據(jù)從產(chǎn)生到消亡的整個生命周期，從數(shù)據(jù)源的抽取、轉(zhuǎn)換，再到數(shù)據(jù)加載入庫，直到數(shù)據(jù)被消費的整個過程都需要通過ETL來完成的。目前多數(shù)系統(tǒng)根據(jù)各自業(yè)務(wù)的需要將ETL能力分布在不同的節(jié)點上，各個節(jié)點的ETL工作流在各自不同的調(diào)度環(huán)境下完成不同的功能，所有節(jié)點相互協(xié)作共同完成數(shù)據(jù)倉庫的構(gòu)建。在ETL工作流監(jiān)控方面，多數(shù)系統(tǒng)出于建立效率最優(yōu)模型的目的，通常注重系統(tǒng)資源層面的監(jiān)控和單一調(diào)度環(huán)境下ETL任務(wù)的監(jiān)控，普遍缺乏對全局ETL工作流在異構(gòu)調(diào)度環(huán)境中的實時監(jiān)控和統(tǒng)一監(jiān)管。

1 數(shù)據(jù)倉庫與調(diào)度環(huán)境

數(shù)據(jù)倉庫是一個面向主題的、集成的、非易失，隨時間變化的用來支持管理人員決策的數(shù)據(jù)集合。數(shù)據(jù)倉庫的構(gòu)建不僅僅指倉庫內(nèi)部數(shù)據(jù)的抽取、清洗、轉(zhuǎn)化、加載過程，也包括外部數(shù)據(jù)源的存儲與處理，例如對原始數(shù)據(jù)源的抽取、轉(zhuǎn)換、加載過程以及從倉庫向數(shù)據(jù)集市或OLAP系統(tǒng)的數(shù)據(jù)導出與同步過程等（如圖1所示），都涵蓋在數(shù)據(jù)倉庫的構(gòu)建過程中。

Oozie是Hadoop生態(tài)圈的一種工作流調(diào)度引擎，它運行在Java Servlet容器，底層把復雜的任務(wù)分解成map-reduce任務(wù)提交給Hadoop計算框架完成任務(wù)的執(zhí)行；在工程上Oozie的工作流定義和工作流實例狀態(tài)通常存儲在Mysql數(shù)據(jù)庫。所有基于Hadoop平臺的ETL任務(wù)都可以通過Oozie進行調(diào)度執(zhí)行，包括HDFS數(shù)據(jù)的抽取與加載，Hive表聯(lián)查，數(shù)據(jù)清洗與計算，數(shù)據(jù)匯總統(tǒng)計等。Oozie調(diào)度引擎主要面向運行于Hadoop平臺上的ETL工作流調(diào)度。

圖1 數(shù)據(jù)倉庫結(jié)構(gòu)

對于外部數(shù)據(jù)的ETL工作流調(diào)度，包括對原始數(shù)據(jù)源的抽取、轉(zhuǎn)換、加載、同步等流程同樣需要調(diào)度系統(tǒng)的支持。由于原始數(shù)據(jù)源的多樣性以及數(shù)據(jù)源平臺的異構(gòu)性導致Oozie不適合作為處理外部數(shù)據(jù)源工作流的調(diào)度工具，一方面是由于Oozie需要依賴Hadoop和Mysql等系統(tǒng)模塊的支持，與Hadoop和Mysql高度耦合，運行體系龐大，系統(tǒng)部署維護難度大；另一方面是由于Oozie調(diào)度系統(tǒng)占用系統(tǒng)資源較多，不適合在數(shù)據(jù)源平臺運行。所以對于外部數(shù)據(jù)源的抽取、轉(zhuǎn)換與同步作業(yè)的調(diào)度通常采用自研調(diào)度系統(tǒng)。

自研調(diào)度系統(tǒng)是一種輕量級、具有高可擴展和可移植性的調(diào)度系統(tǒng)。自研調(diào)度系統(tǒng)對ETL任務(wù)組件提供統(tǒng)一的接口規(guī)范，并且與各功能組件低耦合，凡是符合自研調(diào)度系統(tǒng)接口規(guī)范的組件，都可以被調(diào)度系統(tǒng)調(diào)度執(zhí)行。自研調(diào)度系統(tǒng)的工作流定義和工作流實例狀態(tài)通常存儲在ETL能力節(jié)點的本地文件系統(tǒng)。目前自研調(diào)度系統(tǒng)已經(jīng)具備FTP上傳/下載、表提取、文件合并、備份刪除等能力。

由于Oozie調(diào)度系統(tǒng)與自研調(diào)度系統(tǒng)在實現(xiàn)機制與管理機制方面差異較大，缺乏統(tǒng)一的工作流運行狀態(tài)反饋和執(zhí)行結(jié)果反饋，造成了用戶對全局數(shù)據(jù)流向和ETL工作流調(diào)度進度難以掌控，對于數(shù)據(jù)的異常處理難以準確定位和二次調(diào)度?；诋悩?gòu)調(diào)度系統(tǒng)存在的問題，本文設(shè)計了一種對分布式ETL工作流在異構(gòu)調(diào)度環(huán)境下的統(tǒng)一監(jiān)控方法，采用對工作流對象增量抽取和跟蹤的方式，對異構(gòu)調(diào)度環(huán)境下的全局ETL工作流進行統(tǒng)一監(jiān)管，實現(xiàn)了對數(shù)據(jù)流向的實時掌控和調(diào)度進度的全面管理。

2 調(diào)度監(jiān)控系統(tǒng)設(shè)計

監(jiān)控對象是指在調(diào)度系統(tǒng)中全部被用戶納入監(jiān)控目標的實體，ETL任務(wù)的依賴關(guān)系、執(zhí)行規(guī)則、執(zhí)行狀態(tài)與運行結(jié)果等都屬于監(jiān)控對象的范疇。獲取監(jiān)控對象較直接和較可靠的辦法是對每個ETL任務(wù)的元數(shù)據(jù)進行提取和轉(zhuǎn)化。但是由于調(diào)度環(huán)境的異構(gòu)性，自研調(diào)度環(huán)境的ETL任務(wù)主要面向外部數(shù)據(jù)的存儲和處理，包括數(shù)據(jù)源的提取、轉(zhuǎn)碼、清洗和加載等，其元數(shù)據(jù)集中存儲在各能力節(jié)點的文件系統(tǒng)中，Oozie調(diào)度環(huán)境主要面向倉庫內(nèi)部數(shù)據(jù)的存儲和計算，支持對Java、Mapreduce、Hive、Sqoop等任務(wù)的調(diào)度，其元數(shù)據(jù)存儲在Mysql關(guān)系型數(shù)據(jù)庫中（如圖2所示）。

圖2 Oozie調(diào)度環(huán)境與自研調(diào)度環(huán)境

為了將兩種不同調(diào)度環(huán)境下的監(jiān)控對象進行統(tǒng)一管理，解決元數(shù)據(jù)存儲結(jié)構(gòu)的差異性，本文從ETL工作流元數(shù)據(jù)底層存儲結(jié)構(gòu)著手，將異構(gòu)存儲的元數(shù)據(jù)進行過濾提取和抽象建模，并轉(zhuǎn)換成統(tǒng)一的目標監(jiān)控對象，從而屏蔽了底層元數(shù)據(jù)的差異。

該方法的核心思想是將分布在每個節(jié)點上ETL工作流監(jiān)控分成兩個過程，第一個過程按照既定的抽取規(guī)則生成監(jiān)控對象并進行增量提取，完成后將抽取的對象交付給另一過程，同時繼續(xù)監(jiān)控和抽取新增對象；另一過程負責對已抽取的監(jiān)控對象進行增量跟蹤，同時記錄監(jiān)控對象的運行狀態(tài)信息，當發(fā)現(xiàn)被監(jiān)控對象的狀態(tài)有更新時就通過網(wǎng)絡(luò)消息通知管理節(jié)點更新監(jiān)控數(shù)據(jù)中心的狀態(tài)，一旦監(jiān)測到監(jiān)控對象處于完成態(tài)就終結(jié)對該監(jiān)控對象的跟蹤。為此對監(jiān)控系統(tǒng)進行角色分配，將負責元數(shù)據(jù)抽取的能力節(jié)點定義為Worker，把負責將Worker進行收斂并加載到監(jiān)控數(shù)據(jù)中心的能力節(jié)點定義為Manager。Worker與Manager共同實現(xiàn)了在不同調(diào)度環(huán)境下對全局ETL工作流的統(tǒng)一跟蹤和監(jiān)控。

2.1 Worker設(shè)計

Worker負責ETL任務(wù)元數(shù)據(jù)的抽取和跟蹤。Worker在邏輯結(jié)構(gòu)上可以劃分為4層，分別是元數(shù)據(jù)層、抽象層、跟蹤層和收發(fā)層（如圖3所示）。

元數(shù)據(jù)是描述數(shù)據(jù)的數(shù)據(jù)，元數(shù)據(jù)層存儲了所有ETL工作流的元數(shù)據(jù)，其中涵蓋了工作流的依賴關(guān)系、執(zhí)行規(guī)則、運行狀態(tài)和執(zhí)行結(jié)果，除此之外還包含許多噪聲信息。對于不同的存儲方式，元數(shù)據(jù)的描述方式也不同。在文本文件中，元數(shù)據(jù)以文本的形式描述，在Mysql數(shù)據(jù)庫中元數(shù)據(jù)以表字段形式描述，在XML文件中以節(jié)點字段描述。在監(jiān)控對象抽取過程中，必須先對監(jiān)控對象進行建模，再從繁雜的元數(shù)據(jù)中過濾掉冗余信息，篩選出需要的數(shù)據(jù)組合。

抽象層將異構(gòu)元數(shù)據(jù)進行抽象、過濾和統(tǒng)一，并根據(jù)既定的監(jiān)控規(guī)則對監(jiān)控對象建模和提取。首先由抽象過濾器從繁雜的元數(shù)據(jù)集中提取和過濾出有效元數(shù)據(jù)，然后根據(jù)規(guī)則引擎定義的監(jiān)控規(guī)則對監(jiān)控對象進行建模，并利用過濾提取的元數(shù)據(jù)將監(jiān)控對象實例化。規(guī)則引擎定義了監(jiān)控對象的模型，可通過修改規(guī)則引擎，實現(xiàn)不同監(jiān)控對象的靈活構(gòu)建。實例化后的監(jiān)控對象包含了ETL工作流的初始狀態(tài)信息，通過增量監(jiān)控器的提取和判決，將抽取的監(jiān)控對象提交到跟蹤層，由跟蹤層負責對該監(jiān)控對象后續(xù)狀態(tài)的跟蹤。

圖3 Worker邏輯結(jié)構(gòu)

跟蹤層負責對監(jiān)控對象進行狀態(tài)跟蹤和更新。跟蹤器中含有監(jiān)控對象的初始狀態(tài)信息和特征標識信息，為了提高監(jiān)控對象的監(jiān)控效率和準確性，跟蹤層繞過抽象層直接到元數(shù)據(jù)層定向獲取監(jiān)控對象的狀態(tài)信息。在獲取監(jiān)控狀態(tài)時可能獲取到監(jiān)控對象狀態(tài)未變的情況，此時對于監(jiān)控數(shù)據(jù)中心來說是不必感知的。所以為了降低系統(tǒng)和網(wǎng)絡(luò)帶寬的負荷，在跟蹤層增加一個狀態(tài)機模塊，用于監(jiān)控對象的狀態(tài)維護，當跟蹤器獲取到監(jiān)控對象的狀態(tài)信息時，就從狀態(tài)機中查詢該監(jiān)控對象狀態(tài)是否有更新，對于未更新的狀態(tài)，跟蹤器將獲取的狀態(tài)信息刪除，對于有更新的狀態(tài)，跟蹤器首先更新狀態(tài)機中的信息，然后將更新提交到消息收發(fā)層，將更新通知監(jiān)控數(shù)據(jù)中心，實現(xiàn)了對監(jiān)控對象狀態(tài)的增量提取。狀態(tài)機保存所有未完成狀態(tài)的監(jiān)控對象的狀態(tài)信息，當監(jiān)控對象到達完成態(tài)時，就將該監(jiān)控對象從狀態(tài)機刪除，采用增量提取監(jiān)控對象的方法，大大節(jié)省了系統(tǒng)內(nèi)存和網(wǎng)絡(luò)帶寬資源。

收發(fā)層處于Worker邏輯層的最上層，負責與Manager直接進行網(wǎng)絡(luò)消息交互。格式化消息不適合在網(wǎng)絡(luò)上傳輸，收發(fā)層負責將底層提交的格式化消息按照協(xié)議進行格式編碼，編碼后將消息發(fā)送到Manager。Worker與Manager之間的通信鏈路維護機制參考了Hadoop計算框架Tasktracker與Jobtracker之間的心跳機制，通過收發(fā)心跳消息來監(jiān)測和保持鏈路。每個Worker在向Manager發(fā)送消息前，必須進行登錄和認證，只有認證成功后才可以向Manager發(fā)送消息。

2.2 Manager設(shè)計

Manager負責對分布式的Worker節(jié)點進行信息收斂，并將監(jiān)控對象加載到監(jiān)控數(shù)據(jù)中心，同時提供分析呈現(xiàn)接口，負責對全局ETL工作流狀態(tài)的訪問。Manager在邏輯上可以分成3層，分別為收發(fā)層，加載層和呈現(xiàn)分析層（如圖4所示）。

收發(fā)層處于Manager的最底層，直接與Worker進行網(wǎng)絡(luò)消息交互，其中包括控制類消息和業(yè)務(wù)類消息，控制類消息包括登錄認證消息和心跳消息，業(yè)務(wù)類消息包括承載各種監(jiān)控對象的監(jiān)控消息。Manager在接收到消息后，首先對消息進行解碼，將流式消息解析成格式化消息。對于控制類消息，由收發(fā)層直接處理，并進行相應(yīng)的消息回復；對于業(yè)務(wù)類消息，則提交到加載層，由加載層將監(jiān)控信息加載到監(jiān)控數(shù)據(jù)中心供上層訪問。

圖4 Manager邏輯結(jié)構(gòu)

消息到達加載層后，需要對結(jié)構(gòu)化消息進行二次處理，抽取出內(nèi)層結(jié)構(gòu)數(shù)據(jù)，同時根據(jù)監(jiān)控數(shù)據(jù)中心預(yù)先定義的關(guān)系模型將抽取的監(jiān)控數(shù)據(jù)進行格式化處理。由于元數(shù)據(jù)的差異已經(jīng)在Worker側(cè)屏蔽，加載層無需對元數(shù)據(jù)的結(jié)構(gòu)進行抽取和過濾，只需要把數(shù)據(jù)轉(zhuǎn)換成符合監(jiān)控數(shù)據(jù)中心定義的格式，由加載層按關(guān)系模型將數(shù)據(jù)逐條加載到監(jiān)控數(shù)據(jù)中心。

監(jiān)控數(shù)據(jù)中心集中了全局ETL工作流的所有信息，包括任務(wù)間的依賴關(guān)系，子任務(wù)間的依賴關(guān)系，任務(wù)的執(zhí)行規(guī)則、運行狀態(tài)、執(zhí)行結(jié)果等。分布式ETL任務(wù)的信息由監(jiān)控數(shù)據(jù)中心集中匯總，實現(xiàn)了全局ETL工作流的統(tǒng)一監(jiān)管。

用戶通過訪問監(jiān)控數(shù)據(jù)中心，可以掌控全局ETL工作流的數(shù)據(jù)流向和運行狀態(tài)，為異常數(shù)據(jù)監(jiān)控分析和數(shù)據(jù)修復提供了有效工具。用戶也可以分析出調(diào)度監(jiān)控系統(tǒng)每天監(jiān)控的ETL任務(wù)總數(shù)、任務(wù)更新次數(shù)、成功任務(wù)總數(shù)、消息傳輸最大時延等信息，從而也實現(xiàn)了對全局ETL工作流監(jiān)控系統(tǒng)本身的監(jiān)控。

3 調(diào)度監(jiān)控系統(tǒng)的實現(xiàn)和應(yīng)用

物理結(jié)構(gòu)實現(xiàn)方面，在每個ETL能力節(jié)點上配備一個Worker，負責對該ETL能力節(jié)點的監(jiān)控。全局配備唯一的Manager，匯聚各個分散的Worker監(jiān)控信息并統(tǒng)一加載到監(jiān)控數(shù)據(jù)中心進行監(jiān)控和分析。

基于調(diào)度監(jiān)控系統(tǒng)運作平臺的多樣性，Worker與Manager的消息交互使用通用的網(wǎng)絡(luò)進程間通信技術(shù)，采用傳統(tǒng)的C/S體系架構(gòu)，降低了系統(tǒng)平臺對調(diào)度監(jiān)控系統(tǒng)運行環(huán)境的限制。元數(shù)據(jù)存儲在異構(gòu)介質(zhì)中，Worker在抽取監(jiān)控對象時存在差異，現(xiàn)存系統(tǒng)將元數(shù)據(jù)存儲在Mysql和文件系統(tǒng)中，未來調(diào)度系統(tǒng)元數(shù)據(jù)可能存儲在HDFS或Redis中，為了增強系統(tǒng)的擴展性，Worker預(yù)留了擴展接口，實際應(yīng)用中可根據(jù)存儲介質(zhì)的不同特性去實現(xiàn)。調(diào)度監(jiān)控系統(tǒng)使用了時間觸發(fā)和消息觸發(fā)機制。時間觸發(fā)定時操作，依賴關(guān)系、執(zhí)行規(guī)則等監(jiān)控對象凡是需要周期操作的工作都由時間觸發(fā)機制實現(xiàn)。Manager匯聚各Worker節(jié)點的過程由消息觸發(fā)機制實現(xiàn)，Worker發(fā)送的鑒權(quán)消息、心跳消息、業(yè)務(wù)消息等都會通過觸發(fā)Manager特定消息處理流程來完成鏈路的創(chuàng)建、維持和消息加載。

目前調(diào)度監(jiān)控系統(tǒng)已經(jīng)具備應(yīng)用能力，能夠?qū)崿F(xiàn)對分布式ETL能力節(jié)點在異構(gòu)調(diào)度環(huán)境下的統(tǒng)一監(jiān)控。通過訪問監(jiān)控數(shù)據(jù)中心的集中數(shù)據(jù)庫，能夠掌控數(shù)據(jù)倉庫構(gòu)建過程中全局數(shù)據(jù)的實時流向，為數(shù)據(jù)恢復和任務(wù)重跑提供可靠依據(jù)。同時可以通過查看各ETL能力節(jié)點下任務(wù)的依賴關(guān)系、執(zhí)行規(guī)則、運行狀態(tài)和執(zhí)行結(jié)果等來了解各個ETL能力節(jié)點的運行情況，為ETL系統(tǒng)資源分配和能力優(yōu)化提供重要參考。調(diào)度監(jiān)控系統(tǒng)在數(shù)據(jù)倉庫構(gòu)建過程中的應(yīng)用大大降低了ETL系統(tǒng)維護成本，減輕了維護人員的工作負擔，增強了數(shù)據(jù)監(jiān)管能力和數(shù)據(jù)質(zhì)量保證，為大數(shù)據(jù)挖掘和分析提供了更加可靠的數(shù)據(jù)源。

4 結(jié)束語

數(shù)據(jù)的抽取、轉(zhuǎn)換、加載過程是構(gòu)建數(shù)據(jù)倉庫的核心環(huán)節(jié)，對ETL過程的監(jiān)控也是保證數(shù)據(jù)質(zhì)量、提高系統(tǒng)可靠性的關(guān)鍵環(huán)節(jié)，在分布式ETL在異構(gòu)調(diào)度環(huán)境下難以統(tǒng)一監(jiān)管的條件下，ETL執(zhí)行過程的優(yōu)劣直接影響著整個決策支持系統(tǒng)的服務(wù)質(zhì)量。

本文提出的調(diào)度監(jiān)控思想從過程層面實現(xiàn)對分布式ETL工作流的監(jiān)控，為數(shù)據(jù)倉庫的數(shù)據(jù)質(zhì)量提供了重要保證，但是過程層面的監(jiān)控還無法全面保證倉庫的數(shù)據(jù)質(zhì)量，數(shù)據(jù)層面的監(jiān)控對提高倉庫數(shù)據(jù)質(zhì)量同等重要，通過對數(shù)據(jù)源或中間數(shù)據(jù)在數(shù)量、時延、同環(huán)比方面的監(jiān)控，結(jié)合調(diào)度監(jiān)控的結(jié)果，可實現(xiàn)對ETL工作流在過程層面和數(shù)據(jù)層面的全面監(jiān)控，能夠更有效的保證數(shù)據(jù)倉庫的數(shù)據(jù)質(zhì)量，增強倉庫自愈能力。

Design and implementation of monitoring system for the ETL workflows in heterogeneous scheduling environment

WANG Hong-bin1,2, WANG Chun1,2
(1 State Key Lab of Networking and Switching Technology, Beijing University of Posts and Telecommunications, Beijing 100876, China; 2 EBUPT Information Technology Co., Ltd., Beijing 100191, China)

This paper provided a unified monitoring method of the distributed ETL workflows in heterogeneous environment. By extracting and abstracting the metadata of each workfl ow and tracing the monitored objects incrementally, all the ETL jobs could be monitored and managed by the monitor data center, meanwhile improving the quality of the data warehouse.

data warehouse; distributed ETL; Oozie; scheduling monitor

TN915

A

1008-5599（2016）12-0061-05

2016-07-18

國家杰出青年科學基金(No．60525110)；國家973計劃項目(No．2007CB307100，2007CB307103)；國家自然科學基金(No．61072057，60902051)；中央高?；究蒲袠I(yè)務(wù)費專項資金(BUPT2009RC0505)；國家科技重大專項(No．2011ZX03002-001-01，2001ZX03002-002-01)。