朱平哲
(三門峽職業技術學院 信息傳媒學院,河南 三門峽 472000)
目前,大數據分析技術和網絡技術正在被廣泛地應用于包括醫療領域在內的多個業務領域,該項技術已連續多年被全球研究機構評為當前最重要和最具影響力的技術之一[1-4],并與物聯網技術、人工智能技術一起在高級分析和實時分析等多個領域獲得了長足的發展.由于這些技術均需要借助大量的資源,因此亟需對分布式云特別是混合云技術展開深入的研究,而基于軟件定義架構的分布式云可以提供性能優越的低延遲服務[5].
然而,混合云和醫療環境中存在諸如性能和成本等多方面的限制,因此,難以針對混合云環境的計算性能進行有效精確的預測.因此,有必要研究一種動態的工作流生成和管理方法,以滿足混合云環境下用戶的分析需求[6],而在高級分析和實時分析中,分析質量(Quality of Analysis,QoA)與處理時間(Deadline)之間始終需要進行權衡[7-8].在此背景下,本文對二者之間的關系展開了深入研究,首先假定待分析的數據量與QoA成正比例關系.對于最優的權衡決策,需要在生成工作流時考慮從數據收集到決策制定的全過程.此外,混合云環境的工作流模型需要考慮諸如流、微批量和批處理等各種數據處理方法之間的協作處理.
為了克服現有混合云環境的局限性,提出了一個系統和工作流模型,該系統是采用了工作流模型的“混合大數據處理系統(Big Data Processing System,BDPS)”.針對所提出的BDPS,分析了最佳工作流配置的性能影響因素,不僅如此,還針對評估結果進行了展示以探索可能對系統配置產生的影響.
全文結構如下:作為BDPS模型的基礎,第1節研究了Lambda體系結構和動態工作流;第2節具體介紹了BDPS體系結構和工作流模型;第3節對全文進行了總結.
Lambda體系結構[9]采用批處理和流處理方法對大批量數據加以處理,該體系結構是由批處理層、實時處理層和服務層所構成.其中,批處理層負責處理大型存儲數據集,實時處理層負責及時處理采集到的數據,而服務層通過批處理層和實時處理層提供處理數據的查詢視圖.
為了實時處理數據并向用戶實時提供查詢視圖,文獻[10]采用了Lambda架構成功地對流數據進行了處理.在文獻[10]中構造的系統中,批處理層無限次地針對MapReduce函數進行了重復,其實質為基于storm的實時處理層和基于Hadoop的批處理層間的融合,并使用每一層的完整數據為用戶提供查詢視圖.
目前,針對大數據的研究工作主要集中在自動化以及任務管理上.因此,在醫療大數據處理系統中,亟需一種基于動態工作流生成方法的最優權衡來處理各種分析請求[11].文獻[12]基于OASIS標準之一的云應用拓撲和業務流程規范(Topology and Orchestration Specification for Cloud Applications,TOSCA),提出了云環境下一種自動的工作流生成方法,該方法采用擴展的TOSCA可以很便利地生成自動化工作流.文獻[13]中將工作流從云端下載到本地,構建了Emerald系統以提升整體處理性能.
本文所提出的大數據處理系統(Big Data Processing System,BDPS)可以生成滿足用戶需求的最佳工作流.為了生成盡可能準確的工作流,BDPS在大數據的特性中,確定了對應于價值和速度的QoA和截止期限間的最佳權衡.此外,該系統綜合了多種數據處理方法執行了數據協作處理,并同時考慮了混合云環境中的各種數據處理基礎設施.因此,BDPS的數據處理層由多層所構成,而Lambda體系結構是由批處理層和實時處理層構成.
BDPS是由服務(Service,SV)層、數據流程(Data Orchestration,DO)層和大數據處理(Big data Processing,BP)層所構成,如圖1所示.

