吳 超

江蘇省通信管理局

0 引言

大數(shù)據(jù)時(shí)代，如何才能從豐富的數(shù)據(jù)礦藏中開采出更多價(jià)值？以石油開采來類比大數(shù)據(jù)分析，首先考慮的不是如何煉油（分析數(shù)據(jù)），而是如何獲取優(yōu)質(zhì)原油（高效地采集與存儲(chǔ)數(shù)據(jù)）。

本文圍繞三個(gè)問題展開：在大數(shù)據(jù)環(huán)境下，傳統(tǒng)的數(shù)據(jù)采集、存儲(chǔ)方式還適用嗎？現(xiàn)有哪些優(yōu)質(zhì)高效有前途的技術(shù)方案？我們?cè)撊绾芜x擇？

1 大數(shù)據(jù)的挑戰(zhàn)

數(shù)據(jù)采集方面，傳統(tǒng)工具有ftp、scp、rsync、wget、curl等，它們通常源于少量主機(jī)之間的文件傳輸或同步的業(yè)務(wù)需求，雖然在斷點(diǎn)續(xù)傳、壓縮傳輸或者自動(dòng)同步等方面有一定造詣，但這些基于抽樣分析的方法采集海量數(shù)據(jù)時(shí)如同“在汽車時(shí)代騎馬一樣”，效率、性能低下，不能滿足業(yè)務(wù)需求。

數(shù)據(jù)存儲(chǔ)方面，傳統(tǒng)文件系統(tǒng)適應(yīng)不了紛繁的數(shù)據(jù)類型，同時(shí)關(guān)系型數(shù)據(jù)庫執(zhí)迷于精確的ACID屬性，導(dǎo)致大量非結(jié)構(gòu)化、混雜的數(shù)據(jù)被丟棄，無法利用。

綜上，傳統(tǒng)的以技術(shù)為中心的數(shù)據(jù)處理方式已不能滿足業(yè)務(wù)需求。為了實(shí)現(xiàn)對(duì)海量數(shù)據(jù)的分布采集、高效存儲(chǔ)、交互查詢、實(shí)時(shí)分析、深度挖掘等功能，需要采取以數(shù)據(jù)為中心的新方案。

2 新技術(shù)的應(yīng)用

根據(jù)信息通信行業(yè)咨詢翹楚Gartner公司近年來發(fā)布的新興技術(shù)成熟度曲線，業(yè)界對(duì)大數(shù)據(jù)概念的炒作已進(jìn)入尾聲，大數(shù)據(jù)技術(shù)正在走向“成熟”階段。

開源社區(qū)、商業(yè)公司、學(xué)術(shù)界、極客們圍繞著數(shù)據(jù)處理提出了種類繁多的解決方案，并站在自己立場(chǎng)上，對(duì)技術(shù)方案發(fā)表了各種聲音的爭(zhēng)論?；谲浻布顿Y、學(xué)習(xí)成本的考量，我們希望采用“廉價(jià)的”“有前途”的技術(shù)方案；根據(jù)開源“圣經(jīng)”《大教堂與集市》中經(jīng)典理論，“如果有足夠多的beta測(cè)試者和合作開發(fā)者，幾乎所有問題都會(huì)很快顯現(xiàn)，然后自然有人會(huì)把它解決”；參考業(yè)界實(shí)踐派專家的觀點(diǎn)，新技術(shù)興衰是社區(qū)、企業(yè)、用戶之間“戰(zhàn)略、利益、技術(shù)、實(shí)踐”綜合較量的結(jié)果。

基于以上三點(diǎn)，為了全面、發(fā)展地看待各方案，首先站在用戶、開發(fā)者、外圍支持者的視角，從用戶規(guī)模、技術(shù)水平、兼容性三個(gè)維度，對(duì)備選技術(shù)進(jìn)行生態(tài)評(píng)估；然后篩選出使用廣泛、開發(fā)活躍、兼容性好的方案進(jìn)行技術(shù)介紹；最后在方案對(duì)比的基礎(chǔ)上，結(jié)合應(yīng)用場(chǎng)景提出相關(guān)建議。

2.1 分布采集方案

目前常見的大數(shù)據(jù)采集技術(shù)包括Flume、Kafka、Splunk Forwarder、Logstash、Fluentd、Chukwa、Scribe等，我們?cè)撊绾稳∩幔?/p>

（1）生態(tài)評(píng)估

對(duì)上述技術(shù)生態(tài)進(jìn)行評(píng)估如表1所示。

（2）技術(shù)對(duì)比

