GitChat · 大數據 | 一步一步學習大數據：Hadoop 生態系統與場景

時間 2019-12-07

標籤 gitchat 數據一步學習 hadoop 生態系統場景欄目 Hadoop 简体版

原文原文鏈接

GitChat 做者：Lee
原文：一步一步學習大數據：Hadoop 生態系統與場景
關注公衆號：GitChat 技術雜談，一本正經的講技術html

Hadoop概要

究竟是業務推進了技術的發展，仍是技術推進了業務的發展，這個話題放在何時都會惹來一些爭議。node

隨着互聯網以及物聯網的蓬勃發展，咱們進入了大數據時代。IDC預測，到2020年,全球會有44ZB的數據量。傳統存儲和技術架構沒法知足需求。在2013年出版的《大數據時代》一書中，定義了大數據的5V特色：Volume（大量）、Velocity（高速）、Variety（多樣）、Value（低價值密度）、Veracity（真實性）。git

當咱們把時間往回看10年，來到了2003年，這一年Google發表《Google File System》，其中提出一個GFS集羣中由多個節點組成，其中主要分爲兩類：一個Master node，不少Chunkservers。以後於2004年Google發表論文並引入MapReduce。2006年2月，Doug Cutting等人在Nutch項目上應用GFS和 MapReduce思想,並演化爲Hadoop項目。算法

Doug Cutting曾經說過他很是喜歡本身的程序被千萬人使用的感受，很明顯，他作到了；下圖就是本尊照片，帥氣的一塌糊塗sql

2008年1月, Hadoop成爲Apache的開源項目。數據庫

Hadoop的出現解決了互聯網時代的海量數據存儲和處理，其是一種支持分佈式計算和存儲的框架體系。假如把Hadoop集羣抽象成一臺機器的話，理論上咱們的硬件資源（CPU、Memoery等）是能夠無限擴展的。編程

Hadoop經過其各個組件來擴展其應用場景，例如離線分析、實時處理等。緩存

Hadoop相關組件介紹

本文主要是依據Hadoop2.7版本，後面沒有特殊說明也是按照此版本安全

HDFS

HDFS,Hadoop Distributed File System （Hadoop分佈式文件系統）被設計成適合運行在通用硬件(commodity hardware)上的分佈式文件系統。它和現有的分佈式文件系統有不少共同點，例如典型的Master/Slave架構（這裏不許備展開介紹）；然而HDFS是一個高度容錯性的系統，適合部署在廉價的機器上。數據結構

關於HDFS主要想說兩點。

HDFS中的默認副本數是3，這裏涉及到一個問題爲何是3而不是2或者4。
機架感知（Rack Awareness）。

只有深入理解了這兩點才能理解爲何Hadoop有着高度的容錯性，高度容錯性是Hadoop能夠在通用硬件上運行的基礎。

Yarn

Yarn,Yet Another Resource Negotiator(又一個資源協調者)，是繼Common、HDFS、MapReduce以後Hadoop 的又一個子項目。Yarn的出現是由於在Hadoop1.x中存在以下幾個問題：

擴展性差。JobTracker兼備資源管理和做業控制兩個功能。
可靠性差。在Master/Slave架構中,存在Master單點故障。
資源利用率低。Map Slot（1.x中資源分配的單位）和Reduce Slot分開,二者之間沒法共享。
沒法支持多種計算框架。MapReduce計算框架是基於磁盤的離線計算模型,新應用要求支持內存計算、流式計算、迭代式計算等多種計算框架。

Yarn經過拆分原有的JobTracker爲：

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

由Yarn專門負責資源管理,JobTracker能夠專門負責做業控制,Yarn接替 TaskScheduler的資源管理功能,這種鬆耦合的架構方式實現了Hadoop總體框架的靈活性。

Hive

Hive的是基於Hadoop上的數據倉庫基礎構架，利用簡單的SQL語句（簡稱HQL）來查詢、分析存儲在HDFS的數據。而且把SQL語句轉換成MapReduce程序來數據的處理。

Hive與傳統的關係數據庫主要區別在如下幾點：

