基于HBase+ ElasticSearch的海量交通数据实时存取方案设计
董長青，任女爾，張慶余，田玉靖
北京卡達克數(shù)據技術中心軟件業(yè)務本部，天津 300300
摘要：交通流數(shù)據具有數(shù)據海量、存儲和交互速率快等特征，因此其數(shù)據的采集、存儲及檢索成為了車輛遠程監(jiān)控平臺中的關鍵問題。采用LVS集群技術進行數(shù)據采集負載均衡，隊列緩存處理I/O時延，HBase進行分布式數(shù)據存儲；針對Hadoop實時在線數(shù)據處理不足的問題，整合ElasticSearch并構建了分層索引。通過關鍵技術的設計和實現(xiàn)，車輛監(jiān)控由400輛擴展到上萬輛，PB級數(shù)據在線查詢速度提升了10~20倍，驗證了方案的高效性。
關鍵詞：Hadoop/HBase；ElasticSearch；Linux虛擬服務器；海量數(shù)據；實時
中圖分類號：TP311??文獻標識碼：A?
doi:?10.11959/j.issn.2096-0271.2017010
?
Design scheme of massive traffic data real-time access based on HBase and ElasticSearch
DONG Changqing, REN Nver, ZHANG Qingyu, TIAN Yujing
Software Business Department, Beijing CATARC Data & Technology Center, Tianjin 300300, China
Abstract:?Traffic data has the characteristics of massive and real-time, and its massive data acquisition, storage and retrieval has become a key issue in the vehicle remote monitoring platform. According to the study of these problems, the cluster technology of LVS was used to solve the data acquisition load balance, the queue cache model was used to solve I/O delay, and HBase distributed data storage scheme was used to solve the massive data storage. HBase integration ElasticSearch, which was aimed to solve the real-time online data processing problems of Hadoop, was designed to build a hierarchical index. Through the design and implementation of the key technologies, the number of vehicle monitoring had been promoted from 400 to 1 million, online query speed increased about 10 to 20 times based on PB level data. The results verified the efficiency of the scheme.
Key words:?Hadoop/HBase, ElasticSearch, Linux virtual server, massive data, real-time
論文引用格式：董長青，任女爾，張慶余，等. 基于HBase+ ElasticSearch的海量交通數(shù)據實時存取方案設計[J]. 大數(shù)據, 2017, 3(1): 80-89.
DONG C Q, REN N E,?ZHANG?Q Y, et al.Design scheme of massive traffic data real-time access based on HBase and ElasticSearch[J]. Big Data Research, 2017, 3(1): 80-89.
?
1 ?引言
在車聯(lián)網飛速發(fā)展的時代，智能交通在發(fā)展中的一些問題也逐步暴露出來。如在數(shù)據采集中，常用的通信技術只能同時監(jiān)控幾百輛車；在數(shù)據結構單一、海量的數(shù)據存取和分析時，傳統(tǒng)關系型數(shù)據庫應用能力大幅度降低等。如果車輛每2 s上傳一條約120 byte的全球定位系統(tǒng)（global positioning system，GPS）數(shù)據，統(tǒng)計600輛車的數(shù)據，則月統(tǒng)計數(shù)據為87 GB，一年將約有1 TB的數(shù)據需要進行存儲。在統(tǒng)計過程中，高峰期車輛數(shù)量遠不止這些。在很多企業(yè)的實際環(huán)境中，基于傳統(tǒng)技術的監(jiān)控平臺進行系統(tǒng)優(yōu)化處理后，其數(shù)據處理能力也只能達到幾百輛車的收集功能，一旦進入峰值，系統(tǒng)幾乎無法正常運行。此外，車聯(lián)網數(shù)據不僅包括GPS數(shù)據，還包括車輛控制器局域網絡（controller area network，CAN）數(shù)據、圖像、視頻等數(shù)據，在采集和檢索技術上往往與其實際生產需求相差較遠。
大數(shù)據技術的快速發(fā)展為這一情況帶來了良好的發(fā)展前景和機遇，尤其是當前被廣泛探索應用的Hadoop、Spark等技術，針對TB甚至PB級的數(shù)據，其豐富的組件在數(shù)據存儲和挖掘、分析方面提出了完善的處理方案。本文通過分析當前的分布式軟件技術，結合HBase數(shù)據庫進行設計改進，設計了一套針對交通數(shù)據采集、存儲和檢索的方案。
?
2 ?技術介紹
在車聯(lián)網遠程監(jiān)控平臺中，數(shù)據的采集、存儲及檢索問題是傳統(tǒng)的關系型數(shù)據平臺無法高效處理的。
2.1 ?Linux虛擬服務器技術
在數(shù)據采集方面，交通數(shù)據到監(jiān)控平臺之間一般采用3G/4G等技術，通過socket進行TCP/IP數(shù)據傳輸。但是每個端口負載能力有限，最高能夠支持400輛車同時上傳數(shù)據，高于400輛車同時傳輸時，數(shù)據時延甚至丟失的現(xiàn)象較為明顯。本研究使用Linux虛擬服務器（Linux virtual server，LVS）技術進行負載均衡，從而提供給用戶訪問一臺超高性能服務器的效果。LVS技術支持通過配置多個高速局域網服務器來進行任務分配，其對外的接口則為固定的IP地址和端口，從而提供任務分發(fā)轉移的負載調度功能。此外，LVS技術支持熱處理，在正常工作的情況下增加或者刪除節(jié)點。LVS的負載調度器（director）可以設置3種工作模式：一是地址轉換，負載調度器通過算法將內網地址進行映射，外網數(shù)據分組通過映射的地址進行分發(fā)；二是通過IP隧道，負載調度器進行調度請求，通過IP隧道客戶端數(shù)據分組進行封裝發(fā)給服務器，服務器直接響應客戶端；三是直接路由，適用于集群內的服務器都在一個網段，數(shù)據分組直接由負載調度器發(fā)給實際服務器，該種方式速度快，且開銷較少。LVS調度算法主要有等比例輪轉、加權輪循、目標地址散列調度、源地址散列調度等靜態(tài)調度算法以及最少連接、加權最少連接、永不排隊、動態(tài)目標地址散列、帶復制的動態(tài)目標地址散列等動態(tài)調度算法。IP虛擬服務器（IP virtual server，IPVS）技術是一種工作在網絡模型第四層的高效交換機，可以針對不同的網絡選擇不同的調度算法。
在小型的分布式負載中，唯一從軟件技術上能達到硬件F5量級的方案就是采用LVS技術。參考文獻[1]使用LVS技術解
決負載網站的負載均衡配置問題，參考文獻[2]描述了LVS技術的高可用負載均衡方案，但其后續(xù)處理案例也主要針對超文本傳輸協(xié)議（hypertext transfer protocol， HTTP）。本文基于LVS的IP虛擬分發(fā)技術進行socket通信集群負載。
2.2 ?HBase存儲技術
數(shù)據采集接收伴隨著海量數(shù)據的存儲問題，性能較好的傳統(tǒng)關系型數(shù)據庫一般采用Oracle、DB2等。但在實際應用中，交通流數(shù)據結構單一，結構內部卻比較靈活，當有些字段在數(shù)據存儲中只為部分數(shù)據設計時，其存儲空間將造成極大的浪費，再加上數(shù)據量巨大，交通流數(shù)據顯然不適合傳統(tǒng)的存儲方式。隨著分布式數(shù)據庫的發(fā)展，HBase作為列式存儲數(shù)據庫，為交通流的數(shù)據存儲提供了高效的寫入性能和靈活的存儲方式。在其存儲結構上，HBase按照字典順序進行排序，行鍵（RowKey）直接作為其中的一級索引，為其良好的讀寫性能提供了基礎。
2.3 ?HBase檢索
HBase內置了兩張存儲表（ROOT和META）進行區(qū)域分布及區(qū)域詳細情況的存儲。在普通的數(shù)據檢索過程中，首先從ZooKeeper上定位到META表的位置，然后從中獲取對應的RegionServer，根據行鍵從這兩張內置表中查詢數(shù)據的region，然后查找到對應的行鍵，從而進行數(shù)據檢索。但是HBase的存儲業(yè)務表之間沒有直接的關聯(lián)，而且單一索引很可能造成數(shù)據查詢變成全表掃描，因此當查詢海量數(shù)據時，對關聯(lián)數(shù)據或復雜條件的支持較差。目前，針對這一問題，已經發(fā)展了ITHBase（帶索引的事務性HBase）、 IHBase（indexed HBase，是HBase的擴展，用于支持更快的掃描）等二級索引方式。ElasticSearch是一種基于Lucene的實時大數(shù)據搜索引擎，與適用于獨立應用的Solr相比，更適用于云計算環(huán)境。參考文獻[3]中采用對交通流數(shù)據進行存儲，但其存儲行鍵設計在實時查詢性能上經實驗檢測存在較大的問題，參考文獻[4]和參考文獻[5]引入了大數(shù)據的實時處理辦法進行日志的處理，本文通過進一步研究和改進，引進ElasticSearch進行數(shù)據索引，設計其將必要條件與其行鍵關聯(lián)起來，形成二級索引[6]，從而加快數(shù)據搜索速度。
?
3 ?海量交通數(shù)據的存取架構設計
海量交通數(shù)據的存取架構是各個企業(yè)目前亟待解決的問題，并發(fā)采集數(shù)據、海量數(shù)據存儲及海量數(shù)據的檢索等問題，成為企業(yè)車聯(lián)網進程中的阻力。
3.1 ?系統(tǒng)架構
整體架構主要從采集、存儲和檢索3個方面進行設計改進并實現(xiàn)。整體架構如圖1所示。
圖1 海量交通流數(shù)據分布式存取架構
當數(shù)據從交通流中獲取時，由LVS進行IP轉發(fā)負載均衡，實現(xiàn)車輛高并發(fā)數(shù)據的接收工作；接收服務器收到數(shù)據以后，對數(shù)據進行預處理操作，分別按照業(yè)務類型轉入緩沖區(qū)，通過HBase客戶端進行數(shù)據寫入操作，同時將數(shù)據索引[7]建立到ElasticSearch中，根據數(shù)據的狀況動態(tài)調配處理層進行數(shù)據線程數(shù)的設置，保證高并發(fā)寫入速度；在Web應用中讀取數(shù)據時，根據業(yè)務需求的不同設置不同的線程數(shù)量。
3.2 ?關鍵設計
3.2.1 ?LVS負載均衡
結合實際 生產環(huán)境，研究采用速度快、開銷少的直接路由的工作模式以及IPVS技術進行算法調度[8]，配置4臺服務器分別作為LVS以及3臺數(shù)據處理設備，操作系統(tǒng)采用Cento 6。
圖2 系統(tǒng)LVS負載均衡架構
如圖2所示，配置3臺數(shù)據處理服務器，然后配置對應的LVS，在數(shù)據由車載終端發(fā)送到路由時，由路由直接轉發(fā)到LVS，LVS通過調度算法計算將數(shù)據發(fā)送到合適的數(shù)據處理服務器，數(shù)據處理服務器接收數(shù)據以后，直接通過路由響應終端。主要實現(xiàn)步驟如下。
● 配置數(shù)據處理服務器，禁止地址解析協(xié)議（address resolution protocol，ARP）請求。
● 設置LVS子網掩碼與數(shù)據處理服務器一致，開啟報文轉發(fā)功能，增加網卡VIP記錄“ipvsadm -A -t 10.8.10.177:20080 -s rr -p 2000”，含義為各個車載訪問地址及其端口號，設定2 s為超時時間，調度為等比例輪詢調度（rou nd robi n，RR）算法。
● LVS服務配置數(shù)據處理服務器，按照“ipvsadm -a -t 10.8.10.177:20080 -r 10.8.10.162: 20080 -g”指令分別配置
3臺數(shù)據處理服務器的訪問地址端口及直接路由模式。
此時配置完畢，該方案具有較強的可擴展性，一方面可以根據監(jiān)控車輛的負載情況增加或者減少數(shù)據處理服務器的數(shù)據，另一方面可以根據緩沖和寫入線程的情況保證數(shù)據寫入時延在秒級以內。此外，可以參考參考文獻[2]進行LVS備份方案的設定。
3.2.2 ?多源存儲設計
交通流數(shù)據從LVS分發(fā)到各個數(shù)據處理服務器以后，由接收端應用進行預處理，按源分類進行緩沖存儲操作，通過監(jiān)控程序根據各個數(shù)據源中的數(shù)據大小判定啟動不同數(shù)量的寫入線程，默認寫入線程為3個，當數(shù)據量過大時將增加寫入線程。寫入線程主要負責寫入HBase數(shù)據和構建ElasticSearch索引工作。
該架構設計主要分為GPS數(shù)據、CAN數(shù)據和多媒體感知數(shù)據，然后根據每種數(shù)據的結構不同分別存儲到不同的緩沖區(qū)中。按每秒接收10萬條GPS和CAN數(shù)據計算，3臺數(shù)據處理服務器每臺每秒需接收（100 000×12 kB/3）/（1 024×1 024）≈0.39 MB數(shù)據，GPS和CAN數(shù)據緩沖區(qū)大小預設為4 MB，多媒體數(shù)據緩沖區(qū)大小設置為16 MB，即每臺數(shù)據處理服務器根據數(shù)據源由20 MB內存作為數(shù)據緩沖區(qū)，從而允許將一定數(shù)量的數(shù)據高效地進行存儲。對于分組數(shù)據，采用臨時緩沖區(qū)先行進行緩沖，組合成整個分組后再進入緩沖區(qū)，若數(shù)據大小大于緩沖剩余空間大小，則直接啟動額外的寫入線程進行存儲。各個文件結構設計如圖3所示。
圖3 數(shù)據結構
以GPS數(shù)據為例，其在緩沖結構中存儲，采用時間值進行散列計算后存儲到固定個數(shù)的隊列中，如2016年1月13日13:42:57，設置t為20 161 452 663 777 771，進行求余計算，計算式為f(t)=t%n。設置n為3，即GPS數(shù)據源采用3組隊列，隊列索引分別為0、1、2，則f(t) = 20 161 452 663 777 771%3求余結果為1，因此將該數(shù)據放置在索引為1的隊列。
緩沖數(shù)據構建完畢以后，由寫入層以“先進后出”的原則讀取數(shù)據進行持久化存儲。在HBase數(shù)據存儲中，數(shù)據基本上按時間順序存儲，直接存儲會造成寫入熱點問題，即多個線程均指向一個HBase集群節(jié)點寫入的情況，因此采取以下優(yōu)化策略防止熱點和全表掃描。
● 在行鍵前加入散列前綴，利用如下計算方式計算：byte pre=(byte) (Long.hashCode(t) % < regionservers no.>)，將通過前綴加上時間戳散列值的方式產生的不同的數(shù)據分發(fā)到不同的RegionServer上。
● 取消自動寫入，根據實驗設置寫入緩沖區(qū)大小為20 MB，能提高千萬級數(shù)據同時插入的效率。
● 預分配region，建表時直接使用預分配region，避免單個region灌入數(shù)據。通過以上措施，達到了良好的實現(xiàn)效果，加入索引提高查詢的性能，一定會降低寫入數(shù)據的性能，本文兼容性地考慮兩方面，并進行了綜合實現(xiàn)。
3.2.3 ?索引方案改進
HBase本身主鍵構建了B+樹進行索引[9]，稱為一級索引，其對基于主鍵數(shù)據的查詢效率很高；然而對于非主鍵字段的查詢效率卻很低，對HBase大數(shù)據量的訪問，僅僅通過MapReduce和掃描器處理是不能達到令人滿意的效果的。其主要缺陷在于二級索引構建困難，重新構建表結構進行索引往往需要雙重查詢，而且難以維護索引數(shù)據與原數(shù)據的同步性。隨著ITHBase、IHBase以及華為技術有限公司（以下簡稱“華為”）的hindex項目的誕生，二級索引方案和效果不斷提升，本文基于華為二級索引方案進行改進，結合ElasticSearch通過多層索引和直接索引由業(yè)務引擎共享的方案來實現(xiàn)高性能索引改進方案。
（1）基于HBase表的二級索引方案設計
基于HBase 表的二級索引方案設計主要采用索引表和數(shù)據表共存共享的 方 式 構建，通過HBase的協(xié)處理器（coprocessor）構建與數(shù)據表相同和類似的索引，索引表行鍵設計為“數(shù)據表StartKey+IndexName +Value+數(shù)據表行鍵”的方式。通過使索引表和數(shù)據表擁有相同的StartKey并重寫均衡集群類（balance cluster）控制索引表的分配，使其索引表和數(shù)據表構建在相同的RegionServer上，并且在region分裂時也能同步進行分裂，這樣可以使得協(xié)處理器非?？焖俚卦赗egionServer上計算出相應的索引數(shù)據。IndexName和Value對應的為HBase數(shù)據中單列的值，如針對車輛監(jiān)測點進行的數(shù)據查詢，Value對應為監(jiān)測點的數(shù)值，從而通過索引查詢出某個檢測點所有的行鍵數(shù)據，進一步查詢數(shù)據。
如圖4所示，實線代表數(shù)據指向，虛線代表數(shù)據塊指向，索引表數(shù)據對數(shù)據表數(shù)據的行鍵進行進一步改造，增加索引名稱和索引數(shù)據。當數(shù)據進行分裂時，其對應的索引同步進行分裂，并且使用保持數(shù)據的StartKey起始一致。
圖4 數(shù)據分區(qū)分裂表
（2）ElasticSearch構建
通過索引表的方式構建二級索引以后，數(shù)據的查詢依然停留在依靠HBase數(shù)據表本身的能力去優(yōu)化查詢速度。本文在構建索引數(shù)據表基礎上同步構建ElasticSearch及緩存索引數(shù)據。如圖5所示，當負責寫入的線程進行寫入操作時，通過協(xié)處理器同步處理索引表數(shù)據，然后通過觀察者模式同步索引數(shù)據到ElasticSearch中，并且根據多源數(shù)據特性，將實時查詢的數(shù)據添加到內存索引緩沖區(qū)。
圖5 數(shù)據寫入過程
首先，開啟協(xié)處理器，通過HBase Shell激活協(xié)處理器的觀察者（observer）；通過繼承基類BaseRegionObserver，重寫postPut和postDelete方法。把生成的JAR包配置到寫處理器中，即可實現(xiàn)數(shù)據的同步。在實際數(shù)據操作過程中，交通流數(shù) 據幾乎不會發(fā)生更改，但是會持續(xù)寫入，因此在由觀察者數(shù) 據同步時采用了ElasticSearch的緩沖池批處理操作，當達到限值時進行同步寫入操作。此外，設置其分片值、緩存類型為軟引用（soft reference），并調整其最大緩存值等進行ElasticSearch調優(yōu)。
數(shù)據讀取過程如圖6所示，當發(fā)起數(shù)據讀取過程時，首先進行查詢。當數(shù)據讀取時，首先訪問ElasticSearch，根據查找到的索引表中的結果，調用協(xié)處理器進行數(shù)據實際行鍵查找，訪問數(shù)據表，從而得到數(shù)據，從協(xié)處理器返回給客戶端。通過該模式進行改進，數(shù)據查詢效率大幅度增加。
圖6 數(shù)據讀取過程
?
4 ?系統(tǒng)測試
本文主要從并發(fā)存儲的吞吐量、軌跡回放查詢速度進行了測試，從而驗證其并發(fā)寫入和實時讀取的性能。
4.1 ?并發(fā)存儲吞吐量測試
為了充分驗證本架構的可行性，分別測試1萬到1 000萬條數(shù)據的插入速度，并且從單機服務、不添加索引和添加索引3方面進行對比測試。圖7為測試結果。
圖7 單機、添加索引集群、不添加索引集群數(shù)據
其中，添加索引的情況比不添加索引的情況速度明顯降低，但插入數(shù)據完畢時間總體維持在秒級以內。此外，對數(shù)據進行了持續(xù)性測試，連續(xù)10 h以每秒13萬條數(shù)據的速度插入（相當于監(jiān)控了10萬輛車每秒上傳一次數(shù)據），其插入數(shù)據緩沖區(qū)平穩(wěn)保持在某個較低臨界值后不再變動。在數(shù)據進行索引插入時，能夠支持每秒7.84萬條數(shù)據平穩(wěn)運行，較不加索引時有一定降低，但整體插入速度能夠在秒級以內實現(xiàn)10萬級速度的插入。
4.2 ?軌跡回放查詢速度測試
軌跡回放主要從整體統(tǒng)計查詢和實時響應兩方面性能進行體現(xiàn)，圖8測試了在PB級數(shù)量基數(shù)水平上，結果集數(shù)量不同時的數(shù)據查詢效率。
圖8 不同結果集數(shù)據查詢效率
當小結果集進行查詢時，不添加索引時響應速度在10 s以上，而進行索引時，數(shù)據查詢速度在1 s以內，速度提升了20倍左右。大結果集（萬級）進行查詢時，速度提升了9~10倍，實時查詢效率及速度大幅度提升。在實際應用中，20 min的軌跡回放約為600條數(shù)據，能夠實現(xiàn)5 s之內查詢，因為數(shù)據響應可分段，所以如果以5 min為時間段進行4次查詢，能夠達到頁面較為流暢的效果。
此外，在研究傳統(tǒng)數(shù)據庫（如Oracle）在數(shù)據存取過程中的表現(xiàn)時，采用了按照月進行分區(qū)、創(chuàng)建復雜查詢條件索引、添加存儲過程、避免全表掃描操作（如執(zhí)行 “l(fā)ike”語句）、建立緩存等設計。研究發(fā)現(xiàn)索引過多則寫入性能下降，而且對非結構化數(shù)據存儲支持性能不佳，在整體大數(shù)據操作上編程和配置的復雜度提高。研究測試了直接對GPS數(shù)據表進行插入和讀取操作的速度情況：在進行數(shù)據插入操作時（對比每分鐘插入數(shù)據量），百萬條以下的數(shù)據插入速度Oracle和HBase沒有明顯差異，但超過百萬條以后，Oracle的數(shù)據插入速度逐步下降，千萬條以上HBase數(shù)據插入速度比Oracle快2~7倍；在進行數(shù)據讀取操作時，HBase千萬條以上數(shù)據讀取速度是Oracle的5~15倍；在同時進行插入和讀取操作的過程時，HBase讀取速度比Oracle快15 ~30 倍。在相同的硬件和網絡環(huán)境中分析對海量交通流數(shù)據的處理能力，HBase列式數(shù)據庫無論從插入性能還是讀取性能都可以調優(yōu)到更高水平。
?
5 ?結束語
LVS解決高并發(fā)接收數(shù)據的問題，通過多源緩存策略解決數(shù)據存儲不及時的問題，避免數(shù)據分組丟失；同時設計表級二級索引、引入ElasticSearch增加數(shù)據查詢速度?？傮w上本文通過設計高并發(fā)存儲架構和多層索引查詢架構，實現(xiàn)了交通流數(shù)據的高并發(fā)實時監(jiān)控數(shù)據存儲和查詢，從軟件架構上解決了基于Hadoop存儲數(shù)據對實時計算查詢支持度不夠的問題。下一步，將集中設計基于多層的熱點內存緩存方案，并設計響應的緩存命中策略來實現(xiàn)更高的實時性能。
?
參考文獻：
[1] 王頤帥. 基于LVS 的服務器負載均衡技術[J].計算機系統(tǒng)應用, 2014, 23(7): 252-255. W ANG Y S . S er ver lo ad ba l a nc i n g architecture based on LVS[J]. Computer Systems & Applications, 2014, 23(7): 252-255.
[2] 劉敏娜, 張繼濤. 基于LVS+KEEPALIVED的高可用負載均衡研究與應用[J]. 自動化技術與應用, 2014, 33(11): 22-27.
?LIU M N, Z HANG J T. The st udy and application of based on the LVS + KEEPALIVED high avaliablility load balance[J]. Techniques of Automation and Applications, 2014, 33(11): 22-27.
[3] 陸婷, 房俊, 喬彥克. 基于HBase 的交通流數(shù)據實時存儲系統(tǒng)[J]. 計算機應用, 2015, 35(1): 103-107, 135.
L U T, FANG J, QIAO Y K. HBase-based real-time storage system for traffic stream data[J ]. Journal of Computer Applications, 2015, 35(1): 103-107, 135.
[4] 葛微, 羅圣美, 周文輝. HiBase：一種基于分層式索引的高效HBase 查詢技術與系統(tǒng)[J].計算機學報, 2015, 38(35): 1-15.
G E W, LUO S M, ZHOU W H. HiBase:a hierarchical indexing mechanism and system for efficient HBase query[J ]. Chinese Journal of Computers, 2015, 38(35): 1-15.
[5] 白俊, 郭賀彬. 基于ElasticSearch的大日志實時搜索的軟件集成方案研究[J]. 吉林師范大學學報（自然科學版）, 2014(1): 85-87.
BAI J, GUO H B. The design of software integration for big log data real time search based on ElasticSearch[J]. Jilin Norma l Un iver sity Jou r na l( Natu ra l Science Edition), 2014(1): 85-87.
[6] 鐘雨, 黃向東, 劉丹, 等．大規(guī)模裝備監(jiān)測數(shù)據的NoSQL 存儲方案[J]. 計算機集成制造系統(tǒng), 2013, 19(12): 3008-3016.
ZHONG Y, HUANG X D, LIU D, et al. NoSQL storage solution for massive equipment monitoring data management[J]. Computer Integrated Manufacturing Systems, 2013, 19(12): 3008-3016.
[7] SFA K I A NA K I S G, PATL A K A S I, NTARMOS N, et al. Interval indexing and querying on key-value cloud stores[C]//The 29th IEEE International Conference on Data Engineering (ICDE), April 8-12, 2013, Brisbane, Australia. New Jersey: IEEE Press, 2013: 805-816.
[8] 蘇命峰, 陳文芳, 李仁發(fā). LVS 集群負載調度算法研究[J ]. 長沙大學學報, 2012(5): 72-74.
SU ?M F, CHEN W F, LI R F. Research on LVS cluster load scheduling algorithm[J]. Journal of Changsha University, 2012(5): 72-74.
[9] B AI J. Feasibility analysis of big log?data real time search based on HBase a nd El a st ic S e a rch[C ] // 2 013 Ni nt h International Conference on Natural Computation (ICNC), January 28-31, 2013, San Diego, USA. New Jersey: IEEE Press, 2013: 1166-1170.
董長青（1980-），男，北京卡達克數(shù)據技術中心軟件業(yè)務本部高級工程師，主要研究方向為大數(shù)據、車聯(lián)網。
任女爾（1990-)，女，北京卡達克數(shù)據技術中心軟件業(yè)務本部助理工程師，主要研究方向為大數(shù)據、云計算。
張慶余（1991-)，男，北京卡達克數(shù)據技術中心軟件業(yè)務本部助理工程師，主要研究方向為軟件架構、云計算。
田玉靖（1987-)，女，北京卡達克數(shù)據技術中心軟件業(yè)務本部中級工程師，主要研究方向為軟件架構、編程模式。
總結
以上是生活随笔為你收集整理的基于HBase+ ElasticSearch的海量交通数据实时存取方案设计的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 【CyberSecurityLearni
- 下一篇： 【CyberSecurityLearni