基于MapReduce的檔案數(shù)據(jù)快速查詢設(shè)計與應(yīng)用

陳 斯 潔

(復(fù)旦大學附屬華山醫(yī)院　上海 200040)

0　引　言

隨著計算機應(yīng)用的普及，各行各業(yè)的計算機信息化系統(tǒng)建設(shè)重點已從早期的事務(wù)信息管理逐漸向數(shù)據(jù)應(yīng)用方向轉(zhuǎn)變。傳統(tǒng)的信息管理系統(tǒng)主要為聯(lián)機事務(wù)處理OLTP(On-Line Transaction Processing)，實現(xiàn)數(shù)據(jù)采集與存儲、業(yè)務(wù)流程管理等功能，技術(shù)關(guān)注點在于事務(wù)、流程與數(shù)據(jù)之間的依存與表達。當通常意義的信息管理系統(tǒng)已基本建成后，必定來臨的是信息應(yīng)用即大數(shù)據(jù)時代。計算機信息系統(tǒng)主要完成在線分析處理OLAP(On-Line Analytical Processing)功能，計算機信息系統(tǒng)設(shè)計與開發(fā)的重心更關(guān)注于數(shù)據(jù)的清洗、比對與交換，查詢、統(tǒng)計與分析，注重于系統(tǒng)的性能、效率和擴展性，偏重于海量遠程用戶的高可用訪問性能[1]。

在當前大數(shù)據(jù)時代，信息處理技術(shù)飛速進步，數(shù)據(jù)存儲從典型的集中式Oracle關(guān)系數(shù)據(jù)庫發(fā)展到現(xiàn)今代表性的Hadoop分布式文件系統(tǒng)。然而不論從保護前期投資還是現(xiàn)實可操作性觀點出發(fā)，都不可能一夜之間將目前廣泛使用的關(guān)系型數(shù)據(jù)庫如Oracle、SQL Server等關(guān)系型數(shù)據(jù)庫產(chǎn)品替換成NoSQL數(shù)據(jù)庫，這既無必要也不可行。因此，放在廣大主要從事計算機信息管理與應(yīng)用領(lǐng)域技術(shù)人員面前的是如何快速、有效且低成本解決SQL類關(guān)系數(shù)據(jù)庫從原本的OLTP強項進化到最大程度地滿足與適用于OLAP應(yīng)用的問題。

SQL型關(guān)系數(shù)據(jù)庫產(chǎn)品大多采用的都是行存儲數(shù)據(jù)結(jié)構(gòu)，相應(yīng)的軟件開發(fā)也是通過行搜索的方式進行，即將一個個完整的數(shù)據(jù)行存儲在數(shù)據(jù)頁中，在搜索應(yīng)用時找到相應(yīng)的表，逐行取出符合條件的數(shù)據(jù)以形成數(shù)據(jù)集。在一些OLAP應(yīng)用場景中，特別是在海量數(shù)據(jù)表構(gòu)成的檔案數(shù)據(jù)庫如人口資源庫、信用記錄庫、醫(yī)療過程數(shù)據(jù)庫等應(yīng)用場合中，采用通常多表行搜索的方式就會導(dǎo)致系統(tǒng)不能滿足實際應(yīng)用需求，數(shù)據(jù)庫性能急劇下降甚至癱瘓的事件時有發(fā)生。

為此，本文針對傳統(tǒng)關(guān)系型檔案數(shù)據(jù)庫的多表存儲與搜索問題，提出了一種基于MapReduce思想的構(gòu)建數(shù)據(jù)解析抽取函數(shù)表的搜索方法，以解決OLAP應(yīng)用場景中關(guān)系數(shù)據(jù)的查詢和系統(tǒng)維護問題。

1　傳統(tǒng)檔案數(shù)據(jù)處理方法分析

1.1　傳統(tǒng)數(shù)據(jù)搜索方法簡介

