Hadoop不是解決大資料問題的唯一方案

第1頁：對於大資料的渴望


　　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級別的資料嗎，還是只需要訪問其中的一部分資料？


我們應該認識到， hadoop是在批次處理的模式下工作的。 這意味著當有新的資料被添加進來的時候， 資料處理的計算任務需要在整個資料集合上重新運行一遍。 所以，隨著資料的增長，資料分析的時間也會隨之增加。 在實際情況下，小塊新資料的增加、單一種類的資料更改或者微量資料的更新都會即時地發生。 通常， 商業程式都需要根據這些事件進行決策。 然而，不論這些資料多麼迅速地被輸入到hadoop系統，在hadoop處理這些資料的時候，仍然是通過批次處理的方式。 hadoop 2.0的mapreduce框架yarn承諾將解決這個問題。 twitter使用的storm平臺是另一個可行的、流行的備選方案。 將storm和例如kafka這樣的分散式消息系統結合在一起，可以支援流資料處理 和匯總的各種需求。 痛苦的是，目前storm並不支援負載平衡，但是yahoo的s4版本中會提供。


　　第2頁：


　　所以你需要問自己：


　　我的資料的生命週期是多長？


　　我的業務需要多迅速地從輸入資料中獲得價值？


　　對我的業務來說回應即時的資料變化和更新有多重要？


　　即時性的廣告應用和收集感應器的監控應用都要求對流資料的即時處理。 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。