Hadoop生態(tài)圈筆記

1、Hadoop：分布式基礎架構Hadoop的框架最核心的設計就是：HDFS和MapReduce。HDFS為海量的數(shù)據(jù)提供了存儲，則MapReduce為海量的數(shù)據(jù)提供了計算。Hdfs：hadoop分布式文件系統(tǒng)故障的檢測和自動快速恢復，節(jié)點自檢，數(shù)據(jù)恢復，保存多個副本，且提供容錯機制，副本丟失或宕機自動恢復，默認存3份。HDFS默認會將文件分割成block，64M為1個block。NameNote名稱節(jié)點DataNote數(shù)據(jù)節(jié)點簡介：如上圖所示，HDFS也是按照Master和Slave的結構。分NameNode、SecondaryNameNode、DataNode這幾個角色。NameNode：是M

2、aster節(jié)點，是大領導。管理數(shù)據(jù)塊映射；處理客戶端的讀寫請求；配置副本策略；管理HDFS的名稱空間；SecondaryNameNode：是一個小弟，分擔大哥namenode的工作量；是NameNode的冷備份；合并fsimage和fsedits然后再發(fā)給namenode。DataNode：Slave節(jié)點，奴隸，干活的。負責存儲client發(fā)來的數(shù)據(jù)塊block；執(zhí)行數(shù)據(jù)塊的讀寫操作。熱備份：b是a的熱備份，如果a壞掉。那么b馬上運行代替a的工作。冷備份：b是a的冷備份，如果a壞掉。那么b不能馬上代替a工作。但是b上存儲a的一些信息，減少a壞掉之后的損失。fsimage:元數(shù)據(jù)鏡像文件（文件系

3、統(tǒng)的目錄樹。）edits：元數(shù)據(jù)的操作日志（針對文件系統(tǒng)做的修改操作記錄）namenode內(nèi)存中存儲的是=fsimage+edits。SecondaryNameNode負責定時默認1小時，從namenode上，獲取fsimage和edits來進行合并，然后再發(fā)送給namenode。減少namenode的工作量。工作原理寫操作：有一個文件FileA，100M大小。Client將FileA寫入到HDFS上。HDFS按默認配置。HDFS分布在三個機架上Rack1，Rack2，Rack3。 a. Client將FileA按64M分塊。分成兩塊，block1和Block2;b. Client向

4、nameNode發(fā)送寫數(shù)據(jù)請求，如圖藍色虛線->。c. NameNode節(jié)點，記錄block信息。并返回可用的DataNode，如粉色虛線->。    Block1: host2,host1,host3    Block2: host7,host8,host4    原理：        NameNode具有RackAware機架感知功能，這個可以配置。      

5、  若client為DataNode節(jié)點，那存儲block時，規(guī)則為：副本1，同client的節(jié)點上；副本2，不同機架節(jié)點上；副本3，同第二個副本機架的另一個節(jié)點上；其他副本隨機挑選。        若client不為DataNode節(jié)點，那存儲block時，規(guī)則為：副本1，隨機選擇一個節(jié)點上；副本2，不同副本1，機架上；副本3，同副本2相同的另一個節(jié)點上；其他副本隨機挑選。d. client向DataNode發(fā)送block1；發(fā)送過程是以流式寫入。    流式寫入過程，   

6、;     1>將64M的block1按64k的package劃分;        2>然后將第一個package發(fā)送給host2;        3>host2接收完后，將第一個package發(fā)送給host1，同時client想host2發(fā)送第二個package；        4>host1接收完第一個package后，發(fā)送給host3，同時接收host2發(fā)來的第二個package。      &#

7、160; 5>以此類推，如圖紅線實線所示，直到將block1發(fā)送完畢。        6>host2,host1,host3向NameNode，host2向Client發(fā)送通知，說“消息發(fā)送完了”。如圖粉紅顏色實線所示。        7>client收到host2發(fā)來的消息后，向namenode發(fā)送消息，說我寫完了。這樣就真完成了。如圖黃色粗實線        8>發(fā)送完block1后，再向host7，host8，host4發(fā)送block2，如圖藍色