根據(jù)上述評(píng)估，我們選取Flume、Kafka兩種優(yōu)秀的方案，在技術(shù)分析的基礎(chǔ)上，對(duì)適用場(chǎng)景及優(yōu)缺點(diǎn)進(jìn)行深入分析。

Flume是Apache社區(qū)中一款可高效收集、聚合、移動(dòng)海量日志數(shù)據(jù)的工具。不同數(shù)據(jù)源的數(shù)據(jù)“原油”流經(jīng)Flume這個(gè)“水槽”（Flume單詞的原義），最后匯入數(shù)據(jù)存儲(chǔ)系統(tǒng)中。Flume工具部署、維護(hù)簡(jiǎn)單，可根據(jù)業(yè)務(wù)需求進(jìn)行靈活擴(kuò)展。

Kafka是一個(gè)分布式的消息“發(fā)布—訂閱”系統(tǒng)，它作為消息生產(chǎn)者與消費(fèi)者之間的代理人（broker）解耦了這兩個(gè)角色，實(shí)現(xiàn)了消息的高效“按需供給”。Kafka 被廣泛用于采集網(wǎng)頁訪問量、網(wǎng)頁內(nèi)容等活動(dòng)數(shù)據(jù)以及服務(wù)器CPU 使用率、服務(wù)日志等運(yùn)營數(shù)據(jù)。

功能方面，上述兩種方案都比較成熟，詳細(xì)比較見表2。

表2 備選采集方案功能對(duì)比

性能方面，數(shù)據(jù)采集屬于“I/O密集型”業(yè)務(wù)，即相比與CPU、內(nèi)存、網(wǎng)絡(luò)流量等因素，系統(tǒng)I/O受限于低效的磁盤隨機(jī)讀寫物理性能，更易成為整個(gè)采集系統(tǒng)吞吐率的性能瓶頸。Kafka、Flume均支持在內(nèi)存中進(jìn)行數(shù)據(jù)傳輸，此時(shí)兩者性能都極高。下面僅討論當(dāng)數(shù)據(jù)規(guī)模超過集群內(nèi)存容量，需要進(jìn)行大量磁盤讀寫操作時(shí)的場(chǎng)景：（A）Kafka精妙的設(shè)計(jì)保證其進(jìn)行高效的順序讀寫操作，在到達(dá)磁盤物理性能瓶頸之前，寫磁盤平均速率隨著輸入數(shù)據(jù)吞吐率的增加線性增長(zhǎng)；（B）Flume在實(shí)時(shí)性、吞吐率上比Kafka遜色不少，但可通過調(diào)整批量處理參數(shù)（Batch Size），以增加時(shí)延的代價(jià)，一定程度上提高吞吐率；（C）兩者都支持通過增加硬件數(shù)量的橫向擴(kuò)展方式，提高系統(tǒng)吞吐率。

（3）應(yīng)用建議

方案選型時(shí)，需綜合考慮業(yè)務(wù)需求、預(yù)算經(jīng)費(fèi)、自身技術(shù)等因素：（A）當(dāng)僅需要對(duì)服務(wù)器訪問記錄、網(wǎng)絡(luò)設(shè)備告警等運(yùn)維數(shù)據(jù)進(jìn)行采集、分析時(shí)，預(yù)算充裕的用戶推薦Splunk、Datadog等一站式商業(yè)解決方案；有一定技術(shù)基礎(chǔ)、想節(jié)約預(yù)算的用戶可考慮Flume、Logstash；（B）當(dāng)數(shù)據(jù)源既有日志數(shù)據(jù)又有流數(shù)據(jù)，從方便運(yùn)維、擴(kuò)容的角度，建議使用Flume；（C）如果采集數(shù)據(jù)將被多個(gè)業(yè)務(wù)系統(tǒng)使用、業(yè)務(wù)實(shí)時(shí)性要求很高或者需要錯(cuò)峰、流控時(shí)，建議使用Kafka；（D）Kafka與Flume也常?！皬?qiáng)強(qiáng)聯(lián)合”：一種典型應(yīng)用將Kafka作為數(shù)據(jù)源，F(xiàn)lume作為采集代理；此外也可以先部署Flume1.6.0版本采集數(shù)據(jù)，今后業(yè)務(wù)有實(shí)時(shí)性要求時(shí)，將Kafka作為一種傳輸渠道（channel），把采集后數(shù)據(jù)匯入下游存儲(chǔ)系統(tǒng)；此外還可以將Flume采集的數(shù)據(jù)存入Kafka主題中供業(yè)務(wù)程序拉取。

