你是一個程序員，你做了一個商城網站，里面的東西賣的太好了，每天都會產生巨量的用戶行為和訂單數據，通過分析海量的數據，老板得出一個驚人結論：程序員消費力不如狗。

從技術的角度看，這是一個將海量數據先存起來，再將數據拿出來進行計算，并得到結果的過程。

如果使用 mysql 數據庫將這海量數據存起來，再執行 sql 進行統計，大概率直接卡死。

那么問題來了，怎么讀寫這類海量數據場景呢？

沒有什么是加一層中間層不能解決的，如果有，那就再加一層。

這次我們要加的是 Hadoop 全家桶和它的朋友們。

圖片

Hadoop 是什么？

像我們平時用的 mysql，處理個幾百 GB 數據就已經比較極限了。如果數據再大點，比如 TB，PB 這樣的規模，我們就稱它為大數據。

它不僅數據規模大，增長速度也非常快。mysql根本扛不住。

所以需要有專門的工具做處理。Hadoop 就是一套專門用于大數據處理的工具, 內部由多個組件構成。

你可以將它理解為應用和大數據之間的一個中間層。

以前數據量小的時候，應用程序讀寫 mysql，現在數據量大了，應用程序就改為讀寫 Hadoop全家桶。

Hadoop 為應用程序屏蔽了大數據的一些處理細節，對外提供一系列的讀寫 API, 應用通過調用 API，實現對大數據的處理。

圖片

我們來看下它是怎么做到的。

大數據怎么處理

大數據之所以難處理，本質原因在于它大。所以解決思路也很簡單，核心只有一個字，那就是"切", 將處理不過來的大數據，切分成一份份處理得過來的小數據。

圖片

對小份數據進行存儲，計算等一系列操作。

所以 Hadoop 要解決的核心問題有兩個，一個是怎么存，另一個是怎么算？

圖片

怎么存

對于 TB,PB 級別的大數據，一臺服務器的硬盤裝不下，我們就用多臺服務器的硬盤來裝。

文件太大，那就切。我們可以將大文件切分成一個個 128MB 的數據塊，也就是block。

圖片

放到多臺服務器硬盤上，怕一臺數據崩了影響數據完整性，那就多復制幾份數據在多臺服務器備份著。這些存放數據的服務器，就叫 datanode.

圖片

以前我們只需要從一臺服務器里讀寫數據，現在就變成了需要在多臺服務器里讀寫數據，因此需要有一個軟件為我們屏蔽多臺服務器的讀寫復雜性，這個負責切分和存儲數據的分布式軟件，就叫 HDFS，全名 Hadoop Distributed File System，也就是 Hadoop 的分布式文件系統。

圖片

怎么算

大數據的存儲問題是解決了，那怎么對大數據進行計算呢？

比如，我們需要統計商城所有用戶訂單的性別和消費金額。

假設商城的全部訂單數據共1280G，想從HDFS全部加載到內存中做計算，沒有一臺服務器扛得住，有解法嗎？

有！跟存儲類似，也將數據切分為很多份，每份叫一個分片，也就是 split, 分給多個服務器做計算，然后再將結果聚合起來就好啦。

圖片

但每個服務器怎么知道該怎么計算分片數據呢？

當然是由我們來告訴它們！

我們需要定義一個 map 函數，告訴計算機，每個分片數據里的每行訂單數據該怎么算。

圖片

再定義一個 reduce 函數，告訴計算機 map 函數算好的結果怎么匯總起來計算最終結果。

圖片

這個從hdfs中獲取數據，再切分數據為多個分片，執行計算任務并匯總的過程非常通用，用戶只需要自定義里面的 map 和 reduce 函數就能滿足各種定制化需求，所以我們可以抽象為一個通用的代碼庫，說好聽點，又叫框架，它就是所謂的 MapReduce。

圖片

Yarn 是什么

看到這里問題又來了，MapReduce 的計算任務的數量都這么多，每個任務都需要cpu和內存等服務器計算資源，怎么管理和安排這些計算任務，到哪些服務器節點跑數據呢？

很容易想到，我們可以在計算任務和服務器之間，加一個中間層。

也就是大名鼎鼎的 yarn, 全名 Yet Another Resource Negotiator, 讓它來負責資源的管理。

圖片

它將每個計算任務所需要的資源抽象為容器，Container，它本質上其實就是個被限制了 cpu 和內存等計算資源的 jvm 虛擬機進程，容器內運行計算任務代碼。

圖片

yarn 的容器跟 docker/k8s 的容器概念上有點像，但終究不是一回事。具體區別是什么，評論區告訴我。

圖片

yarn會根據MapReduce這類計算框架的需求，分配容器資源，再由計算框架將計算任務調度到，已分配的服務器容器上運行。通過一系列的資源申請+協調調度，完成 map 和 reduce 的計算任務并最終得到計算結果。

圖片

yarn 和 之前視頻里介紹的k8s 做的事情有點像，它們的區別是什么，看爽了就評論區告訴我。

Hadoop 是什么

