大數(shù)據(jù)是數(shù)據(jù)智能時代的“鐵公基”，是一系列計算和存儲的基礎(chǔ)設(shè)施。推薦系統(tǒng)也是建立在大數(shù)據(jù)的基礎(chǔ)之上的，大量的數(shù)據(jù)挖掘和模型訓(xùn)練都離不開大數(shù)據(jù)。

大數(shù)據(jù)這個名詞起的很好，對于非技術(shù)人員來說也能get到大的含義：數(shù)據(jù)量大，算力強大。

但是這強大的能力是怎么來的？大數(shù)據(jù)生態(tài)體系架構(gòu)是怎么分工的？

不具體做過的同學(xué)并不清楚。今天就繼續(xù)站在產(chǎn)品經(jīng)理的角度深入淺出地來講述這些問題。其實不一定是產(chǎn)品經(jīng)理，對大數(shù)據(jù)感興趣的同學(xué)都可以看看。本文比較長，如果時間不夠，建議先Mark下。

01 大數(shù)據(jù)的誕生與分布式
在大數(shù)據(jù)技術(shù)誕生之前，數(shù)據(jù)的存儲和處理大半壁江山都是Oracle和MySql和等數(shù)據(jù)庫軟件的。這些傳統(tǒng)數(shù)據(jù)庫的文件系統(tǒng)是單機的，也就是說，數(shù)據(jù)只能在一臺機器上跑。它們在處理成TB（1024GB）甚至上PB（1024TB）級別數(shù)據(jù)時就會特別吃力。

第一個解決了這個問題的公司是谷歌。谷歌解決這個問題的思路就是分布式。谷歌分別于2003-2004年發(fā)表了三篇重量級的論文，奠定了大數(shù)據(jù)的基礎(chǔ)。

簡單的說，谷歌通過論文公布了以下三個工具如何創(chuàng)造：

1. 分布式文件系統(tǒng)：Google File System
2. 分布式并行計算框架：Google MapReduce
3. 分布式數(shù)據(jù)庫：BigTable

這個就是大數(shù)據(jù)技術(shù)的開始。從谷歌的這個原點開始，大數(shù)據(jù)經(jīng)過多年發(fā)展，形成了今天的全貌。

可以用以下三個分類來去解構(gòu)整個大數(shù)據(jù)生態(tài)：

1. 分布式存儲：把文件切成多份，分布地存儲到多臺機器上。常用的組件有：HDFS,HBase等。
2. 分布式計算：把數(shù)據(jù)計算的任務(wù)切分成多個，分配到多臺機器上計算。常用的組件有：MapReduce，Spark，Storm，F(xiàn)link等。
3. 分布式工具：數(shù)據(jù)輔助類工具，資源調(diào)度管理工具等。常見的組件有：YARN，Hive，F(xiàn)lume，Sqoop，Elastic Search，ZooKeeper等。

大數(shù)據(jù)整個生態(tài)體系非常龐大，相關(guān)的產(chǎn)品不勝枚舉，讓人看著眼花繚亂，有種物種大爆發(fā)的感覺。但是也并非無跡可尋。我們理解大數(shù)據(jù)生態(tài)，從這三個方面去理解就會輕松很多。本文也是嚴格按照這個方式來講述。

02 本文講述需要用的數(shù)據(jù)表
鑒于大數(shù)據(jù)生態(tài)過于龐大復(fù)雜，為了使得文章更加淺顯易懂，本文不對技術(shù)概念做過多的描述，而是直接到操作層面，以圖示的方式講解。因為要講述的是數(shù)據(jù)系統(tǒng)，我這里建一張數(shù)據(jù)表USER，用這張數(shù)據(jù)表在各個系統(tǒng)中處理過程來給大家講述大數(shù)據(jù)各個組件的工作原理和機制。

