基于本地化數(shù)據(jù)空間集中調(diào)度的海量數(shù)據(jù)平臺優(yōu)化策略

溫立輝

基于本地化數(shù)據(jù)空間集中調(diào)度的海量數(shù)據(jù)平臺優(yōu)化策略

溫立輝

（河源職業(yè)技術學院 電子與信息工程學院，廣東 河源 517000）

針對海量數(shù)據(jù)在傳統(tǒng)數(shù)據(jù)集成方式中性能不佳、效率低下問題，提出了一種集中式基于數(shù)據(jù)空間的優(yōu)化方案．首先，把平臺數(shù)據(jù)歸類為靜態(tài)數(shù)據(jù)與動態(tài)數(shù)據(jù)，以解決傳統(tǒng)集成方式中數(shù)據(jù)量過大、數(shù)據(jù)種類混亂，不利平臺的實時響應；其次，通過主/從分離的讀寫方式有效降低靜態(tài)數(shù)據(jù)機器上的節(jié)點負載，有效提升讀寫能力；再次，集群分片存儲方式極大改善了平臺對動態(tài)數(shù)據(jù)處理能力．與聯(lián)機事務分析（OLAP）集成方式相比，本方案依托數(shù)據(jù)切片、配置式數(shù)據(jù)源管理，更加靈活、輕巧，能更好地適應復雜的數(shù)據(jù)環(huán)境，適合中小企業(yè)對海量數(shù)據(jù)運維的需求．

大數(shù)據(jù)；水平切片；時間維度；主/從；讀寫分離；連接工廠

隨著互聯(lián)網(wǎng)、云計算發(fā)展，信息數(shù)據(jù)快速增長，數(shù)據(jù)的價值越來越吸引人們的視線，成為當下主流、火熱的主題[1]．海量數(shù)據(jù)時代的到來對企業(yè)來說既是一個挑戰(zhàn)也是一個機遇，大數(shù)據(jù)的規(guī)模效應給數(shù)據(jù)存儲、管理以及數(shù)據(jù)分析帶來了極大的挑戰(zhàn)[2,3]．海量據(jù)時代，人們能從數(shù)據(jù)中獲得可轉(zhuǎn)化為推動人類生活方式變革的有價值知識，它將成為下一個科技創(chuàng)新、市場競爭與生產(chǎn)力提高的前沿[4]．傳統(tǒng)的OLAP數(shù)據(jù)集成方式采用的是數(shù)據(jù)倉庫模式，分為4層：數(shù)據(jù)源、數(shù)據(jù)集市、分析服務、前端展現(xiàn)，數(shù)據(jù)源的數(shù)據(jù)通過ETL工具轉(zhuǎn)換到數(shù)據(jù)倉庫中, 然后分析工具從數(shù)據(jù)倉庫中讀取數(shù)據(jù), 生成數(shù)據(jù)立方體(MOLAP)供前端進行多種形式的數(shù)據(jù)展現(xiàn)[5]．這種集成方式周期長，且不靈活，不利于行業(yè)的變化發(fā)展．

利用云計算平臺搭建Hadoop計算框架是當前集成大數(shù)據(jù)平臺的主要方式步[6]，然而以此種方式搭建起來的數(shù)據(jù)平臺仍有如下幾大方面的問題：1）整個框架結(jié)構(gòu)特別臃腫，不利于日后平臺的維護與擴充；2）成本過于高昂，無法滿足中小企業(yè)對大數(shù)據(jù)建模的要求；3）由于云計算的開放式與Hadoop應用的分布式特性，不可避免的帶來平臺運營上的安全風險[6]；4）對于敏感數(shù)據(jù)，運營于開放平臺上，容易遭受黑客攻擊，而泄露用戶隱私[7]．針對以上海量數(shù)據(jù)平臺的集成問題，本文探討一種安全、高效、靈活的集成、運維大數(shù)據(jù)平臺架構(gòu)方式，特別適合于中小企業(yè)對大數(shù)據(jù)的建模、運維的要求．

