大數(shù)據(jù)資料常見的Hadoop應用誤解

李榮

Hadoop是一個由Apache基金會所開發(fā)的分布式系統(tǒng)基礎架構。用戶可以在不了解分布式底層細節(jié)的情況下，開發(fā)分布式程序。并充分利用集群的威力進行高速運算和存儲。以下是常見的Hadoop十大應用誤解和正解。

1.（誤解）Hadoop什么都可以做

（正解）當一個新技術出來時，我們都會去思考它在各個不同產業(yè)的應用，而對于平臺的新技術來說，我們思考之后常會出現(xiàn)這樣的結論“這個好像什么都能做”，然而，更深入地去想，就會發(fā)現(xiàn)“好像什么都需要重頭做”。對于Hadoop，本人常喜歡舉數(shù)據(jù)庫（Database）來當例子。三十年前Database剛出來時，上面并沒有什么現(xiàn)成的應用方案（Application），所以廠商在銷售的過程中常需要花很多的時間去告訴客戶說，如果今天你有了這個數(shù)據(jù)庫，你就可以做什么什么的應用，而看起來的確好像數(shù)據(jù)庫什么應用都可以做，因為畢竟大部分的應用都會需要一個數(shù)據(jù)庫。只是三十年前所有的應用都得重頭打造，我們今天習以為常的ERP、CRM等應用系統(tǒng)，當時并不存在的。今天的Hadoop，正好有點像當年database剛出來的時候，畢竟今天所有的應用或多或少都會開始去處理半結構、非結構化數(shù)據(jù)，而這些東西的確都是Hadoop擅長的，所以平臺的適用性問題不大，重點還是在應用要由誰來搭建。

2.（誤解）Hadoop無法扮演HPC or Grid Computing的角色

（正解）由于Hadoop本身是由并行運算架構（MapReduce）與分布式文件系統(tǒng)（HDFS）所組成，所以我們看到很多研究機構或教育單位，開始嘗試把部分原本執(zhí)行在HPC或Grid上面的任務，移植到Hadoop集群上面，利用Hadoop兼顧高速運算與海量儲存的特性，更簡易且更有效率地來執(zhí)行工作。目前國外高能物理、生命科學和醫(yī)學等領域，都已經有這樣的應用案例，利用Hadoop集群與現(xiàn)有的HPC/Grid搭配、協(xié)同運作，滿足不同特性的運算任務。

3.（誤解）Hadoop只能做資料分析或挖掘

（正解）Hadoop特別適合來數(shù)據(jù)分析與挖掘的應用是毫無疑問的，但數(shù)據(jù)分析與挖掘是難度與深度都較高的一個應用，所需要的時間積累也比較長，因此讓一般企業(yè)對于導入Hadoop的數(shù)據(jù)進行分析視為畏途，甚至心懷恐懼。然而，從Etu知意圖團隊這一兩年來輔導客戶的經驗來看，其實更多的應用，大多都在數(shù)據(jù)處理（Data Processing）這個部分，或者更精確地來說，Hadoop這個平臺，特別適合數(shù)據(jù)預處理（Data preProcessing）這種應用場景。無論是數(shù)據(jù)倉庫的負載分流（DW Offload）、數(shù)據(jù)的匯總（Data Aggregation），或是運用協(xié)同過濾算法（Collaborative Filtering）針對線下線上零售業(yè)所做的精準推薦應用（Recommendation），廣義上來看，都可以說是屬于Data Processing的一環(huán)，畢竟，Big Data的來臨，我們看data、運用data的角度與方式都必須要有所改變。

Big Data強調的不是對因果關系的渴求，取而代之的是關注于data之間的相關關系。也就是說，重點在于要知道“是什么”，反而未必需要知道“為什么”。所以，它要求的是所有data的處理，而不只是隨機樣本的分析。

最后我們往往會發(fā)現(xiàn)，處理Big Data的簡單算法所得到的來自于data呈現(xiàn)的事實，往往比分析small data的復雜算法所得到的來自data背后的原因，對企業(yè)帶來的效益更大。

4.（誤解）Hadoop就是商業(yè)智能（Business Intelligence，BI）

