一、Hadoop

1.1. 概念

就是一個大資料解決方案，它提供了一套分布式系統基礎架構， 核心內容包含 hdfs 和mapreduce，
hadoop2.0 以后引入 yarn.
hdfs 是提供資料存盤的，mapreduce 是方便資料計算的，

1. hdfs 又對應 namenode 和 datanode. namenode 負責保存元資料的基本資訊，
   datanode 直接存放資料本身；
2. mapreduce 對應 jobtracker 和 tasktracker. jobtracker 負責分發任務，tasktracker 負
   責執行具體任務；
3. 對應到 master/slave 架構，namenode 和 jobtracker 就應該對應到 master, datanode
   和 tasktracker 就應該對應到 slave.

1.2. HDFS

需要這份java學習筆記資料的點這里-》》》》》》》

1.2.1. Client

Client（代表用 戶） 通過與 NameNode 和 DataNode 互動訪問 HDFS 中 的檔案， Client 提供了一個類似 POSIX 的檔案系統介面供用戶呼叫，

1.2.2. NameNode

整個 Hadoop 集群中只有一個 NameNode， 它是整個系統的“ 總管”， 負責管理 HDFS 的目
錄樹和相關的檔案元資料資訊， 這些資訊是以“ fsimage”（ HDFS 元資料鏡像檔案）和
“ editlog”（HDFS 檔案改動日志）兩個檔案形式存放在本地磁盤，當 HDFS 重啟時重新構造出來的，此外， NameNode 還負責監控各個 DataNode 的健康狀態， 一旦發現某個 DataNode 宕掉，則將該 DataNode 移出 HDFS 并重新備份其上面的資料，

1.2.3. Secondary NameNode

Secondary NameNode 最重要的任務并不是為 NameNode 元資料進行熱備份， 而是定期合并fsimage 和 edits 日志， 并傳輸給 NameNode， 這里需要注意的是，為了減小 NameNode 壓力， NameNode 自己并不會合并 fsimage 和 edits， 并將檔案存盤到磁盤上， 而是交由Secondary NameNode 完成，

1.2.4. DataNode

一般而言， 每個 Slave 節點上安裝一個 DataNode， 它負責實際的資料存盤， 并將資料資訊定期匯報給 NameNode， DataNode 以固定大小的 block 為基本單位組織檔案內容， 默認情況下block 大小為 64MB， 當用戶上傳一個大的檔案到 HDFS 上時， 該檔案會被切分成若干個 block，分別存盤到不同的 DataNode ； 同時，為了保證資料可靠， 會將同一個 block 以流水線方式寫到若干個（默認是 3，該引數可配置）不同的 DataNode 上， 這種檔案切割后存盤的程序是對用戶透明的，

1.3. MapReduce

需要這份java學習筆記資料的點這里-》》》》》》》

同 HDFS 一樣，Hadoop MapReduce 也采用了 Master/Slave（M/S）架構，具體如圖所示，它主要由以下幾個組件組成：Client、JobTracker、TaskTracker 和 Task， 下面分別對這幾個組件進行介紹，

1.3.1. Client

用戶撰寫的 MapReduce 程式通過 Client 提交到 JobTracker 端； 同時， 用戶可通過 Client 提供的一些介面查看作業運行狀態， 在 Hadoop 內部用“作業”（Job） 表示 MapReduce 程式，
一個 MapReduce 程式可對應若干個作業，而每個作業會被分解成若干個 Map/Reduce 任務
（Task），

1.3.2. JobTracker

JobTracker 主要負責資源監控和作業調度，JobTracker 監控所有 TaskTracker 與作業的健康狀況，一旦發現失敗情況后，其會將相應的任務轉移到其他節點；同時 JobTracker 會跟蹤任務的執行進度、資源使用量等資訊，并將這些資訊告訴任務調度器，而調度器會在資源出現空閑時，選擇合適的任務使用這些資源，在 Hadoop 中，任務調度器是一個可插拔的模塊，用戶可以根據自己的需要設計相應的調度器，

1.3.3. TaskTracker

