常見的Hadoop十大應用誤解

常見的Hadoop十大應用誤解

 

1. 1.        (誤解) Hadoop什麼均可以作

(正解) 當一個新技術出來時，咱們都會去思考它在各個不一樣產業的應用，而對於平臺的新技術來講，咱們思考以後常會出現這樣的結論 「這個好像什麼都能作」， 然而，更深刻的去想，你就會發現「好像什麼都須要重頭作」。 對於Hadoop，我常喜歡舉Database來當例子。 三十年前數據庫(Database)剛出來時，上面並無什麼現成的應用方案(Application)，因此廠商在銷售的過程當中常須要花不少的時間去告訴客戶說，若是今天你有了這個數據庫，你就能夠作什麼什麼的應用，而看起來的確好像數據庫什麼應用均可以作，由於畢竟大部分的應用都會須要一個數據庫。只是三十年前全部的應用都得重頭打造，咱們今天習覺得常的ERP、CRM等應用系統，當時並不存在的，那都是後來的事了。今天的Hadoop，正好有點像當年database 剛出來的時候，畢竟今天全部的應用或多或少都會開始去處理半結構、非結構化數據，而這些東西的確都是Hadoop擅長的，因此平臺的適用性其實問題不大，重點仍是在應用要由誰來搭建。

 

1. 2.        (誤解) Hadoop沒法扮演HPC (High Performance Computing) or Grid Computing的角色

(正解) 因爲Hadoop自己是由並行運算架構(MapReduce)與分佈式文件系統(HDFS)所組成，因此咱們也看到不少研究機構或教育單位，開始嘗試把部分本來執行在HPC 或Grid上面的任務，部分移植到Hadoop集羣上面，利用Hadoop兼顧高速運算與海量儲存的特性，更簡易且更有效率地來執行工做。目前國外高能物理、生命科學、醫學等領域，都已經有這樣的應用案例，利用Hadoop集羣與現有的HPC/Grid 搭配、協同運做，來知足不一樣特性的運算任務。

 

1. 3.        (誤解) Hadoop只能作資料分析/挖掘(Data Mining/Analyst)

(正解) Hadoop特別適合來數據分析與挖掘的應用是毫無疑問的，但數據分析與挖掘是難度與深度都較高的一個應用，所須要的時間的積累也比較長，也所以讓通常企業對於導入Hadoop視爲畏途，甚至心懷恐懼。然而，從Etu知意圖團隊這一兩年來輔導客戶的經驗來看，咱們發現其實更多的應用，大多都在數據處理(Data Processing)這個部分，或者更精確地來講，Hadoop這個平臺，特別適合數據預處理(Data pre-Processing)這種應用場景。不管是數據倉庫的負載分流(DW Offload)、數據的彙總(Data Aggregation)、甚或是咱們運用協同過濾算法(Collaborative Filtering)針對線下線上零售業所作的精準推薦應用(Recommendation)，廣義上來看，均可以說是屬於Data Processing的一環，畢竟，Big Data的來臨，咱們看data、運用data的角度與方式都必需要有所改變。

l   Big Data強調的不是對因果關係的渴求，取而代之的是關注於data之間的相關關係。

l   也就是說，重點在於要知道「是什麼」，反而未必須要知道「爲何」。

l   因此, 它要求的是全部data的處理，而不僅是隨機樣本的分析。

l   最後咱們每每會發現，處理Big Data的簡單算法所獲得的來自於data呈現的事實，每每比分析small data的複雜算法所獲得的來自data背後的緣由，對企業帶來的效益更大。

我強烈推薦你們去看Big Data: A Revolution That Will Transform How We Live, Work, and Think這本書，裏面把咱們面對Big Data該有的觀點與見解，作了很是清楚的陳述，有簡中的的翻譯本，繁中的好像還沒看到。

 

1. 4.        (誤解) Hadoop就是BI (Business Intelligence)商業智能