到這里，我們用 hdfs 解決了大數據的存儲問題，用 mapreduce 解決了大數據計算問題，用 yarn 解決了 mapreduce 的計算資源管理問題，它們三個核心組件，共同構成了 Hadoop 大數據處理框架。

Hive 是什么

到這里問題又又來了，以前數據存在 mysql 的時候，我想統計下數據，做下數據分析，只需要寫點 sql。

圖片

而現在，在大數據場景下，卻要我寫那么多 map 和 reduce 函數。

你擱這跟我開玩笑呢？這不變相逼著產品運營 BI 天天按著我寫 mapreduce 代碼嗎？

我能寫代碼，不代表我喜歡寫代碼！

我自嘲是牛馬可以，你不能真把我當牛馬吧，那該怎么辦呢？

圖片

為了讓數據分析人員能夠像使用 SQL 一樣方便地查詢大數據，我們需要一個工具來簡化這個過程。

它就是 Hive。你可以將它理解為 sql 和 mapreduce 的一個中間層。

圖片

它可以將用戶輸入的類似 SQL 的查詢語言解析轉換成一個個復雜的 mapreduce 任務，運行并最終輸出計算結果。

圖片

這樣，不會寫代碼的人也可以通過寫 sql 讀寫大數據。

圖片

Spark和Flink 是什么

現在做一次數據分析，Hadoop就得用Hive解析sql，跑mapreduce任務。一不小心半小時就過去了。有辦法更快嗎？

有！MapReduce 會把計算過程中產生的中間結果放在磁盤中，這就導致需要頻繁讀寫磁盤文件，略慢。

為了提升性能，可以將中間結果放在內存中，內存放不下才放磁盤，那處理速度不就上來了嗎，基于這個思路，大佬們設計了Spark, 你可以將它簡單理解為是通過內存強化性能的 MapReduce。

圖片

以前 Hive 可以將 sql 轉化為 Mapreduce 的任務，現在同樣也可以通過一個叫 Hive on Spark 的適配層接入 Spark ，將 sql 轉化為 spark 任務. 這樣 sql 查詢的性能也能得到提升。

圖片

但畢竟 hive 本身不是為 spark 設計的，所以大佬們又設計了 spark sql。它跟 hive 是類似的東西，但跟 spark 搭配起來，性能更好。

圖片

但不管是mapreduce還是 Spark， 都是為離線數據處理設計的，說白了就是數據是一批一批處理的，一條數據來了，得攢夠一批才會被處理. 攢的過程會浪費一些時間，所以為了更高的實時性，大佬們又又設計了 flink, 數據來一條就處理一條，完美應對了實時性要求較高的在線數據處理場景。

圖片

Hbase是什么

雖然現在大數據存算問題及處理問題都解決了。但用hive從海量數據里讀寫一兩條數據，依然是接近分鐘級別的操作， flink雖然實時性高，但一般面向數據處理，而不是在線讀寫場景。有辦法像mysql那樣，在毫秒級別完成實時在線讀寫嗎？

基于這個痛點，大佬們又設計了分布式數據庫Hbase，用于在海量數據中高并發讀寫數據的場景。

圖片

最后我們用一個例子將它們串起來。

寫數據

在大數據場景下，我們將數據寫入到 hdfs 中的多個 datanode 中。

圖片

讀數據

圖片

在數據分析場景，用戶將寫好的 sql，輸入到 hive 中，hive 會將 sql 解析為多個 mapreduce 計算任務，配合 yarn的資源調度，mapreduce這類計算框架，將這些計算任務分發到多個服務器上，再將計算好的結果匯總后，得到最終結果，最后返回給用戶。完成讀數據。

圖片

當然如果追求性能，也可以將 hive 換成 spark sql，將 mapreduce 換成 spark，通過內存加速整個讀數據的過程。對于實時性要求高的場景，可以使用flink。

圖片

對于在線實時查詢場景，可以通過hbase，實現海量數據的毫秒級查詢。

圖片

現在大家通了嗎？

好啦，如果你覺得這期視頻對你有幫助，記得轉發給你那不成器的兄弟。文字版的筆記，見評論區。

最后遺留一個問題，你聽說過Mongodb嗎？你知道它是怎么被設計出來的嗎？有Mysql為什么還要有Mongodb？

視頻點贊超過 1w，下期聊聊這個話題。如果你感興趣，記得關注！我們下期見！

總結

? Hadoop 是一個開源的大數據處理框架，主要用于存儲和處理大數據。它要解決的核心問題有兩個，一個是怎么存，另一個是怎么算

? 大數據之所以難處理，本質原因在于它大。所以解決思路也很簡單，核心只有一個字，那就是"切",

? Hdfs 將處理不過來的大數據切分成一份份處理得過來的小數據塊。每個 128MB，存到多個 DataNode 中，解決了存儲的問題。

? MapReduce 則通過一套代碼框架，將數據處理抽象為 map 和 reduce 兩個階段，用戶只要實現這兩個函數，框架就會將大數據的處理切分成一個個小任務，完成計算。

? yarn 本質上是計算任務和服務器之間的一個中間層，通過一系列協調調度，將計算任務調度到合適的服務器上運行，完成 map 和 reduce 的計算任務并最終得到最終計算結果。