具體部署時(shí)，需要權(quán)衡高吞吐與低時(shí)延、容錯(cuò)性與冗余性這兩對(duì)矛盾。例如，通過數(shù)據(jù)壓縮傳輸、分批次傳輸?shù)姆椒ǎ栽黾訒r(shí)延的代價(jià)，降低對(duì)系統(tǒng)網(wǎng)絡(luò)、I/O等資源的消耗。此外，數(shù)據(jù)采集過程中也可以嘗試發(fā)揮人的作用，例如為準(zhǔn)確、及時(shí)地采集宏觀經(jīng)濟(jì)數(shù)據(jù)，Premise公司采用線上線下相結(jié)合的方式。其中線下部分鼓勵(lì)大眾貢獻(xiàn)各種價(jià)格數(shù)據(jù)，這種眾包方式受到資本青睞。

2.2 高效存儲(chǔ)方案

對(duì)海量數(shù)據(jù)采集、清洗后，我們既要確定采用什么方式將數(shù)據(jù)長(zhǎng)期保存起來，又要考慮以哪種方案組織管理數(shù)據(jù)以及供業(yè)務(wù)查詢使用，還得權(quán)衡是否需要以內(nèi)存存儲(chǔ)、管理來提高性能。下文將分別對(duì)大數(shù)據(jù)存儲(chǔ)系統(tǒng)、數(shù)據(jù)庫技術(shù)方案進(jìn)行評(píng)估比較。

（1）生態(tài)評(píng)估

大數(shù)據(jù)存儲(chǔ)系統(tǒng)多得令人眼花繚亂，既有云服務(wù)商Amazon的 S3、老牌存儲(chǔ)服務(wù)商EMC的系列產(chǎn)品和解決方案，又含開源社區(qū)的HDFS、Swift、Ceph，還包括高校孵化出的Alluxio。對(duì)這些技術(shù)生態(tài)進(jìn)行評(píng)估如表3所示。

表3 大數(shù)據(jù)存儲(chǔ)系統(tǒng)生態(tài)評(píng)估

技術(shù)方案 用戶規(guī)模 技術(shù)水平 兼容性星級(jí) ★★★★★C e p h 理由概述項(xiàng)目開源早（2006年），但穩(wěn)定較慢（2012年才發(fā)布第一個(gè)穩(wěn)定大版本），現(xiàn)由R e d H a t主推；架構(gòu)有特色，獨(dú)一無二地同時(shí)支持文件、對(duì)象、塊存儲(chǔ)；使用靈活，易于擴(kuò)展；項(xiàng)目長(zhǎng)期不夠穩(wěn)定，缺少大規(guī)模應(yīng)用案例，用戶觀望多使用少。社區(qū)被紅帽公司把持；代碼難懂、耦合過高，質(zhì)量廣受爭(zhēng)議；成功案例少，待實(shí)踐驗(yàn)證完善?？?兼 容A W S、O p e n S t a c k生態(tài)組件；合入L i n u x 2.6.34內(nèi)核；站在“軟件定義存儲(chǔ)”、“超融合”概念風(fēng)口。星級(jí) ★★★★ ★★★A l l u x i o 理由概述2013年誕生于A M P L a b（原名T a c h y o n），是S p a r k同門師弟，基因優(yōu)秀；定位明確，就是為了將海量數(shù)據(jù)從計(jì)算模型中抽象獨(dú)立出來；得益于S p a r k生態(tài)圈壯大、內(nèi)存和S S D變得便宜，正迅速崛起。性能優(yōu)秀；有經(jīng)典案例參考；比較年輕，部分輔助功能待改進(jìn)。完善兼 容 H D F S、S 3、S w i f t等底層存儲(chǔ)系統(tǒng)， 及 M R、S p a r k等上層計(jì)算框架。

大數(shù)據(jù)數(shù)據(jù)庫技術(shù)外延更廣。按適用業(yè)務(wù)場(chǎng)景分為事務(wù)型（追求高效讀寫的事務(wù)處理能力）、分析型（追求高吞吐、高擴(kuò)展能力）、兼顧型；按數(shù)據(jù)存儲(chǔ)模型主要包含關(guān)系型、鍵值對(duì)型、面向列的、面向文檔、圖形數(shù)據(jù)庫；按設(shè)計(jì)原則又分為ACID、C/A/P三選二、兼顧型。典型的大數(shù)據(jù)數(shù)據(jù)庫演進(jìn)及分類如表4所示。

表4 常見大數(shù)據(jù)數(shù)據(jù)庫分類

