文章來源：中國(guó)聯(lián)通網(wǎng)研院網(wǎng)優(yōu)網(wǎng)管部——IT技術(shù)研究團(tuán)隊(duì)

作者：楊杉

1. 數(shù)據(jù)集成和ETL

        隨著移動(dòng)互聯(lián)網(wǎng)、云計(jì)算、物聯(lián)網(wǎng)等信息技術(shù)的飛速發(fā)展，越來越多的數(shù)據(jù)被產(chǎn)生，整個(gè)社會(huì)正在加速進(jìn)入了“大數(shù)據(jù)”時(shí)代。對(duì)于企業(yè)來說，數(shù)據(jù)已經(jīng)成為企業(yè)的財(cái)富，也是一種重要的戰(zhàn)略資源。但在一個(gè)企業(yè)中，不同類型的數(shù)據(jù)通常是分布在若干個(gè)獨(dú)立的信息系統(tǒng)中。以運(yùn)營(yíng)商為例，用戶的計(jì)費(fèi)和賬單信息由信息化或市場(chǎng)部門的經(jīng)營(yíng)分析系統(tǒng)生成和維護(hù)，而用戶在網(wǎng)絡(luò)中所產(chǎn)生的信令和上網(wǎng)行為記錄則由網(wǎng)絡(luò)運(yùn)維部門的網(wǎng)絡(luò)運(yùn)維系統(tǒng)存儲(chǔ)。由于種種歷史和現(xiàn)實(shí)原因，這些獨(dú)立的信息系統(tǒng)之間缺少統(tǒng)一的接口，且數(shù)據(jù)結(jié)構(gòu)差異巨大，造成企業(yè)內(nèi)部的數(shù)據(jù)融合困難，也無法充分挖掘數(shù)據(jù)所包含的經(jīng)濟(jì)和社會(huì)價(jià)值。

        如何將這些相互關(guān)聯(lián)的分布式異構(gòu)數(shù)據(jù)源集成在一起，能夠讓上層用戶無視不同系統(tǒng)的數(shù)據(jù)差異，透明的方式訪問這些數(shù)據(jù)，就是數(shù)據(jù)集成所要解決的問題。下圖給出了一個(gè)典型的商業(yè)智能（BI：Business Intelligence）系統(tǒng)架構(gòu)。

        可以看到數(shù)據(jù)集成包含了：ETL、主數(shù)據(jù)管理、數(shù)據(jù)質(zhì)量監(jiān)控、元數(shù)據(jù)管理、數(shù)據(jù)生命周期管理共五大功能模塊。在這個(gè)專題中，我們將依次對(duì)這些功能模塊進(jìn)行詳細(xì)介紹，本片公眾號(hào)將重點(diǎn)介紹ETL的主要流程和技術(shù)架構(gòu)。

2. ETL流程介紹

        ETL是數(shù)據(jù)抽取、轉(zhuǎn)換和裝載（Extract，Transformation，Loading）的英文簡(jiǎn)稱，是數(shù)據(jù)倉庫獲取高質(zhì)量數(shù)據(jù)的關(guān)鍵環(huán)節(jié)，是對(duì)分散在各業(yè)務(wù)系統(tǒng)中的現(xiàn)有數(shù)據(jù)進(jìn)行提取、轉(zhuǎn)換、清洗和加載的過程，使這些數(shù)據(jù)成為商業(yè)智能系統(tǒng)需要的有用數(shù)據(jù)。ETL是數(shù)據(jù)集成的第一步，也是構(gòu)建數(shù)據(jù)倉庫最重要的步驟。

        下面我們以從某運(yùn)維平臺(tái)獲取的各省RNC基礎(chǔ)工參數(shù)據(jù)為例說明ETL主要流程。

        上圖給出了3個(gè)省級(jí)運(yùn)維平臺(tái)數(shù)據(jù)庫中RNC基礎(chǔ)工參數(shù)據(jù)的字段信息。通過對(duì)比，初步發(fā)現(xiàn)以下問題：

• 問題1： A、B省使用了中文表名、而C省使用了英文表名；

• 問題2： A省數(shù)據(jù)內(nèi)容相對(duì)豐富，但是B省和C省都有不同程度的數(shù)據(jù)內(nèi)容缺失情況，例如B省缺失“NodeB數(shù)量”等字段，C省缺失“所屬SGSN”字段；

