引言

大數(shù)據(jù)查詢分析是云計(jì)算中核心問(wèn)題之一，自從Google在2006年之前的幾篇論文奠定云計(jì)算領(lǐng)域基礎(chǔ)，尤其是GFS、Map-Reduce、 Bigtable被稱為云計(jì)算底層技術(shù)三大基石。GFS、Map-Reduce技術(shù)直接支持了Apache Hadoop項(xiàng)目的誕生。Bigtable和Amazon Dynamo直接催生了NoSQL這個(gè)嶄新的數(shù)據(jù)庫(kù)領(lǐng)域，撼動(dòng)了RDBMS在商用數(shù)據(jù)庫(kù)和數(shù)據(jù)倉(cāng)庫(kù)方面幾十年的統(tǒng)治性地位。FaceBook的Hive項(xiàng) 目是建立在Hadoop上的數(shù)據(jù)倉(cāng)庫(kù)基礎(chǔ)構(gòu)架，提供了一系列用于存儲(chǔ)、查詢和分析大規(guī)模數(shù)據(jù)的工具。當(dāng)我們還浸淫在GFS、Map-Reduce、 Bigtable等Google技術(shù)中，并進(jìn)行理解、掌握、模仿時(shí)，Google在2009年之后，連續(xù)推出多項(xiàng)新技術(shù)，包括：Dremel、 Pregel、Percolator、Spanner和F1。其中，Dremel促使了實(shí)時(shí)計(jì)算系統(tǒng)的興起，Pregel開(kāi)辟了圖數(shù)據(jù)計(jì)算這個(gè)新方 向，Percolator使分布式增量索引更新成為文本檢索領(lǐng)域的新標(biāo)準(zhǔn)，Spanner和F1向我們展現(xiàn)了跨數(shù)據(jù)中心數(shù)據(jù)庫(kù)的可能。在Google的第 二波技術(shù)浪潮中，基于Hive和Dremel，新興的大數(shù)據(jù)公司Cloudera開(kāi)源了大數(shù)據(jù)查詢分析引擎Impala，Hortonworks開(kāi)源了 Stinger，F(xiàn)ackbook開(kāi)源了Presto。類似Pregel，UC Berkeley AMPLAB實(shí)驗(yàn)室開(kāi)發(fā)了Spark圖計(jì)算框架，并以Spark為核心開(kāi)源了大數(shù)據(jù)查詢分析引擎Shark。由于某電信運(yùn)營(yíng)商項(xiàng)目中大數(shù)據(jù)查詢引擎選型需 求，本文將會(huì)對(duì)Hive、Impala、Shark、Stinger和Presto這五類主流的開(kāi)源大數(shù)據(jù)查詢分析引擎進(jìn)行簡(jiǎn)要介紹以及性能比較，最后進(jìn) 行總結(jié)與展望。Hive、Impala、Shark、Stinger和Presto的進(jìn)化圖譜如圖1所示。

圖1. Impala、Shark、Stinger和Presto的進(jìn)化圖譜

當(dāng)前主流引擎簡(jiǎn)介