8、實線所示。        9>發(fā)送完block2后，host7,host8,host4向NameNode，host7向Client發(fā)送通知，如圖淺綠色實線所示。        10>client向NameNode發(fā)送消息，說我寫完了，如圖黃色粗實線。這樣就完畢了。分析，通過寫過程，我們可以了解到：    寫1T文件，我們需要3T的存儲，3T的網(wǎng)絡流量貸款。    在執(zhí)行讀或?qū)懙倪^程中，NameNode和DataNode通過HeartBeat進行保存通信，確定Dat

9、aNode活著。如果發(fā)現(xiàn)DataNode死掉了，就將死掉的DataNode上的數(shù)據(jù)，放到其他節(jié)點去。讀取時，要讀其他節(jié)點去。    掛掉一個節(jié)點，沒關系，還有其他節(jié)點可以備份；甚至，掛掉某一個機架，也沒關系；其他機架上，也有備份。 讀操作： 讀操作就簡單一些了，如圖所示，client要從datanode上，讀取FileA。而FileA由block1和block2組成。  那么，讀操作流程為：a. client向namenode發(fā)送讀請求。b. namenode查看Metadata信息，返回fileA的block的位置。  &

10、#160; block1:host2,host1,host3    block2:host7,host8,host4c. block的位置是有先后順序的，先讀block1，再讀block2。而且block1去host2上讀?。蝗缓骲lock2，去host7上讀取； 上面例子中，client位于機架外，那么如果client位于機架內(nèi)某個DataNode上，例如,client是host6。那么讀取的時候，遵循的規(guī)律是：優(yōu)選讀取本機架上的數(shù)據(jù)。MapReduce：并行計算框架Job Tracker,用于超大型數(shù)據(jù)集的并行運算。Yarn：YARN總體上采用master/s

11、lave架構，如圖1所示，其中，master被稱為ResourceManager，slave被稱為 NodeManager，ResourceManager負責對各個NodeManager上的資源進行統(tǒng)一管理和調(diào)度。當用戶提交一個應用程序時，需要 提供一個用以跟蹤和管理這個程序的ApplicationMaster，它負責向ResourceManager申請資源，并要求NodeManger啟 動可以占用一定資源的Container。由于不同的ApplicationMaster被分布到不同的節(jié)點上，并通過一定的隔離機制進行了資源隔離，因 此它們之間不會相互影響。HBase：一個分布式的、面向列的開源

12、數(shù)據(jù)庫JMX監(jiān)控：從源碼中可以看到json的獲取可以帶有http驗證，另外還可以有一個參數(shù)叫qry。這個參數(shù)的值就是在獲取整個長JSON中每個"name"key所對應的名字。也就是，可以用http:/your_tasktracker:50060/jmx?qry=GarbageCollector,name=PS MarkSweep這種方式來獲取關于JVM對內(nèi)存垃圾回收的處理狀態(tài)信息。很簡單不是嗎？Hive：基于Hadoop的一個數(shù)據(jù)倉庫工具，將HQL查詢語句轉化為MapReduce作業(yè)使用hivesql語句查詢  如何設置此語句所對的mr任務的jobnam

13、e  還有默認jobname根據(jù)hiveql的生成規(guī)則    僅只查找相應對應下的job信息就是要用hive jdbc  做一個頁面    那個頁面的功能可以對job任務進行監(jiān)控     如同50030/jobtracker.jsp頁面的功能。  一個hiveql語句可能執(zhí)行多個mr的執(zhí)行，它們之間有什么關聯(lián) 并且能被找到。Zookeeper：一個分布式的，開放源碼的分布式應用程序協(xié)調(diào)服