03 Hadoop
整個互聯(lián)網(wǎng)技術(shù)生態(tài)圈中，谷歌是超級績優(yōu)生。每次發(fā)表論文，都會引起眾多人員前來“抄作業(yè)”。Hadoop之父Doug Cutting和他的團隊就是其中一個。他花了兩年的業(yè)余時間，照著谷歌的論文實現(xiàn)了一個分布式數(shù)據(jù)系統(tǒng)，并用自己兒子的大象毛絨玩具的名字給這個系統(tǒng)命名為Hadoop。Hadoop的Logo也是個頭大象。

[[358986]]

后來到了2006年，Hadoop被引入Apache基金會，成為一個開源的頂級項目。隨著Hadoop的不斷發(fā)展，在Hadoop項目中，誕生了HBase，Hive，Pig，Zookeeper等子項目，并先后被Apache基金會將其獨立升級成為頂級項目。

同時，Apache基金會也不斷兼收并蓄其他大數(shù)據(jù)項目，基本把絕大多數(shù)優(yōu)秀的大數(shù)據(jù)項目都收入麾下，大有天下武功出少林的味道。大數(shù)據(jù)各種開源組件中，Apache旗下的才是少林正宗。

閑話不多說，我們來講Hadoop。

現(xiàn)在的Hadoop主要分三個部分：

1. 分布式存儲：HDFS(Hadoop Distributed File System)，一個高可靠、高吞吐量的分布式文件系統(tǒng)，實現(xiàn)海量數(shù)據(jù)存儲。
2. 分布式計算：MapReduce，一個分布式離線并行計算計算框架，實現(xiàn)海量計算。
3. 分布式工具：YARN，一個集群資源調(diào)度管理的框架，實現(xiàn)硬件資源的調(diào)配。

04 圖解分布式
這里先具象的解釋下，什么是大數(shù)據(jù)的分布式長什么樣？

我們在安裝Hadoop的時候，要把同一個Hadoop的軟件安裝包，安裝在三臺以上不同的機器上。安裝好后，我們就可以得到一個Hadoop分布式集群。

如下圖，我們將Hadoop的三個組件，安裝在集群每一臺機器上，這個集群有七臺機器。每一臺機器叫一個節(jié)點。這七個節(jié)點中，要選出一個做老大，我們有什么事情先找這個老大，這個就是主節(jié)點。因為主節(jié)點很重要，它要是掛了，整個集群就掛了。所以一般主節(jié)點配置兩臺，一臺備份。其他五個節(jié)點叫做從節(jié)點。在Hadoop中，主節(jié)點命名為Master，從節(jié)點為Slave。

05 分布式文件系統(tǒng)：HDFS
下面將Hadoop的第一個組件HDFS。HDFS作為分布式的文件系統(tǒng)，它是以文本的方式來保存數(shù)據(jù)的，也就是說，數(shù)據(jù)一般會跟我們的TXT文件那樣。一個文件會被按照設(shè)定，切分成不同的數(shù)據(jù)塊，然后每個數(shù)據(jù)塊會被復(fù)制成多份，然后分布式地存到不同的節(jié)點中。HDFS把集群節(jié)點分成兩類：NameNode和DataNode。

• NameNode可以理解成數(shù)據(jù)目錄，它記錄了每個數(shù)據(jù)塊在哪臺機器的哪個位置。這個功能由主節(jié)點承擔(dān)。
• DataNode顧名思義就是存數(shù)據(jù)的節(jié)點了。

下面以USER數(shù)據(jù)表為例，舉例說明HDFS的運作過程。實際的系統(tǒng)中，因為NameNode負荷比較重，會設(shè)置一個SecondaryNameNode來協(xié)助NameNode的工作（注意是協(xié)助，而不是備份）。

上圖中：

1. HDFS先把深藍色的文本數(shù)據(jù)切分成三份。每份數(shù)據(jù)按照系統(tǒng)設(shè)定，如64MB或128MB一塊。
2. 將三份數(shù)據(jù)塊復(fù)制成三份，這樣就有九份數(shù)據(jù)。
3. 把上一步得到的九份數(shù)據(jù)劃分到不同的DataNode中，并建好目錄。
4. 按照儲存分配，把各個數(shù)據(jù)塊保存。