一對多及多對多的數(shù)據(jù)交換和抽取是計算機信息管理系統(tǒng)的基本功能，采用傳統(tǒng)多表存儲的方法是在關(guān)系型數(shù)據(jù)庫中建兩張同構(gòu)數(shù)據(jù)(庫)表。系統(tǒng)按照數(shù)據(jù)來源的數(shù)據(jù)結(jié)構(gòu)進行映射，目標表和原始表一一對應(yīng)，不對表結(jié)構(gòu)進行任何變化，以此完成數(shù)據(jù)的無損抽取與匯集。

這樣的檔案數(shù)據(jù)共享應(yīng)用場景比比皆是，如在智慧醫(yī)療系統(tǒng)中，將各醫(yī)院的每個病人醫(yī)治記錄匯集到大數(shù)據(jù)共享平臺通常都采用此方法。由此大數(shù)據(jù)平臺中存儲的是各醫(yī)院每位病人的醫(yī)療記錄，然而當數(shù)據(jù)共享時，主治醫(yī)生需要的是當前患者曾經(jīng)在各醫(yī)院治療過程的檢測和用藥記錄匯總，以此減少不必要的重復(fù)檢查和提高醫(yī)療質(zhì)量。

針對上述需求，通常的系統(tǒng)搜索匯總工作機制流程是：系統(tǒng)軟件按照需查找信息對象的ID號，在所有相關(guān)數(shù)據(jù)(庫)表掃中描每一張數(shù)據(jù)表，逐個比對這些表中的主鍵與輸入條件匹配的ID數(shù)據(jù)記錄，將其抽取出來，并把這些數(shù)據(jù)記錄關(guān)聯(lián)匯總成數(shù)據(jù)集，推送到系統(tǒng)頁面進行展示。該行搜索方法示意如圖1所示。

圖1　行搜索模式示意圖

在這種傳統(tǒng)行搜索的場景下，軟件系統(tǒng)需要掃描多張表，若系統(tǒng)龐大到有上萬張表時，按此方法，系統(tǒng)性能和效率將是無法承受的。且一旦有新的資源目錄事項加入時，需要不斷地在數(shù)據(jù)庫中新建表。為此相應(yīng)的底層適配讀寫的查找軟件功能代碼都需要重新開發(fā)，由此造成數(shù)據(jù)管理和開發(fā)成本高居高不下，軟件代碼的可擴展性和兼容性不能滿足實時應(yīng)用的需求。因此，該方法在小容量檔案數(shù)據(jù)庫中可使用，對于海量數(shù)據(jù)平臺是無法應(yīng)用的。

1.2　檔案數(shù)據(jù)特征分析

為了解決絕大多數(shù)目前活躍使用的檔案數(shù)據(jù)庫的快速信息查找與抽取問題，需要對此類數(shù)據(jù)庫進行分析，以便從中發(fā)現(xiàn)解決問題的方法。經(jīng)對常見的關(guān)系型檔案數(shù)據(jù)庫表結(jié)構(gòu)解析，社會公共信息檔案數(shù)據(jù)具有如下主要特征：

(1) 主鍵編碼穩(wěn)定且唯一根據(jù)國家有關(guān)法律法規(guī)，法人和自然人均使用全國統(tǒng)一賦碼的18位代碼作為身份識別的編碼，一個主體只能擁有一個統(tǒng)一代碼，一個統(tǒng)一代碼只能賦予一個主體。并且，統(tǒng)一代碼一經(jīng)賦予，在其主體存續(xù)期間，主體信息即使發(fā)生任何變化，統(tǒng)一代碼均保持不變[1]。

(2) 以結(jié)構(gòu)化數(shù)據(jù)信息為主社會公共信息檔案數(shù)據(jù)源于各個主管部門已有的信息管理系統(tǒng)，如工商部門的企業(yè)注冊登記信息、公安部門的行駛證登記信息以及醫(yī)療單位的治療記錄信息等。這些數(shù)據(jù)均是關(guān)系型數(shù)據(jù)庫的產(chǎn)品，通常情況下都是結(jié)構(gòu)化的數(shù)據(jù)信息。