根據(jù)上表分類，將選擇具有代表性的擴(kuò)展MySQL、HBase、Cassandra、MongoDB、Redis、Kudu進(jìn)行生態(tài)進(jìn)行評(píng)估，詳見表5。

表5 大數(shù)據(jù)數(shù)據(jù)庫技術(shù)生態(tài)評(píng)估

（2）技術(shù)對(duì)比

根據(jù)上述評(píng)估，將選取S3、HDFS、Alluxio、HBase幾種優(yōu)秀的方案進(jìn)行詳述。

S3是Amazon公司AWS云存儲(chǔ)服務(wù)的重要組成部分，是對(duì)象存儲(chǔ)的典型代表。S3采用扁平的數(shù)據(jù)組織結(jié)構(gòu)，將對(duì)象數(shù)據(jù)保存在“存儲(chǔ)桶”（Bucket）中，并給用戶提供基于HTTP的REST風(fēng)格數(shù)據(jù)訪問、操作接口。該存儲(chǔ)形態(tài)能夠方便地進(jìn)行橫向擴(kuò)展，以適應(yīng)大量用戶高并發(fā)訪問的場(chǎng)景；但是不支持隨機(jī)位置讀寫操作，只能讀取、寫入或覆蓋整個(gè)文件。

HDFS起源于Google的GFS論文，是一種易于擴(kuò)展的分布式文件系統(tǒng)。HDFS基于“移動(dòng)計(jì)算比移動(dòng)數(shù)據(jù)更經(jīng)濟(jì)”的設(shè)計(jì)理念，可構(gòu)建在大量廉價(jià)機(jī)器上，節(jié)約大量建設(shè)擴(kuò)容投資；另一方面，其具備可靠數(shù)據(jù)容錯(cuò)能力，有效減少運(yùn)營維護(hù)成本。HDFS伴隨著Hadoop生態(tài)圈的壯大不斷完善，目前已支持Parquet存儲(chǔ)格式，可對(duì)嵌套數(shù)據(jù)進(jìn)行高效列式存儲(chǔ)，即將合入ErasureCoding糾錯(cuò)編碼使冷數(shù)據(jù)冗余成本大幅減少。

HBase起源于Google的BigTable論文，是構(gòu)建在HDFS之上高性能、高可靠、易擴(kuò)展的大數(shù)據(jù)列族式存儲(chǔ)數(shù)據(jù)庫。其適合存儲(chǔ)海量稀疏數(shù)據(jù)，可以通過版本檢索到歷史數(shù)據(jù)，解決了HDFS不支持?jǐn)?shù)據(jù)隨機(jī)查找、不適合增量數(shù)據(jù)處理、不支持?jǐn)?shù)據(jù)更新等問題。常用于存儲(chǔ)超大規(guī)模的實(shí)時(shí)隨機(jī)讀寫數(shù)據(jù)，如存儲(chǔ)互聯(lián)網(wǎng)搜索引擎數(shù)據(jù)。

Alluxio原名Tachyon，是以內(nèi)存為中心的虛擬分布式存儲(chǔ)系統(tǒng)。其核心思想是將存儲(chǔ)與計(jì)算分離。Alluxio介于底層存儲(chǔ)系統(tǒng)（如HDFS、Amazon S3、OpenStackSwift）與上層計(jì)算框架（如Spark、MapReduce、Apache Flink）分離，使Spark等框架更專注于計(jì)算，從而達(dá)到更高的執(zhí)行效率。

上述四種大數(shù)據(jù)存儲(chǔ)方案詳細(xì)比較如表6所示。

表6 數(shù)據(jù)存儲(chǔ)方案比較

（3）應(yīng)用建議