(正解) 跟前面同樣，這也是大多數人最容易誤解的地方，由於Hadoop特別適合來作數據分析，因此就很直覺地把它想成 「那就是BI嘛」。 會有這種誤解，主要來自於對數據運用的總體架構的不清楚。傳統BI是屬於數據展示層(Data Presentation)，其數據的載體(Data Store)是數據庫或數據倉庫。對比來看，Hadoop就是專一在半結構化、非結構化數據的數據載體，跟BI是不一樣層次的概念。固然，Hadoop除了Data Store外，又特別具有運算的特性，也所以特別容易帶來這種觀念上的混淆。至於半結構、非結構化數據的數據展示層部分，目前自己並不在Hadoop的生態體系內，而是由其餘現有或新創的公司來填補這塊空缺，因此，逐漸地咱們會看到愈來愈多現有的BI tool，開始強調其自身與Hadoop的聯繫性與兼容性，同時，一些新創公司，也發展出徹底不一樣於現有BI Tool的基於Big Data的數據展示層。

 

1. 5.        (誤解) Hadoop就是ETL (Extract, Transform & Load)

(正解) ETL其實有兩種意涵，它自己是一個概念，也同時是一個產品類別(Product Category)的總稱。因此當咱們聽到「某某公司是作ETL產品的」的這種對話時，其中的 ETL，與DB、Application Server等名詞是相同的，都是指向某種類別的IT產品。然而，若是就概念性上來看，ETL指的實際上是數據運用的生命週期中的其中一個過程， 跟我前面提到的數據預處理(Data pre-Processing)是一樣一個概念，舉凡數據清洗(Data Cleansing)、數據關聯、數據彙總等，都包含在這個範疇內。因此當咱們說Hadoop特別適合拿來作ETL時，在概念上，它是正確的，同時也能很清楚明白地定位出Hadoop在企業資料運用中所扮演的角色。但Hadoop終究不是一個ETL的產品，反卻是現有的ETL產品，也開始跟BI同樣，去發展它在Hadoop上的可用性、聯繫性與兼容性。Etu團隊以前在幫客戶導入Hadoop作數據處理時，經常會用script語言來實現一些應用場景，最近一段時間以來，咱們的技術顧問也開始運用3rd-party 的ETL tool來實做這一塊，對企業客戶來講，這是他們較熟悉的工具，也下降了他們進入Hadoop的門坎。

 

1. 6.        (誤解) Hadoop跟傳統storage沒什麼差異, 都特別適合來作資料的備份(Data Archive)

(正解) 熟悉storage的人，第一次看到Hadoop時，每每只會注意到它的分佈式文件系統HDFS，而後開始拿它來與現有的storage的功能特性作比較，而忽略掉Hadoop自己並行運算的那一塊。這很合理，畢竟MapReduce的概念，在應用上是比較抽象且難以捉摸的，相反的，HDFS就是一個很清楚且具象的概念。Hadoop固然能夠拿來作data archive的運用，但若是你自己的數據沒有被常常或偶爾拿出來使用的需求(也就是咱們所說的cold data)的話，Hadoop自己的HDFS做爲data archive並不會有特別的優點，反而傳統storage的一些延伸的功能特性，Hadoop自己並不具有。雖然HDFS自己是一個不錯的object store，具有有做爲scale-out NAS的底層的特性,， 但也就僅限於此了， Hadoop自己並無特別爲它外加storage自己該具備的功能，畢竟Hadoop當初設計時，對數據的儲存與運用的思考，與storage的應用場景是徹底不同的。Hadoop自己要解決的，反而是現有當數據被放進storage後，須要再被拿出來處理或運算時所遇到的困難性。也所以，它特別適合那些web click-stream、CDR (call detail record)、GPS data, system log、 and other time-series data等數據，由於這些數據都具備須要常常被拿出來分析處理的特性。在實際應用中，Hadoop與傳統storage實際上是相輔相成的，闢如說，咱們可能會在Hadoop上放過去3到6個月的數據，由於這些數據的再被利用性較高，而6個月以後的數據就可能會把它archive在傳統的storage內，由於它被再利用的程度低不少了。

 

1. 7.        (誤解) Hadoop是一個搜索引擎(Search Engine)

