Hadoop快速入門

提到列式(Column Family)數據庫，就不得不提Google的BigTable，其開源版本就是我們熟知的HBASE。BigTable建立在谷歌的另兩個系統GFS和Chubby之上，這三個系統和分布式計算編程模型MapReduce共同構成Google云計算的基礎，Chubby解決主從自動切換的基礎。接下來通過一個表格對比來引入Hadoop。

Hadoop是有Apache Lucene的作者Boug Cutting開發的，其主體結構如下圖所示。

HDFS（Hadoop File System）

NameNode:整個文件系統的大腦，提供整個系統的目錄信息并管理各個數據服務器。

DataNode:分布式文件系統中每一個文件被切割為若干數據塊，每個數據塊存儲在不同服務器，這些就是數據服務器。

Block:每個被切分的數據塊就是一段文件內容，其是基本的存儲單位，被稱為數據塊，典型大小為64MB。

Tip:由于硬件錯誤是常態，HDFS是很多臺Server的集合，因而錯誤檢測和恢復是核心功能；其以流式讀為主，做批量操作，關注數據訪問的高吞吐量。

HDFS采用master/slave架構，一個HDFS集群由一個NameNode和若干DataNode組成，中心服務器NameNode負責管理文件系統的namespace和客戶端對文件的訪問。DataNode一般一個節點一個，負責管理節點上附帶的存儲。在內部，一個文件被分成一個或多個block，這些block存儲在DataNode集合中。NameNode和DataNode均可運行在廉價的linux機器上，HDFS由java語言開發，跨平臺好，總體結構示意圖如下所示。

復制：采用rack-aware策略改進數據可靠性和網絡帶寬的利用；NameNode決定每個DataNode的Rack id；大多數情況，replication因子是3，簡單來說就是將一個副本放在本地機架節點，一個副本放在同一機架另一個節點，最后一個放在不同機架；在讀取時，會選擇最近的副本；NameNode啟動時會進入SafeMode狀態，該狀態時，NameNode不會進行數據塊的復制，這是會檢測DataNode的副本數量，如果滿足要求則認為安全。

NameNode用于存儲元數據，任何修改均被Editlog記錄，通訊協議基于TCP/IP，可以通過java API調用。

安裝Hadoop，步驟如下所示

 View Code

在分布式模式下，hadoop配置文件中不能使用ip，必須使用主機名，安裝hadoop必須在所有節點上使用相同配置和安裝路徑，并用相同用戶啟動。Hadoop中的HDFS和Map-Reduce可以分別啟動，NameNode和JobTracker可以部署到不同節點，但小集群一般在一起，注意元數據安全即可。

Hdfs常見操作，請見下表所示，在實踐中，一般都是通過API調用，了解下就好

通過Java調用hdfs的示例如下所示，其實就是一個文件系統

 View Code

• Map Reduce核心概念

Job: 用戶的每一個計算請求就是一個作業

JobTracker:用戶提交作業的服務器，同時它還負責各個作業任務的分配，管理所有的任務服務器。

Task:一個都需要拆分，交個多個服務器完成，拆分出來的執行單位就是任務

TaskTracker:就是任勞任怨的工人，負責執行具體的任務。

• Map Reduce計算模型

在hadoop中，每一個MapReduce任務被初始化為一個Job,每個Job又被分為兩個階段：Map階段、Reduce階段。這兩個階段分別用兩個函數表示，Map函數接受一個<key,value>輸入，然后產生一個<key,value>的中間輸出；之后hadoop會將具有相同中間key的value集合傳給Reduce函數，之后Reduce處理后得到<key,value>形式輸出。

在Java中接入Hadoop的配置與代碼如下所示。

 View Code

MapReduce的數據流和控制流

zookeeper主要用來解決分布式應用中經常遇到的數據管理的問題，如統一命名服務、狀態同步服務、集群管理和分布式應用配置項的管理，Zookeeper典型的應用場景(配置文件的管理、集群管理、同步鎖、Leader選舉和隊列管理等)。

Zookeeper配置安裝的步驟如下所示

 View Code

ZooKeeper數據模型，其會維護一個層次關系的數據結構，非常類似標準文件系統

ZooKeeper的基礎使用，其作為一個分布式服務框架，主要用于解決分布式集群的一致性問題，它提供類似文件系統目錄節點樹方式的數據存儲，并會維護和監控數據的狀態變化，其常見方法如下所示。

java調用zookeeper的API示例如下

 View Code

ZooKeeper的典型應用場景

統一命名服務(Name Service):分布式應用，通常需要一整套的命名規則，一般使用樹形命名，這兒和JNDI很相似。

配置管理：ZooKeeper統一管理配置信息，保存在對應目錄，一旦變化，對應機器就會收到通知(觀察者)。

集群管理：ZooKeeper不僅能維護當前集群中及其的服務狀態，并能選出一個總管(Leader Election)，從而避免單點故障，示例代碼如下。

共享鎖(Locks):共享鎖在同一個進程容易實現，但再不同Server見不好實現，但Zookeeper卻很容易實現，方式就是需要獲取鎖的Servere創建一個EPHEMERAL_SEQUENTIAL目錄節點，然后調用getChildren方法獲得當前目錄節點列表中最小的目錄節點，并判斷，如果未自己建立，則獲得鎖，如果不是就調用exist方法監控節點變化，一直到自己創建的節點時最小，從而獲得鎖，釋放很賤，只要刪除前面自己創建的目錄節點就OK。

