2.3 大數據架構

基于上述大數據的特征，通過傳統 IT技術存儲和處理大數據成本高昂。一個企業要大力發展大數據應用首先需要解決兩個問題：一是低成本、快速地對海量、多類別的數據進行抽取和存儲；二是使用新的技術對數據進行分析和挖掘，為企業創造價值。因此，大數據的存儲和處理與云計算技術密不可分，在當前的技術條件下，基于分布式系統的Hadoop，被認為是最適合處理大數據的技術平臺。Hadoop提供的功能：利用服務器集群，根據用戶的自定義業務邏輯，對海量數據進行分布式處理。廣義上來說，Hadoop通常是指一個更廣泛的概念——Hadoop生態圈。Hadoop生態圈如圖2.3所示。

各組件簡介如下。

1．主要模塊

（1）HDFS：分布式文件系統。

（2）MAPREDUCE：分布式運算程序開發框架，用于大規模數據集的并行計算。

（3）HBASE：基于 Hadoop的分布式海量數據庫，可以將結構化數據文件映射為數據庫表，并提供常用的SQL支持。Hive查詢引擎將SQL語句轉化為Hadoop平臺的MapReduce任務運行。

2．數據管道

（1）Sqoop：主要用于跟關系數據庫進行數據交互，通過JDBC方式實現數據遷移。

（2）Flume:Cloudera提供的日志收集框架，用于將海量日志數據并行導入HDFS或者Hive中。

（3）DistCp：一般用于在兩個HDFS集群中傳輸數據，但目前此命令只支持同版本下集群數據遷移，主要用于冷熱數據遷移、測試等場景。

（4）Scribe:Facebook開源的日志收集系統，它能夠從各種日志源上收集日志，存儲到一個中央存儲系統（可以是 NFS，分布式文件系統等）上，以便于進行集中統計分析處理。它為日志的“分布式收集，統一處理”提供了一個可擴展的、高容錯的方案。

3．數據分析

（1）Hive：提供了一套類數據庫的數據存儲和處理機制，并采用 HQL（類 SQL ）語言對這些數據進行自動化管理和處理。Hive中的海量結構化數據被看成一個個的表，而實際上這些數據是分布式存儲在HDFS中的。注意，Hive是離線查詢工具，由于其內部機制，需要把 SQL轉換成MapReduce后進行分布式查詢，所以最短查詢時間也需要十幾秒，適用于海量數據場景，不適合即時查詢需求。

（2）Impala:Impala是Google Dremel的Java實現版本之一。Dermel由Google設計開發，最顯著的特性就是支持SQL方式在秒級別分析TB級別數據（1TB數據3秒完成分析計算）。Impala1.0版本完全兼容SQL92規范，不同于Hive將SQL轉換為MapReduce方式，Impala通過與商用并行關系數據庫中類似的分布式查詢引框架（由 Query Planner、Query Coordinator和Query Exec Engine三部分組成，與MR相似的技術架構，但即時性更好），可以直接從HDFS或者HBase中用SELECT、JOIN和統計函數查詢數據，性能是Hive（0.81）的3～90倍，目前剛發布的Hive1.0在原有性能上有很大提升，都屬于數據倉庫工具，但Impala架構更先進。

（3）Pig:Apache Pig是一個分析大規模數據集的平臺，其使用場景和Hive相似，Hive更簡單，使用類SQL進行數據分析，Pig使用腳本語言，編程性更強，具體選擇主要依靠程序員的熟悉程度及場景復雜度決定。

（4）Mahout：主要用于并行數據挖掘，該框架對目前主流數據挖掘算法都已經基于MapReduce進行了實現，節省很多額外開發時間。如推薦引擎、用戶關系引擎、GiS熱點聚類都可以基于此框架算法來實現。

（5）Scalding：使用Scala編程語言封裝MapReduce編程模型，支持DSL（domain-specific language）語法編程，易用性大大提升。主要用于高并發簡單ETL處理場景。

