Hadoop概要

到底是業(yè)務(wù)推動(dòng)了技術(shù)的發(fā)展，還是技術(shù)推動(dòng)了業(yè)務(wù)的發(fā)展，這個(gè)話(huà)題放在什么時(shí)候都會(huì )惹來(lái)一些爭議。

隨著(zhù)互聯(lián)網(wǎng)以及物聯(lián)網(wǎng)的蓬勃發(fā)展，我們進(jìn)入了大數據時(shí)代。IDC預測，到2020年,全球會(huì )有44ZB的數據量。傳統存儲和技術(shù)架構無(wú)法滿(mǎn)足需求。在2013年出版的《大數據時(shí)代》一書(shū)中，定義了大數據的5V特點(diǎn)：Volume(大量)、Velocity(高速)、Variety(多樣)、Value(低價(jià)值密度)、Veracity(真實(shí)性)。

當我們把時(shí)間往回看10年，來(lái)到了2003年，這一年Google發(fā)表《Google File System》，其中提出一個(gè)GFS集群中由多個(gè)節點(diǎn)組成，其中主要分為兩類(lèi)：一個(gè)Master node，很多Chunkservers。之后于2004年Google發(fā)表論文并引入MapReduce。2006年2月，Doug Cutting等人在Nutch項目上應用GFS和 MapReduce思想,并演化為Hadoop項目。

Doug Cutting曾經(jīng)說(shuō)過(guò)他非常喜歡自己的程序被千萬(wàn)人使用的感覺(jué)，很明顯，他做到了;下圖就是本尊照片，帥氣的一塌糊涂

2008年1月, Hadoop成為Apache的開(kāi)源項目。

Hadoop的出現解決了互聯(lián)網(wǎng)時(shí)代的海量數據存儲和處理，其是一種支持分布式計算和存儲的框架體系。假如把Hadoop集群抽象成一臺機器的話(huà)，理論上我們的硬件資源(CPU、Memoery等)是可以無(wú)限擴展的。

Hadoop通過(guò)其各個(gè)組件來(lái)擴展其應用場(chǎng)景，例如離線(xiàn)分析、實(shí)時(shí)處理等。

Hadoop相關(guān)組件介紹

本文主要是依據Hadoop2.7版本，后面沒(méi)有特殊說(shuō)明也是按照此版本

HDFS

HDFS,Hadoop Distributed File System (Hadoop分布式文件系統)被設計成適合運行在通用硬件(commodity hardware)上的分布式文件系統。它和現有的分布式文件系統有很多共同點(diǎn)，例如典型的Master/Slave架構(這里不準備展開(kāi)介紹);然而HDFS是一個(gè)高度容錯性的系統，適合部署在廉價(jià)的機器上。

關(guān)于HDFS主要想說(shuō)兩點(diǎn)。

• HDFS中的默認副本數是3，這里涉及到一個(gè)問(wèn)題為什么是3而不是2或者4。
• 機架感知(Rack Awareness)。

只有深刻理解了這兩點(diǎn)才能理解為什么Hadoop有著(zhù)高度的容錯性，高度容錯性是Hadoop可以在通用硬件上運行的基礎。

Yarn

Yarn,Yet Another Resource Negotiator(又一個(gè)資源協(xié)調者)，是繼Common、HDFS、MapReduce之后Hadoop 的又一個(gè)子項目。Yarn的出現是因為在Hadoop1.x中存在如下幾個(gè)問(wèn)題：

• 擴展性差。JobTracker兼備資源管理和作業(yè)控制兩個(gè)功能。
• 可靠性差。在Master/Slave架構中,存在Master單點(diǎn)故障。
• 資源利用率低。Map Slot(1.x中資源分配的單位)和Reduce Slot分開(kāi),兩者之間無(wú)法共享。
• 無(wú)法支持多種計算框架。MapReduce計算框架是基于磁盤(pán)的離線(xiàn)計算 模型,新應用要求支持內存計算、流式計算、迭代式計算等多種計算框架。

Yarn通過(guò)拆分原有的JobTracker為：

