- 大數(shù)據(jù)技術(shù)框架
- 1. 簡介
- 2. Hadoop框架
- 3. 分布式協(xié)調(diào)****zookeeper
- 4. 數(shù)據(jù)存儲(chǔ)HBASE
- 5. 數(shù)據(jù)倉庫hive
- 6. 數(shù)據(jù)處理
- 7. 消息系統(tǒng)kafka
- 8. 數(shù)據(jù)采集
大數(shù)據(jù)技術(shù)框架
1. 簡介
大數(shù)據(jù)技術(shù)體系主要涉及方面：數(shù)據(jù)采集，數(shù)據(jù)處理，數(shù)據(jù)存儲(chǔ)以及分布式協(xié)調(diào)服務(wù)巧颈；
數(shù)據(jù)采集：etl症昏，kettle省艳，flume
數(shù)據(jù)處理：離線處理hadoop郭膛，實(shí)時(shí)處理spark、storm派昧、flink
數(shù)據(jù)存儲(chǔ)：HBASE、hdfs拢切。
數(shù)據(jù)倉庫蒂萎；hive
分布式協(xié)調(diào)服務(wù)：zookeeper
2. Hadoop框架
Hadoop是Apache軟件基金會(huì)所開發(fā)的并行計(jì)算框架與分布式文件系統(tǒng)。最核心的模塊包括Hadoop Common淮椰、HDFS與MapReduce五慈。
2.1. Hadoop-MapReduce
2.1.1. 簡介：
MapReduce是由Google在一篇論文中提出并廣為流傳的。它最早是Google提出的一個(gè)軟件架構(gòu)主穗，用于大規(guī)模數(shù)據(jù)集群分布式運(yùn)算泻拦。任務(wù)的分解（Map）與結(jié)果的匯總（Reduce）是其主要思想。Map就是將一個(gè)任務(wù)分解成多個(gè)任務(wù)忽媒，Reduce就是將分解后多任務(wù)分別處理争拐，并將結(jié)果匯總為最終結(jié)果。
MapReduce 編程模型：
MapReduce將整個(gè)并行計(jì)算過程抽象到兩個(gè)函數(shù)：
map（映射）：對一些獨(dú)立元素組成的列表的每一個(gè)元素進(jìn)行指定的操作晦雨，可以高度并行
Reduce（化簡）：隊(duì)一個(gè)列表的元素進(jìn)行合并
一個(gè)簡單的MapReduce程序只需要指定map()架曹、reduce()灯抛、input和output，剩下的事由框架來執(zhí)行音瓷。
2.1.2. 特點(diǎn)
高容錯(cuò)
高擴(kuò)展
編程簡單
適合大數(shù)據(jù)離線批量處理
2.1.3. 架構(gòu)
它主要有以下4個(gè)部分組成：
1）Client
2）JobTracker
JobTracke負(fù)責(zé)資源監(jiān)控和作業(yè)調(diào)度对嚼。JobTracker 監(jiān)控所有TaskTracker 與job的健康狀況，一旦發(fā)現(xiàn)失敗绳慎，就將相應(yīng)的任務(wù)轉(zhuǎn)移到其他節(jié)點(diǎn)纵竖；同時(shí)，JobTracker 會(huì)跟蹤任務(wù)的執(zhí)行進(jìn)度杏愤、資源使用量等信息靡砌，并將這些信息告訴任務(wù)調(diào)度器，而調(diào)度器會(huì)在資源出現(xiàn)空閑時(shí)珊楼，選擇合適的任務(wù)使用這些資源通殃。在Hadoop 中，任務(wù)調(diào)度器是一個(gè)可插拔的模塊厕宗，用戶可以根據(jù)自己的需要設(shè)計(jì)相應(yīng)的調(diào)度器画舌。
3）TaskTracker
TaskTracker 會(huì)周期性地通過Heartbeat 將本節(jié)點(diǎn)上資源的使用情況和任務(wù)的運(yùn)行進(jìn)度匯報(bào)給JobTracker，同時(shí)接收J(rèn)obTracker 發(fā)送過來的命令并執(zhí)行相應(yīng)的操作（如啟動(dòng)新任務(wù)已慢、殺死任務(wù)等）曲聂。TaskTracker 使用“slot”等量劃分本節(jié)點(diǎn)上的資源量∮踊荩“slot”代表計(jì)算資源（CPU朋腋、內(nèi)存等）。一個(gè)Task 獲取到一個(gè)slot 后才有機(jī)會(huì)運(yùn)行膜楷，而Hadoop 調(diào)度器的作用就是將各個(gè)TaskTracker 上的空閑slot 分配給Task 使用旭咽。slot 分為Map slot 和Reduce slot 兩種，分別供MapTask 和Reduce Task 使用赌厅。TaskTracker 通過slot 數(shù)目（可配置參數(shù)）限定Task 的并發(fā)度穷绵。
4）Task
Task 分為Map Task 和Reduce Task 兩種，均由TaskTracker 啟動(dòng)察蹲。HDFS 以固定大小的block 為基本單位存儲(chǔ)數(shù)據(jù)请垛，而對于MapReduce 而言，其處理單位是split洽议。split 是一個(gè)邏輯概念宗收，它只包含一些元數(shù)據(jù)信息，比如數(shù)據(jù)起始位置亚兄、數(shù)據(jù)長度混稽、數(shù)據(jù)所在節(jié)點(diǎn)等。它的劃分方法完全由用戶自己決定。但需要注意的是匈勋，split 的多少?zèng)Q定了Map Task 的數(shù)目礼旅，因?yàn)槊總€(gè)split 只會(huì)交給一個(gè)Map Task 處理。
2.1.4. 執(zhí)行流程：
Map Task 執(zhí)行過程如下圖 所示洽洁。由該圖可知痘系，Map Task 先將對應(yīng)的split 迭代解析成一個(gè)個(gè)key/value 對，依次調(diào)用用戶自定義的map() 函數(shù)進(jìn)行處理饿自，最終將臨時(shí)結(jié)果存放到本地磁盤上汰翠，其中臨時(shí)數(shù)據(jù)被分成若干個(gè)partition，每個(gè)partition 將被一個(gè)Reduce Task 處理昭雌。
Reduce Task 執(zhí)行過程下圖所示复唤。該過程分為三個(gè)階段：
①從遠(yuǎn)程節(jié)點(diǎn)上讀取MapTask 中間結(jié)果（稱為“Shuffle 階段”）；
②按照key 對key/value 對進(jìn)行排序（稱為“Sort 階段”）烛卧；
③依次讀取<key, value list>佛纫，調(diào)用用戶自定義的reduce() 函數(shù)處理，并將最終結(jié)果存到HDFS 上（稱為“Reduce 階段”）总放。
2.1.5. Wordcount例子
2.1.6. 缺點(diǎn)：
1.JobTracker是MapReduce的集中處理點(diǎn)呈宇，存在單點(diǎn)故障。
2.JobTracker完成了太多的任務(wù)间聊，造成了過多的資源消耗攒盈，當(dāng)MapReduce Job非常多的時(shí)候抵拘，會(huì)造成很大的內(nèi)存開銷哎榴，潛在來說，也增加了JobTracker fail的風(fēng)險(xiǎn)僵蛛。
3.在TaskTracker端尚蝌，以MapReduce task的數(shù)目作為資源的表示過于簡單，沒有考慮到CPU內(nèi)存的占用情況充尉，如果兩個(gè)大內(nèi)存消耗的task被調(diào)度到了一塊飘言，很容易出現(xiàn)OOM。
4.在TaskTracker端驼侠，把資源強(qiáng)制劃分為Map task slot和reduce task slot姿鸿，如果當(dāng)系統(tǒng)中只有map task或者只有reduce task的時(shí)候，會(huì)造成資源的浪費(fèi)倒源。
2.2. Yarn
2.2.1. 簡介
MapReduce的JobTracker和TaskTracker機(jī)制需要大規(guī)模的調(diào)整來修復(fù)它在可擴(kuò)展性苛预，內(nèi)存消耗，線程模型笋熬，可靠性和性能上的缺陷热某。
為從根本上解決舊MapReduce框架的性能瓶頸，促進(jìn)Hadoop框架更長遠(yuǎn)發(fā)展，從0.23.0版本開始昔馋，Hadoop的MapReduce框架完全重構(gòu)筹吐，發(fā)生了根本的變化。新的Hadoop MapReduce框架命名為MapReduceV2或者叫Yarn秘遏。
Yarn中我們把job的概念換成了application丘薛，因?yàn)樵谛碌腍adoop2.x中，運(yùn)行的應(yīng)用不只是MapReduce了邦危，還有可能是其它應(yīng)用如一個(gè)DAG（有向無環(huán)圖Directed Acyclic Graph榔袋，例如storm應(yīng)用）。Yarn的另一個(gè)目標(biāo)就是拓展Hadoop铡俐，使得它不僅僅可以支持MapReduce計(jì)算凰兑，還能很方便的管理諸如Hive、Hbase审丘、Pig吏够、Spark/Shark等應(yīng)用。這種新的架構(gòu)設(shè)計(jì)能夠使得各種類型的應(yīng)用運(yùn)行在Hadoop上面滩报，并通過Yarn從系統(tǒng)層面進(jìn)行統(tǒng)一的管理锅知，也就是說，有了Yarn脓钾，各種應(yīng)用就可以互不干擾的運(yùn)行在同一個(gè)Hadoop系統(tǒng)中售睹，共享整個(gè)集群資源
2.2.2. 架構(gòu)
從上面的結(jié)構(gòu)圖來看，YARN主要的組件包括ResourceManager可训、NodeManager昌妹、ApplicationMaster和Container。
（1）Client向ResourceManager發(fā)送請求 （2）ResourceManager指定一個(gè)NodeManager啟動(dòng)起ApplicationMaster （3）ApplicationMaster將計(jì)算任務(wù)反饋給ResourceManager （4）ApplicationMaster將任務(wù)分割分發(fā)到不同的NodeManager （5）NodeManager啟動(dòng)Task執(zhí)行work
YARN Client
YARN Client提交Application到RM握截，它會(huì)首先創(chuàng)建一個(gè)Application上下文件對象飞崖，并設(shè)置AM必需的資源請求信息，然后提交到RM谨胞。YARN Client也可以與RM通信固歪，獲取到一個(gè)已經(jīng)提交并運(yùn)行的Application的狀態(tài)信息等，具體詳見后面ApplicationClientProtocol協(xié)議的分析說明胯努。
ResourceManager（RM）
RM是YARN集群的Master牢裳，負(fù)責(zé)管理整個(gè)集群的資源和資源分配。RM作為集群資源的管理和調(diào)度的角色叶沛，如果存在單點(diǎn)故障蒲讯，則整個(gè)集群的資源都無法使用。在2.4.0版本才新增了RM HA的特性恬汁，這樣就增加了RM的可用性伶椿。
NodeManager（NM）
NM是YARN集群的Slave辜伟，是集群中實(shí)際擁有實(shí)際資源的工作節(jié)點(diǎn)。我們提交Job以后脊另，會(huì)將組成Job的多個(gè)Task調(diào)度到對應(yīng)的NM上進(jìn)行執(zhí)行导狡。Hadoop集群中，為了獲得分布式計(jì)算中的Locality特性偎痛，會(huì)將DN和NM在同一個(gè)節(jié)點(diǎn)上運(yùn)行旱捧，這樣對應(yīng)的HDFS上的Block可能就在本地，而無需在網(wǎng)絡(luò)間進(jìn)行數(shù)據(jù)的傳輸踩麦。
Container
Container是YARN集群中資源的抽象枚赡，將NM上的資源進(jìn)行量化，根據(jù)需要組裝成一個(gè)個(gè)Container谓谦，然后服務(wù)于已授權(quán)資源的計(jì)算任務(wù)贫橙。計(jì)算任務(wù)在完成計(jì)算后，系統(tǒng)會(huì)回收資源反粥，以供后續(xù)計(jì)算任務(wù)申請使用卢肃。Container包含兩種資源：內(nèi)存和CPU，后續(xù)Hadoop版本可能會(huì)增加硬盤才顿、網(wǎng)絡(luò)等資源莫湘。
ApplicationMaster（AM）
AM主要管理和監(jiān)控部署在YARN集群上的Application，以MapReduce為例郑气，MapReduce Application是一個(gè)用來處理MapReduce計(jì)算的服務(wù)框架程序幅垮，為用戶編寫的MapReduce程序提供運(yùn)行時(shí)支持。通常我們在編寫的一個(gè)MapReduce程序可能包含多個(gè)Map Task或Reduce Task尾组，而各個(gè)Task的運(yùn)行管理與監(jiān)控都是由這個(gè)MapReduce Application來負(fù)責(zé)忙芒，比如運(yùn)行Task的資源申請，由AM向RM申請演怎；啟動(dòng)/停止NM上某Task的對應(yīng)的Container匕争，由AM向NM請求來完成。
2.2.3. 工作流程
客戶端向ResourceManager提交應(yīng)用程序爷耀，其中包括ApplicationMaster、啟動(dòng)ApplicationMaster的命令拍皮、用戶程序等歹叮；
ResourceManager為該應(yīng)用程序分配第一個(gè)Container，并與對應(yīng)NodeManager通信铆帽，要求它在這個(gè)Container中啟動(dòng)應(yīng)用程序的ApplicationMaster咆耿；
ApplicationMaster向ResourceManager注冊自己，啟動(dòng)成功后與ResourceManager保持心跳爹橱；
ApplicationMaster向ResourceManager申請資源萨螺；
申請資源成功后，由ApplicationMaster進(jìn)行初始化，然后與NodeManager通信慰技，要求NodeManager啟動(dòng)Container椭盏。然后ApplicationMaster與NodeManager保持心跳，從而對NodeManager上運(yùn)行的任務(wù)進(jìn)行監(jiān)控和管理吻商；
Container運(yùn)行期間掏颊，向ApplicationMaster匯報(bào)自己的進(jìn)度和狀態(tài)信息，以便ApplicationMaster掌握任務(wù)運(yùn)行狀態(tài)艾帐，從而在任務(wù)失敗是可以重新啟動(dòng)乌叶；
應(yīng)用運(yùn)行結(jié)束后，ApplicationMaster向ResourceManager注銷自己柒爸，允許其所屬的Container回收准浴。
2.2.4. 設(shè)計(jì)目標(biāo)
Yarn是通用的統(tǒng)一資源管理系統(tǒng)，同時(shí)運(yùn)行長應(yīng)用程序和短應(yīng)用程序捎稚。長應(yīng)用程序通常情況下兄裂，指永不停止運(yùn)行的程序service,http server等，短應(yīng)用程序指短時(shí)間（秒級(jí)阳藻，分鐘級(jí)晰奖，小時(shí)級(jí)）內(nèi)會(huì)運(yùn)行結(jié)束的程序MR job,Spark Job等。 以Yarn為核心的生態(tài)系統(tǒng)也越來越多了：
2.3. Hadoop-hdfs
2.3.1. 簡介：
HDFS即Hadoop Distributed File System分布式文件系統(tǒng)腥泥，它的設(shè)計(jì)目標(biāo)是把超大數(shù)據(jù)集存儲(chǔ)到分布在網(wǎng)絡(luò)中的多臺(tái)普通商用計(jì)算機(jī)上匾南，并且能夠提供高可靠性和高吞吐量的服務(wù)。分布式文件系統(tǒng)要比普通磁盤文件系統(tǒng)復(fù)雜蛔外，因?yàn)樗刖W(wǎng)絡(luò)編程蛆楞，分布式文件系統(tǒng)要容忍節(jié)點(diǎn)故障也是一個(gè)很大的挑戰(zhàn)。
2.3.2. 設(shè)計(jì)目標(biāo)
專為存儲(chǔ)超大文件而設(shè)計(jì)：hdfs應(yīng)該能夠支持GB級(jí)別大小的文件夹厌；它應(yīng)該能夠提供很大的數(shù)據(jù)帶寬并且能夠在集群中拓展到成百上千個(gè)節(jié)點(diǎn)豹爹；它的一個(gè)實(shí)例應(yīng)該能夠支持千萬數(shù)量級(jí)別的文件。
適用于流式的數(shù)據(jù)訪問：hdfs適用于批處理的情況而不是交互式處理矛纹；它的重點(diǎn)是保證高吞吐量而不是低延遲的用戶響應(yīng)
容錯(cuò)性：完善的冗余備份機(jī)制
支持簡單的一致性模型：HDFS需要支持一次寫入多次讀取的模型臂聋，而且寫入過程文件不會(huì)經(jīng)常變化
移動(dòng)計(jì)算優(yōu)于移動(dòng)數(shù)據(jù)：HDFS提供了使應(yīng)用計(jì)算移動(dòng)到離它最近數(shù)據(jù)位置的接口
兼容各種硬件和軟件平臺(tái)
2.3.3. 不使用場景
大量小文件：文件的元數(shù)據(jù)都存儲(chǔ)在NameNode內(nèi)存中，大量小文件會(huì)占用大量內(nèi)存或南。
低延遲數(shù)據(jù)訪問：hdfs是專門針對高數(shù)據(jù)吞吐量而設(shè)計(jì)的
多用戶寫入孩等，任意修改文件
2.3.4. 架構(gòu)設(shè)計(jì)
HDFS中關(guān)鍵組件有兩個(gè)，一個(gè)是NameNode采够，一個(gè)是DataNode肄方。
NameNode負(fù)責(zé)整個(gè)分布式文件系統(tǒng)的元數(shù)據(jù)（MetaData）管理，也就是文件路徑名蹬癌，數(shù)據(jù)block的ID以及存儲(chǔ)位置等信息权她，承擔(dān)著操作系統(tǒng)中文件分配表（FAT）的角色虹茶。HDFS為了保證數(shù)據(jù)的高可用，會(huì)將一個(gè)block復(fù)制為多份（缺省情況為3份）隅要，并將三份相同的block存儲(chǔ)在不同的服務(wù)器上蝴罪。這樣當(dāng)有磁盤損壞或者某個(gè)DataNode服務(wù)器宕機(jī)導(dǎo)致其存儲(chǔ)的block不能訪問的時(shí)候，Client會(huì)查找其備份的block進(jìn)行訪問拾徙。
DataNode負(fù)責(zé)文件數(shù)據(jù)的存儲(chǔ)和讀寫操作洲炊，HDFS將文件數(shù)據(jù)分割成若干塊（block），每個(gè)DataNode存儲(chǔ)一部分block尼啡，這樣文件就分布存儲(chǔ)在整個(gè)HDFS服務(wù)器集群中暂衡。應(yīng)用程序客戶端（Client）可以并行對這些數(shù)據(jù)塊進(jìn)行訪問，從而使得HDFS可以在服務(wù)器集群規(guī)模上實(shí)現(xiàn)數(shù)據(jù)并行訪問崖瞭，極大地提高訪問速度狂巢。實(shí)踐中HDFS集群的DataNode服務(wù)器會(huì)有很多臺(tái)，一般在幾百臺(tái)到幾千臺(tái)這樣的規(guī)模书聚，每臺(tái)服務(wù)器配有數(shù)塊磁盤唧领，整個(gè)集群的存儲(chǔ)容量大概在幾PB到數(shù)百PB。
2.3.5. Api
命令：
查看目錄結(jié)構(gòu)及信息：
Web頁面展示
3. 分布式協(xié)調(diào)****zookeeper
3.1. 簡介
zookeeper它是一個(gè)針對大型應(yīng)用提供高可用的數(shù)據(jù)管理雌续、應(yīng)用程序協(xié)調(diào)服務(wù)的分布式服務(wù)框架斩个，基于對Paxos算法的實(shí)現(xiàn)，使該框架保證了分布式環(huán)境中數(shù)據(jù)的強(qiáng)一致性驯杜，提供的功能包括：配置維護(hù)受啥、統(tǒng)一命名服務(wù)、狀態(tài)同步服務(wù)鸽心、集群管理等滚局。
在分布式應(yīng)用中，由于工程師不能很好地使用鎖機(jī)制顽频，以及基于消息的協(xié)調(diào)機(jī)制不適合在某些應(yīng)用中使用藤肢，因此需要有一種可靠的、可擴(kuò)展的糯景、分布式的嘁圈、可配置的協(xié)調(diào)機(jī)制來統(tǒng)一系統(tǒng)的狀態(tài)。Zookeeper的目的就在于此莺奸。
3.2. 特性
1 最終一致性：為客戶端展示同一視圖丑孩，這是zookeeper最重要的功能。 2 可靠性：如果消息被到一臺(tái)服務(wù)器接受灭贷，那么它將被所有的服務(wù)器接受。 3 實(shí)時(shí)性：Zookeeper不能保證兩個(gè)客戶端能同時(shí)得到剛更新的數(shù)據(jù)略贮，如果需要最新數(shù)據(jù)甚疟，應(yīng)該在讀數(shù)據(jù)之前調(diào)用sync()接口仗岖。 4 等待無關(guān)（wait-free）：慢的或者失效的client不干預(yù)快速的client的請求。 5 原子性：更新只能成功或者失敗览妖，沒有中間狀態(tài)轧拄。 6 順序性：所有Server，同一消息發(fā)布順序一致讽膏。
3.3. 使用場景
3.3.1. 數(shù)據(jù)發(fā)布****與****訂閱
發(fā)布與訂閱即所謂的配置管理檩电，顧名思義就是將數(shù)據(jù)發(fā)布到zk節(jié)點(diǎn)上，供訂閱者動(dòng)態(tài)獲取數(shù)據(jù)府树，實(shí)現(xiàn)配置信息的集中式管理和動(dòng)態(tài)更新俐末。例如：全局的配置信息、地址列表等奄侠。
3.3.2. 命名服務(wù)
這個(gè)主要是作為分布式命名服務(wù)卓箫，通過調(diào)用zk的create node api迁央，能夠很容易創(chuàng)建一個(gè)全局唯一的path罩扇，可以將這個(gè)path作為一個(gè)名稱。
3.3.3. 分布通知/協(xié)調(diào)
ZooKeeper中特有的watcher注冊于異步通知機(jī)制倦西，能夠很好的實(shí)現(xiàn)分布式環(huán)境下不同系統(tǒng)之間的通知與協(xié)調(diào)弯洗，實(shí)現(xiàn)對數(shù)據(jù)變更的實(shí)時(shí)處理旅急。使用方法通常是不同系統(tǒng)都對zk上同一個(gè)znode進(jìn)行注冊，監(jiān)聽znode的變化（包括znode本身內(nèi)容及子節(jié)點(diǎn)內(nèi)容）牡整，其中一個(gè)系統(tǒng)update了znode藐吮，那么另一個(gè)系統(tǒng)能夠收到通知，并做出相應(yīng)處理果正。
3.3.4. 分布式鎖
分布式鎖炎码，主要得益于ZooKeeper保證數(shù)據(jù)的強(qiáng)一致性，即zk集群中任意節(jié)點(diǎn)（一個(gè)zk server）上系統(tǒng)znoe的數(shù)據(jù)一定相同秋泳。
鎖服務(wù)可以分為兩類：
保持獨(dú)占鎖：所有試圖來獲取這個(gè)鎖的客戶端潦闲，最終只有一個(gè)可以成功獲得這把鎖。通常的做法是把zk上的一個(gè)znode看做是一把鎖迫皱，通過create znode的方式來實(shí)現(xiàn)歉闰。所有客戶端都去創(chuàng)建/distribute_lock節(jié)點(diǎn)，最終成功創(chuàng)建的那個(gè)客戶端也即擁有了這把鎖卓起。
控制時(shí)序鎖：所有試圖來獲取這個(gè)鎖的客戶端和敬，最終都是會(huì)被安排執(zhí)行，只是有個(gè)全局時(shí)序了戏阅。與保持獨(dú)占鎖的做法類似昼弟，不同點(diǎn)是/distribute_lock已經(jīng)預(yù)先存在，客戶端在它下面創(chuàng)建臨時(shí)有序節(jié)點(diǎn)（可以通過節(jié)點(diǎn)控制屬性控制：CreateMode.EPHEMERAL_SEQUENTIAL來指定）奕筐。zk的父節(jié)點(diǎn)(/distribute_lock)維持一份sequence舱痘，保證子節(jié)點(diǎn)創(chuàng)建的時(shí)序性变骡，從而形成每個(gè)客戶端的全局時(shí)序。
3.3.5. 集群管理
集群機(jī)器監(jiān)控：這通常用于那種對集群中機(jī)器狀態(tài)芭逝、機(jī)器在線率有較高要求的場景塌碌，能夠快速對集群中機(jī)器變化做出響應(yīng)。這樣的場景中旬盯，往往有一個(gè)監(jiān)控系統(tǒng)台妆，實(shí)時(shí)監(jiān)測集群機(jī)器是否存活。過去的做法通常是：監(jiān)控系統(tǒng)通過某種手段（比如ping）定時(shí)檢測每個(gè)機(jī)器胖翰、或每個(gè)機(jī)器定時(shí)向監(jiān)控系統(tǒng)發(fā)送心跳信息接剩。這種做法存在兩個(gè)弊端：1.集群中機(jī)器有變動(dòng)的時(shí)候，牽連修改的東西比較多泡态。2.有一定的延遲搂漠。利用ZooKeeper，可以實(shí)現(xiàn)另一種集群機(jī)器存活性監(jiān)控系統(tǒng)：a.客戶端在節(jié)點(diǎn)x上注冊watcher某弦，如果x的子節(jié)點(diǎn)發(fā)生變化桐汤，會(huì)通知該客戶端。b.創(chuàng)建EPHEMERAL類型的節(jié)點(diǎn)靶壮，一旦客戶端和服務(wù)器的會(huì)話結(jié)束或過期怔毛，該節(jié)點(diǎn)就會(huì)消失。例如：監(jiān)控系統(tǒng)在/clusterServers節(jié)點(diǎn)上注冊一個(gè)watcher腾降，以后每動(dòng)態(tài)加機(jī)器拣度，就往/culsterServer下創(chuàng)建一個(gè)EPHEMERAL類型的節(jié)點(diǎn)：/clusterServer/{hostname}。這樣螃壤，監(jiān)控系統(tǒng)就能實(shí)時(shí)知道機(jī)器的增減情況抗果，至于后續(xù)處理就是監(jiān)控系統(tǒng)的業(yè)務(wù)了。
Master選舉：在分布式環(huán)境中奸晴，相同的業(yè)務(wù)應(yīng)用分布在不同的機(jī)器上冤馏，有些業(yè)務(wù)邏輯（例如一些耗時(shí)的計(jì)算、網(wǎng)絡(luò)I/O處理）寄啼，往往需要讓整個(gè)集群中的某一臺(tái)機(jī)器進(jìn)行執(zhí)行逮光，其余機(jī)器可以共享這個(gè)結(jié)果，這樣可以減少重復(fù)勞動(dòng)墩划、提高性能涕刚。利用ZooKeeper的強(qiáng)一致性，能夠保證在分布式高并發(fā)情況下節(jié)點(diǎn)創(chuàng)建的全局唯一性乙帮，即：同時(shí)有多個(gè)客戶端請求創(chuàng)建/currentMaster節(jié)點(diǎn)杜漠，最終一定只有一個(gè)客戶端請求能夠創(chuàng)建成功。利用這個(gè)特性，就能很輕易的在分布式環(huán)境中進(jìn)行集群選取了碑幅。另外戴陡，這種場景演化一下塞绿，就是動(dòng)態(tài)Master選舉沟涨。這就要用到 EPHEMERAL_SEQUENTIAL類型節(jié)點(diǎn)的特性了。上文中提到异吻，所有客戶端創(chuàng)建請求裹赴，最終只有一個(gè)能夠創(chuàng)建成功。在這里稍微變化下诀浪，就是允許所有請求都能夠創(chuàng)建成功棋返，但是得有個(gè)創(chuàng)建順序，于是所有的請求最終在zk上創(chuàng)建結(jié)果的一種可能情況是這樣： /currentMaster/{sessionId}-1雷猪、/currentMaster/{sessionId}-2睛竣、/currentMaster/{sessionId}-3……。每次選取序列號(hào)最小的那個(gè)機(jī)器作為Master求摇，如果這個(gè)機(jī)器掛了射沟，由于他創(chuàng)建的節(jié)點(diǎn)會(huì)馬上消失，那么之后最小的那個(gè)機(jī)器就是Master了与境。
3.3.6. 分布式隊(duì)列
隊(duì)列方面验夯，有兩種方式：一種是常規(guī)的先進(jìn)先出隊(duì)列，另一種是要等到隊(duì)列成員聚齊之后的才統(tǒng)一按序執(zhí)行摔刁。
對于先進(jìn)先出隊(duì)列挥转，和分布式鎖服務(wù)中的控制時(shí)序場景基本原理一致，這里不再贅述共屈。
第二種隊(duì)列其實(shí)是在FIFO隊(duì)列的基礎(chǔ)上作了一個(gè)增強(qiáng)绑谣。通常可以在/queue這個(gè)znode下預(yù)先建立一個(gè)/queue/num節(jié)點(diǎn)拗引，并且賦值為n（或者直接給/queue賦值n）借宵，表示隊(duì)列大小，之后每次有隊(duì)列成員加入后寺擂，就判斷下是否已經(jīng)到達(dá)隊(duì)列大小暇务，決定是否可以開始執(zhí)行了。這種用法的典型場景是怔软，分布式環(huán)境中垦细，一個(gè)大任務(wù)Task A，需要在很多子任務(wù)完成（或條件就緒）情況下才能進(jìn)行挡逼。這個(gè)時(shí)候括改，凡是其中一個(gè)子任務(wù)完成（就緒），那么就去/taskList下建立自己的臨時(shí)時(shí)序節(jié)點(diǎn)（CreateMode.EPHEMERAL_SEQUENTIAL）家坎，當(dāng)/taskList發(fā)現(xiàn)自己下面的子節(jié)點(diǎn)滿足指定個(gè)數(shù)嘱能，就可以進(jìn)行下一步按序進(jìn)行處理了吝梅。
3.4. 架構(gòu)
1 每個(gè)Server在內(nèi)存中存儲(chǔ)了一份數(shù)據(jù)； 2 Zookeeper啟動(dòng)時(shí)惹骂，將從實(shí)例中選舉一個(gè)leader（Paxos協(xié)議）苏携； 3 Leader負(fù)責(zé)處理數(shù)據(jù)更新等操作（Zab協(xié)議）； 4 一個(gè)更新操作成功对粪，當(dāng)且僅當(dāng)大多數(shù)Server在內(nèi)存中成功修改數(shù)據(jù)右冻。
3.5. 使用
ZooKeeper -server host:port cmd args
stat path [watch]
set path data [version]
ls path [watch]
delquota [-n|-b] path
ls2 path [watch]
setAcl path acl
setquota -n|-b val path
history
redo cmdno
printwatches on|off
delete path [version]
sync path
listquota path
rmr path
get path [watch]
create [-s] [-e] path data acl
addauth scheme auth
quit
getAcl path
close
connect host:port
4. 數(shù)據(jù)存儲(chǔ)HBASE
4.1. 簡介
HBASE是建立在hdfs之上，提供高可靠性著拭、高性能纱扭、列存儲(chǔ)、可伸縮儡遮、實(shí)時(shí)讀寫的數(shù)據(jù)庫系統(tǒng)乳蛾。
它介于nosql和RDBMS之間，僅能通過主鍵(row key)和主鍵的range來檢索數(shù)據(jù)鄙币，僅支持單行事務(wù)(可通過hive支持來實(shí)現(xiàn)多表join等復(fù)雜操作)肃叶。主要用來存儲(chǔ)非結(jié)構(gòu)化和半結(jié)構(gòu)化的松散數(shù)據(jù)。
與hadoop一樣爱榔，Hbase目標(biāo)主要依靠橫向擴(kuò)展被环，通過不斷增加廉價(jià)的商用服務(wù)器，來增加計(jì)算和存儲(chǔ)能力详幽。
4.2. HBASE視圖
4.3. 特性
1筛欢、大表：一個(gè)表可以有數(shù)十億行，上百萬列唇聘；
2版姑、無模式：每行都有一個(gè)可排序的主鍵和任意多的列，列可以根據(jù)需要?jiǎng)討B(tài)的增加迟郎，同一張表中不同的行可以有截然不同的列剥险；
3、面向列：面向列（族）的存儲(chǔ)和權(quán)限控制宪肖，列（族）獨(dú)立檢索表制；
4、稀疏：對于空（null）的列控乾，并不占用存儲(chǔ)空間么介，表可以設(shè)計(jì)的非常稀疏；
5蜕衡、數(shù)據(jù)多版本：每個(gè)單元中的數(shù)據(jù)可以有多個(gè)版本壤短，默認(rèn)情況下版本號(hào)自動(dòng)分配，是單元格插入時(shí)的時(shí)間戳；
6久脯、數(shù)據(jù)類型單一：Hbase中的數(shù)據(jù)都是字符串纳胧，沒有類型。
4.4. 使用場景
HBASE適用場景
1帘撰、存在高并發(fā)讀寫
2跑慕、表結(jié)構(gòu)的列族經(jīng)常需要調(diào)整
3、存儲(chǔ)結(jié)構(gòu)化或半結(jié)構(gòu)化數(shù)據(jù)
4骡和、高并發(fā)的key-value存儲(chǔ)
5相赁、key隨機(jī)寫入，有序存儲(chǔ)
6慰于、針對每個(gè)key保存一個(gè)固定大小的集合 多版本
HBASE****數(shù)據(jù)也存在不適用的場景
1、由于hbase只能提供行鎖唤衫，它對分布式事務(wù)支持不好
2婆赠、對于查詢操作中的join、group by 性能很差
3佳励、查詢?nèi)绻皇褂胷ow-key查詢休里，性能會(huì)很差，因?yàn)榇藭r(shí)會(huì)進(jìn)行全表掃描赃承，建立二級(jí)索引或多級(jí)索引需要同時(shí)維護(hù)一張索引表
4妙黍、高并發(fā)的隨機(jī)讀支持有限
4.5. 架構(gòu)
由上圖可知，hbase包括Clinet瞧剖、HMaster拭嫁、HRegionServer、ZooKeeper組件
各組件功能介紹：
1抓于、Client
Client主要通過ZooKeeper與Hbaser和HRegionServer通信做粤，對于管理操作：client向master發(fā)起請求，對于數(shù)據(jù)讀寫操作：client向regionserver發(fā)起請求
2捉撮、ZooKeeper
zk負(fù)責(zé)存儲(chǔ)meta表的地址怕品，也負(fù)責(zé)存儲(chǔ)當(dāng)前服務(wù)的master地址,region server也會(huì)將自身的信息注冊到zk中，以便master能夠感知region server的狀態(tài)巾遭，zk也會(huì)協(xié)調(diào)active master肉康，也就是可以提供一個(gè)選舉master leader,也會(huì)協(xié)調(diào)各個(gè)region server的容災(zāi)流程
3、HMaster
master可以啟動(dòng)多個(gè)master灼舍，master主要負(fù)責(zé)table和region的管理工作吼和，響應(yīng)用戶對表的CRUD操作，管理region server的負(fù)載均衡片仿，調(diào)整region 的分布和分配纹安，當(dāng)region server停機(jī)后，負(fù)責(zé)對失效的regionn進(jìn)行遷移操作
4、HRegionServer
region server主要負(fù)責(zé)響應(yīng)用戶的IO請求厢岂，并把IO請求轉(zhuǎn)換為讀寫HDFS的操作
5. 數(shù)據(jù)倉庫hive
5.1. 簡介
Hive 是一個(gè)基于 Hadoop 文件系統(tǒng)之上的數(shù)據(jù)倉庫架構(gòu)光督。它為數(shù)據(jù)倉庫的管理提供了許多功能：數(shù)據(jù) ETL （抽取、轉(zhuǎn)換和加載）工具塔粒、數(shù)據(jù)存儲(chǔ)管理和大型數(shù)據(jù)集的查詢和分析能力结借。同時(shí) Hive 還定義了類 SQL的語言 – Hive QL. Hive QL 允許用戶進(jìn)行和 SQL 相似的操作，它可以將結(jié)構(gòu)化的數(shù)據(jù)文件映射為一張數(shù)據(jù)庫表卒茬，并提供簡單的 SQL 查詢功能船老。還允許開發(fā)人員方便地使用 Mapper 和 Reducer 操作，可以將 SQL 語句轉(zhuǎn)換為 MapReduce 任務(wù)運(yùn)行圃酵，這對 MapReduce 框架來說是一個(gè)強(qiáng)有力的支持柳畔。
5.2. 特性
優(yōu)點(diǎn)： 1.Hive 使用類SQL 查詢語法, 最大限度的實(shí)現(xiàn)了和SQL標(biāo)準(zhǔn)的兼容，大大降低了傳統(tǒng)數(shù)據(jù)分析人員學(xué)習(xí)的曲線郭赐； 2.使用JDBC 接口/ODBC接口薪韩，開發(fā)人員更易開發(fā)應(yīng)用； 3.以MR 作為計(jì)算引擎捌锭、HDFS 作為存儲(chǔ)系統(tǒng)俘陷，為超大數(shù)據(jù)集設(shè)計(jì)的計(jì)算/ 擴(kuò)展能力； 4.統(tǒng)一的元數(shù)據(jù)管理（Derby观谦、MySql等）拉盾，并可與Pig 、Presto 等共享豁状； 缺點(diǎn)： 1.Hive 的HQL 表達(dá)的能力有限捉偏，有些復(fù)雜運(yùn)算用HQL 不易表達(dá)； 2.由于Hive自動(dòng)生成MapReduce 作業(yè)替蔬， HQL 調(diào)優(yōu)困難告私； 3.粒度較粗，可控性差
5.3. 使用場景
Hive 構(gòu)建在基于靜態(tài)批處理的 Hadoop 之上承桥，Hadoop 通常都有較高的延遲并且在作業(yè)提交和調(diào)度的時(shí)候需要大量的開銷驻粟。因此，Hive 不適合在大規(guī)模數(shù)據(jù)集上實(shí)現(xiàn)低延遲快速的查詢凶异。
Hive 并不適合那些需要低延遲的應(yīng)用蜀撑，例如，聯(lián)機(jī)事務(wù)處理（OLTP）剩彬。Hive 查詢操作過程嚴(yán)格遵守 Hadoop MapReduce 的作業(yè)執(zhí)行模型酷麦，Hive 將用戶的 HiveQL 語句通過解釋器轉(zhuǎn)換為 MapReduce 作業(yè)提交到 Hadoop 集群上，Hadoop 監(jiān)控作業(yè)執(zhí)行過程喉恋，然后返回作業(yè)執(zhí)行結(jié)果給用戶沃饶。Hive 并非為聯(lián)機(jī)事務(wù)處理而設(shè)計(jì)母廷，Hive 并不提供實(shí)時(shí)的查詢和基于行級(jí)的數(shù)據(jù)更新操作。
Hive 的最佳使用場合是大數(shù)據(jù)集的批處理作業(yè)糊肤，例如琴昆，網(wǎng)絡(luò)日志分析。
5.4. 架構(gòu)
從圖中我們可以看出 Hive 其基本組成可以分為：
1用戶接口馆揉，包括 CLI, JDBC/ODBC, WebUI
2元數(shù)據(jù)存儲(chǔ)业舍，通常是存儲(chǔ)在關(guān)系數(shù)據(jù)庫如 MySQL, Derby 中
3解釋器、編譯器升酣、優(yōu)化器舷暮、執(zhí)行器
4用 HDFS 進(jìn)行存儲(chǔ)，利用 MapReduce 進(jìn)行計(jì)算
5.5. 開發(fā)常用命令
查看所有的數(shù)據(jù)庫：
hive> show databases ;
使用數(shù)據(jù)庫：
hive> use default;
創(chuàng)建表：
加載數(shù)據(jù)：
查看表數(shù)據(jù)：
等等
6. 數(shù)據(jù)處理
6.1. Spark
6.1.1. 簡介
1. 什么是Spark噩茄？Spark作為Apache頂級(jí)的開源項(xiàng)目下面，是一個(gè)快速、通用的大規(guī)模數(shù)據(jù)處理引擎巢墅，和Hadoop的MapReduce計(jì)算框架類似诸狭，但是相對于MapReduce，Spark憑借其可伸縮君纫、基于內(nèi)存計(jì)算等特點(diǎn)，以及可以直接讀寫Hadoop上任何格式數(shù)據(jù)的優(yōu)勢芹彬，進(jìn)行批處理時(shí)更加高效蓄髓，并有更低的延遲。相對于“one stack to rule them all”的目標(biāo)舒帮，實(shí)際上会喝，Spark已經(jīng)成為輕量級(jí)大數(shù)據(jù)快速處理的統(tǒng)一平臺(tái)，各種不同的應(yīng)用玩郊，如實(shí)時(shí)流處理肢执、機(jī)器學(xué)習(xí)、交互式查詢等译红，都可以通過Spark建立在不同的存儲(chǔ)和運(yùn)行系統(tǒng)上预茄。
2. Spark是基于內(nèi)存計(jì)算的大數(shù)據(jù)并行計(jì)算框架。Spark基于內(nèi)存計(jì)算侦厚，提高了在大數(shù)據(jù)環(huán)境下數(shù)據(jù)處理的實(shí)時(shí)性耻陕，同時(shí)保證了高容錯(cuò)性和高可伸縮性，允許用戶將Spark部署在大量廉價(jià)硬件之上刨沦，形成集群诗宣。
3. Spark目前，已經(jīng)成為Apache軟件基金會(huì)旗下的頂級(jí)開源項(xiàng)目想诅。相對于MapReduce上的批量計(jì)算召庞、迭代型計(jì)算以及基于Hive的SQL查詢岛心，Spark可以帶來上百倍的性能提升。目前Spark的生態(tài)系統(tǒng)日趨完善篮灼，Spark SQL的發(fā)布忘古、Hive on Spark項(xiàng)目的啟動(dòng)以及大量大數(shù)據(jù)公司對Spark全棧的支持，讓Spark的數(shù)據(jù)分析范式更加豐富
6.1.2. 特性
基于Hadoop的資源管理器YARN實(shí)際上是一個(gè)彈性計(jì)算平臺(tái)穿稳，作為統(tǒng)一的計(jì)算資源管理框架存皂，不僅僅服務(wù)于MapReduce計(jì)算框架，而且已經(jīng)實(shí)現(xiàn)了多種計(jì)算框架進(jìn)行統(tǒng)一管理逢艘。這種共享集群資源的模式帶來了很多好處旦袋。
- 快速
Spark有先進(jìn)的DAG執(zhí)行引擎，支持循環(huán)數(shù)據(jù)流和內(nèi)存計(jì)算它改；Spark程序在內(nèi)存中的運(yùn)行速度是Hadoop MapReduce運(yùn)行速度的100倍疤孕，在磁盤上的運(yùn)行速度是Hadoop MapReduce運(yùn)行速度的10倍。
- 易用
Spark支持使用Java央拖、Scala祭阀、Python語言快速編寫應(yīng)用，提供超過80個(gè)高級(jí)運(yùn)算符鲜戒，使得編寫并行應(yīng)用程序變得容易专控。
- 通用
Spark可以與SQL、Streaming以及復(fù)雜的分析良好結(jié)合遏餐÷赘基于Spark，有一系列高級(jí)工具失都，包括Spark SQL柏蘑、MLlib（機(jī)器學(xué)習(xí)庫）、GraphX和Spark Streaming粹庞，支持在一個(gè)應(yīng)用中同時(shí)使用這些架構(gòu)咳焚。 4. 有效集成Hadoop
Spark可以指定Hadoop，YARN的版本來編譯出合適的發(fā)行版本庞溜，Spark也能夠很容易地運(yùn)行在EC2革半、Mesos上，或以Standalone模式運(yùn)行强缘，并從HDFS督惰、HBase、Cassandra和其他Hadoop數(shù)據(jù)源讀取數(shù)據(jù)旅掂。
5.資源利用率高
多種框架共享資源的模式有效解決了由于應(yīng)用程序數(shù)量的不均衡性導(dǎo)致的高峰時(shí)段任務(wù)比較擁擠赏胚，空閑時(shí)段任務(wù)比較空閑的問題；同時(shí)均衡了內(nèi)存和CPU等資源的利用商虐。
6.實(shí)現(xiàn)了數(shù)據(jù)共享
隨著數(shù)據(jù)量的增加觉阅，數(shù)據(jù)移動(dòng)成本越來越高崖疤，網(wǎng)絡(luò)帶寬、磁盤空間典勇、磁盤IO都會(huì)成為瓶頸劫哼，在分散數(shù)據(jù)的情況下，會(huì)造成任務(wù)執(zhí)行的成本提高割笙，獲得結(jié)果的周期變長权烧，而數(shù)據(jù)共享模式可以讓多種框架共享數(shù)據(jù)和硬件資源，大幅度減少數(shù)據(jù)分散帶來的成本伤溉。
7.有效降低運(yùn)維和管理成本
相比較一種計(jì)算框架需要一批維護(hù)人員般码，而運(yùn)維人員較多又會(huì)帶來的管理成本的上升；共享模式只需要少數(shù)的運(yùn)維人員和管理人員即可完成多個(gè)框架的統(tǒng)一運(yùn)維管理乱顾，便于運(yùn)維優(yōu)化和運(yùn)維管理策略統(tǒng)一執(zhí)行板祝。
6.1.3. 使用場景
1. 快速查詢系統(tǒng)基于日志數(shù)據(jù)的快速查詢系統(tǒng)業(yè)務(wù)構(gòu)建于Spark之上，利用其快速查詢以及內(nèi)存表等優(yōu)勢走净，能夠承擔(dān)大部分日志數(shù)據(jù)的即時(shí)查詢工作券时；在性能方面，普遍比Hive快2～10倍伏伯，如果使用內(nèi)存表的功能橘洞，性能將會(huì)比Hive快百倍。
2. 實(shí)時(shí)日志采集處理 通過Spark Streaming實(shí)時(shí)進(jìn)行業(yè)務(wù)日志采集说搅，快速迭代處理震檩，并進(jìn)行綜合分析，能夠滿足線上系統(tǒng)分析要求蜓堕。
3. 業(yè)務(wù)推薦系統(tǒng) 使用Spark將業(yè)務(wù)推薦系統(tǒng)的小時(shí)和天級(jí)別的模型訓(xùn)練轉(zhuǎn)變?yōu)榉昼娂?jí)別的模型訓(xùn)練，有效優(yōu)化相關(guān)排名博其、個(gè)性化推薦以及熱點(diǎn)點(diǎn)擊分析等套才。
4. 定制廣告系統(tǒng) 在定制廣告業(yè)務(wù)方面需要大數(shù)據(jù)做應(yīng)用分析、效果分析慕淡、定向優(yōu)化等背伴，借助Spark快速迭代的優(yōu)勢，實(shí)現(xiàn)了在“數(shù)據(jù)實(shí)時(shí)采集峰髓、算法實(shí)時(shí)訓(xùn)練傻寂、系統(tǒng)實(shí)時(shí)預(yù)測”的全流程實(shí)時(shí)并行高維算法富稻，支持上億的請求量處理偿乖；模擬廣告投放計(jì)算效率高汇在、延遲小癣丧，同MapReduce相比延遲至少降低一個(gè)數(shù)量級(jí)胚委。
5. 用戶圖計(jì)算 利用GraphX解決了許多生產(chǎn)問題士飒，包括以下計(jì)算場景：基于度分布的中樞節(jié)點(diǎn)發(fā)現(xiàn)帘营、基于最大連通圖的社區(qū)發(fā)現(xiàn)尉姨、基于三角形計(jì)數(shù)的關(guān)系衡量、基于隨機(jī)游走的用戶屬性傳播等拂檩。
6.1.4. 架構(gòu)
· Spark Core：包含Spark的基本功能侮腹；尤其是定義RDD的API、操作以及這兩者上的動(dòng)作稻励。其他Spark的庫都是構(gòu)建在RDD和Spark Core之上的
· Spark SQL：提供通過Apache Hive的SQL變體Hive查詢語言（HiveQL）與Spark進(jìn)行交互的API父阻。每個(gè)數(shù)據(jù)庫表被當(dāng)做一個(gè)RDD，Spark SQL查詢被轉(zhuǎn)換為Spark操作望抽。
· Spark Streaming：對實(shí)時(shí)數(shù)據(jù)流進(jìn)行處理和控制加矛。Spark Streaming允許程序能夠像普通RDD一樣處理實(shí)時(shí)數(shù)據(jù)
· MLlib：一個(gè)常用機(jī)器學(xué)習(xí)算法庫，算法被實(shí)現(xiàn)為對RDD的Spark操作糠聪。這個(gè)庫包含可擴(kuò)展的學(xué)習(xí)算法荒椭，比如分類、回歸等需要對大量數(shù)據(jù)集進(jìn)行迭代的操作舰蟆。
· GraphX：控制圖趣惠、并行圖操作和計(jì)算的一組算法和工具的集合。GraphX擴(kuò)展了RDD API身害，包含控制圖味悄、創(chuàng)建子圖、訪問路徑上所有頂點(diǎn)的操作塌鸯。
6.2. Storm
6.2.1. 簡介
Storm是一個(gè)免費(fèi)并開源的分布式實(shí)時(shí)計(jì)算系統(tǒng)侍瑟。利用Storm可以很容易做到可靠地處理無限的數(shù)據(jù)流，像Hadoop批量處理大數(shù)據(jù)一樣丙猬，Storm可以實(shí)時(shí)處理數(shù)據(jù)涨颜。Storm簡單，可以使用任何編程語言茧球。
在Storm之前庭瑰，進(jìn)行實(shí)時(shí)處理是非常痛苦的事情: 需要維護(hù)一堆消息隊(duì)列和消費(fèi)者，他們構(gòu)成了非常復(fù)雜的圖結(jié)構(gòu)抢埋。消費(fèi)者進(jìn)程從隊(duì)列里取消息弹灭，處理完成后，去更新數(shù)據(jù)庫揪垄，或者給其他隊(duì)列發(fā)新消息穷吮。
這樣進(jìn)行實(shí)時(shí)處理是非常痛苦的。我們主要的時(shí)間都花在關(guān)注往哪里發(fā)消息饥努，從哪里接收消息捡鱼，消息如何序列化，真正的業(yè)務(wù)邏輯只占了源代碼的一小部分肪凛。一個(gè)應(yīng)用程序的邏輯運(yùn)行在很多worker上堰汉，但這些worker需要各自單獨(dú)部署辽社，還需要部署消息隊(duì)列。最大問題是系統(tǒng)很脆弱翘鸭，而且不是容錯(cuò)的：需要自己保證消息隊(duì)列和worker進(jìn)程工作正常滴铅。
Storm完整地解決了這些問題。它是為分布式場景而生的就乓，抽象了消息傳遞汉匙，會(huì)自動(dòng)地在集群機(jī)器上并發(fā)地處理流式計(jì)算，讓你專注于實(shí)時(shí)處理的業(yè)務(wù)邏輯生蚁。
6.2.2. 特性
編程簡單：開發(fā)人員只需要關(guān)注應(yīng)用邏輯噩翠，而且跟Hadoop類似，Storm提供的編程原語也很簡單
高性能邦投，低延遲：可以應(yīng)用于廣告搜索引擎這種要求對廣告主的操作進(jìn)行實(shí)時(shí)響應(yīng)的場景伤锚。
分布式：可以輕松應(yīng)對數(shù)據(jù)量大，單機(jī)搞不定的場景
可擴(kuò)展： 隨著業(yè)務(wù)發(fā)展志衣，數(shù)據(jù)量和計(jì)算量越來越大屯援，系統(tǒng)可水平擴(kuò)展
容錯(cuò)：單個(gè)節(jié)點(diǎn)掛了不影響應(yīng)用
消息不丟失：保證消息處理
6.2.3. 使用場景
Storm有很多應(yīng)用：實(shí)時(shí)分析，在線機(jī)器學(xué)習(xí)(online machine learning)念脯，連續(xù)計(jì)算(continuous computation)狞洋，分布式遠(yuǎn)程過程調(diào)用(RPC)、ETL等绿店。Storm處理速度很快：每個(gè)節(jié)點(diǎn)每秒鐘可以處理超過百萬的數(shù)據(jù)組吉懊。它是可擴(kuò)展(scalable)，容錯(cuò)(fault-tolerant)假勿，保證你的數(shù)據(jù)會(huì)被處理借嗽，并且很容易搭建和操作。
例如Nathan Marz提供的例子转培，產(chǎn)生Twitter的趨勢信息淹魄。Twitter從海量推文中抽取趨勢信息，并在本地區(qū)域和國家層級(jí)進(jìn)行維護(hù)堡距。這意味者一旦一個(gè)案例開始出現(xiàn)，Twitter的話題趨勢算法就能實(shí)時(shí)的鑒別出這個(gè)話題兆蕉。這個(gè)實(shí)時(shí)的算法就是通過在Storm上連續(xù)分析Twitter數(shù)據(jù)來實(shí)現(xiàn)的羽戒。
6.2.4. 架構(gòu)
Nimbus Storm集群的Master節(jié)點(diǎn)，負(fù)責(zé)分發(fā)用戶代碼虎韵，指派給具體的Supervisor節(jié)點(diǎn)上的Worker節(jié)點(diǎn)易稠，去運(yùn)行Topology對應(yīng)的組件（Spout/Bolt）的Task。 Supervisor Storm集群的從節(jié)點(diǎn)包蓝，負(fù)責(zé)管理運(yùn)行在Supervisor節(jié)點(diǎn)上的每一個(gè)Worker進(jìn)程的啟動(dòng)和終止驶社。通過Storm的配置文件中的supervisor.slots.ports配置項(xiàng)企量，可以指定在一個(gè)Supervisor上最大允許多少個(gè)Slot，每個(gè)Slot通過端口號(hào)來唯一標(biāo)識(shí)亡电，一個(gè)端口號(hào)對應(yīng)一個(gè)Worker進(jìn)程（如果該Worker進(jìn)程被啟動(dòng)）届巩。
Worker
運(yùn)行具體處理組件邏輯的進(jìn)程。Worker運(yùn)行的任務(wù)類型只有兩種份乒，一種是Spout任務(wù)恕汇，一種是Bolt任務(wù)。
Task
worker中每一個(gè)spout/bolt的線程稱為一個(gè)task. 在storm0.8之后或辖，task不再與物理線程對應(yīng)瘾英，不同spout/bolt的task可能會(huì)共享一個(gè)物理線程，該線程稱為executor颂暇。
ZooKeeper 用來協(xié)調(diào)Nimbus和Supervisor缺谴，如果Supervisor因故障出現(xiàn)問題而無法運(yùn)行Topology，Nimbus會(huì)第一時(shí)間感知到耳鸯，并重新分配Topology到其它可用的Supervisor上運(yùn)行
6.2.5. 與****hadoop比較
1.Storm用于實(shí)時(shí)計(jì)算湿蛔，Hadoop用于離線計(jì)算。
2. Storm處理的數(shù)據(jù)保存在內(nèi)存中片拍，源源不斷煌集；Hadoop處理的數(shù)據(jù)保存在文件系統(tǒng)中，一批一批捌省。
Storm的數(shù)據(jù)通過網(wǎng)絡(luò)傳輸進(jìn)來苫纤；Hadoop的數(shù)據(jù)保存在磁盤中。
Storm與Hadoop的編程模型相似
6.2.6. 與spark比較
7. 消息系統(tǒng)kafka
7.1. 簡介
Kafka是最初由Linkedin公司開發(fā)纲缓，是一個(gè)分布式卷拘、支持分區(qū)的（partition）、多副本的（replica）祝高，基于zookeeper協(xié)調(diào)的分布式消息系統(tǒng)栗弟，它的最大的特性就是可以實(shí)時(shí)的處理大量數(shù)據(jù)以滿足各種需求場景：比如基于hadoop的批處理系統(tǒng)、低延遲的實(shí)時(shí)系統(tǒng)工闺、storm/Spark流式處理引擎乍赫，web/nginx日志、訪問日志陆蟆，消息服務(wù)等等雷厂，用scala語言編寫，Linkedin于2010年貢獻(xiàn)給了Apache基金會(huì)并成為頂級(jí)開源 項(xiàng)目叠殷。
7.2. 特性
高吞吐量改鲫、低延遲：kafka每秒可以處理幾十萬條消息，它的延遲最低只有幾毫秒，每個(gè)topic可以分多個(gè)partition, consumer group 對partition進(jìn)行consume操作像棘。
可擴(kuò)展性：kafka集群支持熱擴(kuò)展
持久性稽亏、可靠性：消息被持久化到本地磁盤，并且支持?jǐn)?shù)據(jù)備份防止數(shù)據(jù)丟失
容錯(cuò)性：允許集群中節(jié)點(diǎn)失斅铺狻（若副本數(shù)量為n,則允許n-1個(gè)節(jié)點(diǎn)失斀厍浮）
高并發(fā)：支持?jǐn)?shù)千個(gè)客戶端同時(shí)讀寫
7.3. 使用場景
日志收集：一個(gè)公司可以用Kafka可以收集各種服務(wù)的log，通過kafka以統(tǒng)一接口服務(wù)的方式開放給各種consumer避除，例如hadoop怎披、Hbase、Solr等瓶摆。
消息系統(tǒng)：解耦和生產(chǎn)者和消費(fèi)者凉逛、緩存消息等。
用戶活動(dòng)跟蹤：Kafka經(jīng)常被用來記錄web用戶或者app用戶的各種活動(dòng)群井，如瀏覽網(wǎng)頁状飞、搜索、點(diǎn)擊等活動(dòng)书斜，這些活動(dòng)信息被各個(gè)服務(wù)器發(fā)布到kafka的topic中诬辈，然后訂閱者通過訂閱這些topic來做實(shí)時(shí)的監(jiān)控分析，或者裝載到hadoop荐吉、數(shù)據(jù)倉庫中做離線分析和挖掘焙糟。
運(yùn)營指標(biāo)：Kafka也經(jīng)常用來記錄運(yùn)營監(jiān)控?cái)?shù)據(jù)。包括收集各種分布式應(yīng)用的數(shù)據(jù)样屠，生產(chǎn)各種操作的集中反饋穿撮，比如報(bào)警和報(bào)告。
流式處理：比如spark streaming和storm
事件源
7.4. 架構(gòu)
一個(gè)典型的Kafka集群中包含若干Producer（可以是web前端FET痪欲，或者是服務(wù)器日志等）悦穿，若干broker（Kafka支持水平擴(kuò)展，一般broker數(shù)量越多业踢，集群吞吐率越高）栗柒，若干ConsumerGroup，以及一個(gè)Zookeeper集群知举。Kafka通過Zookeeper管理Kafka集群配置：選舉Kafka broker的leader瞬沦，以及在Consumer Group發(fā)生變化時(shí)進(jìn)行rebalance，因?yàn)?strong>consumer消費(fèi)kafka topic的partition的offsite信息是存在Zookeeper的雇锡。Producer使用push模式將消息發(fā)布到broker蛙埂，Consumer使用pull模式從broker訂閱并消費(fèi)消息。
7.5. Kafka中名詞解釋
Kafka中發(fā)布訂閱的對象是topic遮糖。我們可以為每類數(shù)據(jù)創(chuàng)建一個(gè)topic，把向topic發(fā)布消息的客戶端稱作producer叠赐，從topic訂閱消息的客戶端稱作consumer欲账。Producers和consumers可以同時(shí)從多個(gè)topic讀寫數(shù)據(jù)屡江。一個(gè)kafka集群由一個(gè)或多個(gè)broker服務(wù)器組成，它負(fù)責(zé)持久化和備份具體的kafka消息赛不。
· Broker：Kafka節(jié)點(diǎn)惩嘉，一個(gè)Kafka節(jié)點(diǎn)就是一個(gè)broker，多個(gè)broker可以組成一個(gè)Kafka集群踢故。
· Topic：一類消息文黎，消息存放的目錄即主題，例如page view日志殿较、click日志等都可以以topic的形式存在耸峭，Kafka集群能夠同時(shí)負(fù)責(zé)多個(gè)topic的分發(fā)。
· Partition：topic物理上的分組淋纲，一個(gè)topic可以分為多個(gè)partition劳闹，每個(gè)partition是一個(gè)有序的隊(duì)列
· Segment：partition物理上由多個(gè)segment組成，每個(gè)Segment存著message信息
· **Producer **: 生產(chǎn)message發(fā)送到topic
· **Consumer **: 訂閱topic消費(fèi)message, consumer作為一個(gè)線程來消費(fèi)
· Consumer Group：一個(gè)Consumer Group包含多個(gè)consumer, 這個(gè)是預(yù)先在配置文件中配置好的洽瞬。各個(gè)consumer（consumer 線程）可以組成一個(gè)組（Consumer group ）本涕，partition中的每個(gè)message只能被組（Consumer group ） 中的一個(gè)consumer（consumer 線程 ）消費(fèi)，如果一個(gè)message可以被多個(gè)consumer（consumer 線程 ） 消費(fèi)的話伙窃，那么這些consumer必須在不同的組菩颖。Kafka不支持一個(gè)partition中的message由兩個(gè)或兩個(gè)以上的consumer thread來處理，即便是來自不同的consumer group的也不行为障。它不能像AMQ那樣可以多個(gè)BET作為consumer去處理message晦闰，這是因?yàn)槎鄠€(gè)BET去消費(fèi)一個(gè)Queue中的數(shù)據(jù)的時(shí)候，由于要保證不能多個(gè)線程拿同一條message产场，所以就需要行級(jí)別悲觀所（for update）,這就導(dǎo)致了consume的性能下降鹅髓，吞吐量不夠。而kafka為了保證吞吐量京景，只允許一個(gè)consumer線程去訪問一個(gè)partition窿冯。如果覺得效率不高的時(shí)候，可以加partition的數(shù)量來橫向擴(kuò)展确徙，那么再加新的consumer thread去消費(fèi)醒串。這樣沒有鎖競爭，充分發(fā)揮了橫向的擴(kuò)展性鄙皇，吞吐量極高芜赌。這也就形成了分布式消費(fèi)的概念。
8. 數(shù)據(jù)采集
8.1. Etl介紹
ETL是數(shù)據(jù)抽取（Extract）伴逸、清洗（Cleaning）缠沈、轉(zhuǎn)換（Transform）、裝載（Load）的過程。是構(gòu)建數(shù)據(jù)倉庫的重要一環(huán)洲愤，用戶從數(shù)據(jù)源抽取出所需的數(shù)據(jù)颓芭，經(jīng)過數(shù)據(jù)清洗,最終按照預(yù)先定義好的數(shù)據(jù)倉庫模型，將數(shù)據(jù)加載到數(shù)據(jù)倉庫中去柬赐。
8.2. Elk
8.2.1. 簡介
ELK 其實(shí)并不是一款軟件亡问，而是一整套解決方案，是三個(gè)軟件產(chǎn)品的首字母縮寫肛宋，Elasticsearch州藕，Logstash 和 Kibana。這三款軟件都是開源軟件酝陈，通常是配合使用床玻，而且又先后歸于 Elastic.co 公司名下，故被簡稱為 ELK 協(xié)議棧后添，見圖 笨枯。
8.2.1.1. Elasticsearch
Elasticsearch 是一個(gè)實(shí)時(shí)的分布式搜索和分析引擎，它可以用于全文搜索遇西，結(jié)構(gòu)化搜索以及分析馅精。它是一個(gè)建立在全文搜索引擎 Apache Lucene 基礎(chǔ)上的搜索引擎，使用 Java 語言編寫粱檀。目前洲敢，最新的版本是 2.1.0。
主要特點(diǎn)
實(shí)時(shí)分析
分布式實(shí)時(shí)文件存儲(chǔ)茄蚯，并將每一個(gè)字段都編入索引
文檔導(dǎo)向压彭，所有的對象全部是文檔
高可用性，易擴(kuò)展渗常，支持集群（Cluster）壮不、分片和復(fù)制（Shards 和 Replicas）。見圖 2 和圖 3
接口友好皱碘，支持 JSON
8.2.1.2. Logstash
Logstash 是一個(gè)具有實(shí)時(shí)渠道能力的數(shù)據(jù)收集引擎询一。使用 JRuby 語言編寫。其作者是世界著名的運(yùn)維工程師喬丹西塞 (JordanSissel)癌椿。
主要特點(diǎn):
幾乎可以訪問任何數(shù)據(jù)
可以和多種外部應(yīng)用結(jié)合
支持彈性擴(kuò)展
它由三個(gè)主要部分組成健蕊，見圖：
Shipper－發(fā)送日志數(shù)據(jù)
Broker－收集數(shù)據(jù)，缺省內(nèi)置 Redis
Indexer－數(shù)據(jù)寫入
8.2.1.3. Kibala
Kibana 是一款基于 Apache 開源協(xié)議踢俄，使用 JavaScript 語言編寫缩功，為 Elasticsearch 提供分析和可視化的 Web 平臺(tái)。它可以在 Elasticsearch 的索引中查找都办，交互數(shù)據(jù)嫡锌，并生成各種維度的表圖虑稼。
8.2.2. 架構(gòu)
8.2.3. 使用場景
1、日志查詢势木，問題排查动雹，上線檢查。
2跟压、服務(wù)器監(jiān)控，應(yīng)用監(jiān)控歼培，錯(cuò)誤報(bào)警震蒋，bug管理。
3躲庄、性能分析查剖，用戶行為分析，安全漏洞分析噪窘，時(shí)間管理笋庄。
8.3. Flume
8.3.1. 簡介
apache Flume 是一個(gè)從可以收集例如日志，事件等數(shù)據(jù)資源倔监，并將這些數(shù)量龐大的數(shù)據(jù)從各項(xiàng)數(shù)據(jù)資源中集中起來存儲(chǔ)的工具/服務(wù)直砂，或者數(shù)集中機(jī)制。flume具有高可用浩习，分布式静暂，配置工具，其設(shè)計(jì)的原理也是基于將數(shù)據(jù)流谱秽，如日志數(shù)據(jù)從各種網(wǎng)站服務(wù)器上匯集起來存儲(chǔ)到HDFS洽蛀，HBase等集中存儲(chǔ)器中
8.3.2. 特性
1. Flume可以高效率的將多個(gè)網(wǎng)站服務(wù)器中收集的日志信息存入HDFS/HBase中
2. 使用Flume，我們可以將從多個(gè)服務(wù)器中獲取的數(shù)據(jù)迅速的移交給Hadoop中
3. 除了日志信息疟赊，F(xiàn)lume同時(shí)也可以用來接入收集規(guī)模宏大的社交網(wǎng)絡(luò)節(jié)點(diǎn)事件數(shù)據(jù)郊供，比如facebook,twitter,電商網(wǎng)站如亞馬遜，flipkart等
4. 支持各種接入資源數(shù)據(jù)的類型以及接出數(shù)據(jù)類型
5. 支持多路徑流量近哟，多管道接入流量驮审，多管道接出流量，上下文路由等
6. 可以被水平擴(kuò)展
8.3.3. 使用場景
比如我們在做一個(gè)電子商務(wù)網(wǎng)站椅挣，然后我們想從消費(fèi)用戶中訪問點(diǎn)特定的節(jié)點(diǎn)區(qū)域來分析消費(fèi)者的行為或者購買意圖. 這樣我們就可以更加快速的將他想要的推送到界面上头岔，實(shí)現(xiàn)這一點(diǎn)，我們需要將獲取到的她訪問的頁面以及點(diǎn)擊的產(chǎn)品數(shù)據(jù)等日志數(shù)據(jù)信息收集并移交給Hadoop平臺(tái)上去分析.而Flume正是幫我們做到這一點(diǎn)∈笾ぃ現(xiàn)在流行的內(nèi)容推送峡竣，比如廣告定點(diǎn)投放以及新聞私人定制也是基于次，不過不一定是使用FLume,畢竟優(yōu)秀的產(chǎn)品很多量九，比如facebook的Scribe适掰，還有Apache新出的另一個(gè)明星項(xiàng)目chukwa颂碧，還有淘寶Time Tunnel。
8.3.4. 架構(gòu)
flume之所這么神奇类浪，是源于它自身的一個(gè)設(shè)計(jì)载城，這個(gè)設(shè)計(jì)就是agent，agent本身是一個(gè)java進(jìn)程费就，運(yùn)行在日志收集節(jié)點(diǎn)—所謂日志收集節(jié)點(diǎn)就是服務(wù)器節(jié)點(diǎn)诉瓦。
agent里面包含3個(gè)核心的組件：source—->channel—–>sink,類似生產(chǎn)者、倉庫力细、消費(fèi)者的架構(gòu)睬澡。
source：source組件是專門用來收集數(shù)據(jù)的，可以處理各種類型眠蚂、各種格式的日志數(shù)據(jù),包括avro煞聪、thrift、exec逝慧、jms昔脯、spooling directory、netcat笛臣、sequence generator云稚、syslog、http捐祠、legacy碱鳞、自定義。
channel：source組件把數(shù)據(jù)收集來以后踱蛀，臨時(shí)存放在channel中窿给，即channel組件在agent中是專門用來存放臨時(shí)數(shù)據(jù)的——對采集到的數(shù)據(jù)進(jìn)行簡單的緩存，可以存放在memory率拒、jdbc崩泡、file等等。
sink：sink組件是用于把數(shù)據(jù)發(fā)送到目的地的組件猬膨，目的地包括hdfs角撞、logger、avro勃痴、thrift谒所、ipc、file沛申、null劣领、hbase、solr铁材、自定義尖淘。
8.3.5. Flume優(yōu)點(diǎn)
1. Flume可以將應(yīng)用產(chǎn)生的數(shù)據(jù)存儲(chǔ)到任何集中存儲(chǔ)器中奕锌，比如HDFS,HBase
2. 當(dāng)收集數(shù)據(jù)的速度超過將寫入數(shù)據(jù)的時(shí)候，也就是當(dāng)收集信息遇到峰值時(shí)村生，這時(shí)候收集的信息非常大惊暴，甚至超過了系統(tǒng)的寫入數(shù)據(jù)能力，這時(shí)候趁桃，F(xiàn)lume會(huì)在數(shù)據(jù)生產(chǎn)者和數(shù)據(jù)收容器間做出調(diào)整辽话，保證其能夠在兩者之間提供一共平穩(wěn)的數(shù)據(jù).
3. 提供上下文路由特征
4. Flume的管道是基于事務(wù)，保證了數(shù)據(jù)在傳送和接收時(shí)的一致性.
5. Flume是可靠的卫病，容錯(cuò)性高的屡穗，可升級(jí)的，易管理的,并且可定制的忽肛。
