基于混合架構的國產化大數據平臺研究與應用

王新東 王一大 李昌盛 張亞威 郭 煒

中國聯合網絡通信有限公司濟南軟件研究院 濟南 250100

引言

開源Hadoop平臺在國內各領域應用廣泛，但隨著國產化芯片、操作系統、數據庫等應用普及，Hadoop已無法完全適配國產化芯片和操作系統?，F有大數據組件不能兼容傳統X86主機和ARM主機，在麒麟操作系統中運行不穩定，且部分功能在麒麟操作系統中不適配，嚴重阻礙了國內大數據行業的發展?；谝陨媳尘?，本文研究了一種基于混合架構的國產化大數據平臺，能夠較好適配國產化芯片、操作系統等國產化組件。目前開源Hadoop平臺仍存在以下幾個問題。

1)分布式調度系統YARN調度功能不完善，資源無法復用。YARN的ResourceManager雖然支持Memory和CPU調度，但CPU資源調度功能不完善，且AppMaster無法復用資源，交互效率低[1]。

2)分布式存儲系統HDFS存在單點故障問題。HDFS中所有Metadata操作均需要通過Namenode，數據量訪問過大時，這種設計會成為系統中明顯的單點故障源，影響Hadoop性能發揮，雖然引入Federation機制，使用多個獨立NameSpace滿足HDFS命名空間的水平擴展，但并未完全解決單點故障問題，在很大程度上制約了整個集群的擴展性和可靠性[2]。

3)海量數據處理場景受限，元數據不統一，缺少權限安全管理。應用開源Hadoop體系使我們從底層架構受制于人，無法滿足海量數據處理場景，元數據不統一，無法進行全局的數據倉庫規劃，數據安全各自為戰，缺乏權限安全管控[3]。

4)開源Hadoop平臺無法實現高效存儲、處理大量小文件[4]。小數據處理過程中，會出現配置任務時間超出運行計算時間的情況，且在HDFS中，每個文件對應一個數據塊，若存儲大量小文件，系統會消耗Namenode大量內存來保護這些數據塊信息[5]。

針對上述問題并借鑒國內外相關文獻，本文提出一種基于混合架構的國產化大數據平臺。一方面擺脫了底層架構受限問題，可以很好地適配國產化ARM主機和傳統X86主機，且全部功能均適配國產化麒麟操作系統，性能穩定可靠；另一方面解決開源Hadoop平臺調度系統不完善、交互效率低和單點故障問題。

1 基于混合架構的國產化大數據平臺架構

本文主要研究了適配國產化ARM主機和麒麟操作系統的大數據平臺架構，下面分別從分布式調度系統、分布式存儲系統、統一元數據及安全體系、運維監控告警平臺、一站式數據智能研發與綜合治理服務、適配X86與ARM主機、適配Centos與麒麟操作系統、部署架構八大方面詳細闡述基于混合架構的國產化大數據平臺。其中基于混合架構的國產化大數據平臺整體架構如圖1所示。

圖1 基于混合架構的國產化大數據平臺整體架構圖

基于混合架構的國產化大數據平臺架構由7層組成，包括主機資源層、操作系統層、分布式調度與存儲層、大數據組件層、計算引擎層、接口層、應用層。如圖1所示，其底座是由X86主機或ARM主機的主機資源層組成，基于混合架構的國產化大數據平臺既支持單獨部署在X86集群上，也支持單獨部署在ARM集群上，還支持在ARM集群跟X86集群進行混合部署，實現了資源重復利用，部署更加靈活；上一層是操作系統層，包括Centos操作系統與麒麟操作系統，基于混合架構的國產化大數據平臺既支持單獨部署在Centos操作系統上，也支持單獨部署在麒麟操作系統上，還支持混合部署，實現了平臺的可移植性；在操作系統層之上為分布式調度與存儲層，包括分布式調度系統及分布式存儲系統，用于存儲底層數據、調度任務作業等；分布式調度與存儲層之上為大數據組件層，能夠支撐多種大數據組件，包括HDFS、YARN、HIVE、HBASE、HUDI、FLINK等；大數據組件層之上為計算引擎層，基于混合架構的國產化大數據平臺支持多種計算引擎，包括SQL、MapReduce、機器學習等；計算引擎層之上為接口層，基于混合架構的國產化大數據平臺不僅支持RESTful API接口接入，也支持RPC API接口接入，同時兼容Java SDK、Python SDK、JDBC、Console等工具供開發者使用；接口層之上為應用層，目前已開發的應用有一站式數據智能研發平臺、統一元數據及安全系統、運維監控告警平臺。

