《大数据技术原理与应用》林子雨(第二版)--总结
廈大子雨老師的這本書內(nèi)容不多，但是很全面，推薦適合大數(shù)據(jù)入門。本篇文章主要是自己根據(jù)書中內(nèi)容，以QA的形式做下總結(jié)，且對書后答案做了解答。
文章目錄
- 第一篇 大數(shù)據(jù)基礎(chǔ)
- 大數(shù)據(jù)處理架構(gòu)Hadoop
- 1. 試述 hadoop 和谷歌的 mapreduce、gfs 等技術(shù)之間的關(guān)系
- 2. 試述 Hadoop 具有哪些特性。
- 3. 試述 Hadoop 在各個(gè)領(lǐng)域的應(yīng)用情況。
- 4. 試述 Hadoop 生態(tài)系統(tǒng)以及每個(gè)部分的具體功能
- 5. 配置Hadoop時(shí)，Java的路徑JAVA_HOME是在哪一個(gè)配置文件中進(jìn)行設(shè)置的？
- 6. 所有節(jié)點(diǎn)的HDFS路徑是通過fs.default.name來設(shè)置的，請問它是在哪個(gè)配置文件中設(shè)置的？
- 7. 試著列舉單機(jī)模式和偽分布模式的異同點(diǎn)。
- 8. Hadoop偽分布式運(yùn)行啟動(dòng)后所具有的進(jìn)程都有哪些？
- 第二篇 大數(shù)據(jù)存儲(chǔ)與管理
- 分布式文件系統(tǒng)HDFS
- 1. 什么是分布式文件系統(tǒng)？
- 2. 分布式文件系統(tǒng)結(jié)構(gòu)有什么特點(diǎn)，且是如何實(shí)現(xiàn)高水平擴(kuò)展的？
- 3. HDFS如何保證節(jié)點(diǎn)可能出現(xiàn)故障的情況？
- 4. 試述 HDFS 中的塊和普通文件系統(tǒng)中的塊的區(qū)別。
- 5. 試述 HDFS 中的名稱節(jié)點(diǎn)和數(shù)據(jù)節(jié)點(diǎn)的具體功能。
- 6. 為什么HDFS不適合存儲(chǔ)大量小文件？
- 7. 在分布式文件系統(tǒng)中，中心節(jié)點(diǎn)的設(shè)計(jì)至關(guān)重要，請闡述HDFS是如何減輕中心節(jié)點(diǎn)的負(fù)擔(dān)的？
- 8. HDFS只設(shè)置唯一一個(gè)主節(jié)點(diǎn)，在簡化系統(tǒng)設(shè)計(jì)的同時(shí)也帶來了一些明顯的局限性，請闡述局限性具體表現(xiàn)在哪些方面？
- 9. 試述HDFS的冗余數(shù)據(jù)保存策略。
- 10. 數(shù)據(jù)復(fù)制主要是在數(shù)據(jù)寫入和數(shù)據(jù)恢復(fù)時(shí)發(fā)生，HDFS數(shù)據(jù)復(fù)制是采用流水線復(fù)制的策略，請闡述該策略的細(xì)節(jié)。
- 11. HDFS是如何探測錯(cuò)誤發(fā)生以及如何進(jìn)行恢復(fù)的？
- 12. 闡述HDFS在不發(fā)生故障的情況下讀文件的過程。
- 13. 闡述HDFS在不發(fā)生故障的情況下寫文件的過程。
- 分布式數(shù)據(jù)庫HBase
- 1. 試述在 Hadoop 體系架構(gòu)中 HBase 與其他組成部分的相互關(guān)系。
- 2. 請闡述 HBase 和 BigTable 的底層技術(shù)的對應(yīng)關(guān)系
- 3. 請闡述 HBase 和傳統(tǒng)關(guān)系數(shù)據(jù)庫的區(qū)別
- 4. 說明 HBase 數(shù)據(jù)模型。
- 5. 分別解釋 HBase 中行鍵、列鍵和時(shí)間戳的概念
- 6. 闡述 HBase 的概念視圖和物理視圖的不同
- 7. 試述 HBase 各功能組建及其作用
- 8. 闡述 HBase 的數(shù)據(jù)分區(qū)機(jī)制。
- 9. HBase 中的分區(qū)是如何定位的。
- 10. 試述 HBase 的三層結(jié)構(gòu)中各層次的名稱和作用。
- 11. 闡述 HBase 的三層結(jié)構(gòu)下，客戶端是如何訪問到數(shù)據(jù)的。
- 12. 試述 HBase 系統(tǒng)基本架構(gòu)以及每個(gè)組成部分的作用。
- 13. 請闡述 Region 服務(wù)器向 HDFS 文件系統(tǒng)中讀寫數(shù)據(jù)的基本原理
- 14. 試述 HStore 的工作原理
- 15. 試述 HLog 的工作原理
- 16. 在 HBase 中，每個(gè) Region 服務(wù)器維護(hù)一個(gè) HLog，而不是為每個(gè) Region 都單獨(dú)維護(hù)一個(gè) HLog。請說明這種做法的優(yōu)缺點(diǎn)。
- 17. 當(dāng)一臺 Region 服務(wù)器意外終止時(shí)，Master 如何發(fā)現(xiàn)這種意外終止情況？為了恢復(fù)這臺發(fā)生意外的 Region 服務(wù)器上的 Region,Master 應(yīng)該做出哪些處理 (包括如何使用 HLog 進(jìn)行恢復(fù))?
- 18. 行式存儲(chǔ)和列式存儲(chǔ)的區(qū)別是什么？
- 19. HBase是列式存儲(chǔ)數(shù)據(jù)庫嗎？
- NoSQL數(shù)據(jù)庫
- 1. NoSQL 數(shù)據(jù)庫的四大類型，并解釋其含義。
- 2. 試述 CAP 理論的具體含義。
- 3. 試述數(shù)據(jù)庫的 ACID 四性的含義
- 4. 請解釋軟狀態(tài)、無狀態(tài)、硬狀態(tài)的具體含義。
- 5. 試述不一致性窗口的含義。
- 第三章 大數(shù)據(jù)處理與分析
- MapReduce
- 1. MapReduce 模型采用 Master(JobTracker)-Slave(TaskTracker) 結(jié)構(gòu)，試描述 JobTracker 和 TasKTracker 的功能。
- 2. TaskTracker出現(xiàn)故障會(huì)有什么影響？該故障是如何處理的？
- 3. MapReduce計(jì)算模型的核心是Map函數(shù)和Reduce函數(shù)，試述這兩個(gè)函數(shù)各自的輸入，輸出以及處理過程。
- 4. 試述 MapReduce 的工作流程 (需包括提交任務(wù)、Map、Shuffle、Reduce 的過程)。
- 6. Shuffle過程是MapReduce工作流程的核心，試分析Shuffle過程的作用。
- 7. 分別描述Map端和Reduce端的Shuffle過程(需包括spill、Sort、Merge、Fetch的過程)
- 8. MapReduce 中有這樣一個(gè)原則: 移動(dòng)計(jì)算比移動(dòng)數(shù)據(jù)更經(jīng)濟(jì)。試述什么是本地計(jì)算，并分析為何要采用本地計(jì)算。
- 9. 試說明一個(gè) MapReduce 程序在運(yùn)行期間，所啟動(dòng)的 Map 任務(wù)數(shù)量和 Reduce 任務(wù)數(shù)量各是由什么因素決定的。
- 10. 是否所有的 MapReduce 程序都需要經(jīng)過 Map 和 Reduce 這兩個(gè)過程? 如果不是，請舉例說明。
- 11. 分析為何采用 Combiner 可以減少數(shù)據(jù)傳輸量? 是否所有的 MapReduce 程序都可以采用 Combiner? 為什么?
- 12. MapReduce 程序的輸入文件、輸出文件都存儲(chǔ)在 HDFS 中，而在 Map 任務(wù)完成時(shí)的中間結(jié)果則存儲(chǔ)在本地磁盤中。試分析中間結(jié)果存儲(chǔ)在本地磁盤而不是 HDFS 上有何優(yōu)缺點(diǎn)？
- 13. 早期版本的HDFS，其默認(rèn)塊大小為64MB，而較新版本默認(rèn)為128MB，采用較大的塊具有什么影響和優(yōu)缺點(diǎn)？
- 14. 試著畫出使用MapReduce來對英語句子“Whatever is worth doing is worth doing well”進(jìn)行單詞統(tǒng)計(jì)的過程。
- 15. 在基于MapReduce的單詞統(tǒng)計(jì)中，MapReduce是如何保證相同的單詞數(shù)據(jù)會(huì)劃分到同一個(gè)Reducer上進(jìn)行處理以保證結(jié)果的正確性？
- Hadoop再探討
- 1. HDFS1.0 中只包含一個(gè)名稱節(jié)點(diǎn)會(huì)帶來哪些問題(單點(diǎn)故障問題)。
- 2. 請描述 HDFS HA 架構(gòu)組成組建及其具體功能。
- 3. 請分析 HDFS HA 架構(gòu)中數(shù)據(jù)節(jié)點(diǎn)如何和名稱節(jié)點(diǎn)保持通信。
- 4. 為什么需要HDFS聯(lián)邦，它能解決什么問題？
- 5. 描述HDFS 聯(lián)邦中 “塊池” 的概念，分析為什么 HDFS 聯(lián)邦中的一個(gè)名稱節(jié)點(diǎn)失效，也不會(huì)影響到與它相關(guān)的數(shù)據(jù)節(jié)點(diǎn)繼續(xù)為其他名稱節(jié)點(diǎn)提供服務(wù)。
- 6. 請闡述 MapReduce1.0 體系結(jié)構(gòu)中存在的問題。
- 7. 請描述 YARN 架構(gòu)中各組件的功能。
- 8. YARN 框架中執(zhí)行一個(gè) MapReduce 程序時(shí)，從提交到完成需要經(jīng)歷的具體步驟。
- 9. 請對 YARN 和 MapReduce1.0 框架進(jìn)行優(yōu)劣勢對比分析。
- 10. 請分別描述 Pig、Tez 和 Kafka 的功能。
- Spark
- 1. 闡述如下 Spark 的幾個(gè)主要概念：RDD、DAG、階段、分區(qū)、窄依賴、寬依賴。
第一篇 大數(shù)據(jù)基礎(chǔ)
大數(shù)據(jù)處理架構(gòu)Hadoop
1. 試述 hadoop 和谷歌的 mapreduce、gfs 等技術(shù)之間的關(guān)系
Hadoop 的核心是分布式文件系統(tǒng) HDFS 和 MapReduce。HDFS 是谷歌文件系統(tǒng) GFS 的開源實(shí)現(xiàn)，具有較高的讀寫速度、很好的容錯(cuò)性和可伸縮性，支持大規(guī)模數(shù)據(jù)的分布式存儲(chǔ)。MapReduces 是針對谷歌 MapReduce 的開源實(shí)現(xiàn)，允許用戶在不了解分布式系統(tǒng)底層細(xì)節(jié)的情況下開發(fā)并行應(yīng)用程序，采用MapReduce來整合分布式文件系統(tǒng)上的數(shù)據(jù)，可保證分析和處理數(shù)據(jù)的高效性。
2. 試述 Hadoop 具有哪些特性。
① 高可靠性(采用冗余數(shù)據(jù)存儲(chǔ)方式，一個(gè)副本宕機(jī)時(shí)，其他副本也可以正常對外服務(wù))；
② 高效性
③ 高可擴(kuò)展性
④ 高容錯(cuò)性
⑤ 成本低
3. 試述 Hadoop 在各個(gè)領(lǐng)域的應(yīng)用情況。
2007 年，雅虎在 Sunnyvale 總部建立了 M45——一個(gè)包含了 4000 個(gè)處理器和 1.5PB 容量的 Hadooop 集群系統(tǒng)；
Facebook主要將 Hadoop 平臺用于日志處理，推薦系統(tǒng)和數(shù)據(jù)倉庫等方面；
百度主要使用 Hadoop 于日志的存儲(chǔ)和統(tǒng)計(jì)、網(wǎng)頁數(shù)據(jù)的分析和挖掘、商業(yè)分析、在線數(shù)據(jù)反饋、網(wǎng)頁聚類等。
4. 試述 Hadoop 生態(tài)系統(tǒng)以及每個(gè)部分的具體功能
Hadoop生態(tài)系統(tǒng)包括：Ambari(安裝、部署、配置和管理工具)，zookeeper(分布式協(xié)作服務(wù))，HBase(分布式數(shù)據(jù)庫)，Hive(數(shù)據(jù)倉庫)，Pig(數(shù)據(jù)流處理)，Mahout(數(shù)據(jù)挖掘庫)，MapReduce(分布式計(jì)算框架)，YARN(資源調(diào)度和管理框架)，HDFS(分布式文件系統(tǒng))，Flume(日志收集)，Sqoop(數(shù)據(jù)庫ETL)。
其中每個(gè)部分的具體功能如下：
HDFS 是 Hadoop 項(xiàng)目的兩個(gè)核心之一，它是針對谷歌文件系統(tǒng)的開源實(shí)現(xiàn)。其放寬了一部分POSIX約束，從而實(shí)現(xiàn)以流的方式訪問文件系統(tǒng)中的數(shù)據(jù)。
HBase 是一個(gè)提高可靠性、高性能、可伸縮、實(shí)時(shí)讀寫、分布式的列式數(shù)據(jù)庫，一般采用 HDFS 作為其底層數(shù)據(jù)存儲(chǔ)。
MapReduce是一種編程模型， 是針對谷歌 MapReduce 的開源實(shí)現(xiàn)，用于大規(guī)模數(shù)據(jù)集的并行運(yùn)算。核心思想是分而治之，把輸入的數(shù)據(jù)集切分為若干獨(dú)立的數(shù)據(jù)塊，分發(fā)給一個(gè)主節(jié)點(diǎn)管理下的各個(gè)分節(jié)點(diǎn)來共同并行完成，最后通過整合各個(gè)節(jié)點(diǎn)的中間結(jié)果得到最終結(jié)果。
Hive 是一個(gè)基于 Hadoop 的數(shù)據(jù)倉庫工具，可以用于對 Hadoop 文件中的數(shù)據(jù)集進(jìn)行數(shù)據(jù)整理、特殊查詢和分布存儲(chǔ)。
Mahout的功能主要是提供一些可擴(kuò)展的機(jī)器學(xué)習(xí)領(lǐng)域經(jīng)典算法的實(shí)現(xiàn)，目的是幫助開發(fā)人員更加方便快捷的創(chuàng)建智能應(yīng)用程序。
Pig 是一種數(shù)據(jù)流語言和運(yùn)行環(huán)境，適合于使用 Hadoop 和 MapReducce 平臺上查詢大型半結(jié)構(gòu)化數(shù)據(jù)集。
Zoookepper 是針對谷歌 Chubby 的一個(gè)開源實(shí)現(xiàn)，是高效和可靠的協(xié)同工作系統(tǒng)，提供分布式鎖之類的基本服務(wù)，用于構(gòu)建分布式應(yīng)用，減輕分布式應(yīng)用程序所承擔(dān)的協(xié)調(diào)任務(wù)。
Flume的功能是在日志系統(tǒng)中定制各類數(shù)據(jù)的發(fā)送方用于收集數(shù)據(jù)，同時(shí)提供對數(shù)據(jù)進(jìn)行簡單處理并寫到各種數(shù)據(jù)接收方的能力。
Sqoop用來在Hadoop和關(guān)系數(shù)據(jù)庫之間交換數(shù)據(jù)，可以改進(jìn)數(shù)據(jù)的互操作性。
Ambari支持Hadoop集群的安裝，部署配置和管理。
5. 配置Hadoop時(shí)，Java的路徑JAVA_HOME是在哪一個(gè)配置文件中進(jìn)行設(shè)置的？
在安裝Hadoop時(shí)，Hadoop文件夾中的"etc/hadoop"目錄下的hadoop-env.sh文件，將JAVA_HOME環(huán)境變量指定到本機(jī)的JDK目錄即可。
$export JAVA_HOME=/usr/lib/jvm/default-java6. 所有節(jié)點(diǎn)的HDFS路徑是通過fs.default.name來設(shè)置的，請問它是在哪個(gè)配置文件中設(shè)置的？
在conf/core-site.xml中設(shè)置，core-site是用來配置HDFS和MapReduce常用的I/O設(shè)置等。
7. 試著列舉單機(jī)模式和偽分布模式的異同點(diǎn)。
相同點(diǎn)：偽分布式安裝是指在一臺機(jī)器上模擬一個(gè)小的集群，但是集群中只有一個(gè)節(jié)點(diǎn)。單機(jī)模式同樣是在一臺機(jī)器上完成部署，因此相同點(diǎn)是都在一臺機(jī)器上。
不同點(diǎn)：單機(jī)hadoop無需進(jìn)行配置，偽分布式需要通過配置文件來對各個(gè)組件的協(xié)同工作進(jìn)行設(shè)置；單機(jī)模式是在本地的文件系統(tǒng)， 偽分布式需要將本地文件上傳到HDFS的文件夾中(無需網(wǎng)絡(luò)，因?yàn)槎荚谕慌_機(jī)器)。
8. Hadoop偽分布式運(yùn)行啟動(dòng)后所具有的進(jìn)程都有哪些？
6個(gè)進(jìn)程：NodeManager，jps，NameNode，SecondaryNameNode，DataNode，ResourceManager。
第二篇 大數(shù)據(jù)存儲(chǔ)與管理
本章主要介紹大數(shù)據(jù)存儲(chǔ)與管理的相關(guān)技術(shù)，主要包括：HDFS，分布式數(shù)據(jù)庫HBase，NoSQL數(shù)據(jù)庫和云數(shù)據(jù)庫。
HDFS提供了服務(wù)器集群中進(jìn)行大規(guī)模分布式文件存儲(chǔ)的能力，HBase是一個(gè)分布式數(shù)據(jù)庫，主要用來存儲(chǔ)非結(jié)構(gòu)化和半結(jié)構(gòu)化的松散數(shù)據(jù)，NoSQL支持超大規(guī)模的數(shù)據(jù)存儲(chǔ)，云數(shù)據(jù)庫是部署在云環(huán)境的數(shù)據(jù)庫。
本章重點(diǎn)在于：分布式文件系統(tǒng)及分布式數(shù)據(jù)庫的實(shí)現(xiàn)原理和應(yīng)用方法，難點(diǎn)在HDFS存儲(chǔ)原理及HBase實(shí)現(xiàn)原理。
分布式文件系統(tǒng)HDFS
1. 什么是分布式文件系統(tǒng)？
分布式文件系統(tǒng)是一種通過網(wǎng)絡(luò)實(shí)現(xiàn)文件在多臺主機(jī)上進(jìn)行分布式存儲(chǔ)的文件系統(tǒng)。其設(shè)計(jì)一般采用“客戶機(jī)/服務(wù)器”模式，客戶端以特定的通信協(xié)議通過網(wǎng)絡(luò)與服務(wù)器建立連接，提出文件訪問請求，客戶端和服務(wù)器可以通過設(shè)置訪問權(quán)來限制請求方對底層數(shù)據(jù)存儲(chǔ)塊的訪問。
2. 分布式文件系統(tǒng)結(jié)構(gòu)有什么特點(diǎn)，且是如何實(shí)現(xiàn)高水平擴(kuò)展的？
① 普通文件系統(tǒng)的塊是512個(gè)字節(jié)，每次讀寫的數(shù)據(jù)量必須是磁盤塊的整數(shù)倍，分布式文件系統(tǒng)HDFS的一個(gè)塊默認(rèn)是64MB，如果一個(gè)文件小于一個(gè)數(shù)據(jù)塊的大小，它并不占用整個(gè)數(shù)據(jù)塊的存儲(chǔ)空間；
② 分布式系統(tǒng)的物理結(jié)構(gòu)上是由計(jì)算機(jī)集群的多個(gè)節(jié)點(diǎn)構(gòu)成的，這些節(jié)點(diǎn)分別是主節(jié)點(diǎn)和從節(jié)點(diǎn)。
③ 為了保證數(shù)據(jù)的完整性，分布式文件系統(tǒng)通常采用多副本存儲(chǔ)。
3. HDFS如何保證節(jié)點(diǎn)可能出現(xiàn)故障的情況？
HDFS通常采用多副本存儲(chǔ)，文件塊會(huì)被復(fù)制為多個(gè)副本，存儲(chǔ)在不同的節(jié)點(diǎn)上，且存儲(chǔ)同一文件塊的不同副本的各個(gè)節(jié)點(diǎn)會(huì)分布在不同的機(jī)架上，這樣，在單個(gè)節(jié)點(diǎn)出現(xiàn)故障時(shí)，就可以快速調(diào)用副本重啟單個(gè)節(jié)點(diǎn)上的計(jì)算過程，而無需重啟整個(gè)計(jì)算過程，整個(gè)機(jī)架出現(xiàn)故障時(shí)也不會(huì)丟失所有文件塊。
4. 試述 HDFS 中的塊和普通文件系統(tǒng)中的塊的區(qū)別。
在傳統(tǒng)的文件系統(tǒng)中，為了提高磁盤讀寫效率，一般以數(shù)據(jù)塊為單位，而不是以字節(jié)為單位。 HDFS 中的塊，默認(rèn)一個(gè)塊大小為 64MB，而 HDFS 中的文件會(huì)被拆分成多個(gè)塊，每個(gè)塊作為獨(dú)立的單元進(jìn)行存儲(chǔ)。HDFS 在塊的大小的設(shè)計(jì)上明顯要大于普通文件系統(tǒng)。
5. 試述 HDFS 中的名稱節(jié)點(diǎn)和數(shù)據(jù)節(jié)點(diǎn)的具體功能。
主節(jié)點(diǎn)負(fù)責(zé)文件和目錄的創(chuàng)建刪除重命名，同時(shí)管理著從節(jié)點(diǎn)和文件塊的映射關(guān)系，因此客戶端只有訪問名稱節(jié)點(diǎn)才能找到請求的文件塊所在的位置，進(jìn)而到相應(yīng)位置讀取所需的文件塊。
從節(jié)點(diǎn)負(fù)責(zé)數(shù)據(jù)的存儲(chǔ)和讀取，存儲(chǔ)時(shí)由主節(jié)點(diǎn)分配存儲(chǔ)位置，然后由客戶端把數(shù)據(jù)直接寫入到相應(yīng)的從節(jié)點(diǎn)；在讀取時(shí)客戶端從主節(jié)點(diǎn)中獲得從節(jié)點(diǎn)和文件塊的映射關(guān)系，然后就可以到相應(yīng)位置訪問文件塊。
6. 為什么HDFS不適合存儲(chǔ)大量小文件？
① HDFS采用NameNode來管理文件系統(tǒng)的元數(shù)據(jù)，這些元數(shù)據(jù)被保存在內(nèi)存中，從而使客戶端可以快速的獲取文件實(shí)際存儲(chǔ)位置。但當(dāng)小文件比較多時(shí)，名稱節(jié)點(diǎn)要花大量的內(nèi)存來保存這些元數(shù)據(jù)信息，這樣會(huì)導(dǎo)致元數(shù)據(jù)的檢索效率變低；
② MapReduce處理大量小文件時(shí)，會(huì)產(chǎn)生過多的map任務(wù)，線程管理開銷會(huì)大大增加；
③ 訪問大量小文件的速度要遠(yuǎn)低于訪問幾個(gè)大文件的速度，因?yàn)樵L問小文件要不斷從一個(gè)數(shù)據(jù)節(jié)點(diǎn)跳到另一個(gè)數(shù)據(jù)節(jié)點(diǎn)，影響性能。
7. 在分布式文件系統(tǒng)中，中心節(jié)點(diǎn)的設(shè)計(jì)至關(guān)重要，請闡述HDFS是如何減輕中心節(jié)點(diǎn)的負(fù)擔(dān)的？
我認(rèn)為從兩個(gè)方面考慮：一個(gè)是HDFS的主從架構(gòu)，另一個(gè)是第二名稱節(jié)點(diǎn)。
首先HDFS采用了主從架構(gòu)模型，一個(gè)HDFS集群包括一個(gè)名稱節(jié)點(diǎn)和若干個(gè)數(shù)據(jù)節(jié)點(diǎn)。名稱節(jié)點(diǎn)作為中心服務(wù)器，負(fù)責(zé)管理文件系統(tǒng)的命名空間及客戶端對文件的訪問。數(shù)據(jù)節(jié)點(diǎn)一般是一個(gè)節(jié)點(diǎn)運(yùn)行一個(gè)數(shù)據(jù)節(jié)點(diǎn)進(jìn)程，負(fù)責(zé)處理文件系統(tǒng)客戶端的讀寫請求，在名稱節(jié)點(diǎn)的統(tǒng)一調(diào)度下進(jìn)行數(shù)據(jù)庫的創(chuàng)建、刪除和復(fù)制等操作。
其實(shí)是第二名稱節(jié)點(diǎn)，為了有效的解決EditLog逐漸變大帶來的問題，HDFS設(shè)計(jì)時(shí)采用了第二名稱節(jié)點(diǎn)，其可以完成EditLog和FsImage的合并操作，減小EditLog文件大小，縮短名稱節(jié)點(diǎn)的重啟時(shí)間。其次可以作為名稱節(jié)點(diǎn)的檢查點(diǎn)，來保存名稱節(jié)點(diǎn)的元數(shù)據(jù)信息。
8. HDFS只設(shè)置唯一一個(gè)主節(jié)點(diǎn)，在簡化系統(tǒng)設(shè)計(jì)的同時(shí)也帶來了一些明顯的局限性，請闡述局限性具體表現(xiàn)在哪些方面？
① 命名空間的限制。名稱節(jié)點(diǎn)是保存在內(nèi)存中的，因此名稱節(jié)點(diǎn)能夠容納對象(文件、塊)的個(gè)數(shù)會(huì)受到內(nèi)存空間大小的限制；
② 性能的瓶頸，整個(gè)分布式文件系統(tǒng)的吞吐量受限于單個(gè)名稱節(jié)點(diǎn)的吞吐量(單位時(shí)間內(nèi)成功地傳送數(shù)據(jù)的數(shù)量);
③ 隔離問題。只有一個(gè)命名空間無法對不同應(yīng)用程序進(jìn)行隔離；
9. 試述HDFS的冗余數(shù)據(jù)保存策略。
HDFS采用多副本的方法對數(shù)據(jù)進(jìn)行冗余存儲(chǔ)，通常一個(gè)數(shù)據(jù)塊的多個(gè)副本會(huì)被分布到不同的數(shù)據(jù)節(jié)點(diǎn)上。
10. 數(shù)據(jù)復(fù)制主要是在數(shù)據(jù)寫入和數(shù)據(jù)恢復(fù)時(shí)發(fā)生，HDFS數(shù)據(jù)復(fù)制是采用流水線復(fù)制的策略，請闡述該策略的細(xì)節(jié)。
HDFS的數(shù)據(jù)復(fù)制采用了流水線復(fù)制的策略，其顯著的提高了數(shù)據(jù)復(fù)制過程的效率：
① 當(dāng)客戶端往HDFS中寫入一個(gè)文件時(shí)，這個(gè)文件會(huì)首先被寫入本地，并被切分成若干個(gè)塊，每個(gè)塊的大小是由HDFS的設(shè)定值決定的；
② 每個(gè)塊向HDFS集群中的名稱節(jié)點(diǎn)發(fā)起寫請求，名稱節(jié)點(diǎn)會(huì)根據(jù)系統(tǒng)中各個(gè)數(shù)據(jù)節(jié)點(diǎn)的使用情況，選擇一個(gè)數(shù)據(jù)節(jié)點(diǎn)列表返回給客戶端；
③ 客戶端會(huì)把數(shù)據(jù)首先寫入列表中的第一個(gè)數(shù)據(jù)節(jié)點(diǎn)，同時(shí)把列表傳給第一個(gè)數(shù)據(jù)節(jié)點(diǎn)；
④ 當(dāng)?shù)谝粋€(gè)數(shù)據(jù)節(jié)點(diǎn)接收到4KB數(shù)據(jù)時(shí)，寫入本地，且向列表中的第二個(gè)數(shù)據(jù)節(jié)點(diǎn)發(fā)起連接請求，把自己已經(jīng)接收到的4KB數(shù)據(jù)和列表傳給第二個(gè)數(shù)據(jù)節(jié)點(diǎn)，當(dāng)?shù)诙€(gè)數(shù)據(jù)節(jié)點(diǎn)接收到4KB數(shù)據(jù)時(shí)，寫入本地，且向列表中第三個(gè)數(shù)據(jù)節(jié)點(diǎn)發(fā)送請求，一次類推，由列表中的多個(gè)數(shù)據(jù)節(jié)點(diǎn)形成一條數(shù)據(jù)復(fù)制的流水線，最后當(dāng)文件寫完時(shí)，數(shù)據(jù)復(fù)制完成。
11. HDFS是如何探測錯(cuò)誤發(fā)生以及如何進(jìn)行恢復(fù)的？
HDFS的錯(cuò)誤可以分為3種情況：名稱節(jié)點(diǎn)出錯(cuò)，數(shù)據(jù)節(jié)點(diǎn)出錯(cuò)以及數(shù)據(jù)出錯(cuò)。
① 名稱節(jié)點(diǎn)出錯(cuò)：名稱節(jié)點(diǎn)發(fā)生宕機(jī)(或者是FsImage和EditLog發(fā)生損壞)。首先到遠(yuǎn)程掛載的網(wǎng)絡(luò)文件系統(tǒng)種獲取備份的元數(shù)據(jù)信息，放到第二名稱節(jié)點(diǎn)上進(jìn)行恢復(fù)，并把第二名稱節(jié)點(diǎn)作為名稱節(jié)點(diǎn)來使用。
② 數(shù)據(jù)節(jié)點(diǎn)出錯(cuò)：數(shù)據(jù)節(jié)點(diǎn)發(fā)生故障或者斷網(wǎng)，從而導(dǎo)致數(shù)據(jù)節(jié)點(diǎn)無法定期向名稱節(jié)點(diǎn)發(fā)送心跳。名稱節(jié)點(diǎn)會(huì)定期檢查心跳，通過數(shù)據(jù)冗余復(fù)制來生產(chǎn)新的副本。
③ 數(shù)據(jù)出錯(cuò)：如何探測–文件被創(chuàng)建時(shí)，客戶端會(huì)對每一個(gè)文件塊進(jìn)行信息摘錄，并把這些信息寫入同一個(gè)路徑的隱藏文件里。當(dāng)客戶端讀取文件時(shí)，會(huì)先讀取該信息文件，然后利用該信息文件對每個(gè)讀取的數(shù)據(jù)塊進(jìn)行校驗(yàn)。如何恢復(fù)-- 當(dāng)校驗(yàn)出錯(cuò)時(shí)，客戶端會(huì)請求到另外一個(gè)數(shù)據(jù)節(jié)點(diǎn)讀取該文件塊，并向名稱節(jié)點(diǎn)報(bào)告這個(gè)文件塊有誤。
12. 闡述HDFS在不發(fā)生故障的情況下讀文件的過程。
① 打開文件：客戶端通過FileSystem.open()打開文件，調(diào)用open方法后，DistributedFileSystem會(huì)創(chuàng)建輸入流；
② 獲取數(shù)據(jù)塊信息：輸入流哦通過getBlockLocations方法獲得文件開始部分?jǐn)?shù)據(jù)塊的保存位置。對于該數(shù)據(jù)塊，名稱節(jié)點(diǎn)返回保存該數(shù)據(jù)庫的所有數(shù)據(jù)節(jié)點(diǎn)的地址，同時(shí)根據(jù)距離客戶端的遠(yuǎn)近對數(shù)據(jù)節(jié)點(diǎn)進(jìn)行排序，同時(shí)返回給客戶端數(shù)據(jù)塊的數(shù)據(jù)節(jié)點(diǎn)地址；
③ 讀取請求：客戶端調(diào)用read()函數(shù)開始讀取數(shù)據(jù)，輸入流根據(jù)前面的排序結(jié)果，選擇距離客戶端最近的數(shù)據(jù)節(jié)點(diǎn)建立連接并讀取數(shù)據(jù)；
④ 讀取數(shù)據(jù)：數(shù)據(jù)從該數(shù)據(jù)節(jié)點(diǎn)讀到客戶端；
⑤ 獲得數(shù)據(jù)塊信息：輸入流通過getBlockLocations()方法查找下一個(gè)數(shù)據(jù)塊(如果客戶端緩存中已經(jīng)包含了該數(shù)據(jù)塊的位置信息，就不需要調(diào)用該方法。)
⑥ 讀取數(shù)據(jù)：找到該數(shù)據(jù)塊的最佳數(shù)據(jù)節(jié)點(diǎn)(距離客戶端最近)，讀取數(shù)據(jù)；
⑦ 關(guān)閉文件：當(dāng)客戶端讀取完畢數(shù)據(jù)時(shí)，通過close函數(shù)關(guān)閉輸入流。
13. 闡述HDFS在不發(fā)生故障的情況下寫文件的過程。
① 創(chuàng)建文件請求：客戶端通過create方法創(chuàng)建文件輸出流；
② 創(chuàng)建文件元數(shù)據(jù)：輸出流通過RPC遠(yuǎn)程調(diào)用名稱節(jié)點(diǎn)，在文件系統(tǒng)的命名空間中創(chuàng)建一個(gè)新的文件，名稱節(jié)點(diǎn)會(huì)執(zhí)行一些檢查，通過后，會(huì)返回給客戶端使用這個(gè)輸出流來寫入數(shù)據(jù)；
③ 寫入數(shù)據(jù)：客戶端用輸出流的write方法向HDFS中對應(yīng)的文件寫入數(shù)據(jù)；
④ 寫入數(shù)據(jù)包：客戶端由輸出流寫入的數(shù)據(jù)會(huì)首先被分為一個(gè)個(gè)的分包，這些分包被放入DFSOutputStream對象的內(nèi)部隊(duì)列，輸出流FSDataOutputStream會(huì)向名稱節(jié)點(diǎn)申請保存文件和副本數(shù)據(jù)塊的若干個(gè)數(shù)據(jù)節(jié)點(diǎn)，這些數(shù)據(jù)節(jié)點(diǎn)形成一個(gè)數(shù)據(jù)流管道。按照流水線復(fù)制的方法，將數(shù)據(jù)包留經(jīng)管道上的各個(gè)數(shù)據(jù)節(jié)點(diǎn)。
⑤ 接受確認(rèn)包：接受到數(shù)據(jù)的數(shù)據(jù)節(jié)點(diǎn)需要向發(fā)送者發(fā)送確認(rèn)包，確認(rèn)包從管道一次經(jīng)故各個(gè)數(shù)據(jù)節(jié)點(diǎn)最終發(fā)往客戶端，當(dāng)客戶端收到應(yīng)答時(shí)，將對應(yīng)的分包從內(nèi)部隊(duì)列中清除，直到數(shù)據(jù)全部寫完；
⑥ 關(guān)閉文件：通知名稱節(jié)點(diǎn)關(guān)閉文件，完成一次正常的寫文件過程。
分布式數(shù)據(jù)庫HBase
1. 試述在 Hadoop 體系架構(gòu)中 HBase 與其他組成部分的相互關(guān)系。
HBase 利用 Hadoop MapReduce 來處理 HBase 中的海量數(shù)據(jù)，實(shí)現(xiàn)高性能計(jì)算；利用 Zookeeper 作為協(xié)同服務(wù)，實(shí)現(xiàn)穩(wěn)定服務(wù)和失敗恢復(fù)；使用 HDFS 作為高可靠的底層存儲(chǔ)，利用廉價(jià)集群提供海量數(shù)據(jù)存儲(chǔ)能力; Sqoop 為 HBase 的底層數(shù)據(jù)導(dǎo)入功能，Pig 和 Hive 為 HBase 提供了高層語言支持，HBase 是 BigTable 的開源實(shí)現(xiàn)。
2. 請闡述 HBase 和 BigTable 的底層技術(shù)的對應(yīng)關(guān)系
① 文件存儲(chǔ)系統(tǒng)：BigTable基于GFS，HBase基于HDFS；
② 海量數(shù)據(jù)處理：BigTable基于MapReduce，HBase基于Hadoop MapReduce；
③ 協(xié)同服務(wù)管理：BigTable基于Chubby，HBase基于Zookeeper；
3. 請闡述 HBase 和傳統(tǒng)關(guān)系數(shù)據(jù)庫的區(qū)別
①數(shù)據(jù)類型：關(guān)系數(shù)據(jù)庫采用關(guān)系模型，HBase采用數(shù)據(jù)模型。數(shù)據(jù)模型就是把數(shù)據(jù)存儲(chǔ)為未經(jīng)解釋的字符串，用戶可以將不同格式的結(jié)構(gòu)化數(shù)據(jù)和非結(jié)構(gòu)化數(shù)據(jù)都序列化成字符串保存在HBase中，然后通過自己的程序把字符串解析成不同的數(shù)據(jù)類型；
② 數(shù)據(jù)操作：關(guān)系數(shù)據(jù)庫中會(huì)涉及復(fù)雜的多表連接，HBase中通常只采用單表的主鍵查詢；
③ 存儲(chǔ)模式：關(guān)系數(shù)據(jù)庫基于行存儲(chǔ)，HBase基于列存儲(chǔ)。
4. 說明 HBase 數(shù)據(jù)模型。
關(guān)系數(shù)據(jù)庫通過行和列來確定表中一個(gè)具體的值，HBase中通過行鍵，列族，列限定符和時(shí)間戳來確定一個(gè)單元格。
5. 分別解釋 HBase 中行鍵、列鍵和時(shí)間戳的概念
① 行鍵是唯一的，在一個(gè)表里只出現(xiàn)一次，否則就是在更新同一行，行鍵可以是任意的字節(jié)數(shù)組。
② 列族需要在創(chuàng)建表的時(shí)候就定義好，數(shù)量也不宜過多。列族名必須由可打印字符組成，創(chuàng)建表的時(shí)候不需要定義好列。
③ 時(shí)間戳，默認(rèn)由系統(tǒng)指定，用戶也可以顯示設(shè)置。使用不同的時(shí)間戳來區(qū)分不同的版本。
6. 闡述 HBase 的概念視圖和物理視圖的不同
(沒總結(jié)好)
7. 試述 HBase 各功能組建及其作用
（1）庫函數(shù)：鏈接到每個(gè)客戶端；
（2）一個(gè) Master 主服務(wù)器：主服務(wù)器 Master 主要負(fù)責(zé)表和 Region 的管理工作；
（3）許多個(gè) Region 服務(wù)器：Region 服務(wù)器是 HBase 中最核心的模塊，負(fù)責(zé)維護(hù)分配給自己的 Region，并響應(yīng)用戶的讀寫請求
8. 闡述 HBase 的數(shù)據(jù)分區(qū)機(jī)制。
HBase 采用分區(qū)存儲(chǔ)，根據(jù)行鍵的值對表中的行進(jìn)行分區(qū)，每個(gè)行區(qū)間構(gòu)成一個(gè)分區(qū)，叫做Region。一個(gè)大的表會(huì)被分拆許多個(gè) Region，這些 Region 會(huì)被分發(fā)到不同的服務(wù)器上實(shí)現(xiàn)分布式存儲(chǔ)。
每個(gè)Region都有一個(gè)RegionID來標(biāo)識其唯一性。為了定位每個(gè)Region所在的位置，就可以構(gòu)建一張映射表，**映射表的每行包含兩項(xiàng)內(nèi)容：Region標(biāo)識符，及Region服務(wù)器標(biāo)識。**從而知道某個(gè)Region被保存在哪個(gè)Region服務(wù)器中，這個(gè)映射表被叫做".META.表"。
9. HBase 中的分區(qū)是如何定位的。
通過構(gòu)建的映射表的每個(gè)條目包含兩項(xiàng)內(nèi)容，一個(gè)是 Regionde 標(biāo)識符，另一個(gè)是 Region 服務(wù)器標(biāo)識，這個(gè)條目就標(biāo)識 Region 和 Region 服務(wù)器之間的對應(yīng)關(guān)系，從而就可以知道某個(gè) Region 被保存在哪個(gè) Region 服務(wù)器中。
10. 試述 HBase 的三層結(jié)構(gòu)中各層次的名稱和作用。
①第一層 Zookeeper 文件，記錄了 - ROOT - 表的位置信息；
② 第二層 -ROOT - 表，記錄了. META. 表的 Region 位置信息，-ROOT - 表只能有一個(gè) Region。通過 - ROOT - 表，就可以訪問. META. 表中的數(shù)據(jù)；
③ 第三層： .META. 表，記錄了用戶數(shù)據(jù)表的 Region 位置信息，.META. 表可以有多個(gè) Region，保存了 HBase 中所有用戶數(shù)據(jù)表的 Region 位置信息；
11. 闡述 HBase 的三層結(jié)構(gòu)下，客戶端是如何訪問到數(shù)據(jù)的。
首先訪問 Zookeeper，獲取 - ROOT 表的位置信息，然后訪問 - Root - 表，獲得. MATA. 表的信息，接著訪問. MATA. 表，找到所需的 Region 具體位于哪個(gè) Region 服務(wù)器，最后才會(huì)到該 Region 服務(wù)器讀取數(shù)據(jù)。
12. 試述 HBase 系統(tǒng)基本架構(gòu)以及每個(gè)組成部分的作用。
（1）客戶端
客戶端包含訪問 HBase 的接口，同時(shí)在緩存中維護(hù)著已經(jīng)訪問過的 Region 位置信息，用來加快后續(xù)數(shù)據(jù)訪問過程
（2）Zookeeper 服務(wù)器
Zookeeper 可以幫助選舉出一個(gè) Master 作為集群的總管，并保證在任何時(shí)刻總有唯一一個(gè) Master 在運(yùn)行，這就避免了 Master 的 “單點(diǎn)失效” 問題
（3）Master
主服務(wù)器 Master 主要負(fù)責(zé)表和 Region 的管理工作：管理用戶對表的增加、刪除、修改、查詢等操作；實(shí)現(xiàn)不同 Region 服務(wù)器之間的負(fù)載均衡；在 Region 分裂或合并后，負(fù)責(zé)重新調(diào)整 Region 的分布；對發(fā)生故障失效的 Region 服務(wù)器上的 Region 進(jìn)行遷移
（4）Region 服務(wù)器
Region 服務(wù)器是 HBase 中最核心的模塊，負(fù)責(zé)維護(hù)分配給自己的 Region，并響應(yīng)用戶的讀寫請求；
13. 請闡述 Region 服務(wù)器向 HDFS 文件系統(tǒng)中讀寫數(shù)據(jù)的基本原理
Region 服務(wù)器內(nèi)部管理了一系列 Region 對象和一個(gè) HLog 文件，其中，HLog 是磁盤上面的記錄文件，它記錄著所有的更新操作。每個(gè) Region 對象又是由多個(gè) Store 組成的，每個(gè) Store 對應(yīng)了表中的一個(gè)列族的存儲(chǔ)。每個(gè) Store 又包含了 MemStore 和若干個(gè) StoreFile，其中，MemStore 是在內(nèi)存中的緩存，保存最近更新的數(shù)據(jù)。StoreFile是磁盤中的文件，這些文件都是樹結(jié)構(gòu)，方便讀取。
用戶讀寫數(shù)據(jù)的過程：當(dāng)用戶寫入數(shù)據(jù)時(shí)，會(huì)被分配到相應(yīng)的Region服務(wù)器去執(zhí)行操作，用戶數(shù)據(jù)首先被寫入到MemStore和HLog中，當(dāng)操作寫入HLog之后，commit()調(diào)用才會(huì)將其返回給客戶端。當(dāng)用戶讀取數(shù)據(jù)時(shí)，Region服務(wù)器會(huì)首先訪問MemStore緩存，如果數(shù)據(jù)不在緩存中，才會(huì)到磁盤上面的StoreFile中去尋找。
14. 試述 HStore 的工作原理
每個(gè) Store 對應(yīng)了表中的一個(gè)列族的存儲(chǔ)。每個(gè) Store 包括一個(gè) MenStore 緩存和若干個(gè) StoreFile 文件。MenStore 是排序的內(nèi)存緩沖區(qū)，當(dāng)用戶寫入數(shù)據(jù)時(shí)，系統(tǒng)首先把數(shù)據(jù)放入 MenStore 緩存，當(dāng) MemStore 緩存滿時(shí)，就會(huì)刷新到磁盤中的一個(gè) StoreFile 文件中(文件合并)，當(dāng)單個(gè) StoreFile 文件大小超過一定閾值時(shí)，就會(huì)觸發(fā)文件分裂操作。新分裂出的2個(gè)子Region會(huì)被Master分配到相應(yīng)的Region服務(wù)器上。
15. 試述 HLog 的工作原理
HLog用來保證HBase系統(tǒng)發(fā)生故障時(shí)能夠恢復(fù)到正確的狀態(tài)。HBase 系統(tǒng)為每個(gè) Region 服務(wù)器配置了一個(gè) HLog 文件（所有Region對象共用一個(gè)HLog），它是一種預(yù)寫式日志（Write Ahead Log），用戶更新數(shù)據(jù)必須首先寫入日志后，才能寫入 MemStore 緩存，并且，直到 MemStore 緩存內(nèi)容對應(yīng)的日志已經(jīng)寫入磁盤，該緩存內(nèi)容才能被刷寫到磁盤。
當(dāng)一個(gè)Region服務(wù)器發(fā)生故障時(shí)，通過將Region服務(wù)器上的HLog按照其所屬的Region對象進(jìn)行拆分，然后分發(fā)到其他Region服務(wù)器上執(zhí)行恢復(fù)操作。
16. 在 HBase 中，每個(gè) Region 服務(wù)器維護(hù)一個(gè) HLog，而不是為每個(gè) Region 都單獨(dú)維護(hù)一個(gè) HLog。請說明這種做法的優(yōu)缺點(diǎn)。
優(yōu)點(diǎn)： 多個(gè) Region 對象的更新操作所發(fā)生的日志修改，只需要不斷把日志記錄追加到單個(gè)日志文件中，不需要同時(shí)打開、寫入到多個(gè)日志文件中，可以減少磁盤尋址次數(shù)。
缺點(diǎn)：如果一個(gè) Region 服務(wù)器發(fā)生故障，為了恢復(fù)其上次的 Region 對象，需要將 Region 服務(wù)器上的對象，需要將 Region 服務(wù)器上的 HLog 按照其所屬的 Region 對象進(jìn)行拆分，然后分發(fā)到其他 Region 服務(wù)器上執(zhí)行恢復(fù)操作。
17. 當(dāng)一臺 Region 服務(wù)器意外終止時(shí)，Master 如何發(fā)現(xiàn)這種意外終止情況？為了恢復(fù)這臺發(fā)生意外的 Region 服務(wù)器上的 Region,Master 應(yīng)該做出哪些處理 (包括如何使用 HLog 進(jìn)行恢復(fù))?
①Zookeeper 會(huì)實(shí)時(shí)監(jiān)測每個(gè) Region 服務(wù)器的狀態(tài)，當(dāng)某個(gè) Region 服務(wù)器發(fā)生故障時(shí)，Zookeeper 會(huì)通知 Master。
② Master 首先會(huì)處理該故障 Region 服務(wù)器上面遺留的 HLog 文件，這個(gè)遺留的 HLog 文件中包含了來自多個(gè) Region 對象的日志記錄。
③ 系統(tǒng)會(huì)根據(jù)每條日志記錄所屬的 Region 對象對 HLog 數(shù)據(jù)進(jìn)行拆分，分別放到相應(yīng) Region 對象的目錄下，然后，再將失效的 Region 重新分配到可用的 Region 服務(wù)器中，并把與該 Region 對象相關(guān)的 HLog 日志記錄也發(fā)送給相應(yīng)的 Region 服務(wù)器。
④ Region 服務(wù)器領(lǐng)取到分配給自己的 Region 對象以及與之相關(guān)的 HLog 日志記錄以后，會(huì)重新做一遍日志記錄中的各種操作，把日志記錄中的數(shù)據(jù)寫入到 MemStore 緩存中，然后，刷新到磁盤的 StoreFile 文件中，完成數(shù)據(jù)恢復(fù)；
18. 行式存儲(chǔ)和列式存儲(chǔ)的區(qū)別是什么？
① 行式存儲(chǔ)使用NSM存儲(chǔ)模型，一個(gè)元組(或行)會(huì)被連續(xù)的存儲(chǔ)在磁盤頁中。**(存)數(shù)據(jù)是一行行存的，當(dāng)?shù)谝恍袑懭氪疟P頁后，再繼續(xù)寫入第二行。(讀取)**從磁盤中讀取數(shù)據(jù)時(shí)，需要從磁盤中順序掃描每個(gè)元組的完整內(nèi)容，然后從每個(gè)元組中篩選出查詢所需要的屬性；
② 列式存儲(chǔ)使用DSM存儲(chǔ)模型，DSM會(huì)對關(guān)系進(jìn)行垂直分解，并為每個(gè)屬性分配一個(gè)子關(guān)系。因此，一個(gè)具有n個(gè)屬性的關(guān)系會(huì)被分解成n個(gè)子關(guān)系，每個(gè)子關(guān)系單獨(dú)存儲(chǔ)，每個(gè)子關(guān)系只有當(dāng)其相應(yīng)的屬性被請求時(shí)才會(huì)被訪問。故列式存儲(chǔ)以關(guān)系數(shù)據(jù)庫的屬性為單位進(jìn)行存儲(chǔ)，關(guān)系中多個(gè)元組的同一屬性值會(huì)被存儲(chǔ)再一起，而一個(gè)元組中不同屬性值則通常會(huì)被分別存放于不同的磁盤頁中；
③ (兩者區(qū)別) 行式存儲(chǔ)適合小批量的數(shù)據(jù)處理，但是適合于復(fù)雜的表連接的操作。列式存儲(chǔ)適合大量的數(shù)據(jù)處理和查詢。
19. HBase是列式存儲(chǔ)數(shù)據(jù)庫嗎？
HBase嚴(yán)格意義上來說并不是列式存儲(chǔ)的數(shù)據(jù)庫，因?yàn)镠Base是以列族為單位進(jìn)行分解(列族中可以包含多個(gè)列)，而不是每個(gè)列都單獨(dú)存儲(chǔ)，但是HBase借鑒和利用了磁盤上的這種列存儲(chǔ)格式，故而可以被稱為列式存儲(chǔ)數(shù)據(jù)庫。
NoSQL數(shù)據(jù)庫
1. NoSQL 數(shù)據(jù)庫的四大類型，并解釋其含義。
鍵值數(shù)據(jù)庫、列族數(shù)據(jù)庫、文檔數(shù)據(jù)庫和圖數(shù)據(jù)庫。
① 鍵值數(shù)據(jù)庫會(huì)使用一個(gè)哈希表來存儲(chǔ)，只能通過key進(jìn)行查詢，從而找到對應(yīng)的value，缺點(diǎn)是不容易進(jìn)行條件查詢；
② 列族數(shù)據(jù)庫采用列族數(shù)據(jù)模型，同一列的數(shù)據(jù)會(huì)存放在一起；
③ 文檔數(shù)據(jù)庫以文檔作為數(shù)據(jù)庫的最小單位；
④ 圖數(shù)據(jù)庫使用圖作為數(shù)據(jù)模型來存儲(chǔ)數(shù)據(jù)；
2. 試述 CAP 理論的具體含義。
C（Consistency）：一致性，所有節(jié)點(diǎn)在同一時(shí)間具有相同的數(shù)據(jù)。
A:（Availability）：可用性，是指快速獲取數(shù)據(jù)，可以在確定的時(shí)間內(nèi)返回操作結(jié)果，保證每個(gè)請求不管成功或者失敗都有響應(yīng)；
P（Tolerance of Network Partition）：分區(qū)容忍性，是指當(dāng)出現(xiàn)網(wǎng)絡(luò)分區(qū)的情況時(shí)（即系統(tǒng)中的一部分節(jié)點(diǎn)無法和其他節(jié)點(diǎn)進(jìn)行通信），分離的系統(tǒng)也能夠正常運(yùn)行，也就是說，系統(tǒng)中任意信息的丟失或失敗不會(huì)影響系統(tǒng)的繼續(xù)運(yùn)作。
3. 試述數(shù)據(jù)庫的 ACID 四性的含義
① 原子性（Atomicity)
指事務(wù)必須是原子工作單元，對于其數(shù)據(jù)修改，要么全都執(zhí)行，要么全都不執(zhí)行。
② 一致性（consistency）
指事務(wù)在完成時(shí)，必須使所有的數(shù)據(jù)都保持一致狀態(tài)。
③ 隔離性（Isolation)
指并發(fā)事務(wù)所做的修改必須與其他并發(fā)事務(wù)所做的修改隔離。
④ 持久性（Durability)
指事務(wù)完成之后，它對于系統(tǒng)的影響是永久性的，該修改即使出現(xiàn)致命的系統(tǒng)故障也將一直保持。
4. 請解釋軟狀態(tài)、無狀態(tài)、硬狀態(tài)的具體含義。
“軟狀態(tài)（soft-state）”是與 “硬狀態(tài)（hard-state）” 相對應(yīng)的一種提法。數(shù)據(jù)庫保存的數(shù)據(jù)是 “硬狀態(tài)” 時(shí)，可以保證數(shù)據(jù)一致性，即保證數(shù)據(jù)一直是正確的。“軟狀態(tài)”是指狀態(tài)可以有一段時(shí)間不同步，具有一定的滯后性。
5. 試述不一致性窗口的含義。
所有后續(xù)的訪問都可以讀取到操作 OP 寫入的最新值。從 OP 操作完成到后續(xù)訪問可以最終讀取到 OP 寫入的最新值，這之間的時(shí)間間隔稱為 “不一致性窗口”。
第三章 大數(shù)據(jù)處理與分析
MapReduce
1. MapReduce 模型采用 Master(JobTracker)-Slave(TaskTracker) 結(jié)構(gòu)，試描述 JobTracker 和 TasKTracker 的功能。
MapReduce 框架采用了 Master/Slave 架構(gòu)，包括一個(gè) Master 和若干個(gè) Slave。Master 上運(yùn)行 JobTracker,Slave 上運(yùn)行 TaskTrackero 用戶提交的每個(gè)計(jì)算作業(yè)，會(huì)被劃分成若千個(gè)任務(wù)。JobTracker 負(fù)責(zé)作業(yè)和任務(wù)的調(diào)度，監(jiān)控它們的執(zhí)行，并重新調(diào)度已經(jīng)失敗的任務(wù)。TaskTracker 負(fù)責(zé)執(zhí)行由 JobTracker 指派的任務(wù)。
2. TaskTracker出現(xiàn)故障會(huì)有什么影響？該故障是如何處理的？
3. MapReduce計(jì)算模型的核心是Map函數(shù)和Reduce函數(shù)，試述這兩個(gè)函數(shù)各自的輸入，輸出以及處理過程。
① Map函數(shù)的輸入來自于分布式文件系統(tǒng)的文件塊，map函數(shù)將輸入的元素轉(zhuǎn)換成<key,value>形式的鍵值對；
② Reduce函數(shù)的任務(wù)就是將輸入的一系列具有相同鍵的鍵值對以某種方式組合起來，輸出處理后的鍵值對，輸出結(jié)果會(huì)合并成一個(gè)文件。
4. 試述 MapReduce 的工作流程 (需包括提交任務(wù)、Map、Shuffle、Reduce 的過程)。
① 邏輯切分：首先MapReduce框架會(huì)使用InputFormat模塊做Map前的預(yù)處理，比如驗(yàn)證輸入的格式是否符合輸入的定義；然后，將輸入文件切分為邏輯上的多個(gè)InputSplit，InputSplit是MapReduce對文件進(jìn)行處理和運(yùn)算的輸入單位；(每個(gè)InputSplit并沒有對文件進(jìn)行實(shí)際切割，只是記錄了要處理的數(shù)據(jù)的位置和長度)；
② 轉(zhuǎn)化為Key-value：通過RecordReader(RR)根據(jù)InputSplit中的信息來處理InputSplit中的具體記錄，加載數(shù)據(jù)并轉(zhuǎn)換為適合Map任務(wù)讀取的鍵值對，輸入給Map任務(wù)；
③ Map處理：Map任務(wù)會(huì)根據(jù)用戶自定義的映射規(guī)則，輸出一系列的<key,value>作為中間結(jié)果；
④ Shuffle：為了讓Reduce可以并行處理Map的結(jié)果，需要對Map的輸出進(jìn)行一定的分區(qū)、排序、合并、歸并等操作，得到<key,value-list>形式的中間結(jié)果，再交給對應(yīng)的Reduce進(jìn)行處理。Shuffle將無序的<key,value>轉(zhuǎn)化為有序的<key,value-list>；
⑤ Reduce：Reduce 以一系列<key,value-list>中間結(jié)果作為輸入，執(zhí)行用戶定義的邏輯，輸出結(jié)果給OutputFormat模塊；
⑥ 輸出模塊：OutputFormat模塊驗(yàn)證輸出目錄是否已經(jīng)存在且輸出結(jié)果類型是否符合配置文件中的配置類型，如果都滿足，就輸出Reduce的結(jié)果到分布式文件系統(tǒng)。
6. Shuffle過程是MapReduce工作流程的核心，試分析Shuffle過程的作用。
將無序的<key,value>轉(zhuǎn)成有序的<key,value-list>，目的是為了讓Reduce可以并行處理Map的結(jié)果。
7. 分別描述Map端和Reduce端的Shuffle過程(需包括spill、Sort、Merge、Fetch的過程)
Shuffle就是對Map輸出結(jié)果進(jìn)行分區(qū)、排序、合并等處理一并交給Reduce的過程。Shuffle過程分為Map端的操作和Reduce端的操作：
在Map端的Shuffle過程：Map端的Shuffle過程分為四個(gè)步驟，① 輸入數(shù)據(jù)和執(zhí)行Map任務(wù)；② 寫入緩存(分區(qū)，排序和合并)；③ 溢寫；④ 文件歸并；
① Map任務(wù)的輸入數(shù)據(jù)一般保存在分布式文件系統(tǒng)的文件塊中，接受<key,value>作為輸入，按一定映射規(guī)則轉(zhuǎn)換為一批<key,value>作為輸出；
② Map的輸出結(jié)果首先寫入緩存，在緩存中積累一定數(shù)量的Map輸出結(jié)果后，再一次性批量寫入磁盤，這樣可以大大減少對磁盤的IO消耗。因?yàn)閷ぶ窌?huì)開銷很大，所以通過一次尋址、連續(xù)寫入，就可以大大降低開銷；(寫入緩存之前，key和value值都會(huì)被序列化成字節(jié)數(shù)組)；
③ 因?yàn)榫彺嬷衜ap結(jié)果的數(shù)量不斷增加，因此需要啟動(dòng)溢寫操作，把緩存中的內(nèi)容一次性寫入磁盤，并清空緩存。通常采用的方法是到達(dá)0.8的閾值后，就啟動(dòng)溢寫過程。在溢寫到磁盤之前，緩存中的數(shù)據(jù)首先會(huì)被分區(qū)，默認(rèn)分區(qū)方式是采用Hash函數(shù)對key進(jìn)行哈希后再用Reduce任務(wù)的數(shù)量進(jìn)行取模，表示為：hash(key) mod reduce任務(wù)數(shù)量，這樣就可以把map輸出結(jié)果均勻的分配給這R個(gè)reduce任務(wù)去并行處理了。分完區(qū)后，再根據(jù)key對它們進(jìn)行內(nèi)存排序，排序完后，可以通過用戶自定義的Combiner函數(shù)來執(zhí)行合并操作，從而減少需要溢寫到磁盤的數(shù)據(jù)量。經(jīng)過分區(qū)、排序以及可能發(fā)生的合并操作后，這些緩存中的鍵值對就可以被寫入磁盤，并清空緩存。每次溢寫操作都會(huì)在磁盤中生成一個(gè)新的溢寫文件，寫入溢寫文件中的所有鍵值對都是經(jīng)過分區(qū)和排序的。
④ 每次溢寫操作都會(huì)在磁盤中生成一個(gè)新的溢寫文件，隨著MapReduce任務(wù)的進(jìn)行，磁盤中的溢寫文件數(shù)量越來越多，最后在Map任務(wù)全部結(jié)束之前，系統(tǒng)對所有溢寫文件中的數(shù)據(jù)進(jìn)行歸并，從而生成一個(gè)大的溢寫文件；
⑤ 經(jīng)過上述四個(gè)步驟后，Shffle過程完成，最終生成的一個(gè)大文件會(huì)被存放在本地磁盤上，這個(gè)大文件中的數(shù)據(jù)是被分區(qū)的，不同的分區(qū)會(huì)被發(fā)送到不同的Reduce任務(wù)進(jìn)行并行處理。同時(shí)JobTracker會(huì)一直檢測Map任務(wù)的執(zhí)行，當(dāng)檢測到一個(gè)Map任務(wù)完成后，就會(huì)立即通知相關(guān)的Reduce任務(wù)來“領(lǐng)取”數(shù)據(jù)，然后開始Reduce端的Shuffle過程。
在Reduce端的Shuffle過程：Reduce端的Shuffle只需要從Map端讀取Map結(jié)果，然后執(zhí)行歸并操作，最后輸送給Reduce任務(wù)進(jìn)行處理。過程分為三個(gè)步驟，① 領(lǐng)取數(shù)據(jù)；② 歸并數(shù)據(jù)；③ 把數(shù)據(jù)輸入給Reduce任務(wù)；
① 領(lǐng)取數(shù)據(jù)
Map端的Shuffle過程結(jié)束后，所有map輸出結(jié)果都保存在Map機(jī)器的本地磁盤上，Reduce需要把磁盤上的數(shù)據(jù)fetch回來存放在自己所在機(jī)器的本地磁盤上。故每個(gè)Reduce任務(wù)會(huì)不斷的向JobTracker詢問Map任務(wù)是否完成，當(dāng)檢測到一個(gè)完成后，就會(huì)通知相關(guān)的Reduece任務(wù)來領(lǐng)取數(shù)據(jù)，一旦一個(gè)Reduce任務(wù)收到了通知，就會(huì)到該Map任務(wù)所在機(jī)器上把屬于自己處理的分區(qū)數(shù)據(jù)fetch到本地磁盤；
② 歸并數(shù)據(jù)
因?yàn)榫彺嬷械臄?shù)據(jù)是來自不同的Map機(jī)器，一般會(huì)存在很多可以合并的鍵值對。當(dāng)溢寫過程啟動(dòng)時(shí)，具有相同key的鍵值會(huì)被歸并，歸并時(shí)會(huì)對鍵值對進(jìn)行排序，以保證最終大文件的鍵值對都是有序的。最終通過多輪歸并將磁盤上多個(gè)溢寫文件歸并為多個(gè)大文件。
③ 把數(shù)據(jù)輸入給Reduce
磁盤經(jīng)過多輪歸并后得到的若干個(gè)大文件，會(huì)直接輸入個(gè)Reduce任務(wù)(不會(huì)歸并成一個(gè)新的大文件)。
8. MapReduce 中有這樣一個(gè)原則: 移動(dòng)計(jì)算比移動(dòng)數(shù)據(jù)更經(jīng)濟(jì)。試述什么是本地計(jì)算，并分析為何要采用本地計(jì)算。
MapReduce 設(shè)計(jì)的一個(gè)理念就是 “計(jì)算向數(shù)據(jù)靠攏”，而不是 “數(shù)據(jù)向計(jì)算靠攏”，因?yàn)橐苿?dòng)數(shù)據(jù)需要大量的網(wǎng)絡(luò)傳輸開銷，尤其是在大規(guī)模數(shù)據(jù)環(huán)境下，這種開銷尤為驚人，所以，移動(dòng)計(jì)算要比移動(dòng)數(shù)據(jù)更加經(jīng)濟(jì)。
本地計(jì)算：在一個(gè)集群中，只要有可能，MapReduce 框架就會(huì)將 Map 程序就近地在 HDFS 數(shù)據(jù)所在的節(jié)點(diǎn)運(yùn)行，即將計(jì)算節(jié)點(diǎn)和存儲(chǔ)節(jié)點(diǎn)放在一起運(yùn)行，從而減少了節(jié)點(diǎn)間的數(shù)據(jù)移動(dòng)開銷。
9. 試說明一個(gè) MapReduce 程序在運(yùn)行期間，所啟動(dòng)的 Map 任務(wù)數(shù)量和 Reduce 任務(wù)數(shù)量各是由什么因素決定的。
10. 是否所有的 MapReduce 程序都需要經(jīng)過 Map 和 Reduce 這兩個(gè)過程? 如果不是，請舉例說明。
不是。對于關(guān)系的選擇運(yùn)算，只需要 Map 過程就能實(shí)現(xiàn)，對于關(guān)系 R 中的每個(gè)元組 t, 檢測是否是滿足條件的所需元組，如果滿足條件，則輸出鍵值對 <,>, 也就是說，鍵和值都是 t。這時(shí)的 Reduce 函數(shù)就只是一個(gè)恒等式，對輸入不做任何變換就直接輸出。
11. 分析為何采用 Combiner 可以減少數(shù)據(jù)傳輸量? 是否所有的 MapReduce 程序都可以采用 Combiner? 為什么?
對于每個(gè)分區(qū)內(nèi)的所有鍵值對，后臺線程會(huì)根據(jù) key 對它們進(jìn)行內(nèi)存排序 (Sort), 排序是 MapReduce 的默認(rèn)操作。排序結(jié)束后，還包含一個(gè)可選的合并(Combine ) 操作。如果用戶事先沒有定義 Combiner 函數(shù)，就不用進(jìn)行合并操作。如果用戶事先定義了 Combiner 函數(shù)，則這個(gè)時(shí)候會(huì)執(zhí)行合并操作，從而減少需要溢寫到磁盤的數(shù)據(jù)量。所謂 “合并”，是指將那些具有相同 key 的 < key,value > 的 value 加起來，比如，有兩個(gè)鍵值對 <*xmu",1 > 和 <*xmu",1>, 經(jīng)過合并操作以后就可以得到一個(gè)鍵值對 <*xmu",2>, 減少了鍵值對的數(shù)量。不過，并非所有場合都可以使用 Combiner, 因?yàn)?#xff0c;Combiner 的輸出是 Reduce 任務(wù)的輸人，Combiner 絕不能改變 Reduce 任務(wù)最終的計(jì)算結(jié)果，一般而言，累加、最大值等場景可以使用合并操作。
12. MapReduce 程序的輸入文件、輸出文件都存儲(chǔ)在 HDFS 中，而在 Map 任務(wù)完成時(shí)的中間結(jié)果則存儲(chǔ)在本地磁盤中。試分析中間結(jié)果存儲(chǔ)在本地磁盤而不是 HDFS 上有何優(yōu)缺點(diǎn)？
13. 早期版本的HDFS，其默認(rèn)塊大小為64MB，而較新版本默認(rèn)為128MB，采用較大的塊具有什么影響和優(yōu)缺點(diǎn)？
14. 試著畫出使用MapReduce來對英語句子“Whatever is worth doing is worth doing well”進(jìn)行單詞統(tǒng)計(jì)的過程。
15. 在基于MapReduce的單詞統(tǒng)計(jì)中，MapReduce是如何保證相同的單詞數(shù)據(jù)會(huì)劃分到同一個(gè)Reducer上進(jìn)行處理以保證結(jié)果的正確性？
Hadoop再探討
1. HDFS1.0 中只包含一個(gè)名稱節(jié)點(diǎn)會(huì)帶來哪些問題(單點(diǎn)故障問題)。
單點(diǎn)故障問題：雖然HDFS1.0中存在第二名稱節(jié)點(diǎn)，但是在1.0版本中第二名稱節(jié)點(diǎn)的作用是周期性的從名稱節(jié)點(diǎn)獲取命名空間鏡像文件(FsImage)和修改日志(EditLog)，從而來對FsImage的恢復(fù)。因此當(dāng)名稱節(jié)點(diǎn)發(fā)生故障時(shí)，系統(tǒng)無法實(shí)時(shí)切換到第二名稱節(jié)點(diǎn)以對外提供服務(wù)，仍需要停機(jī)恢復(fù)。（可以通過HA來解決）
在可擴(kuò)展性方面，名稱節(jié)點(diǎn)把整個(gè) HDFS 文件系統(tǒng)中的元數(shù)據(jù)信息都保存在自己的內(nèi)存中，HDFS1.0 中只有一個(gè)名稱節(jié)點(diǎn)，不可以水平擴(kuò)展，而單個(gè)名稱節(jié)點(diǎn)的內(nèi)存空間是由上限的，這限制了系統(tǒng)中數(shù)據(jù)塊、文件和目錄的數(shù)目。在系統(tǒng)整體性能方面，整個(gè) HDFS 文件系統(tǒng)的性能會(huì)受限于單個(gè)名稱節(jié)點(diǎn)的吞吐量。在隔離性方面，單個(gè)名稱節(jié)點(diǎn)難以提供不同程序之間的隔離性，一個(gè)程序可能會(huì)影響會(huì)影響其他運(yùn)行的程序。（通過HDFS聯(lián)邦來進(jìn)行解決）
2. 請描述 HDFS HA 架構(gòu)組成組建及其具體功能。
設(shè)置兩個(gè)名稱節(jié)點(diǎn)，其中一個(gè)名稱節(jié)點(diǎn)處于 “活躍” 狀態(tài)，另一個(gè)處于 “待命” 狀態(tài)。處于活躍狀態(tài)的名稱節(jié)點(diǎn)負(fù)責(zé)對外處理所有客戶端的請求，而處于待命狀態(tài)的名稱節(jié)點(diǎn)則作為備用節(jié)點(diǎn)。處于待命狀態(tài)的名稱節(jié)點(diǎn)提供了“熱備份”，一旦活躍名稱節(jié)點(diǎn)出現(xiàn)故障，就可以立即切換到待命名稱節(jié)點(diǎn)，不會(huì)影響到系統(tǒng)的正常對外服務(wù)。
3. 請分析 HDFS HA 架構(gòu)中數(shù)據(jù)節(jié)點(diǎn)如何和名稱節(jié)點(diǎn)保持通信。
在 HDFS HA中，所有名稱節(jié)點(diǎn)會(huì)共享底層的數(shù)據(jù)節(jié)點(diǎn)存儲(chǔ)資源。每個(gè)數(shù)據(jù)節(jié)點(diǎn)要向集群中所有的名稱節(jié)點(diǎn)注冊，并周期性地向名稱節(jié)點(diǎn)發(fā)送 “心跳” 和塊信息，報(bào)告自己的狀態(tài)，同時(shí)也會(huì)處理來自名稱節(jié)點(diǎn)的指令。
4. 為什么需要HDFS聯(lián)邦，它能解決什么問題？
因?yàn)樵瓉淼腍DFS存在可擴(kuò)展性，系統(tǒng)性能及隔離性三個(gè)方面的問題。
聯(lián)邦設(shè)計(jì)了多個(gè)相互獨(dú)立的名稱節(jié)點(diǎn)，使得HDFS的命名服務(wù)能夠水平擴(kuò)展。
5. 描述HDFS 聯(lián)邦中 “塊池” 的概念，分析為什么 HDFS 聯(lián)邦中的一個(gè)名稱節(jié)點(diǎn)失效，也不會(huì)影響到與它相關(guān)的數(shù)據(jù)節(jié)點(diǎn)繼續(xù)為其他名稱節(jié)點(diǎn)提供服務(wù)。
HDFS 聯(lián)邦擁有多個(gè)獨(dú)立的命名空間，其中，每一個(gè)命名空間管理屬于自己的一組塊，這些屬于同一個(gè)命名空間的塊構(gòu)成一個(gè) “塊池”。
每個(gè)數(shù)據(jù)節(jié)點(diǎn)會(huì)為多個(gè)塊池提供塊的存儲(chǔ)。可以看出，數(shù)據(jù)節(jié)點(diǎn)是一個(gè)物理邏輯，而塊池則屬于邏輯概念，一個(gè)塊池是一組塊的邏輯集合，塊池中的各個(gè)塊實(shí)際上是存儲(chǔ)在各個(gè)不同的數(shù)據(jù)節(jié)點(diǎn)中的。因此 HDFS 聯(lián)邦中的一個(gè)名稱節(jié)點(diǎn)失效，也不會(huì)影響到與它相關(guān)的數(shù)據(jù)節(jié)點(diǎn)繼續(xù)為其他名稱節(jié)點(diǎn)提供服務(wù)。
6. 請闡述 MapReduce1.0 體系結(jié)構(gòu)中存在的問題。
（1）存在單點(diǎn)故障：系統(tǒng)中只有一個(gè)JobTracker來負(fù)責(zé)所有MapReduce作業(yè)的調(diào)度；
（2）JobTracker負(fù)責(zé)的任務(wù)過重：JobTracker不僅要負(fù)責(zé)作業(yè)的調(diào)度和失敗恢復(fù)，同時(shí)要負(fù)責(zé)資源管理與分配；
（3）容易出現(xiàn)內(nèi)存溢出：TaskTracker資源分配時(shí)不考慮內(nèi)存的實(shí)際情況；
（4）資源劃分不合理：資源槽之間彼此不能共通使用；
7. 請描述 YARN 架構(gòu)中各組件的功能。
YARN體系中包含了三個(gè)組件：ResourceManager、ApplicationMaster和NodeManager。
8. YARN 框架中執(zhí)行一個(gè) MapReduce 程序時(shí)，從提交到完成需要經(jīng)歷的具體步驟。
①用戶編寫客戶端應(yīng)用程序，向 YARN 提交應(yīng)用程序，提交的內(nèi)容包括 ApplicationMaster 程序、啟動(dòng) ApplicationMaster 的命令、用戶程序等；
②YARN 中的 ResourceManager 負(fù)責(zé)接收和處理來自客戶端的請求。接到客戶端應(yīng)用程序請求后，ResourceManager 里面的調(diào)度器會(huì)為應(yīng)用程序分配一個(gè)容器。同時(shí)，ResourceManager 的應(yīng)用程序管理器會(huì)與該容器所在的 NodeManager 通信，為該應(yīng)用程序在該容器中啟動(dòng)一個(gè) ApplicationMaster；
③ApplicationMaster 被創(chuàng)建后會(huì)首先向 ResourceManager 注冊，從而使得用戶可以通過 ResourceManager 來直接查看應(yīng)用程序的運(yùn)行狀態(tài)；
④ApplicationMaster 采用輪詢的方式通過 RPC 協(xié)議向 ResourceManager 申請資源；
⑤ResourceManager 以 “容器” 的形式向提出申請的 ApplicationMaster 分配資源，一旦 ApplicationMaster 申請到資源后，就會(huì)與該容器所在的 NodeManager 進(jìn)行通信，要求它啟動(dòng)任務(wù)；
⑥當(dāng) ApplicationMaster 要求容器啟動(dòng)任務(wù)時(shí)，它會(huì)為任務(wù)設(shè)置好運(yùn)行環(huán)境（包括環(huán)境變量、JAR 包、二進(jìn)制程序等），然后將任務(wù)啟動(dòng)命令寫到一個(gè)腳本中，最后通過在容器中運(yùn)行該腳本來啟動(dòng)任務(wù)；
⑦各個(gè)任務(wù)通過某個(gè) RPC 協(xié)議向 ApplicationMaster 匯報(bào)自己的狀態(tài)和進(jìn)度，讓 ApplicationMaster 可以隨時(shí)掌握各個(gè)任務(wù)的運(yùn)行狀態(tài)，從而可以在任務(wù)失敗時(shí)重啟任務(wù)；
⑧應(yīng)用程序運(yùn)行完成后，ApplicationMaster 向 ResourceManager 的應(yīng)用程序管理器注銷并關(guān)閉自己。若 ApplicationMaster 因故失敗，ResourceManager 中的應(yīng)用程序管理器會(huì)監(jiān)測到失敗的情形，然后將其重新啟動(dòng)，直到所有任務(wù)執(zhí)行完畢；
9. 請對 YARN 和 MapReduce1.0 框架進(jìn)行優(yōu)劣勢對比分析。
（1）大大減少了承擔(dān)中心服務(wù)功能的 ResourceManager 的資源消耗。MapReduce1.0 中的 JobTracker 需要同時(shí)承擔(dān)資源管理、任務(wù)調(diào)度和任務(wù)監(jiān)控等三大功能，而 YARN 中的 ResourceManager 只需要負(fù)責(zé)資源管理，需要消耗大量資源的任務(wù)調(diào)度和監(jiān)控重啟工作則交由 ApplicationMaster 來完成。由于每個(gè)作業(yè)都有與之關(guān)聯(lián)的獨(dú)立的 ApplicationMaster，所以，系統(tǒng)中存在多個(gè)作業(yè)時(shí)，就會(huì)同時(shí)存在多個(gè) ApplicationMaster，這就實(shí)現(xiàn)了監(jiān)控任務(wù)的分布化，不再像 MapReduce1.0 那樣監(jiān)控任務(wù)只集中在一個(gè) JobTracker 上。
（2）MapReduce1.0 既是一個(gè)計(jì)算框架，又是一個(gè)資源管理調(diào)度框架，但是只能支持 MapReduce 編程模型。而 YARN 則是一個(gè)純粹的資源調(diào)度管理框架，在它上面可以運(yùn)行包括 MapReduce 在內(nèi)的不同類型的計(jì)算框架，默認(rèn)類型是 MapReduce。因?yàn)?#xff0c;YARN 中的 ApplicationMaster 是可變更的，針對不同的計(jì)算框架，用戶可以采用任何編程語言自己編寫服務(wù)于該計(jì)算框架的 ApplicationMaster。比如，可以編寫一個(gè)面向 MapReduce 計(jì)算框架的 ApplicationMaster，從而使得 MapReduce 計(jì)算框架可以運(yùn)行在 YARN 框架之上。同理，還可以編寫面向 Spark、Storm 等計(jì)算框架的ApplicationMaster，從而使得 Spark、Storm 等計(jì)算框架也可以運(yùn)行在 YARN 框架之上。
（3）YARN 中的資源管理比 MapReduce1.0 更加高效。YARN 采用容器為單位進(jìn)行資源管理和分配，而不是以槽為單位，避免了 MapReduce1.0 中槽的閑置浪費(fèi)情況，大大提高了資源的利用率。
10. 請分別描述 Pig、Tez 和 Kafka 的功能。
① Pig 是 Hadoop 生態(tài)系統(tǒng)的一個(gè)組件，允許用戶通過編寫簡單的腳本來實(shí)現(xiàn)復(fù)雜的數(shù)據(jù)分析，而不需要編寫復(fù)雜的 MapReduce 應(yīng)用程序，Pig 會(huì)自動(dòng)把用戶編寫的腳本轉(zhuǎn)換成 MapReduce 作業(yè)在 Hadoop 集群上運(yùn)行，而且具備對生成的 MapReduce 程序進(jìn)行自動(dòng)優(yōu)化的功能；
② Tez 直接源于 MapReduce 框架，核心思想是將 Map 和 Reduce 兩個(gè)操作進(jìn)一步進(jìn)行拆分，即 Map 被拆分成 Input、Processor、Sort、Merge 和 Output，Reduce 被拆分成 Input、Shuffle、Sort、Merge、Processor 和 Output 等，經(jīng)過分解后的這些元操作可以進(jìn)行自由任意組合產(chǎn)生新的操作，經(jīng)過一些控制程序組裝后就可形成一個(gè)大的 DAG 作業(yè)。通過 DAG 作業(yè)的方式運(yùn)行 MapReduce 作業(yè)，提供了程序運(yùn)行的整體處理邏輯，就可以去除工作流當(dāng)中多余的 Map 階段，減少不必要的操作，提升數(shù)據(jù)處理的性能；
③ Kafka 是由 LinkedIn 公司開發(fā)的一種高吞吐量的分布式發(fā)布訂閱消息系統(tǒng)，用戶通過 Kafka 系統(tǒng)可以發(fā)布大量的消息，同時(shí)也能實(shí)時(shí)訂閱消費(fèi)消息。Kafka 設(shè)計(jì)的初衷是構(gòu)建一個(gè)可以處理海量日志、用戶行為和網(wǎng)站運(yùn)營統(tǒng)計(jì)等的數(shù)據(jù)處理框架。
Spark
1. 闡述如下 Spark 的幾個(gè)主要概念：RDD、DAG、階段、分區(qū)、窄依賴、寬依賴。
①RDD：是彈性分布式數(shù)據(jù)集（Resilient Distributed Dataset）的英文縮寫，是分布式內(nèi)存的一個(gè)抽象概念，提供了一種高度受限的共享內(nèi)存模型。
②DAG：是 Directed Acyclic Graph（有向無環(huán)圖）的英文縮寫，反映 RDD 之間的依賴關(guān)系。
③階段：是作業(yè)的基本調(diào)度單位，一個(gè)作業(yè)會(huì)分為多組任務(wù)，每組任務(wù)被稱為 “階段”，或者也被稱為 “任務(wù)集”。
④分區(qū)：一個(gè) RDD 就是一個(gè)分布式對象集合，本質(zhì)上是一個(gè)只讀的分區(qū)記錄集合，每個(gè) RDD 可以分成多個(gè)分區(qū)，每個(gè)分區(qū)就是一個(gè)數(shù)據(jù)集片段。
⑤窄依賴：父 RDD 的一個(gè)分區(qū)只被一個(gè)子 RDD 的一個(gè)分區(qū)所使用就是窄依賴。
⑥寬依賴：父 RDD 的一個(gè)分區(qū)被一個(gè)子 RDD 的多個(gè)分區(qū)所使用就是寬依賴
作者計(jì)算機(jī)碩士，從事大數(shù)據(jù)方向，公眾號致力于技術(shù)專欄，主要內(nèi)容包括：算法，大數(shù)據(jù)，個(gè)人思考總結(jié)等
總結(jié)
以上是生活随笔為你收集整理的《大数据技术原理与应用》林子雨(第二版)--总结的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 关于for循环中的变量int i 如果
- 下一篇： WX: picker 滚动选择器