• 全局的 ResourceManager(RM)。
• 每個(gè)Application有一個(gè)ApplicationMaster(AM)。

由Yarn專(zhuān)門(mén)負責資源管理,JobTracker可以專(zhuān)門(mén)負責作業(yè)控制,Yarn接替 TaskScheduler的資源管理功能,這種松耦合的架構方式 實(shí)現了Hadoop整體框架的靈活性。

Hive

Hive的是基于Hadoop上的數據倉庫基礎構架，利用簡(jiǎn)單的SQL語(yǔ)句(簡(jiǎn)稱(chēng)HQL)來(lái)查詢(xún)、分析存儲在HDFS的數據。并且把SQL語(yǔ)句轉換成MapReduce程序來(lái)數據的處理。

Hive與傳統的關(guān)系數據庫主要區別在以下幾點(diǎn)：

• 存儲的位置 Hive的數據存儲在HDFS或者Hbase中，而后者一般存儲在裸設備或者本地的文件系統中。

• 數據庫更新 Hive是不支持更新的，一般是一次寫(xiě)入多次讀寫(xiě)。

• 執行SQL的延遲 Hive的延遲相對較高，因為每次執行HQL需要解析成MapReduce。

• 數據的規模上 Hive一般是TB級別，而后者相對較小。

• 可擴展性上 Hive支持UDF/UDAF/UDTF，后者相對來(lái)說(shuō)較差。

HBase

HBase，是Hadoop Database，是一個(gè)高可靠性、高性能、面向列、可伸縮的分布式存儲系統。它底層的文件系統使用HDFS，使用Zookeeper來(lái)管理集群的HMaster和各Region server之間的通信，監控各Region server的狀態(tài)，存儲各Region的入口地址等。

HBase是Key-Value形式的數據庫(類(lèi)比Java中的Map)。那么既然是數據庫那肯定就有表，HBase中的表大概有以下幾個(gè)特點(diǎn)：

• 大：一個(gè)表可以有上億行，上百萬(wàn)列(列多時(shí)，插入變慢)。

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

• 稀疏：對于為空(null)的列，并不占用存儲空間，因此，表可以設計的非常稀疏。

• 每個(gè)cell中的數據可以有多個(gè)版本，默認情況下版本號自動(dòng)分配，是單元格插入時(shí)的時(shí)間戳。

• HBase中的數據都是字節，沒(méi)有類(lèi)型(因為系統需要適應不同種類(lèi)的數據格式和數據源，不能預先嚴格定義模式)。

Spark

Spark是由伯克利大學(xué)開(kāi)發(fā)的分布式計算引擎，解決了海量數據流式分析的問(wèn)題。Spark首先將數據導入Spark集群，然后再通過(guò)基于內存的管理方式對數據進(jìn)行快速掃描 ，通過(guò)迭代算法實(shí)現全局I/O操作的最小化，達到提升整體處理性能的目的，這與Hadoop從“計算”找“數據”的實(shí)現思路是類(lèi)似的。

Other Tools

Phoneix

基于Hbase的SQL接口，安裝完P(guān)honeix之后可以適用SQL語(yǔ)句來(lái)操作Hbase數據庫。

Sqoop

Sqoop的主要作用是方便不同的關(guān)系數據庫將數據遷移到Hadoop，支持多種數據庫例如Postgres，Mysql等。

Hadoop集群硬件和拓撲規劃

規劃這件事情并沒(méi)有最優(yōu)解，只是在預算、數據規模、應用場(chǎng)景下之間的平衡。

硬件配置

Raid

首先Raid是否需要，在回答這個(gè)問(wèn)題之前，我們首先了解什么是Raid0以及Raid1。

Raid0是提高存儲性能的原理是把連續的數據分散到多個(gè)磁盤(pán)上存取，這樣，系統有數據請求就可以被多個(gè)磁盤(pán)并行的執行，每個(gè)磁盤(pán)執行屬于它自己的那部分數據請求。這種數據上的并行操作可以充分利用總線(xiàn)的帶寬，顯著(zhù)提高磁盤(pán)整體存取性能。(來(lái)源百度百科)