HDFS優(yōu)點：數(shù)據(jù)容量大，是大數(shù)據(jù)最主要的數(shù)據(jù)存儲方式。很多其他組件都是建立在HDFS的基礎(chǔ)上，應(yīng)用非常廣泛。

HDFS的缺點：它是個文件系統(tǒng)，而不是數(shù)據(jù)庫系統(tǒng)，不能像關(guān)系數(shù)據(jù)庫系統(tǒng)那樣建立索引等工具提升處理速度和定位到數(shù)據(jù)位置。因為數(shù)據(jù)記錄的形式是一行一行的字符串，沒辦法定位，不支持對數(shù)據(jù)的直接修改。

06 分布式離線計算引擎：MapReduce
MapReduce是專門負責(zé)分布式計算的，它是是一個組合詞，可以分成兩個部分：Map和Reduce。

簡單的說，Map就是把要計算的數(shù)據(jù)分解成多個計算任務(wù)，而Reduce則是Map過程得到的結(jié)果進行匯總。假設(shè)現(xiàn)在我們要計算在USER表中，男女各有多少人。

MapReduce計算詳細過程如下：

上圖中：

1. Splitting階段，把數(shù)據(jù)分成三塊。Splitting一般就是在HDFS存儲時的切分的基礎(chǔ)上再次切分。
2. Mapper則為每個切分的數(shù)據(jù)塊建一個Mapping任務(wù)，逐條地計算每條數(shù)據(jù)的結(jié)果，然后在磁盤中存起來。
3. Shuffling也就是將Mapping階段的結(jié)果進行分揀，shuffle任務(wù)要等Mapping完全完成后才能開展。
4. Reducing就是將分揀好的數(shù)據(jù)，進行匯總。

通過這種方式，MapReduce獲得了強大的運算能力。

MapReduce優(yōu)點：計算能力強大，運算耗費成本低廉，在運算能力一般的機器上也能運行。

MapReduce缺點：它誕生的年代，內(nèi)存還很貴，在計算的過程中，中間結(jié)果要不斷存入磁盤中，以減少內(nèi)存的壓力，但是這樣導(dǎo)致了MapReduce運算速度比較慢。另外就是代碼不簡潔，學(xué)習(xí)曲線比較陡，后面在HIVE部分會講述。

07 資源管理調(diào)度系統(tǒng)：YARN
YARN的全稱是Yet Another Resource Negotiator，直譯就是另一種資源協(xié)調(diào)者。

看名字就知道，他是Hadoop中其中一種資源調(diào)度器。它的最重要的組件是ResourceManager，通過這個組件，YARN可以為我們的MapReduce任務(wù)進行資源分配，分配的資源就是一個個的計算容器，每個計算的任務(wù)就在這個容器中跑。由于優(yōu)秀，后來YARN進一步被發(fā)揚光大，成了Hadoop以外的很多大數(shù)據(jù)組件的資源調(diào)度框架。

08 數(shù)據(jù)分析和數(shù)據(jù)倉庫工具：HIVE
在MapReduce的中，處理數(shù)據(jù)作業(yè)的程序是要通過JAVA來實現(xiàn)的，但是JAVA在寫MapReduce的過程并不簡潔。像我們前面提到的統(tǒng)計數(shù)據(jù)表中男女人數(shù)這個簡單的操作，需要嚴格按照Input到Reducing這五步來實現(xiàn)，代碼一般長達上百行。

但是統(tǒng)計這個數(shù)據(jù)結(jié)果，對于SQL來說，就是一句話的事：SELECT sex，COUNT(1) FROM USER GROUP BY sex。

為了不再寫又長又煩的JAVA，Hive應(yīng)運而生。Hive組件就主要做的事情是，將SQL代碼轉(zhuǎn)譯成MapReduce，然后放入YARN構(gòu)建的容器里面跑出結(jié)果。

