大数据技术原理与应用（最后三天备考！！！）
大數(shù)據(jù)原理與應(yīng)用期末備考 三天速成不掛科
☆ 內(nèi)容期末大概率考
選擇部分直達(dá) → 選擇部分
導(dǎo)航
- 大數(shù)據(jù)原理與應(yīng)用期末備考 三天速成不掛科
- 第一章 大數(shù)據(jù)概述
- 第二章 大數(shù)據(jù)處理架構(gòu) Hadoop
- 第三章 分布式文件系統(tǒng) HDFS
- 第四章 分布式數(shù)據(jù)庫 HBase
- 第五章 NoSql 數(shù)據(jù)庫
- 第六章 云數(shù)據(jù)庫
- 第七章 MapReduce
- 第八章 Hadoop 再探討
第一章 大數(shù)據(jù)概述
1. 試述大數(shù)據(jù)的四個(gè)基本特征。
數(shù)據(jù)量大：人類進(jìn)入信息社會(huì)后，數(shù)據(jù)以自然方式增長，數(shù)據(jù)每兩年就會(huì)增加一倍多。
數(shù)據(jù)類型繁多：大數(shù)據(jù)的數(shù)據(jù)類型非常豐富，包括結(jié)構(gòu)化數(shù)據(jù)和非結(jié)構(gòu)化數(shù)據(jù)，如郵件、音頻、視頻等，給數(shù)據(jù)處理和分析技術(shù)提出了新的挑戰(zhàn)。
處理速度快：由于很多應(yīng)用都需要基于快速生成的數(shù)據(jù)給出實(shí)時(shí)分析結(jié)果，因此新興的大數(shù)據(jù)分析技術(shù)通常采用集群處理和獨(dú)特的內(nèi)部設(shè)計(jì)。
價(jià)值密度低：有價(jià)值的數(shù)據(jù)分散在海量數(shù)據(jù)中。
2. 舉例說明大數(shù)據(jù)的關(guān)鍵技術(shù)。
| 數(shù)據(jù)采集與預(yù)處理 | 利用 ETL 工具將分布在異構(gòu)數(shù)據(jù)源中的數(shù)據(jù)抽到臨時(shí)中間層后進(jìn)行清洗、轉(zhuǎn)換和集成后加載到數(shù)據(jù)倉庫中，成為聯(lián)機(jī)分析處理、數(shù)據(jù)挖掘的基礎(chǔ)，也可以利用日志采集工具（如 Flume、Kafka 等）將實(shí)時(shí)采集的數(shù)據(jù)作為流計(jì)算系統(tǒng)的輸入，進(jìn)行實(shí)時(shí)處理分析。 |
| 數(shù)據(jù)存儲(chǔ)和管理 | 利用分布式文件系統(tǒng)、NoSQL 數(shù)據(jù)庫等實(shí)現(xiàn)對數(shù)據(jù)的存儲(chǔ)和管理。 |
| 數(shù)據(jù)處理與分析 | 利用分布式并行編程模型和計(jì)算框架，結(jié)合機(jī)器學(xué)習(xí)和數(shù)據(jù)挖掘算法，實(shí)現(xiàn)對海量數(shù)據(jù)的處理和分析，并進(jìn)行可視化呈現(xiàn)。 |
| 數(shù)據(jù)安全和隱私保護(hù) | 構(gòu)建數(shù)據(jù)安全體系和隱私數(shù)據(jù)保護(hù)體系。 |
3. 詳細(xì)闡述大數(shù)據(jù)、云計(jì)算和物聯(lián)網(wǎng)三者之間的區(qū)別與聯(lián)系
| 大數(shù)據(jù)側(cè)重于海量數(shù)據(jù)的存儲(chǔ)、處理與分析，從海量數(shù)據(jù)中發(fā)現(xiàn)價(jià)值，服務(wù)于生產(chǎn)和生活；云計(jì)算旨在整合和優(yōu)化各種 IT 資源并通過網(wǎng)絡(luò)以服務(wù)的方式，廉價(jià)地提供給用戶；物聯(lián)網(wǎng)的發(fā)展目標(biāo)是實(shí)現(xiàn) “ 物物相連 ”，應(yīng)用創(chuàng)新是物聯(lián)網(wǎng)的核心。 | 從整體上看，大數(shù)據(jù)、云計(jì)算和物聯(lián)網(wǎng)這三者是相輔相成的。大數(shù)據(jù)根植于云計(jì)算，大數(shù)據(jù)分析的很多技術(shù)都來自于云計(jì)算，云計(jì)算的分布式存儲(chǔ)和管理系統(tǒng)提供了海量數(shù)據(jù)的存儲(chǔ)和管理能力，分布式并行處理框架 MapReduce 提供了數(shù)據(jù)分析能力。沒有這些云計(jì)算技術(shù)作為支撐，大數(shù)據(jù)分析就無從談起。物聯(lián)網(wǎng)的傳感器源源不斷的產(chǎn)生大量數(shù)據(jù)，構(gòu)成了大數(shù)據(jù)的重要數(shù)據(jù)來源，物聯(lián)網(wǎng)需要借助于云計(jì)算和大數(shù)據(jù)技術(shù)，實(shí)現(xiàn)物聯(lián)網(wǎng)大數(shù)據(jù)的存儲(chǔ)、分析和處理。 |
第二章 大數(shù)據(jù)處理架構(gòu) Hadoop
☆☆☆ 1. 試述 Hadoop 具有哪些特性。
2. 試述 Hadoop 的項(xiàng)目結(jié)構(gòu)以及每個(gè)部分的具體功能。
3. 試列舉單機(jī)模式和偽分布式模式的異同點(diǎn)。
單機(jī)模式： Hadoop 只在一臺機(jī)器上運(yùn)行，存儲(chǔ)采用本地文件系統(tǒng)，沒有采用分布式文件系統(tǒng) HDFS。
偽分布式模式： Hadoop 存儲(chǔ)采用分布式文件系統(tǒng) HDFS，但是，HDFS 的名稱節(jié)點(diǎn)和數(shù)據(jù)節(jié)點(diǎn)都在同一臺機(jī)器上。
第三章 分布式文件系統(tǒng) HDFS
1. 試述 HDFS 中的名稱節(jié)點(diǎn)和數(shù)據(jù)節(jié)點(diǎn)的具體功能。
名稱節(jié)點(diǎn) 負(fù)責(zé)管理分布式文件系統(tǒng)系統(tǒng)的命名空間（Namespace），記錄分布式文件系統(tǒng)中的每個(gè)文件中各個(gè)塊所在的數(shù)據(jù)節(jié)點(diǎn)的位置信息。
數(shù)據(jù)節(jié)點(diǎn) 是分布式文件系統(tǒng) HDFS 的工作節(jié)點(diǎn)，負(fù)責(zé)數(shù)據(jù)的存儲(chǔ)和讀取，會(huì)根據(jù)客戶端或者名稱節(jié)點(diǎn)的調(diào)度來進(jìn)行數(shù)據(jù)的存儲(chǔ)和檢索，并向名稱節(jié)點(diǎn)定期發(fā)送自己所存儲(chǔ)的塊的列表信息。
2. HDFS 只設(shè)置唯一一個(gè)名稱節(jié)點(diǎn)，在簡化系統(tǒng)設(shè)計(jì)的同時(shí)也帶來了一些明顯的局限性，請闡述局限性具體表現(xiàn)在哪些方面。
3. 試述 HDFS 的冗余數(shù)據(jù)保存策略。
采用了多副本方式多數(shù)據(jù)進(jìn)行存儲(chǔ)。即先在集群內(nèi)挑選一個(gè)磁盤不太滿、CPU 不太忙的數(shù)據(jù)節(jié)點(diǎn)作為第一個(gè)副本存放點(diǎn)；選取不同的機(jī)架的數(shù)據(jù)節(jié)點(diǎn)作為第二副本存放點(diǎn)；選擇與第一副本存放點(diǎn)同機(jī)架的不同節(jié)點(diǎn)作為第三副本存放點(diǎn)；第四副本存放點(diǎn)從集群中隨機(jī)挑選節(jié)點(diǎn)。
4. 數(shù)據(jù)復(fù)制主要是在數(shù)據(jù)寫入和數(shù)據(jù)恢復(fù)的時(shí)候發(fā)生，HDFS 數(shù)據(jù)復(fù)制是使用流水線復(fù)制的策略，請闡述該策略的細(xì)節(jié)。
每個(gè)塊都會(huì)向 HDFS 集群中的名稱節(jié)點(diǎn)發(fā)出寫請求，名稱節(jié)點(diǎn)會(huì)返回一個(gè)數(shù)據(jù)節(jié)點(diǎn)列表給客戶端，客戶端將數(shù)據(jù)寫入列表中第一個(gè)數(shù)據(jù)節(jié)點(diǎn)時(shí)，同時(shí)把列表傳給第一個(gè)節(jié)點(diǎn)；第一個(gè)節(jié)點(diǎn)在接收到數(shù)據(jù)寫入本地的同時(shí)，會(huì)把自己已經(jīng)接收到的數(shù)據(jù)傳給第二個(gè)數(shù)據(jù)節(jié)點(diǎn)，同時(shí)第二個(gè)數(shù)據(jù)節(jié)點(diǎn)接收到數(shù)據(jù)時(shí)，會(huì)在寫入的同時(shí)將數(shù)據(jù)發(fā)送給第三個(gè)節(jié)點(diǎn)，以此類推。最后，當(dāng)文件寫完的時(shí)候，數(shù)據(jù)復(fù)制也同時(shí)完成了。
5. 請闡述 HDFS 在不發(fā)生故障的情況下讀文件的過程。
1） 客戶端打開文件，創(chuàng)建輸入流；
2） 輸入流通過遠(yuǎn)程調(diào)用名稱節(jié)點(diǎn)，獲得文件開始部分?jǐn)?shù)據(jù)塊的保存位置；
3） 客戶端得到位置后開始讀取數(shù)據(jù)，輸入流選擇距離客戶端最近的數(shù)據(jù)節(jié)點(diǎn)建立連接并讀取數(shù)據(jù)；
4） 數(shù)據(jù)從該數(shù)據(jù)節(jié)點(diǎn)讀取至客戶端，當(dāng)該數(shù)據(jù)塊讀取完畢時(shí)，關(guān)閉連接；
5） 輸入流查找下一個(gè)數(shù)據(jù)塊；
6） 找到該數(shù)據(jù)塊的最佳數(shù)據(jù)節(jié)點(diǎn)，讀取數(shù)據(jù)；
7） 當(dāng)客戶端讀取完數(shù)據(jù)時(shí)，關(guān)閉輸入流。
6. 請闡述 HDFS 在不發(fā)生故障的情況下寫文件的過程。
1） 客戶端創(chuàng)建文件和輸出流；
2） HDFS 調(diào)用名稱節(jié)點(diǎn)，在文件系統(tǒng)的命名空間中建一個(gè)新的文件，并執(zhí)行檢查；檢查通過后，名稱節(jié)點(diǎn)會(huì)構(gòu)造一個(gè)新文件夾，并添加文件信息；
3） 客戶端通過輸出流向 HDFS 的文件寫入數(shù)據(jù)；
4） 客戶端寫入的數(shù)據(jù)首先會(huì)被分成一個(gè)個(gè)的分包，將分包放入輸出流對象的內(nèi)部隊(duì)列，并向名稱節(jié)點(diǎn)申請若干個(gè)數(shù)據(jù)節(jié)點(diǎn)，然后通過流水線復(fù)制策略打包成數(shù)據(jù)包發(fā)送出去；
5） 為保證所有數(shù)據(jù)節(jié)點(diǎn)的數(shù)據(jù)都是準(zhǔn)確的，需要數(shù)據(jù)節(jié)點(diǎn)向發(fā)送者發(fā)送 “ 確認(rèn)包 ”，當(dāng)客戶端收到應(yīng)答時(shí)，將對應(yīng)的分包從內(nèi)部隊(duì)列移除。不斷執(zhí)行 3~5 直至數(shù)據(jù)寫完；
6） 客戶端關(guān)閉輸出流，通知名稱節(jié)點(diǎn)關(guān)閉文件。
第四章 分布式數(shù)據(jù)庫 HBase
1. 請闡述 HBase 和傳統(tǒng)關(guān)系數(shù)據(jù)庫的區(qū)別。
| 數(shù)據(jù)類型 | 數(shù)據(jù)模型 | 關(guān)系模型 |
| 數(shù)據(jù)操作 | 插入、查詢、刪除、清空，無法實(shí)現(xiàn)表與表之間關(guān)聯(lián) | 插入、刪除、更新、查詢、多表連接 |
| 存儲(chǔ)模式 | 基于列存儲(chǔ)，每個(gè)列族都由幾個(gè)文件保存，不同列族的文件是分離的 | 基于行模式存儲(chǔ)，元組或行會(huì)被連續(xù)地存儲(chǔ)在磁盤中 |
| 數(shù)據(jù)索引 | 只有一個(gè)行鍵索引 | 針對不同列構(gòu)建復(fù)雜的多個(gè)索引 |
| 數(shù)據(jù)維護(hù) | 更新操作不會(huì)刪除數(shù)據(jù)舊的版本，而是生成一個(gè)新的版本 | 用最新的當(dāng)前值去替換記錄中原來的舊值 |
| 可伸縮性 | 輕易地通過在集群中增加或者減少硬件數(shù)量來實(shí)現(xiàn)性能的伸縮 | 很難實(shí)現(xiàn)橫向擴(kuò)展，縱向擴(kuò)展的空間也比較有限 |
☆☆☆ 2. 試述 HBase 各功能組件及其作用。
（1）庫函數(shù)：鏈接到每個(gè)客戶端；
（2）一個(gè) Master 主服務(wù)器：主服務(wù)器 Master 主要負(fù)責(zé)管理和維護(hù) HBase 表的分區(qū)信息和 Region 服務(wù)器列表；
（3）許多個(gè) Region 服務(wù)器：Region 服務(wù)器是 HBase 中最核心的模塊，負(fù)責(zé)維護(hù)分配給自己的 Region，并響應(yīng)用戶的讀寫請求。
3. 試述 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 位置信息 |
4. 試述 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 主服務(wù)器主要負(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)用戶的讀寫請求。
第五章 NoSql 數(shù)據(jù)庫
1. 請比較關(guān)系數(shù)據(jù)庫和 NoSQL 數(shù)據(jù)庫的優(yōu)缺點(diǎn)。
| 關(guān)系數(shù)據(jù)庫 | 以完善的關(guān)系代數(shù)理論作為基礎(chǔ)，有嚴(yán)格的標(biāo)準(zhǔn)，支持事務(wù) ACID 四性，借助索引機(jī)制可以實(shí)現(xiàn)高效的查詢，技術(shù)成熟，有專業(yè)公司的技術(shù)支持 | 可擴(kuò)展性較差，無法較好地支持海量數(shù)據(jù)存儲(chǔ)，數(shù)據(jù)模型過于死板，無法較好支持 Web2.0 應(yīng)用，事務(wù)機(jī)制影響了系統(tǒng)的整體性能等 |
| NoSQL 數(shù)據(jù)庫 | 可以支持超大規(guī)模數(shù)據(jù)存儲(chǔ)，靈活的數(shù)據(jù)模型可以很好支持 Web2.0 應(yīng)用，具有強(qiáng)大的橫向擴(kuò)展能力等 | 缺乏數(shù)學(xué)理論基礎(chǔ)，復(fù)雜查詢性能不高，一般不能實(shí)現(xiàn)事務(wù)強(qiáng)一致性、很難實(shí)現(xiàn)數(shù)據(jù)完整性，技術(shù)尚不成熟，缺乏專業(yè)團(tuán)隊(duì)的技術(shù)支持，維護(hù)較困難等 |
2. 試述 NoSQL 數(shù)據(jù)庫的四大類型。
鍵值數(shù)據(jù)庫：使用一個(gè)哈希表，表中有一個(gè)特定的 Key 和一個(gè)指針指向特定的 Value，Key 可以用來定位 Value，即存儲(chǔ)和檢索具體的 Value。
列族數(shù)據(jù)庫：一般采用列族數(shù)據(jù)模型，數(shù)據(jù)庫由多個(gè)行構(gòu)成，每行數(shù)據(jù)包含多個(gè)列族，不同的行可以具有不同數(shù)量的列族，屬于同一列族的數(shù)據(jù)會(huì)被存放在一起。
文檔數(shù)據(jù)庫：以文檔作為最小單位，大都假定文檔以某種標(biāo)準(zhǔn)化格式封裝并對數(shù)據(jù)進(jìn)行加密，同時(shí)用多種格式進(jìn)行解碼。
圖數(shù)據(jù)庫：使用圖作為數(shù)據(jù)模型來存儲(chǔ)數(shù)據(jù)。
☆☆☆ 3. 試述鍵值數(shù)據(jù)庫、列族數(shù)據(jù)庫、文檔數(shù)據(jù)庫和圖數(shù)據(jù)庫的適用場合和優(yōu)缺點(diǎn)。（主要是優(yōu)缺點(diǎn)，相應(yīng)產(chǎn)品了解即可）
| 鍵值數(shù)據(jù)庫 | 擴(kuò)展性好、靈活性好、大量寫操作是性能高 | 無法存儲(chǔ)結(jié)構(gòu)化 | 內(nèi)容緩存 | Redis、SimpleDB |
| 列族數(shù)據(jù)庫 | 查找速度快、可擴(kuò)展性強(qiáng)、容易進(jìn)行分布式擴(kuò)展、復(fù)雜性低 | 功能較少大都不支持強(qiáng)事務(wù)一致性 | 分布式數(shù)據(jù)存儲(chǔ)與管理 | BigTable、HBase、HadoopDB |
| 文檔數(shù)據(jù)庫 | 性能好、靈活性高、復(fù)雜性低、數(shù)據(jù)結(jié)構(gòu)靈活 | 缺乏統(tǒng)一的查詢語法 | 存儲(chǔ)、索引并管理面向文檔的數(shù)據(jù)或者類似的半結(jié)構(gòu)化數(shù)據(jù) | MongoDB、SisoDB |
| 圖數(shù)據(jù)庫 | 靈活性高、支持復(fù)雜的圖算法、可用于構(gòu)建復(fù)雜的關(guān)系圖譜 | 復(fù)雜性高、只能支持一定的數(shù)據(jù)規(guī)模 | 應(yīng)用于大量復(fù)雜、互連接、低結(jié)構(gòu)化的圖結(jié)構(gòu)場合 | Neo4J、OrientDB |
4. 試述 CAP 理論的具體含義。
C（Consistency）：一致性。在分布式環(huán)境中，多點(diǎn)的數(shù)據(jù)是一致的。
A（Availability）：可用性。指能夠快速獲取數(shù)據(jù)，且在確定的時(shí)間內(nèi)返回操作結(jié)果。
P（Tolerance of Network Partition）：分區(qū)容忍性，指當(dāng)出現(xiàn)網(wǎng)絡(luò)分區(qū)的情況時(shí)，分離的系統(tǒng)也能正常運(yùn)行。
5. 述數(shù)據(jù)庫的 ACID 四性的含義。
A（Atomicity）：原子性。 指事務(wù)必須是原子工作單元，對于其數(shù)據(jù)修改，要么全都執(zhí)行，要么全都不執(zhí)行。
C（Consistency）：一致性。 指事務(wù)在完成時(shí)，必須使所有的數(shù)據(jù)都保持一致狀態(tài)。
I（Isolation）：隔離性。 指并發(fā)事務(wù)所做的修改必須與其他并發(fā)事務(wù)所做的修改隔離。
D（Durability）：持久性。 指事務(wù)完成之后，它對于系統(tǒng)的影響是永久性的，該修改即使出現(xiàn)致命的系統(tǒng)故障也將一直保持。
第六章 云數(shù)據(jù)庫
1. 云數(shù)據(jù)庫有哪些特性。
動(dòng)態(tài)可擴(kuò)展、高可用性、較低的使用代價(jià)、易用性、高性能、免維護(hù)、安全。
2. 試述 UMP 系統(tǒng)的功能。
UMP 系統(tǒng)構(gòu)建在一個(gè)大的集群之上的，通過多個(gè)組件的協(xié)同作業(yè)，整個(gè)系統(tǒng)實(shí)現(xiàn)了對用戶透明的 容災(zāi)、讀寫分離、分庫分表、資源管理、資源調(diào)度、資源隔離和數(shù)據(jù)安全等功能。
1. 容災(zāi)
云數(shù)據(jù)庫必須向用戶提供一直可用的數(shù)據(jù)庫連接，當(dāng) MySQL 實(shí)例發(fā)生故障時(shí)，系統(tǒng)必須自動(dòng)執(zhí)行故障恢復(fù)，所有故障處理過程對于用戶而言是透明的，用戶不會(huì)感知到后臺發(fā)生的一切。
為了實(shí)現(xiàn)容災(zāi)，UMP 系統(tǒng)會(huì)為每個(gè)用戶創(chuàng)建兩個(gè) MySQL 實(shí)例，一個(gè)是主庫，一個(gè)是從庫，而且，這兩個(gè) MySQL 實(shí)例之間互相把對方設(shè)置為備份機(jī)，任意一個(gè) MySQL 實(shí)例上面發(fā)生的更新都會(huì)復(fù)制到對方。同時(shí)，Proxy 服務(wù)器可以保證只向主庫寫人數(shù)據(jù)。
2. 讀寫分離
由于每個(gè)用戶都有兩個(gè) MySQL 實(shí)例，即主庫和從庫，因此 UMP 系統(tǒng)可以充分利用主從庫實(shí)現(xiàn)用戶讀寫操作的分離，實(shí)現(xiàn)負(fù)載均衡。UMP 系統(tǒng)實(shí)現(xiàn)了對于用戶透明的讀寫分離功能，當(dāng)整個(gè)功能被開啟時(shí)，負(fù)責(zé)向用戶提供訪問MySQL數(shù)據(jù)庫服務(wù)的 Proxy 服務(wù)器，就會(huì)對用戶發(fā)起的 SQL 語句進(jìn)行解析，如果屬于寫操作,就直接發(fā)送到主庫，如果是讀操作，就會(huì)被均衡地發(fā)送到主庫和從庫上執(zhí)行。
3. 分庫分表
UMP 支持對用戶透明的分庫分表（Shard/Horizontal Partition）。但是，用戶在創(chuàng)建賬號的時(shí)候需要指定類型為多實(shí)例，并且設(shè)置實(shí)例的個(gè)數(shù)，系統(tǒng)會(huì)根據(jù)用戶設(shè)置來創(chuàng)建多組 MySQL 實(shí)例。除此以外，用戶還需要自己設(shè)定分庫分表規(guī)則，如需要確定分區(qū)字段，也就是根據(jù)哪個(gè)字段進(jìn)行分庫分表，還要確定分區(qū)字段里的值如何映射到不同的 MySQL 實(shí)例上。
4. 資源管理
UMP 系統(tǒng)采用資源池機(jī)制來管理數(shù)據(jù)庫服務(wù)器上的 CPU、內(nèi)存、磁盤等計(jì)算資源，所有的計(jì)算資源都放在資源池內(nèi)進(jìn)行統(tǒng)一分配，資源池是為 MySQL 實(shí)例分配資源的基本單位。整個(gè)集群中的所有服務(wù)器會(huì)根據(jù)其機(jī)型、所在機(jī)房等因素被劃分為多個(gè)資源池，每臺服務(wù)器會(huì)被加人到相應(yīng)的資源池。在資源池劃分的基礎(chǔ)上，UMP還在每臺服務(wù)器內(nèi)部采用 Cgroup 將資源進(jìn)一步地細(xì)化，從而可以限制每個(gè)進(jìn)程組使用資源的上限，同時(shí)保證進(jìn)程組之間相互隔離。
5. 資源調(diào)度
UMP 系統(tǒng)中有 3 種規(guī)格的用戶，分別是數(shù)據(jù)量和流量比較小的用戶、中等規(guī)模用戶以及需要分庫分表的用戶。多個(gè)小規(guī)模用戶可以共享同一個(gè) MySQL 實(shí)例。對于中等規(guī)模的用戶，每個(gè)用戶獨(dú)占個(gè)MySQL 實(shí)例。用戶可以根據(jù)自己的需求來調(diào)整內(nèi)存空間和磁盤空間，如果用戶需要更多的資源，就可以遷移到資源有空閑或者具有更高配置的服務(wù)器上對于分庫分表的用戶，會(huì)占有多個(gè)獨(dú)立的MySQL 實(shí)例，這些實(shí)例既可以共存在同一臺物理機(jī)上，也可以每個(gè)實(shí)例獨(dú)占一臺物理機(jī)。
UMP 通過 MySQL 實(shí)例的遷移來實(shí)現(xiàn)資源調(diào)度。借助于阿里集團(tuán)中間件團(tuán)隊(duì)開發(fā)的愚公系統(tǒng)，UMP 可以實(shí)現(xiàn)在不停機(jī)的情況下動(dòng)態(tài)擴(kuò)容、縮容和遷移。
6. 資源隔離
當(dāng)多個(gè)用戶共享同一個(gè) MySQL 實(shí)例或者多個(gè) MySQL 實(shí)例共存在同一個(gè)物理機(jī)上時(shí)，為了保護(hù)用戶應(yīng)用和數(shù)據(jù)的安全，必須實(shí)現(xiàn)資源隔離，否則，某個(gè)用戶過多消耗系統(tǒng)資源會(huì)嚴(yán)重影響到其他用戶的操作性能。
7. 數(shù)據(jù)安全
數(shù)據(jù)安全是讓用戶放心使用云數(shù)據(jù)庫產(chǎn)品的關(guān)鍵，尤其是企業(yè)用戶，數(shù)據(jù)庫中存放了很多業(yè)務(wù)數(shù)據(jù)，有些屬于商業(yè)機(jī)密，一旦泄露，會(huì)給企業(yè)造成損失。UMP 系統(tǒng)設(shè)計(jì)了多種機(jī)制來保證數(shù)據(jù)安全。
1.SSL 數(shù)據(jù)庫連接。
2.數(shù)據(jù)訪問 IP 白名單。
3.記錄用戶操作日志。
4.SQL 攔截。
3. 試述 UMP 系統(tǒng)的組件及其具體作用。
1. Controller 服務(wù)器：向 UMP 集群提供各種管理服務(wù)，實(shí)現(xiàn)集群成員管理、元數(shù)據(jù)存儲(chǔ)、MySQL 實(shí)例管理、故障恢復(fù)、備份、遷移、擴(kuò)容等功能。
2. Web 控制臺：向用戶提供系統(tǒng)管理界面。
3. Proxy 服務(wù)器：向用戶提供訪問 MySQL 數(shù)據(jù)庫的服務(wù)。除了數(shù)據(jù)路由的基本功能外，Proxy 服務(wù)器中還實(shí)現(xiàn)了屏蔽MySQL實(shí)例故障、讀寫分離、分庫分表、資源隔離、記錄用戶訪問日志等功能。
4. Agent服務(wù)器：管理每臺物理機(jī)上的 MySQL 實(shí)例，執(zhí)行主從切換、創(chuàng)建、刪除、備份、遷移等操作，同時(shí)還負(fù)責(zé)收集和分析 MySQL 進(jìn)程的統(tǒng)計(jì)信息、慢查詢?nèi)罩?#xff08;Slow Query Log）和 bin-log。
5. 日志分析服務(wù)器：存儲(chǔ)和分析 Proxy 服務(wù)器傳入的用戶訪問日志，并支持實(shí)時(shí)查詢一段時(shí)間內(nèi)的慢日志和統(tǒng)計(jì)報(bào)表。
6. 信息統(tǒng)計(jì)服務(wù)器：定期對采集到的用戶的連接數(shù)、QPS 數(shù)值以及 MySQL 實(shí)例的進(jìn)程狀態(tài)用 RRDtool 進(jìn)行統(tǒng)計(jì)。
7. 愚公系統(tǒng)：是一個(gè)進(jìn)行增量復(fù)制的工具，它結(jié)合了全量復(fù)制和 bin-log 分析，可以實(shí)現(xiàn)在不停機(jī)的情況下動(dòng)態(tài)擴(kuò)容、縮容和遷移。
第七章 MapReduce
1. 試述 Map 函數(shù)和 Reduce 函數(shù)的輸入、輸出以及處理過程。
Map 函數(shù)的輸入為分布式文件系統(tǒng)的文件塊，這些文件快的格式是任意的。Map 函數(shù)將輸入的元素轉(zhuǎn)換成 <key, value> 形式的鍵值對，鍵和值的類型也是任意的。
Reduce函數(shù)的輸入是 Map 函數(shù)輸出的結(jié)果即中間結(jié)果，其任務(wù)是將輸入的一系列具有相同鍵的鍵值對以某種方式組合起來，輸出處理后的鍵值對，輸出結(jié)果會(huì)合并成一個(gè)文件。
2. 試述 MapReduce 的工作流程。（需包括提交任務(wù)、Map、Shuffle、Reduce 的過程）
1） MapReduce 框架使用 InputFormat 模塊做 Map 前的預(yù)處理，然后將輸入文件切分為邏輯上的多個(gè) InputSplit。
2） 通過 RecordReader 根據(jù) InputSplit 中的信息來處理 InputSplit 中的具體記錄，加載數(shù)據(jù)并轉(zhuǎn)換為適合 Map 任務(wù)讀取的鍵值對，輸入給Map任務(wù)。
3） Map 任務(wù)會(huì)根據(jù)用戶自定義的映射規(guī)則，輸出一系列的 <key, value> 作為中間結(jié)果。
4） Shuffle：對 Map 任務(wù)輸出結(jié)果進(jìn)行分區(qū)、排序、合并、歸并等操作，得到 <key,value-list> 形式的中間結(jié)果，再交給對應(yīng)的 Reduce 進(jìn)行處理。
5） Reduce 以一系列 <key, value-list> 中間結(jié)果作為輸入，執(zhí)行用戶定義的邏輯，輸出結(jié)果給 OutputFormat 模塊。
6） OutputFormat 模塊會(huì)驗(yàn)證輸出目錄是否存在以及輸出結(jié)果類型是否符合配置文件中的配置類型，如果都滿足，就輸出 Reduce 的結(jié)果到分布式文件系統(tǒng)。
☆☆☆ 3. Shuffle 過程是 MapReduce 過程的核心，也被稱為奇跡發(fā)生的地方，試分析 Shuffle 過程的作用。（答案不全，看書 P135）
對 Map 任務(wù)輸出結(jié)果進(jìn)行分區(qū)、排序、合并、歸并等處理并交給 Reduce 的過程，減少磁盤 I/O 的讀寫次數(shù)，并減小從 Map 到 Reduce 之間的數(shù)據(jù)傳遞量。
4. 早期版本的 HDFS，其默認(rèn)塊（Block）大小為 64MB，而較新的版本默認(rèn)為 128MB，采用較大的塊有什么影響和優(yōu)缺點(diǎn)。
采用較大的塊說明分片的數(shù)量較小，那么 Map 任務(wù)也較少，導(dǎo)致任務(wù)的并行化程度不高，不能充分利用集群資源，拖慢作業(yè)運(yùn)行速度。
采用較小的塊，說明 Map 任務(wù)較多，而創(chuàng)建多個(gè) Map 任務(wù)進(jìn)程需要耗費(fèi)大量時(shí)間。
塊的大小設(shè)置主要從以下考慮：減少磁盤尋道時(shí)間、減少 NameNode 內(nèi)存消耗、Map 崩潰問題、監(jiān)管時(shí)間問題、問題分解問題、約束 Map 輸出。
第八章 Hadoop 再探討
1. 請描述 HDFS HA 架構(gòu)組成組件及其具體功能。
在一個(gè)典型的 HA 集群中，一般設(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ǒng)元數(shù)據(jù)，當(dāng)名稱節(jié)點(diǎn)出現(xiàn)故障時(shí)提供快速恢復(fù)能力。也就是說，在 HDFS HA 中，處于待命狀態(tài)的名稱節(jié)點(diǎn)提供了 “ 熱備份 ”，一旦活躍名稱節(jié)點(diǎn)出現(xiàn)故障，就可以立即切換到待命名稱節(jié)點(diǎn)，不會(huì)影響到系統(tǒng)的正常對外服務(wù)。
2. 請分析 HDFS HA 架構(gòu)中數(shù)據(jù)節(jié)點(diǎn)如何和名稱節(jié)點(diǎn)保持通信。
在 HDFS 聯(lián)邦中，所有名稱節(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)的指令。
3. 請闡述 MapReduce 1.0 體系結(jié)構(gòu)中存在的問題。
1）存在單點(diǎn)故障問題。
2）JobTracker “ 大包大攬 ” 導(dǎo)致任務(wù)過重。
3）容易出現(xiàn)內(nèi)存溢出。
4）資源劃分不合理。
總結(jié)
以上是生活随笔為你收集整理的大数据技术原理与应用（最后三天备考！！！）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 相机标定（二）深入理解四大坐标系与其变换
- 下一篇： 相机标定(三) —— 畸变校正