(正解) Search 的確是Hadoop的一個重要的應用，但Hadoop自己並無內含search engine。實務上，咱們常會把HBase 的index設計運用到極致，來知足一些特定search 或query的應用，但若是要知足全文檢索 (full-text search)的需求的話，你就必須在Hadoop上建構一個基於Hadoop的搜索引擎。Lucene / Katta 及其餘的open source都有相對應的計劃，如何藉助Hadoop的特性，來實現一個強大的分佈式搜索引擎，這也是咱們一直密切注意、且已放進將來產品的藍圖之中的重要話題。

 

1. 8.        (誤解) 基於Hadoop的推薦系統與傳統的推薦系統並沒有不一樣

(正解) 傳統的推薦系統只處理客戶的事務數據(transaction data)，大多用的是數據倉庫或商業智能等解決方案，然而，除了客戶的事務數據以外，是否也有可能針對客戶交易前的行爲進行分析、進而產生推薦? 特別是對電子商務網站來講，客戶在完成購買前的點擊瀏覽、搜尋、及放進購物車等行爲，都包含了豐富的訊息，能夠藉此很容易去導引出客戶想要尋找什麼樣的商品，因此，若是在產生推薦過程當中能夠把這些訊息都納進來，則所產生推薦的精準度與豐富度必然能夠大爲提升。這正是新一代的推薦系統會面臨到的挑戰 : 如何在事務數據 (Transaction Data) 以外，同時也能夠把客戶的互動數據 (Interaction Data) 含括進來? 因爲客戶互動數據的型態與事務數據間有極大的差別，其數量級更是遠遠大於事務數據量，運算頻率更是有極高的要求，也所以都遠超過現有數據庫或數據倉儲的能力，而這正是Hadoop所擅長，能夠輕易拓展傳統機器學習 (Machine Learning) 算法分析大量數據集 (Large Datasets) 的能力，並同時具有橫向擴充 (Scale-out) 的能力，可隨着數據集的成長輕易擴充，不管多大的數據均可輕易勝任。

 

1. 9.        (誤解) Hadoop不適合用來處理小檔案的應用

(正解) 對Hadoop稍微有點了解的人，都會知道HDFS的block size的default 值爲64MB，且不建議往下調，由於HDFS當初在設計時，並非針對碎片般的小檔案的處理而來的。因此當咱們說Hadoop不適合用來處理小檔案的應用時，就技術上來講是對的，但在實際運用上，卻能夠有不一樣的作法來知足海量小檔案管理的需求。咱們在中國曾經輔導過一個保險公司，它自己須要處理的小圖檔 (20KB ~ 1MB)大概有兩億個那麼多，且天天還持續在成長，舉凡客戶的簽名、看診紀錄等，都須要被掃描成圖像文件，並加以儲存，同時，還要偶爾被相對應的應用程序來查詢、調用。在實做上，咱們把這些小圖檔的binary file存進去HBase——而不是HDFS——來管理，因此HDFS block size的設定值大小就不是重點，同時，利用HBase column-base 高效能與高延展性的特性，能夠很輕易的就知足多人同時快速在線查詢的要求，而隨着檔案數量持續的增長 , 橫向擴充也再也不是問題。相似的應用其實還很多，譬如說銀行票據文件的管理就是其中一種，也所以，Etu團隊在中國市場，特別針對此應用規劃了 「海量小圖文件管理系統」解決方案，以知足此類客戶的需求。

 

1. 10.     (誤解) Hadoop不適合用來作日誌管理(Log Management)的應用

(正解) 當天天的日誌量成長到必定的程度，現有的日誌管理工具都會遇到瓶頸，因此一些國外的日誌管理工具(如Splunk、ArcSight)都已經發布了其Hadoop Connector，強調其與Hadoop的聯繫性與兼容性。因此，若是客戶對日誌管理的需求只是保存日誌、並能夠隨時對日誌搜索的話，那Hadoop自己便可以知足這樣的應用，而對於比較複雜的日誌管理且日誌量很是大的需求，客戶也能夠從現有的日誌管理工具中來挑選，並與Hadoop來搭配協同運做。