大數(shù)據(jù)的特點(diǎn)及處理平臺(tái)比較

許吳環(huán)

[摘 要] 大數(shù)據(jù)環(huán)境下傳統(tǒng)的數(shù)據(jù)處理方式不再適用，以云計(jì)算技術(shù)為支撐的大數(shù)據(jù)處理平臺(tái)的出現(xiàn)為落實(shí)大數(shù)據(jù)應(yīng)用提供了可行思路。為此，在歸納了開(kāi)源Hadoop和Spark平臺(tái)各自優(yōu)缺點(diǎn)后，指出其應(yīng)用場(chǎng)景，以更好地利用大數(shù)據(jù)。通過(guò)比較常用大數(shù)據(jù)平臺(tái)發(fā)現(xiàn)，Hadoop適用于數(shù)據(jù)密集型任務(wù)，并廣泛應(yīng)用于離線分析。Spark因其基于內(nèi)存的計(jì)算，在迭代計(jì)算和實(shí)時(shí)分析領(lǐng)域占據(jù)優(yōu)勢(shì)。并發(fā)現(xiàn)他們?cè)诠δ苌嫌休^強(qiáng)的互補(bǔ)性，有時(shí)二者協(xié)同使用可以優(yōu)化效益，Spark和許多Hadoop發(fā)行版已經(jīng)互相支持實(shí)現(xiàn)。經(jīng)過(guò)此項(xiàng)探討工作，期望有利于選擇和實(shí)施大數(shù)據(jù)處理平臺(tái)，實(shí)現(xiàn)大數(shù)據(jù)資源的更大價(jià)值。

[關(guān)鍵字] 大數(shù)據(jù)特點(diǎn)；大數(shù)據(jù)平臺(tái)；比較研究

[中圖分類號(hào)] TP202 [文獻(xiàn)標(biāo)識(shí)碼] A [文章編號(hào)] 1002-8129（2017）01-0103-04

一、大數(shù)據(jù)的特點(diǎn)與處理平臺(tái)概述

1.大數(shù)據(jù)的特點(diǎn)。

目前，大數(shù)據(jù)還沒(méi)有一個(gè)標(biāo)準(zhǔn)的定義，但是把握大數(shù)據(jù)的特征，有助于加深對(duì)大數(shù)據(jù)內(nèi)涵的理解。數(shù)據(jù)具有的3V特征，即規(guī)模大（Volume）、種類多（Variety）、速度快（Velocity），在業(yè)內(nèi)已經(jīng)基本成為統(tǒng)一認(rèn)識(shí)。規(guī)模大，意味著數(shù)據(jù)量不斷擴(kuò)張，數(shù)據(jù)量級(jí)將從現(xiàn)在的GB、TB增長(zhǎng)到PB、EB甚至達(dá)到ZB級(jí)。種類多，是指數(shù)據(jù)類型有結(jié)構(gòu)化、半結(jié)構(gòu)化和非結(jié)構(gòu)化，其中文字、圖片、音頻、視頻等非結(jié)構(gòu)化數(shù)據(jù)占更大比例。速度快，表示大數(shù)據(jù)有強(qiáng)時(shí)效性，數(shù)據(jù)通常快速地產(chǎn)生，又需要及時(shí)地進(jìn)行處理分析，才能有效地實(shí)現(xiàn)大數(shù)據(jù)的經(jīng)濟(jì)價(jià)值。

“大數(shù)據(jù)的處理過(guò)程可以分為：數(shù)據(jù)抽取與集成、數(shù)據(jù)分析以及數(shù)據(jù)解釋”[1]。巨量的數(shù)據(jù)往往也意味著噪音的增多，這給預(yù)處理數(shù)據(jù)時(shí)數(shù)據(jù)的清洗工作造成了困難。傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)處理對(duì)象單位通常為MB，并且適合存儲(chǔ)結(jié)構(gòu)化數(shù)據(jù)，面向大數(shù)據(jù)的數(shù)據(jù)庫(kù)技術(shù)應(yīng)該能夠解決海量非結(jié)構(gòu)數(shù)據(jù)的存儲(chǔ)問(wèn)題。傳統(tǒng)的數(shù)據(jù)分析方法以算法的準(zhǔn)確率作為最重要的衡量指標(biāo)，而大數(shù)據(jù)的高速性要求算法必須犧牲一部分準(zhǔn)確性以達(dá)到更高效地處理數(shù)據(jù)。大數(shù)據(jù)的分析結(jié)果往往也是大量的，故小數(shù)據(jù)量時(shí)可以選擇的數(shù)據(jù)解釋方法基本不再適用，引入可視化技術(shù)來(lái)將大數(shù)據(jù)的分析結(jié)果以友好的形式展現(xiàn)。

