本系列文章將從最簡單的概念開始，逐步講解推薦系統的發展歷程和最新實踐。以產品經理的視角，闡述推薦系統涉及的算法，技術和架構。本章是第三章，將系統性地介紹推薦系統的基石之一：大數據。
大數據是數據智能時代的“鐵公基”，是一系列計算和存儲的基礎設施。推薦系統也是建立在大數據的基礎之上的，大量的數據挖掘和模型訓練都離不開大數據。
大數據這個名詞起的很好，對於非技術人員來說也能get到大的含義：數據量大，算力強大。
但是這強大的能力是怎麼來的？大數據生態體系架構是怎麼分工的？
不具體做過的同學並不清楚。今天就繼續站在產品經理的角度深入淺出地來講述這些問題。其實不一定是產品經理，對大數據感興趣的同學都可以看看。本文比較長，如果時間不夠，建議先Mark下。
01 大數據的誕生與分佈式
在大數據技術誕生之前，數據的存儲和處理大半壁江山都是Oracle和MySql和等數據庫軟件的。這些傳統數據庫的文件系統是單機的，也就是說，數據只能在一臺機器上跑。它們在處理成TB（1024GB）甚至上PB（1024TB）級別數據時就會特別吃力。
第一個解決了這個問題的公司是谷歌。谷歌解決這個問題的思路就是分佈式。谷歌分別於2003-2004年發表了三篇重量級的論文，奠定了大數據的基礎。
簡單的說，谷歌通過論文公佈了以下三個工具如何創造：
- 分佈式文件系統：Google File System
- 分佈式並行計算框架：Google MapReduce
- 分佈式數據庫：BigTable
這個就是大數據技術的開始。從谷歌的這個原點開始，大數據經過多年發展，形成了今天的全貌。
可以用以下三個分類來去解構整個大數據生態：
- 分佈式存儲：把文件切成多份，分佈地存儲到多臺機器上。常用的組件有：HDFS,HBase等。
- 分佈式計算：把數據計算的任務切分成多個，分配到多臺機器上計算。常用的組件有：MapReduce，Spark，Storm，Flink等。
- 分佈式工具：數據輔助類工具，資源調度管理工具等。常見的組件有：YARN，Hive，Flume，Sqoop，Elastic Search，ZooKeeper等。
大數據整個生態體系非常龐大，相關的產品不勝枚舉，讓人看著眼花繚亂，有種物種大爆發的感覺。但是也並非無跡可尋。我們理解大數據生態，從這三個方面去理解就會輕鬆很多。本文也是嚴格按照這個方式來講述。
02 本文講述需要用的數據表
鑑於大數據生態過於龐大複雜，為了使得文章更加淺顯易懂，本文不對技術概念做過多的描述，而是直接到操作層面，以圖示的方式講解。因為要講述的是數據系統，我這裡建一張數據表USER，用這張數據表在各個系統中處理過程來給大家講述大數據各個組件的工作原理和機制。
03 Hadoop
整個互聯網技術生態圈中，谷歌是超級績優生。每次發表論文，都會引起眾多人員前來“抄作業”。Hadoop之父Doug Cutting和他的團隊就是其中一個。他花了兩年的業餘時間，照著谷歌的論文實現了一個分佈式數據系統，並用自己兒子的大象毛絨玩具的名字給這個系統命名為Hadoop。Hadoop的Logo也是個頭大象。
後來到了2006年，Hadoop被引入Apache基金會，成為一個開源的頂級項目。隨著Hadoop的不斷髮展，在Hadoop項目中，誕生了HBase，Hive，Pig，Zookeeper等子項目，並先後被Apache基金會將其獨立升級成為頂級項目。
同時，Apache基金會也不斷兼收幷蓄其他大數據項目，基本把絕大多數優秀的大數據項目都收入麾下，大有天下武功出少林的味道。大數據各種開源組件中，Apache旗下的才是少林正宗。
閒話不多說，我們來講Hadoop。
現在的Hadoop主要分三個部分：
- 分佈式存儲：HDFS(Hadoop Distributed File System)，一個高可靠、高吞吐量的分佈式文件系統，實現海量數據存儲。
- 分佈式計算：MapReduce，一個分佈式離線並行計算計算框架，實現海量計算。
- 分佈式工具：YARN，一個集群資源調度管理的框架，實現硬件資源的調配。
04 圖解分佈式
這裡先具象的解釋下，什麼是大數據的分佈式長什麼樣？
我們在安裝Hadoop的時候，要把同一個Hadoop的軟件安裝包，安裝在三臺以上不同的機器上。安裝好後，我們就可以得到一個Hadoop分佈式集群。
如下圖，我們將Hadoop的三個組件，安裝在集群每一臺機器上，這個集群有七臺機器。每一臺機器叫一個節點。這七個節點中，要選出一個做老大，我們有什麼事情先找這個老大，這個就是主節點。因為主節點很重要，它要是掛了，整個集群就掛了。所以一般主節點配置兩臺，一臺備份。其他五個節點叫做
從節點。在Hadoop中，主節點命名為Master，從節點為Slave。
05 分佈式文件系統：HDFS
下面將Hadoop的第一個組件HDFS。HDFS作為分佈式的文件系統，它是以文本的方式來保存數據的，也就是說，數據一般會跟我們的TXT文件那樣。一個文件會被按照設定，切分成不同的數據塊，然後每個數據塊會被複製成多份，然後分佈式地存到不同的節點中。HDFS把集群節點分成兩類：NameNode和DataNode。
- NameNode可以理解成數據目錄，它記錄了每個數據塊在哪臺機器的哪個位置。這個功能由主節點承擔。
- DataNode顧名思義就是存數據的節點了。
下面以USER數據表為例，舉例說明HDFS的運作過程。實際的系統中，因為NameNode負荷比較重，會設置一個SecondaryNameNode來協助NameNode的工作（注意是協助，而不是備份）。
上圖中：
- HDFS先把深藍色的文本數據切分成三份。每份數據按照系統設定，如64MB或128MB一塊。
- 將三份數據塊複製成三份，這樣就有九份數據。
- 把上一步得到的九份數據劃分到不同的DataNode中，並建好目錄。
- 按照儲存分配，把各個數據塊保存。
HDFS優點：數據容量大，是大數據最主要的數據存儲方式。很多其他組件都是建立在HDFS的基礎上，應用非常廣泛。
HDFS的缺點：它是個文件系統，而不是數據庫系統，不能像關係數據庫系統那樣建立索引等工具提升處理速度和定位到數據位置。因為數據記錄的形式是一行一行的字符串，沒辦法定位，不支持對數據的直接修改。
06 分佈式離線計算引擎：MapReduce
MapReduce是專門負責分佈式計算的，它是是一個組合詞，可以分成兩個部分：Map和Reduce。
簡單的說，Map就是把要計算的數據分解成多個計算任務，而Reduce則是Map過程得到的結果進行彙總。假設現在我們要計算在USER表中，男女各有多少人。
MapReduce計算詳細過程如下：
上圖中：
- Splitting階段，把數據分成三塊。Splitting一般就是在HDFS存儲時的切分的基礎上再次切分。
- Mapper則為每個切分的數據塊建一個Mapping任務，逐條地計算每條數據的結果，然後在磁盤中存起來。
- Shuffling也就是將Mapping階段的結果進行分揀，shuffle任務要等Mapping完全完成後才能開展。
- Reducing就是將分揀好的數據，進行彙總。
通過這種方式，MapReduce獲得了強大的運算能力。
MapReduce優點：計算能力強大，運算耗費成本低廉，在運算能力一般的機器上也能運行。
MapReduce缺點：它誕生的年代，內存還很貴，在計算的過程中，中間結果要不斷存入磁盤中，以減少內存的壓力，但是這樣導致了MapReduce運算速度比較慢。另外就是代碼不簡潔，學習曲線比較陡，後面在HIVE部分會講述。
07 資源管理調度系統：YARN
YARN的全稱是Yet Another Resource Negotiator，直譯就是另一種資源協調者。
看名字就知道，他是Hadoop中其中一種資源調度器。它的最重要的組件是ResourceManager，通過這個組件，YARN可以為我們的MapReduce任務進行資源分配，分配的資源就是一個個的計算容器，每個計算的任務就在這個容器中跑。由於優秀，後來YARN進一步被髮揚光大，成了Hadoop以外的很多大數據組件的資源調度框架。
08 數據分析和數據倉庫工具：HIVE
在MapReduce的中，處理數據作業的程序是要通過JAVA來實現的，但是JAVA在寫MapReduce的過程並不簡潔。像我們前面提到的統計數據表中男女人數這個簡單的操作，需要嚴格按照Input到Reducing這五步來實現，代碼一般長達上百行。
但是統計這個數據結果，對於SQL來說，就是一句話的事：SELECT sex，COUNT(1) FROM USER GROUP BY sex。
為了不再寫又長又煩的JAVA，Hive應運而生。Hive組件就主要做的事情是，將SQL代碼轉譯成MapReduce，然後放入YARN構建的容器裡面跑出結果。
這樣，我們要統計USER表中的男女人數的時候，就不用寫JAVA實現也能調動MapReduce了，這裡我們畫圖說明一下：
另外，Hive除了轉譯SQL的功能外，它也可以用來建數據庫和數據表。一個數據庫擁有的能力它都有，而且還可以處理大量的數據，所以一般還會將Hive用來建數據倉庫。數據倉庫的主要功能，就是把歷史數據都存進去，可以反覆地統計計算使用。數據倉庫最主要的特徵就是數據量特別大。
由於它是構建於HADOOP的基礎上，Hive可計算的容量大，運算能力強，但是速度不快。Hive也不能直接修改數據。對Hive進行數據的修改操作非常費時。
最後，介紹一下Hive和MySql的區別：
- MySql是關係型數據庫，它適合用於聯機事務數據管理。如用戶註冊，修改暱稱等數據操作，可以讓用戶對數據進行實時快速地增刪改查。
- HIVE是建立的HADOOP基礎上的數據倉庫工具。它適合計算大容量數據的場景，因為計算速度比較慢，不能用來進行實時響應的事務性場景。
09 離線計算和流式計算DAG計算引擎：SPARK
Spark是分佈式計算引擎，是大數據生態體系中的一個速度快，功能強大的一個組件。Spark整個框架非常龐大，提供能非常豐富的離線計算和流式計算能力。
本小節先介紹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表的數據時，會經過以下過程：
上圖中：
- 數據讀取：數據讀取可以從文本，HDFS，HIVE，JSON等多種格式中讀取。
- 轉換成DataFrame：把讀取的數據錶轉換成Spark的內置格式DataFrame，並上圖中命名為USER_DF。有了DataFrame就可以直接對它進行算子操作。上圖中用到的groupby和count都是算子。算子的作用就是執行某類計算的操作。
- groupby算子運算：groupby就是分組的算子。它實現了按照男女對數據進行了分組，得到一個分組後的新DataFrame，上圖中命名為GROUPBY_DF。每次算子運算後，都得到一個新的DataFrame。
- count算子運算：從上一步的結果中，再次進行個數計算，得出最後結果RESULT_DF。
多個算子混合後，就形成了一個DAG，上面的操作，會形成以下的DAG。Spark通過構建DAG，然後下發給從節點計算。
同時這個計算過程也是像MapReduce那樣，將計算任務分解成Map和Reduce兩個階段，分佈式地在多臺機器中計算，這裡不再描述。
10 離線計算和流式計算
MapReduce和Spark都是離線計算的代表，離線計算就是計算前已經有了所有需要計算的數據，且每次計算都是所有的數據都參與的運算。因為每次都是一整批數據做計算，所以離線計算一般又叫批量計算。但是日常的事務中，有很多場景是需要不斷實時的更新數據的。
假設我們的USER表，現在因為有個新用戶註冊，多了一條用戶數據“蔡九，女，27”。離線計算就要把新數據彙總，然後再進行計算：
增加一條用戶日誌，就要對全部的進行計算，在數據量非常龐大的時候，這根本是不可能的事情。所以我們還要另外一種計算方式，那就是流式計算。流式計算因其實時性，又常被叫做在線計算和實時計算。
以下是流式計算的過程，同樣的新增數據，流失計算只要對新增數據進行計算，然後彙總更新：
流式計算引擎有：SPARK streaming，Storm和Flink。它們都可以提供流式計算的服務，但是有些不同。
- SPARK streaming是使用微批的方式計算流數據。微批就是小批量的意思。SPARK streaming並不是一條一條地計算新數據流，而且小批量的計算。比如幾分鐘算一次，或者幾十條算一次。像割韭菜那樣，等長夠高了，再收割，一茬又一茬。
- Storm和Flink就是來一條計算一條地處理數據流了。像流水線作業那樣，不斷地逐個逐個處理。值得一提的是，最近兩年Flink很火，在推薦系統上被廣泛用來計算如用戶畫像等實時性較高的數據。
11 分佈式結構化存儲系統：HBASE
前面說到谷歌三篇關於大數據的論文，這裡再補充一下它們後來的演變結果：
- 分佈式文件系統：Google File System，演變成Hadoop的HDFS。
- 分佈式並行計算框架：Google MapReduce，演變成Hadoop的MapReduce。
- 分佈式數據庫：BigTable，演變成了另外一個大名鼎鼎的HBase。
這就是HBase的誕生。
HBase是一個NoSql數據庫。它在整個大數據生態中的定位是對數據進行實時的操作：查詢，更新，刪除和插入。前面說到HIVE是能處理大量數據，但是速度慢且不能對數據進行修改，而MySql等傳統數據庫響應快但是運算能力不足。HBase的出現，就是為了解決這些問題。
NoSql數據庫的意思就是不支持SQL語句的數據庫，HBase有以下特徵：
- HBase最終存儲是基於HDFS的，有存儲海量數據能力。
- HBase的增刪改查是分佈式的，也就是一次修改，是多個節點服務器的修改。
- HBase的表結構跟關係型數據庫是不一樣的。
- HBase有很快的讀取響應速度。
為了方便理解，我們直接畫圖看HBase怎麼工作。如何把我們的USER數據表放入HBase後，它是長成這樣子的：
其中：
- rowkey是行鍵，是每行數據的編號。
- Users_info叫做列族，是保存數據的表頭。
- HBASE中，每個數據都被保存成為key:value的鍵值對，每個鍵值對叫做cell（單元格）。如name：張三就是一個cell。
MySql中，修改數據就會覆蓋掉舊數據。但是在HBase中，同個鍵值對可以保留多個數據版本。這個版本會以時間戳的形式來標記。如張三，有一天改名叫張三丰了，它並不會覆蓋掉原有的張三，而是兩個版本都保存起來。
如下如所示：
HBase有強大的讀取和增刪改查能力，加上可以保存不同時間的數據版本，在推薦系統中，用戶畫像的結果數據，離線召回，近線召回等數據，都是保存在HBase中。另外，HBase可以做到快速響應，推薦系統中需要快速讀取的數據，都可以存在HBase中。
12 數據採集
大數據的誕生，並不是取代掉傳統的關係型數據庫，而是變成一種補充。傳統數據庫存不下的數據，大數據來存。傳統數據庫算不了的數據，大數據來算。大數據系統只是把現有系統的數據採集到大數據中，做存儲和計算，對已有的業務流程和系統架構並沒有什麼影響。
將數據採集到大數據，一般用到兩個工具：Sqoop、Flume。其實不同公司使用的數據採集工具不一樣，這裡只是簡單的介紹。
關係型數據是我們最常見的一種數據，Sqoop是關係型數據庫和大數據之間數據流動的一個橋樑。它可以用來將MySql和Oracle的數據導入HDFS，HBASE中，或者將大數據中的數據導入MySql或Oracle。
另外一種常見的數據是來自於日誌系統的數據，在生產環境中，我們的搜索，推薦，廣告服務每時每刻都在產生大量的流式日誌。這些日誌數據格式不一，形態各異，他們都是非結構數據。
這些數據一般都是以文本的方式保存在各個業務系統中，對於推薦系統而言，最重要用戶的埋點行為數據就存在日誌中。而對於這些非關係型數據，我們需要採集到大數據的時候，就需要用到Flume。Flume可以採集批量數據也可以採集流數據。
這兩個工具知道作用即可，不用深究太多。
13 分佈式消息隊列：KAFKA
採用Sqoop或者Flume做數據採集的時候，可以說是一對一的直採專線服務模式。我們把生產數據的系統叫生產者，消費數據的系統叫消費者。隨著系統的發展，一般生產者和消費者都會越來越多，全部一對一直採，連接數就會指數上升，且難以維護。如果生產者的數據沒能及時被消費者接收或者丟包，數據就會丟失。
為了解決這些問題，Kafka被創造了出來。
通過Kafka，生產者只要把數據打包好，標記好Topic，扔到Kafka的消息隊列上就可以了。而消費者，只要做的事情就是訂閱該生產者的Topic。當有新的數據到達時，Kafka就會告知消費者去取。
數據會被暫時保存在Kafka的硬盤中一段時間（一般7天），消費者隨時可以來取。被保存的一系列數據塊，就是一個個按時間排序的消息隊列。同樣的，Kakfa也是分佈式的，它會被安裝在多個節點中，數據也會被保存在多個節點中。
14 Lambda架構
能看到這裡，你已經很不容易了，前面已經將本文需要介紹的大數據組件講完了。
大數據實在是太龐大了，而且各司其職，分工得特別細。這麼多大數據的框架，有離線計算和流式計算，不同的分佈式存儲和不同的分佈式工具，這些框架是怎麼構建成一個大數據系統的呢？
這就要介紹大數據的Lambda架構。
Lambda架構算大數據系統裡面舉足輕重的架構，數據通道分為兩條分支：實時流和離線。
實時流依照流式架構，保障了其實時性，而離線則以批處理方式為主，保障了最終一致性，適用於同時存在實時和離線需求的情況。
抽象掉所有的框架，可以把Lambda架構簡化成如下方式：
推薦系統是個存儲和算力消耗的大戶，它需要離線計算，對時間不敏感的數據進行大批量的計算。也需要實時流式計算，對用戶畫像，物品畫像數據進行實時的更新。
把本章中說到的大數據的各個框架組件按照Lambda架構的方式組建後，我們可以得到下圖：
實際的情況比上圖還要更復雜些，但是對於本文來說，借用機器學習的術語，再複雜就要“過擬合”了，適當的DropOut可以防止過擬合。扔掉一些，可能是更好的。
總結
千言萬語，彙總成一句話：大數據是由分佈式存儲，分佈式計算和輔助性組件構成一個龐大的數據技術生態體系。 它有幾個要知識點：
- 要理解分佈式存儲的機制。因為數據量大，數據的存儲的最終載體是最簡單文本數據，沒有很多花裡胡哨的東西。這些文本數據被切割成多個數據塊，分佈式地保存在不同的數據節點中。
- 要理解分佈式計算中的MapReduce機制。理解HIVE的工作機制。理解什麼是離線計算，什麼是流式計算。
- 最後，可以的話，記住Lambda架構。
寫在最後的話：
大數據太多知識點了，受篇幅所限，這次只選擇性地介紹推薦系統需要用到的大數據開源類組件。這個生態體系還在不斷的發展中，我也還在路上。不足之處，還請各路高手不吝指教。
下篇文章將介紹用戶畫像，敬請期待，謝謝！
題圖來自Unsplash，基於CC0協議
閱讀更多 人人都是產品經理 的文章
