鮮征征 葉嘉祥

摘 要：ELK架構(gòu)是解決日志分布式采集與分析問題中具有代表性的解決方案。但原生ELK架構(gòu)存在Logstash對CPU資源占用較大、無法動態(tài)更新日志相關(guān)配置和日志數(shù)據(jù)傳輸過程中數(shù)據(jù)易丟失等問題。為滿足現(xiàn)實中大型分布式服務(wù)的日志采集與分析需求，對原生ELK架構(gòu)作如下改進：在收集過程中增加限速器以減少CPU占用率;增加分布式注冊中心實現(xiàn)相關(guān)配置動態(tài)更新;增加消息隊列使得消息傳輸過程更健全。實驗結(jié)果表明，改進后的ELK日志采集及分析系統(tǒng)與原生ELK相比，CPU占用率減少了近60%，日志速度提高了3倍，且消息丟失率為零。

關(guān)鍵詞：日志采集;分布式架構(gòu);ELK;消息隊列

DOI：10. 11907/rjdk. 191790 開放科學(xué)（資源服務(wù)）標(biāo)識碼（OSID）：

中圖分類號：TP319文獻標(biāo)識碼：A 文章編號：1672-7800（2019）008-0105-06

An Improved ELK Log Collection and Analysis System

XIAN Zheng-zheng，YE Jia-xiang

（Department of Internet Finance and Information Engineering， Guang Dong University of Finance， Guangzhou 510521，China）

Abstract：ELK architecture is a representative solution to the problem of distributed log collection and analysis. However， the native ELK architecture has problems such as Logstash consuming large CPU resources， unable to dynamically update log related configuration， and has data loss during log data transmission. In order to satisfy the needs of log collection and analysis of large distributed services in reality， the paper improves the native ELK architecture as follows： speed limiter is added to reduce CPU occupancy in the collection process; distributed registry is added to update the configuration dynamically; and message queue is added to make the message transmission process more sounder. The experimental results show that compared with the original ELK， the CPU occupancy of the improved ELK log acquisition and analysis system is reduced by nearly 60%， the log speed is increased by three times， and the excellent effect of zero message loss rate is achieved.

Key Words： log collection;distributed architecture;ELK;message queue

基金項目：廣東省自然科學(xué)基金項目（2017A030313391）;廣東省科技廳國際合作項目（2017A050501042）

作者簡介：鮮征征（1977-），女，博士，廣東金融學(xué)院互聯(lián)網(wǎng)金融與信息工程學(xué)院講師，研究方向為數(shù)據(jù)挖掘、隱私保護、機器學(xué)習(xí)、軟件開發(fā)與測試;葉嘉祥（1996-），男，廣東金融學(xué)院互聯(lián)網(wǎng)金融與信息工程學(xué)院學(xué)生，研究方向為服務(wù)端開發(fā)。

0 引言

如今，互聯(lián)網(wǎng)在人們?nèi)粘Ｉ钪邪缪葜豢商娲慕巧?，?dāng)用戶在訪問、瀏覽或點擊電子商務(wù)、社交娛樂、金融保險等網(wǎng)站時，都會產(chǎn)生相應(yīng)的日志數(shù)據(jù)。這些日志數(shù)據(jù)是軟件系統(tǒng)、硬件設(shè)備和用戶行為的記錄工具，旨在及時發(fā)現(xiàn)用戶異常行為和軟硬件故障，以確保網(wǎng)站穩(wěn)定、安全運行，從而提升網(wǎng)站服務(wù)質(zhì)量[1]。對于海量小文件存儲隨服務(wù)訪問量上升的情況，大型網(wǎng)站通常在系統(tǒng)部署策略上采用分布式架構(gòu)，但這會導(dǎo)致所產(chǎn)生的日志也分散在各臺服務(wù)器中，而傳統(tǒng)對多臺服務(wù)器進行單機日志檢索的方法效率低下。由此，基于分布式架構(gòu)的日志采集與分析系統(tǒng)應(yīng)運而生，各大互聯(lián)網(wǎng)公司紛紛提出各種各樣的日志監(jiān)控平臺方案。目前主流的監(jiān)控平臺有：基于傳統(tǒng) Web 框架的監(jiān)控平臺，基于數(shù)據(jù)索引的監(jiān)控平臺和基于大數(shù)據(jù)處理框架的監(jiān)控平臺。其中，集Elasticsearch、Logstash和Kibana為一體的基于數(shù)據(jù)索引的ELK[2]開源框架，是實現(xiàn)企業(yè)通用輕量級大型日志監(jiān)控平臺的常用技術(shù)。ELK的分布式日志采集與分析系統(tǒng)可根據(jù)不同場景，結(jié)合不同的工具或中間件，靈活簡單地處理復(fù)雜日志問題，在分布式日志收集與分析領(lǐng)域得到了廣泛研究和應(yīng)用。

