Hadoop生態學習總結

Hadoop生態

hdfs

架構

hdfs是一個分佈式文件系統。底層的存儲採用廉價的磁盤陣列RAID，因爲能夠併發讀寫因此效率很高。

基本架構是一個namenode和多個dataNode。node的意思是節點，通常指主機，也能夠是虛擬機。

每一個文件都會有兩個副本存放在datanode中。

讀寫

客戶端寫入文件時，先把請求發送到namenode，namenode會返回datanode的服務地址，接着客戶端去訪問datanode，進行文件寫入，而後通知namenode，namenode接收到寫入完成的消息之後，會另外選兩個datanode存放冗餘副本。

讀取文件時，從namenode獲取一個datanode的地址，而後本身去讀取便可。

當一個文件的副本不足兩份時，namenode自動會完成副本複製。而且，因爲datanode通常會放在各個機架。namenode通常會把副本一個放在同一機架，一個放在其餘機架，防止某個機架出問題致使整個文件讀寫不可用。

高可用

namenode節點是單點，因此宕機了就沒救了，因此咱們可使用zookeeper來保證namenode的高可用。可使用zookeeper選主來實現故障切換，namenode先註冊一個節點在zk上，表示本身是主，宕機時zk會通知備份節點進行切換。

Hadoop2.0中加入了hdfs namenode高可用的方案，也叫HDFS HA。namenode和一個備份節點綁定在一塊兒，而且經過一個共享數據區域進行數據同步。同時支持故障切換。

MapReduce

架構和流程

MapReduce是基於Hadoop集羣的分佈式計算方案。通常先編寫map函數進行數據分片，而後經過shuffle進行相同分片的整合，最後經過reduce把全部的數據結果進行整理。

具體來講，用戶提交一個MapReduce程序給namenode節點，namenode節點啓動一個jobtracker進行子任務的調度和監控，而後派發每一個子任務tasktracker到datanode進行任務執行，因爲數據分佈在各個節點，每一個tasktracker只須要執行本身的那一部分便可。最後再將結果彙總給tasktracker。

wordcount

首先是一個文本文件:hi hello good hello hi hi。 三個節點，則進行三次map。hi hello，good hello，hi hi分別由三個節點處理。結果分別是hi 1 hello 1,good 1 hello 1,hi 1,hi 1。 shuffle時進行combine操做，獲得hi 1,hello 1,good 1 hello 1,hi 2。最終reduce的結果是hi 3 hello 2 good 1.

hive

hive是一個基於hdfs文件系統的數據倉庫。能夠經過hive sql語句執行對hdfs上文件的數據查詢。原理是hive把hdfs上的數據文件當作一張張數據表，把表結構信息存在關係數據庫如mysql中。而後執行sql時經過對錶結構的解析再去hdfs上查詢真正的數據，最後也會以結構化的形式返回。

hbase

簡介

hbase是基於列的數據庫。

他與傳統關係數據庫有很大不一樣。

首先在表結構上，hbase使用rowkey行鍵做爲惟一主鍵，經過行鍵惟一肯定一行數據。

同時，hbase使用列族的概念，每一個表都有固定的列族，每一行的數據的列族都同樣，可是每一行所在列族的實際列均可以不同。 好比列族是info，列能夠是name age，也能夠是sex address等。也就是說具體列能夠在插入數據時再進行確認。

而且，hbase的每一行數據還能夠有多個版本，經過時間戳來表示不一樣的數據版本。

存儲

通常狀況下hbase使用hdfs做爲底層存儲，因此hdfs提供了數據的可靠性以及併發讀寫的高效率。

hbase一個表的 每n行數據會存在一個region中，而且，對於列來講，每個列族都會用一個region來存儲，假設有m個列族，那麼就會有n * m個region須要存儲在hdfs上。

同時hbase使用regionserver來管理這些region，他們可能存在不一樣的datanode裏，因此經過regionserver能夠找出每個region的位置。

hbase使用zookeeper來保證regionserver的高可用，會自動進行故障切換。

zk

zk在Hadoop的做用有幾個，經過選主等機制保證主節點高可用。

使用zk進行配置資源的統一管理，保證服務器節點無狀態，全部服務信息直接從zk獲取便可。