2.大數(shù)據(jù)處理平臺(tái)發(fā)展概述。

為了應(yīng)對(duì)大數(shù)據(jù)處理上的挑戰(zhàn)，“從規(guī)模巨大、種類繁多、生成快速的數(shù)據(jù)集中挖掘價(jià)值”[2]，專門針對(duì)大數(shù)據(jù)的技術(shù)和方法應(yīng)運(yùn)而生。GFS、NoSQL、ITHbase、MapReduce等云計(jì)算技術(shù)的發(fā)展，使得大數(shù)據(jù)的有效存儲(chǔ)、管理和分析成為可能。但是從眾多復(fù)雜的大數(shù)據(jù)技術(shù)中進(jìn)行選擇，并搭建完備的大數(shù)據(jù)處理框架難度很高，不利于挖掘大數(shù)據(jù)中的經(jīng)濟(jì)價(jià)值。大數(shù)據(jù)平臺(tái)和產(chǎn)品的出現(xiàn)，可以使用戶在不了解架構(gòu)底層細(xì)節(jié)的情況下，開(kāi)發(fā)大數(shù)據(jù)應(yīng)用程序。全球領(lǐng)先的科技巨頭都紛紛在制定大數(shù)據(jù)戰(zhàn)略時(shí)提出了建設(shè)與應(yīng)用大數(shù)據(jù)處理平臺(tái)：IBM公司推出了云端版InfoSphere BigInsights[3]；HP推出了HP Vertica6.1分析平臺(tái)[4]；Google提出的GFS、MapReduce等云計(jì)算技術(shù)催生了大數(shù)據(jù)處理平臺(tái)的事實(shí)標(biāo)準(zhǔn)Hadoop，目前，Google使用的是自己開(kāi)發(fā)的Caffeine[2]；Facebook結(jié)合自身的使用需求實(shí)現(xiàn)了Corona、Prism。一個(gè)完備、高效的大數(shù)據(jù)處理平臺(tái)為實(shí)施大數(shù)據(jù)應(yīng)用提供一站式的基礎(chǔ)服務(wù)，支持應(yīng)用系統(tǒng)從清洗、集成、分析到結(jié)果可視化展現(xiàn)的大數(shù)據(jù)處理全過(guò)程建設(shè)，降低了用戶技術(shù)門檻[5]。因此，比較和選擇有大數(shù)據(jù)特征的處理平臺(tái)，有助于大數(shù)據(jù)技術(shù)研發(fā)和產(chǎn)業(yè)落地，實(shí)現(xiàn)大數(shù)據(jù)的巨大價(jià)值。

二、常用大數(shù)據(jù)處理平臺(tái)比較

1.Hadoop

Hadoop是由Apache開(kāi)發(fā)的開(kāi)源云計(jì)算平臺(tái)，實(shí)現(xiàn)在大量計(jì)算機(jī)組成的集群中進(jìn)行分布式存儲(chǔ)和計(jì)算。Hadoop框架最核心的技術(shù)是HDFS和MapReduce。HDFS是可以部署在廉價(jià)機(jī)器上的分布式文件系統(tǒng)，采用主/從結(jié)構(gòu)，將大文件分割后形成大小相等的block復(fù)制三份，分別存儲(chǔ)在不同的節(jié)點(diǎn)上，實(shí)現(xiàn)了海量數(shù)據(jù)的存儲(chǔ)。MapReduce編程模型實(shí)現(xiàn)大數(shù)據(jù)處理，它的核心是“分而治之”[1]。Map任務(wù)區(qū)將輸入數(shù)據(jù)源分塊后，分散給不同的節(jié)點(diǎn)，通過(guò)用戶自定義的Map函數(shù)，得到中間key/Value集合，存儲(chǔ)到HDFS上。Reduce任務(wù)區(qū)從硬盤上讀取中間結(jié)果，把相同K值的數(shù)據(jù)組織在一起，再經(jīng)過(guò)用戶自定義的Reduce函數(shù)處理，得到并輸出最終結(jié)果。將對(duì)巨量資料的處理并行地運(yùn)行在集群上，從而實(shí)現(xiàn)了對(duì)大數(shù)據(jù)的有效處理。從Hadoop的核心處理過(guò)程我們可以總結(jié)出它具有如下優(yōu)點(diǎn)[6-9]：