基于Map-Reduce模式的Hadoop擅長(zhǎng)數(shù)據(jù)批處理，不是特別符合即時(shí)查詢的場(chǎng)景。實(shí)時(shí)查詢一般使用MPP (Massively Parallel Processing)的架構(gòu)，因此用戶需要在Hadoop和MPP兩種技術(shù)中選擇。在Google的第二波技術(shù)浪潮中，一些基于Hadoop架構(gòu)的快速 SQL訪問(wèn)技術(shù)逐步獲得人們關(guān)注。現(xiàn)在有一種新的趨勢(shì)是MPP和Hadoop相結(jié)合提供快速SQL訪問(wèn)框架。最近有四個(gè)很熱門(mén)的開(kāi)源工具出 來(lái)：Impala、Shark、Stinger和Presto。這也顯示了大數(shù)據(jù)領(lǐng)域?qū)τ贖adoop生態(tài)系統(tǒng)中支持實(shí)時(shí)查詢的期望?？傮w來(lái) 說(shuō)，Impala、Shark、Stinger和Presto四個(gè)系統(tǒng)都是類SQL實(shí)時(shí)大數(shù)據(jù)查詢分析引擎，但是它們的技術(shù)側(cè)重點(diǎn)完全不同。而且它們也不 是為了替換Hive而生，Hive在做數(shù)據(jù)倉(cāng)庫(kù)時(shí)是非常有價(jià)值的。這四個(gè)系統(tǒng)與Hive都是構(gòu)建在Hadoop之上的數(shù)據(jù)查詢工具，各有不同的側(cè)重適應(yīng) 面，但從客戶端使用來(lái)看它們與Hive有很多的共同之處，如數(shù)據(jù)表元數(shù)據(jù)、Thrift接口、ODBC/JDBC驅(qū)動(dòng)、SQL語(yǔ)法、靈活的文件格式、存儲(chǔ) 資源池等。Hive與Impala、Shark、Stinger、Presto在Hadoop中的關(guān)系如圖2所示。Hive適用于長(zhǎng)時(shí)間的批處理查詢分 析，而Impala、Shark、Stinger和Presto適用于實(shí)時(shí)交互式SQL查詢，它們給數(shù)據(jù)分析人員提供了快速實(shí)驗(yàn)、驗(yàn)證想法的大數(shù)據(jù)分析工 具?？梢韵仁褂肏ive進(jìn)行數(shù)據(jù)轉(zhuǎn)換處理，之后使用這四個(gè)系統(tǒng)中的一個(gè)在Hive處理后的結(jié)果數(shù)據(jù)集上進(jìn)行快速的數(shù)據(jù)分析。下面，從問(wèn)題域出發(fā)簡(jiǎn)單介紹 Hive、Impala、Shark、Stinger和Presto：

1) Hive，披著SQL外衣的Map-Reduce。Hive是為方便用戶使用Map-Reduce而在外面封裝了一層SQL，由于Hive采 用了SQL，它的問(wèn)題域比Map-Reduce更窄，因?yàn)楹芏鄦?wèn)題，SQL表達(dá)不出來(lái)，比如一些數(shù)據(jù)挖掘算法，推薦算法、圖像識(shí)別算法等，這些仍只能通過(guò) 編寫(xiě)Map-Reduce完成。

2) Impala：Google Dremel的開(kāi)源實(shí)現(xiàn)（Apache Drill類似），因?yàn)榻换ナ綄?shí)時(shí)計(jì)算需求，Cloudera推出了Impala系統(tǒng)，該系統(tǒng)適用于交互式實(shí)時(shí)處理場(chǎng)景，要求最后產(chǎn)生的數(shù)據(jù)量一定要少。

3) Shark/Spark：為了提高M(jìn)ap-Reduce的計(jì)算效率，Berkeley的AMPLab實(shí)驗(yàn)室開(kāi)發(fā)了Spark，Spark可看 做基于內(nèi)存的Map-Reduce實(shí)現(xiàn)，此外，伯克利還在Spark基礎(chǔ)上封裝了一層SQL，產(chǎn)生了一個(gè)新的類似Hive的系統(tǒng)Shark。

4) Stinger Initiative（Tez optimized Hive）：Hortonworks開(kāi)源了一個(gè)DAG計(jì)算框架Tez，Tez可以理解為Google Pregel的開(kāi)源實(shí)現(xiàn)，該框架可以像Map-Reduce一樣，可以用來(lái)設(shè)計(jì)DAG應(yīng)用程序，但需要注意的是，Tez只能運(yùn)行在YARN上。Tez的一 個(gè)重要應(yīng)用是優(yōu)化Hive和PIG這種典型的DAG應(yīng)用場(chǎng)景，它通過(guò)減少數(shù)據(jù)讀寫(xiě)IO，優(yōu)化DAG流程使得Hive速度提供了很多倍。

5) Presto：FaceBook于2013年11月份開(kāi)源了Presto，一個(gè)分布式SQL查詢引擎，它被設(shè)計(jì)為用來(lái)專門(mén)進(jìn)行高速、實(shí)時(shí)的數(shù) 據(jù)分析。它支持標(biāo)準(zhǔn)的ANSI SQL，包括復(fù)雜查詢、聚合（aggregation）、連接（join）和窗口函數(shù)（window functions)。Presto設(shè)計(jì)了一個(gè)簡(jiǎn)單的數(shù)據(jù)存儲(chǔ)的抽象層，來(lái)滿足在不同數(shù)據(jù)存儲(chǔ)系統(tǒng)（包括HBase、HDFS、Scribe等）之上都可 以使用SQL進(jìn)行查詢。

圖2. Hive與Impala、Shark、Stinger、Presto在Hadoop中的關(guān)系

當(dāng)前主流引擎架構(gòu)

Hive

