大數(shù)據(jù)之常見的Hadoop十大應(yīng)用誤解常見的Hadoop十大應(yīng)用誤解。

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

1. (誤解) Hadoop什么都可以做

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

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

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

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

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

• Big Data強(qiáng)調(diào)的不是對因果關(guān)系的渴求，取而代之的是關(guān)注于data之間的相關(guān)關(guān)系。
• 也就是說，重點在于要知道“是什么”，反而未必需要知道“為什么”。
• 所以, 它要求的是所有data的處理，而不只是隨機(jī)樣本的分析。
• ***我們往往會發(fā)現(xiàn)，處理Big Data的簡單算法所得到的來自于data呈現(xiàn)的事實，往往比分析small data的復(fù)雜算法所得到的來自data背后的原因，對企業(yè)帶來的效益更大。

我強(qiáng)烈推薦大家去看Big Data: A Revolution That Will Transform How We Live, Work, and Think這本書，里面把我們面對Big Data該有的觀點與看法，做了非常清楚的陳述，有簡中的的翻譯本，繁中的好像還沒看到。

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

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

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

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

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

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

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

(正解) Search 的確是Hadoop的一個重要的應(yīng)用，但Hadoop本身并沒有內(nèi)含search engine。實務(wù)上，我們常會把HBase 的index設(shè)計運(yùn)用到***，來滿足一些特定search 或query的應(yīng)用，但如果要滿足全文檢索 (full-text search)的需求的話，你就必須在Hadoop上建構(gòu)一個基于Hadoop的搜索引擎。Lucene / Katta 及其他的open source都有相對應(yīng)的計劃，如何借助Hadoop的特性，來實現(xiàn)一個強(qiáng)大的分布式搜索引擎，這也是我們一直密切注意、且已放進(jìn)未來產(chǎn)品的藍(lán)圖之中的重要話題。

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

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

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

(正解) 對Hadoop稍微有點了解的人，都會知道HDFS的block size的default 值為64MB，且不建議往下調(diào)，因為HDFS當(dāng)初在設(shè)計時，并不是針對碎片般的小檔案的處理而來的。所以當(dāng)我們說Hadoop不適合用來處理小檔案的應(yīng)用時，就技術(shù)上來說是對的，但在實際運(yùn)用上，卻可以有不同的做法來滿足海量小檔案管理的需求。我們在中國曾經(jīng)輔導(dǎo)過一個保險公司，它本身需要處理的小圖檔 (20KB ~ 1MB)大概有兩億個那么多，且每天還持續(xù)在成長，舉凡客戶的簽名、看診紀(jì)錄等，都需要被掃描成圖像文件，并加以儲存，同時，還要偶爾被相對應(yīng)的應(yīng)用程序來查詢、調(diào)用。在實作上，我們把這些小圖檔的binary file存進(jìn)去HBase——而不是HDFS——來管理，所以HDFS block size的設(shè)定值大小就不是重點，同時，利用HBase column-base 高效能與高延展性的特性，可以很輕易的就滿足多人同時快速在線查詢的要求，而隨著檔案數(shù)量持續(xù)的增加 , 橫向擴(kuò)充也不再是問題。類似的應(yīng)用其實還不少，譬如說銀行票據(jù)文件的管理就是其中一種，也因此，Etu團(tuán)隊在中國市場，特別針對此應(yīng)用規(guī)劃了 “海量小圖文件管理系統(tǒng)”解決方案，以滿足此類客戶的需求。

10. (誤解) Hadoop不適合用來做日志管理(Log Management)的應(yīng)用

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

新聞標(biāo)題：大數(shù)據(jù)資料之常見的Hadoop十大應(yīng)用誤解學(xué)習(xí)
標(biāo)題網(wǎng)址：http://m.newbst.com/news47/99197.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站建設(shè)、網(wǎng)站營銷、響應(yīng)式網(wǎng)站、虛擬主機(jī)、全網(wǎng)營銷推廣、做網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)