(3) 數(shù)據(jù)來源繁多類別與結(jié)構(gòu)復(fù)雜檔案數(shù)據(jù)歸屬于多頭采集且部門繁多，各領(lǐng)域、各系統(tǒng)都具有不同的業(yè)務(wù)規(guī)范和數(shù)據(jù)標準，導(dǎo)致檔案數(shù)據(jù)資源目錄的元數(shù)據(jù)名稱、格式、標準、長度、類型千差萬別，本質(zhì)上具有分布式數(shù)據(jù)庫的主要特征。

以上海市某資源目錄為例，資源目錄共有5 198個事項，字段最多的資源目錄事項有34個字段，最少的有8個字段。另外，除國家制定的少量特殊數(shù)據(jù)之外，沒有一個資源目錄事項的字段是一致的。

2　數(shù)據(jù)映射歸約函數(shù)表的構(gòu)建方法

針對前節(jié)結(jié)構(gòu)化數(shù)據(jù)中數(shù)據(jù)標準不一致的問題，本文采用構(gòu)建數(shù)據(jù)映射歸約(MapReduce)函數(shù)表方式予以解決，其中map和reduce提供的是所需對象數(shù)據(jù)抽取的計算框架?？梢园袽apReduce過程簡單理解為把一堆互不關(guān)聯(lián)的數(shù)據(jù)(表)按照某種特征歸納起來，然后處理并得到最終需要的結(jié)果。本質(zhì)上是一種用函數(shù)程序語言來實現(xiàn)泛數(shù)據(jù)歸集[2]。

采用MapReduce函數(shù)表方式后，在檔案數(shù)據(jù)查詢抽取程序設(shè)計中就較為簡單了，只要構(gòu)建兩張函數(shù)表，一張為map表，另一張為reduce表。Map函數(shù)表實現(xiàn)將源數(shù)據(jù)表中的數(shù)據(jù)名稱、類型、長度以及該數(shù)據(jù)字段在目標顯示系統(tǒng)的展示順序、寬度和名稱等數(shù)據(jù)結(jié)構(gòu)(屬性)信息列入表中。而Reduce函數(shù)表的作用是將數(shù)據(jù)(屬性)結(jié)構(gòu)中對應(yīng)的各數(shù)據(jù)內(nèi)容提供一個存儲空間。用計算機編程語言來講，Map表中記錄的key，Reduce表中存儲的是value。

為了便于理解MapReduce函數(shù)程序語言編程方法，本文提供了Map表T_HEADER(表1)與Reduce表T_DATA(表2)的示意結(jié)構(gòu)。所有檔案的元數(shù)據(jù)統(tǒng)一在“數(shù)據(jù)名稱表T_HEADER”中存儲，所有數(shù)據(jù)記錄在“數(shù)據(jù)內(nèi)容表T_DATA”中存儲。

表1　數(shù)據(jù)名稱表T_HEADER表結(jié)構(gòu)

表2　數(shù)據(jù)內(nèi)容表T_DATA表結(jié)構(gòu)

數(shù)據(jù)內(nèi)容表T_DATA統(tǒng)一管理所有的數(shù)據(jù)記錄，這些數(shù)據(jù)記錄是嚴格按照T_HEADER的元數(shù)據(jù)標準進行存儲的，分別用A1至A50存放每個元數(shù)據(jù)字段所對應(yīng)的具體數(shù)據(jù)。法人統(tǒng)一代碼和單位名稱、自然人的身份證號碼和姓名單獨用兩個字段“CREDITCODE”和“NAME”單獨存放。其與各原始表的映射關(guān)系如圖2所示。

圖2　列搜索表結(jié)構(gòu)與原始表結(jié)構(gòu)映射關(guān)系圖