存儲的位置 Hive的數據存儲在HDFS或者Hbase中，然後者通常存儲在裸設備或者本地的文件系統中。
數據庫更新 Hive是不支持更新的，通常是一次寫入屢次讀寫。
執行SQL的延遲 Hive的延遲相對較高，由於每次執行HQL須要解析成MapReduce。
數據的規模上 Hive通常是TB級別，然後者相對較小。
可擴展性上 Hive支持UDF/UDAF/UDTF，後者相對來講較差。

HBase

HBase，是Hadoop Database，是一個高可靠性、高性能、面向列、可伸縮的分佈式存儲系統。它底層的文件系統使用HDFS，使用Zookeeper來管理集羣的HMaster和各Region server之間的通訊，監控各Region server的狀態，存儲各Region的入口地址等。

HBase是Key-Value形式的數據庫（類比Java中的Map）。那麼既然是數據庫那確定就有表，HBase中的表大概有如下幾個特色：

大：一個表能夠有上億行，上百萬列（列多時，插入變慢）。

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

稀疏：對於爲空(null)的列，並不佔用存儲空間，所以，表能夠設計的很是稀疏。
每一個cell中的數據能夠有多個版本，默認狀況下版本號自動分配，是單元格插入時的時間戳。
HBase中的數據都是字節，沒有類型（由於系統須要適應不一樣種類的數據格式和數據源，不能預先嚴格定義模式）。

Spark

Spark是由伯克利大學開發的分佈式計算引擎，解決了海量數據流式分析的問題。Spark首先將數據導入Spark集羣，而後再經過基於內存的管理方式對數據進行快速掃描，經過迭代算法實現全局I/O操做的最小化，達到提高總體處理性能的目的，這與Hadoop從「計算」找「數據」的實現思路是相似的。

Other Tools

Phoneix

基於Hbase的SQL接口，安裝完Phoneix以後能夠適用SQL語句來操做Hbase數據庫。

Sqoop

Sqoop的主要做用是方便不一樣的關係數據庫將數據遷移到Hadoop，支持多種數據庫例如Postgres，Mysql等。

Hadoop集羣硬件和拓撲規劃

規劃這件事情並無最優解，只是在預算、數據規模、應用場景下之間的平衡。

硬件配置

Raid

首先Raid是否須要，在回答這個問題以前，咱們首先了解什麼是Raid0以及Raid1。

Raid0是提升存儲性能的原理是把連續的數據分散到多個磁盤上存取，這樣，系統有數據請求就能夠被多個磁盤並行的執行，每一個磁盤執行屬於它本身的那部分數據請求。這種數據上的並行操做能夠充分利用總線的帶寬，顯著提升磁盤總體存取性能。（來源百度百科）

當Raid0與Hadoop結合在一塊兒會產生什麼影響呢？

優點：

提升IO。
加快讀寫。
消除單塊磁盤的讀寫過熱的狀況。

然而在Hadoop系統中，當Raid0中的一塊磁盤數據出現問題（或者讀寫變得很慢的時候）時，你須要從新格式化整個Raid，而且數據須要從新恢復到DataNode中。整個週期會隨着數據的增長而逐步增長。

其次Raid0的瓶頸是Raid中最慢的那一塊盤，當你須要替換其中最慢的那一塊盤的時候就會從新格式化整個Raid而後恢復數據。

RAID 1經過磁盤數據鏡像實現數據冗餘，在成對的獨立磁盤上產生互爲備份的數據。當原始數據繁忙時，可直接從鏡像拷貝中讀取數據，所以RAID 1能夠提升讀取性能。RAID 1是磁盤陣列中單位成本最高的，但提供了很高的數據安全性和可用性。當一個磁盤失效時，系統能夠自動切換到鏡像磁盤上讀寫，而不須要重組失效的數據。（來源百度百科）

因此Raid1的本質是提升數據的冗餘，而Hadoop自己默認就是3個副本，因此當存在Raid1時候，副本數將會變成6，將會提升系統對於硬件資源的需求。

因此在Hadoop系統中不建議適用Raid的，其實更加推薦JBOD，當一塊磁盤出現問題時，直接unmount而後替換磁盤（不少時候直接換機器的）。

集羣規模及資源

這裏主要依據數據總量來推算集羣規模，不考慮CPU以以及內存配置。

通常狀況來講，咱們是根據磁盤的的需求來計算須要機器的個數。

首先咱們須要調研整個系統的當量以及增量數據。

