Hadoop通常被認(rèn)定是能夠幫助你解決所有問(wèn)題的唯一方案。 當(dāng)人們提到“大數(shù)據(jù)”或是“數(shù)據(jù)分析”等相關(guān)問(wèn)題的時(shí)候，會(huì)聽(tīng)到脫口而出的回答：Hadoop!實(shí)際上Hadoop被設(shè)計(jì)和建造出來(lái)，是用來(lái)解決一系列特 定問(wèn)題的。對(duì)某些問(wèn)題來(lái)說(shuō)，Hadoop至多算是一個(gè)不好的選擇。對(duì)另一些問(wèn)題來(lái)說(shuō)，選擇Hadoop甚至?xí)且粋€(gè)錯(cuò)誤。對(duì)于數(shù)據(jù)轉(zhuǎn)換的操作，或者更廣泛 意義上的抽取-轉(zhuǎn)換-裝載的操作(譯者注：Extraction Transformation Load，ETL，數(shù)據(jù)倉(cāng)庫(kù)中對(duì)數(shù)據(jù)從初始狀態(tài)到可用狀態(tài)處理過(guò)程的經(jīng)典定義)， 使用Hadoop系統(tǒng)能夠得到很多好處， 但是如果你的問(wèn)題是下面5類(lèi)之中的一個(gè)的話，Hadoop可能會(huì)是一不合適的解決方案。

1.對(duì)于大數(shù)據(jù)的渴望

很多人相信他們擁有正真“大”的數(shù)據(jù)， 但通常情況并非如此。 當(dāng)考慮數(shù)據(jù)容量和理解大多數(shù)人對(duì)“大數(shù)據(jù)”處理的想法的時(shí)候， 我們應(yīng)當(dāng)參考這篇研究論文， 沒(méi)有人會(huì)因?yàn)橘I(mǎi)了一個(gè)集群的服務(wù)器而被辭退， 它告訴了我們一些有趣的事實(shí)。 Hadoop是被設(shè)計(jì)成用來(lái)處理在TB或PB級(jí)別的數(shù)據(jù)的， 而世界上大多數(shù)的計(jì)算任務(wù)處理的是100GB以下的輸入數(shù)據(jù)。(Microsoft和Yahoo在這個(gè)數(shù)據(jù)統(tǒng)計(jì)上的中位數(shù)是14GB,而90% Facebook的任務(wù)處理的是100GB以下的數(shù)據(jù))。對(duì)于這樣的情況來(lái)說(shuō)， 縱向擴(kuò)展的解決方案就會(huì)在性能上勝過(guò)橫向擴(kuò)展(scale-out)的解決方案。

(譯者注：縱向擴(kuò)展scale-up通常是指在一臺(tái)機(jī)器上增加或更換內(nèi)存、CPU、硬盤(pán)或網(wǎng)絡(luò)設(shè)備等硬件來(lái)實(shí)現(xiàn)系統(tǒng)整體性能的提升, 橫向擴(kuò)展(scale-out)指的是通過(guò)在集群中增加機(jī)器來(lái)提升集群系統(tǒng)整體性能的提升。論文中比較了對(duì)Hadoop系統(tǒng)進(jìn)行各種縱向擴(kuò)展和橫向擴(kuò)展之 后， 在性能指標(biāo)上進(jìn)行評(píng)測(cè)的試驗(yàn)。結(jié)論是在某些情況下在一臺(tái)機(jī)器上的縱向擴(kuò)展會(huì)比在Hadoop集群中增加機(jī)器得到更高的系統(tǒng)性能，而且性?xún)r(jià)比會(huì)更好。這個(gè)結(jié) 論打破了大多數(shù)人對(duì)Hadoop系統(tǒng)的簡(jiǎn)單認(rèn)識(shí)， 那就是一定要用若干廉價(jià)的機(jī)器組成集群才能到達(dá)最好的整體性能。 )

所以你需要問(wèn)自己：

我是否有超過(guò)幾個(gè)TB的數(shù)據(jù)？

我是否有穩(wěn)定、海量的輸入數(shù)據(jù)？

我有多少數(shù)據(jù)要操作和處理？

2.你在隊(duì)列中