從圖2中可以看到，任意多張源數(shù)據(jù)表的數(shù)據(jù)(屬性)結(jié)構(gòu)映射到Map表中，而任意多張源數(shù)據(jù)表的數(shù)據(jù)內(nèi)容歸集到Reduce表中。MapReduce表中的A1、A2、…即為函數(shù)代碼，具體含義由系統(tǒng)實際需求確定。

檔案數(shù)據(jù)的映射歸集如圖2示意，在實際應(yīng)用中，最終需要的是相關(guān)數(shù)據(jù)的展現(xiàn)，其工作機制流程示意如圖3所示。

圖3　列搜索模式示意圖

圖3的工作流程為，以查找對象的統(tǒng)一代碼為主鍵，軟件系統(tǒng)首先在數(shù)據(jù)內(nèi)容表T_DATA中進行匹配，將CREDITCODE字段中所有符合條件的數(shù)據(jù)記錄全部找到，以ZYMLID為外鍵，在數(shù)據(jù)名稱表T_HEADER中找到這些數(shù)據(jù)記錄對應(yīng)的表頭名稱信息、類型信息、長度信息、信用檔案中展示的先后順序、展示的寬度、展示的別名等。然后將這些數(shù)據(jù)記錄關(guān)聯(lián)起來進行展示。

通過舉例說明，可以清楚地認識到，Map實現(xiàn)的是對數(shù)據(jù)表中每個結(jié)構(gòu)元素Key獨立處理，且這些數(shù)據(jù)表中可以是互補關(guān)聯(lián)的。而Reduce實現(xiàn)的數(shù)據(jù)key后面所屬的若干內(nèi)容(value) 歸集，這些value是有相關(guān)性的，至少它們都在一個key下面。這是典型的函數(shù)式語言Map和Reduce基本思想方法：Map表示對一個列表(List)中的每個元素Key做計算，Reduce表示對一個列表中的每個元素Value做迭代計算。它們具體的計算是通過傳入的函數(shù)來實現(xiàn)的[3]。

3　應(yīng)用實踐與分析

通過對資源數(shù)據(jù)的MapReduce整合，可以實現(xiàn)應(yīng)用系統(tǒng)數(shù)據(jù)ETL成本大幅降低，因為采用該方法，數(shù)據(jù)整合應(yīng)用系統(tǒng)只需針對兩張表進行開發(fā)。不需要在關(guān)系數(shù)據(jù)庫中對各張數(shù)據(jù)表進行關(guān)注，不需要為每張表單獨建立實體類進行讀寫維護的開發(fā)，簡化了數(shù)據(jù)整合軟件開發(fā)，降低了應(yīng)用系統(tǒng)軟件的開發(fā)時間和維護成本。

其次，數(shù)據(jù)易于維護與擴展。隨著未來新的部門不斷接入，新的信用信息資源目錄事項不斷增加，在基于MapReduce的數(shù)據(jù)管理模式下，只需要在數(shù)據(jù)內(nèi)容標T_DATA中新增數(shù)據(jù)記錄，并把對應(yīng)數(shù)據(jù)記錄的元數(shù)據(jù)信息插入數(shù)據(jù)名稱表T_HEADER中即可。不需要修改軟件程序，也不需要新增表實體或修改表結(jié)構(gòu)就可以完成擴展，并保持來源部門的原始數(shù)據(jù)結(jié)構(gòu)不變。

第三，提高了查詢應(yīng)用的效率。在此模式下，軟件系統(tǒng)不需要掃描幾千張表，只需要對兩張表進行操作即可。大大提高了應(yīng)用系統(tǒng)的查詢效率。

在上海相關(guān)的醫(yī)療信息資源交互平臺項目中進行了試驗與實踐，截止2017年1月，該方法通過整合醫(yī)療系統(tǒng)近20多家機構(gòu)的相關(guān)數(shù)據(jù)，實現(xiàn)了病人相關(guān)治療信息的交互與整合，避免了病人重復(fù)檢查的成本支持，取得了良好的社會效益。

4　數(shù)據(jù)搜索與歸集方法的分析與討論