• 問題3：A、B、C省相同的字段內(nèi)容使用了不同的名稱，例如A省的“所屬城市標(biāo)識(shí)”分別對(duì)應(yīng)B省的“城市標(biāo)識(shí)”和C省的“city_id”。A省的“載頻數(shù)目”對(duì)應(yīng)B省的“載波數(shù)”和C省的”freq_num”；

• 問題4：A、B、C省均存在字段名稱相近，但實(shí)際取值需要轉(zhuǎn)換的字段。例如A省”廠商標(biāo)識(shí)”字段取值為“1,2,3,4,5”，對(duì)應(yīng)B省“廠商名稱”字段的“華為、中興、阿郎、諾西、愛立信”；

• 問題5：A、C省中”Iu接口配置帶寬”單位為Mbps，但B省該字段的單位為bps，為便于后續(xù)分析對(duì)比，需要進(jìn)行轉(zhuǎn)換；

• 問題6：由于這是RNC基礎(chǔ)工參信息表，所以“RNC標(biāo)識(shí)”字段應(yīng)為非空。但在實(shí)際數(shù)據(jù)中，卻存在”RNC標(biāo)識(shí)”為空的無效數(shù)據(jù)，需要清洗。

2.1 數(shù)據(jù)抽取（Data Extract）

        數(shù)據(jù)抽取指的是從不同的網(wǎng)絡(luò)、不同的操作平臺(tái)、不同的數(shù)據(jù)庫和數(shù)據(jù)格式、不同的應(yīng)用中抽取數(shù)據(jù)的過程。在這個(gè)過程中，首先需要結(jié)合業(yè)務(wù)需求確定抽取的字段，形成一張公共需求表頭，并且每個(gè)省的數(shù)據(jù)庫字段也應(yīng)與這些需求字段形成一一映射關(guān)系。這樣通過數(shù)據(jù)抽取所得到的數(shù)據(jù)都具有統(tǒng)一、規(guī)整的字段內(nèi)容，為后續(xù)的數(shù)據(jù)轉(zhuǎn)換和加載提供基礎(chǔ)。

         在上圖中可以觀察到，雖然B省數(shù)據(jù)庫中缺少“NodeB數(shù)量”、“單載頻NodeB數(shù)量”、 “雙載頻NodeB數(shù)量”、 “三載頻NodeB數(shù)量”信息，但這些信息能夠較為重要，所以依然將這些字段包含在需求字段中，只是從B省抽取的數(shù)據(jù)中這些字段內(nèi)容為空。

        通過數(shù)據(jù)抽取，我們可以有效的解決剛才提到的問題1-3。但是需要特別說明的是，數(shù)據(jù)抽取并不僅僅是根據(jù)業(yè)務(wù)確定公共需求字段。更涉及到從不同類型的數(shù)據(jù)庫（Oracle、Mysql、DB2、Vertica等）、不同類型的文件系統(tǒng)（Linux、Windows、HDFS）、以何種方式（數(shù)據(jù)庫抽取、文件傳輸、流式）、何種頻率（分鐘、小時(shí)、天、周、月）、何種抽取方式（全量抽取、增量抽?。┇@取數(shù)據(jù)。所以具體的實(shí)現(xiàn)也包含了大量的工作和技術(shù)難點(diǎn)。

