用Hadoop，還是不用Hadoop？
Hadoop通常被認定是能夠幫助你解決所有問題的唯一方案。 當人們提到“大數據”或是“數據分析”等相關問題的時候，會聽到脫口而出的回答：Hadoop！實際上Hadoop被設計和建造出來，是用來解決一系列特定問題的。對某些問題來說，Hadoop至多算是一個不好的選擇。對另一些問題來說，選擇Hadoop甚至會是一個錯誤。對于數據轉換的操作，或者更廣泛意義上的抽取－轉換－裝載的操作（譯者注：Extraction Transformation Load，ETL，數據倉庫中對數據從初始狀態到可用狀態處理過程的經典定義)， 使用Hadoop系統能夠得到很多好處， 但是如果你的問題是下面5類之中的一個的話，Hadoop可能會是一不合適的解決方案。
1.對于大數據的渴望
很多人相信他們擁有正真“大”的數據， 但通常情況并非如此。 當考慮數據容量和理解大多數人對“大數據”處理的想法的時候， 我們應當參考這篇研究論文， 沒有人會因為買了一個集群的服務器而被辭退，它告訴了我們一些有趣的事實。 Hadoop是被設計成用來處理在TB或PB級別的數據的， 而世界上大多數的計算任務處理的是100GB以下的輸入數據。（Microsoft和Yahoo在這個數據統計上的中位數是14GB,而90% Facebook的任務處理的是100GB以下的數據）。對于這樣的情況來說， 縱向擴展的解決方案就會在性能上勝過橫向擴展（scale-out）的解決方案。
（譯者注：縱向擴展scale-up通常是指在一臺機器上增加或更換內存、CPU、硬盤或網絡設備等硬件來實現系統整體性能的提升, 橫向擴展（scale-out）指的是通過在集群中增加機器來提升集群系統整體性能的提升。論文中比較了對Hadoop系統進行各種縱向擴展和橫向擴展之后， 在性能指標上進行評測的試驗。結論是在某些情況下在一臺機器上的縱向擴展會比在Hadoop集群中增加機器得到更高的系統性能，而且性價比會更好。這個結論打破了大多數人對Hadoop系統的簡單認識， 那就是一定要用若干廉價的機器組成集群才能到達最好的整體性能。 ）
所以你需要問自己：
- 我是否有超過幾個TB的數據？
- 我是否有穩定、海量的輸入數據？
- 我有多少數據要操作和處理？
2.你在隊列中
當你在Hadoop系統中提交計算任務的時候， 最小的延遲時間是1分鐘 。 這意味系統對于客戶的商品購買信息要花1分鐘的時間才能響應并提供相關商品推薦。這要求系統有非常忠實和耐心的客戶， 盯著電腦屏幕超過60秒鐘等待結果的出現。 一種好的方案是將庫存中的每一件商品都做一個預先的相關商品的計算， 放在Hadoop上。 然后提供一個網站，或者是移動應用來訪問預先存儲的結果，達到1秒或以下的即時響應。 Hadoop是一個非常好的做預先計算的大數據引擎。 當然，隨著需要返回的數據越來越復雜，完全的預先計算會變得越來越沒有效率。
所以你需要問自己：
- 用戶期望的系統響應時間大概在什么范圍？
- 哪些計算任務是可以通過批處理的方式來運行的？
（譯者注：原作者應該是用了B2C電子商務網站上經典的商品推薦功能作為用例，描述如何用Hadoop實現這個功能。）
3.你的問題會在多少時間內得到響應
對于要求實時響應查詢的問題來說，Hadoop并不是一個好的解決方案。Hadoop的計算任務要在map和reduce上花費時間， 并且在shuffle階段還要花時間。 這些過程都不是可以在限定時間內可以完成的， 所以Hadoop并不適合用于開發有實時性需求的應用。一個實際的例子是，在期貨或股票市場的程序化交易系統（Program Trading）中用到的成交量加權平均價格（Volume-weighted average price，VWAP）的計算，通常是實時的。這要求交易系統在限定時間內將結果給到用戶，使得他們能夠進行交易。
（譯者注：Hadoop的MapReduce中的shuffle過程指的是將多個map任務的結果分配給一個或多個reduc任務是的數據洗牌和分配的操作，這篇blog解釋的比較詳細，http://langyu.iteye.com/blog/992916 。 這里的用例是在投資銀行的程序交易中，如何計算股票或期貨交易的基準價格。 這樣的計算我覺得每次對數據的查詢響應時間應該是在100ms以下的，詳見http://baike.baidu.com/view/1280239.htm，http://baike.baidu.com/view/945603.htm。關于這個例子，相信投行的xdjm們應該有更多的發言權。）
對數據分析人員來說， 他們實際上非常想使用SQL這樣的查詢語言的。Hadoop系統并不能很好地支持對存儲在Hadoop上的數據的隨即訪問 。即便你使用了HIVE來幫助將你的類似SQL的查詢轉換成特定MapReduce計算任務的時候， 數據的隨機訪問也不是Hadoop的強項。Google的Dremel系統（和它的擴展， BigQuery系統）被設計成能夠在幾秒中之內返回海量的數據。啟示SQL還能夠很好地支持數據表之間的各種join操作。 另外一些支持實時響應的技術方案包括，從Berkley 加州分校（University of California, Berkeley）的AmpLab誕生的Shark項目， 以及Horntoworks領導的Stinger項目等。
所以你需要問自己：
- 你的用戶和分析人員期望的數據訪問的交互性和實時性要求是怎樣的？
- 你的用戶希望要能夠訪問TB級別的數據嗎，還是只需要訪問其中的一部分數據？
（譯者注：Apache Hive 是Hadoop生態系統中的一個開源項目，其主要目的是在Hadoop系統上提供接近ANSI SQL的數據操作，以方便熟悉SQL語言的數據分析人員對Hadoop上的數據進行查詢。Dremel 系統是Google開發的支持大數據的實時查詢系統，它利用了精心設計的列式存儲結構和大規模并行查詢的機制， 在測試中能夠到達在3秒內在分析和查詢1PB數據的性能（英文論文，中文翻譯 ）。 BigQuery是Google基于Dremel開發出的開放給開發人員的SaaS服務，可以對大量數據進行操作 。Berkeley Data Analytics Stack, BDAS 是AmpLab提供的基于Hadoop的大數據平臺， 包含多個開源項目， 詳見https://amplab.cs.berkeley.edu/software/。Spark項目是BDAS中的一個項目， 它使用Scala語言開發，提供了類似于SQL的數據操作接口，完全兼容Hive。其主要的特點是利用底層的Spark將查詢翻譯為具體的計算任務。Spark會通過大量使用Hadoop集群中結點上內存的方式來進行數據緩存和在內存中進行實時計算， 達到加速查詢和計算的目的。詳見http://shark.cs.berkeley.edu/。Hortonworks是目前幾家專注于提供基于Hadoop的大數據系統和應用的公司之一， Stinger是用來 Horontoworks提出的為了提升Hive查詢性能的一系列在基于Hadoop的項目和改進的總稱，其主要方法是優化Hive的文件存儲格式以及針對Hive的查詢請求進行分析優化。）
我們應該認識到， Hadoop是在批處理的模式下工作的。 這意味著當有新的數據被添加進來的時候， 數據處理的計算任務需要在整個數據集合上重新運行一遍。所以，隨著數據的增長，數據分析的時間也會隨之增加。 在實際情況下，小塊新數據的增加、單一種類的數據更改或者微量數據的更新都會實時地發生。通常， 商業程序都需要根據這些事件進行決策。 然而，不論這些數據多么迅速地被輸入到Hadoop系統，在Hadoop處理這些數據的時候，仍然是通過批處理的方式。Hadoop 2.0的MapReduce框架YARN承諾將解決這個問題。 Twitter使用的Storm平臺是另一個可行的、流行的備選方案。將Storm和例如Kafka這樣的分布式消息系統結合在一起，可以支持流數據處理和匯總的各種需求。痛苦的是，目前Storm并不支持負載平衡，但是Yahoo的S4版本中會提供。
所以你需要問自己：
- 我的數據的生命周期是多長？
- 我的業務需要多迅速地從輸入數據中獲得價值？
- 對我的業務來說響應實時的數據變化和更新有多重要？
實時性的廣告應用和收集傳感器的監控應用都要求對流數據的實時處理。 Hadoop以及之上的工具并不是解決這類問題的唯一選擇。 在最近的Indy 500車賽中，邁凱輪車隊在他們的ATLAS系統中使用了SAP的HANA內存數據庫產品來進行數據分析，并結合Matlab來進行各種模擬，對比賽中實時得到的賽車遙測數據進行分析和計算。很多數據分析人員認為，Hadoop的未來在于能夠支持實時性和交互性的操作。
（譯者注：YARN是Hadoop2.0采用的新不同于MapReduce的資源管理和任務處理的框架，它號稱能夠支持比MapReduce更廣的編程模型， 同時實現對實時查詢和計算的任務的支持，詳見http://hortonworks.com/hadoop/yarn/ 。Storm是由Twitter主導的開源項目， 是一種分布式數據處理系統，其主要特點是能夠很好地支持實時性要求高的流數據處理，詳見http://storm-project.net 。淘寶和阿里巴巴都在使用Storm。Simple Scalable Streaming System， S4 是由Yahoo創建的另外一個實時流數據處理的分布式系統，詳見http://incubator.apache.org/s4/ 。這里有一篇網頁引用了很多比較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 的一個開源項目，http://kafka.apache.org/。HANA是 SAP推出的商業產品，是可一個支持橫向擴展的內存數據庫解決方案，可以支持實時的大數據分析和計算。詳見http://www.sap.com/HANA。Matlab是Mathworks公司開發的一個用于科學計算的開發類產品， www.mathworks.com/products/matlab. McLaren 車隊是著名的英國F1車隊， 它是F1方程式比賽中一支非常成功的隊伍。同時他們也參加美國著名的Indy 500賽車比賽。他們使用大數據平臺處理賽車數據來提高賽車成績的故事可以看這篇文章，http://blogs.gartner.com/doug-laney/the-indy-500-big-race-bigger-data/ ）
4.我才和我的社交網絡分手
當數據能夠被分解為鍵值對，又不用擔心丟失上下文或者某些數據之間隱性關系的時候，Hadoop，特別是MapReduce框架，是最好的選擇。但是圖這樣的數據結構中包含著各種隱性的關系， 如圖的邊、子樹 、節點之間的父子關系、權重等，而且這些關系并非都能在圖中一個結點上表示。這樣的特性就要求處理圖的算法要在每一次的迭代計算中加入當前圖的完整或部分的信息。 這樣的算法基本上用MapReduce的框架是不可能實現的，即便能夠實現也會是一種很迂回的解決方案。 另外一個問題是如何制定將數據切分到不同結點上的策略。如果你要處理的數據的主要數據結構是圖或者是網絡， 那么你最好選擇使用面向圖的數據庫，比如NeoJ或者Dex。或者你可以去研究一下最新的Google Pregel 或者Apache Giraph項目。
所以你需要問自己：
- 我的數據的底層結構是否和數據本身一樣重要？
- 我希望從數據的結構中得到的啟發和見解，是否和數據本身一樣重要， 甚至更重要？
（譯者注：NeoJ 擁有商業和GPL雙許可證模式，詳見http://www.neo4j.org/，Dex是商業產品，詳見http://www.sparsity-technologies.com/dex 。Apache Giraph 項目http://giraph.apache.org 是根據Google Pregel論文http://dl.acm.org/citation.cfm?id=1807184，http://kowshik.github.io/JPregel/pregel_paper.pdf 的開源實現 ，是用來分析社交網絡這樣可以被抽象為圖或網絡數據結構的大數據處理平臺。 ）
5.MapReduce的模具
很多的計算任務、工作及算法從本質上來說就是不適合使用MapReduce框架的。 上一章中已經談到了其中一類的問題。另一類的問題是，某些計算任務需要上一步計算的結果來進行當前一步的計算。一個數學上的例子就是斐波那契數列的計算。 某些機器學習的算法，如梯度和最大期望等，也不是很適合使用MapReduce的模式。很多研究人員已經對實現這些算法中需要的特定優化和策略（全局狀態，計算時將數據結構傳入進行引用等）給出了建議，但是如果用Hadoop來實現具體算法的話，還是會變得很復雜而且不易被理解。
所以你需要問自己：
- 我的業務是否對特定的算法或者領域相關的流程有非常高的要求？
- 技術團隊是否有足夠的能力和資源來分析算法是否可以使用MapReduce框架？
（譯者注：梯度方法， gradient method通常用于數學優化計算中，詳見http://zh.wikipedia.org/wiki/%E6%A2%AF%E5%BA%A6%E4%B8%8B%E9%99%8D%E6%B3%95。最大期望算法maximization expectation algorithm ，通常用于概率模型及相應的機器學習算法中，http://zh.wikipedia.org/zh-cn/%E6%9C%80%E5%A4%A7%E6%9C%9F%E6%9C%9B%E7%AE%97%E6%B3%95 ）
除此之外，需要考慮另外一些情況， 比如，數據總量并不大，或者數據集雖然很大，但主要是由上億的小文件組成，而且不能拼接（如，許多圖形文件需要以不同的形狀被輸入進來）。正如我們之前說到的，對于那些不適合使用MapReduce分割、合并原則的計算任務，如果用Hadoop來實現他們的話，會讓Hadoop的使用變得大費周折。
現在我們已經分析了在哪些情況下Hadoop不合適，讓我們看一下在哪些情況下使用Hadoop是正確的選擇。
你需要問自己，你的組織是否，
- 想要從一堆文本格式的日志文件中抽取信息？
- 想要將大多數是非結構化或者半結構化的數據轉換為有用的、結構化的格式？
- 有沒有計算任務是每天晚上在整個數據集合上運行的？（比如說信用卡公司在晚上處理所有白天的交易記錄）
- 從一次數據處理中獲取的結論和下一次計劃要處理的結論是一致的（不像股票市場的價格，每一天都在變化）？
如果以上答案都為“是”，那么你就應該深入研究Hadoop。
以上所談到的幾類問題代表了相當大部分能夠用Hadoop來解決的商業問題（盡管很多行業報告的結論是將這些類別的Hadoop系統部署到生產環境中并不是一件容易的事情）。對于某些計算任務，Hadoop的計算模型是非常合適的。 比如說， 你需要處理海量的非結構化或半結構化的數據，然后將內容進行匯總或者將相關計算結果轉換成結構化的數據， 并且將結果提供給其他組件或系統使用。如果收集的數據可以很容易地被轉換位一個ID以及和它對應的內容（用Hadoop的術語來說就是鍵值對，key-value pair)，那么你就可以使用這種簡單的關聯來進行不同種類的匯總計算。
總的來說， 關鍵是要認清你擁有的各種資源，并且理解想要解決的問題的本質。 結合本文提到的一些觀點和你自己的理解和認識， 你就能夠選擇最適合你的工具。 在某些情況下， 最終的解決方案很有可能是Hadoop。
你在使用Hadoop方面有哪些經驗和教訓？ 請在評論中分享吧。
本文由 伯樂在線 - Lex Lian 翻譯自 Anand Krishnaswamy。