隊列管理(Queue Management):可以處理兩類隊列，一種是當成員齊聚時，隊列才可用，否則一直等待，被稱為同步隊列；一種是按照FIFO方式進行入隊和出隊，例如實現生產-消費者模型。

HBase（邏輯結構）是BigTable的開源版，其建立在HDFS（物理結構）之上，提供高可靠性、高性能、列存儲和可伸縮、實時讀寫的數據庫系統。它結余NOSQL和RDBMS之間，僅能通過主鍵和主鍵range來檢索數據，支持單行事務（可通過hive支持來實現多表join等復雜操作），主要用于存儲非結構和半結構化的松散數據。與Hadoop一樣，Hbase主要依靠橫向擴展來提高計算和存儲能力。

Hbase的表具有以下特點：

大：一個表可以有上億行

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

稀疏：對于空的列，并不占用空間，因此表可以設計的非常稀疏。

• 邏輯視圖:HBase以表的形式存儲數據，表由行和列組成，列劃分為若干個列族row family,如下表所示。

Row Key：檢索數據的主鍵，訪問HBase中的行，可以通過單個row key（字典序，數值型數據需要補0）訪問；通過row key的range的訪問；全表掃描。

列族：表中的每一列，都歸屬于列族，列族是表schema的一部分，必須在使用前定義，而列不是，關鍵理解。列名都以列族作為前綴，例如courses:history和courses:math都數據courses列族。

時間戳：通過row和column確定一個存儲單元cell，每個cell保存同一份數據的多個版本，通過時間戳來索引。時間戳為64位證書，精確到毫秒，按時間倒序排列。為了避免版本過多，一般通過個數或時間來回收。

Cell:由{row key, column(=<family>+<label>),version}唯一確定的單元，cell中數據沒有類型，以字節碼存儲。

• 物理存儲：指如何將大表分布的存儲在多臺服務器。

特點：Table上所有行使用row key排列;Table在行方向上分割為多個HRegion;HRegion按大小分割，每個表已開始只有一個region，隨著數據不斷插入，region增大，當超過閾值是，會分裂成連個新的HRegion；HRegion是HBase中分布式存儲和負載均衡最小單元，表示不同Region可以分布在不同RegionServer上；HRegion是分布式存儲的最小單元，但不是最小存儲單元，實際上，一個Region由多個Store組成，一個Store保存一個columns family，一個Store又由一個memStore和0-多個StoreFile（重點是StoreFile就是一個Hdfs中文件，通過壓縮存儲減少通信消耗，這兒就找到了對應關系，還可以細分，就不介紹了）組成。（腦海里有了大體的印象）

• 系統架構

Client：包含訪問HBase接口，client維護一些cahce來加快訪問，比如region未知信息。

ZooKeeper:保證任何時候集群只有一個master；存儲所有region尋址接口；實施監控Region Server狀態，將其上下線消息實時通知給master；存儲Hbase的schema,包含哪些table,每個table的column family；為region server分配region；負責Region server的負載均衡；發現失效的Region Server并重新分配其上Region，GFS上的垃圾文件回收；處理schema更新請求。

Region Server：維護Master分配給它的Region，處理這些Region的IO請求；切分在運行中變得過大的Region。

Tip:可以看到client訪問HBase數據的過程并不需要master參與，尋址訪問zookeeper和Region Server，數據讀寫訪問Region Server,master只維護table和Region的元數據，負載低。

• 關鍵算法和流程

Region定位：大表使用三層類似B+樹的結構來存儲Region位置，第一次保存zookeeper中數據，持有RootRegion位置；第二層RootRegion是.META表的第一個Region，其中保存了其他Region的位置；第三層是個特殊的表，存儲HBase中所有數據表的Region位置信息。

讀寫過程：HBase使用MemStore和StoreFile存儲對表的更新。數據在更新時首先寫入Log和MemStore，MemStore中的數據是排序的，當MemStore累計到一定閾值，會創建新MemStore，并將老MemStore添加到Flush隊列，有單獨線程寫到磁盤，稱為一個StoreFile，同時系統會在zookeeper記錄一個Redo point，表示更新已經持久化。系統出現問題是，可以使用log來恢復check point之后的數據。（思路和傳統數據庫一致）

Region分配：任何時刻，一個region只能分配給一個server，master記錄了當前可用的Server以及當前region的分配情況，當存在未分配region且有server有可用空間時，master就給這個server發送一個裝載請求，分配該region。

Region Server的上下線：master通過zookeeper來跟蹤region server狀態，當某個server啟動時，會在zookeeper的server目錄建立代表自己的文件，并獲得該文件獨占鎖，由于master訂閱了該目錄的變更小心，因此當文件出現增刪時，可以接到通知。下線時，斷開與zookeeper會話，釋放獨占鎖，這時master會發現并刪除對應目錄文件，并將原有region分配給其他server。

master的上下線：從zookeeper獲取唯一master鎖，阻止其他人稱為master；掃描zookeeper上server目錄，獲得region server列表；與每個server通信，獲得Region分配的情況；掃描META.region集合，計算得到當前未分配的region,放入待分配列表。

• 安裝與配置

 View Code

• 常見操作

比如創建一個如下表格

 View Code

Tip:

終于完成了，帥，這部分內容之后重點在于既有的集成解決方案，包括docker上的部署等。

此外，有空考慮區塊鏈方面的學習，同時把數據結構好好再學習下，感覺還是不太OK。，比如B+樹。