TaskTracker 會周期性地通過 Heartbeat 將本節點上資源的使用情況和任務的運行進度匯報給JobTracker， 同時接收 JobTracker 發送過來的命令并執行相應的操作（如啟動新任務、 殺死任務等），TaskTracker 使用“slot” 等量劃分本節點上的資源量，“slot” 代表計算資源（CPU、記憶體等），一個 Task 獲取到一個 slot 后才有機會運行，而 Hadoop 調度器的作用就是將各個TaskTracker 上的空閑 slot 分配給 Task 使用， slot 分為 Map slot 和 Reduce slot 兩種，分別供MapTask 和 Reduce Task 使用， TaskTracker 通過 slot 數目（可配置引數）限定 Task 的并發度，

1.3.4. Task

Task 分為 Map Task 和 Reduce Task 兩種， 均由 TaskTracker 啟動， HDFS 以固定大小的 block 為基本單位存盤資料， 而對于 MapReduce 而言， 其處理單位是 split，split 與 block 的對應關系如圖所示， split 是一個邏輯概念， 它只包含一些元資料資訊， 比如資料起始位置、資料長度、資料所在節點等，它的劃分方法完全由用戶自己決定， 但需要注意的是，split 的多少決定了 Map Task 的數目 ，因為每個 split 會交由一個 Map Task 處理，
Map Task 執行程序如圖所示， 由該圖可知，Map Task 先將對應的 split 迭代決議成一個個
key/value 對，依次呼叫用戶自定義的 map() 函式進行處理，最終將臨時結果存放到本地磁盤上，其中臨時資料被分成若干個 partition，每個 partition 將被一個 Reduce Task 處理，

1.3.5. Reduce Task 執行程序

該程序分為三個階段

1. 從遠程節點上讀取 MapTask 中間結果（稱為“Shuffle 階段”）；
2. 按照 key 對 key/value 對進行排序（稱為“ Sort 階段”）；
3. 依次讀取<key, value list>，呼叫用戶自定義的 reduce() 函式處理，并將最終結果存到 HDFS
   上（稱為“ Reduce 階段”），

1.4. Hadoop MapReduce 作業的生命周期

需要這份java學習筆記資料的點這里-》》》》》》》

1.作業?交與初始化

1. 用戶提交作業后， 首先由 JobClient 實體將作業相關資訊， 比如將程式 jar 包、作業配置文
   件、 分片元資訊檔案等上傳到分布式檔案系統（ 一般為 HDFS）上，其中，分片元資訊檔案
   記錄了每個輸入分片的邏輯位置資訊， 然后 JobClient 通過 RPC 通知 JobTracker，
   JobTracker 收到新作業提交請求后， 由 作業調度模塊對作業進行初始化：為作業創建一個
   JobInProgress 物件以跟蹤作業運行狀況， 而 JobInProgress 則會為每個 Task 創建一個
   TaskInProgress 物件以跟蹤每個任務的運行狀態， TaskInProgress 可能需要管理多個
   “ Task 運行嘗試”（ 稱為“ Task Attempt”），
   2.任務調度與監控，
2. 前面提到，任務調度和監控的功能均由 JobTracker 完成，TaskTracker 周期性地通過
   Heartbeat 向 JobTracker 匯報本節點的資源使用 情況， 一旦出 現空閑資源， JobTracker
   會按照一定的策略選擇一個合適的任務使用該空閑資源， 這由任務調度器完成， 任務調度器
   是一個可插拔的獨立模塊， 且為雙層架構， 即首先選擇作業， 然后從該作業中選擇任務， 其
   中，選擇任務時需要重點考慮資料本地性， 此外，JobTracker 跟蹤作業的整個運行程序，并
   為作業的成功運行提供全方位的保障， 首先， 當 TaskTracker 或者 Task 失敗時， 轉移計算
   任務 ； 其次， 當某個 Task 執行進度遠落后于同一作業的其他 Task 時，為之啟動一個相同
   Task， 并選取計算快的 Task 結果作為最終結果，
   3.任務運行環境準備
3. 運行環境準備包括 JVM 啟動和資源隔 離， 均由 TaskTracker 實作， TaskTracker 為每個
   Task 啟動一個獨立的 JVM 以避免不同 Task 在運行程序中相互影響 ； 同時，TaskTracker 使
   用了作業系統行程實作資源隔離以防止 Task 濫用資源，
   4.任務執行