（正解）跟前面一樣，這也是大多數(shù)人最容易誤解的地方，因為Hadoop特別適合來做數(shù)據(jù)分析，所以就很直覺地把它想成“那就是BI嘛”。會有這種誤解，主要來自于對數(shù)據(jù)運用的整體架構的不清楚。傳統(tǒng)BI是屬于數(shù)據(jù)展現(xiàn)層，其數(shù)據(jù)的載體（Data Store）是數(shù)據(jù)庫或數(shù)據(jù)倉庫。對比來看，Hadoop就是專注在半結構化、非結構化數(shù)據(jù)的數(shù)據(jù)載體，跟BI是不同層次的概念。當然，Hadoop除了Data Store外，又具備運算的特性，也因此特別容易帶來這種觀念上的混淆。至于半結構、非結構化數(shù)據(jù)的數(shù)據(jù)展現(xiàn)層部分，目前本身并不在Hadoop的生態(tài)體系內，而是由其他現(xiàn)有或新創(chuàng)的公司來填補這塊空缺，所以，逐漸地我們會看到越來越多現(xiàn)有的BI tool，開始強調其自身與Hadoop的聯(lián)系性與兼容性，同時，一些新創(chuàng)公司，也發(fā)展出完全不同于現(xiàn)有BI Tool基于Big Data的數(shù)據(jù)展現(xiàn)層。

5.（誤解）Hadoop就是ETL（Extract， Transform & Load）

（正解）ETL其實有2種涵意，它本身是一個概念，也同時是一個產品類別的總稱。所以當聽到“某某公司是做ETL產品的”的這種對話時，其中的ETL，DB，Application Server等名詞是相同的，都是指向某種類別的IT產品。然而，如果就概念性上來看，ETL指的其實是數(shù)據(jù)運用的生命周期中的其中一個過程，跟前面提到的數(shù)據(jù)預處理是同樣一個概念，數(shù)據(jù)清洗（Data Cleansing）、數(shù)據(jù)關聯(lián)和數(shù)據(jù)匯總等，都包含在這個范疇內。所以當我們說Hadoop特別適合拿來做ETL時，在概念上，它是正確的，同時也能很清楚地定位出Hadoop在企業(yè)資料運用中所扮演的角色。但Hadoop終究不是一個ETL的產品，反倒是現(xiàn)有的ETL產品，也開始跟BI一樣，去發(fā)展它在Hadoop上的可用性、聯(lián)系性與兼容性。Etu團隊之前在幫客戶導入Hadoop做數(shù)據(jù)處理時，常常會用script語言來實現(xiàn)一些應用場景，最近一段時間以來，一些企業(yè)的技術顧問也開始運用3rd-party的ETL tool來實作這一塊，對企業(yè)客戶來說，這是他們較熟悉的工具，也降低了他們進入Hadoop的門檻。

6.（誤解）Hadoop跟傳統(tǒng)storage沒什么差別，都特別適合用來做資料的備份

（正解）熟悉storage的人，第一次看到Hadoop時，往往只會注意到它的分布式文件系統(tǒng)HDFS，然后開始拿它來與現(xiàn)有的storage的功能特性做比較，而忽略掉Hadoop本身并行運算的那一塊。這很合理，畢竟MapReduce的概念，在應用上是比較抽象且難以捉摸的，相反的，HDFS就是一個很清楚且具體的概念。Hadoop當然可以拿來做data archive的運用，但如果你本身的數(shù)據(jù)沒有被經常或偶爾拿出來使用需求（也就是我們所說的cold data）的話，Hadoop本身的HDFS作為data archive并不會有特別的優(yōu)勢，反而傳統(tǒng)storage的一些延伸功能特性，Hadoop本身并不具備。雖然HDFS本身是一個不錯的object store，具備有作為scale-out NAS的底層的特性，但也就僅限于此，Hadoop本身并沒有特別為它外加storage本身具有的功能，畢竟Hadoop當初設計時，對數(shù)據(jù)的儲存與運用的思考，與storage的應用場景是完全不一樣的。Hadoop本身要解決的反而是現(xiàn)有當數(shù)據(jù)被放進storage后，需要再被拿出來處理或運算時所遇到的困難。也因此，它特別適合那些Web click-stream，CDR（call detail record），GPS data，system log，other time-series data等數(shù)據(jù)，因為這些數(shù)據(jù)都具有需要經常被拿出來分析處理的特性。在實際應用中，Hadoop與傳統(tǒng)storage其實是相輔相成的，辟如說，我們可能會在Hadoop上放過去3～6個月的數(shù)據(jù)，因為這些數(shù)據(jù)的再被利用性較高，而6個月之后的數(shù)據(jù)就可能會把它放在傳統(tǒng)的storage內，因為它被再利用的程度低很多了。