1 整體架構(gòu)

海量數(shù)據(jù)的核心作用是統(tǒng)計分析，統(tǒng)計分析的關鍵步驟則在于數(shù)據(jù)建模[8]，而建模過程直接跟平臺集成架構(gòu)方式相耦合[9]，因而平臺的架構(gòu)方式合理與否直接影響到大數(shù)據(jù)的功能價值．海量數(shù)據(jù)平臺的架構(gòu)要考慮的因素有多方面，其中一個很重要的方面是數(shù)據(jù)負載[10]．大數(shù)據(jù)平臺的重要特征就是海量數(shù)據(jù)，且數(shù)據(jù)類型有：結(jié)構(gòu)化、半結(jié)構(gòu)化、非結(jié)構(gòu)化等形式[11]，因此數(shù)據(jù)負載是大數(shù)據(jù)架構(gòu)的核心要點．

傳統(tǒng)海量數(shù)據(jù)集成采用分布的結(jié)構(gòu)[12]，本數(shù)據(jù)集成架構(gòu)方式則采用集中式中央處理，如圖1所示，整個平臺簡單的劃分為3層，分別為：Web應用層、數(shù)據(jù)庫接口層、數(shù)據(jù)層．Web應用層為APP應用，由Java或其他面向?qū)ο笳Z言編寫的B/S服務，本層與業(yè)務相關并非我們的關注點，我們重點關注數(shù)據(jù)庫接口層與數(shù)據(jù)層．

1.1 數(shù)據(jù)庫接口層

數(shù)據(jù)庫接口層有兩臺服務器組成，一臺為接口服務主機，負責響應Web層的數(shù)據(jù)業(yè)務請求，另一臺為接口服務熱備主機，通過心跳檢測的方式相連，當服務主機出現(xiàn)故障時，熱備主機能自動檢測到，并自動替代服務主機提供相應的接口服務，Web應用層與此層之間是REST方式：http+json進行接口通信．REST是一種與WebService相似的通信方式，其復雜度比WebService要小，靈活性與擴展性比WebService更強大，實現(xiàn)方式更簡單，很多插件都提供對REST的完美支持，如Java語言的Spring框架．

1.2 數(shù)據(jù)層

數(shù)據(jù)層由若干臺數(shù)據(jù)庫服務器主機與備份機組成，主機與備份機之間通過心跳檢測方式相連．在本層中數(shù)據(jù)庫服務器分成2組，一組處理平臺業(yè)務數(shù)據(jù)，一組處理平臺系統(tǒng)數(shù)據(jù)．因應用數(shù)據(jù)具有動態(tài)性強，數(shù)據(jù)量大的特征，處理平臺應用數(shù)據(jù)的服務器應該占絕大多數(shù)，平臺系統(tǒng)數(shù)據(jù)是系統(tǒng)的管理數(shù)據(jù)，如系統(tǒng)的組織結(jié)構(gòu)數(shù)據(jù)、系統(tǒng)用戶數(shù)據(jù)、系統(tǒng)配置數(shù)據(jù)等，此類數(shù)據(jù)具有相對穩(wěn)定、數(shù)據(jù)量相對較小等特征，因而這一組應該占用相對少的數(shù)據(jù)庫服務器即可．應用數(shù)據(jù)組的數(shù)據(jù)庫服務器按某一維度進行水平切片，一般是按時間順序維度進行分片，方便數(shù)據(jù)的管理，同時對每一臺服務主機配備一臺備份機，用心跳的方式進行相連．平臺系統(tǒng)數(shù)據(jù)組的數(shù)據(jù)庫服務器采用主/從（Master/Slaver）方式進行連接，讀/寫實行分離的方式進行運作，以提高讀/寫的響應速度，當DB接口層有基礎數(shù)據(jù)寫操作的請求時，直接把數(shù)據(jù)寫入Master主機，后臺再異步把數(shù)據(jù)同步到Slaver從機，同步過程視服務器的忙碌程度會有一定的時間滯后，一般很短，DB接口層有基礎數(shù)據(jù)的讀請求時，直接從Slaver從機中讀取相關數(shù)據(jù)，從而實現(xiàn)讀/寫操作的分離，減輕服務器負載，加快了響應的速度．由于平臺的基礎數(shù)據(jù)相對穩(wěn)定，動態(tài)變化程度相對較小，因而主/從數(shù)據(jù)同步的滯后時間對其的影響可以忽略．