這樣，我們要統(tǒng)計USER表中的男女人數(shù)的時候，就不用寫JAVA實現(xiàn)也能調(diào)動MapReduce了，這里我們畫圖說明一下：

另外，Hive除了轉(zhuǎn)譯SQL的功能外，它也可以用來建數(shù)據(jù)庫和數(shù)據(jù)表。一個數(shù)據(jù)庫擁有的能力它都有，而且還可以處理大量的數(shù)據(jù)，所以一般還會將Hive用來建數(shù)據(jù)倉庫。數(shù)據(jù)倉庫的主要功能，就是把歷史數(shù)據(jù)都存進去，可以反復(fù)地統(tǒng)計計算使用。數(shù)據(jù)倉庫最主要的特征就是數(shù)據(jù)量特別大。

由于它是構(gòu)建于HADOOP的基礎(chǔ)上，Hive可計算的容量大，運算能力強，但是速度不快。Hive也不能直接修改數(shù)據(jù)。對Hive進行數(shù)據(jù)的修改操作非常費時。

最后，介紹一下Hive和MySql的區(qū)別：

• MySql是關(guān)系型數(shù)據(jù)庫，它適合用于聯(lián)機事務(wù)數(shù)據(jù)管理。如用戶注冊，修改昵稱等數(shù)據(jù)操作，可以讓用戶對數(shù)據(jù)進行實時快速地增刪改查。
• HIVE是建立的HADOOP基礎(chǔ)上的數(shù)據(jù)倉庫工具。它適合計算大容量數(shù)據(jù)的場景，因為計算速度比較慢，不能用來進行實時響應(yīng)的事務(wù)性場景。

09 離線計算和流式計算DAG計算引擎：SPARK
Spark是分布式計算引擎，是大數(shù)據(jù)生態(tài)體系中的一個速度快，功能強大的一個組件。Spark整個框架非常龐大，提供能非常豐富的離線計算和流式計算能力。

本小節(jié)先介紹Spark的離線計算功能。

得益于摩爾定律下的硬件基礎(chǔ)設(shè)施的升級，內(nèi)存變得越來越便宜，與MapReduce主要把中間結(jié)果不斷寫入磁盤不同，Spark主要把數(shù)據(jù)放在內(nèi)存中計算。這樣Spark在速度上比起MapReduce有上千倍的提升。

當(dāng)內(nèi)存不足的時候，Spark也會需要將中間結(jié)果存入磁盤。但是在這種情況下，Spark在速度上比起MapReduce也有上百倍的提升。因為Spark提供了RDD，DataFrame，DataSet這樣的數(shù)據(jù)表工具，并為這些數(shù)據(jù)表提供了一系列高效計算的算子，有效提升了速度。多個算子疊加就成了一個DAG(Directed Acyclic Graph)，所以Spark也被成為DAG計算引擎。

下面介紹Spark的計算流程。

因為RDD，DataFrame，DataSet都是類似關(guān)系數(shù)據(jù)庫的數(shù)據(jù)表，流程機制都差不多，這里選用DataFrame來解釋。當(dāng)Spark處理USER表的數(shù)據(jù)時，會經(jīng)過以下過程：

上圖中：

1. 數(shù)據(jù)讀?。簲?shù)據(jù)讀取可以從文本，HDFS，HIVE，JSON等多種格式中讀取。
2. 轉(zhuǎn)換成DataFrame：把讀取的數(shù)據(jù)表轉(zhuǎn)換成Spark的內(nèi)置格式DataFrame，并上圖中命名為USER_DF。有了DataFrame就可以直接對它進行算子操作。上圖中用到的groupby和count都是算子。算子的作用就是執(zhí)行某類計算的操作。
3. groupby算子運算：groupby就是分組的算子。它實現(xiàn)了按照男女對數(shù)據(jù)進行了分組，得到一個分組后的新DataFrame，上圖中命名為GROUPBY_DF。每次算子運算后，都得到一個新的DataFrame。
4. count算子運算：從上一步的結(jié)果中，再次進行個數(shù)計算，得出最后結(jié)果RESULT_DF。