關(guān)于日志采集與分析技術(shù)，目前已取得一定研究成果。郝璇[3]基于Apache Flume設(shè)計并實現(xiàn)了一個適用于異構(gòu)網(wǎng)站平臺間的分布式日志收集系統(tǒng)，該系統(tǒng)雖然可以將多個網(wǎng)站的日志集中存儲，但缺少過濾和分析功能;廖湘科等[4]從日志特征分析、基于日志的故障診斷和日志增強3個方面分析了日志研究現(xiàn)狀，然后通過對幾種常用大規(guī)模開源軟件的日志進行調(diào)研，發(fā)現(xiàn)一些日志相關(guān)的特征和規(guī)律以及現(xiàn)有工具難以解決的問題;李祥池[5]針對ELK在日志傳輸過程中可能丟失的情況，進行消息隊列優(yōu)化，利用Redis、Kafka、Rockmq等消息隊列作為日志傳輸通道，達到了防止數(shù)據(jù)丟失、減緩服務(wù)器壓力的效果;陳波[6]等針對ELK的ElasticSearch離線存儲功能的性能瓶頸，進行存儲功能拓展，利用大數(shù)據(jù)工具如HBASE等分布式存儲系統(tǒng)提升日志的存儲能力;張彩云等[7]通過對ELK、Redis 進行整合，結(jié)合全國綜合氣象信息共享系統(tǒng)內(nèi)蒙古氣象局實際場景設(shè)計了ELK 日志分析平臺;姚攀等[8]針對ELK的Logstash對CPU有較大壓力等問題，提出解析日志的規(guī)則和技巧，通過對Logstash作進一步優(yōu)化，搭建能夠?qū)Ａ咳罩具M行實時采集和檢索的分析監(jiān)控系統(tǒng);湯網(wǎng)祥等[9]針對系統(tǒng)大規(guī)模部署下日志采集配置復(fù)雜、難以集中控制等問題，提出對各類源日志進行整合，并通過本地采集、網(wǎng)絡(luò)匯集、集中管控、異步分級處理等方式加以實現(xiàn);王參參等[10]根據(jù)銀行業(yè)務(wù)發(fā)展需求，提出將全網(wǎng)范圍日志分析系統(tǒng)由總行的一級中心平臺和地級市的二級分行數(shù)據(jù)采集點組成，用以解決因日志規(guī)模過大造成的省級系統(tǒng)資源過載和網(wǎng)絡(luò)堵塞等問題，但由于日志源眾多，日志類型繁雜且未對收集的日志進行過濾，最終對業(yè)務(wù)系統(tǒng)運行帶來一定影響;羅學(xué)貫[11]通過與互聯(lián)網(wǎng)行業(yè)流行的配置管理數(shù)據(jù)庫及監(jiān)控系統(tǒng)進行關(guān)聯(lián)，設(shè)計并實現(xiàn)了以ELK為基礎(chǔ)的日志分析系統(tǒng)，利用logstash 豐富的插件解決日志分析和處理難題，形成實際工作中豐富的日志字段，為重點日志增加了標(biāo)識字段，為日志分析和故障診斷提供了便捷手段;袁華[12]提出ELK與大數(shù)據(jù)處理數(shù)據(jù)技術(shù)Spark相結(jié)合，用一種隨機 key 后綴方式優(yōu)化 Spark 集群性能，從而提高集群計算效率;嚴嘉維等[13]為提高可信計算平臺日志數(shù)據(jù)分析效率，提出了一種基于Hadoop的可信計算平臺日志分析模型，將實時日志與規(guī)則庫匹配，實現(xiàn)對用戶異常行為的檢測，日志分析結(jié)果為主動防御提供了決策支持;王夢蕾[14]從網(wǎng)絡(luò)安全角度設(shè)計與實現(xiàn)了一個基于 Spark Streaming 的實時日志分析與信息管理系統(tǒng)，在發(fā)生 DDoS 攻擊時及時給予用戶警告;孫魯森[15]研究并使用Flume集群將Web應(yīng)用集群所產(chǎn)生的日志進行匯總，搭建Hadoop集群并使用其內(nèi)部組件HDFS來持久化Flume集群所匯總的日志數(shù)據(jù)，可以對網(wǎng)站的多維度Page View、訪客來源統(tǒng)計、用戶關(guān)鍵路徑轉(zhuǎn)化進行多維度且詳細的數(shù)據(jù)分析。但該研究與文獻[13]都是基于Flume平臺，F(xiàn)lume自身比較繁瑣，與ELK相比，它主要側(cè)重于數(shù)據(jù)傳輸而非采集。隨著容器虛擬化技術(shù)的進步與推廣，主流的服務(wù)部署均掛載在宿主機的虛擬容器里，如Docker[16]，但是容器會根據(jù)不同的策略分布與漂移，這樣會導(dǎo)致日志過于分散。因此，基于如Kubernetes[17]容器編排管理的大型日志收集系統(tǒng)相關(guān)研究受到關(guān)注。