2.2 數(shù)據(jù)轉(zhuǎn)換（Data Transformation）

        數(shù)據(jù)轉(zhuǎn)換就是處理抽取上來的數(shù)據(jù)中存在的不一致的過程。數(shù)據(jù)轉(zhuǎn)換一般包括兩類：

        第一類：數(shù)據(jù)名稱及格式的統(tǒng)一，即數(shù)據(jù)粒度轉(zhuǎn)換、商務(wù)規(guī)則計(jì)算以及統(tǒng)一的命名、數(shù)據(jù)格式、計(jì)量單位等；針對(duì)問題4中的”廠商標(biāo)識(shí)”字段，將取值統(tǒng)一為“華為、中興、阿郎、諾西、愛立信”。這樣就需要對(duì)A省的該字段取值“1,2,3,4,5”根據(jù)映射關(guān)系進(jìn)行數(shù)據(jù)轉(zhuǎn)換；而對(duì)于問題5中的”Iu接口配置帶寬”字段，則將單位統(tǒng)一為Mbps，這樣在對(duì)B省數(shù)據(jù)進(jìn)行處理時(shí)，需要對(duì)取值除以1000000進(jìn)行匹配。

        第二類：數(shù)據(jù)倉庫中存在源數(shù)據(jù)庫中可能不存在的數(shù)據(jù)，因此需要進(jìn)行字段的組合、分割或計(jì)算。以運(yùn)營(yíng)商獲取的用戶上網(wǎng)詳單為例，需要根據(jù)用戶上網(wǎng)內(nèi)容和流量類型確定用戶使用的業(yè)務(wù)類型（流媒體、即時(shí)通信、下載、瀏覽等），生成相應(yīng)字段。并對(duì)單個(gè)用戶在單個(gè)小區(qū)的各類型業(yè)務(wù)流量、次數(shù)、時(shí)間進(jìn)行匯總統(tǒng)計(jì)

        數(shù)據(jù)轉(zhuǎn)換實(shí)際上還包含了數(shù)據(jù)清洗的工作，需要根據(jù)業(yè)務(wù)規(guī)則對(duì)異常數(shù)據(jù)進(jìn)行清洗，保證后續(xù)分析結(jié)果的準(zhǔn)確性。問題6中“RNC標(biāo)識(shí)”為空的字段將會(huì)被清除。

2.3 數(shù)據(jù)加載（Data Loading）

        數(shù)據(jù)裝載的主要任務(wù)是將經(jīng)過清洗后的干凈的數(shù)據(jù)集按照物理數(shù)據(jù)模型定義的表結(jié)構(gòu)裝入目標(biāo)數(shù)據(jù)倉庫的數(shù)據(jù)表中，并允許人工干預(yù)，以及提供強(qiáng)大的錯(cuò)誤報(bào)告、系統(tǒng)日志、數(shù)據(jù)備份與恢復(fù)功能。整個(gè)操作過程往往要跨網(wǎng)絡(luò)、跨操作平臺(tái)。在實(shí)際的工作中，數(shù)據(jù)加載需要結(jié)合使用的數(shù)據(jù)庫系統(tǒng)（Oracle、Mysql、Spark、Impala等），確定最優(yōu)的數(shù)據(jù)加載方案，節(jié)約CPU、硬盤IO和網(wǎng)絡(luò)傳輸資源。

3. 分布式ETL技術(shù)架構(gòu)

        傳統(tǒng)ETL通常都是采用昂貴的ETL工具（Datastage、SSIS等）基于高性能的小型機(jī)完成。這種方式已經(jīng)難以滿足“大數(shù)據(jù)”時(shí)代下TB甚至PB級(jí)的數(shù)據(jù)ETL需求，如何在有限的時(shí)間內(nèi)，高效高質(zhì)量的完成海量數(shù)據(jù)的ETL工作，對(duì)ETL技術(shù)的架構(gòu)設(shè)計(jì)也提出了更高的要求。

        目前主流的解決方案是通過對(duì)傳統(tǒng)ETL進(jìn)行橫向擴(kuò)展，將ETL工作轉(zhuǎn)化為并行或分布式的架構(gòu)，從而縮短數(shù)據(jù)處理時(shí)間。目前基于分布式的ETL技術(shù)架構(gòu)有以下兩種：

