大数据技术原理与应用学习笔记（八）
大數(shù)據(jù)技術(shù)原理與應(yīng)用學(xué)習(xí)筆記（八）
- 本系列歷史文章
- Hadoop再探討
- Hadoop的優(yōu)化與發(fā)展
- Hadoop1.0到Hadoop2.0
- 不斷完善的Hadoop生態(tài)系統(tǒng)
- HDFS2.0新特性
- HDFS HA（高可用性）
- HDFS Federation
- YARN——新一代資源管理調(diào)度框架
- MapReduce1.0中的缺陷
- YARN設(shè)計(jì)思路
- YARN體系結(jié)構(gòu)
- ResourceManager
- ApplicationMaster
- NodeManager
- YARN的工作流程
- 與MapReduce1.0的對(duì)比
- YARN的發(fā)展目標(biāo)
- Hadoop生態(tài)系統(tǒng)中具有代表性的功能組件
- Pig
- Pig的概念與特點(diǎn)
- Pig的應(yīng)用場(chǎng)景
- Tez
- Tez的概念與特點(diǎn)
- Spark和Kafka
- Spark
- Kafka
本系列歷史文章
大數(shù)據(jù)技術(shù)原理與應(yīng)用學(xué)習(xí)筆記（一）
大數(shù)據(jù)技術(shù)原理與應(yīng)用學(xué)習(xí)筆記（二）
大數(shù)據(jù)技術(shù)原理與應(yīng)用學(xué)習(xí)筆記（三）
大數(shù)據(jù)技術(shù)原理與應(yīng)用學(xué)習(xí)筆記（四）
大數(shù)據(jù)技術(shù)原理與應(yīng)用學(xué)習(xí)筆記（五）
大數(shù)據(jù)技術(shù)原理與應(yīng)用學(xué)習(xí)筆記（六）
大數(shù)據(jù)技術(shù)原理與應(yīng)用學(xué)習(xí)筆記（七）
Hadoop再探討
Hadoop的優(yōu)化與發(fā)展
在Hadoop1.0中仍存在很多不足：
- 抽象層次低，需人工編碼
- 表達(dá)能力有限
- 開發(fā)著自己管理Job間的依賴關(guān)系
- 難以看到程序的整體邏輯
- 執(zhí)行迭代效率低
- 資源浪費(fèi)
- 實(shí)時(shí)性差
采取的改進(jìn)措施如下： - 改進(jìn)自身的核心組件（MapReduce和HDFS）
- 其他組件的不斷豐富（Pig、Tez、Spark、Kafka）
Hadoop1.0到Hadoop2.0
Hadoop更新到2.0后，以下方面做出了很大更新：
HDFS：
- 由原來(lái)的單一名稱節(jié)點(diǎn)（存在單點(diǎn)失效問題），增添設(shè)計(jì)了HDFS HA，提供名稱節(jié)點(diǎn)熱備份機(jī)制；
- 由原來(lái)的單一命名空間（存在無(wú)法實(shí)現(xiàn)資源管理），增添設(shè)計(jì)了HDFS Federation來(lái)管理多個(gè)命名空間。
MapReduce： - 由原來(lái)的資源管理效率低，增添設(shè)計(jì)了管理框架YARN。
不斷完善的Hadoop生態(tài)系統(tǒng)
在Hadoop的優(yōu)化和發(fā)展中，越來(lái)越多的組件被包含在Hadoop生態(tài)系統(tǒng)中，使得Hadoop平臺(tái)的性能提升許多。
| Pig | 處理大規(guī)模數(shù)據(jù)的腳本語(yǔ)言，用戶只需編寫幾條語(yǔ)句，系統(tǒng)會(huì)自動(dòng)轉(zhuǎn)換為MapReduce作業(yè)（可用來(lái)解決需人工編碼的不足） |
| Spark | 基于內(nèi)存的分布式并行編程框架，具有較高的實(shí)時(shí)性，并且較好的支持迭代計(jì)算（可用來(lái)解決迭代效率低的不足） |
| Oozie | 工作流和協(xié)作服務(wù)引擎，協(xié)調(diào)Hadoop上運(yùn)行的不同任務(wù)（解決開發(fā)者自己管理Job間依賴關(guān)系的不足） |
| Tez | 支持DAG作業(yè)的計(jì)算，對(duì)作業(yè)的操作進(jìn)行重新分解和組合，形成DAG作業(yè)，減少不必要的操作（解決重復(fù)操作的不足） |
| Kafka | 分布式發(fā)布訂閱消息系統(tǒng)，一般作為企業(yè)大數(shù)據(jù)分析平臺(tái)的數(shù)據(jù)交換樞紐，不同類型的分布式系統(tǒng)可以接入到Kafka，實(shí)現(xiàn)和Hadoop各組件之間不同類型數(shù)據(jù)的實(shí)時(shí)高效交換（解決了Hadoop組件和其他產(chǎn)品間缺乏統(tǒng)一、搞笑的數(shù)據(jù)交換中介） |
HDFS2.0新特性
HDFS HA（高可用性）
HDFS HA（High Availability）是為了解決單點(diǎn)故障問題。HA集群設(shè)置兩個(gè)名稱節(jié)點(diǎn)，“活躍（Active）”和“待命（Standby）”。兩種名稱節(jié)點(diǎn)的狀態(tài)同步，可以借助于一個(gè)共享存儲(chǔ)系統(tǒng)來(lái)實(shí)現(xiàn)。一旦活躍名稱節(jié)點(diǎn)出現(xiàn)故障，就可以立即切換到待命名稱節(jié)點(diǎn)。Zookeeper確保一個(gè)名稱節(jié)點(diǎn)在對(duì)外服務(wù)。名稱節(jié)點(diǎn)維護(hù)映射信息，數(shù)據(jù)節(jié)點(diǎn)同時(shí)向兩個(gè)名稱節(jié)點(diǎn)匯報(bào)信息。
HDFS Federation
在Hadoop1.0中，仍然存在以下問題：
- 不可水平擴(kuò)展；
- 單點(diǎn)故障（由HDFS HA解決）；
- 系統(tǒng)整體性能受單個(gè)名稱節(jié)點(diǎn)吞吐量限制；
- 單個(gè)名稱節(jié)點(diǎn)難以提供不同程序間隔離性。
由此設(shè)計(jì)出了HDFS Federation，其設(shè)計(jì)了多個(gè)相互獨(dú)立的名稱節(jié)點(diǎn)，使HDFS命名空間可以橫向擴(kuò)展，不是真正的分布式設(shè)計(jì)，但遠(yuǎn)低于分布式設(shè)計(jì)的復(fù)雜性等。
所有名稱節(jié)點(diǎn)共享底層數(shù)據(jù)節(jié)點(diǎn)的存儲(chǔ)資源，擁有多個(gè)獨(dú)立命名空間管理屬于自己的一組塊（塊池）。
采取客戶端掛載表訪問
比Hadoop1.0的優(yōu)勢(shì)：
- HDFS集群可擴(kuò)展性
- 系統(tǒng)整體性能高
- 良好的隔離性
YARN——新一代資源管理調(diào)度框架
MapReduce1.0中的缺陷
- 存在單點(diǎn)故障
- JobTracker“大包大攬”任務(wù)過(guò)重
- 容易出現(xiàn)內(nèi)存溢出
- 資源劃分不合理
YARN設(shè)計(jì)思路
將原來(lái)的JobTracker拆分（原Master端）
- 資源管理→ResourceManager
- 任務(wù)調(diào)度→ApplicationMaster
- 任務(wù)監(jiān)控→ApplicationMaster
YARN體系結(jié)構(gòu)
ResourceManager
- 處理客戶端請(qǐng)求
- 啟動(dòng)、監(jiān)控ApplicationMaster
- 資源分配與調(diào)度
- 監(jiān)控NodeManager
ApplicationMaster
- 為應(yīng)用程序申請(qǐng)資源，并分配給內(nèi)部任務(wù)
- 任務(wù)監(jiān)控、調(diào)度與容錯(cuò)
NodeManager
- 單個(gè)節(jié)點(diǎn)上的資源管理
- 處理來(lái)自ResourceManager的命令
- 處理來(lái)自ApplicationMaster的命令
YARN的工作流程
- 首先由用戶編寫客戶端應(yīng)用程序，向YARN提交；
- YARN中，ResourceManager 負(fù)責(zé)接受和處理來(lái)自客戶端的請(qǐng)求，為其分配一個(gè)容器，并在其中啟動(dòng)一個(gè)ApplicationMaster；
- 啟動(dòng)后，向ResourceManager注冊(cè)；
- ApplicationMaster輪詢向ResourceManager申請(qǐng)資源；
- ResourceManager以“容器”形式向ApplicationMaster申請(qǐng)資源；
- 在容器中啟動(dòng)任務(wù)（二次分配后）
- 各任務(wù)向ApplicationMaster匯報(bào)自己的狀態(tài)和進(jìn)度；
- 運(yùn)行完成后ApplicationMaster向ResourceManager的應(yīng)用程序管理器注銷并關(guān)閉自己。
與MapReduce1.0的對(duì)比
優(yōu)勢(shì)：
- YARN減少了中心服務(wù)功能ResourceManager的資源消耗
- YARN是純粹的資源調(diào)度管理框架
- YARN中的資源管理比MapReduce1.0更加高效
YARN的發(fā)展目標(biāo)
實(shí)現(xiàn) “一個(gè)集群，多個(gè)框架” 。
Hadoop生態(tài)系統(tǒng)中具有代表性的功能組件
Pig
Pig的概念與特點(diǎn)
- 提供了類似SQL的Pig Latin語(yǔ)言，允許用戶通過(guò)編寫簡(jiǎn)單的腳本來(lái)實(shí)現(xiàn)復(fù)雜的數(shù)據(jù)分析，而不需要編寫復(fù)雜的MapReduce應(yīng)用程序
- Pig會(huì)自動(dòng)把用戶編寫的腳本轉(zhuǎn)換成MapReduce作業(yè)在Hadoop集群上運(yùn)行，而且具備對(duì)生成的MapReduce程序進(jìn)行自動(dòng)優(yōu)化的功能（用戶在編寫Pig程序的時(shí)候，不需要關(guān)心程序的運(yùn)行效率，這就大大減少了用戶編程時(shí)間）
- 通過(guò)配合使用Pig和Hadoop，在處理海量數(shù)據(jù)時(shí)就可以實(shí)現(xiàn)事半功倍的效果，比使用Java、C++等語(yǔ)言編寫MapReduce程序的難度要小很多，并且用更少的代碼量實(shí)現(xiàn)了相同的數(shù)據(jù)處理分析功能
Pig的應(yīng)用場(chǎng)景
- 數(shù)據(jù)查詢只面向相關(guān)技術(shù)人員
- 即時(shí)性的數(shù)據(jù)處理需求，這樣可以通過(guò)pig很快寫一個(gè)腳本開始運(yùn)行處理，而不需要?jiǎng)?chuàng)建表等相關(guān)的事先準(zhǔn)備工作
Tez
Tez的概念與特點(diǎn)
- Tez是Apache開源的支持DAG作業(yè)的計(jì)算框架，它直接源于MapReduce框架
- 核心思想是將Map和Reduce兩個(gè)操作進(jìn)一步拆分（Map被拆分成Input、Processor、Sort、Merge和Output） Reduce被拆分成Input、Shuffle、Sort、Merge、Processor和Output等
- 分解后的元操作可以任意靈活組合，產(chǎn)生新的操作。這些操作經(jīng)過(guò)一些控制程序組裝后，可形成一個(gè)大的DAG作業(yè)
- 通過(guò)DAG作業(yè)的方式運(yùn)行MapReduce作業(yè)，提供了程序運(yùn)行的整體處理邏輯，就可以去除工作流當(dāng)中多余的Map階段，減少不必要的操作，提升數(shù)據(jù)處理的性能
Spark和Kafka
Spark
Spark最初誕生于伯克利大學(xué)的APM實(shí)驗(yàn)室，是一個(gè)可應(yīng)用于大規(guī)模數(shù)據(jù)處理的快速、通用引擎，如今是Apache軟件基金會(huì)下的頂級(jí)開源項(xiàng)目之一。Spark在借鑒Hadoop MapReduce優(yōu)點(diǎn)的同時(shí)，很好地解決了MapReduce所面臨的問題。Spark最大的特點(diǎn)是內(nèi)存計(jì)算，帶來(lái)了更高的迭代運(yùn)算效率
其基于DAG的任務(wù)調(diào)度執(zhí)行機(jī)制，優(yōu)于MapReduce的迭代執(zhí)行機(jī)制。所以當(dāng)前，Spark正以其結(jié)構(gòu)一體化、功能多元化的優(yōu)勢(shì)，逐漸成為當(dāng)今大數(shù)據(jù)領(lǐng)域最熱門的大數(shù)據(jù)計(jì)算平臺(tái)。關(guān)于Spark后面的學(xué)習(xí)筆記還會(huì)提到。
Kafka
Kafka是一種高吞吐量的分布式發(fā)布訂閱消息系統(tǒng)，用戶通過(guò)Kafka系統(tǒng)可以發(fā)布大量的消息，同時(shí)也能實(shí)時(shí)訂閱消費(fèi)消息。Kafka可以同時(shí)滿足在線實(shí)時(shí)處理和批量離線處理。
總結(jié)
以上是生活随笔為你收集整理的大数据技术原理与应用学习笔记（八）的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 提取字典的子集
- 下一篇： java 常见bug_java常见bug