Hive是基于Hadoop的一個(gè)數(shù)據(jù)倉(cāng)庫(kù)工具，可以將結(jié)構(gòu)化的數(shù)據(jù)文件映射為一張數(shù)據(jù)庫(kù)表，并提供完整的SQL查詢功能，可以將SQL語(yǔ)句轉(zhuǎn)換為 Map-Reduce任務(wù)進(jìn)行運(yùn)行，十分適合數(shù)據(jù)倉(cāng)庫(kù)的統(tǒng)計(jì)分析。其架構(gòu)如圖3所示，Hadoop和Map-Reduce是Hive架構(gòu)的根基。Hive 架構(gòu)包括如下組件：CLI（Command Line Interface）、JDBC/ODBC、Thrift Server、Meta Store和Driver(Complier、Optimizer和Executor)。

圖3. Hive架構(gòu)

Impala架構(gòu)

Impala是Cloudera在受到Google的Dremel啟發(fā)下開(kāi)發(fā)的實(shí)時(shí)交互SQL大數(shù)據(jù)查詢工具，它可以看成是Google Dremel架構(gòu)和MPP (Massively Parallel Processing)結(jié)構(gòu)的結(jié)合體。Impala沒(méi)有再使用緩慢的Hive&Map-Reduce批處理，而是通過(guò)使用與商用并行關(guān)系數(shù)據(jù)庫(kù)中 類似的分布式查詢引擎（由Query Planner、Query Coordinator和Query Exec Engine三部分組成），可以直接從HDFS或HBase中用SELECT、JOIN和統(tǒng)計(jì)函數(shù)查詢數(shù)據(jù)，從而大大降低了延遲，其架構(gòu)如圖4所 示，Impala主要由Impalad，State Store和CLI組成。Impalad與DataNode運(yùn)行在同一節(jié)點(diǎn)上，由Impalad進(jìn)程表示，它接收客戶端的查詢請(qǐng)求（接收查詢請(qǐng)求的 Impalad為Coordinator，Coordinator通過(guò)JNI調(diào)用java前端解釋SQL查詢語(yǔ)句，生成查詢計(jì)劃樹(shù)，再通過(guò)調(diào)度器把執(zhí)行計(jì) 劃分發(fā)給具有相應(yīng)數(shù)據(jù)的其它Impalad進(jìn)行執(zhí)行），讀寫(xiě)數(shù)據(jù)，并行執(zhí)行查詢，并把結(jié)果通過(guò)網(wǎng)絡(luò)流式的傳送回給Coordinator，由 Coordinator返回給客戶端。同時(shí)Impalad也與State Store保持連接，用于確定哪個(gè)Impalad是健康和可以接受新的工作。Impala State Store跟蹤集群中的Impalad的健康狀態(tài)及位置信息，由state-stored進(jìn)程表示，它通過(guò)創(chuàng)建多個(gè)線程來(lái)處理Impalad的注冊(cè)訂閱和 與各Impalad保持心跳連接，各Impalad都會(huì)緩存一份State Store中的信息，當(dāng)State Store離線后，因?yàn)镮mpalad有State Store的緩存仍然可以工作，但會(huì)因?yàn)橛行㊣mpalad失效了，而已緩存數(shù)據(jù)無(wú)法更新，導(dǎo)致把執(zhí)行計(jì)劃分配給了失效的Impalad，導(dǎo)致查詢失敗。 CLI提供給用戶查詢使用的命令行工具，同時(shí)Impala還提供了Hue，JDBC，ODBC，Thrift使用接口。

圖4. Impala架構(gòu)

Shark架構(gòu)

Shark是UC Berkeley AMPLAB開(kāi)源的一款數(shù)據(jù)倉(cāng)庫(kù)產(chǎn)品，它完全兼容Hive的HQL語(yǔ)法，但與Hive不同的是，Hive的計(jì)算框架采用Map-Reduce，而 Shark采用Spark。所以，Hive是SQL on Map-Reduce，而Shark是Hive on Spark。其架構(gòu)如圖4所示，為了最大程度的保持和Hive的兼容性，Shark復(fù)用了Hive的大部分組件，如下所示：

1) SQL Parser&Plan generation: Shark完全兼容Hive的HQL語(yǔ)法，而且Shark使用了Hive的API來(lái)實(shí)現(xiàn)query Parsing和 query Plan generation，僅僅最后的Physical Plan execution階段用Spark代替Hadoop Map-Reduce；