舉個例子來講，假如如今系統中存在8T的數據，默認副本數爲3，那麼所須要的存儲＝8T*3/80% = 30T左右。

每臺機器存儲爲6T，則數據節點個數爲5。

加上Master節點，不考慮HA的狀況下，大概是6臺左右機器。

軟件配置

根據業務需求是否須要配置HA方案進行劃分,因爲實際場景複雜多變，下面方案僅供參考。

1.非HA方案

通常考慮將全部的管理節點放在一臺機器上，同時在數據節點上啓動若干個Zookeeper服務（奇數）。

管理節點：NameNode+ResourceManager+HMaster
數據節點：SecondaryNameNode
數據節點：DataNode +RegionServer+Zookeeper

2.HA方案

在HA方案中，須要將Primary Node 與Standby Node 放在不一樣的機器上，通常在實際場景中，考慮到節省機器，可能會將不一樣的組件的Master節點進行交叉互備，如A機器上有Primary NameNonde 以及 Standby HMaster ，B機器上有Standby NameNode 以及 Primary Master。

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

Hadoop的設計目標和適用場景

其實在上面的Hadoop概要上咱們就能夠看到Hadoop當初的設計目標是什麼。Hadoop在不少場合下都是大數據的代名詞。其主要是用來處理半結構以及非結構數據（例如MapReduce）。

其本質也是經過Mapreduce程序來將半結構化或者非結構化的數據結構化繼而來進行後續的處理。

其次因爲Hadoop是分佈式的架構，其針對的是大規模的數據處理，因此相對較少的數據量並不能體現Hadoop的優點。例如處理GB級別的數據量，利用傳統的關係型數據庫的速度可能相對較快。

基於上述來看Hadoop的適用場景以下：

離線日誌的處理（包括ETL過程，其實本質就是基於Hadoop的數據倉庫）。
大規模並行計算。

Hadoop的架構解析

Hadoop由主要由兩部分組成：

分佈式文件系統（HDFS），主要用於大規模的數據存儲。
分佈式計算框架MapReduce，其主要用來對HDFS上的數據進行運算處理。

HDFS主要由NameNode（Master）以及DataNode（Slave）組成。前者主要是對命名空間管理：如對HDFS中的目錄、文件和塊作相似文件系統的建立、修改、刪除、列表文件和目錄等基本操做。後者存儲實際的數據塊，並與NameNode保持必定的心跳。

MapReduce2.0的計算框架本質是有Yarn來完成的，Yarn是關注點分離的思路，由Yarn專門負責資源管理，JobTracker能夠專門負責做業控制，Yarn接替 TaskScheduler的資源管理功能，這種鬆耦合的架構方式實現了Hadoop總體框架的靈活性。

MapReduce工做原理和案例說明

MapReduce可謂Hadoop的精華所在，是用於數據處理的編程模型。MapReduce從名稱上面能夠看到Map以及Reduce兩個部分。其思想相似於先分後合，Map對與數據進行抽取轉換，Reduce對數據進行彙總。其中須要注意的是Map任務將輸出結果存儲在本地磁盤,而不是HDFS。

在咱們執行MapReduce的過程當中，根據Map與數據庫的關係大致上能夠分爲三類：

數據本地
機架本地
跨機架

從上述幾種能夠看出來，假設一個MapReduce過程當中存在大量的數據移動對於執行效率來講是災難性。

MapReduce數據流

從數據流來看MapReduce的關係大致能夠分爲如下幾類：

單Reduce

多Reduce

無Reduce

然而不管什麼MapReduce關係如何，MapReduce的執行流程都以下圖所示：

其中在執行每一個Map Task時，不管Map方法中執行什麼邏輯，最終都是要把輸出寫到磁盤上。若是沒有Reduce階段，則直接輸出到HDFS上。若是有Reduce做業，則每一個Map方法的輸出在寫磁盤前線在內存中緩存。每一個Map Task都有一個環狀的內存緩衝區，存儲着Map的輸出結果，默認100m，在每次當緩衝區快滿的時候由一個獨立的線程將緩衝區的數據以一個溢出文件的方式存放到磁盤，當整個Map Task結束後再對磁盤中這個Map Task產生的全部溢出文件作合併，被合併成已分區且已排序的輸出文件。而後等待Reduce Task來拉數據。

上述這個過程其實也MapReduce中赫赫有名的Shuffle過程。