多個算子混合后，就形成了一個DAG，上面的操作，會形成以下的DAG。Spark通過構(gòu)建DAG，然后下發(fā)給從節(jié)點計算。

同時這個計算過程也是像MapReduce那樣，將計算任務(wù)分解成Map和Reduce兩個階段，分布式地在多臺機器中計算，這里不再描述。

10 離線計算和流式計算
MapReduce和Spark都是離線計算的代表，離線計算就是計算前已經(jīng)有了所有需要計算的數(shù)據(jù)，且每次計算都是所有的數(shù)據(jù)都參與的運算。因為每次都是一整批數(shù)據(jù)做計算，所以離線計算一般又叫批量計算。但是日常的事務(wù)中，有很多場景是需要不斷實時的更新數(shù)據(jù)的。

假設(shè)我們的USER表，現(xiàn)在因為有個新用戶注冊，多了一條用戶數(shù)據(jù)“蔡九，女，27”。離線計算就要把新數(shù)據(jù)匯總，然后再進行計算：

增加一條用戶日志，就要對全部的進行計算，在數(shù)據(jù)量非常龐大的時候，這根本是不可能的事情。所以我們還要另外一種計算方式，那就是流式計算。流式計算因其實時性，又常被叫做在線計算和實時計算。

以下是流式計算的過程，同樣的新增數(shù)據(jù)，流失計算只要對新增數(shù)據(jù)進行計算，然后匯總更新：

流式計算引擎有：SPARK streaming，Storm和Flink。它們都可以提供流式計算的服務(wù)，但是有些不同。

• SPARK streaming是使用微批的方式計算流數(shù)據(jù)。微批就是小批量的意思。SPARK streaming并不是一條一條地計算新數(shù)據(jù)流，而且小批量的計算。比如幾分鐘算一次，或者幾十條算一次。像割韭菜那樣，等長夠高了，再收割，一茬又一茬。
• Storm和Flink就是來一條計算一條地處理數(shù)據(jù)流了。像流水線作業(yè)那樣，不斷地逐個逐個處理。值得一提的是，最近兩年Flink很火，在推薦系統(tǒng)上被廣泛用來計算如用戶畫像等實時性較高的數(shù)據(jù)。

11 分布式結(jié)構(gòu)化存儲系統(tǒng)：HBASE
前面說到谷歌三篇關(guān)于大數(shù)據(jù)的論文，這里再補充一下它們后來的演變結(jié)果：

1. 分布式文件系統(tǒng)：Google File System，演變成Hadoop的HDFS。
2. 分布式并行計算框架：Google MapReduce，演變成Hadoop的MapReduce。
3. 分布式數(shù)據(jù)庫：BigTable，演變成了另外一個大名鼎鼎的HBase。

這就是HBase的誕生。

HBase是一個NoSql數(shù)據(jù)庫。它在整個大數(shù)據(jù)生態(tài)中的定位是對數(shù)據(jù)進行實時的操作：查詢，更新，刪除和插入。前面說到HIVE是能處理大量數(shù)據(jù)，但是速度慢且不能對數(shù)據(jù)進行修改，而MySql等傳統(tǒng)數(shù)據(jù)庫響應(yīng)快但是運算能力不足。HBase的出現(xiàn)，就是為了解決這些問題。

NoSql數(shù)據(jù)庫的意思就是不支持SQL語句的數(shù)據(jù)庫，HBase有以下特征：

• HBase最終存儲是基于HDFS的，有存儲海量數(shù)據(jù)能力。
• HBase的增刪改查是分布式的，也就是一次修改，是多個節(jié)點服務(wù)器的修改。
• HBase的表結(jié)構(gòu)跟關(guān)系型數(shù)據(jù)庫是不一樣的。
• HBase有很快的讀取響應(yīng)速度。