2) metastore：Shark采用和Hive一樣的meta信息，Hive里創(chuàng)建的表用Shark可無(wú)縫訪問(wèn)；

3) SerDe: Shark的序列化機(jī)制以及數(shù)據(jù)類型與Hive完全一致；

4) UDF: Shark可重用Hive里的所有UDF。通過(guò)配置Shark參數(shù)，Shark可以自動(dòng)在內(nèi)存中緩存特定的RDD（Resilient Distributed Dataset），實(shí)現(xiàn)數(shù)據(jù)重用，進(jìn)而加快特定數(shù)據(jù)集的檢索。同時(shí)，Shark通過(guò)UDF用戶自定義函數(shù)實(shí)現(xiàn)特定的數(shù)據(jù)分析學(xué)習(xí)算法，使得SQL數(shù)據(jù)查詢 和運(yùn)算分析能結(jié)合在一起，最大化RDD的重復(fù)使用；

5) Driver：Shark在Hive的CliDriver基礎(chǔ)上進(jìn)行了一個(gè)封裝，生成一個(gè)SharkCliDriver，這是shark命令的入口；

6) ThriftServer：Shark在Hive的ThriftServer（支持JDBC/ODBC）基礎(chǔ)上，做了一個(gè)封裝，生成了一個(gè)SharkServer，也提供JDBC/ODBC服務(wù)。

圖5. Shark架構(gòu)

Spark是UC Berkeley AMP lab所開(kāi)源的類Hadoop Map-Reduce的通用的并行計(jì)算框架，Spark基于Map-Reduce算法實(shí)現(xiàn)的分布式計(jì)算，擁有Hadoop Map-Reduce所具有的優(yōu)點(diǎn)；但不同于Map-Reduce的是Job中間輸出和結(jié)果可以保存在內(nèi)存中，從而不再需要讀寫(xiě)HDFS，因此Spark 能更好地適用于數(shù)據(jù)挖掘與機(jī)器學(xué)習(xí)等需要迭代的Map-Reduce的算法。其架構(gòu)如圖6所示：

圖6. Spark架構(gòu)

與Hadoop的對(duì)比，Spark的中間數(shù)據(jù)放到內(nèi)存中，對(duì)于迭代運(yùn)算效率更高，因此Spark適用于需要多次操作特定數(shù)據(jù)集的應(yīng)用場(chǎng)合。需要反復(fù)操作的 次數(shù)越多，所需讀取的數(shù)據(jù)量越大，受益越大，數(shù)據(jù)量小但是計(jì)算密集度較大的場(chǎng)合，受益就相對(duì)較小。Spark比Hadoop更通用，Spark提供的數(shù)據(jù) 集操作類型有很多種（map, filter, flatMap, sample, groupByKey, reduceByKey, union, join, cogroup, mapValues, sort，partionBy等），而Hadoop只提供了Map和Reduce兩種操作。Spark可以直接對(duì)HDFS進(jìn)行數(shù)據(jù)的讀寫(xiě)，同樣支持 Spark on YARN。Spark可以與Map-Reduce運(yùn)行于同集群中，共享存儲(chǔ)資源與計(jì)算，數(shù)據(jù)倉(cāng)庫(kù)Shark實(shí)現(xiàn)上借用Hive，幾乎與Hive完全兼容。

Stinger架構(gòu)

Stinger是Hortonworks開(kāi)源的一個(gè)實(shí)時(shí)類SQL即時(shí)查詢系統(tǒng)，聲稱可以提升較Hive 100倍的速度。與Hive不同的是，Stinger采用Tez。所以，Hive是SQL on Map-Reduce，而Stinger是Hive on Tez。Tez的一個(gè)重要作用是優(yōu)化Hive和PIG這種典型的DAG應(yīng)用場(chǎng)景，它通過(guò)減少數(shù)據(jù)讀寫(xiě)IO，優(yōu)化DAG流程使得Hive速度提供了很多倍。 其架構(gòu)如圖7所示， Stinger是在Hive的現(xiàn)有基礎(chǔ)上加了一個(gè)優(yōu)化層Tez（此框架是基于Yarn），所有的查詢和統(tǒng)計(jì)都要經(jīng)過(guò)它的優(yōu)化層來(lái)處理，以減少不必要的工作 以及資源開(kāi)銷。雖然Stinger也對(duì)Hive進(jìn)行了較多的優(yōu)化與加強(qiáng)，Stinger總體性能還是依賴其子系統(tǒng)Tez的表現(xiàn)。而Tez是 Hortonworks開(kāi)源的一個(gè)DAG計(jì)算框架，Tez可以理解為Google Pregel的開(kāi)源實(shí)現(xiàn)，該框架可以像Map-Reduce一樣，用來(lái)設(shè)計(jì)DAG應(yīng)用程序，但需要注意的是，Tez只能運(yùn)行在YARN上。