高擴(kuò)展性。Hadoop的橫向擴(kuò)展性能很好，使海量數(shù)據(jù)能橫跨幾百甚至上千臺(tái)服務(wù)器，而用戶使用時(shí)好像只是面對(duì)一個(gè)。大量計(jì)算機(jī)并行工作，使對(duì)大數(shù)據(jù)的處理能在合理的時(shí)間內(nèi)完成并得以應(yīng)用，這是在傳統(tǒng)單機(jī)模式下無(wú)法實(shí)現(xiàn)的。

高容錯(cuò)性。從HDFS的設(shè)計(jì)中可以看出，它通過(guò)提供數(shù)據(jù)冗余的方式提供高可靠性。當(dāng)某個(gè)數(shù)據(jù)塊損壞或丟失，NameNode就會(huì)將其他DataNode上的副本進(jìn)行復(fù)制，保證每塊都有三份。所以，在數(shù)據(jù)處理過(guò)程中，當(dāng)集群中機(jī)器出現(xiàn)故障，計(jì)算并不會(huì)停止。

節(jié)約成本。首先，Hadoop本身是開(kāi)源軟件，完全免費(fèi)；其次，它可以部署在廉價(jià)的PC機(jī)上；“把計(jì)算推送給數(shù)據(jù)”的設(shè)計(jì)理念，節(jié)省了數(shù)據(jù)傳輸中的通信開(kāi)銷。顯然，若使用傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)將所有數(shù)據(jù)存儲(chǔ)起來(lái)成本高昂，這不利于大數(shù)據(jù)產(chǎn)業(yè)的發(fā)展。

高效性。Hadoop以簡(jiǎn)單直觀的方式解決了大數(shù)據(jù)處理中的基本問(wèn)題，即大數(shù)據(jù)儲(chǔ)存和大數(shù)據(jù)分析。并且數(shù)據(jù)規(guī)模越大，相較于單機(jī)處理Hadoop的集群并行處理優(yōu)勢(shì)越明顯。

基礎(chǔ)性。對(duì)于技術(shù)優(yōu)勢(shì)的企業(yè)，可以根據(jù)基礎(chǔ)的Hadoop結(jié)合應(yīng)用場(chǎng)景進(jìn)行二次開(kāi)發(fā)，使其更適合實(shí)際工作環(huán)境。比如，F(xiàn)acebook從自身應(yīng)用需要出發(fā)，構(gòu)建了實(shí)時(shí)Hadoop系統(tǒng)。

Hadoop系統(tǒng)的局限性 [10-11]：

不適合迭代運(yùn)算。MapReduce要求每個(gè)運(yùn)算結(jié)果都輸出到HDFS，每次初始化都要從HDFS讀入數(shù)據(jù)。在迭代運(yùn)算中，每次運(yùn)算的中間結(jié)果都要寫入磁盤，Hadoop在執(zhí)行每一次功能相同的迭代任務(wù)時(shí)，都有反復(fù)的I/O操作，計(jì)算代價(jià)很大。而對(duì)于現(xiàn)在常見(jiàn)的圖計(jì)算和數(shù)據(jù)挖掘等領(lǐng)域，迭代計(jì)算是必要的。

實(shí)時(shí)性差。Hadoop平臺(tái)由于頻繁的磁盤I/O操作，大大地增加了時(shí)間延遲，對(duì)于快速處理任務(wù)不能勝任。

易用性差。Hadoop只是一個(gè)基礎(chǔ)框架，精細(xì)程度有所欠缺，如果想用它來(lái)實(shí)現(xiàn)具體的業(yè)務(wù)，還需要更進(jìn)一步的開(kāi)發(fā)。MapReduce特定的編程模型，增加了Hadoop的技術(shù)復(fù)雜性。