方案選型時(shí)，首先需要綜合考慮業(yè)務(wù)需求變化、原始數(shù)據(jù)規(guī)模、實(shí)時(shí)分析需求、存儲(chǔ)周期、軟硬件開發(fā)及運(yùn)維成本等因素，再進(jìn)一步明確存儲(chǔ)方案：（A）對(duì)業(yè)務(wù)中斷時(shí)間、業(yè)務(wù)恢復(fù)時(shí)長(zhǎng)、數(shù)據(jù)一致性要求都極高的金融等行業(yè)，可根據(jù)業(yè)務(wù)量考慮購買EMC、IBM等廠商的存儲(chǔ)軟硬件產(chǎn)品，在此基礎(chǔ)上選擇Teradata、IBM的方案做進(jìn)一步數(shù)據(jù)挖掘；（B）對(duì)于啟動(dòng)資金有限、需求靈活多變、規(guī)模可能激增的創(chuàng)業(yè)公司，建議以“輕資產(chǎn)”的方式運(yùn)營。可購買Amazon、微軟、阿里等的云服務(wù)，集中精力進(jìn)行業(yè)務(wù)開發(fā)和市場(chǎng)推廣；（C）對(duì)于TB數(shù)據(jù)級(jí)別數(shù)據(jù)，一致性要求不高并且需要進(jìn)行實(shí)時(shí)查詢的場(chǎng)景可考慮Redis，一致性高且追求高吞吐量的場(chǎng)景可考慮GemFire。不建議用低性能的CouchBase、Memcached；（D）對(duì)于PB數(shù)量級(jí)存儲(chǔ)、計(jì)算、虛擬化服務(wù)提供商，建議搭建自己的OpenStack環(huán)境，采用Swift、Cinder等存儲(chǔ)方案，以快速滿足定制化需求；（E）對(duì)于PB—ZB級(jí)別歷史數(shù)據(jù)、需要進(jìn)行關(guān)聯(lián)查詢、批量計(jì)算的業(yè)務(wù)場(chǎng)景，建議搭建Hadoop環(huán)境，采用HDFS存儲(chǔ)方案;（F）對(duì)于PB級(jí)別數(shù)據(jù)、追求低延遲隨機(jī)讀寫的場(chǎng)景，例如對(duì)海量網(wǎng)頁數(shù)據(jù)做進(jìn)一步提取、修改的，建議采用HBase數(shù)據(jù)庫。非專家級(jí)用戶不推薦在生產(chǎn)環(huán)境使用Kudu、Kylin等新興方案。

在此基礎(chǔ)上，根據(jù)業(yè)務(wù)場(chǎng)景進(jìn)一步選擇合適的存儲(chǔ)模式：（A）如果業(yè)務(wù)首要考慮數(shù)據(jù)完整性與可靠性，行存儲(chǔ)具備了天然的優(yōu)勢(shì)，列存儲(chǔ)只有增加磁盤并改進(jìn)軟件后才能接近該目標(biāo)；（B）以長(zhǎng)期保存數(shù)據(jù)為主的應(yīng)用，可考慮寫入性能較高的行存儲(chǔ)模式；（C）需要對(duì)大數(shù)據(jù)做深入挖掘分析的場(chǎng)景，特別是數(shù)據(jù)源為扁平的關(guān)系型數(shù)據(jù)或者復(fù)雜的嵌套數(shù)據(jù)時(shí)，建議使用讀取性能優(yōu)秀的列式存儲(chǔ)。

具體部署時(shí)，可根據(jù)自身預(yù)算水平、技術(shù)能力，選擇服務(wù)商一攬子解決方案，集成商負(fù)責(zé)建設(shè)維保，利用開源框架自建自維，在開源代碼基礎(chǔ)上自主開發(fā)等建設(shè)與維護(hù)模式。

3 小結(jié)與展望

本文回顧了主流的大數(shù)據(jù)采集與存儲(chǔ)技術(shù)誕生、發(fā)展、對(duì)抗、衰落的歷史，梳理了其中老牌的商業(yè)公司、初創(chuàng)的明星企業(yè)、大小的開源社區(qū)、學(xué)術(shù)界、極客之間的糾葛與合作，從生態(tài)角度進(jìn)行了宏觀對(duì)比與評(píng)估；同時(shí)本文選取優(yōu)秀、通用的方案進(jìn)行了較詳盡的介紹，并結(jié)合具體應(yīng)用場(chǎng)景給出了技術(shù)選型及應(yīng)用部署的相關(guān)建議。

展望未來，物聯(lián)網(wǎng)、智能制造等新興產(chǎn)業(yè)的崛起，將提供更大規(guī)模、更多類型的海量數(shù)據(jù)源，大數(shù)據(jù)采集方案將結(jié)合更廉價(jià)的采集設(shè)備、更靈活的組網(wǎng)部署、更有效的數(shù)據(jù)清洗；同時(shí)隨著內(nèi)存、SSD等高效存儲(chǔ)介質(zhì)的性能提升，內(nèi)存存儲(chǔ)技術(shù)將進(jìn)一步發(fā)展與普及；業(yè)務(wù)形態(tài)方面，大數(shù)據(jù)技術(shù)將與商業(yè)智能、機(jī)器學(xué)習(xí)等新興技術(shù)更緊密地結(jié)合，采集、存儲(chǔ)等底層技術(shù)將隨之進(jìn)一步演進(jìn)。