圖7. Stinger架構(gòu)

Presto架構(gòu)

2013年11月Facebook開(kāi)源了一個(gè)分布式SQL查詢引擎Presto，它被設(shè)計(jì)為用來(lái)專門(mén)進(jìn)行高速、實(shí)時(shí)的數(shù)據(jù)分析。它支持標(biāo)準(zhǔn)的 ANSI SQL子集，包括復(fù)雜查詢、聚合、連接和窗口函數(shù)。其簡(jiǎn)化的架構(gòu)如圖8所示，客戶端將SQL查詢發(fā)送到Presto的協(xié)調(diào)器。協(xié)調(diào)器會(huì)進(jìn)行語(yǔ)法檢查、分析 和規(guī)劃查詢計(jì)劃。調(diào)度器將執(zhí)行的管道組合在一起，將任務(wù)分配給那些里數(shù)據(jù)最近的節(jié)點(diǎn)，然后監(jiān)控執(zhí)行過(guò)程?？蛻舳藦妮敵龆沃袑?shù)據(jù)取出，這些數(shù)據(jù)是從更底層 的處理段中依次取出的。Presto的運(yùn)行模型與Hive有著本質(zhì)的區(qū)別。Hive將查詢翻譯成多階段的Map-Reduce任務(wù)，一個(gè)接著一個(gè)地運(yùn)行。 每一個(gè)任務(wù)從磁盤(pán)上讀取輸入數(shù)據(jù)并且將中間結(jié)果輸出到磁盤(pán)上。然而Presto引擎沒(méi)有使用Map-Reduce。它使用了一個(gè)定制的查詢執(zhí)行引擎和響應(yīng) 操作符來(lái)支持SQL的語(yǔ)法。除了改進(jìn)的調(diào)度算法之外，所有的數(shù)據(jù)處理都是在內(nèi)存中進(jìn)行的。不同的處理端通過(guò)網(wǎng)絡(luò)組成處理的流水線。這樣會(huì)避免不必要的磁盤(pán) 讀寫(xiě)和額外的延遲。這種流水線式的執(zhí)行模型會(huì)在同一時(shí)間運(yùn)行多個(gè)數(shù)據(jù)處理段，一旦數(shù)據(jù)可用的時(shí)候就會(huì)將數(shù)據(jù)從一個(gè)處理段傳入到下一個(gè)處理段。 這樣的方式會(huì)大大的減少各種查詢的端到端響應(yīng)時(shí)間。同時(shí)，Presto設(shè)計(jì)了一個(gè)簡(jiǎn)單的數(shù)據(jù)存儲(chǔ)抽象層，來(lái)滿足在不同數(shù)據(jù)存儲(chǔ)系統(tǒng)之上都可以使用SQL進(jìn) 行查詢。存儲(chǔ)連接器目前支持除Hive/HDFS外，還支持HBase、Scribe和定制開(kāi)發(fā)的系統(tǒng)。

圖8. Presto架構(gòu)

性能評(píng)測(cè)總結(jié)

通過(guò)對(duì)Hive、Impala、Shark、Stinger和Presto的評(píng)測(cè)和分析，總結(jié)如下：

1) 列存儲(chǔ)一般對(duì)查詢性能提升明顯，尤其是大表是一個(gè)包含很多列的表。例如，從Stinger（Hive 0.11 with ORCFile）VS Hive，以及Impala的Parquet VS Text file；

2) 繞開(kāi)MR計(jì)算模型，省去中間結(jié)果的持久化和MR任務(wù)調(diào)度的延遲，會(huì)帶來(lái)性能提升。例如，Impala，Shark，Presto要好于Hive和Stinger，但這種優(yōu)勢(shì)隨著數(shù)據(jù)量增加和查詢變復(fù)雜而減弱；

3) 使用MPP數(shù)據(jù)庫(kù)技術(shù)對(duì)連接查詢有幫助。例如，Impala在兩表，多表連接查詢中優(yōu)勢(shì)明顯；