4．任務調度

（1）Oozie：其作用就是將多個 MapReduce作業連接到一起，作為一個工作流程執行。一般情況下，一個大型任務由多個 MapReduce組成。如果不用 Oozie，需要手動編寫大量連接和轉換代碼，用于串聯起多個MR任務流程，比較耗時，出錯率和維護率也比較高。Oozie通過xml方式配置連接起整個任務流程。與傳統工作流引擎作用相似。

（2）Azkaban：美國知名互聯公司Linkedin發布的開源產品，屬于 Oozie的同類產品，在細節上有區別。

5．管理

Hue：它是運營和開發Hadoop應用的圖形化用戶界面。對單獨的用戶來說不需要額外的安裝。另外，Hue具備簡單的權限和用戶管理功能，這是其他開源UI不具備的。

Hadoop是一個分布式的基礎架構，能夠讓用戶方便高效地利用運算資源和處理海量數據，目前已在很多大型互聯網企業得到了廣泛應用，如亞馬遜、Facebook、Yahoo等。它是一個開放式的架構，架構成員也在不斷擴充完善中。

Hadoop是一個開發和運行處理大規模數據的軟件平臺，屬于 Apache開源組織，用Java語言開發，用于實現在大量計算機組成的集群中對海量數據進行分布式存儲和計算。Hadoop最核心的設計包含兩個模塊：HDFS和MapReduce。其中HDFS提供海量數據的存儲，MapReduce提供海量數據的分布式計算能力。

2.3.1 HDFS系統

1. HDFS系統的概念和特性

首先，HDFS系統是一個文件系統，用于存儲文件，通過統一的命名空間——目錄樹來定位文件。其次，HDFS系統是分布式的，由很多服務器聯合起來實現其功能，集群中的服務器有各自的角色。

HDFS系統在大數據中的應用是為各類分布式運算框架提供數據存儲服務，將大文件、大批量文件，分布式存放在大量的服務器上，以便于采取分而治之的方式對海量數據進行運算分析。

HDFS系統的特性如下。

（1）有高容錯性的特點。

（2）整個系統部署在低廉的硬件上。

（3）提供高傳輸率來訪問應用程序的數據。

（4）適合超大數據集的應用程序。

（5）流式數據訪問。

HDFS本身是軟件系統，不同于傳統硬盤和共享存儲介質，在文件操作上有其不同之處。

（1）不支持文件隨機寫入。支持隨機讀，但沒有隨機寫入機制，這與HDFS文件寫入機制有關，所以不支持斷點續傳等功能。

（2）需要客戶端與HDFS交互。目前已有開源支持HDFSmount到Linux服務器上，但性能非常不好。

（3）適合大文件讀取場景。因為其分塊冗余存儲機制，其存儲架構在處理小于其分塊文件大小的文件時，會浪費管理節點資源，導致效率低。

（4）吞吐和并發具備橫向擴展能力。單節點系統比傳統硬盤效率低很多，但在大量機器集群環境下，其吞吐和并發能力可以線性提升，遠遠高于單一硬件設備。

（5）不適合高響應系統。由于HDFS是為高數據吞吐量應用而設計的，以高延遲為代價。

2. HDFS的結構

HDFS中有3個重要角色：NameNode、DataNode和Client，如圖2.4所示。

對外部客戶機而言，HDFS就像一個傳統的分級文件系統，可以刪除、移動或重命名文件等。但是HDFS架構是基于一組特定的節點構建的，這是由它自身的特點決定的。這些節點包括NameNode（僅1個），它在HDFS內部提供元數據服務；DataNode為HDFS提供存儲塊。

存儲在HDFS中的文件被分成塊，然后將這些塊復制到多臺計算機中（DataNode）。這與傳統的RAID架構大不相同。塊的大小（通常為64MB）和復制的塊數量在創建文件時由客戶機決定。NameNode可以控制所有文件操作。HDFS內部的所有通信都基于標準的TCP/IP協議。