3.1 基于多Agent方式的ETL技術(shù)架構(gòu)

        該方法是將多Agent系統(tǒng)技術(shù)?1引入到分布式計(jì)算環(huán)境中，該分布式ETL框架把數(shù)據(jù)抽取、數(shù)據(jù)轉(zhuǎn)換和數(shù)據(jù)加載分別對(duì)應(yīng)成各個(gè)Agent，同時(shí)把每一個(gè)模塊比如元數(shù)據(jù)管理、作業(yè)管理和轉(zhuǎn)換函數(shù)管理等各對(duì)應(yīng)到一個(gè)Agent，然后利用Agent之間的協(xié)作性、主動(dòng)性和交互性來構(gòu)建分布式ETL框架。

        上圖給出了基于Agent的分布式ETL架構(gòu)。其中”ETL任務(wù)設(shè)計(jì)”模塊向用戶提供ETL工作流的設(shè)計(jì)界面?！盓TL任務(wù)管理”模塊則是分布式ETL的協(xié)調(diào)中心，向上（用戶）承接ETL作業(yè)的上傳、轉(zhuǎn)換函數(shù)的定義和日志瀏覽功能，向下（ETL執(zhí)行）基于元數(shù)據(jù)提供ETL作業(yè)轉(zhuǎn)換規(guī)則和作業(yè)調(diào)度?！盓TL任務(wù)執(zhí)行”模塊則是具體的執(zhí)行引擎，分布在各個(gè)實(shí)體服務(wù)器上。通過各個(gè)Agent協(xié)作完成ETL的任務(wù)。

        這種架構(gòu)可以較好的解決分布式系統(tǒng)中的負(fù)載均衡問題，而且也能夠?qū)崿F(xiàn)準(zhǔn)實(shí)時(shí)的數(shù)據(jù)解析和入庫。但是該方式不能較好的保證各個(gè)Agent的穩(wěn)定性，一旦某個(gè)Agent出現(xiàn)故障，將會(huì)使整個(gè)系統(tǒng)處于崩潰狀態(tài)，甚至有可能導(dǎo)致數(shù)據(jù)的丟失。

3.2 基于MapReduce的ETL技術(shù)架構(gòu)

        Hadoop技術(shù)在其誕生之初就是定位于大數(shù)據(jù)的存儲(chǔ)、分析。所以在hadoop框架下基于MapReduce實(shí)現(xiàn)ETL也是很多企業(yè)自然而然的選擇。

        上圖中給出了一個(gè)典型的基于MapReduce的ETL技術(shù)架構(gòu)。 服務(wù)端主要包括元數(shù)據(jù)管理模塊、執(zhí)行引擎模塊、數(shù)據(jù)訪問模塊。元數(shù)據(jù)管理模塊是系統(tǒng)的基礎(chǔ)模塊，它描述了系統(tǒng)中所有數(shù)據(jù)結(jié)構(gòu)的定義，提供元數(shù)據(jù)存儲(chǔ)、訪問的服務(wù)。系統(tǒng)的其他模塊通過公共接口從元數(shù)據(jù)管理模塊獲得元數(shù)據(jù)信息。另外，元數(shù)據(jù)管理模塊提供接口用來導(dǎo)入導(dǎo)出元數(shù)據(jù)。執(zhí)行引擎模塊是系統(tǒng)的核心模塊，又分為流程解析和流程執(zhí)行兩個(gè)模塊。在流程解析模塊，執(zhí)行引擎獲取執(zhí)行流程的元數(shù)據(jù)信息，根據(jù)這些信息，生成相應(yīng)的工作流。流程執(zhí)行模塊完成從數(shù)據(jù)轉(zhuǎn)換到數(shù)據(jù)解析的所有任務(wù)。數(shù)據(jù)訪問模塊提供公共的數(shù)據(jù)訪問接口，它屏蔽了各種數(shù)據(jù)源之間的差異，以一種統(tǒng)一的方式對(duì)數(shù)據(jù)進(jìn)行查詢、刪除、修改。

        在基于MapReduce的ETL技術(shù)框架下，開發(fā)人員只需要Map和Reduce兩個(gè)函數(shù)進(jìn)行數(shù)據(jù)轉(zhuǎn)換的并行處理，并基于hadoop生態(tài)圈所提供的API接口進(jìn)行數(shù)據(jù)抽取和加載。這樣可以提高開發(fā)效率，而且系統(tǒng)的并行處理能力也有成熟hadoop生態(tài)圈得以保證。但是MapReduce程序啟動(dòng)較為耗時(shí)，并不適用于數(shù)據(jù)的實(shí)時(shí)加載和入庫，而且MapReduce作業(yè)流程的優(yōu)化也需要投入大量的時(shí)間。

4. 小結(jié)

        在本文中我們簡(jiǎn)單介紹了數(shù)據(jù)集成，并結(jié)合具體案例說明了ETL的主要流程，并對(duì)兩種分布式ETL技術(shù)架構(gòu)并進(jìn)行了介紹和比較。在隨后的文章中，我們將基于某省級(jí)運(yùn)營(yíng)商的大數(shù)據(jù)分析需求，提供相應(yīng)的ETL技術(shù)架構(gòu)和實(shí)現(xiàn)方案。