針對現(xiàn)實中的復(fù)雜場景，以上方法都未從原生ELK架構(gòu)自身缺點出發(fā)，原生ELK架構(gòu)存在服務(wù)器處理效率低下、Logstash對CPU資源占用過多、可擴展性差、無法動態(tài)更新日志相關(guān)配置和日志數(shù)據(jù)傳輸過程中數(shù)據(jù)易丟失等問題。本文通過使用Etcd搭建配置中心集群，使用Gin框架與Nginx實現(xiàn)日志產(chǎn)生器，模擬分布式系統(tǒng)下產(chǎn)生日志，使用Vue.js搭建前端，提出對收集模塊和轉(zhuǎn)發(fā)模塊的改進方案，即實時收集產(chǎn)生的日志，同時能限制日志收集頻率，從而替代ELK框架中的Logstash，達到減少CPU壓力的目的;還使用Kafka與Zookeeper搭建一個消息隊列集群，將收集到的日志發(fā)送至消息隊列中，達到削峰、保證消息健全的作用，并用go語言實現(xiàn)轉(zhuǎn)發(fā)模塊，從消息隊列中拉取日志;最后使用Elasticsearch與Kibana構(gòu)建日志存儲與展示模塊，向用戶提供強大的日志搜索與分析功能。本文基于ELK、Kafka與Etcd等技術(shù)，通過對ELK的改進，彌補了原生ELK在大型分布式業(yè)務(wù)系統(tǒng)中不能直接使用的缺陷，設(shè)計并實現(xiàn)了一個日志健全、配置便捷、性能更高效的分布式日志采集與分析系統(tǒng)。

1 系統(tǒng)設(shè)計

1.1 系統(tǒng)業(yè)務(wù)架構(gòu)設(shè)計

系統(tǒng)分為四大模塊，分別是系統(tǒng)入口模塊、日志收集模塊、日志轉(zhuǎn)發(fā)模塊和日志展示模塊，如圖1所示。

圖1 系統(tǒng)業(yè)務(wù)架構(gòu)

圖1中，其核心關(guān)注點在于日志收集模塊和日志轉(zhuǎn)發(fā)模塊的消息健全、高性能以及高可用設(shè)計。系統(tǒng)入口模塊直接對終端設(shè)備提供服務(wù)，同時入口模塊通過調(diào)用http服務(wù)生成日志、配置文件等;日志收集模塊主要是獲取配置中心上的路徑配置，對特定日志進行收集，并發(fā)送到消息隊列中;日志轉(zhuǎn)發(fā)模塊主要是獲取配置中心上的主題配置，對特定主題的日志進行過濾接收，并發(fā)送至ElasticSearch;日志展示模塊主要對日志進行搜索、分析和展示。

1.2 系統(tǒng)執(zhí)行時序分析

系統(tǒng)業(yè)務(wù)在執(zhí)行過程中是按照一定的時序進行，圖2展示了本系統(tǒng)的業(yè)務(wù)執(zhí)行時序。

圖2 系統(tǒng)執(zhí)行時序圖

圖2中，Logweb服務(wù)是系統(tǒng)入口模塊，產(chǎn)生日志;Logagent是日志收集模塊，對產(chǎn)生的日志進行收集，并將消息推送到kafka消息隊列;Logtransfer是日志轉(zhuǎn)發(fā)模塊，將從Kafka拉取的日志消息推送到ElasticSearch，并且通過Kibana進行日志分析與展示。