4. TaskTracker 為 Task 準備好運行環境后， 便會啟動 Task， 在運行程序中， 每個 Task 的最
   新進度首先由 Task 通過 RPC 匯報給 TaskTracker， 再由 TaskTracker 匯報給 JobTracker，
   5.作業完成，
5. 待所有 Task 執行完畢后， 整個作業執行成功，

二. Spark

需要這份java學習筆記資料的點這里-》》》》》》》

2.1. 概念

Spark 提供了一個全面、統一的框架用于管理各種有著不同性質（文本資料、圖表資料等）的資料集和資料源（批量資料或實時的流資料）的大資料處理的需求，

2.2. 核心架構

Spark Core
包含 Spark 的基本功能；尤其是定義 RDD 的 API、操作以及這兩者上的動作，其他 Spark 的庫都是構建在 RDD 和 Spark Core 之上的
*Spark SQL
提供通過 Apache Hive 的 SQL 變體 Hive 查詢語言（HiveQL）與 Spark 進行互動的 API，每個資料庫表被當做一個 RDD，Spark SQL 查詢被轉換為 Spark 操作，
Spark Streaming
對實時資料流進行處理和控制，Spark Streaming 允許程式能夠像普通 RDD 一樣處理實時資料
Mllib
一個常用機器學習演算法庫，演算法被實作為對 RDD 的 Spark 操作，這個庫包含可擴展的學習演算法，比如分類、回歸等需要對大量資料集進行迭代的操作，
GraphX
控制圖、并行圖操作和計算的一組演算法和工具的集合，GraphX 擴展了 RDD API，包含控制圖、創建子圖、訪問路徑上所有頂點的操作

2.3. 核心組件

Cluster Manager-制整個集群，監控 worker
在 standalone 模式中即為 Master 主節點，控制整個集群，監控 worker，在 YARN 模式中為資源管理器
Worker 節點-負責控制計算節點
從節點，負責控制計算節點，啟動 Executor 或者 Driver，
Driver： 運行 Application 的 main()函式
Executor：執行器，是為某個 Application 運行在 worker node 上的一個行程

2.4. SPARK 編程模型

Spark 應用程式從撰寫到提交、執行、輸出的整個程序如圖所示，圖中描述的步驟如下：

1. 用戶使用 SparkContext 提供的 API（常用的有 textFile、sequenceFile、runJob、stop 等）
   撰寫 Driver application 程式，此外 SQLContext、HiveContext 及 StreamingContext 對
   SparkContext 進行封裝，并提供了 SQL、Hive 及流式計算相關的 API，
2. 使用SparkContext提交的用戶應用程式，首先會使用BlockManager和BroadcastManager
   將任務的 Hadoop 配置進行廣播，然后由 DAGScheduler 將任務轉換為 RDD 并組織成 DAG，
   DAG 還將被劃分為不同的 Stage，最后由 TaskScheduler 借助 ActorSystem 將任務提交給
   集群管理器（Cluster Manager），
3. 集群管理器（ClusterManager）給任務分配資源，即將具體任務分配到Worker上，Worker
   創建 Executor 來處理任務的運行，Standalone、YARN、Mesos、EC2 等都可以作為 Spark
   的集群管理器，

2.5. SPARK 計算模型

RDD 可以看做是對各種資料計算模型的統一抽象，Spark 的計算程序主要是 RDD 的迭代計算程序，RDD 的迭代計算程序非常類似于管道，磁區數量取決于 partition 數量的設定，每個磁區的資料只會在一個 Task 中計算，所有磁區可以在多個機器節點的 Executor 上并行執行，

2.6. SPARK 運行流程

1. 構建 Spark Application 的運行環境，啟動 SparkContext
2. SparkContext 向資源管理器（可以是 Standalone，Mesos，Yarn）申請運行 Executor 資源，并啟動 StandaloneExecutorbackend，
3. Executor 向 SparkContext 申請 Task
4. SparkContext 將應用程式分發給 Executor
5. SparkContext 構建成 DAG 圖，將 DAG 圖分解成 Stage、將 Taskset 發送給 Task Scheduler，最后由 Task Scheduler 將 Task 發送給 Executor 運行
6. Task 在 Executor 上運行，運行完釋放所有資源

2.7. SPARK RDD 流程