圖1 BDPS體系結構
SV層根據用戶的需求分析生成工作流.當BDPS根據規范生成工作流時,它將從DO層收集數據信息,并從BP層中收集工作節點信息,然后根據分析要求確定最優折衷方案.其中,分析要求包括QoA和截止期限.QoA決定一次分析多少行數據,而截止時限則對任務的處理速度提出了要求.為了滿足基于折衷方案的性能要求,可以考慮進行擴展或編程加以配置.
DO層主要負責執行數據同步、數據搜索等數據管理,并通過服務類型和生成的工作流將DO層與關系數據庫、內存數據庫、圖形數據庫等數據存儲相連接.為實現高效的數據管理,DO層使用圖形數據庫創建并對數據本體進行管理.數據本體表示可以由計算機加以處理的表單中數據的關系,且可以對數據同步和搜索進行改進.通過使用數據本體,可以從用戶感興趣的主題中智能地搜索數據.此外,也可以通過關系將分區數據加以同步.
BP層是由流層、微批量層和批處理層所構成,并可以根據工作流和數據處理方法的特點對數據加以處理.例如,BP層可以在流層中對收集到的數據進行預處理.根據分析要求,在微批量層或批量層進行數據處理.BP層通過層間的協同處理提升分析性能,有助于確定最佳的權衡方式.BP層中每一層的描述如下.
(1) 流層負責實時對收集到的流數據執行預處理、本體生成和流分析.通常,在Apache開放源碼項目中擁有諸如Storm和Spark流的項目.
(2) 相比批處理層,微批量層處理的數據量相對較小,它主要負責處理側重于完成期限的高優先級任務.
(3)為了滿足分析要求,批處理層負責處理大量數據或執行數據采樣.如果需要處理質量優先級任務,可以對批處理層中未采樣的原始大數據進行處理以提高分析質量.
當BDPS從用戶處收到醫療大數據處理需求規范時,BDPS將對醫療大數據執行以下處理.
首先,將采集到的數據經過預處理后存儲在DO層和BP層.BDPS將收集到數據的元數據作為基于本體的圖進行管理,以便快速搜索需求規范所需的數據.此時,可以通過服務管理員的數據管理策略定位存儲.為了保障數據安全,存儲前后均需考隱私層面的預處理.
其次,當用戶請求進行醫療大數據處理時,SV層將執行節點擴展,并根據物理機器的分析需求和資源狀態動態生成工作流.為了優化流程,可以重復權衡方案的確定流程,從而生成如圖2所示的工作流.通過使用生成的工作流,DO層通過在本體元數據中基于相關性檢索來準備所需的數據.通過生成的工作流,BP層在各層間執行協同數據處理.根據在SV層確定的權衡方案,在每個相應層中執行數據采樣、數據預處理和數據分析.

圖2 BDPS工作流管理流程圖
其中Ps為用戶滿意度,Tps為用戶滿意度閾值,Po為計算開銷預測,Tpo為計算開銷預測的閾值,Nr為重復次數,Tnc為重復次數的閾值.
為了滿足BDPS中的用戶需求,需要生成一個具有合適有向無環圖(Directed Acyclic Graph,DAG)組合的最佳工作流,并盡可能地降低總延遲.為了生成一個最佳的工作流,需要通過評估批處理方法的性能來分析性能影響因素,該方法以工作流中的總延遲為代價.下節將采用Hadoop進行性能評估來研究批處理的延遲問題.
Hadoop在將數據劃分并存儲在HDFS塊后,針對每個塊執行基于MapReduce的批處理操作.因此,影響批處理配置的性能包括HDFS的塊大小、每個塊的映射器/減法器、每次迭代的數據大小、映射器線程數、數據采樣率等.本文使用數據溢出大小、映射器線程數和根據工作流進行動態配置的數據采樣率執行評估.
為了進行性能評估,5臺同構虛擬機(Virtual Machines,VMs)配備了雙核CPU、4GB RAM和50GB硬盤.有1個主節點/3個從節點用于數據處理,此外還有1個消息傳遞節點.每臺虛擬機均安裝了Ubuntu服務器,ZooKeeper(3.4.9),Hazelcast(3.8),Hadoop(2.7.3),Spark(2.1.0)和MQTT(3.1).采用Hadoop進行批處理、Spark進行流處理和微批量處理、ZooKeeper進行應用協調、Hazelcast用于內存存儲和中間緩沖區,MQTT用于通信.在所有仿真實驗中采用醫療數據集,分別為案例1(14 000行)、案例2(35 000行)和案例3(70 000行).盡管模擬數據集并非大數據,但可以通過動態配置快速地顯示評估結果.仿真的工作負載包括數據加載、預處理和僅由映射器模型進行的分析處理.在工作負載的每一階段,臨時數據均被存儲在內存存儲器中以最小化HDFS的運行開銷.
首先,數據拆分大小表示在映射器線程的每次迭代中要處理的數據集行數,如圖3所示.