1）NameNode

NameNode是一個通常在HDFS實例中的單獨機器上運行的軟件。它負責管理文件系統名稱空間和控制外部客戶機的訪問。NameNode決定是否將文件映射到DataNode上的復制塊上。對于最常見的3個復制塊，第一個復制塊存儲在同一機架的不同節點上，最后一個復制塊存儲在不同機架的某個節點上。Metadata所有的相關服務都是由NameNode提供，包括 filename->block（namespace），以及 block->DataNode的對應表。其中，前者通過FsImage寫入本地文件系統中，而后者是通過每次HDFS啟動時，DataNode進行blockreport后在內存中重構的數據結構。

實際的I/O實務并沒有經過NameNode，只有表示DataNode和塊的文件映射的元數據經過NameNode。當外部客戶機發送請求要求創建文件時，NameNode會以塊標識和該塊的第一個副本的DataNode的IP地址作為響應。這個NameNode還會通知其他將要接收該塊的副本的DataNode。

NameNode在一個稱為 FsImage的文件中存儲所有關于文件系統名稱空間的信息。這個文件和一個包含所有事務的記錄文件（EditLog）將存儲在NameNode的本地文件系統上。FsImage和EditLog文件也需要復制副本，以防文件損壞或NameNode系統走失。

2）DataNode

DataNode也是一個通常在HDFS實例中的單獨機器上運行的軟件。Hadoop集群中包含一個 NameNode和大量 DataNode。DataNode通常以機架的形式組織，機架通過一個交換機將所有系統連接起來。

DataNode響應來自HDFS客戶機的讀寫請求。并且還響應來自NameNode的創建、刪除和復制塊的命令。NameNode依賴來自每個 DataNode的定期心跳（Heartbeat）消息。每條消息都包含一個塊報告，NameNode可以根據這個報告驗證塊映射和其他文件系統元數據。

分布式文件存儲的數據節點，存儲著文件塊（Block），而文件是由文件塊組成的，每個塊存儲在多個（可配，默認為3）不同的DataNode可以提高數據的可靠性。

如果客戶機想將文件寫到HDFS上，首先需要將文件緩存到本地的臨時存儲區。如果緩存的數據大于所需的HDFS塊大小，創建文件的請求將發送給 NameNode。NameNode將以 DataNode標識和目標塊響應客戶機。同時也通知將要保存文件塊副本的DataNode。當客戶機開始將臨時文件發送給第一個 DataNode時，將立即通過管道方式將塊方式內容轉發副本DataNode。客戶機也負責創建保存在相同HDFS名稱空間中的校驗文件。在最后的文件塊發送后，NameNode將文件創建提交到它的持久化數據存儲（EditLog和FsImage文件）。

3）Client

用于實現客戶端文件存儲的所有操作，包括文件的增刪以及查詢等。

3. HDFS文件寫入與讀取

HDFS文件的寫入流程如圖2.5所示。

（1）客戶端通過Distributed FileSystem上的create（）方法指明一個欲創建的文件的文件名，然后client通過RPC方式與NameNode通信創建一個新文件映射關系。

（2）客戶端寫數據：FSData OutputStream把寫入的數據分成包（packet），放入一個中間隊列——數據隊列（data queue）中去。OutputStream從數據隊列中取數據，同時向NameNode申請一個新的block來存放它已經取得的數據。NameNode選擇一系列合適的DataNode（個數由文件的replication數決定，默認為3，構成一個管道線（pipeline），所以管道線中就有3個 DataNode。OutputStream把數據流式地寫入到管道線中的第一個DataNode中，第一個DataNode再把接收到的數據轉到第二個DataNode中，以此類推。

（3）FSData OutputStream同時也維護著另一個中間隊列——確認隊列（ack queue），確認隊列中的包只有在得到管道線中所有的DataNode的確認以后才會被移出確認隊列。