1. 創建 RDD 物件
2. DAGScheduler 模塊介入運算，計算 RDD 之間的依賴關系，RDD 之間的依賴關系就形成了
   DAG
3. 每一個 Job 被分為多個 Stage，劃分 Stage 的一個主要依據是當前計算因子的輸入是否是確
   定的，如果是則將其分在同一個 Stage，避免多個 Stage 之間的訊息傳遞開銷

2.8. SPARK RDD

需要這份java學習筆記資料的點這里-》》》》》》》

（1）RDD 的創建方式
1）從 Hadoop 檔案系統（或與Hadoop兼容的其他持久化存盤系統，如Hive、Cassandra、
HBase）輸入（例如 HDFS）創建，
2）從父 RDD 轉換得到新 RDD，
3）通過 parallelize 或 makeRDD 將單機資料創建為分布式 RDD，
（2）RDD 的兩種操作算子（轉換（Transformation）與行動（Action））
對于 RDD 可以有兩種操作算子：轉換（Transformation）與行動（Action），
1）轉換（Transformation）：Transformation操作是延遲計算的，也就是說從一個RDD轉
換生成另一個 RDD 的轉換操作不是馬上執行，需要等到有 Action 操作的時候才會真正觸
發運算，

2）行動（Action）：Action 算子會觸發 Spark 提交作業（Job），并將資料輸出 Spark 系統，

三. Storm

需要這份java學習筆記資料的點這里-》》》》》》》

3.1. 概念

Storm 是一個免費并開源的分布式實時計算系統，利用 Storm 可以很容易做到可靠地處理無限的資料流，像 Hadoop 批量處理大資料一樣，Storm 可以實時處理資料，

3.1. 集群架構

3.1.1. Nimbus（master-代碼分發給 Supervisor）

Storm 集群的 Master 節點，負責分發用戶代碼，指派給具體的 Supervisor 節點上的 Worker 節點，去運行 Topology 對應的組件（Spout/Bolt）的 Task，

3.1.2. Supervisor（slave-管理 Worker 行程的啟動和終止）

Storm 集群的從節點，負責管理運行在 Supervisor 節點上的每一個 Worker 行程的啟動和終止，通過 Storm 的組態檔中的 supervisor.slots.ports 配置項，可以指定在一個 Supervisor 上最大允許多少個 Slot，每個 Slot 通過埠號來唯一標識，一個埠號對應一個 Worker 行程（如果該Worker 行程被啟動），

3.1.3. Worker（具體處理組件邏輯的行程）

運行具體處理組件邏輯的行程，Worker 運行的任務型別只有兩種，一種是 Spout 任務，一種是Bolt 任務，

3.1.4. Task

worker中每一個spout/bolt的執行緒稱為一個task. 在storm0.8 之后，task不再與物理執行緒對應，不同 spout/bolt 的 task 可能會共享一個物理執行緒，該執行緒稱為 executor，

3.1.5. ZooKeeper

用來協調 Nimbus 和 Supervisor，如果 Supervisor 因故障出現問題而無法運行 Topology，
Nimbus 會第一時間感知到，并重新分配 Topology 到其它可用的 Supervisor 上運行

3.2. 編程模型（spout->tuple->bolt）

strom 在運行中可分為 spout 與 bolt 兩個組件，其中，資料源從 spout 開始，資料以 tuple 的方式發送到 bolt，多個 bolt 可以串連起來，一個 bolt 也可以接入多個 spot/bolt.運行時原理如下圖：

3.2.1. Topology

Storm 中運行的一個實時應用程式的名稱，將 Spout、 Bolt 整合起來的拓撲圖，定義了 Spout 和Bolt 的結合關系、并發數量、配置等等，

3.2.2. Spout

在一個 topology 中獲取源資料流的組件，通常情況下 spout 會從外部資料源中讀取資料，然后轉換為 topology 內部的源資料，

3.2.3. Bolt

接受資料然后執行處理的組件,用戶可以在其中執行自己想要的操作，

3.2.4. Tuple

一次訊息傳遞的基本單元，理解為一組訊息就是一個 Tuple，

3.2.5. Stream

Tuple 的集合，表示資料的流向，

3.3. Topology 運行