當(dāng)你在Hadoop系統(tǒng)中提交計(jì)算任務(wù)的時(shí)候， 最小的延遲時(shí)間是1分鐘 。 這意味系統(tǒng)對(duì)于客戶(hù)的商品購(gòu)買(mǎi)信息要花1分鐘的時(shí)間才能響應(yīng)并提供相關(guān)商品推薦。這要求系統(tǒng)有非常忠實(shí)和耐心的客戶(hù)， 盯著電腦屏幕超過(guò)60秒鐘等待結(jié)果的出現(xiàn)。 一種好的方案是將庫(kù)存中的每一件商品都做一個(gè)預(yù)先的相關(guān)商品的計(jì)算， 放在Hadoop上。 然后提供一個(gè)網(wǎng)站，或者是移動(dòng)應(yīng)用來(lái)訪問(wèn)預(yù)先存儲(chǔ)的結(jié)果，達(dá)到1秒或以下的即時(shí)響應(yīng)。 Hadoop是一個(gè)非常好的做預(yù)先計(jì)算的大數(shù)據(jù)引擎。 當(dāng)然，隨著需要返回的數(shù)據(jù)越來(lái)越復(fù)雜，完全的預(yù)先計(jì)算會(huì)變得越來(lái)越?jīng)]有效率。

所以你需要問(wèn)自己：

用戶(hù)期望的系統(tǒng)響應(yīng)時(shí)間大概在什么范圍？

哪些計(jì)算任務(wù)是可以通過(guò)批處理的方式來(lái)運(yùn)行的？

(譯者注：原作者應(yīng)該是用了B2C電子商務(wù)網(wǎng)站上經(jīng)典的商品推薦功能作為用例，描述如何用Hadoop實(shí)現(xiàn)這個(gè)功能。)

3.你的問(wèn)題會(huì)在多少時(shí)間內(nèi)得到響應(yīng)

對(duì)于要求實(shí)時(shí)響應(yīng)查詢(xún)的問(wèn)題來(lái)說(shuō)，Hadoop并不是一個(gè)好的解決方案。Hadoop的計(jì)算任務(wù)要在map和reduce上花費(fèi)時(shí)間， 并且在shuffle階段還要花時(shí)間。 這些過(guò)程都不是可以在限定時(shí)間內(nèi)可以完成的， 所以Hadoop并不適合用于開(kāi)發(fā)有實(shí)時(shí)性需求的應(yīng)用。一個(gè)實(shí)際的例子是，在期貨或股票市場(chǎng)的程序化交易系統(tǒng)(Program Trading)中用到的成交量加權(quán)平均價(jià)格(Volume-weighted average price，VWAP)的計(jì)算，通常是實(shí)時(shí)的。這要求交易系統(tǒng)在限定時(shí)間內(nèi)將結(jié)果給到用戶(hù)，使得他們能夠進(jìn)行交易。

(譯者注：Hadoop的MapReduce中的shuffle過(guò)程指的是將多個(gè)map任務(wù)的結(jié)果分配給一個(gè)或多個(gè)reduc任務(wù)是的數(shù)據(jù)洗牌和分配的操作，這篇blog解釋的比較詳細(xì)，http://langyu.iteye.com/blog/992916 。 這里的用例是在投資銀行的程序交易中，如何計(jì)算股票或期貨交易的基準(zhǔn)價(jià)格。 這樣的計(jì)算我覺(jué)得每次對(duì)數(shù)據(jù)的查詢(xún)響應(yīng)時(shí)間應(yīng)該是在100ms以下的，詳見(jiàn)http://baike.baidu.com/view/1280239.htm，http://baike.baidu.com/view/945603.htm。關(guān)于這個(gè)例子，相信投行的xdjm們應(yīng)該有更多的發(fā)言權(quán)。)

對(duì)數(shù)據(jù)分析人員來(lái)說(shuō)， 他們實(shí)際上非常想使用SQL這樣的查詢(xún)語(yǔ)言的。Hadoop系統(tǒng)并不能很好地支持對(duì)存儲(chǔ)在Hadoop上的數(shù)據(jù)的隨即訪問(wèn) 。即便你使用了HIVE來(lái)幫助將你的類(lèi)似SQL的查詢(xún)轉(zhuǎn)換成特定MapReduce計(jì)算任務(wù)的時(shí)候， 數(shù)據(jù)的隨機(jī)訪問(wèn)也不是Hadoop的強(qiáng)項(xiàng)。Google的Dremel系統(tǒng)(和它的擴(kuò)展， BigQuery系統(tǒng))被設(shè)計(jì)成能夠在幾秒中之內(nèi)返回海量的數(shù)據(jù)。啟示SQL還能夠很好地支持?jǐn)?shù)據(jù)表之間的各種join操作。 另外一些支持實(shí)時(shí)響應(yīng)的技術(shù)方案包括，從Berkley 加州分校(University of California, Berkeley)的AmpLab誕生的Shark項(xiàng)目， 以及Horntoworks領(lǐng)導(dǎo)的Stinger項(xiàng)目等。