應用層中研發了一站式數據智能研發平臺，封裝了一系列操作，提供了統一的數據建模、數據采集、數據加工、調度等一系列能力。通過研發統一元數據及安全系統，基于混合架構的國產化大數據平臺將所有元數據統一管理，有助于進行全局數據倉庫規劃；基于混合架構的國產化大數據平臺將具備完善的安全體系，Capability機制、沙箱、IP白名單、多租戶管理、數據分級打標、項目保護模式等可獨立做數據權限管理。研發運維監控告警平臺，實現了對基于混合架構的國產化大數據平臺中集群、主機、項目、服務的全方位管控。

1.1 分布式調度系統

分布式調度系統主要負責任務調度與資源管理，目前常見的三種分布式調度系統主要有Hadoop MR、YARN、Mesos，它們均存在較多問題，Hadoop MR規模擴展存在瓶頸，容錯性差，不利于功能擴展，可靠性差，資源利用率低；YARN的ResourceManager雖然支持內存和CPU調度，但CPU資源調度仍需完善，且AppMaster無法復用資源，交互效率低；Mesos計算框架只能被動接受Resource Offer，不能精確描述資源需求，且一次資源分配需要兩次通信交互，調度效率低，不支持資源搶占等問題[6]。

在此基礎上，研發了一種分布式調度系統，由資源調度和任務調度分離兩層架構組成。本文提出通過資源調度器和agsou結構解決分布式調度中資源調度問題，將每個計算任務的APP Master及一組APP Worker組合起來解決分布式調度中的任務調度問題，其架構如圖2所示。

圖2 分布式調度系統架構圖

Client負責接受用戶請求；APP Master負責向資源調度器申請/釋放資源，調度APP Worker到集群節點，分配Instance、APP Worker數據傳輸，管理APP Worker生命周期，故障重啟等；APP Worker負責接收Instance，執行用戶計算邏輯；agsou負責收集每個機器的硬件資源(CPU、Memory、Disk等)，發送給資源調度器；資源調度器作為中控節點，負責整個集群的調度。

集群部署完畢，分布式調度系統操作步驟如下：

1)用戶通過Client向資源調度器提交計算任務；

2)資源調度器選擇一臺agsou啟動計算任務對應的APP Master；

3)APP Master向資源調度器提交資源申請，資源調度器經過資源調度，將結果返回給APP Master；

4)APP Master進行任務調度，決定計算任務適配的機器，并將計算任務發送給對應機器上的agsou進程；

5)agsou接受命令，從程序包管理器中下載對應程序并解壓，啟動用戶APP Worker；

6)APP Worker根據配置信息讀取文件存儲系統中的數據進行計算，并將計算結果發往下一個APP Worker。

本文提出的分布式調度系統相比現有的分布式調度系統有明顯優勢，包括：資源調度器擴展性強，針對不同任務在APP Master中可通過心跳監控選擇不同調度策略，實現了負載均衡；通過對開源組件Ambari進行優化，實現了YARN、Zookeeper的復用，以支撐多種計算框架，達到資源復用的效果，提高了資源交互效率；分布式調度系統支持集群節點超大規模，水平擴展，能夠支撐2000臺大數據節點規模，另外支撐集群節點擴縮容；通過借鑒HDFS HA思想，對每個角色都部署多個節點，同時主節點與備節點保持心跳通信，以達到主節點發生故障可隨時切換備節點，同時數據不丟失，實現了分布式調度系統的高容錯性，任何角色故障不影響任務執行。

1.2 分布式存儲系統

在超大規模分布式集群中，小概率故障成為常態，可能帶來“雪崩效應”[6]。本文提出了一個穩定可靠的分布式存儲系統，設置3個不同角色負責管理不同事務：元數據服務器(Master)、數據存儲服務器(ChunkServer)、客戶端(Client)，解決了集群小概率故障問題，同時確保數據具有強一致性、安全性、可靠性、可用性。分布式存儲系統架構如圖3所示。

圖3 分布式存儲系統架構圖