在 Storm 中,一個實時應用的計算任務被打包作為 Topology 發布，這同 Hadoop MapReduce
任務相似，但是有一點不同的是:在 Hadoop 中，MapReduce 任務最侄訓執行完成后結束；而在Storm 中，Topology 任務一旦提交后永遠不會結束，除非你顯示去停止任務，計算任務
Topology 是由不同的 Spouts 和 Bolts，通過資料流（Stream）連接起來的圖｡一個 Storm 在集群上運行一個 Topology 時，主要通過以下 3 個物體來完成 Topology 的執行作業：
(1). Worker（行程）
(2). Executor（執行緒）
(3). Task

3.3.1. Worker(1 個 worker 行程執行的是 1 個 topology 的子集)

1 個 worker 行程執行的是 1 個 topology 的子集（注：不會出現 1 個 worker 為多個 topology
服務），1 個 worker 行程會啟動 1 個或多個 executor 執行緒來執行 1 個 topology 的
component(spout 或 bolt)，因此，1 個運行中的 topology 就是由集群中多臺物理機上的多個
worker 行程組成的，

3.3.2. Executor(executor 是 1 個被 worker 行程啟動的單獨執行緒)

executor 是 1 個被 worker 行程啟動的單獨執行緒，每個 executor 只會運行 1 個 topology 的 1 個component(spout 或 bolt)的 task（注：task 可以是 1 個或多個，storm 默認是 1 個
component 只生成 1 個 task，executor 執行緒里會在每次回圈里順序呼叫所有 task 實體），

3.3.3. Task(最終運行 spout 或 bolt 中代碼的單元)

是最終運行 spout 或 bolt 中代碼的單元（注：1 個 task 即為 spout 或 bolt 的 1 個實體，
executor 執行緒在執行期間會呼叫該 task 的 nextTuple 或 execute 方法），topology 啟動后，1 個 component(spout 或 bolt)的 task 數目是固定不變的，但該 component 使用的 executor 執行緒數可以動態調整（例如：1 個 executor 執行緒可以執行該 component 的 1 個或多個 task 實體），這意味著，對于 1 個 component 存在這樣的條件：#threads<=#tasks（即：執行緒數小于等于 task 數目），默認情況下 task 的數目等于 executor 執行緒數目，即 1 個 executor 執行緒只運行 1 個 task，

3.4. Storm Streaming Grouping

Storm 中最重要的抽象，應該就是 Stream grouping 了，它能夠控制 Spot/Bolt 對應的 Task 以什么樣的方式來分發 Tuple，將 Tuple 發射到目的 Spot/Bolt 對應的 Task.

目前，Storm Streaming Grouping 支持如下幾種型別：

3.4.1. huffle Grouping

隨機分組，盡量均勻分布到下游 Bolt 中將流分組定義為混排，這種混排分組意味著來自 Spout 的輸入將混排，或隨機分發給此 Bolt 中的任務，shuffle grouping 對各個 task 的 tuple 分配的比較均勻，

3.4.2. Fields Grouping

按欄位分組，按資料中 field 值進行分組；相同 field 值的 Tuple 被發送到相同的 Task 這種
grouping 機制保證相同 field 值的 tuple 會去同一個 task，

3.4.3. All grouping ：廣播

廣播發送， 對于每一個 tuple 將會復制到每一個 bolt 中處理，

3.4.4. Global grouping

全域分組，Tuple 被分配到一個 Bolt 中的一個 Task，實作事務性的 Topology，Stream 中的所有的 tuple 都會發送給同一個 bolt 任務處理，所有的 tuple 將會發送給擁有最小 task_id 的 bolt任務處理，

3.4.5. None grouping ：不分組

不關注并行處理負載均衡策略時使用該方式，目前等同于 shuffle grouping,另外 storm 將會把bolt 任務和他的上游提供資料的任務安排在同一個執行緒下，

3.4.6. Direct grouping ：直接分組 指定分組

由 tuple 的發射單元直接決定 tuple 將發射給那個 bolt，一般情況下是由接收 tuple 的 bolt 決定接收哪個 bolt 發射的 Tuple，這是一種比較特別的分組方法，用這種分組意味著訊息的發送者指定由訊息接收者的哪個 task 處理這個訊息， 只有被宣告為 Direct Stream 的訊息流可以宣告這種分組方法，而且這種訊息 tuple 必須使用 emitDirect 方法來發射，訊息處理者可以通過TopologyContext 來獲取處理它的訊息的 taskid (OutputCollector.emit 方法也會回傳
taskid)，