14、務，是一個為分布式應用提供一致性服務的軟件具體監(jiān)控指標l  CPU/MEM/LOAD的監(jiān)控l  ZK日志目錄所在磁盤剩余空間監(jiān)控l  單機連接數(shù)的峰值報警l  單機 Watcher數(shù)的峰值報警l  節(jié)點自檢：是指對集群中每個IP所在ZK節(jié)點上的PATH: /YINSHI.MONITOR.ALIVE.CHECK 定期進行三次如下流程 : 節(jié)點連接 數(shù)據(jù)發(fā)布 修改通知 獲取數(shù)據(jù) 數(shù)據(jù)對比, 在指定的延時內(nèi)，三次流程均成功視為該節(jié)點處于正常狀態(tài)。Watch機制我這套系統(tǒng)就是基于方法一實現(xiàn)的。更多的詳情

15、可以參考官方文檔。下面貼一下我們系統(tǒng)的圖：這是系統(tǒng)的菜單功能，分別包含了Zookeeper集群配置、集群監(jiān)控、報警設置以及系統(tǒng)設置等功能。這里列出了Zookeeper的所有機器的簡單概括。點擊IP可以進入到集群的簡單概括，可以查看到集群是否運行正常等信息，如下圖所示：下圖是某一具體機器的所有客戶端連接詳情：下圖是某一具體機器的所有監(jiān)聽目錄的詳情:這是某一具體機器的圖形化監(jiān)控圖：Spark類Hadoop MapReduce的通用并行框架Spark 是在 Scala 語言中實現(xiàn)的，它將 Scala 用作其應用程序框架Kafka：分布式發(fā)布-訂閱消息系統(tǒng)Kafka是一個分布式的，可劃分的，冗余備份的

16、持久性的日志服務。它主要用于處理活躍的流式數(shù)據(jù)。開啟JMX端口修改bin/kafka-server-start.sh，添加JMX_PORT參數(shù)，添加后樣子如下if "x$KAFKA_HEAP_OPTS" = "x" ; then    export KAFKA_HEAP_OPTS="-Xmx1G -Xms1G"    export JMX_PORT="9999"fi通過Jconsole測試時候可以連接監(jiān)控指標：· kafka.messages_in· .b

17、ytes_in· .bytes_out· .bytes_rejected· kafka.replication.isr_expands· kafka.replication.isr_shrinks· kafka.replication.leader_elections· kafka.replication.unclean_leader_elections· kafka.request.fetch.failed· kafka.request.fetch.time.99percentile· kafka.re

18、quest.fetch.time.avg· kafka.request.handler.avg.idle.pct· kafka.request.metadata.time.99percentile· kafka.request.metadata.time.avg· kafka.request.offsets.time.99percentile· kafka.request.offsets.time.avg· duce.failed· duce.time.99

19、percentile· duce.time.avg· kafka.request.update_metadata.time.99percentile· kafka.request.update_metadata.time.avgKafka Web Console：監(jiān)控功能較為全面，可以預覽消息，監(jiān)控Offset、Lag等信息，但存在bug，不建議在生產(chǎn)環(huán)境中使用。Kafka Manager：偏向Kafka集群管理，若操作不當，容易導致集群出現(xiàn)故障。對Kafka實時生產(chǎn)和消費消息是通過JMX實現(xiàn)的。沒有記錄Offset、Lag等信息

20、。KafkaOffsetMonitor：程序一個jar包的形式運行，部署較為方便。只有監(jiān)控功能，使用起來也較為安全。鏈接: 密碼: qh7t若只需要監(jiān)控功能，推薦使用KafkaOffsetMonito，若偏重Kafka集群管理，推薦使用Kafka Manager。Kayka的應用場景：1.消息隊列比起大多數(shù)的消息系統(tǒng)來說，Kafka有更好的吞吐量，內(nèi)置的分區(qū)，冗余及容錯性，這讓Kafka成為了一個很好的大規(guī)模消息處理應用的解決方案。 消息系統(tǒng)一般吞吐量相對較低，但是需要更小的端到端延時，并嘗嘗依賴于Kafka提供的強大的持久性保障。在這個領域，Kafka足以媲美傳統(tǒng)消息系統(tǒng)， 如ActiveM