圖3 映射器線程迭代中的評估結果
在6個映射器線程中,數據集從6行(每個單線程1行)變化為122 880行(每個單線程20 480行).除了虛擬機使用過程中導致的錯誤以外,三個案例在數據拆分大小達到7 680行以前的處理時間大致相同.當數據拆分大小超過7 680行時,三個案例的處理時間均迅速上升;其次,根據圖3的性能評估結果,所有數據處理方法的仿真結果如圖4所示,其中包括流處理、微批量處理和批處理.本文基于BDPS針對患者的血液測試數據建立了一個醫療數據分析方案.分析方案包括數據加載、預處理和分析,這些分析通過微批量處理進行了簡單的統計分析.在整個過程中,批處理任務由于可以包含個人信息,因而是在混合云環境的私有云中加以執行的,而流處理和微批量處理則是在公共云中以高性能加以執行.

圖4 批處理、流處理、微批量處理的評估結果
圖4中數據處理的延遲時間是指當前任務完成后,直到下一個任務完成的時間.此時,下一任務并不等待當前任務的完成,即在當前任務中處理流或微批處理的數據時,就會啟動下一個任務.例如,分別有批處理時間、流處理時間和微批量處理時間.批處理時間是指批處理任務完成之前的時間;流處理時間是批處理任務完成后,直到流處理任務完成的時間;微批量處理時間是流處理任務完成后,微批處理任務完成的時間.
在仿真實驗結果中,除單個映射器線程外,所有案例下的總處理時間均基本一致,且批處理程序的延遲時間模式與圖3的實驗結果較為相似.隨著批處理程序延遲時間的減少,可以發現流處理程序的延遲時間逐漸增加.當映射器線程數為1時,流處理和批處理任務的完成時間相同,且二者之間沒有延遲.由于內存存儲I/O中的存儲鎖和瓶頸的存在,相對較小的數據拆分而言,較大數據拆分(1920行)的流處理任務往往需要更長的延遲時間.
為了進一步驗證本文提出的工作流模型的有效性,本節還選取了一種基于網絡流的工作流模型(Netflow-Based Assignment Judgment,NBAJ)[14]進行比較.NBAJ將資源分配問題中涉及的資源、資源類型以及活動節點等三類元素映射到一個網絡流模型上;而BDPS系統僅考慮兩個因素,即對應于價值和速度的QoA和截止期限間的最佳權衡,因此涉及到的因素更為集中,實現起來也更為直觀便捷.
為了滿足用戶的分析需求,提出了一種面向用戶的BDPS系統和工作流模型.BDPS分析了性能影響因素,并對不同配置設置下的批處理性能進行了評估,從而確定權衡方案并動態地生成工作流.仿真實驗表明本文提出的BDPS系統可以為混合云中的醫療大數據分析提供一種有效的數據處理方法.如何將BDPS進一步應用于多種不同用例中將是下一步工作的重點.