為了方便理解，我們直接畫圖看HBase怎么工作。如何把我們的USER數(shù)據(jù)表放入HBase后，它是長成這樣子的：

其中：

• rowkey是行鍵，是每行數(shù)據(jù)的編號。
• Users_info叫做列族，是保存數(shù)據(jù)的表頭。
• HBASE中，每個數(shù)據(jù)都被保存成為key:value的鍵值對，每個鍵值對叫做cell（單元格）。如name：張三就是一個cell。

MySql中，修改數(shù)據(jù)就會覆蓋掉舊數(shù)據(jù)。但是在HBase中，同個鍵值對可以保留多個數(shù)據(jù)版本。這個版本會以時間戳的形式來標記。如張三，有一天改名叫張三豐了，它并不會覆蓋掉原有的張三，而是兩個版本都保存起來。

如下如所示：

HBase有強大的讀取和增刪改查能力，加上可以保存不同時間的數(shù)據(jù)版本，在推薦系統(tǒng)中，用戶畫像的結(jié)果數(shù)據(jù)，離線召回，近線召回等數(shù)據(jù)，都是保存在HBase中。另外，HBase可以做到快速響應(yīng)，推薦系統(tǒng)中需要快速讀取的數(shù)據(jù)，都可以存在HBase中。

12 數(shù)據(jù)采集
大數(shù)據(jù)的誕生，并不是取代掉傳統(tǒng)的關(guān)系型數(shù)據(jù)庫，而是變成一種補充。傳統(tǒng)數(shù)據(jù)庫存不下的數(shù)據(jù)，大數(shù)據(jù)來存。傳統(tǒng)數(shù)據(jù)庫算不了的數(shù)據(jù)，大數(shù)據(jù)來算。大數(shù)據(jù)系統(tǒng)只是把現(xiàn)有系統(tǒng)的數(shù)據(jù)采集到大數(shù)據(jù)中，做存儲和計算，對已有的業(yè)務(wù)流程和系統(tǒng)架構(gòu)并沒有什么影響。

將數(shù)據(jù)采集到大數(shù)據(jù)，一般用到兩個工具：Sqoop、Flume。其實不同公司使用的數(shù)據(jù)采集工具不一樣，這里只是簡單的介紹。

關(guān)系型數(shù)據(jù)是我們最常見的一種數(shù)據(jù)，Sqoop是關(guān)系型數(shù)據(jù)庫和大數(shù)據(jù)之間數(shù)據(jù)流動的一個橋梁。它可以用來將MySql和Oracle的數(shù)據(jù)導(dǎo)入HDFS，HBASE中，或者將大數(shù)據(jù)中的數(shù)據(jù)導(dǎo)入MySql或Oracle。

另外一種常見的數(shù)據(jù)是來自于日志系統(tǒng)的數(shù)據(jù)，在生產(chǎn)環(huán)境中，我們的搜索，推薦，廣告服務(wù)每時每刻都在產(chǎn)生大量的流式日志。這些日志數(shù)據(jù)格式不一，形態(tài)各異，他們都是非結(jié)構(gòu)數(shù)據(jù)。

這些數(shù)據(jù)一般都是以文本的方式保存在各個業(yè)務(wù)系統(tǒng)中，對于推薦系統(tǒng)而言，最重要用戶的埋點行為數(shù)據(jù)就存在日志中。而對于這些非關(guān)系型數(shù)據(jù)，我們需要采集到大數(shù)據(jù)的時候，就需要用到Flume。Flume可以采集批量數(shù)據(jù)也可以采集流數(shù)據(jù)。

這兩個工具知道作用即可，不用深究太多。

13 分布式消息隊列：KAFKA
采用Sqoop或者Flume做數(shù)據(jù)采集的時候，可以說是一對一的直采專線服務(wù)模式。我們把生產(chǎn)數(shù)據(jù)的系統(tǒng)叫生產(chǎn)者，消費數(shù)據(jù)的系統(tǒng)叫消費者。隨著系統(tǒng)的發(fā)展，一般生產(chǎn)者和消費者都會越來越多，全部一對一直采，連接數(shù)就會指數(shù)上升，且難以維護。如果生產(chǎn)者的數(shù)據(jù)沒能及時被消費者接收或者丟包，數(shù)據(jù)就會丟失。