1.3 系統(tǒng)物理架構(gòu)設(shè)計

原生的ELK架構(gòu)中沒有嵌入消息中間件、配置中心等內(nèi)容，因此，只適合日志量較少、業(yè)務(wù)簡單的系統(tǒng)。隨著業(yè)務(wù)逐漸復(fù)雜，ELK原生架構(gòu)已不能支撐龐大復(fù)雜的日志信息。因此，需要設(shè)計一個適合分布式系統(tǒng)的日志采集與分析系統(tǒng)，并考慮消息隊列集群及應(yīng)用集群。本系統(tǒng)針對此種場景，從分布式系統(tǒng)、高可用集群方面入手，對原生ELK架構(gòu)進行改進。系統(tǒng)物理架構(gòu)如圖3所示。

圖3 系統(tǒng)物理架構(gòu)

圖3中，Web端的http請求首先會經(jīng)過Nginx負載均衡，轉(zhuǎn)發(fā)到服務(wù)器集群中1～3號服務(wù)器中的任意一臺;服務(wù)器集群中的日志收集器，會通過Etcd集群中的配置路徑，進行日志收集，然后將日志推送到Kafka集群;而Kafka集群之間的聯(lián)系是靠Zookeeper集群進行服務(wù)注冊與發(fā)現(xiàn);日志轉(zhuǎn)發(fā)器通過Etcd集群中的主題配置，從Kafka集群中選擇相關(guān)主題的日志，拉取到服務(wù)器集群中;最后日志將發(fā)送至ElasticSearch，通過Kibana連接ElasticSearch獲取日志，進行日志展示與分析。

其中，日志消息隊列Kafka的高可用與消息健全性尤為重要，其集群架構(gòu)如圖4所示。

圖4 消息隊列集群架構(gòu)

圖4中，product是生產(chǎn)者，它從Zookeeper注冊中心獲取到Kafka集群的地址，然后將產(chǎn)生的消息發(fā)送至Kafka集群，而Kafka集群事先需要將自己本身的地址注冊到Zookeeper集群，并且保持心跳檢測，才能被生產(chǎn)者、消費者發(fā)現(xiàn);consumer是消費者，同理，它也從Zookeeper注冊中心獲取到Kafka集群的地址，然后去Kafka集群拉取消息。本系統(tǒng)的生產(chǎn)者指日志收集器，它將收集的日志發(fā)送至Kafka中，消費者是指日志轉(zhuǎn)發(fā)器，將日志從Kafka中拉取下來。

2 系統(tǒng)功能模塊

2.1 系統(tǒng)入口模塊

系統(tǒng)入口模塊主要作用是配置收集規(guī)則、產(chǎn)生日志，用Nginx與Gin框架搭建，對外開放http接口，網(wǎng)頁端可以通過調(diào)用相關(guān)接口，完成該功能。Nginx在本系統(tǒng)中的作用是作為業(yè)務(wù)應(yīng)用服務(wù)器集群的負載均衡器，應(yīng)用服務(wù)器集群架構(gòu)如圖5所示。圖5中，所有服務(wù)器都處理相同業(yè)務(wù)，所有請求經(jīng)Nginx轉(zhuǎn)發(fā)到不同的服務(wù)器中。如果集群中的一個服務(wù)器發(fā)生故障，則Nginx能夠迅速將該系統(tǒng)的任務(wù)轉(zhuǎn)發(fā)到集群中其它正常工作的服務(wù)器上進行處理。業(yè)務(wù)具體處理則是用Gin框架支撐，大致分為兩個步驟：①配置收集規(guī)則、收集路徑等，主要完成對日志文件位置、日志主題過濾等功能模塊配置;②模擬生產(chǎn)環(huán)境下的日志產(chǎn)生過程。

圖5 應(yīng)用服務(wù)器集群架構(gòu)

2.2 日志收集模塊

該模塊中日志收集器根據(jù)規(guī)則收集日志，并將日志發(fā)送到消息隊列中，包括收集器、限速器和推送子模塊。收集器和限速器主要根據(jù)配置規(guī)則收集相關(guān)日志，并配置特定的發(fā)送頻率，達到限速目的，其UML設(shè)計如圖6所示。

圖6 收集器與限速UMl設(shè)計