當Raid0與Hadoop結合在一起會(huì )產(chǎn)生什么影響呢?

優(yōu)勢：

• 提高IO。
• 加快讀寫(xiě)。
• 消除單塊磁盤(pán)的讀寫(xiě)過(guò)熱的情況。

然而在Hadoop系統中，當Raid0中的一塊磁盤(pán)數據出現問(wèn)題(或者讀寫(xiě)變得很慢的時(shí)候)時(shí)，你需要重新格式化整個(gè)Raid，并且數據需要重新恢復到DataNode中。整個(gè)周期會(huì )隨著(zhù)數據的增加而逐步增加。

其次Raid0的瓶頸是Raid中最慢的那一塊盤(pán)，當你需要替換其中最慢的那一塊盤(pán)的時(shí)候就會(huì )重新格式化整個(gè)Raid然后恢復數據。

RAID 1通過(guò)磁盤(pán)數據鏡像實(shí)現數據冗余，在成對的獨立磁盤(pán)上產(chǎn)生互 為備份的數據。當原始數據繁忙時(shí)，可直接從鏡像拷貝中讀取數據，因此RAID 1可以提高讀取性能。RAID 1是磁盤(pán)陣列中單位成本最高的，但提供了很高的數據安全性和可用性。當一個(gè)磁盤(pán)失效時(shí)，系統可以自動(dòng)切換到鏡像磁盤(pán)上讀寫(xiě)，而不需要重組失效的數據。(來(lái)源百度百科)

所以Raid1的本質(zhì)是提高數據的冗余，而Hadoop本身默認就是3個(gè)副本，所以當存在Raid1時(shí)候，副本數將會(huì )變成6，將會(huì )提高系統對于硬件資源的需求。

所以在Hadoop系統中不建議適用Raid的，其實(shí)更加推薦JBOD，當一塊磁盤(pán)出現問(wèn)題時(shí)，直接unmount然后替換磁盤(pán)(很多時(shí)候直接換機器的)。

集群規模及資源

這里主要依據數據總量來(lái)推算集群規模，不考慮CPU以以及內存配置。

一般情況來(lái)說(shuō)，我們是根據磁盤(pán)的的需求來(lái)計算需要機器的個(gè)數。

首先我們需要調研整個(gè)系統的當量以及增量數據。

舉個(gè)例子來(lái)說(shuō)，假如現在系統中存在8T的數據，默認副本數為3，那么所需要的存儲=8T*3/80% = 30T左右。

每臺機器存儲為6T，則數據節點(diǎn)個(gè)數為5。

加上Master節點(diǎn)，不考慮HA的情況下，大概是6臺左右機器。

軟件配置

根據業(yè)務(wù)需求是否需要配置HA方案進(jìn)行劃分,由于實(shí)際場(chǎng)景復雜多變，下面方案僅供參考。

1.非HA方案

一般考慮將所有的管理節點(diǎn)放在一臺機器上，同時(shí)在數據節點(diǎn)上啟動(dòng)若干個(gè)Zookeeper服務(wù)(奇數)。

• 管理節點(diǎn)：NameNode+ResourceManager+HMaster
• 數據節點(diǎn)：SecondaryNameNode
• 數據節點(diǎn)：DataNode +RegionServer+Zookeeper

2.HA方案

在HA方案中，需要將Primary Node 與Standby Node 放在不同的機器上，一般在實(shí)際場(chǎng)景中，考慮到節省機器，可能會(huì )將不同的組件的Master節點(diǎn)進(jìn)行交叉互備，如A機器上有Primary NameNonde 以及 Standby HMaster ，B機器上有Standby NameNode 以及 Primary Master。

• 管理節 點(diǎn)：NameNode(Primary)+HMaster(Standby)
• 管理節點(diǎn)：NameNode(Standby)+HMaster(Primary)
• 管理節點(diǎn)：ResourceManager
• 數據節點(diǎn)：DataNode +RegionServer+Zookeeper