Client負責接受用戶請求，部分用戶偏向高性能，部分用戶偏向大存儲，針對用戶不同需求，系統采用多線程同步，同時支撐不同用戶。Master負責管理整個存儲集群的元數據，采用Paxos選主，而非Zookeeper的外部服務，支撐海量存儲穩定運行。ChunkServer負責磁盤管理，將閃存和機械硬盤相結合，數據前臺先寫入閃存，后臺轉儲到機械硬盤上，實現了在關鍵節點使用閃存以代替全部使用閃存的方式，解決了存儲皆使用閃存導致存儲成本高的問題。

數據高可用：由于對外服務器數量固定，單純增加服務器數量無法實現數據的高可用，將目錄樹分割成volume，通過不同volume實現Master水平擴展，保證了數據高可用。

數據高可靠：分布式存儲系統中，采用多副本機制，設置多副本位于不同故障域，當有數據節點故障時，Master就會發起復制機制，在ChunkServer間復制數據，保證了數據高可靠。

數據完整性：在小概率事件下，內存或磁盤存儲的數據可能會發生改變。每段數據后面設置循環冗余校驗(CRC)，進行數據周期性掃描，若發現數據與CRC無法匹配，則認為此段數據發生了位反轉，此時采用完整副本覆蓋發生位反轉副本，保證了數據完整性。

1.3 統一元數據及安全體系

基于混合架構的國產化大數據平臺將元數據統一管理，提供了項目元數據視圖和作業歷史視圖，可查看元數據，使用歷史數據、項目內的作業歷史等信息。為管控元數據安全查看，設置用戶訪問權限，若項目內其他用戶或角色需要查看時，需申請授權。

基于混合架構的國產化大數據平臺提供完善的安全管理體系，主要包含用戶及授權管理(負責用戶認證、用戶管理、授權、角色管理及權限查看)、列級別訪問控制(設置安全策略，對敏感數據劃分等級，實現用戶對列級敏感數據訪問)、數據下載權限管控、項目空間安全配置(支持多種正交授權機制，定制鑒權模型)、項目空間數據保護(自行設置數據保護機制，防止敏感數流出)、IP白名單(限制白名單以外設備訪問項目空間)等。

1.4 運維監控告警平臺

運維監控告警平臺是為基于混合架構的國產化大數據平臺研發的運維管控平臺，支持從業務、集群、服務和主機維度對大數據組件進行運維管理。

1)業務運維

業務運維功能包括項目管理(負責展示項目列表及項目詳情、元倉資源授權、數據存儲加密、容災查看及切換、項目遷移)，隊列管理(負責展示、新增及修改項目隊列、查看詳情)，作業管理(展示集群所有作業、查看運行日志、終止作業)。

2)集群運維

集群運維功能包括集群概況(CPU、磁盤、內存、服務狀態、LOAD、PACKAGE等運行信息)、集群健康管理(查看集群檢查項)、機器列表(展示集群主機信息)。

3)服務運維

服務運維包括控制服務運維、分布式調度系統運維、分布式存儲系統運維和數據通道運維?？刂品者\維主要負責查看服務總體運行狀態，查看服務檢查項及詳情，查看服務元倉狀況，啟停服務，采集服務日志。分布式調度系統運維主要監控分布式調度系統的關鍵運行指標(服務狀態、CPU和內存使用情況、計算節點使用情況等)、分布式調度系統健康狀況管理(檢查項、檢查狀態等)、分布式調度系統隊列管理。分布式存儲系統運維主要管理關鍵運行指標、健康狀況、存儲節點和服務實例(展示分布式存儲系統的Master主機和服務角色信息)。數據通道管理數據流量分析。

4)主機運維

主機運維功能包括主機概況(展示集群中主機信息、運行健康、以及機器CPU、內存、存儲、負載等信息)，主機健康管理(查看主機檢查項及詳情)，主機服務(查看主機所屬集群、主機運行服務實例等)。

除此之外，運維監控告警平臺還支持對大數據組件自定義監控告警，當指標超出設定閾值，監控系統會通過短信、釘釘、電話等多種形式自動向運維人員發送報警信息，通過監控大盤界面也可實時觀察監控指標變化。

1.5 一站式數據智能研發與綜合治理服務

一站式數據智能研發與綜合治理服務是集ETL、數據質量檢測、智能調度和數據血緣管理于一體的全方位多功能平臺，與基于混合架構的國產化大數據平臺深度集成，支持多種計算和存儲引擎服務。