使用zookeeper進行節點間的通訊等，也可使用zk的目錄順序節點實現分佈式鎖，以及服務器選主。不只在Hadoop中，zk在分佈式系統中總能有用武之地。

zookeeper自己的部署方式就是一個集羣,一個master和多個slave。

使用zab協議保證一致性和高可用。

zab協議實現原理：

1 使用兩段式提交的方式確保一個協議須要半數以上節點贊成之後再進行廣播執行。

2 使用基於機器編號加時間戳的id來表示每一個事務，經過這個方式當初始選舉或者主節點宕機時進行一輪選主，每一個節點優先選擇本身當主節點，在選舉過程當中節點優先採納比較新的事務，將本身的選票更新，而後反饋個其餘機器，最後當一個機器得到超過半數選票時當選爲master。

3選主結束之後，主節點與slave進行主從同步，保證數據一致性，而後對外提供服務，而且寫入只能經過master而讀取能夠經過任意一臺機器。

sqoop

將hive表中的內容導入到MySQL數據庫，也能夠將MySQL中的數據導入hive中。

yarn

沒有yarn以前，hdfs使用jobtracker和tasktracker來執行和跟蹤任務，jobtracker的任務過重，又要執行又要監控還要獲取結果。 而且不一樣機器的資源狀況沒有被考慮在內。

yarn是一個資源調度系統。提供applicationmaster對一個調度任務進行封裝，而後有一個resourcemanager專門負責各節點資源的管理和監控。同時nodemanager則運行每一個節點中用於監控節點狀態和向rm彙報。還有一個container則是對節點資源的一個抽象，applicationmaster任務將由節點上的一個container進行執行。rm會將他調度到最合適的機器上。

kafka

架構

kafka是一個分佈式的消息隊列。

它組成通常包括kafka broker，每一個broker中有多個的partition做爲存儲消息的隊列。

而且向上提供服務時抽象爲一個topic，咱們訪問topic時實際上執行的是對partition的寫入和讀取操做。

讀寫和高可用

partition支持順序寫入，效率比較高，而且支持零拷貝機制，經過內存映射磁盤mmap的方式，寫入partition的數據順序寫入到映射的磁盤中，比傳統的IO要快。

因爲partition可能會宕機，因此通常也要支持partition的備份，1個broker ，master一般會有多個 broker slave，是主從關係，經過zookeeper進行選主和故障切換。

當數據寫入隊列時，通常也會經過日誌文件的方式進行數據備份，會把broker中的partition被分在各個slave中以便於均勻分佈和恢復。

生產者和消費者

生產者消費者須要訪問kafka的隊列時，若是是寫入，直接向zk發送請求，通常是向一個topic寫入消息，broker會自動分配partition進行寫入。而後zk會告訴生產者寫入的partition所在的broker地址，而後進行寫入。

若是是讀取的話，也是經過zk獲取partition所在位置，而後經過給定的offset進行讀取，讀取完後更新offset。

因爲kafka的partition支持順序讀寫。因此保證一個partition中的讀取和寫入時是順序的，可是若是是多個partition則不保證順序。

正常狀況下kafka使用topic來實現消息點對點發送，而且每一個consumer都要在一個consumer group中，並且comsumer group中每次只能有一個消費者能接受對應topic的消息。由於爲了實現訂閱也就是一對多發送，咱們讓每一個consumer在一個單獨的group，因而每一個consumer均可以接受到該消息。

flume

flume用於數據的收集和分發，flume能夠監聽端口的數據流入，監視文件的變更以及各類數據形式的數據流入，而後再把數據從新轉發到其餘須要數據的節點或存儲中。

一、Flume的概念

flume是分佈式的日誌收集系統，它將各個服務器中的數據收集起來並送到指定的地方去，好比說送到圖中的HDFS，簡單來講flume就是收集日誌的。

二、Event的概念 在這裏有必要先介紹一下flume中event的相關概念：flume的核心是把數據從數據源(source)收集過來，在將收集到的數據送到指定的目的地(sink)。爲了保證輸送的過程必定成功，在送到目的地(sink)以前，會先緩存數據(channel),待數據真正到達目的地(sink)後，flume在刪除本身緩存的數據。