為了解決這些問題，Kafka被創(chuàng)造了出來。

通過Kafka，生產(chǎn)者只要把數(shù)據(jù)打包好，標記好Topic，扔到Kafka的消息隊列上就可以了。而消費者，只要做的事情就是訂閱該生產(chǎn)者的Topic。當(dāng)有新的數(shù)據(jù)到達時，Kafka就會告知消費者去取。

數(shù)據(jù)會被暫時保存在Kafka的硬盤中一段時間（一般7天），消費者隨時可以來取。被保存的一系列數(shù)據(jù)塊，就是一個個按時間排序的消息隊列。同樣的，Kakfa也是分布式的，它會被安裝在多個節(jié)點中，數(shù)據(jù)也會被保存在多個節(jié)點中。

14 Lambda架構(gòu)
能看到這里，你已經(jīng)很不容易了，前面已經(jīng)將本文需要介紹的大數(shù)據(jù)組件講完了。

大數(shù)據(jù)實在是太龐大了，而且各司其職，分工得特別細。這么多大數(shù)據(jù)的框架，有離線計算和流式計算，不同的分布式存儲和不同的分布式工具，這些框架是怎么構(gòu)建成一個大數(shù)據(jù)系統(tǒng)的呢？

這就要介紹大數(shù)據(jù)的Lambda架構(gòu)。

Lambda架構(gòu)算大數(shù)據(jù)系統(tǒng)里面舉足輕重的架構(gòu)，數(shù)據(jù)通道分為兩條分支：實時流和離線。

實時流依照流式架構(gòu)，保障了其實時性，而離線則以批處理方式為主，保障了最終一致性，適用于同時存在實時和離線需求的情況。

抽象掉所有的框架，可以把Lambda架構(gòu)簡化成如下方式：

推薦系統(tǒng)是個存儲和算力消耗的大戶，它需要離線計算，對時間不敏感的數(shù)據(jù)進行大批量的計算。也需要實時流式計算，對用戶畫像，物品畫像數(shù)據(jù)進行實時的更新。

把本章中說到的大數(shù)據(jù)的各個框架組件按照Lambda架構(gòu)的方式組建后，我們可以得到下圖：

實際的情況比上圖還要更復(fù)雜些，但是對于本文來說，借用機器學(xué)習(xí)的術(shù)語，再復(fù)雜就要“過擬合”了，適當(dāng)?shù)腄ropOut可以防止過擬合。扔掉一些，可能是更好的。

總結(jié)
千言萬語，匯總成一句話：大數(shù)據(jù)是由分布式存儲，分布式計算和輔助性組件構(gòu)成一個龐大的數(shù)據(jù)技術(shù)生態(tài)體系。它有幾個要知識點：

1. 要理解分布式存儲的機制。因為數(shù)據(jù)量大，數(shù)據(jù)的存儲的最終載體是最簡單文本數(shù)據(jù)，沒有很多花里胡哨的東西。這些文本數(shù)據(jù)被切割成多個數(shù)據(jù)塊，分布式地保存在不同的數(shù)據(jù)節(jié)點中。
2. 要理解分布式計算中的MapReduce機制。理解HIVE的工作機制。理解什么是離線計算，什么是流式計算。
3. 最后，可以的話，記住Lambda架構(gòu)。

寫在最后的話：

大數(shù)據(jù)太多知識點了，受篇幅所限，這次只選擇性地介紹推薦系統(tǒng)需要用到的大數(shù)據(jù)開源類組件。這個生態(tài)體系還在不斷的發(fā)展中，我也還在路上。不足之處，還請各路高手不吝指教。

下篇文章將介紹用戶畫像，敬請期待，謝謝！