1)數據集成

在復雜網絡環境下，異構數據源之間數據傳輸與同步困難，數據集成模塊是一個可跨異構數據進行數據傳輸的穩定、安全可靠的數據同步平臺。數據集成模塊包括離線和實時數據同步兩種方式，不僅提供不同網絡環境下全量或增量數據同步，而且提供批量創建同步任務，實現數據庫內所有表批量上傳到基于混合架構的國產化大數據平臺中，提高了工作效率。

2)數據開發

數據開發模塊支持開發、生產相隔離，提供了更穩定、更可靠的生產環境。數據開發模塊還支持開發者自主組合SQL、MapReduce、Flink和機器學習等各項任務的混編工作流，實現分鐘級調度、邏輯控制等。除此以外，開發者可以從業務角度管控工作流，將同類型業務組織為解決方案，實現沉浸式開發。

3)數據質量檢測

數據質量檢測支持多種異構數據源的質量校驗、通知及管理，支持基于混合架構的國產化大數據平臺數據表和實時數據流。

4)智能調度

智能調度模塊通過設置調度參數、時間屬性、資源屬性、調度依賴等不同調度配置實現強大的調度功能，支持通過時間屬性和調度依賴配置進行任務觸發，時間屬性包含實例生成方式、調度類型、重跑屬性及調度周期等配置。調度依賴即上游節點輸出作為下游節點輸入，形成依賴關系，防止下游節點調用上游數據時，上游數據未正常產出而影響下游節點運行。同時，智能調度模塊支持按月、周、小時和分鐘等多種調度周期配置，支持每日千萬級別任務調度，可通過DAG圖準確、準時地運行。

5)數據血緣管理

數據血緣管理是在元數據基礎上提供數據目錄管理模塊，支持全局數據檢索、查看元數據詳情、血緣管理等功能，讓數據資產盡可能在組織內被更好地共享、發現，從而提升數據使用率、降低數據重復率。元數據接入時，可通過數據血緣管理服務對基于混合架構的國產化大數據平臺引擎直接進行表元數據管理操作，也可以對不同數據源的元數據導入數據血緣管理服務中統一管理。通過血緣管理可視化節點的依賴關系圖和內部血緣圖，方便研發人員快速清晰地理解數據生成路徑。

1.6 適配X86與ARM主機

開源大數據平臺為原生HDP大數據平臺，主要包括Ambari管理平臺以及各大數據服務組件(HDFS、YARN、HIVE等)。而國產化平臺采購的主機主要包括X86架構主機和ARM架構主機。我們需要解決HDP大數據平臺在這兩種機型的安裝，以便實現兩種機型的混合部署，從而規避產業鏈中潛在的卡脖子風險。

適配主機的本質，就是將HDP大數據平臺的rpm安裝包中的各類文件，如jar包文件、靜態鏈接庫文件(.a)、動態鏈接庫文件(.so)、二進制執行文件、配置文本文件等，以及這些文件的目錄層級關系安裝到所適配架構的主機上。

1.6.1 X86主機適配

由于HDP大數據平臺官網提供針對X86芯片的安裝包，因此針對X86芯片主機并不需要做單獨適配工作，經測試可以直接使用官方提供的X86安裝包在X86主機上進行安裝使用，性能與Intel X86并無明顯差異。

1.6.2 ARM主機適配

針對ARM芯片，由于其芯片架構與X86有較大差異，因此在該芯片架構上安裝HDP大數據平臺，需要專門適配，基于混合架構的國產化大數據平臺基于原生HDP大數據集群，包括Ambari管理平臺以及各大數據服務組件(HDFS、Yarn、Hive、HBase等)。

本次rpm包的架構適配實際上是rpm安裝包中靜態、動態鏈接庫和二進制執行文件的適配，即通過將同版本源碼在需要適配的架構上(本次適配的是采用arm v8的linux aarch64架構)進行編譯，得到的編譯產物就是對應架構的安裝包。

本次編譯過程總體分為三大步，具體如下。

1)安裝編譯前置依賴，如rpm-build、gcc-c++、python-devel、gulp、git等。

2)安裝編譯工具，如phantomjs、frontend-mavenplugin、leveldb/jni等。