四. YARN

需要這份java學習筆記資料的點這里-》》》》》》》

4.1. 概念

YARN 是一個資源管理、任務調度的框架，主要包含三大模塊：ResourceManager（RM）、NodeManager（NM）、ApplicationMaster（AM），其中，ResourceManager 負責所有資源的監控、分配和管理； ApplicationMaster 負責每一個具體應用程式的調度和協調；NodeManager 負責每一個節點的維護，對于所有的 applications，RM 擁有絕對的控制權和對資源的分配權，而每個 AM 則會和 RM 協商資源，同時和 NodeManager 通信來執行和監控 task，幾個模塊之間的關系如圖所示，

4.2. ResourceManager

1. ResourceManager 負責整個集群的資源管理和分配，是一個全域的資源管理系統，
2. NodeManager 以心跳的方式向 ResourceManager 匯報資源使用情況（目前主要是 CPU 和
   記憶體的使用情況），RM 只接受 NM 的資源回報資訊，對于具體的資源處理則交給 NM 自己
   處理，
3. YARN Scheduler 根據 application 的請求為其分配資源，不負責 application job 的監控、
   追蹤、運行狀態反饋、啟動等作業，

4.3. NodeManager

1. NodeManager 是每個節點上的資源和任務管理器，它是管理這臺機器的代理，負責該節點
   程式的運行，以及該節點資源的管理和監控，YARN集群每個節點都運行一個NodeManager，
2. NodeManager 定時向 ResourceManager 匯報本節點資源（CPU、記憶體）的使用情況和
   Container 的運行狀態，當 ResourceManager 宕機時 NodeManager 自動連接 RM 備用節
   點，
3. NodeManager 接收并處理來自 ApplicationMaster 的 Container 啟動、停止等各種請求，

4.4. ApplicationMaster

用戶提交的每個應用程式均包含一個 ApplicationMaster，它可以運行在 ResourceManager 以外的機器上，

1. 負責與 RM 調度器協商以獲取資源（用 Container 表示），
2. 將得到的任務進一步分配給內部的任務(資源的二次分配)，
3. 與 NM 通信以啟動/停止任務，
4. 監控所有任務運行狀態，并在任務運行失敗時重新為任務申請資源以重啟任務，
5. 當前 YARN 自帶了兩個 ApplicationMaster 實作，一個是用于演示 AM 撰寫方法的實體程式
   DistributedShell，它可以申請一定數目的 Container 以并行運行一個 Shell 命令或者 Shell
   腳本；另一個是運行 MapReduce 應用程式的 AM—MRAppMaster，
   注：RM 只負責監控 AM，并在 AM 運行失敗時候啟動它，RM 不負責 AM 內部任務的容錯，任務
   的容錯由 AM 完成，

4.5.YARN 運行流程

1. client 向 RM 提交應用程式，其中包括啟動該應用的 ApplicationMaster 的必須資訊，例如
   ApplicationMaster 程式、啟動 ApplicationMaster 的命令、用戶程式等，
2. ResourceManager 啟動一個 container 用于運行 ApplicationMaster，
3. 啟動中的ApplicationMaster向ResourceManager注冊自己，啟動成功后與RM保持心跳，
4. ApplicationMaster 向 ResourceManager 發送請求，申請相應數目的 container，
5. ResourceManager 回傳 ApplicationMaster 的申請的 containers 資訊，申請成功的
   container，由 ApplicationMaster 進行初始化，container 的啟動資訊初始化后，AM 與對
   應的 NodeManager 通信，要求 NM 啟動 container，AM 與 NM 保持心跳，從而對 NM 上
   運行的任務進行監控和管理，
6. container 運行期間，ApplicationMaster 對 container 進行監控，container 通過 RPC 協議
   向對應的 AM 匯報自己的進度和狀態等資訊，
7. 應用運行期間，client 直接與 AM 通信獲取應用的狀態、進度更新等資訊，
8. 應用運行結束后，ApplicationMaster 向 ResourceManager 注銷自己，并允許屬于它的
   container 被識訓
   
   需要這份java學習筆記資料的點這里-》》》》》》》