21、R或RabbitMQ。2.行為跟蹤Kafka的另一個應用場景是跟蹤用戶瀏覽頁面、搜索及其他行為，以發(fā)布-訂閱的模式實時記錄到對應的topic里。那么這些結果被訂閱者拿到后，就可以做進一步的實時處理，或?qū)崟r監(jiān)控，或放到hadoop/離線數(shù)據(jù)倉庫里處理。3.元信息監(jiān)控作為操作記錄的監(jiān)控模塊來使用，即匯集記錄一些操作信息，可以理解為運維性質(zhì)的數(shù)據(jù)監(jiān)控吧。4.日志收集日志收集方面，其實開源產(chǎn)品有很多，包括Scribe、Apache Flume。很多人使用Kafka代替日志聚合（log aggregation）。日志聚合一般來說是從服務器上收集日志文件，然后放到一個集中的位置（文件服務器或HDFS）進行

22、處理。然而Kafka忽略掉 文件的細節(jié)，將其更清晰地抽象成一個個日志或事件的消息流。這就讓Kafka處理過程延遲更低，更容易支持多數(shù)據(jù)源和分布式數(shù)據(jù)處理。比起以日志為中心的 系統(tǒng)比如Scribe或者Flume來說，Kafka提供同樣高效的性能和因為復制導致的更高的耐用性保證，以及更低的端到端延遲。5.流處理這個場景可能比較多，也很好理解。保存收集流數(shù)據(jù)，以提供之后對接的Storm或其他流式計算框架進行處理。很多用戶會將那些從原始topic來的 數(shù)據(jù)進行階段性處理，匯總，擴充或者以其他的方式轉換到新的topic下再繼續(xù)后面的處理。例如一個文章推薦的處理流程，可能是先從RSS數(shù)據(jù)源中抓取文 章的內(nèi)

23、容，然后將其丟入一個叫做“文章”的topic中；后續(xù)操作可能是需要對這個內(nèi)容進行清理，比如回復正常數(shù)據(jù)或者刪除重復數(shù)據(jù)，最后再將內(nèi)容匹配的 結果返還給用戶。這就在一個獨立的topic之外，產(chǎn)生了一系列的實時數(shù)據(jù)處理的流程。Strom和Samza是非常著名的實現(xiàn)這種類型數(shù)據(jù)轉換的框架。6.事件源事件源是一種應用程序設計的方式，該方式的狀態(tài)轉移被記錄為按時間順序排序的記錄序列。Kafka可以存儲大量的日志數(shù)據(jù)，這使得它成為一個對這種方式的應用來說絕佳的后臺。比如動態(tài)匯總（News feed）。7.持久性日志（commit log）Kafka可以為一種外部的持久性日志的分布式系統(tǒng)提供服務。這種日志可以在節(jié)點間備份數(shù)據(jù)，并為故障節(jié)點數(shù)據(jù)回復提供一種重新同步的機制。Kafka中日志壓縮功能為這種用法提供了條件。在這種用法中，Kafka類似于Apache BookKeeper項目。Memcache:是一個高性能的分布式的內(nèi)存對象緩存系統(tǒng)通過在內(nèi)存里維護一個統(tǒng)一的巨大的hash表，它能夠用來存儲各種格式的數(shù)據(jù)，包括圖像、視頻、文件以及數(shù)據(jù)庫檢索的結果等。簡單的說就是將數(shù)據(jù)調(diào)用到內(nèi)存中，然后從內(nèi)存中讀取，從而大大提高讀取速度。目前被許多網(wǎng)站使用以提升網(wǎng)站的訪問速度，尤其對于一些大型的、需要頻繁訪