所以你需要問(wèn)自己：

你的用戶(hù)和分析人員期望的數(shù)據(jù)訪問(wèn)的交互性和實(shí)時(shí)性要求是怎樣的？

你的用戶(hù)希望要能夠訪問(wèn)TB級(jí)別的數(shù)據(jù)嗎，還是只需要訪問(wèn)其中的一部分?jǐn)?shù)據(jù)？

(譯者注：Apache Hive 是Hadoop生態(tài)系統(tǒng)中的一個(gè)開(kāi)源項(xiàng)目，其主要目的是在Hadoop系統(tǒng)上提供接近ANSI SQL的數(shù)據(jù)操作，以方便熟悉SQL語(yǔ)言的數(shù)據(jù)分析人員對(duì)Hadoop上的數(shù)據(jù)進(jìn)行查詢(xún)。Dremel 系統(tǒng)是Google開(kāi)發(fā)的支持大數(shù)據(jù)的實(shí)時(shí)查詢(xún)系統(tǒng)，它利用了精心設(shè)計(jì)的列式存儲(chǔ)結(jié)構(gòu)和大規(guī)模并行查詢(xún)的機(jī)制， 在測(cè)試中能夠到達(dá)在3秒內(nèi)在分析和查詢(xún)1PB數(shù)據(jù)的性能(英文論文，中文翻譯 )。 BigQuery是Google基于Dremel開(kāi)發(fā)出的開(kāi)放給開(kāi)發(fā)人員的SaaS服務(wù)，可以對(duì)大量數(shù)據(jù)進(jìn)行操作 。Berkeley Data Analytics Stack, BDAS 是AmpLab提供的基于Hadoop的大數(shù)據(jù)平臺(tái)， 包含多個(gè)開(kāi)源項(xiàng)目， 詳見(jiàn)https://amplab.cs.berkeley.edu/software/。 Spark項(xiàng)目是BDAS中的一個(gè)項(xiàng)目， 它使用Scala語(yǔ)言開(kāi)發(fā)，提供了類(lèi)似于SQL的數(shù)據(jù)操作接口，完全兼容Hive。其主要的特點(diǎn)是利用底層的Spark將查詢(xún)翻譯為具體的計(jì)算任務(wù)。 Spark會(huì)通過(guò)大量使用Hadoop集群中結(jié)點(diǎn)上內(nèi)存的方式來(lái)進(jìn)行數(shù)據(jù)緩存和在內(nèi)存中進(jìn)行實(shí)時(shí)計(jì)算， 達(dá)到加速查詢(xún)和計(jì)算的目的。詳見(jiàn)http://shark.cs.berkeley.edu/。 Hortonworks是目前幾家專(zhuān)注于提供基于Hadoop的大數(shù)據(jù)系統(tǒng)和應(yīng)用的公司之一， Stinger是用來(lái) Horontoworks提出的為了提升Hive查詢(xún)性能的一系列在基于Hadoop的項(xiàng)目和改進(jìn)的總稱(chēng)，其主要方法是優(yōu)化Hive的文件存儲(chǔ)格式以及針 對(duì)Hive的查詢(xún)請(qǐng)求進(jìn)行分析優(yōu)化。)

我們應(yīng)該認(rèn)識(shí)到， Hadoop是在批處理的模式下工作的。 這意味著當(dāng)有新的數(shù)據(jù)被添加進(jìn)來(lái)的時(shí)候， 數(shù)據(jù)處理的計(jì)算任務(wù)需要在整個(gè)數(shù)據(jù)集合上重新運(yùn)行一遍。所以，隨著數(shù)據(jù)的增長(zhǎng)，數(shù)據(jù)分析的時(shí)間也會(huì)隨之增加。 在實(shí)際情況下，小塊新數(shù)據(jù)的增加、單一種類(lèi)的數(shù)據(jù)更改或者微量數(shù)據(jù)的更新都會(huì)實(shí)時(shí)地發(fā)生。通常， 商業(yè)程序都需要根據(jù)這些事件進(jìn)行決策。 然而，不論這些數(shù)據(jù)多么迅速地被輸入到Hadoop系統(tǒng)，在Hadoop處理這些數(shù)據(jù)的時(shí)候，仍然是通過(guò)批處理的方式。Hadoop 2.0的MapReduce框架YARN承諾將解決這個(gè)問(wèn)題。 Twitter使用的Storm平臺(tái)是另一個(gè)可行的、流行的備選方案。將Storm和例如Kafka這樣的分布式消息系統(tǒng)結(jié)合在一起，可以支持流數(shù)據(jù)處理 和匯總的各種需求。痛苦的是，目前Storm并不支持負(fù)載平衡，但是Yahoo的S4版本中會(huì)提供。

所以你需要問(wèn)自己：

我的數(shù)據(jù)的生命周期是多長(zhǎng)？

我的業(yè)務(wù)需要多迅速地從輸入數(shù)據(jù)中獲得價(jià)值？

對(duì)我的業(yè)務(wù)來(lái)說(shuō)響應(yīng)實(shí)時(shí)的數(shù)據(jù)變化和更新有多重要？

實(shí)時(shí)性的廣告應(yīng)用和收集傳感器的監(jiān)控應(yīng)用都要求對(duì)流數(shù)據(jù)的實(shí)時(shí)處理。 Hadoop以及之上的工具并不是解決這類(lèi)問(wèn)題的唯一選擇。 在最近的Indy 500車(chē)賽中，邁凱輪車(chē)隊(duì)在他們的ATLAS系統(tǒng)中使用了SAP的HANA內(nèi)存數(shù)據(jù)庫(kù)產(chǎn)品來(lái)進(jìn)行數(shù)據(jù)分析，并結(jié)合Matlab來(lái)進(jìn)行各種模擬，對(duì)比賽中實(shí) 時(shí)得到的賽車(chē)遙測(cè)數(shù)據(jù)進(jìn)行分析和計(jì)算。很多數(shù)據(jù)分析人員認(rèn)為，Hadoop的未來(lái)在于能夠支持實(shí)時(shí)性和交互性的操作。

(譯者注：YARN是Hadoop2.0采用的新不同于MapReduce的資源管理和任務(wù)處理的框架，它號(hào)稱(chēng)能夠支持比MapReduce更廣的編程模型， 同時(shí)實(shí)現(xiàn)對(duì)實(shí)時(shí)查詢(xún)和計(jì)算的任務(wù)的支持，詳見(jiàn)http://hortonworks.com/hadoop/yarn/ 。Storm是由Twitter主導(dǎo)的開(kāi)源項(xiàng)目， 是一種分布式數(shù)據(jù)處理系統(tǒng)，其主要特點(diǎn)是能夠很好地支持實(shí)時(shí)性要求高的流數(shù)據(jù)處理，詳見(jiàn)http://storm-project.net 。淘寶和阿里巴巴都在使用Storm。Simple Scalable Streaming System， S4 是由Yahoo創(chuàng)建的另外一個(gè)實(shí)時(shí)流數(shù)據(jù)處理的分布式系統(tǒng)，詳見(jiàn)http://incubator.apache.org/s4/ 。這里有一篇網(wǎng)頁(yè)引用了很多比較Yahoo S4和Storm的文章，http://blog.softwareabstractions.com/the_software_abstractions/2013/06/links-comparing-yahoo-s4-and-storm-for-continuous-stream-processing-aka-real-time-big-data.html 。Kafka是Apache 的一個(gè)開(kāi)源項(xiàng)目，http://kafka.apache.org/。HANA是 SAP推出的商業(yè)產(chǎn)品，是可一個(gè)支持橫向擴(kuò)展的內(nèi)存數(shù)據(jù)庫(kù)解決方案，可以支持實(shí)時(shí)的大數(shù)據(jù)分析和計(jì)算。詳見(jiàn) http://www.sap.com/HANA。 Matlab是Mathworks公司開(kāi)發(fā)的一個(gè)用于科學(xué)計(jì)算的開(kāi)發(fā)類(lèi)產(chǎn)品， www.mathworks.com/products/matlab. McLaren 車(chē)隊(duì)是著名的英國(guó)F1車(chē)隊(duì)， 它是F1方程式比賽中一支非常成功的隊(duì)伍。同時(shí)他們也參加美國(guó)著名的Indy 500賽車(chē)比賽。他們使用大數(shù)據(jù)平臺(tái)處理賽車(chē)數(shù)據(jù)來(lái)提高賽車(chē)成績(jī)的故事可以看這篇文章，http://blogs.gartner.com/doug-laney/the-indy-500-big-race-bigger-data/ )

4.我才和我的社交網(wǎng)絡(luò)分手

當(dāng)數(shù)據(jù)能夠被分解為鍵值對(duì)，又不用擔(dān)心丟失上下文或者某些數(shù)據(jù)之間隱性關(guān)系的時(shí)候，Hadoop，特別是MapReduce框架，是最好的選擇。但 是圖這樣的數(shù)據(jù)結(jié)構(gòu)中包含著各種隱性的關(guān)系， 如圖的邊、子樹(shù) 、節(jié)點(diǎn)之間的父子關(guān)系、權(quán)重等，而且這些關(guān)系并非都能在圖中一個(gè)結(jié)點(diǎn)上表示。這樣的特性就要求處理圖的算法要在每一次的迭代計(jì)算中加入當(dāng)前圖的完整或部分 的信息。 這樣的算法基本上用MapReduce的框架是不可能實(shí)現(xiàn)的，即便能夠?qū)崿F(xiàn)也會(huì)是一種很迂回的解決方案。 另外一個(gè)問(wèn)題是如何制定將數(shù)據(jù)切分到不同結(jié)點(diǎn)上的策略。如果你要處理的數(shù)據(jù)的主要數(shù)據(jù)結(jié)構(gòu)是圖或者是網(wǎng)絡(luò)， 那么你最好選擇使用面向圖的數(shù)據(jù)庫(kù)，比如NeoJ或者Dex。或者你可以去研究一下最新的Google Pregel 或者Apache Giraph項(xiàng)目。

所以你需要問(wèn)自己：

我的數(shù)據(jù)的底層結(jié)構(gòu)是否和數(shù)據(jù)本身一樣重要？

我希望從數(shù)據(jù)的結(jié)構(gòu)中得到的啟發(fā)和見(jiàn)解，是否和數(shù)據(jù)本身一樣重要， 甚至更重要？

(譯者注：NeoJ 擁有商業(yè)和GPL雙許可證模式，詳見(jiàn)http://www.neo4j.org/，Dex是商業(yè)產(chǎn)品，詳見(jiàn)http://www.sparsity-technologies.com/dex 。Apache Giraph 項(xiàng)目http://giraph.apache.org 是根據(jù)Google Pregel論文http://dl.acm.org/citation.cfm?id=1807184， http://kowshik.github.io/JPregel/pregel_paper.pdf 的開(kāi)源實(shí)現(xiàn) ，是用來(lái)分析社交網(wǎng)絡(luò)這樣可以被抽象為圖或網(wǎng)絡(luò)數(shù)據(jù)結(jié)構(gòu)的大數(shù)據(jù)處理平臺(tái)。 )

5.MapReduce的模具

很多的計(jì)算任務(wù)、工作及算法從本質(zhì)上來(lái)說(shuō)就是不適合使用MapReduce框架的。 上一章中已經(jīng)談到了其中一類(lèi)的問(wèn)題。另一類(lèi)的問(wèn)題是，某些計(jì)算任務(wù)需要上一步計(jì)算的結(jié)果來(lái)進(jìn)行當(dāng)前一步的計(jì)算。一個(gè)數(shù)學(xué)上的例子就是斐波那契數(shù)列的計(jì)算。 某些機(jī)器學(xué)習(xí)的算法，如梯度和最大期望等，也不是很適合使用MapReduce的模式。很多研究人員已經(jīng)對(duì)實(shí)現(xiàn)這些算法中需要的特定優(yōu)化和策略(全局狀 態(tài)，計(jì)算時(shí)將數(shù)據(jù)結(jié)構(gòu)傳入進(jìn)行引用等)給出了建議，但是如果用Hadoop來(lái)實(shí)現(xiàn)具體算法的話，還是會(huì)變得很復(fù)雜而且不易被理解。

所以你需要問(wèn)自己：

我的業(yè)務(wù)是否對(duì)特定的算法或者領(lǐng)域相關(guān)的流程有非常高的要求？

技術(shù)團(tuán)隊(duì)是否有足夠的能力和資源來(lái)分析算法是否可以使用MapReduce框架？

(譯者注：梯度方法， gradient method通常用于數(shù)學(xué)優(yōu)化計(jì)算中，詳見(jiàn)http://zh.wikipedia.org/wiki/%E6%A2%AF%E5%BA%A6%E4%B8%8B%E9%99%8D%E6%B3%95。最大期望算法maximization expectation algorithm ，通常用于概率模型及相應(yīng)的機(jī)器學(xué)習(xí)算法中， http://zh.wikipedia.org/zh-cn/%E6%9C%80%E5%A4%A7%E6%9C%9F%E6%9C%9B%E7%AE%97%E6%B3%95 )

除此之外，需要考慮另外一些情況， 比如，數(shù)據(jù)總量并不大，或者數(shù)據(jù)集雖然很大，但主要是由上億的小文件組成，而且不能拼接(如，許多圖形文件需要以不同的形狀被輸入進(jìn)來(lái))。正如我們之前說(shuō) 到的，對(duì)于那些不適合使用MapReduce分割、合并原則的計(jì)算任務(wù)，如果用Hadoop來(lái)實(shí)現(xiàn)他們的話，會(huì)讓Hadoop的使用變得大費(fèi)周折。

現(xiàn)在我們已經(jīng)分析了在哪些情況下Hadoop不合適，讓我們看一下在哪些情況下使用Hadoop是正確的選擇。

你需要問(wèn)自己，你的組織是否，

想要從一堆文本格式的日志文件中抽取信息？

想要將大多數(shù)是非結(jié)構(gòu)化或者半結(jié)構(gòu)化的數(shù)據(jù)轉(zhuǎn)換為有用的、結(jié)構(gòu)化的格式？

有沒(méi)有計(jì)算任務(wù)是每天晚上在整個(gè)數(shù)據(jù)集合上運(yùn)行的？(比如說(shuō)信用卡公司在晚上處理所有白天的交易記錄)

從一次數(shù)據(jù)處理中獲取的結(jié)論和下一次計(jì)劃要處理的結(jié)論是一致的(不像股票市場(chǎng)的價(jià)格，每一天都在變化)？

如果以上答案都為“是”，那么你就應(yīng)該深入研究Hadoop。

以上所談到的幾類(lèi)問(wèn)題代表了相當(dāng)大部分能夠用Hadoop來(lái)解決的商業(yè)問(wèn)題(盡管很多行業(yè)報(bào)告的結(jié)論是將這些類(lèi)別的Hadoop系統(tǒng)部署到生產(chǎn)環(huán)境 中并不是一件容易的事情)。對(duì)于某些計(jì)算任務(wù)，Hadoop的計(jì)算模型是非常合適的。 比如說(shuō)， 你需要處理海量的非結(jié)構(gòu)化或半結(jié)構(gòu)化的數(shù)據(jù)，然后將內(nèi)容進(jìn)行匯總或者將相關(guān)計(jì)算結(jié)果轉(zhuǎn)換成結(jié)構(gòu)化的數(shù)據(jù)， 并且將結(jié)果提供給其他組件或系統(tǒng)使用。如果收集的數(shù)據(jù)可以很容易地被轉(zhuǎn)換位一個(gè)ID以及和它對(duì)應(yīng)的內(nèi)容(用Hadoop的術(shù)語(yǔ)來(lái)說(shuō)就是鍵值對(duì)，key- value pair)，那么你就可以使用這種簡(jiǎn)單的關(guān)聯(lián)來(lái)進(jìn)行不同種類(lèi)的匯總計(jì)算。

總的來(lái)說(shuō)， 關(guān)鍵是要認(rèn)清你擁有的各種資源，并且理解想要解決的問(wèn)題的本質(zhì)。 結(jié)合本文提到的一些觀點(diǎn)和你自己的理解和認(rèn)識(shí)， 你就能夠選擇最適合你的工具。 在某些情況下， 最終的解決方案很有可能是Hadoop。

你在使用Hadoop方面有哪些經(jīng)驗(yàn)和教訓(xùn)？ 請(qǐng)?jiān)谠u(píng)論中分享吧。