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