圖1 大數(shù)據(jù)整體架構(gòu)

2 實現(xiàn)原理

海量數(shù)據(jù)處理是利用強大的支持平臺，分析數(shù)據(jù)的潛在價值[13]．海量數(shù)據(jù)在實際應用中，包含多個環(huán)節(jié)的處理，最終形成監(jiān)控運行狀態(tài)、支撐方案決策的數(shù)據(jù)應用，在數(shù)據(jù)分析的全鏈條中，比較關鍵的2個環(huán)節(jié)是數(shù)據(jù)存儲和數(shù)據(jù)計算[14]，與本文所討論的架構(gòu)體系相對應即為：數(shù)據(jù)層與數(shù)據(jù)庫接口層．

2.1 主從雙機熱備

在主從模式工作中，數(shù)據(jù)庫接口層兩臺主備服務器以同一個虛擬IP響應對外服務，WEB應用層請求發(fā)送給主服務器，備份服務器通過心跳線偵測主服務器的運行狀態(tài)，若主服務器因硬件、軟件、資源等方面的原因出現(xiàn)故障而不能正常響應外部服務，備份服務器感知到后迅速啟動本機上的服務資源，接管主機上的服務，從而完成從備份服務器到主服務器的角色轉(zhuǎn)換，如圖2所示．因為原主服務器與原備份服務器兩臺服務器使用的是同一套APP，所以主備服務器切換后不影響原來的功能服務．

2.2 數(shù)據(jù)計算

數(shù)據(jù)庫接口層結(jié)構(gòu)如圖3所示，其由兩功能模塊組成，為：DAO持久化模塊、連接工廠模塊．持久化模塊負責數(shù)據(jù)表的增、刪、改、查等持久化操作的業(yè)務實現(xiàn)，接口向Web應用層暴露，接口層用REST的方式架構(gòu)，以Http超文本傳輸協(xié)議進行通訊，以Json作為報文格式，通信非常簡單、靈活、輕巧．連接工廠模塊只負責生產(chǎn)對應的數(shù)據(jù)層的數(shù)據(jù)庫連接（Connection），每一個連接為APP操作數(shù)據(jù)庫的橋梁，供持久化模塊調(diào)用，當持久化模塊進行DAO的業(yè)務操作時，首先應該通過連接工廠取得DB節(jié)點的連接，進而才能進行CRUD：Create、Retrieve、Update、Delete操作．

數(shù)據(jù)層有眾多的DB節(jié)點，連接工廠能通過數(shù)據(jù)庫接口層中的專門的配置文件（Excel格式）準確的創(chuàng)建對應業(yè)務所需的DB節(jié)點數(shù)據(jù)源，在整個連接工廠中有三種類型的數(shù)據(jù)配置文件，分別是：數(shù)據(jù)源參數(shù)配置文件、讀寫分離配置文件、時間維度配置文件．

連接工廠的數(shù)據(jù)源參數(shù)配置文件為Excel配置文件，具體格式及配置參數(shù)見表1．其中，“實例號”為每個數(shù)據(jù)源實例的唯一標識，“文件路徑”為每一個數(shù)據(jù)庫節(jié)點的連接配置文件（配置：訪問帳號、密碼、連接池等相關資源信息）所在的位置，“主機節(jié)點”為每臺數(shù)據(jù)庫服務器的IP地址．每一行代表一個數(shù)據(jù)源實例，Excel配置文件中可以無限擴展數(shù)據(jù)源實例．