各類數(shù)據(jù)的搜索、查詢與歸集可以理解為通常意義上的數(shù)據(jù)ETL過程，主要環(huán)節(jié)就是數(shù)據(jù)抽取、數(shù)據(jù)轉(zhuǎn)換和加工、數(shù)據(jù)裝載。在目前的實際應(yīng)用中，從關(guān)系數(shù)據(jù)庫中抽取數(shù)據(jù)一般有以下幾種方式：

1) 全量抽取。全量抽取類似于數(shù)據(jù)遷移或數(shù)據(jù)復(fù)制，它將數(shù)據(jù)源中的表或視圖的數(shù)據(jù)原封不動地從數(shù)據(jù)庫中抽取出來，并轉(zhuǎn)換成自己的ETL工具可以識別的格式并加載到目標數(shù)據(jù)庫。

2) 增量抽取。增量抽取只抽取自上次抽取以來數(shù)據(jù)庫中要抽取的表中新增或修改的數(shù)據(jù)。在ETL 使用過程中，增量抽取較全量抽取應(yīng)用更廣。如何捕獲變化的數(shù)據(jù)是增量抽取的關(guān)鍵。

3) 日志表方式。在業(yè)務(wù)系統(tǒng)中添加系統(tǒng)日志表，當業(yè)務(wù)數(shù)據(jù)發(fā)生變化時，更新維護日志表內(nèi)容，當作ETL 加載時，通過讀日志表數(shù)據(jù)決定加載那些數(shù)據(jù)及如何加載。

優(yōu)點：不需要修改業(yè)務(wù)系統(tǒng)表結(jié)構(gòu)，源數(shù)據(jù)抽取清楚，速度較快?？梢詫崿F(xiàn)數(shù)據(jù)的遞增加載。

缺點：日志表維護需要由業(yè)務(wù)系統(tǒng)完成，需要對業(yè)務(wù)系統(tǒng)業(yè)務(wù)操作程序作修改，記錄日志信息。日志表維護較為麻煩，對原有系統(tǒng)有較大影響。工作量較大，改動較大，有一定風險。

4) 全表比對方式。全表比對的方式是ETL 工具事先為要抽取的表建立一個結(jié)構(gòu)類似的臨時表，該臨時表記錄源表主鍵以及根據(jù)所有字段的數(shù)據(jù)計算出來。每次進行數(shù)據(jù)抽取時，對源表和臨時表進行的比對，如有不同，進行Update 操作，如目標表沒有存在該主鍵值，表示該記錄還沒有，即進行Insert 操作。

優(yōu)點：對已有系統(tǒng)表結(jié)構(gòu)不產(chǎn)生影響，不需要修改業(yè)務(wù)操作程序，所有抽取規(guī)則由ETL完成，管理維護統(tǒng)一，可以實現(xiàn)數(shù)據(jù)的遞增加載，沒有風險。

缺點：ETL 比對較復(fù)雜，設(shè)計較為復(fù)雜，速度較慢。與觸發(fā)器和時間戳方式中的主動通知不同，全表比對方式是被動地進行全表數(shù)據(jù)的比對，性能較差。當表中沒有主鍵或唯一列且含有重復(fù)記錄時，全表比對方式的準確性較差。

本文提出的檔案數(shù)據(jù)快速查詢方法從原理上屬于數(shù)據(jù)轉(zhuǎn)換和加工ETL方法。因為在現(xiàn)實應(yīng)用場景中，數(shù)據(jù)源中抽取的數(shù)據(jù)不一定完全滿足目標庫的數(shù)據(jù)要求，例如數(shù)據(jù)格式的不一致、數(shù)據(jù)輸入錯誤、數(shù)據(jù)不完整等，所以有必要對抽取出的數(shù)據(jù)進行數(shù)據(jù)轉(zhuǎn)換、選取和加工，與前述的覆蓋式數(shù)據(jù)ETL有極大的差別。