圖6中，日志收集器模塊分別由TailManager類（用作管理收集日志）、CollectObj類（實現(xiàn)日志收集器）、LogConfig類（實現(xiàn)日志配置）、Limit類（解決日志限速）4個類構(gòu)成。

推送子模塊負責(zé)將收集的日志推送到kafka消息隊列中，其UML圖設(shè)計如圖7所示。該模塊功能實現(xiàn)包括Message和Sender兩個類。前者定義日志消息，后者解決日志消息推送。

圖11 日志轉(zhuǎn)發(fā)結(jié)果

4.2.4 日志搜索和分析

當(dāng)日志成功收集后，需對這些日志數(shù)據(jù)進行搜索和分析，其結(jié)果如圖12所示。柱狀圖表示每秒鐘收集到的日志，其下是按時間先后順序排列的日志數(shù)據(jù)，默認情況下是全量顯示，若需要搜索特定規(guī)則的日志，可以通過搜索欄進行搜索匹配。

圖12 日志展示效果

通過上述實驗，系統(tǒng)可以完成收集、轉(zhuǎn)發(fā)和展示分析等功能，體現(xiàn)了其強大的分布式日志采集與分析能力。

4.3 對比實驗

在同樣的實驗環(huán)境下，針對同一實驗對象，將改進后的系統(tǒng)與原生ELK在性能方面作對比實驗。

較原生ELK而言，改進后的系統(tǒng)優(yōu)勢主要體現(xiàn)在日志收集時多項性能的提升。具體壓測方案設(shè)計如下：

（1）壓測環(huán)境：Core i5-4200H處理器，8G內(nèi)存，1T硬盤。

（2）Logstash / Logagent 讀取 500 000條日志，單行數(shù)據(jù) 500B。

（3）壓測實驗一：正常收集日志數(shù)據(jù)，統(tǒng)計CPU平均占用率、總耗時和收集速度，結(jié)果如表1所示。

（4）壓測實驗二：在收集日志數(shù)據(jù)時，人工對網(wǎng)絡(luò)進行實驗性阻斷，產(chǎn)生網(wǎng)絡(luò)抖動，統(tǒng)計消息丟失數(shù)和丟失率，結(jié)果如表2所示。

表1 壓測實驗一結(jié)果

表2 壓測實驗二結(jié)果

從表1可看出，原生ELK系統(tǒng)中Logstash CPU占用率高達75.6%，而改進后的收集器 CPU占用率降低到44.8%，且收集速度為原生ELK的3倍。從實驗結(jié)果來看，改進后的系統(tǒng)解決了原生ELK中Logstash對CPU資源消耗問題，且提升了日志收集速度與系統(tǒng)的穩(wěn)定性。

從表2可以看出，在產(chǎn)生網(wǎng)絡(luò)抖動時，原生ELK系統(tǒng)會丟失一些數(shù)據(jù)，500 000條消息丟失了698條，消息丟失率達0.14%，改進后的日志收集系統(tǒng)，500 000條消息丟失0條，消息丟失率為0。從實驗結(jié)果來看，改進后的系統(tǒng)解決了原生系統(tǒng)日志消息容易丟失的問題，顯著提高了日志收集過程中消息的健全性。

5 結(jié)語

隨著云計算、物聯(lián)網(wǎng)技術(shù)的迅速發(fā)展，數(shù)據(jù)已呈爆炸式增長，人們進入大數(shù)據(jù)時代[19]。而對于Web日志數(shù)據(jù)量的增加，文件的分布式存儲和數(shù)據(jù)挖掘技術(shù)也成為Web日志挖掘研究領(lǐng)域的重點分支[20]。因此，日志的采集和分析將是其研究的重要支撐。

本文系統(tǒng)主要著眼于日志系統(tǒng)的簡易實用性、高可用性與日志的健全性。簡易實用性的實現(xiàn)途徑主要是：可配置的Web管理后臺、簡易操作的搜索與分析Web頁面等;高可用性的實現(xiàn)途徑主要是：分布式、集群、負載均衡、限流等;日志的健全性實現(xiàn)途徑主要是：消息隊列、注冊中心等。

下一步工作將關(guān)注兩個問題：一是將日志收集與分析系統(tǒng)整合到Docker容器，并且用Kubernetes進行管理編排，這樣能極大方便開發(fā)者和運維者，后續(xù)迭代開發(fā)也具有敏捷性;二是改進現(xiàn)有系統(tǒng)，增加分布式鏈路追蹤系統(tǒng)，以獲得服務(wù)之間調(diào)用的耗時、吞吐量、是否故障等信息，從而為運維和監(jiān)控提供更好的參考。