3)Ambari源碼編譯。從官方下載源碼后需要將部分pom文件中的X86和amd64修改為arm和aarch64，以適配ARM芯片架構，涉及的文件列表如下：

#將noarch改為aarch64

ambari-logsearch/pom.xml

ambari-funtest/pom.xml

ambari-metrics/ambari-metrics-grafana/pom.xml

#將amd64或i386 amd64改為arm64

ambari-agent/pom.xml

ambari-logsearch/pom.xml

ambari-server/pom.xml

contrib/views/ambari-views-package/pom.xml

ambari-client/python-client/pom.xml

ambari-shell/ambari-python-shell/pom.xml

#將X86改為aarch64

ambari-agent/pom.xml

ambari-metrics/ambari-metircs-assembly/pom.xml

ambari-server/pom.xml

修改芯片架構參數后仍需要按照上述2步安裝的依賴與編譯工具版本修改對應pom文件中的版本號，涉及的文件列表如下：

ambari-logsearch/pom.xml

ambari-funtest/pom.xml

ambari-metrics/ambari-metrics-grafana/pom.xml

ambari-metrics/pom.xml

ambari-admin/pom.xml

最后需要將ambari-web/package.json中的emberhandlerbars-brunch修改為github，鏈接如下：

“ember-handlerbars-brunch”:“git://github.com/ember-handlerbars-brunch.git#540127137296a 09601cbd215dcf4da4d27bcfb9e”

以上配置修改完后即可完成編譯，rpm包將會存儲在對應target路徑下。

1.7 適配Centos與麒麟操作系統

在操作系統層面主要使用了Centos操作系統與麒麟操作系統。我們的目標是不僅實現大數據平臺在這些操作系統上安裝，還要實現混合部署，以具備可移植性和靈活性。

針對Centos：開源HDP均在Centos主機上安裝且十分成熟，因此大數據平臺安裝包無需更改即可平滑安裝于Centos主機。

針對麒麟操作系統：由于開源HDP并未對麒麟操作系統進行兼容適配，需對ambari-agent下的相關腳本和配置進行修改，以完成對麒麟操作系統的適配，修改內容涉及以下幾個方面。

1)配置操作系統校驗，將Ambari agent校驗中添加麒麟操作系統，需要修改操作系統校驗相關腳本，路徑為：/usr/lib/ambariagent/lib/ambari_commons/os_check.py。在207行添加：

elif _is_kylin_linux():

distribution = (“Centos”,“7.6.1810”,“LTS”)

意思為若操作系統判斷為麒麟操作系統，則返回麒麟操作系統的版本。

2)按照適配的HDP版本號，固定安裝腳本中的版本號信息。需要修改的腳本路徑為：/usr/lib/ambari-agent/lib/resource_management/libraries/script/script.py和/usr/lib/ambari-agent/lib/ambari_commons/repo_manager/yum_manager.py。由于自行適配的版本針對3.1.0進行，因此將所有腳本中的版本號固定為3.1.0，防止出現yum自動安裝時版本不一致的問題，其中script.py需要修改89行如下：

STACK_VERSION_PLACEHOLDER=“3_1_0_0_78”

yum_mamager.py需要修改yum_check_package_available函數，該函數的作用為在yum安裝之前校驗安裝包是否存在，將版本校驗部分邏輯修改為只校驗3.1.0版本安裝包，強行使安裝包校驗這一步通過，修改如下：

if name.find(“stack_version”) != -1:

name=name.replace(“${stack_version}”，“3_1_0_0_78”)

3)固定yum源地址。由于Centos和麒麟混部需求，因此自動化安裝需要配置兩套yum源，其中一套yum源為Centos版本，另外一套為麒麟版本，其中在麒麟版本安裝時，將yum源校驗這部分腳本代碼修改為固定地址，即強行使麒麟主機安裝各組件的過程通過設置單一yum源下載安裝包，以解決麒麟版本對Centos版本yum源誤掃描的問題，需要修改的腳本路徑為：/usr/lib/ambari-agent/lib/resource_management/libraries/functions/repository_util.py。修改內容如下：

base_url=“http://{kylin-yumip:port}/HDP/Centos7/3.1.0.0-78”

1.8 基于混合架構的國產化大數據平臺部署架構

1)基于混合架構的國產化大數據平臺支持X86主機與ARM主機混合部署，其架構如圖4所示。

圖4 基于混合架構的國產化大數據平臺X86與ARM混部架構圖