在平臺服務啟動時，接口層會從Excel配置文件讀取每一行的參數(shù)信息并事先建好對應的數(shù)據(jù)源實例，存儲在緩存中，在需要用到相關實例時直接從緩存中取得相關實例．

連接工廠的讀寫分離參數(shù)配置信息同樣存儲到Excel文件中，具體格式及配置參數(shù)見表2．其中，“數(shù)據(jù)表”是指數(shù)據(jù)庫中的某一張系統(tǒng)表，“讀/寫操作”表示請求的性質(zhì)是讀操作還是寫操作，“實例號”就是數(shù)據(jù)源號，與表1相對應．

圖2 雙機熱備模式

圖3 數(shù)據(jù)庫接口層內(nèi)部結(jié)構(gòu)及交互原理

表1 數(shù)據(jù)源參數(shù)配置

表2 讀寫分離參數(shù)配置

當Web節(jié)點層向DB接口請求平臺中的系統(tǒng)數(shù)據(jù)時，連接工廠會根據(jù)此表的配置信息找到對應相匹配的數(shù)據(jù)源．首先，根據(jù)操作請求的表名，找到對應的數(shù)據(jù)行，然后再根據(jù)操作性質(zhì)確定唯一的數(shù)據(jù)源實例號．如，請求操作要查詢?nèi)罩颈淼娜罩拘畔?，則根據(jù)表名“sys_log”，操作性質(zhì)“read”，可以在此配置表中確定“DS_001”數(shù)據(jù)源實例，然后再與表1相匹配，找到已經(jīng)在緩存中創(chuàng)建好的數(shù)據(jù)源實例，再通過數(shù)據(jù)源實例可構(gòu)建出相應的數(shù)據(jù)庫連接，響應Web節(jié)點查詢?nèi)罩镜恼埱螅绻菍懭罩镜恼埱蟛僮?，則會在些配置表中找到“DS_002”的數(shù)據(jù)源，即實現(xiàn)了讀與寫操作服務器節(jié)點相分離，達到減輕服務器負載，加快響應的速度的目的．

連接工廠的時間維度參數(shù)配置信息也是存儲在Excel文件中，具體格式及配置參數(shù)見表3．其中，“數(shù)據(jù)表”是指數(shù)據(jù)庫中的某一張業(yè)務表，“起始日期”業(yè)務數(shù)據(jù)發(fā)生的開始日期，“結(jié)束日期”業(yè)務數(shù)據(jù)發(fā)生的結(jié)束日期，“實例號”就是數(shù)據(jù)源號，與表1相對應．

表3 時間維度參數(shù)配置

當Web節(jié)點層向DB接口請求平臺中的業(yè)務數(shù)據(jù)時，連接工廠會根據(jù)此表的配置信息找到對應相匹配的數(shù)據(jù)源．首先與業(yè)務表匹配，再與開始、結(jié)束時間相匹配，最后確定唯一的數(shù)據(jù)源實例號．如，Web節(jié)點層要請求查詢2018年6到8月的訂單數(shù)據(jù)時，根據(jù)業(yè)務表名“order”，開始時間“2018年6月”，結(jié)束時間“2018年8月”可確定唯一的數(shù)據(jù)源實例號“DS_005”，再與表1相關聯(lián)找到對應的數(shù)據(jù)源，這樣就避免了在所有服務器節(jié)點上掃描訂單數(shù)據(jù)，只需在“DS_005”數(shù)據(jù)源對應的服務器節(jié)點上檢索相關的訂單數(shù)據(jù)即可．

2.3 數(shù)據(jù)存儲

數(shù)據(jù)層由若干臺服務器主機集群組成，其中集群機器分成2大片，一組主機處理平臺的系統(tǒng)數(shù)據(jù)，另一組集群主機處理平臺的應用數(shù)據(jù)．

2.3.1 基礎數(shù)據(jù)存儲

2.3.1.1 主從結(jié)構(gòu)