雖然Hadoop本身有一些缺點(diǎn)，但是由于其支撐技術(shù)（MapReduce等）成熟較早，并且實(shí)現(xiàn)了海量數(shù)據(jù)分布式的存儲(chǔ)和批量處理，所以被廣泛使用，已成為大數(shù)據(jù)處理平臺(tái)的事實(shí)標(biāo)準(zhǔn)。為了提高Hadoop的性能，各種工具應(yīng)運(yùn)而生，已經(jīng)發(fā)展成為包括Hive、Pig、HBase、Cassandra、YARN等在內(nèi)的完整生態(tài)系統(tǒng)。HBase新型NoSQL數(shù)據(jù)庫(kù)便于數(shù)據(jù)管理，Hive提供類似SQL的操作方式進(jìn)行數(shù)據(jù)分析，Pig是用來(lái)處理大規(guī)模數(shù)據(jù)的高級(jí)腳本語(yǔ)言……這些功能模塊在一定程度上彌補(bǔ)了Hadoop的不足，降低了用戶使用難度。MapReduce的設(shè)計(jì)理念決定了Hadoop適用于對(duì)龐大數(shù)據(jù)集加以控制、數(shù)據(jù)密集型計(jì)算和離線分析的場(chǎng)景。

2.Spark

Spark的整個(gè)生態(tài)系統(tǒng)稱為BDAS（伯克利數(shù)據(jù)分析棧），包括Tachyon、Spark Streaming、Spark Core、MLlib等。其核心框架Spark，是為了實(shí)現(xiàn)大數(shù)據(jù)的快速處理而出現(xiàn)的，可以用來(lái)構(gòu)建低延遲的應(yīng)用。Spark以RDD（彈性分布數(shù)據(jù)集）為基礎(chǔ)，實(shí)現(xiàn)了基于內(nèi)存的大數(shù)據(jù)計(jì)算。RDD是對(duì)數(shù)據(jù)的基本抽象，實(shí)現(xiàn)了對(duì)分布式內(nèi)存的抽象使用。由于RDD能緩存到內(nèi)存中，可以將每次運(yùn)算的中間結(jié)果都存放到內(nèi)存中，避免過(guò)多的磁盤I/O操作，大大降低了時(shí)延。Tachyon是分布式內(nèi)存文件系統(tǒng)，類似于內(nèi)存中的HDFS，基于它可以實(shí)現(xiàn)RDD或文件在計(jì)算機(jī)集群中可靠的共享。Spark沒(méi)有自己的文件系統(tǒng)，通過(guò)支持Hadoop HDFS、HBase等進(jìn)行數(shù)據(jù)的存儲(chǔ)，Spark更專注于計(jì)算性能?？梢钥偨Y(jié)出如下特點(diǎn)[11-13]：

高速性。Spark主要通過(guò)基于內(nèi)存計(jì)算減少磁盤I/O開(kāi)銷，極大地縮小了時(shí)間延遲。這使得它擅長(zhǎng)處理Hadoop無(wú)法應(yīng)對(duì)的迭代運(yùn)算，在進(jìn)行圖計(jì)算等工作時(shí)表現(xiàn)更好。并且高速數(shù)據(jù)處理能力使得Spark更能滿足大數(shù)據(jù)分析中對(duì)實(shí)時(shí)分析的要求。

靈活性。較之僅支持map函數(shù)和reduce函數(shù)的Hadoop，Spark支持map、reduce、filter、join、count等近80多種操作類型。Spark的交互模式使用戶在進(jìn)行操作時(shí)能及時(shí)獲得反饋，這是Hadoop所沒(méi)有的。Spark SQL提供用戶直接用標(biāo)準(zhǔn)SQL語(yǔ)句在Spark上進(jìn)行大數(shù)據(jù)查詢，簡(jiǎn)單易學(xué)。盡管在Hadoop中，有了Hive，可以不用Java來(lái)寫復(fù)雜的MapReduce程序，但是Hive在MapReduce上運(yùn)行速度卻達(dá)不到期望程度。

