一文縱覽大資料計算生態
歡迎關注wx公眾號：DLab資料實驗室 關注更多知識乾貨～
概述
大資料計算髮展至今，已經形成了一個百花齊放的大資料生態，通用的、定製的，批量的、實時的，關係的、圖的、非結構的，資料計算的、機器學習的，我們都可以找到各種對應的計算引擎。
本文擬以大資料平臺從底到高的層次為主線，梳理整個大資料計算生態。
下面大資料計算生態的圖最上層為應用層，也就是實際與開發人員互動的層，例如分析人員通過在Hive中寫SQL就可以呼叫到中間層的MapReduce引擎來進行分析處理。Spark的GraphX、MLlib等元件可以用來進行圖分析和機器學習等。中間層的Spark、Flink等作為核心計算引擎提供批計算和流計算支援。左邊ZK和Oozie是任務配置協調，右邊的是日誌採集、遷移或者獲取資料相關的元件，再往下是最重要的資源排程管理系統，最底層是資料儲存，一個大資料平臺就要提供能進行多模型資料儲存的能力，比如除了最常見的關係資料，還有時序、文件、鍵值和圖等資料。
分析
大資料平臺按照整體架構從底向上可以分為：儲存層、快取層、計算層、元件層、工具層、排程協調層。大資料平臺的各層之間是向上賦能的。例如計算層依賴儲存層，元件應用層依賴於計算層。
下面針對每個不同的功能層中的每個元件進行介紹。這裡將會從概覽的角度來介紹每個引擎或者元件，後續會通過一系列的文章對每個引擎或者元件進行詳細的分析。
1.儲存層
儲存層負責進行大資料平臺的資料儲存。過去的幾十年，資料大部分以結構化的形式儲存在關係資料庫中，常見的如Oracle和MySQL兩種。隨著資料越來越多樣，出現了各種型別的資料庫，如圖資料庫、鍵值資料庫、時序資料庫、文件資料庫等，以及除了傳統的行存資料庫外，也出現了列存資料庫或者檔案格式。
1.1 HDFS：HDFS 是 Hadoop Distribute File System，Hadoop分散式檔案系統的簡稱。這個檔案系統是一個適用於大的資料集的支援高吞吐和高容錯的執行在通用（廉價）機上的分散式檔案系統。
HDFS 是一個主從架構的服務。一個 HDFS 叢集包括一個 NameNode 節點、一個 SecondaryNameNode 節點（非必須）和多個 DataNode 節點。
圖中的幾個要點：
- NameNode管理著Metadata（元資料）
- 客戶端client對元資料的操作是指向NameNode，對使用者資料的讀寫是通過DataNode
- NameNode向DataNode傳送Block的操作命令
- 一塊的副本被儲存在不同的機架中
1.2 關係資料儲存（行儲存)
傳統的資料庫例如MySQL,Oracle等關係資料庫，都採用的是行儲存引擎，在基於行式儲存的資料庫中， 資料是按照行資料為基礎邏輯儲存單元進行儲存的， 一行中的資料在儲存介質中以連續儲存形式存在。
1.3 列儲存
列式儲存(Column-based)是相對於行式儲存來說的，新興的 Hbase、HP Vertica、EMC Greenplum 等分散式資料庫均採用列式儲存。在基於列式儲存的資料庫中， 資料是按照列為基礎的邏輯儲存單元進行儲存的，一列中的資料在儲存介質中以連續儲存形式存在。
1.4 多模型儲存
隨著資料多樣性的發展，多種型別的資料大量湧出，相對應的NoSQL系統也出現了。例如Neo4j圖儲存，用來儲存社交網路、知識圖譜等圖資料；再入近兩年Iot智慧製造的興起，大量工業生產生活中的時序資料，也對應出現了InfluxDB這種儲存時序資料的系統；還有生產中常用的鍵值資料庫Redis等。
2. 快取層
快取其實已經不是什麼新概念了，無論是在作業系統還是傳統的資料管理系統，都有緩衝區或者快取的概念，主要是為了平衡CPU和磁碟之間的速度的差異，提高效率。在大資料的應用場景中，由於資料量比較大，資料的處理邏輯也比較複雜，因此一些中間過程結果可以複用的資料就可以通過分散式快取來進行臨時儲存，其他的任務就可以避免資料的二次加工從而提高效率。
2.1 Alluxio
Alluxio（之前名為Tachyon）是世界上第一個以記憶體為中心的虛擬的分散式儲存系統。它統一了資料訪問的方式，為上層計算框架和底層儲存系統構建了橋樑。 應用只需要連線Alluxio即可訪問儲存在底層任意儲存系統中的資料。此外，Alluxio的以記憶體為中心的架構使得資料的訪問速度能比現有方案快幾個數量級。
Alluxio的特點是資料儲存與計算分離，兩部分引擎可以進行獨立的擴充套件。上層的計算引擎(如Hadoop, Spark)可以通過Alluxio訪問不同資料來源(Amazon S3, HDFS)中的資料，通過Alluxio遮蔽底層不同的資料來源，做到資料的無感獲取。
3. 計算層（計算引擎）
有了資料之後，各個應用就可以利用這些資料進行不同維度或角度的分析，從而形成不同的資料價值產品。支撐這一過程的最重要的就是計算引擎。計算引擎為各個資料任務提供算力支援。
目前可以把計算引擎分為三類，批處理、流處理和即席（Ad-Hoc）查詢三類。
批處理指的是大規模複雜的資料處理過程，通常的時間跨度在幾分鐘到數小時甚至數日；流處理指的是實時的資料處理和查詢，通常的時間跨度在數百毫秒到數秒之間；即席（Ad-Hoc）查詢指的是介於實時和批處理之間的一種查詢處理，如一些互動式的資料探查任務，需要秒級或分鐘級的較快的響應時間。
3.1 批處理
3.1.1 MapReduce（Hadoop）
MapReduce就是指我們常說的Hadoop MapReduce，它是一個批處理計算引擎。每個MapReduce任務都包含兩個過程：Map過程和Reduce過程。
-
- MapReduce的計算模型：Map和Reduce兩個計算過程(中間用Shuffle串聯),MapReduce程式
- Map階段：多臺機器同時讀取一個檔案的各個部分，分別統計詞頻，產生多個Map集合
- Reduce階段：接收所對應的Map集合結果，將相同鍵的集合彙總，進而得到整個檔案的詞頻結果
- Map+Reduce過於笨重
- 第二代的Tez/Spark讓Map/Reduce模型更通用，讓Map和Reduce之間的界限更模糊，資料交換更靈活，更少的磁碟讀寫，以便更方便地描述複雜演算法，取得更高的吞吐量
3.1.2 Spark
與Hadoop MapReduce不同的是，Spark是基於記憶體的批處理計算引擎。SparkSpark及其元件已經形成了一個大資料生態，Spark基於這個引擎，提供了很多的高階應用模組解決不同場景中的業務需求。Spark分為Spark Core、SparkSQL、SparkStreaming、GraphX以及MLLib等，SparkCore為Spark的核心和基礎，提供基本的批處理功能，其他的每個元件專注於不同的處理任務。
Spark與Hadoop相比主要有且不限於以下幾個優勢：
減少磁碟I/O：Hadoop的的map和reduce過程每此處理都要涉及讀寫磁碟，map端的中間結果也要排序並寫入磁碟，reduce從磁碟中進行讀取；這樣整個處理過程中磁碟I/O就成了處理瓶頸；Spark允許將map端的中間結果放入記憶體，reduce直接從記憶體中拉取資料，避免了大量的磁碟I/O。
提高並行度：MapReduce的並行度是程序級別，Spark是執行緒級別。MapReduce需要進行磁碟的map寫入，reduce讀取，屬於序列執行；spark把不同環節抽象為stage，允許多個stage序列執行或並行執行。
避免重複計算：Spark中通過DAG（有向無環圖）來串起資料處理的各個Stage階段，如果某個階段發生故障或者資料丟失，可以利用血緣機制來回溯某個RDD，從而減少資料的重新計算，提高效率。
3.2 流處理
3.2.1 Flink
Flink是一個面向資料流處理和批量資料處理的可分散式的開源計算框架，它基於同一個Flink流式執行模型（streaming execution model），能夠支援流處理和批處理兩種應用型別。
它將資料流抽象為無界流和有界流。無界流是有開始但是沒有結束的資料流，有界流是有開始也有結束的資料流。
Flink元件棧
Deployment層： 該層主要涉及了Flink的部署模式，Flink支援多種部署模式：本地、叢集（Standalone/YARN），（GCE/EC2）。
Runtime層：Runtime層提供了支援Flink計算的全部核心實現，比如：支援分散式Stream處理、JobGraph到ExecutionGraph的對映、排程等等，為上層API層提供基礎服務。
API層： 主要實現了面向無界Stream的流處理和麵向Batch的批處理API，其中面向流處理對應DataStream API，面向批處理對應DataSet API。
Libraries層：該層也可以稱為Flink應用框架層，根據API層的劃分，在API層之上構建的滿足特定應用的實現計算框架，也分別對應於面向流處理和麵向批處理兩類。面向流處理支援：CEP（複雜事件處理）、基於SQL-like的操作（基於Table的關係操作）；面向批處理支援：FlinkML（機器學習庫）、Gelly（圖處理）
3.2.2 Storm
Storm是Twitter開源的分散式實時大資料處理框架，被業界稱為實時版Hadoop。
Apache Storm從一端讀取實時資料的原始流，並將其傳遞通過一系列小處理單元，並在另一端輸出處理/有用的資訊。
下圖描述了Apache Storm的核心概念。
但是隨著SparkStreaming混合Flink的興起，目前Storm的使用已經越來越少。
3.2.3 Spark（Streaming/Structured）
除此之外，在流處理上，還有Spark生態中的Spark streaming和structured streaming。
Spark Streaming：Spark Streaming是Spark最早推出的流處理元件，它基於流式批處理引擎，基本原理是把輸入資料以某一時間間隔批量的處理（微批次），當批處理時間間隔縮短到秒級時，便可以用於實時資料流。
程式設計模型：在sparkstreaming內部，將接收到資料流按照一定的時間間隔進行切分，然後交給spark引擎處理，最終得到一個個微批的處理結果。
資料抽象：離散資料流或者資料流是sparkStreaming提供的基本抽象。他可以是從資料來源不斷流入的，也可以是從一個數據流轉換而來的。本質上就是一系列的RDD。每個流中的RDD包含了一個特定時間間隔內的資料集合，如下圖所示。
Structured Streaming：毫秒級別的持續流式處理，Spark 2.0 引入了Structured Streaming， 將微批次處理從高階 API 中解耦出去。它簡化了 API 的使用，API 不再負責進行微批次處理；開發者可以將流看成是一個沒有邊界的表，並基於這些“表”執行查詢。Structured Streaming的預設引擎基於微批處理引擎，並且可以達到最低100ms的延遲和資料處理的exactly-once保證。
Spark 2.3 繼續向更快、更易用、更智慧的目標邁進，引入了低延遲的持續流處理模式，可以達到端到端最低1ms的延遲和資料處理的at-least-once的保證。
採用何種處理模式只需要進行簡單的模式配置即可。
程式設計模型：無界表，每個流的資料來源從邏輯上來說看做一個不斷增長的動態表（無界表），從資料來源不斷流入的每個資料項可以看作為新的一行資料追加到動態表中。使用者可以通過靜態結構化資料的批處理查詢方式（SQL查詢），對資料進行實時查詢。
3.3 即席查詢（Ad-Hoc)
3.3.1 Impala
Impala是用於處理儲存在Hadoop叢集中的大量資料的MPP（大規模並行處理）SQL查詢引擎。 它是一個用C ++和Java編寫的開源軟體。 與其他Hadoop的SQL引擎相比，它提供了高效能和低延遲。
換句話說，Impala是效能最高的SQL引擎（提供類似RDBMS的體驗），它提供了訪問儲存在Hadoop分散式檔案系統中的資料的最快方法。
與Hive依賴於MapReduce計算不同，Impala採用的是基於記憶體的計算，因此可以更快地完成計算任務。
3.3.2 Presto
Presto是一個facebook開源的分散式SQL查詢引擎，適用於互動式分析查詢，資料量支援GB到PB位元組。presto的架構由關係型資料庫的架構演化而來。presto之所以能在各個記憶體計算型資料庫中脫穎而出，在於以下幾點：
- 清晰的架構，是一個能夠獨立執行的系統，不依賴於任何其他外部系統。例如排程，presto自身提供了對叢集的監控，可以根據監控資訊完成排程。
- 簡單的資料結構，列式儲存，邏輯行，大部分資料都可以輕易的轉化成presto所需要的這種資料結構。
- 豐富的外掛介面，完美對接外部儲存系統，或者新增自定義的函式。
Presto採用典型的master-slave模型：
- coordinator(master)負責meta管理,worker管理，query的解析和排程
- worker則負責計算和讀寫。
- discovery server， 通常內嵌於coordinator節點中，也可以單獨部署，用於節點心跳。在下文中，預設discovery和coordinator共享一臺機器。
3.3.3 ClickHouse
ClickHouse是一個面向聯機分析處理(OLAP)的開源的面向列式儲存的DBMS，簡稱CK, 與Hadoop, Spark相比，ClickHouse很輕量級,由俄羅斯第一大搜索引擎Yandex於2016年6月釋出, 開發語言為C++
ClickHouse的特點:
開源的列儲存資料庫管理系統，支援線性擴充套件，簡單方便，高可靠性，
容錯跑分快：比Vertica快5倍，比Hive快279倍，比MySQL快800倍,其可處理的資料級別已達到10億級別
功能多：支援資料統計分析各種場景，支援類SQL查詢，異地複製部署
ClickHouse最近也是比較火，很多公司用它來進行即時查詢任務，如位元組、攜程等。
3.4 圖計算
Giraph和GraphLab都是用來進行圖資料處理的計算引擎，其中Giraph屬於同步計算模型，GraphLab為非同步計算模型。圖計算主要將客觀世界中事物間關係完整地刻畫、計算和分析的一門技術。它可以用於銀行對於不良貸款的預測，也可以用於網站大資料分析推薦等功能。圖演算法有很多種，每一種演算法都有其實際的應用場景。常見的圖演算法有PageRank、最短路徑、社群發現等演算法。
4. 元件層（互動元件）
上面介紹的主要是可以獨立進行計算的計算引擎，但是這些計算引擎對於一般水平的開發人員來講還是比較複雜的，例如你可能只是想進行一些簡單的SQL資料探查，就需要編寫一整套的MapReduce程式碼，這就造成了這些計算引擎的使用門檻過高。
為了提高對資料分析人員的友好，一系列的上層元件也應運而生。例如Hive、Pig等，提供了將SQL或者指令碼轉換成MapReduce任務的功能，這樣資料分析人員只需要關注業務SQL或者指令碼的開發即可，而不用關係MapReduce的任務該如何寫。
4.1 批處理
4.1.1 Hive
HIVE是由facebook開源，最初用於解決海量結構化的日誌資料統計問題。Hive更多的是與資料倉庫的概念結合在一起。各個公司的資料倉庫可能都離不開Hive。主要是因為Hive定義了一種類似SQL的查詢語言(HQL),將SQL轉化為MapReduce任務在Hadoop上執行。
HQL用於執行儲存在Hadoop上的查詢語句，Hive讓不熟悉MapReduce開發人員也能編寫資料查詢語句，然後這些語句被翻譯為Hadoop上面的MapReduce任務。
4.1.2 Pig
由yahoo!開源，設計動機是提供一種基於MapReduce的ad-hoc(計算在query時發生)資料分析工具。其實Pig跟Hive類似，它是定義了一種資料流指令碼語言(Pig Latin)，其編譯器將Pig Latin翻譯成MapReduce程式序列將指令碼轉換為MapReduce任務在Hadoop上執行。通常用於進行離線分析。
4.1.3 Tez
MapReduce(下面簡稱MR)的缺點很明顯，效能比較弱，效率不高。 原因在於它只能把Job抽象成為Map, Reduce，但是複雜的任務可以有幾十個MR任務，中間可能會有很多重複的任務。 而且MR並不支援對於整個pipeline的任務進行優化。比如說若干個MR任務的組合可以合併成一個來計算，這樣就減少了資料的讀寫，傳輸的開銷。歸根結底，是因為Hadoop不支援任務的DAG(有向無環圖)描述。
Tez提供了一個可重用，靈活的框架來支援資料流模型。他的主要特點是：
- 使用者可以將自己的Job描述成一個DAG，這樣可以進行更靈活的優化和配置。
- 提供了靈活的Runtime API。Tez支援在Runtime對DAG的配置進行修改，比如對於partitition的調整。
- 提供了data-locality感知， 資源重用和錯誤容忍。
上面這個圖就很好詮釋了Tez的功能。它其實與Spark有點類似，說白了就是減少不同作業之間的資料讀寫磁碟的次數。
舉個栗子看優勢，如圖，Tez可以將多個有依賴的作業轉換為一個作業（這樣只需寫一次HDFS，且中間節點較少），從而大大提升DAG作業的效能。Tez已被Hortonworks用於Hive引擎的優化，經測試，效能提升約100倍。
SparkSQL
由於SQL的易學易用的特點，為了擴大Spark的應用範圍，增加了對SQL和Hive的支援。
SparkSQL的處理流程如下圖所示。
SparkSQL在1.x版本是通過SQLContext、HiveContext來獲取程式設計入口，在2.X版本通過SparkSession獲取程式設計入口，通過SparkSession.sql()簡單易用。
連線方式：Spark連線hive表的兩種策略，JDBC的方式和Spark直連的方式
4.1.4 Kudu
在 KUDU 之前，大資料主要以兩種方式儲存：
- 靜態資料：以 HDFS 引擎作為儲存引擎，適用於高吞吐量的離線大資料分析場景。這類儲存的侷限性是資料無法進行隨機的讀寫。
- 動態資料：以 HBase、Cassandra 作為儲存引擎，適用於大資料隨機讀寫場景。這類儲存的侷限性是批量讀取吞吐量遠不如 HDFS，不適用於批量資料分析的場景。
從上面分析可知，這兩種資料在儲存方式上完全不同，進而導致使用場景完全不同，但在真實的場景中，邊界可能沒有那麼清晰，面對既需要隨機讀寫，又需要批量分析的大資料場景。
通常的做法是，資料實時寫入 HBase，實時的資料更新也在 HBase 完成，為了應對 OLAP 需求，定時（通常是 T+1 或者 T+H）將 HBase 資料寫成靜態的檔案（如：Parquet）匯入到 OLAP 引擎（如：HDFS）。這一架構能滿足既需要隨機讀寫，又可以支援 OLAP 分析的場景，但他有如下缺點：
- 架構複雜。從架構上看，資料在 HBase、訊息佇列、HDFS 間流轉，涉及環節太多，運維成本很高。並且每個環節需要保證高可用，都需要維護多個副本，儲存空間也有一定的浪費。最後資料在多個系統上，對資料安全策略、監控等都提出了挑戰。
- 時效性低。資料從 HBase 匯出成靜態檔案是週期性的，一般這個週期是一天（或一小時），在時效性上不是很高。
- 難以應對後續的更新。真實場景中，總會有資料是「延遲」到達的。如果這些資料之前已經從 HBase 匯出到 HDFS，新到的變更資料就難以處理了，一個方案是把原有資料應用上新的變更後重寫一遍，但這代價又很高。
為了解決上述架構的這些問題，KUDU 應運而生。KUDU 的定位是 「Fast Analytics on Fast Data」，是一個既支援隨機讀寫、又支援 OLAP 分析的大資料儲存引擎。
從上圖可以看出，KUDU 是一個「折中」的產品，在 HDFS 和 HBase 這兩個偏科生中平衡了隨機讀寫和批量分析的效能。從 KUDU 的誕生可以說明一個觀點：底層的技術發展很多時候都是上層的業務推動的，脫離業務的技術很可能是「空中樓閣」。
4.2 流處理
SparkStreaming、Structured Streaming以及Flink和Storm已經在上面介紹過。
4.3 即席查詢
4.3.1 ElasticSearch
Elasticsearch是一個開源的分散式、RESTful 風格的搜尋和資料分析引擎，它的底層是開源庫Apache Lucene。Elasticsearch主要是為了解決Lucene使用時的繁複性。它使用 Java 編寫，內部採用 Lucene 做索引與搜尋，但是它的目標是使全文檢索變得更簡單，簡單來說，就是對Lucene 做了一層封裝，它提供了一套簡單一致的 RESTful API 來幫助我們實現儲存和檢索。 當然，Elasticsearch 不僅僅是 Lucene，並且也不僅僅只是一個全文搜尋引擎。 它可以包含下面的一些內容：
- 一個分散式的實時文件儲存，每個欄位可以被索引與搜尋；
- 一個分散式實時分析搜尋引擎；
- 能勝任上百個服務節點的擴充套件，並支援 PB 級別的結構化或者非結構化資料。
由於Elasticsearch的功能強大和使用簡單，維基百科、衛報、Stack Overflow、GitHub等都紛紛採用它來做搜尋。現在，Elasticsearch已成為全文搜尋領域的主流軟體之一。
4.4 人工智慧
4.4.1 SparkMLlib
MLlib支援包括分類、迴歸、聚類和協同過濾在內的四種常見機器學習演算法，MLlib基於RDD，與SparkSQL、Spark Streaming、GraphX無縫整合，共同組成了Spark大資料生態。
4.4.2 Mahout
Apache Mahout 是 Apache Software Foundation（ASF）旗下的一個開源專案，提供一些可擴充套件的機器學習領域經典演算法的實現，旨在幫助開發人員更加方便快捷地建立智慧應用程式。Mahout專案目前已經有了多個公共發行版本。Mahout包含許多實現，包括聚類、分類、推薦過濾、頻繁子項挖掘。通過使用 Apache Hadoop 庫，Mahout 可以有效地擴充套件到Hadoop叢集。
4.4.3 TensorFlow
TensorFlow 是一個用於數值計算的Python 庫， 可以描述一幅資料計算的資料流圖（data flow graph）。TensorFlow 最初由Google大腦小組（隸屬於Google機器智慧研究機構）的研究員和工程師們開發出來，用於機器學習和深度神經網路方面的研究，但這個系統的通用性使其也可廣泛用於其他計算領域。
會話(Session)：TensorFlow描述的計算流程圖需要在Session中啟動；Session將其與C++後端連線，為其分配計算裝置（CPU 或 GPU）和提供計算方法，反覆訓練模型。
節點（Nodes）：在圖中表示數學操作，例如，資料輸入（feed in）的起點或輸出（push out）的終點；
線（edges）：線輸送節點間相互聯絡和不斷變化的多維資料陣列(即張量, tensor）。
5.工具層
除了以上的核心元件，還有一些必要的工具類元件，例如日誌採集工具，不同資料來源之間的資料傳輸工具等，這些是我們進行資料輸入或輸出過程中必不可少的。
5.1 Sqoop
傳統的應用程式管理系統，即應用程式與使用RDBMS的關係資料庫的互動，是產生大資料的來源之一。由RDBMS生成的這種大資料儲存在關係資料庫結構中的關係資料庫伺服器中。
Sqoop是一個用於在Hadoop和關係資料庫伺服器之間傳輸資料的工具。它用於從關係資料庫（如MySQL，Oracle）匯入資料到Hadoop HDFS，並從Hadoop檔案系統匯出到關係資料庫。它由Apache軟體基金會提供。
下圖描述了Sqoop的工作流程。
Sqoop匯入:匯入工具從RDBMS向HDFS匯入單獨的表。表中的每一行都被視為HDFS中的記錄。所有記錄都以文字檔案的形式儲存在文字檔案中或作為Avro和Sequence檔案中的二進位制資料儲存。
Sqoop匯出:匯出工具將一組檔案從HDFS匯出回RDBMS。給Sqoop輸入的檔案包含記錄，這些記錄在表中被稱為行。這些被讀取並解析成一組記錄並用使用者指定的分隔符分隔。
5.2 Flume
Flume是一個分散式的、高可靠的、高可用的將大批量的不同資料來源的日誌資料收集、聚合、移動到資料中心（HDFS）進行儲存的系統。即是日誌採集和彙總的工具
flume的優勢：
- 可以高速採集資料，採集的資料能夠以想要的檔案格式及壓縮方式儲存在hdfs上
- 事務功能保證了資料在採集的過程中資料不丟失
- 部分Source保證了Flume掛了以後重啟依舊能夠繼續在上一次採集點採集資料，真正做到資料零丟失
flume有3大元件
- source(源端資料採集)：Flume提供了各種各樣的Source、同時還提供了自定義的Source
- Channel(臨時儲存聚合資料)：主要用的是memory channel和File channel（生產最常用），生產中channel的資料一定是要監控的，防止sink掛了，撐爆channel
- Sink（移動資料到目標端）：如HDFS、KAFKA、DB以及自定義的sink
5.3 Kafka
Kafka是Apache旗下的一款分散式流媒體平臺，Kafka是一種高吞吐量、永續性、分散式的釋出訂閱的訊息佇列系統。 它最初由LinkedIn(領英)公司釋出，使用Scala語言編寫，與2010年12月份開源，成為Apache的頂級子專案。 它主要用於處理消費者規模網站中的所有動作流資料。動作指(網頁瀏覽、搜尋和其它使用者行動所產生的資料)。
6. 協調排程層
一個大資料平臺，它的元件是數量多、型別繁的，那如何協調不同計算引擎之間對資源的申請、使用和釋放，就需要統一的資源管理器；同時，大資料平臺的任務之間並不是獨立存在的，很多工存在上下游的關係，例如一個任務的輸入可能依賴於前一個或者多個任務的輸出，這就需要我們協調好各個任務之間的依賴關係，確定好任務啟動的時間和順序；再者，在分散式的架構中，不同節點之間的資料協調、節點間的角色劃分、HA等也都需要一些協調器來協助。
6.1 Zookeeper
zookeeper功能非常強大，可以實現諸如分散式應用配置管理、統一命名服務、狀態同步服務、叢集管理等功能，我們這裡拿比較簡單的分散式應用配置管理為例來說明。
假設我們的程式是分散式部署在多臺機器上，如果我們要改變程式的配置檔案，需要逐臺機器去修改，非常麻煩，現在把這些配置全部放到zookeeper上去，儲存在 zookeeper 的某個目錄節點中，然後所有相關應用程式對這個目錄節點進行監聽，一旦配置資訊發生變化，每個應用程式就會收到 zookeeper 的通知，然後從 zookeeper 獲取新的配置資訊應用到系統中。
6.2 Oozie
設想一下，當你的系統引入了spark或者hadoop以後，基於Spark和Hadoop已經做了一些任務，比如一連串的Map Reduce任務，但是他們之間彼此右前後依賴的順序，因此你必須要等一個任務執行成功後，再手動執行第二個任務。 這個時候Oozie就可以把多個任務組成一個工作流，自動完成任務的呼叫。
總結來說
- Oozie是管理Hadoop作業的工作流排程系統
- Oozie的工作流是一系列的操作圖
- Oozie協調作業是通過時間（頻率）以及有效資料觸發當前的Oozie工作流程
- Oozie是針對Hadoop開發的開源工作流引擎，專門針對大規模複雜工作流程和資料管道設計
- Oozie圍繞兩個核心：工作流和協調器，前者定義任務的拓撲和執行邏輯，後者負責工作流的依賴和觸發。
6.3 Yarn
YARN 是一個資源管理、任務排程的框架，主要包含三大模組：ResourceManager（RM）、 NodeManager（NM）、ApplicationMaster（AM）。
ResourceManager 負責所有資源的監控、分配和管理；
ApplicationMaster 負責每一個具體應用程式的排程和協調；
NodeManager 負責每一個節點的維護。 對於所有的 applications，RM 擁有絕對的控制權和對資源的分配權。而每個 AM 則會和 RM 協商資源，同時和 NodeManager 通訊來執行和監控 task。
總結
講了這麼多的大資料元件，其實，大資料計算生態中的元件遠不止這些，這只是我們在各個領域常用的元件，隨著資料多樣性和場景多樣性的增加，大資料生態中的元件也會繼續增加，但是原理其實都是大同小異。我們需要不斷的去學習。
本文主要從總體上來介紹了大資料生態中的各個元件及其功能，後面我會將每個元件用一整篇文章來進行詳細介紹，也歡迎大家關注我的微信公眾號【DLab資料實驗室】來一起學習大資料的知識～