在整個數據的傳輸的過程當中，流動的是event，即事務保證是在event級別進行的。那麼什麼是event呢？—–event將傳輸的數據進行封裝，是flume傳輸數據的基本單位，若是是文本文件，一般是一行記錄，event也是事務的基本單位。event從source，流向channel，再到sink，自己爲一個字節數組，並可攜帶headers(頭信息)信息。event表明着一個數據的最小完整單元，從外部數據源來，向外部的目的地去。

flume使用

ambari

ambari就是一個Hadoop的Web應用。

spark

spark和MapReduce不一樣的地方就是，把計算過程放在內存中運行。

spark提出了抽象的RDD分佈式內存模型，把每一步的計算操做轉換成一個RDD結構，而後造成一個RDD鏈接而成的有向圖。

好比data.map().filter().reduce(); 程序提交到master之後，會解析成多個RDD，而且造成一個有向圖，而後spark再根據這些RD結構在內存中執行對應的操做。固然這個拓撲結構會被拆分爲各個子任務分發到各個spark節點上，而後計算完之後再造成下一個rdd。最後彙總結果便可。

因爲是在內存中對數據進行操做，省去了沒必要要的IO操做，，不須要像Mapreduce同樣還得先去hdfs讀取文件再完成計算。

storm

在運行一個Storm任務以前，須要瞭解一些概念：

1. Topologies
2. Streams
3. Spouts
4. Bolts
5. Stream groupings
6. Reliability
7. Tasks
8. Workers
9. Configuration

Storm集羣和Hadoop集羣表面上看很相似。可是Hadoop上運行的是MapReduce jobs，而在Storm上運行的是拓撲（topology），這二者之間是很是不同的。一個關鍵的區別是： 一個MapReduce job最終會結束， 而一個topology永遠會運行（除非你手動kill掉）。

在Storm的集羣裏面有兩種節點： 控制節點（master node）和工做節點（worker node）。控制節點上面運行一個叫Nimbus後臺程序，它的做用相似Hadoop裏面的JobTracker。Nimbus負責在集羣裏面分發代碼，分配計算任務給機器， 而且監控狀態。

每個工做節點上面運行一個叫作Supervisor的節點。Supervisor會監聽分配給它那臺機器的工做，根據須要啓動/關閉工做進程。每個工做進程執行一個topology的一個子集；一個運行的topology由運行在不少機器上的不少工做進程組成。

Nimbus和Supervisor之間的全部協調工做都是經過Zookeeper集羣完成。另外，Nimbus進程和Supervisor進程都是快速失敗（fail-fast)和無狀態的。全部的狀態要麼在zookeeper裏面， 要麼在本地磁盤上。這也就意味着你能夠用kill -9來殺死Nimbus和Supervisor進程， 而後再重啓它們，就好像什麼都沒有發生過。這個設計使得Storm異常的穩定。

storm比起spark它的實時性能更高更強，storm能夠作到亞秒級別的數據輸入分析。而spark的方式是經過秒級的數據切分，來造成spark rdd數據集，而後再按照DAG有向圖進行執行的。

storm則否則。

一：介紹Storm設計模型

1.Topology

  Storm對任務的抽象，其實 就是將實時數據分析任務 分解爲 不一樣的階段    

  點： 計算組件 Spout Bolt

  邊： 數據流向 數據從上一個組件流向下一個組件 帶方向

2.tuple

  Storm每條記錄 封裝成一個tuple

  其實就是一些keyvalue對按順序排列

  方便組件獲取數據

3.Spout

  數據採集器

  源源不斷的日誌記錄 如何被topology接收進行處理？

  Spout負責從數據源上獲取數據，簡單處理 封裝成tuple向後面的bolt發射

4.Bolt

  數據處理器    二：開發wordcount案例

1.書寫整個大綱的點線圖

  

   topology就是一個拓撲圖，相似於spark中的dag有向圖，只不過storm執行的流式的數據，比dag執行更加具備實時性。

topology包含了spout和bolt。 spout負責獲取數據，而且將數據發送給bolt，這個過程就是把任務派發到多個節點，bolt則負責對數據進行處理，好比splitbolt負責把每一個單詞提取出來，countbolt負責單詞數量的統計，最後的printbolt將每一個結果集tuple打印出來。

這就造成了一個完整的流程。