（4）所有文件寫入完成后，關閉文件寫入流。

從以上文件寫入流程，可以總結出HDFS文件寫入具備如下特性。

● 響應時間比較長。

● 文件寫入效率與block塊數和集群數量相關。

HDFS文件的讀取流程如圖2.6所示。

（1）打開文件流（open（））。

（2）從NameNode讀取文件塊位置列表。

（3）FSDataInputSteam打開read（）方法。

（4）根據文件塊與DataNode的映射關系。

（5）從不同的DataNode中并發讀取文件塊。

（6）文件讀取完畢，關閉input流。

因為冗余機制，當HDFS文件讀取壓力比較大的時候，可以通過提高冗余數的方式，NameNode可以通過輪詢方式，分配不同client訪問不同DataNode上的相同文件塊，提升整體吞吐率。

Hadoop在創建新文件時是如何選擇block的位置的呢，綜合來說，要考慮帶寬（包括寫帶寬和讀帶寬）和數據安全性，如圖2.7所示。

如果把3個備份全部放在一個 DataNode上，雖然可以避免寫帶寬的消耗，但幾乎沒有提供數據冗余帶來的安全性，如果這個 DataNode宕機，那么這個文件的所有數據就全部丟失了。另一個極端情況是，如果把3個冗余備份全部放在不同的機架上，甚至數據中心里面，雖然這樣做數據很安全，但寫數據會消耗很多的帶寬。HDFS提供了一個默認備份分配策略：把第一個備份放在與客戶端相同的DataNode上，第二個放在與第一個不同機架的一個隨機DataNode上，第三個放在與第二個相同機架的隨機DataNode上。如果備份數大于3，則隨后的備份在集群中隨機存放，Hadoop會盡量避免過多的備份存放在同一個機架上。

2.3.2 MapReduce

MapReduce是 Google提出的并行計算架構，用于大規模數據集（TB級以上）的并行運算。此算法的計算能力，隨著計算節點的數量增加而線性上升。

圖2.8表示一個MapReduce計算處理思路，可以簡要分解為兩部分，數據分塊映射處理（Map）和數據結果聚合（Reduce）兩個步驟，源數據可以存儲在HDFS或者第三方數據源上，計算過程臨時數據存儲在HDFS和內存中，最終獲得我們需要的計算結果，其具體處理流程如圖2.9所示。

1. Map端

（1）每個輸入分片會讓一個Map任務來處理，默認情況下，以HDFS的一個塊的大小（默認為64MB）為一個分片，當然我們也可以自行設置塊的大小。Map輸出的結果會暫時放在一個環形內存緩沖區中（該緩沖區的大小默認為100MB），當該緩沖區快要溢出時（默認為緩沖區大小的80%），會在本地文件系統中創建一個溢出文件，將該緩沖區中的數據寫入這個文件。

（2）在寫入磁盤之前，線程首先根據 Reduce任務的數目將數據劃分為相同數目的分區，也就是一個 Reduce任務對應一個分區的數據。這樣做是為了避免有些 Reduce任務分到大量數據，而有些 Reduce任務卻分到很少數據，甚至沒有分到數據的尷尬局面。其實分區就是對數據進行 Hash的過程。然后對每個分區中的數據進行排序，如果此時設置了Combiner，將排序后的結果進行 Map合并操作，這樣做的目的是讓盡可能少的數據寫入磁盤。

（3）當Map任務輸出最后一個記錄時，可能會有很多溢出文件，這時需要將這些文件合并。合并的過程中會不斷地進行排序和合并操作，目的有兩個：①盡量減少每次寫入磁盤的數據量；②盡量減少下一復制階段網絡傳輸的數據量。最后合并成了一個已分區且已排序的文件。為了減少網絡傳輸的數據量，可以將數據壓縮。