7.（誤解）Hadoop是一個搜索引擎

（正解）Search的確是Hadoop的一個重要的應用，但Hadoop本身并沒有內含search engine。實務上，我們常會把HBase的index設計運用到極致，來滿足一些特定search或query的應用，但要滿足全文檢索的需求，就必須在Hadoop上建構一個基于Hadoop的搜索引擎。

8.（誤解）基于Hadoop的推薦系統(tǒng)與傳統(tǒng)的推薦系統(tǒng)并無不同

（正解）傳統(tǒng)的推薦系統(tǒng)只處理客戶的事務數(shù)據(jù)，大多用的是數(shù)據(jù)倉庫或商業(yè)智能等解決方案，然而，除了客戶的事務數(shù)據(jù)之外，是否也有可能針對客戶交易前的行為進行分析、進而產生推薦？特別是對電子商務網站來說，客戶在完成購買前的點擊瀏覽、搜尋以及放進購物車等行為，都包含了豐富的訊息，可以藉此很容易地導引出客戶想要尋找什么樣的商品。所以，如果在產生推薦過程中可以把這些訊息都納進來，則所產生推薦的精準度與豐富度必然可以大為提高。這正是新一代推薦系統(tǒng)面臨到的挑戰(zhàn)：如何在事務數(shù)據(jù)（Transaction Data）之外，同時也可以把客戶的互動數(shù)據(jù)（Interaction Data）含括進來。由于客戶互動數(shù)據(jù)的型態(tài)與事務數(shù)據(jù)間有極大差異，其數(shù)量級更是遠遠大于事務數(shù)據(jù)量，運算頻率更是有極高的要求，也因此都遠超過現(xiàn)有數(shù)據(jù)庫或數(shù)據(jù)倉儲的能力，而這正是Hadoop所擅長，可以輕易拓展傳統(tǒng)機器學習算法分析大量數(shù)據(jù)集（Large Datasets）的能力，并同時具備橫向擴充的能力，可隨著數(shù)據(jù)集的成長輕易擴充，無論多大的數(shù)據(jù)都可勝任。

9.（誤解）Hadoop不適合用來處理小檔案的應用

（正解）對Hadoop稍微有點了解的人，都會知道HDFS的block size的default值為64 MB，且不建議往下調，因為HDFS當初在設計時，并不是針對碎片般的小檔案處理。所以說Hadoop不適合用來處理小檔案的應用時，就技術上來說是對的，但在實際運用上，卻有不同的做法來滿足海量小檔案管理的需求。例如保險公司，它本身需要處理的小圖檔（20KB～1 MB）大概有2億個那么多，且每天還持續(xù)在成長，包括客戶的簽名、看診紀錄等，都需要被掃描成圖像文件，并加以儲存，同時，還要被相對應的應用程序來進行查詢、調用。在實作上，Hadoop把這些小圖檔的binary file存進去HBase，而不是HDFS來管理，所以HDFS block size的設定值大小就不是重點，同時，利用HBase column-base高效能與高延展性的特性，可以很容易滿足多人同時快速在線查詢的要求，而隨著檔案數(shù)量持續(xù)的增加。橫向擴充也不再是問題。類似的應用其實還不少，譬如說銀行票據(jù)文件的管理就是其中一種。

10.（誤解）Hadoop不適合用來做日志管理的應用

（正解）當每天的日志量成長到一定的程度，現(xiàn)有的日志管理工具都會遇到瓶頸，所以一些國外的日志管理工具（如Splunk，ArcSight）都已經發(fā)布了其Hadoop Connector，強調其與Hadoop的聯(lián)系性與兼容性。所以，如果客戶對日志管理的需求只是保存日志、并可以隨時對日志搜索的話，那Hadoop本身即可以滿足，而對于比較復雜的日志管理且日志量非常大的需求，客戶也可以從現(xiàn)有的日志管理工具中來挑選，并與Hadoop來搭配協(xié)同運作。