系統(tǒng)數(shù)據(jù)方面，原理結(jié)構(gòu)如圖4所示，服務主機采取主/從結(jié)構(gòu)的形式搭配，由Master主機處理寫操作，Slaver從機處理讀操作，從而實現(xiàn)讀/寫相分離的模式．Master與Slaver間數(shù)據(jù)的同步，直接使用數(shù)據(jù)庫系統(tǒng)的主/從同步功能，目前絕大多數(shù)據(jù)庫管理系統(tǒng)都支持這一功能，即使是功能相對弱小的MySQL開源數(shù)據(jù)庫也已經(jīng)對這一塊有很好的支持，由于Slaver為讀（read）操作機器，因而其數(shù)據(jù)不會直接改變，因業(yè)務而發(fā)生變化的數(shù)據(jù)只需從Master寫（write）操作機器同步過來即可．

圖4 基礎數(shù)據(jù)主/從結(jié)構(gòu)

2.3.1.2 主從數(shù)據(jù)同步

在主服務節(jié)點與從服務節(jié)點之間的數(shù)據(jù)同步過程由三個進程來實現(xiàn)，其中從服務節(jié)點包含兩個工作進程：文件轉(zhuǎn)換進程、Socket通信進程，以及主服務節(jié)點的Socket通信進程．同步原理圖5所示，步驟如下：

1）從服務節(jié)點的Socket通信進程向主服務節(jié)點進程請求讀取數(shù)據(jù)庫二進制日志文件內(nèi)容．

2）主服務節(jié)點接收到從服務節(jié)點的TCP通信請求后，通過IO流把日志文件變化的數(shù)據(jù)信息返回給從服務節(jié)點，以響應其TCP通信請求．

3）從服務節(jié)點的Socket通信進程接收到信息后，將接收到的數(shù)據(jù)寫入中繼日志文件的末端，并記錄其它相關信息，為下一次操作能快速響應．

4）從服務節(jié)點的文件轉(zhuǎn)換進程定時偵測中繼日志文件，如果發(fā)現(xiàn)日志文件中新追加了新的數(shù)據(jù)內(nèi)容，會即時解析該日志文件中的內(nèi)容變成可執(zhí)行的SQL語句，同時在本服務器端執(zhí)行相應的SQL語句，以兩端的數(shù)據(jù)一致、同步．

2.3.2 業(yè)務數(shù)據(jù)存儲

2.3.2.1 分片結(jié)構(gòu)

應用數(shù)據(jù)方面，原理結(jié)構(gòu)如圖6所示，服務主機從某一維度對數(shù)據(jù)作切片，最常見的是對時間維度進行統(tǒng)一分片，也就是說，每一臺服務主機上的表結(jié)構(gòu)是一樣的，但是不同節(jié)點上的具體的業(yè)務數(shù)據(jù)是不同的，按時間進行分片存儲，例如按日歷年來進行分片，可考慮每個節(jié)點的主機上存儲某年的數(shù)據(jù)，也可以一臺主機節(jié)點存儲多年的業(yè)務數(shù)據(jù)，根據(jù)實際情況來進行切片，但要確保切片在每個節(jié)點上不重復，且要保證切片的連貫性與完整性，不能有分片被遺漏．同時，可根據(jù)實際需要為每一個主節(jié)點添加一個備份節(jié)點，主/備服務器上的所有數(shù)據(jù)完全一樣，當主節(jié)點發(fā)生故障時，由備份節(jié)點替代主節(jié)點繼續(xù)工作．此處每一個主節(jié)點對時間維度配置一個數(shù)據(jù)源實例節(jié)點，可根據(jù)實際無限的增加主節(jié)點．

主/備節(jié)點間可考慮使用主/從原理同步數(shù)據(jù)，也可以自己編寫一個數(shù)據(jù)同步腳本，然后由系統(tǒng)定時器周期性的調(diào)度此同步腳本，達到數(shù)據(jù)同步的目的．當主節(jié)點發(fā)生故障時，接口層的連接工廠無法構(gòu)建節(jié)點上的數(shù)據(jù)庫連接，此時，連接工廠自動查找備份節(jié)點的數(shù)據(jù)源實例來構(gòu)建新的連接．