參考文獻：

[1]? 應(yīng)毅，任凱，劉亞軍.? 基于大數(shù)據(jù)的網(wǎng)絡(luò)日志分析技術(shù)[J]. 計算機科學(xué)， 2018， 45（11A）： 353-355.

[2]? 高凱. 大數(shù)據(jù)搜索與日志挖掘及可視化方案—ELK Stack：Elasticsearch、Logstash、Kibana[M]. 第2版. 北京：清華大學(xué)出版社，2016.

[3]? 郝璇. 基于Apache Flume的分布式日志收集系統(tǒng)設(shè)計與實現(xiàn)[J].? 軟件導(dǎo)刊，2014，13（7）：110-111.

[4]? 廖湘科，李姍姍，董威，等. 大規(guī)模軟件系統(tǒng)日志研究綜述[J]. 軟件學(xué)報，2016，27（8）：1934-1947.

[5]? 李祥池. 基于ELK和Spark Streaming的日志分析系統(tǒng)設(shè)計與實現(xiàn)[J]. 電子科學(xué)技術(shù)，2015，6（2） 674-678.

[6]? 陳波. 基于 HBASE 分布式存儲的通用海量日志系統(tǒng)設(shè)計方法研究[J]. 信息通信， 2017（6）： 7-9.

[7]? 張彩云，牛永紅，趙迦琪.? ELK日志分析平臺在系統(tǒng)運維中的應(yīng)用[J]. 電子技術(shù)與軟件工程，2017（6）： 182-183.

[8]? 姚攀，馬玉鵬，徐春香，等. 基于ELK的日志分析系統(tǒng)研究及應(yīng)用 [J].? 計算機工程與設(shè)計， 2018， 39（7）：2090-2095.

[9]? 湯網(wǎng)祥，王金華，赫凌俊，等.? 大規(guī)模軟件系統(tǒng)日志匯集服務(wù)平臺設(shè)計與實現(xiàn) [J]. 計算機工程與設(shè)計， 2018， 35（11）：173-178.

[10] 王參參，姜青云，李彤.? 基于大數(shù)據(jù)的日志分析平臺在銀行中的研究與實現(xiàn) [J].? 網(wǎng)絡(luò)安全技術(shù)與應(yīng)用， 2018（5）： 68-70.

[11] 羅學(xué)貫.? 基于ELK的Web日志分析系統(tǒng)的設(shè)計與實現(xiàn)[D]. 廣州： 華南理工大學(xué)， 2018.

[12] 袁華.? 基于ELK和Spark的日志分析系統(tǒng)的研究與實現(xiàn)[D]. 南昌： 南昌大學(xué)， 2018.

[13] 嚴嘉維， 張琛. 基于Hadoop的可信計算平臺日志分析模型[J].? 軟件導(dǎo)刊，2018，7（8）： 71-75.

[14] 王夢蕾. 基于Spark Streaming的實時日志分析與信息管理系統(tǒng)的設(shè)計與實現(xiàn)[D].? 哈爾濱： 哈爾濱工業(yè)大學(xué)， 2018.

[15] 孫魯森.? 基于分布式Web應(yīng)用的大數(shù)據(jù)日志分析方法研究 [J].? 電腦知識與技術(shù)， 2019， 15（3）： 16-19.

[16] BOETTIGER C. An introduction to docker for reproducible research [J].? ACM SIGOPS Operating Systems Review-Special Issue on Repeatability and Sharing of Experimental Artifacts，2015，49（1）：71-79.

[17] BERNSTEIN D.Containers and cloud： from LXC to docker to kubernetes[J].? IEEE Cloud Computing， 2014， 1（3）： 81-84.

[18] DIEGO ONGARO， JOHN OUSTERHOUT. In search of an understandable consensus algorithm[C]. In Proc ATC14， USENIX Annual Technical Conference，2014.

[19] 孟小峰，慈祥.? 大數(shù)據(jù)管理：概念·技術(shù)與挑戰(zhàn) [J].? 計算機研究與發(fā)展， 2013，50（1）： 146-169.

[20] 班秋成. 基于Hadoop的Web日志存儲和分析系統(tǒng)的研究與實現(xiàn)[D]. 北京： 北京郵電大學(xué)， 2018.

（責(zé)任編輯：孫 娟）