4) 充分利用緩存的系統(tǒng)在內(nèi)存充足的情況下性能優(yōu)勢(shì)明顯。例如，Shark，Impala在小數(shù)據(jù)量時(shí)性能優(yōu)勢(shì)明顯；內(nèi)存不足時(shí)性能下降嚴(yán)重，Shark會(huì)出現(xiàn)很多問(wèn)題；

5) 數(shù)據(jù)傾斜會(huì)嚴(yán)重影響一些系統(tǒng)的性能。例如，Hive、Stinger、Shark對(duì)數(shù)據(jù)傾斜比較敏感，容易造成傾斜；Impala受這方面的影響似乎不大；

對(duì)于Hive、Impala、Shark、Stinger和Presto這五類開(kāi)源的分析引擎，在大多數(shù)情況下，Imapla的綜合性能是最穩(wěn)定的，時(shí)間 性能也是最好的，而且其安裝配置過(guò)程也相對(duì)容易。其他分別為Presto、Shark、Stinger和Hive。在內(nèi)存足夠和非Join操作情況 下，Shark的性能是最好的。

總結(jié)與展望

對(duì)大數(shù)據(jù)分析的項(xiàng)目來(lái)說(shuō)，技術(shù)往往不是最關(guān)鍵的，關(guān)鍵在于誰(shuí)的生態(tài)系統(tǒng)更強(qiáng)，技術(shù)上一時(shí)的領(lǐng)先并不足以保證項(xiàng)目的最終成功。對(duì)于Hive、 Impala、Shark、Stinger和Presto來(lái)講，最后哪一款產(chǎn)品會(huì)成為事實(shí)上的標(biāo)準(zhǔn)還很難說(shuō)，但我們唯一可以確定并堅(jiān)信的一點(diǎn)是，大數(shù)據(jù)分 析將隨著新技術(shù)的不斷推陳出新而不斷普及開(kāi)來(lái)，這對(duì)用戶永遠(yuǎn)都是一件幸事。舉個(gè)例子，如果讀者注意過(guò)下一代Hadoop（YARN）的發(fā)展的話就會(huì)發(fā)現(xiàn)， 其實(shí)YARN已經(jīng)支持Map-Reduce之外的計(jì)算范式（例如Shark，Impala等），因此將來(lái)Hadoop將可能作為一個(gè)兼容并包的大平臺(tái)存 在，在其上提供各種各樣的數(shù)據(jù)處理技術(shù)，有應(yīng)對(duì)秒量級(jí)查詢的，有應(yīng)對(duì)大數(shù)據(jù)批處理的，各種功能應(yīng)有盡有，滿足用戶各方面的需求。

除了Hive、Impala、Shark、Stinger和Presto這樣的開(kāi)源方案外，像Oracle，EMC等傳統(tǒng)廠商也沒(méi)在坐以待斃等著自己的市 場(chǎng)被開(kāi)源軟件侵吞。像EMC就推出了HAWQ系統(tǒng)，并號(hào)稱其性能比之Impala快上十幾倍，而Amazon的Redshift也提供了比Impala更 好的性能。雖然說(shuō)開(kāi)源軟件因?yàn)槠鋸?qiáng)大的成本優(yōu)勢(shì)而擁有極其強(qiáng)大的力量，但是傳統(tǒng)數(shù)據(jù)庫(kù)廠商仍會(huì)嘗試推出性能、穩(wěn)定性、維護(hù)服務(wù)等指標(biāo)上更加強(qiáng)大的產(chǎn)品與之 進(jìn)行差異化競(jìng)爭(zhēng)，并同時(shí)參與開(kāi)源社區(qū)、借力開(kāi)源軟件來(lái)豐富自己的產(chǎn)品線、提升自己的競(jìng)爭(zhēng)力，并通過(guò)更多的高附加值服務(wù)來(lái)滿足某些消費(fèi)者需求。畢竟，這些廠 商往往已在并行數(shù)據(jù)庫(kù)等傳統(tǒng)領(lǐng)域積累了大量的技術(shù)和經(jīng)驗(yàn)，這些底蘊(yùn)還是非常深厚的。總的來(lái)看，未來(lái)的大數(shù)據(jù)分析技術(shù)將會(huì)變得越來(lái)越成熟、越來(lái)越便宜、越來(lái) 越易用；相應(yīng)的，用戶將會(huì)更容易更方便地從自己的大數(shù)據(jù)中挖掘出有價(jià)值的商業(yè)信息。