圖5 主從復制原理

圖6 按時間維度分片結(jié)構(gòu)

2.3.2.2 分片原則

對于海量平臺數(shù)據(jù)，首先面臨的問題就是如何將數(shù)據(jù)平均的分配到不同的服務器上，使每臺機器盡可能負載均衡．對于非關聯(lián)數(shù)據(jù)來說，這個問題解決起來比較容易，只要平臺數(shù)據(jù)盡可能的平均分布在各臺主機上即可．對于關聯(lián)數(shù)據(jù)來說，由于數(shù)據(jù)之間的強耦合性，如果數(shù)據(jù)分片不合理，不僅會造成機器之間負載不均衡，還會大量增加機器之間的網(wǎng)絡通信，反而造成性能不佳，所以合理切分關聯(lián)數(shù)據(jù)對于提高平臺數(shù)據(jù)的運行效率非常重要[15]．如圖7兩種分片方式中，方案1的分片方式其網(wǎng)絡通信總量要遠小于方案2的分片方式所對應的網(wǎng)絡通信量．

衡量關聯(lián)數(shù)據(jù)切片是否合理主要考慮2個因素：機器負載均衡以及網(wǎng)絡通信成本．如果單獨考慮機器負載均衡，那么最好是將數(shù)據(jù)盡可能平均地分配到各個服務器上，但是這樣不能保證網(wǎng)絡通信總量是盡可能少的；如果單獨考慮網(wǎng)絡通信，那么可以將密集交互的數(shù)據(jù)節(jié)點盡可能放到同一臺機器上，這樣就有效地減少了網(wǎng)絡通信量，但是這樣很難做到機器之間的負載均衡，某個較大的密集的子節(jié)點會導致某臺機器高負載．所以，合理的切片方式需要在這兩個因素之間找到一個較穩(wěn)妥的均衡點，以期系統(tǒng)整體性能最優(yōu)[15]．

圖7 不同分片方式差異

3 結(jié) 論

本海量數(shù)據(jù)架構(gòu)方案不同與傳統(tǒng)的數(shù)據(jù)集群，關系型數(shù)據(jù)庫服務主節(jié)點的業(yè)務數(shù)據(jù)不需要在各個主節(jié)點間進行同步，進一步節(jié)省了數(shù)據(jù)的存儲空間，具有以下幾大優(yōu)點：1）可擴展性好，在水平切片維度，可以根據(jù)實際需要任意擴展．如按時間維度進行切片時，可以在未來與過去的軸線上進行無縫的擴充；2）對原有業(yè)務數(shù)據(jù)兼容性好，可以在不改變、不遷移原有數(shù)據(jù)服務節(jié)點的情況完美對接現(xiàn)有業(yè)務數(shù)據(jù)；3）能適應各種復雜的數(shù)據(jù)環(huán)境，本方案與數(shù)據(jù)平臺無關，可完全兼容各種類型的關系數(shù)據(jù)庫，各種類型的關系數(shù)據(jù)庫只需在各自服務節(jié)點的配置文件中配置好即可，不需要作復雜的整合．

同時本方案也還存在不足的地方，如數(shù)據(jù)分片存儲后增加了不同機器上關聯(lián)數(shù)據(jù)的網(wǎng)絡開銷，一定程度降低了數(shù)據(jù)分片存儲的性能，尋找一種合理的分片算法來減少不同機器節(jié)點上的通信開銷是下一步的研究重點．

[1] 孫峻嶺，假露，劉其軍，等．基于Web集群的海量影像顯示技術研究[J]．計算機系統(tǒng)應用，2019，28（4）：76-82．

