其實我們要知道大數(shù)據(jù)的實質(zhì)特性：針對增量中海量的結(jié)構(gòu)化，非結(jié)構(gòu)化，半結(jié)構(gòu)數(shù)據(jù)，在這種情況下，如何快速反復(fù)計算挖掘出高效益的市場數(shù)據(jù)？

帶著這個問題滲透到業(yè)務(wù)中去分析，就知道hadoop需要應(yīng)用到什么業(yè)務(wù)場景了！??！如果關(guān)系型數(shù)據(jù)庫都能應(yīng)付的工作還需要hadoop嗎？

比如

1.銀行的信用卡業(yè)務(wù)，當你正在刷卡完一筆消費的那一瞬間，假如在你當天消費基礎(chǔ)上再消費滿某個額度，你就可以免費獲得某種令你非常滿意的利益等等，你可能就會心動再去消費，這樣就可能提高銀行信用卡業(yè)務(wù)，那么這個消費額度是如何從海量的業(yè)務(wù)數(shù)據(jù)中以秒級的速度計算出該客戶的消費記錄，并及時反饋這個營銷信息到客戶手中呢？這時候關(guān)系型數(shù)據(jù)庫計算出這個額度或許就需要幾分鐘甚至更多時間，就需要hadoop了，這就是所謂的“秒級營銷”. 針對真正的海量數(shù)據(jù)，一般不主張多表關(guān)聯(lián)。

2. 在淘寶，當你瀏覽某個商品的時候，它會及時提示出你感興趣的同類商品的產(chǎn)品信息和實時銷售情況，這或許也需要用到hadoop.

3. 就是報表用到的年度報告或者年度環(huán)比數(shù)據(jù)報告的時候也會用到hadoop去計算.

4.搜索引擎分析的時候應(yīng)該也會用到。一個網(wǎng)友說過，其實還是看big data能否帶來多大的效益！比如銀行在躺著都賺錢的情況下，big data不一定是銀行的項目. 況且hadoop是新興技術(shù)，銀行業(yè)對新技術(shù)還是相對保守的.

hadoop 主要用于大數(shù)據(jù)的并行計算 并行計算按計算特征分為：

數(shù)據(jù)密集型并行計算：數(shù)據(jù)量極大，但是計算相對簡單的并行處理

如：大規(guī)模Web信息搜索

計算密集型并行計算：數(shù)據(jù)量相對不是很大，但是計算較為復(fù)雜的并行計算

如：3-D建模與渲染，氣象預(yù)報，科學(xué)計算

數(shù)據(jù)密集與計算密集混合型的并行計算

如：3－D電影的渲染

hadoop比較擅長的是數(shù)據(jù)密集的并行計算。它主要是對不同的數(shù)據(jù)做相同的事情，最后再整合。

我知道以及曾經(jīng)實驗過的hadoop的例子有

wordCount （相當于hadoop的HelloWorld的程序）；

文檔倒排索引；

PageRank；

K-Means 算法；

這些程序都可以從網(wǎng)上找到相應(yīng)的解決方案。

hadoop的是根據(jù)Google MapReduce 提出的開源版本。但是它的性能不是很好。

hadoop主要應(yīng)用于數(shù)據(jù)量大的離線場景。特征為：

1、數(shù)據(jù)量大。一般真正線上用Hadoop的，集群規(guī)模都在上百臺到幾千臺的機器。這種情況下，T級別的數(shù)據(jù)也是很小的。Coursera上一門課了有句話覺得很不錯：Don’t use hadoop, your data isn’t that big

2、離線。Mapreduce框架下，很難處理實時計算，作業(yè)都以日志分析這樣的線下作業(yè)為主。另外，集群中一般都會有大量作業(yè)等待被調(diào)度，保證資源充分利用。

3、數(shù)據(jù)塊大。由于HDFS設(shè)計的特點，Hadoop適合處理文件塊大的文件。大量的小文件使用Hadoop來處理效率會很低。

舉個例子，百度每天都會有用戶對側(cè)邊欄廣告進行點擊。這些點擊都會被記入日志。然后在離線場景下，將大量的日志使用Hadoop進行處理，分析用戶習慣等信息。