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