本文提出的基于混合架構的國產化大數據平臺既支持單獨部署在X86集群上，也支持單獨部署在ARM集群上，還支持在ARM集群跟X86集群進行混合部署，實現了資源重復利用，部署更加靈活。

2)基于混合架構的國產化大數據平臺支持Centos操作系統與麒麟操作系統混合部署，其架構如圖5所示。

圖5 基于混合架構的國產化大數據平臺Centos與麒麟混部架構圖

本文提出的基于混合架構的國產化大數據平臺既支持單獨部署在Centos操作系統上，也支持單獨部署在麒麟操作系統上，還支持Centos操作系統與麒麟操作系統混合部署，實現了平臺的可移植性。

3)基于混合架構的國產化大數據平臺支持跨機房部署，其架構如圖6所示。

圖6 基于混合架構的國產化大數據平臺跨機房部署架構圖

相比于開源Hadoop平臺，本文提出的基于混合架構的國產化大數據平臺支持跨機房部署，如圖6所示，控制集群和計算集群均可以部署在不同機房，保證了集群的高可用。

2 基于混合架構的國產化大數據平臺應用

為進一步分析基于混合架構的國產化大數據平臺應用，本文通過TPCDS SQL性能實驗、批量數據加工實驗進行兩組對比實驗，分析開源Hadoop平臺與本文提出的基于混合架構的國產化大數據平臺的性能對比。

2.1 TPCDS SQL性能實驗

對100臺物理機資源部署集群平臺，分別選50臺機器部署開源Hadoop平臺，50臺機器部署基于混合架構的國產化大數據平臺。集群部署正常且運行正常情況下，通過TPC-DS工具在集群上構建實驗數據，規模為100TB TPC-DS實驗數據。通過TPC-DS工具依次運行99條標準SQL，記錄每條SQL執行時間，分別得到開源Hadoop平臺和基于混合架構的國產化大數據平臺運行99條標準SQL的整體耗時對比結果，如圖7所示。

圖7 TPCDS 99條SQL運行結果對比圖

由圖7可知，對2個平臺分別運行了兩次99條TPCDS SQL，整體耗時方面，基于混合架構的國產化大數據平臺比開源Hadoop平臺耗時縮短一倍，運行速度得到較大提升，說明本文提出的基于混合架構的國產化大數據平臺優于開源Hadoop平臺。

2.2 批量數據加工實驗

分別針對基于混合架構的國產化大數據平臺與開源Hadoop平臺創建離線加工租戶，均分配2560Hz的CPU資源、10T內存，建表并導入數據，其中包含6個數據庫，涉及32張表，共計2.4T數據量，進行一系列數據加工流程：依次執行SRC→ODS加工流程，ODS→DWD加工流程，DWD→DWA加工流程，DWA→DM加工流程，并記錄每個加工流程的耗時，分別得到基于混合架構的大數據平臺和開源Hadoop平臺對批量數據加工實驗的整體耗時對比結果，如圖8所示。

圖8 批量加工流程整體耗時對比圖

由圖8可知，批量數據加工過程中，開源Hadoop平臺整體耗時0.927小時，基于混合架構的國產化大數據平臺整體耗時0.256小時，數據表明，本文提出的基于混合架構的國產化大數據平臺運行效率更優。

3 結論

基于混合架構的國產化大數據平臺通過對開源Hadoop平臺進行改進，通過研發了一套分布式調度系統和分布式存儲系統，一方面擺脫了底層架構受限問題，可以很好地適配ARM主機和傳統X86主機，且全部功能均適配麒麟操作系統，性能穩定可靠；另一方面解決開源Hadoop平臺調度系統不完善、交互效率低和單點故障問題。通過統一元數據及安全管理體系，將元數據統一規劃，節省存儲費用，提高安全管控能力。并通過業界通用的TPCDS SQL實驗及批量數據加工實驗，證明了基于混合架構的國產化大數據平臺具有一定的可行性及有效性。

基于混合架構的國產化大數據平臺還有很多地方需要改進，由于本文特定場景的需求并沒有引入其它實時業務場景，在今后的研究工作中將引入實時場景進行多項驗證，探索能否形成一套通用平臺，既可應用于離線大數據任務也可應用于實時大數據任務，以便應用于不同生產系統，從而大大提高平臺的靈活性。