[2] 趙會群，劉金鑾．基于貝葉斯網(wǎng)絡的復雜事件大數(shù)據(jù)處理系統(tǒng)測試數(shù)據(jù)生成方法研究[J]．計算機應用研究，2018，35（8）：2389-2392，2396．

[3] 朝樂門，邢春曉，張勇．數(shù)據(jù)科學研究的現(xiàn)狀與趨勢[J]．計算機科學，2018，45（1）：1-13．

[4] 畢婭，原惠群，初葉萍，等．大數(shù)據(jù)環(huán)境下基于公共服務平臺的資源多級智能尋租與匹配策略和價值創(chuàng)造[J]．計算機科學，2019，46（2）：42-49．

[5] 李志國，鐘將．數(shù)據(jù)科學在國內(nèi)管理學研究中的應用綜述[J]．計算機科學，2018，45（9）：38-45．

[6] 溫振蕙，樊永生，余紅英．基于Thrift的HBase數(shù)據(jù)存儲機制優(yōu)化[J]．科學技術與工程，2019，19（6）：185-189．

[7] PANG Qian, YU Zhongqing, WANG Haiya. Data Resource Management Platform of Paper-making Mill Equipment Operation based on Hadoop[J]. International Journal of Plant Engineering and Management, 2019，24（1）：44-51．

[8] Dawei Zhao, Gang Chen. Construction of Implicit Semantic Multi-label Text Fast Clustering Model based on Big Data[C]/Computer Science and Electronic Technology International Society, 2018：159-162．

[9] Zhang Xiaohui. Construction of Personalized English Teaching Model Driven by Big Data[C]/Computer Science and Electronic Technology International Society, 2019：371-375．

[10] 周岳，陳慶奎．面向大規(guī)模數(shù)據(jù)接入系統(tǒng)的負載平衡機制[J]．計算機應用，2018，38（1）：50-55．

[11] 史開泉．大數(shù)據(jù)結(jié)構(gòu)-邏輯特征與大數(shù)據(jù)規(guī)律[J]．山東大學學報（理學版），2019，54（2）：1-29．

[12] QU Huan. Spatial Distribution Patterns of Cultural Facilities in Shenzhen Based on GIS and Big Data[J]., 2018，10（4）：48-54．

[13] 田亞明．大數(shù)據(jù)挖掘在電商市場中分析與決策的應用[J]．電子技術與軟件工程，2019（7）：167-168．

[14] 聶璐，鄭吉洲，王麗娜，等．基于國產(chǎn)化服務器集群的海量數(shù)據(jù)處理負載均衡技術[J]．航天控制，2019，37（1）：51-56．

[15] 張俊林．大數(shù)據(jù)日知錄:架構(gòu)與算法[M]．北京：電子工業(yè)出版社，2014：271-310．

Optimizing Strategy of Massive Data Platform Based on Localized Data and Space Centralized Scheduling

WEN Lihui

（）

In view of the poor performance and low efficiency of mass data in traditional data integration, an optimum scheme based on centralized data space is proposed. First of all, the platform data is classified as either static or dynamic, so as to solve the problems that traditional integration method have, such as too large amount of data, data types confusion, and real-time response to adverse platform. Secondly, the ability of reading and writing can be enhanced and the node static data on the machine load can be reduced effectively through a master/slave separation. Thirdly, the dynamic data processing ability of the platform can be greatly improved by cluster slicing storage way. Compared with the online transaction processing (OLTP), this scheme is based on data slicing and configuration data source management. Therefore, it is more flexible and agile, better adapted to complex data environment, and more suitable to meet small and medium-sized enterprises’ demand for large data operation.

massive data; horizontal slicing; time dimension; master/slave; reading and writing separation; factory connection

10.13899/j.cnki.szptxb.2019.05.005

2019-03-27

溫立輝（1979-），男，廣東河源人，漢族，高級工程師，主要從事大數(shù)據(jù)、云平臺、系統(tǒng)架構(gòu)研究．

TP311.13

A

1672-0318（2019）05-0023-06