Spark以其近乎實(shí)時(shí)的性能和相對(duì)易用靈活而受到歡迎，它同Hadoop一樣都是Apache旗下的開(kāi)源集群系統(tǒng)，是目前發(fā)展最快的大數(shù)據(jù)處理平臺(tái)之一。Spark主要適用于支持迭代計(jì)算，交互式查詢，實(shí)時(shí)分析的場(chǎng)景。比如，淘寶使用Spark來(lái)實(shí)現(xiàn)基于用戶的圖計(jì)算應(yīng)用[11]。由RDD特點(diǎn)決定，它不適合異步細(xì)粒度更新?tīng)顟B(tài)的應(yīng)用[1]，比如，增量的Web抓取和索引。RDD的特點(diǎn)之一是“不可變”，即只讀不可寫，如果要對(duì)RDD中的數(shù)據(jù)進(jìn)行更新的話，就要遍歷整個(gè)RDD并生成一個(gè)新RDD，這使得對(duì)細(xì)粒度內(nèi)容的頻繁更新代價(jià)很大。

Hadoop與Spark并不是互相排斥的關(guān)系，Hadoop解決了如何將大數(shù)據(jù)儲(chǔ)存起來(lái)的問(wèn)題，Spark在這基礎(chǔ)之上考慮更快速、易用地實(shí)現(xiàn)大數(shù)據(jù)分析，這點(diǎn)從Spark仍采用HDFS作為文件系統(tǒng)就可以看出。它們適用于不同的場(chǎng)景，有時(shí)協(xié)同工作會(huì)達(dá)到更理想的效果，在Spark和Hadoop的許多發(fā)行版中，它們都已經(jīng)互相支持實(shí)現(xiàn)。

3.Hadoop發(fā)行版

包括傳統(tǒng)IT企業(yè)和新興互聯(lián)網(wǎng)企業(yè)在內(nèi)的眾多廠家，通過(guò)對(duì)開(kāi)源平臺(tái)Hadoop進(jìn)行改進(jìn)，紛紛推出了自己的商業(yè)發(fā)行版。用戶能更容易地對(duì)大數(shù)據(jù)進(jìn)行處理，并易于搭建、監(jiān)管復(fù)雜集群系統(tǒng)。

（1）CDH

Cloudera推出的CDH，基于穩(wěn)定版Apache Hadoop并應(yīng)用最新的BUG修復(fù)系統(tǒng)和管理監(jiān)控平臺(tái)，在安全性、兼容性和穩(wěn)定性方面有所增強(qiáng)。Cloudera公司業(yè)務(wù)開(kāi)發(fā)負(fù)責(zé)人Ed Albanese表示[14]：在CDH上運(yùn)行的應(yīng)用已超過(guò)其它Hadoop產(chǎn)品上運(yùn)行的應(yīng)用。

（2）MapR

提供了完整的Hadoop組件體系，并且100%和Apache Hadoop API兼容。新增的Direct Access NFS技術(shù)支持文件隨機(jī)讀寫，大大地?cái)U(kuò)展了MapR Hadoop的應(yīng)用范圍。還支持了Snapshot（快照）、Mirro（鏡像）等企業(yè)應(yīng)用功能。

（3）InfoSphere BigInsights[15]

是IBM推出的以Hadoop為基礎(chǔ)的云端大數(shù)據(jù)分析平臺(tái)，企業(yè)版在30分鐘內(nèi)可以啟動(dòng)運(yùn)行?？蛻艏词箾](méi)有Hadoop技能，也可以捕捉和分析任意數(shù)據(jù)，使組織內(nèi)任何人都獲得了大數(shù)據(jù)處理的能力。

由于開(kāi)源Hadoop存在的許多先天不足，直接使用尚達(dá)不到普及的程度。為了推進(jìn)大數(shù)據(jù)的企業(yè)級(jí)應(yīng)用，大數(shù)據(jù)平臺(tái)產(chǎn)品旨在提供優(yōu)越性能的同時(shí)，簡(jiǎn)化客戶搭建、管理和監(jiān)控復(fù)雜集群的過(guò)程，優(yōu)化和擴(kuò)展開(kāi)源方案，降低使用難度以普及應(yīng)用，使大數(shù)據(jù)作為企業(yè)的基礎(chǔ)資源能有效被利用。

三、結(jié)語(yǔ)