數(shù)據(jù)的轉(zhuǎn)換和加工可以在ETL引擎中進行，也可以在數(shù)據(jù)抽取過程中利用關(guān)系數(shù)據(jù)庫的特性同時進行。通過對各種數(shù)據(jù)抽取機制的對比分析發(fā)現(xiàn)，沒有

一種機制具有絕對的優(yōu)勢，不同機制在各種因素下的表現(xiàn)大體上都是相對平衡的。

ETL實施過程中究竟選擇哪種抽取機制，要根據(jù)實際的數(shù)據(jù)源系統(tǒng)環(huán)境進行決策，需要綜合考慮源系統(tǒng)數(shù)據(jù)庫的類型、抽取的數(shù)據(jù)量(決定對性能要求的苛刻程度)、對源業(yè)務(wù)系統(tǒng)和數(shù)據(jù)庫的控制能力以及實現(xiàn)難度等各種因素，甚至結(jié)合各種不同的數(shù)據(jù)類型及不同環(huán)境的數(shù)據(jù)源系統(tǒng)進行ETL實施，合適的才是最好的。本文提出的利用key-value語言函數(shù)抽取及歸集數(shù)據(jù)的方法相比較適合與分布式數(shù)據(jù)源的重點關(guān)注數(shù)據(jù)抽取，也是當前海量數(shù)據(jù)挖掘與應(yīng)用的熱點課題，在此提出以供各位借鑒與參考。

5　結(jié)　語

本文提出的MapReduce實時異構(gòu)數(shù)據(jù)存儲技術(shù)是一項面向?qū)ο蟮姆植际綌?shù)據(jù)庫存儲技術(shù)，具有良好的實時讀寫性能和可擴展性及查詢能力。但該技術(shù)和所有 NoSql 非關(guān)系型數(shù)據(jù)存儲系統(tǒng)一樣， 都面臨著一個共性問題。其存儲與檢索效率受限于各節(jié)點的服務(wù)器磁盤性能影響，如磁盤的尋道時間、盤片轉(zhuǎn)速、碟片密度以及接口速度等都對本技術(shù)的讀寫速率產(chǎn)生一定的影響。上述局限性需要今后不斷的探索與優(yōu)化[4]。

同時在應(yīng)用過程中，發(fā)現(xiàn)MapReduce存儲模式下的一些問題，如統(tǒng)計報表和專題分析等應(yīng)用的開發(fā)相對SQL模式無明顯優(yōu)勢。下一步工作是如何兼容SQL與NoSQL的混合存儲模式，以兼顧分布式大數(shù)據(jù)架構(gòu)下的存儲與分類查詢的系統(tǒng)性能和效率。

[1] 馬建光, 姜巍. 大數(shù)據(jù)的概念、特征及其應(yīng)用[J]. 國防科技, 2013,34(2):10-17.

[2] 周楓. 大數(shù)據(jù)時代檔案館的特征及發(fā)展策略[J]. 檔案與建設(shè), 2013(8):6-9.

[3] 庫俊平. 大數(shù)據(jù)環(huán)境中企業(yè)文書檔案的信息化管理及利用[J]. 創(chuàng)新科技,2013(9):50-51.

[4] 李斌. 大數(shù)據(jù)及其發(fā)展趨勢研究[J]. 廣西教育,2013(35):190-192.

[5] 杜方, 陳躍國, 杜小勇. RDF數(shù)據(jù)查詢處理技術(shù)綜述[J]. 軟件學報, 2013(6):1222-1242.

[6] 冷泳林, 魯富宇. 基于MapReduce的SimRank算法在圖聚類中的應(yīng)用[J]. 電子設(shè)計工程, 2015(6):9-11.

[7] 李彬, 劉莉莉. 基于MapReduce的Web日志挖掘[J]. 計算機工程與應(yīng)用, 2012,48(22):95-98.

[8] 應(yīng)毅, 任凱, 曹陽. 基于改進的MapReduce模型的Web挖掘[J]. 科學技術(shù)與工程, 2013,13(5):1205-1209.