（4）將分區中的數據復制給相對應的Reduce任務。Map任務一直和其父 TaskTracker保持聯系，而 TaskTracker又一直和JobTracker保持心跳。所以 JobTracker中保存了整個集群中的宏觀信息。Reduce任務只需向JobTracker獲取對應的Map輸出位置。

2. Reduce端

（1）Reduce會接收到不同的Map任務傳來的數據，并且每個 Map傳來的數據都是有序的。如果 Reduce端接收的數據量相當小，則直接存儲在內存中，如果數據量超過了該緩沖區大小的一定比例，則對數據合并后溢寫到磁盤中。

（2）隨著溢寫文件的增多，后臺線程會將它們合并成一個更大的有序的文件，這樣做是為了給后面的合并節省時間。其實不管在Map端還是 Reduce端，MapReduce都是反復地執行排序、合并操作，這就是為什么有些人會說：排序是Hadoop的靈魂。

（3）合并的過程中會產生許多中間文件（寫入磁盤了），但 MapReduce會讓寫入磁盤的數據盡可能地少，并且最后一次合并的結果并沒有寫入磁盤，而是直接輸入到Reduce函數。

3. Shuffle

在Hadoop的集群環境中，大部分Map任務和Reduce任務是在不同的Node上執行，主要的開銷是網絡開銷和磁盤I/O開銷，因此Shuffle的主要作用如下。

（1）完整地從Map端傳輸到Reduce端。

（2）跨節點傳輸數據時，盡可能減少對帶寬的消耗（注意是 Reduce執行的時候去拉取Map端的結果）。

（3）減少磁盤I/O開銷對任務的影響。

2.3.3 HBase

HBase是Google Bigtable的開源實現版本。數據存儲在HDFS中，繼承了HDFS的高可靠性、可伸縮架構，同時自己實現了高性能、列存儲、實時讀寫的特性。

不同于HDFS的高吞吐低響應，HBase設計用于高并發讀寫場景。

（1）HBase基于HadoopHDFSappend方式進行數據追加操作，非常適合列族文件存儲架構。

（2）HBase寫請求，都會先寫redo log，然后更新內存中的緩存。緩存會定期地刷入HDFS。文件基于列創建，因此任何一個文件（MapFile）只包含一個特定列的數據。

（3）當某一列的MapFile數量超過配置的閾值時，一個后臺線程就開始將現有的MapFile合并為一個文件，這個操作叫 Compaction。在合并的過程中，讀寫不會被阻塞。

（4）讀操作會先檢查緩存，若未命中，則從最新的MapFile開始，依次往最老的MapFile找數據。可以想象一次隨機讀操作可能需要掃描多個文件。

HBase的文件和日志確實都存儲在HDFS中，但通過精致設計的算法實現了對高并發數據隨機讀寫的完美支持，這依賴于 HBase數據排序后存儲的特性。與其他的基于 Hash尋址的NoSQL數據庫有很大不同。

在使用特性上，原生 HBase不支持 JDBC驅動，也不支持 SQL方式進行數據查詢，只有簡單的PUT和GET操作。數據查詢通過主鍵（rowkey）索引和Scan查詢方式實現，在事務上，HBase支持單行事務（可通過上層應用和模塊如hive或者coprocessor來實現多表join等復雜操作）。HBase主要用來存儲非結構化和半結構化的松散數據，如圖2.10所示。

HBase中的表一般有以下特點。

（1）大：一個表可以有上億行，上百萬列。

（2）面向列：面向列（族）的存儲和權限控制，列（族）獨立檢索。

（3）稀疏：對于為空（null）的列，并不占用存儲空間（每個列族是一個文件，沒內容的情況下不會占用空間），因此，表可以設計得非常稀疏。

（4）HBase適用于海量高并發文本數據寫入、存儲、查詢需求場景，這些數據量是傳統數據庫難以滿足的，以下列了一些適用場景。

（5）詳單管理、查詢。

（6）GiS數據存儲、統計。