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

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

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

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

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

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

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

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

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

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

1. 分布式存儲：把文件切成多份，分布地存儲到多臺機器上。常用的組件有：HDFS,HBase等。
2. 分布式計算：把數據計算的任務切分成多個，分配到多臺機器上計算。常用的組件有：MapReduce，Spark，Storm，Flink等。
3. 分布式工具：數據輔助類工具，資源調度管理工具等。常見的組件有：YARN，Hive，Flume，Sqoop，Elastic Search，ZooKeeper等。

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

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

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

[[358986]]

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

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

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

現在的Hadoop主要分三個部分：

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

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

我們在安裝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)，它是以文本的方式來保存數據的，也就是說，數據一般會跟我們的TXT文件那樣。一個文件會被按照設定，切分成不同的數據塊，然后每個數據塊會被復制成多份，然后分布式地存到不同的節(jié)點中。HDFS把集群節(jié)點分成兩類：NameNode和DataNode。

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

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

上圖中：

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

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

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

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

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

MapReduce計算詳細過程如下：

上圖中：

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

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

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

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

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

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

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

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

為了不再寫又長又煩的JAVA，Hive應運而生。Hive組件就主要做的事情是，將SQL代碼轉譯成MapReduce，然后放入YARN構建的容器里面跑出結果。

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

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

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

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

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

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

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

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

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

下面介紹Spark的計算流程。

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

上圖中：

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

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

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

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

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

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

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

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

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

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

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

這就是HBase的誕生。

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

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

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

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

其中：

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

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

如下如所示：

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

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

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

關系型數據是我們最常見的一種數據，Sqoop是關系型數據庫和大數據之間數據流動的一個橋梁。它可以用來將MySql和Oracle的數據導入HDFS，HBASE中，或者將大數據中的數據導入MySql或Oracle。

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

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

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

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

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

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

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

14 Lambda架構
能看到這里，你已經很不容易了，前面已經將本文需要介紹的大數據組件講完了。

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

這就要介紹大數據的Lambda架構。

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

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

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

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

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

實際的情況比上圖還要更復雜些，但是對于本文來說，借用機器學習的術語，再復雜就要“過擬合”了，適當的DropOut可以防止過擬合。扔掉一些，可能是更好的。

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

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

寫在最后的話：

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

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