Hadoop的設計目標和適用場(chǎng)景

其實(shí)在上面的Hadoop概要上我們就可以看到Hadoop當初的設計目標是什么。Hadoop在很多場(chǎng)合下都是大數據的代名詞。其主要是用來(lái)處理半結構以及非結構數據(例如MapReduce)。

其本質(zhì)也是通過(guò)Mapreduce程序來(lái)將半結構化或者非結構化的數據結構化繼而來(lái)進(jìn)行后續的處理。

其次由于Hadoop是分布式的架構，其針對的是大規模的數據處理，所以相對較少的數據量并不能體現Hadoop的優(yōu)勢。例如處理GB級別的數據量，利用傳統的關(guān)系型數據庫的速度可能相對較快。

基于上述來(lái)看Hadoop的適用場(chǎng)景如下：

• 離線(xiàn)日志的處理(包括ETL過(guò)程，其實(shí)本質(zhì)就是基于Hadoop的數據倉庫)。
• 大規模并行計算。
• Hadoop的架構解析

Hadoop由主要由兩部分組成：

• 分布式文件系統(HDFS)，主要用于大規模的數據存儲。
• 分布式計算框架MapReduce，其主要用來(lái)對HDFS上的數據進(jìn)行運算處理。

HDFS主要由NameNode(Master)以及DataNode(Slave)組成。前者主要是對命名空間管理：如對HDFS中的目錄、文件和塊做類(lèi)似 文件系統的創(chuàng )建、修改、刪除、列表文件和目錄等基本操作。后者存儲實(shí)際的數據塊，并與NameNode保持一定的心跳。

MapReduce2.0的計算框架本質(zhì)是有Yarn來(lái)完成的，Yarn是關(guān)注點(diǎn)分離的思路，由Yarn專(zhuān)門(mén)負責資源管理 ，JobTracker可以專(zhuān)門(mén)負責作業(yè)控制，Yarn接替 TaskScheduler的資源管理功能，這種松耦合的架構方式 實(shí)現了Hadoop整體框架的靈活性。

MapReduce工作原理和案例說(shuō)明

MapReduce可謂Hadoop的精華所在，是用于數據處理的編程模型。MapReduce從名稱(chēng)上面可以看到Map以及Reduce兩個(gè)部分。其思想類(lèi)似于先分后合，Map對與數據進(jìn)行抽取轉換，Reduce對數據進(jìn)行匯總。其中需要注意的是Map任務(wù)將輸出結果存儲在本地磁盤(pán),而不是HDFS。

在我們執行MapReduce的過(guò)程中，根據Map與數據庫的關(guān)系大體上可以分為三類(lèi)：

• 數據本地
• 機架本地
• 跨機架

從上述幾種可以看出來(lái)，假設一個(gè)MapReduce過(guò)程中存在大量的數據移動(dòng)對于執行效率來(lái)說(shuō)是災難性。

MapReduce數據流

從數據流來(lái)看MapReduce的關(guān)系大體可以分為以下幾類(lèi)：

單Reduce

多Reduce

無(wú)Reduce

上述這個(gè)過(guò)程其實(shí)也MapReduce中赫赫有名的Shuffle過(guò)程。

MapReduce實(shí)際案例

Raw Data

原始的數據文件是普通的文本文件，每一行記錄中存在一個(gè)年份以及改年份中每一天的溫度。

Map

Map過(guò)程中，將每一行記錄都生成一個(gè)key，key一般是改行在文件中的行數(Offset)，例如下圖中的0，106代表第一行、第107行。其中粗體的地方代表年份以及溫度。

Shuffle

該過(guò)程中獲取所要的記錄組成鍵值對{年份，溫度}。

Sort

將上一步過(guò)程中的相同key的value組成一個(gè)list，即{年份，List<溫度>}，傳到Reduce端。

Reduce

Reduce端對list進(jìn)行處理，獲取最大值，然后輸出到HDFS中。

上述過(guò)程進(jìn)行總結下來(lái)流程如下：