介紹大數(shù)據(jù)的3v特點(diǎn)及在此特點(diǎn)下數(shù)據(jù)處理上與傳統(tǒng)數(shù)據(jù)處理的不同，有助于認(rèn)識(shí)傳統(tǒng)處理方式在大數(shù)據(jù)環(huán)境下的局限性。通過(guò)分析常用的大數(shù)據(jù)處理平臺(tái)，并分析Hadoop和Spark的核心技術(shù)，對(duì)其優(yōu)缺點(diǎn)進(jìn)行了歸納。Hadoop實(shí)現(xiàn)了對(duì)海量異構(gòu)數(shù)據(jù)在人們可以接受的時(shí)間和成本內(nèi)進(jìn)行可靠地存儲(chǔ)和處理，雖然它在處理速度和易用性方面存在缺陷，但由于它的基礎(chǔ)性，企業(yè)可以根據(jù)自身應(yīng)用特點(diǎn)進(jìn)行改進(jìn)，目前已被廣泛應(yīng)用。雖然Spark不適合異步細(xì)粒度更新?tīng)顟B(tài)的應(yīng)用，但在處理性能和易用程度上較于Hadoop有顯著優(yōu)勢(shì)，發(fā)展十分迅速。文章指出它們各自的適用場(chǎng)景，平臺(tái)的選擇應(yīng)根據(jù)企業(yè)的應(yīng)用需要。通過(guò)比較兩者的優(yōu)缺點(diǎn)，可以發(fā)現(xiàn)它們?cè)诠δ苌嫌休^強(qiáng)的互補(bǔ)性，有時(shí)它們對(duì)資源的協(xié)同使用可以帶來(lái)效益優(yōu)化，目前Spark和很多Hadoop發(fā)行版都已經(jīng)支持互相實(shí)現(xiàn)。最后介紹了幾種目前常用的商業(yè)Hadoop發(fā)行版，相較于開(kāi)源框架它們都進(jìn)行了不同程度的優(yōu)化，并且更易于企業(yè)級(jí)實(shí)現(xiàn)。綜上，以期對(duì)大數(shù)據(jù)平臺(tái)或產(chǎn)品的選擇、利用和研發(fā)有所啟發(fā)。

[參考文獻(xiàn)]

[1]孟小峰.大數(shù)據(jù)管理：概念、技術(shù)與挑戰(zhàn)[J].計(jì)算機(jī)研究與發(fā)展，2013，（01）.

[2]張 引.大數(shù)據(jù)應(yīng)用的現(xiàn)狀與展望[J].計(jì)算機(jī)研究與發(fā)展，2013，（S2）.

[3]IBM：積極推進(jìn)“大數(shù)據(jù)”時(shí)代革新[J].硅谷，2011，（22）.

[4]于 翔.HP Vertica 6.1快速連接H-

adoop[N].網(wǎng)絡(luò)世界，2013-02-04.

[5]王 強(qiáng).大數(shù)據(jù)分析平臺(tái)建設(shè)與應(yīng)用綜述[J].集成技術(shù)，2016，（02）.

[6]黃素萍.Hadoop平臺(tái)在大數(shù)據(jù)處理中的應(yīng)用研究[J].現(xiàn)代計(jì)算機(jī)，2013，（29）.

[7]任 仁.Hadoop在大數(shù)據(jù)處理中的應(yīng)用優(yōu)勢(shì)分析[J].電子技術(shù)與軟件工程，2014，（15）.

[8]戴中華.基于Hadoop平臺(tái)的大數(shù)據(jù)分析與處理[J].通訊世界，2015，（06）.

[9]張 臻.大數(shù)據(jù)處理平臺(tái)分析[J].電信快報(bào)，2014，（06）.

[10]張巖峰.云環(huán)境下大數(shù)據(jù)迭代計(jì)算研究[D].東北：東北大學(xué)，2012.

[11]何海林.大數(shù)據(jù)處理平臺(tái)比較與分析[J].微型機(jī)與應(yīng)用，2015，（11）.

[12]李 曼.Spark生態(tài)系統(tǒng)走向成熟和應(yīng)用[J].世界電信，2015，（07）.

[13]范煒瑋.大數(shù)據(jù)處理平臺(tái)Spark及其生物醫(yī)學(xué)應(yīng)用[J].中國(guó)中醫(yī)藥圖書情報(bào)雜志，2015，39（02）.

[14]NetApp攜Cloudera提供卓越的Hadoop解決方案[J].硅谷，2011，（22）.

[15]許繼楠.IBM大數(shù)據(jù)戰(zhàn)略：將洞察付諸行動(dòng)[N].中國(guó)計(jì)算機(jī)報(bào)，2011-11-07.

[責(zé)任編輯：彭 亮]