一、HDFS
????????Hadoop中的分布式文件系統(tǒng)呻逆，高容錯（數(shù)據(jù)庫blcok備份）夸赫，可擴(kuò)展，適合存儲大文件咖城，不適合存儲小文件茬腿，不適合處理低延時的數(shù)據(jù)（HBase更好），一次寫入宜雀、多次讀寫切平，不支持多用戶寫入及任意修改文件。
1辐董、原理架構(gòu)
（1）NameNode：主節(jié)點(diǎn)悴品，負(fù)責(zé)管理文件系統(tǒng)的命名空間，將HDFS的元數(shù)據(jù)存儲在NameNode節(jié)點(diǎn)的內(nèi)存中简烘；負(fù)責(zé)響應(yīng)客戶端對文件的讀寫請求苔严。
（2）DataNode：數(shù)據(jù)節(jié)點(diǎn),主要負(fù)責(zé)數(shù)據(jù)的讀寫, 存儲block以及block元數(shù)據(jù)到datanode本地磁盤（此處的元數(shù)據(jù)包括數(shù)據(jù)塊的長度、塊數(shù)據(jù)的校驗(yàn)和孤澎、時間戳）届氢；定期向NameNode發(fā)送心跳，超過10分鐘節(jié)點(diǎn)不可用覆旭，6小時上報當(dāng)前DataNode上的塊狀態(tài)退子。
（3）SecondaryNameNode：輔助節(jié)點(diǎn),定期做checkpoint操作，合并NameNode的fsimage及editlog型将，NameNode就有了最新的fsimage文件和更小的editslog文件絮供，可減少恢復(fù)系統(tǒng)的時間，每小時或每分鐘editslog含有100萬個事務(wù)茶敏，就創(chuàng)建一個checkpoint檢查點(diǎn)壤靶。
心跳機(jī)制：
????集群的心跳機(jī)制，讓集群中各節(jié)點(diǎn)形成一個整體惊搏，可以判斷DataNode是否在線贮乳；知道各DataNode的存儲情況忧换；集群剛開始啟動時，99.9%的block沒有達(dá)到最小副本數(shù)1向拆，集群處于安全模式亚茬，涉及BlockReport；
首先浓恳，NameNode啟動時會開一個ipc server刹缝；DataNode每3秒鐘向NameNode發(fā)送一個心跳，心跳返回結(jié)果帶有NameNode給該DataNode的命令颈将；每6小時向NameNode上報當(dāng)前DataNode上的塊狀態(tài)報告梢夯，塊狀態(tài)報告包含了一個該 Datanode上所有數(shù)據(jù)塊的列表；超過10分鐘沒有收到某個DataNode 的心跳晴圾，則認(rèn)為該DataNode節(jié)點(diǎn)不可用颂砸。
負(fù)載均衡：
????在機(jī)器之間磁盤利用率不平衡、DataNode節(jié)點(diǎn)出現(xiàn)故障死姚、增添新的DataNode的時候可能造成不均衡人乓；
?????可以手動觸發(fā)負(fù)載均衡：?sbin/start-balancer.sh -t 5% # 磁盤利用率最高的節(jié)點(diǎn)若比最少的節(jié)點(diǎn)，大于5%都毒，觸發(fā)均衡
2色罚、SecondaryNameNode
引入原因：
? ? ·客戶端對HDFS的增刪重命名等操作，會保存再次namenode的editlog中账劲；
????·系統(tǒng)出故障時保屯，可從editlog進(jìn)行恢復(fù)；
????· editlog日志大小隨時間變在越來越大涤垫，系統(tǒng)重啟根據(jù)日志恢復(fù)的時候會越來越長；
????·為解決恢復(fù)系統(tǒng)時間長：設(shè)置檢查點(diǎn)checkpoint竟终，定期將namenode內(nèi)存中元數(shù)據(jù)持久化保存到磁盤蝠猬，形成fsimage文件，恢復(fù)系統(tǒng)時不再只依賴editlog日志统捶，先從fsimage恢復(fù)出元數(shù)據(jù)榆芦，再到回放editlog日志檢查點(diǎn)之后記錄；
????·但對editlog日志文件的保存策略未改變喘鸟，editlog日志依然不斷增大匆绣；
????·為解決editlog大，引入部署在另外一節(jié)點(diǎn)secondarynamenode什黑，定期做checkpoint操作崎淳，合并fsimage及editlog，nameNode就有了最新的fsimage文件和更小的edits文件愕把。
執(zhí)行過程：
????????先請求NameNode繼續(xù)滾動寫edits日志拣凹；
????????再GET請求讀取NameNode當(dāng)前fsimage及edits森爽；
????????然后讀取fsimage到內(nèi)存中，并回放執(zhí)行edits中的每個操作嚣镜，創(chuàng)建一個新的fsimage 文件爬迟，后綴為.ckpt；
????????最后PUT請求將新的fsimage發(fā)送到原NameNode菊匿，原NameNode用新的fsimage替換舊的fsimage付呕，
創(chuàng)建checkpoint兩大條件：
????·SecondaryNameNode每隔1小時創(chuàng)建一個檢查點(diǎn)；
????·Secondary NameNode每1分鐘檢查一次跌捆，從上一檢查點(diǎn)開始徽职，edits日志文件中是否已包括100萬個事務(wù)，如果是疹蛉，也會創(chuàng)建檢查點(diǎn)活箕；
NameNode與SecondaryNameNode 的區(qū)別與聯(lián)系？?
?2）區(qū)別可款，功能不同
（1）NameNode負(fù)責(zé)管理元數(shù)據(jù)育韩，以及每一路徑（文件）所對應(yīng)的數(shù)據(jù)塊信息。
（2）SecondaryNameNode闺鲸，主要定期合并NameNode的fsimage及editlog
3）聯(lián)系：
（1）SecondaryNameNode中保存了一份和namenode一致的鏡像文件（fsimage）和編輯日志（edits）筋讨。
（2）在主namenode發(fā)生故障時（假設(shè)沒有及時備份數(shù)據(jù)），可以從SecondaryNameNode恢復(fù)數(shù)據(jù)摸恍。
3悉罕、數(shù)據(jù)存儲
（1）元數(shù)據(jù)管理
????·元數(shù)據(jù)：關(guān)于文件或目錄的描述信息，如文件所在路徑立镶、文件名稱壁袄、文件類型等等，這些信息稱為文件的元數(shù)據(jù)metadata
????·命名空間：文件系統(tǒng)中媚媒，為了便于管理存儲介質(zhì)上的嗜逻，給每個目錄、目錄中的文件缭召、子目錄都起了名字栈顷，這樣形成的層級結(jié)構(gòu)，稱之為命名空間嵌巷；
·HDFS元數(shù)據(jù)：文件目錄樹萄凤、所有的文件（目錄）名稱、文件屬性（生成時間搪哪、副本靡努、權(quán)限）、每個文件的塊列表、每個block塊所在的datanode列表颤难；每個文件神年、目錄、block占用大概?150Byte字節(jié)的元數(shù)據(jù)?行嗤；元數(shù)據(jù)metadata保存在NameNode內(nèi)存中已日，所以HDFS適合存儲大文件，不適合存儲小文件
????HDFS元數(shù)據(jù)信息以兩種形式持久化保存：①編輯日志edits log②命名空間鏡像文件fsimage
????·edits log：HDFS編輯日志文件栅屏，保存客戶端對HDFS的所有更改記錄飘千，如增南蹂、刪掀鹅、重命名文件（目錄），這些操作會修改HDFS目錄樹唱较；NameNode會在編輯日志edit日志中記錄下來哥纫；類似mysql的binlog霉旗。一旦系統(tǒng)出故障，可從editlog進(jìn)行恢復(fù)
????·fsimage：HDFS元數(shù)據(jù)鏡像文件蛀骇，即將namenode內(nèi)存中的數(shù)據(jù)落入磁盤生成的文件厌秒；保存了文件系統(tǒng)目錄樹信息以及文件、塊擅憔、datanode的映射關(guān)系?
（2）分塊存儲
????數(shù)據(jù)分塊存儲和副本的存放鸵闪，是保證可靠性和高性能的關(guān)鍵：??
????向HDFS上傳文件，是按照128M為單位暑诸，切分成一個個block蚌讼，分散的存儲在集群的不同數(shù)據(jù)節(jié)點(diǎn)datanode上。如果每個block只有一份的話个榕，當(dāng)block所在的節(jié)點(diǎn)宕機(jī)后篡石，此block將無法訪問，進(jìn)而導(dǎo)致文件無法完整讀任鞑伞凰萨；為保正數(shù)據(jù)的可用及容錯，HDFS設(shè)計(jì)成每個block共有三份苛让，即三個副本；實(shí)際機(jī)房中湿诊，會有機(jī)架狱杰，每個機(jī)架上若干服務(wù)器
4、寫數(shù)據(jù)流程
請求上傳——檢查目錄——可以上傳?
查詢Datanode信息——分配datanode?
建立數(shù)據(jù)流——根據(jù)管道寫數(shù)據(jù)——?循環(huán)寫入其他block
1）請求上傳：客戶端向namenode請求上傳文件厅须，namenode檢查目標(biāo)文件是否已存在仿畸，父目錄是否存在。?namenode返回是否可以上傳。
2）分配datanode：客戶端請求第一個block上傳到哪幾個datanode服務(wù)器上错沽，namenode返回3個datanode節(jié)點(diǎn)簿晓，如dn1、dn2千埃、dn3憔儿。
3）建立數(shù)據(jù)流管道：客戶端請求dn1上傳數(shù)據(jù)，dn1收到請求會繼續(xù)調(diào)用dn2放可，然后dn2調(diào)用dn3谒臼，dn1、dn2耀里、dn3逐級應(yīng)答客戶端蜈缤，?建立數(shù)據(jù)流管道pipeline ；
4）根據(jù)管道寫數(shù)據(jù)：客戶端開始往dn1上傳第一個block（先從磁盤讀取數(shù)據(jù)放到一個本地內(nèi)存緩存），以packet為單位，dn1收到一個packet就會傳給pipeline中的下一個 dn2，直到最后一個dn3；dn1每傳完一個packet，會放入一個應(yīng)答隊(duì)列ackQueue等待應(yīng)答，最后一個datanode成功存儲之后，會返回傳遞至客戶端ack packet（確認(rèn)隊(duì)列），成功收到ack后驻呐，會將packet刪除猜拾，否則重新發(fā)送。
5）循環(huán)寫入其他block：當(dāng)一個block傳輸完成之后务豺，客戶端再次請求namenode上傳第二個block的服務(wù)器。文件最后一個block塊數(shù)據(jù)寫完后汹桦，會再發(fā)送一個空的packet钥弯，表示當(dāng)前block寫完了脆霎，然后關(guān)閉pipeline狈惫；
5、讀數(shù)據(jù)流程
1）客戶端向namenode請求下載文件忆肾，namenode通過查詢元數(shù)據(jù)，找到文件塊所在的datanode地址客冈。
2）挑選一臺datanode（就近原則郊酒，然后隨機(jī)）服務(wù)器褐健，請求讀取數(shù)據(jù)蚜迅。
3）datanode開始傳輸數(shù)據(jù)給客戶端（從磁盤里面讀取數(shù)據(jù)放入流，以packet為單位來做校驗(yàn)）俊抵。
4）客戶端以packet為單位接收谁不，先在本地緩存，然后寫入目標(biāo)文件徽诲。
6刹帕、小文件治理
NameNode存儲著文件系統(tǒng)的元數(shù)據(jù)，每個文件谎替、目錄偷溺、塊大概有150字節(jié)的元數(shù)據(jù)；小文件數(shù)量多會大量占用namenode的內(nèi)存; 使namenode讀取元數(shù)據(jù)速度變慢, 啟動時間延長; 還因?yàn)檎加脙?nèi)存過大, 導(dǎo)致gc時間增加等.
解決辦法:兩個角度,
一是钱贯，從數(shù)據(jù)源入手,如每小時抽取一次改為每天抽取一次等方法來積累數(shù)據(jù)量.
二是挫掏，選擇合并.HAR文件方案，Sequence Files方案
????如果小文件無可避免,一般就采用合并的方式解決. 可以寫一個MR任務(wù)讀取某個目錄下的所有小文件, 并重寫為一個大文件.
????SequenceFile文件秩命，是一種由header信息和一條條record記錄組成的文件尉共。每個record是鍵值對形式，小文件名作為當(dāng)前record的鍵硫麻，小文件的內(nèi)容作為當(dāng)前record的值爸邢；
7、高可用HA
????對于HDFS拿愧，nameNode存儲元數(shù)據(jù)在內(nèi)存中杠河，并負(fù)責(zé)管理文件系統(tǒng)的命名空間和客戶端對HDFS的讀寫請求。只存在一個nameNode浇辜，一旦發(fā)生“單點(diǎn)故障”券敌，會使整個系統(tǒng)失效。
????HDFS2.x采用了HA（High Availability高可用）架構(gòu)柳洋。（HDFS HA可看作為NN和SN的優(yōu)化）待诅；在HA集群中，可設(shè)置兩個nameNode熊镣，一個處于“活躍（Active）”狀態(tài)卑雁，另一個處于“待命（Standby）”狀態(tài)募书。由zookeeper確保一主一備，主備切換
如何熱備份元數(shù)據(jù)：
????Standby nameNode是ActivenameNode的“熱備份”测蹲，因此Active nameNode的狀態(tài)信息必須實(shí)時同步到StandbynameNode莹捡。
????Active nameNode將更新數(shù)據(jù)寫入到共享存儲系統(tǒng)，StandbynameNode一直監(jiān)聽該系統(tǒng)扣甲，一旦發(fā)現(xiàn)有新的數(shù)據(jù)寫入篮赢，就立即從公共存儲系統(tǒng)中讀取這些數(shù)據(jù)并加載到StandbynameNode自己內(nèi)存中，從而保證元數(shù)據(jù)與ActivenameNode狀態(tài)一致琉挖。
????塊報告：nameNode保存了數(shù)據(jù)塊到實(shí)際存儲位置的映射信息启泣，為了實(shí)現(xiàn)故障時的快速切換，必須保證StandbynameNode中也包含最新的塊映射信息示辈。因此需要給所有DataNode配置Active和Standby兩個nameNode的地址寥茫，把塊的位置和心跳信息同時發(fā)送到兩個nameNode上。
8矾麻、Hadoop聯(lián)邦
HA高可用解決了單點(diǎn)故障問題坠敷，但HA本質(zhì)上還是單個nameNode工作，在擴(kuò)展性射富、整體性能和隔離性方面仍有問題膝迎。
·擴(kuò)展性：元數(shù)據(jù)存儲在nameNode內(nèi)存中，受限于內(nèi)存上限（每個文件胰耗、目錄限次、block占用約150字節(jié)）
·整體性能：吞吐量受單個NN的影響
·隔離性：一個程序可能會影響其他程序的運(yùn)行，如果一個程序消耗過多資源會導(dǎo)致其他程序無法順利運(yùn)行
HDFS聯(lián)邦柴灯，解決擴(kuò)展性卖漫、整體性能和隔離性
·擴(kuò)展性：有多個命名空間；每個命名空間有一個nameNode或一主一備兩個nameNode赠群，使得HDFS的命名服務(wù)能夠水平擴(kuò)展羊始；
·整體性能：多個nameNode分別管理各自命名空間和塊，相互獨(dú)立查描，不需要彼此協(xié)調(diào)突委；
9、文件壓縮
·gzip：優(yōu)點(diǎn)是壓縮率高冬三，速度快匀油。Hadoop支持與直接處理文本一樣。缺點(diǎn)不支持split勾笆，當(dāng)文件壓縮在128m內(nèi)敌蚜，都可以用gzip；
·bzip2：支持split窝爪，很高的壓縮率弛车，比gzip高齐媒，hadoop支持但不支持native，linux自帶命令使用方便纷跛。缺點(diǎn)壓縮解壓速度慢
·Izo： 優(yōu)點(diǎn)壓縮速度快里初，合理的壓縮率；支持split忽舟，是最流行的壓縮格式。支持native庫淮阐；缺點(diǎn) 比gzip壓縮率低叮阅，hadoop本身不支持，需要安裝泣特；在應(yīng)用中對lzo格式文件需要處理如 指定inputformat為lzo格式浩姥；
·Snappy：壓縮高速，壓縮率合理状您，支持本地庫勒叠，不支持split，hadoop不支持膏孟，要安裝linux沒有對應(yīng)命令眯分；當(dāng)MR輸出數(shù)據(jù)較大，作為到reduce數(shù)據(jù)壓縮格式
?二柒桑、MapReduce
????MapReduce弊决，是采用一種分而治之的思想，設(shè)計(jì)出來的分布式離線計(jì)算框架魁淳，輸入輸出都是hdfs飘诗。由兩個階段組成：Map階段（切分成一個個小的任務(wù)）；Reduce階段（匯總小任務(wù)的結(jié)果）
?????map任務(wù)一次讀取block的一行數(shù)據(jù)界逛，將當(dāng)前所讀行的行首相對于當(dāng)前block開始處的字節(jié)偏移量作為key(0)昆稿，當(dāng)前行的內(nèi)容作為value，以kv對的形式輸入map()方法息拜；? ?map()方法內(nèi)溉潭，按需求，執(zhí)行業(yè)務(wù)代碼岛抄；? ?map()方法的輸出作為reduce()的輸入；? ? 輸入文件有幾個block狈茉，就會生成幾個map任務(wù)夫椭；
?????reduce任務(wù)通過網(wǎng)絡(luò)將各map任務(wù)輸出結(jié)果中，屬于自己的數(shù)據(jù)拉取過來氯庆，key相同的鍵值對作為一組蹭秋，調(diào)用一次reduce()扰付；reduce任務(wù)生成一個結(jié)果文件，文件寫入HDFS仁讨；reduce任務(wù)的個數(shù)羽莺，由程序中編程指定：job.setNumReduceTasks(4)
????shuffle主要指的是map端的輸出作為reduce端輸入的過程
map端的shuffle
（1）環(huán)形內(nèi)存緩沖：
????????每個map任務(wù)都有一個對應(yīng)的環(huán)形內(nèi)存緩沖區(qū)；map()方法輸出kv對時洞豁，先寫入到環(huán)形緩沖區(qū)（默認(rèn)100M盐固，當(dāng)內(nèi)容占據(jù)80%緩沖區(qū)空間后，由一個后臺線程將緩沖區(qū)中的數(shù)據(jù)溢出寫到一個磁盤文件丈挟。
????在溢出寫的過程中刁卜，map任務(wù)可以繼續(xù)向環(huán)形緩沖區(qū)寫入數(shù)據(jù)；但是若寫入速度大于溢出寫的速度曙咽，最終造成100m占滿后蛔趴，map任務(wù)會暫停向環(huán)形緩沖區(qū)中寫數(shù)據(jù)的過程；只執(zhí)行溢出寫的過程例朱；直到環(huán)形緩沖區(qū)的數(shù)據(jù)全部溢出寫到磁盤孝情，才恢復(fù)向緩沖區(qū)寫入
（2）后臺線程溢寫磁盤過程，
????1）分區(qū)：先對每個溢寫的kv對根據(jù)key進(jìn)行hash分區(qū)洒嗤；分區(qū)的個數(shù)由reduce任務(wù)數(shù)決定箫荡；自定義分區(qū)，實(shí)現(xiàn)Partitioner接口渔隶，在getPartition()中實(shí)現(xiàn)分區(qū)邏輯
????2）排序：每個分區(qū)中菲茬，每個kv對根據(jù)key在內(nèi)存中排序派撕；
????3）可選combine聚合：若設(shè)置了map端本地聚合combiner婉弹，則對每個分區(qū)中搂抒，排好序的數(shù)據(jù)做combine預(yù)聚合操作笼裳；
????4）可選壓縮：若設(shè)置了對map輸出壓縮的功能刁岸，會對溢寫數(shù)據(jù)壓縮
reduce端的shuffle
?（1）拉取：
????reduce task會在每個map task運(yùn)行完成后展鸡，通過HTTP獲得map task輸出中老速，屬于自己的分區(qū)數(shù)據(jù)（許多kv對）宪睹，如果map輸出數(shù)據(jù)比較小慎冤，先保存在reduce的jvm內(nèi)存中整葡，否則直接寫入reduce磁盤姆打。
（2）歸并merge:
????一旦內(nèi)存緩沖區(qū)達(dá)到閾值（默認(rèn)0.66）或map輸出數(shù)的閾值（默認(rèn)1000）良姆，則觸發(fā)歸并merge，結(jié)果寫到本地磁盤幔戏。
（3）combine（可選）：若MR編程指定了combine玛追，在歸并過程中會執(zhí)行combine操作
2、數(shù)據(jù)傾斜
????MR數(shù)據(jù)傾斜，一般是指map端輸出數(shù)據(jù)中存在數(shù)據(jù)頻率傾斜的狀況痊剖，即部分輸出鍵的數(shù)據(jù)量遠(yuǎn)遠(yuǎn)大于其它的輸出鍵韩玩，導(dǎo)致map和reduce的任務(wù)執(zhí)行時間大為延長，也會讓需要緩存數(shù)據(jù)集的操作消耗更多的內(nèi)存資源陆馁。
造成原因：
????????·原數(shù)據(jù)頻率不一致找颓，某些key鍵值對數(shù)量遠(yuǎn)多于其他鍵的鍵值對，導(dǎo)致分區(qū)時分區(qū)不均勻叮贩，一些分區(qū)中數(shù)據(jù)多击狮，一些少
????????·原數(shù)據(jù)大小不同，某些key鍵值對的大小遠(yuǎn)遠(yuǎn)大于平均值益老。對緩存造成較大的影響彪蓬，乃至導(dǎo)致OutOfMemoryError異常。
如何減緩數(shù)據(jù)傾斜：主要是分區(qū)不均勻杨箭，
? ??①預(yù)聚合Combine，聚合并精簡數(shù)據(jù)储狭。
? ??②自定義分區(qū)互婿，根據(jù)輸出鍵背景知識，進(jìn)行自定義分區(qū)辽狈。
? ??③抽樣并范圍分區(qū)：先對原數(shù)據(jù)進(jìn)行抽樣慈参，得到的結(jié)果集，通過TotalOrderPartitioner中范圍分區(qū)器刮萌，預(yù)設(shè)分區(qū)邊界值驮配，進(jìn)行分區(qū)。
????④數(shù)據(jù)大小傾斜着茸，調(diào)參line.maxlength壮锻，限制RecordReader讀取最大長度。
3涮阔、代碼
?繼承Mapper類猜绣，實(shí)現(xiàn)map()方法；
繼承Reducer類敬特，實(shí)現(xiàn)reduce()方法
?三掰邢、Yarn
1、原理架構(gòu)
YARN(Yet Another Resource Negotiator)是Hadoop2.0資源管理的子項(xiàng)目
1) Resource Manager：全局資源管理器伟阔，一個集群只有一個RM辣之，類似老總。?負(fù)責(zé)和AM(Application Master)交互皱炉，資源調(diào)度怀估、資源分配等；
2）Node Manager：一臺機(jī)器上的管理者合搅，類似于部門經(jīng)理奏夫。管理著本機(jī)上若干小弟Containers的生命周期怕篷、監(jiān)視資源和跟蹤節(jié)點(diǎn)健康并定時上報給RM；接收并處理來自AM的Container啟動/停止等各種請求酗昼。
3）Application Master：應(yīng)用程序的管理器廊谓，類似項(xiàng)目經(jīng)理，一個應(yīng)用程序只有一個AM麻削。負(fù)責(zé)任務(wù)開始時找RM要資源蒸痹，任務(wù)完成時向RM注銷自己，釋放資源呛哟；與NM通信以啟動/停止任務(wù)叠荠；接收NM同步的任務(wù)進(jìn)度信息。
ApplicationMaster可以在容器內(nèi)運(yùn)行任何類型的任務(wù)扫责，不同的 ApplicationMaster 被分布到不同的節(jié)點(diǎn)上榛鼎，因此它們之間不會相互影響。
?Container：一臺機(jī)器上具體提供運(yùn)算資源鳖孤，類似員工者娱，將設(shè)備上的內(nèi)存、CPU苏揣、磁盤黄鳍、網(wǎng)絡(luò)等資源封裝在一起的抽象概念——“資源容器”，Container是一個動態(tài)資源分配單位平匈，為了限定每個任務(wù)使用的資源量框沟。
Client向 ResourceManager 提交的每一個應(yīng)用程序都必須有一個 ApplicationMaster，它經(jīng)過 ResourceManager 分配資源后增炭，運(yùn)行于某一個 Slave 節(jié)點(diǎn)的 Container 中忍燥，具體做事情的 Task，同樣也運(yùn)行與某一個 Slave 節(jié)點(diǎn)的 Container 中隙姿。
2灾前、執(zhí)行過程
????????Application在Yarn中的執(zhí)行過程，整個執(zhí)行過程可以總結(jié)為三步：應(yīng)用程序提交?-> 啟動應(yīng)用的ApplicationMaster實(shí)例?-> ApplicationMaster實(shí)例管理應(yīng)用程序的執(zhí)行
精簡版的：
????步驟1：客戶端程序向 ResourceManager 提交應(yīng)用孟辑，請求一個 RM的ApplicationMaster 實(shí)例哎甲，并請求傳遞給RM的scheduler（調(diào)度器）；調(diào)度器分配container（容器）
????步驟2：ResourceManager 找到一個可以運(yùn)行一個 Container 的 NodeManager饲嗽，并在這個 Container 中啟動 ApplicationMaster 實(shí)例炭玫；
????步驟3：ApplicationMaster 與 ResourceManager 注冊進(jìn)行通信，為內(nèi)部要執(zhí)行的任務(wù)申請資源貌虾，一旦得到資源后吞加，將于 NodeManager 通信，以啟動對應(yīng)的 Task；
????步驟4：所有任務(wù)運(yùn)行完成后衔憨，ApplicationMaster 向 ResourceManager 注銷叶圃，整個應(yīng)用程序運(yùn)行結(jié)束。
2践图、調(diào)度器
在YARN中有三種調(diào)度器可以選擇：FIFO Scheduler 掺冠，Capacity Scheduler，F(xiàn)air?Scheduler
3码党、yarn狀態(tài)
yarn的web ui上能夠看到y(tǒng)arn 應(yīng)用程序分為如下幾個狀態(tài):
- NEW -----新建狀態(tài)
- NEW_SAVING-----新建保存狀態(tài)
- SUBMITTED-----提交狀態(tài)
- ACCEPTED-----接受狀態(tài)
- RUNNING-----運(yùn)行狀態(tài)
- FINISHED-----完成狀態(tài)
- FAILED-----失敗狀態(tài)
- KILLED-----殺掉狀態(tài)
四德崭、zookeeper
ZooKeeper是分布式應(yīng)用程序的協(xié)調(diào)服務(wù)。主從架構(gòu)leader揖盘；follower或observer
主要通過本身的文件系統(tǒng)和通知機(jī)制眉厨，維護(hù)和監(jiān)控存儲的數(shù)據(jù)的狀態(tài)變化，達(dá)到基于數(shù)據(jù)的集群管理兽狭，主要用來解決分布式集群中應(yīng)用系統(tǒng)的一致性問題（指數(shù)據(jù)在多個副本之間保持一致的特性）憾股。為了保證事務(wù)的順序一致性，ZK采用遞增的事務(wù)id號（zxid）來標(biāo)識事務(wù)箕慧，所有提議（proposal）都有zxid服球。
ZooKeeper??=??簡版文件系統(tǒng)(Znode)?+原語基本命令+通知機(jī)制(Watcher)。
1销钝、保證事務(wù)的順序一致性
（1）zookeeper采用了全局遞增的事務(wù)Id來標(biāo)識有咨，所有的 proposal（提議）在被提出時候琐簇，加上了?zxid蒸健。zxid實(shí)際上是一個 64 位的數(shù)字，高32 位是 epoch用來標(biāo)識 leader 周期婉商，如果有新的 leader 產(chǎn)生出來似忧，epoch會自增；低32位用來遞增計(jì)數(shù)丈秩。
（2）當(dāng)新產(chǎn)生proposal的時候盯捌，會依據(jù)數(shù)據(jù)庫的兩階段過程，首先會向其他的 server 發(fā)出事務(wù)執(zhí)行請求蘑秽，如果超過半數(shù)的機(jī)器都能執(zhí)行并且能夠成功饺著，那么就會開始執(zhí)行。
客戶端的讀請求可以被集群中的任意一臺機(jī)器處理肠牲，如果讀請求在節(jié)點(diǎn)上注冊了監(jiān)聽器幼衰，這個監(jiān)聽器也是由所連接的zookeeper機(jī)器來處理。對于寫請求缀雳，這些請求會同時發(fā)給其他zookeeper機(jī)器并且達(dá)成一致后渡嚣，請求才會返回成功。因此， 隨著 zookeeper 的集群機(jī)器增多识椰，讀請求的吞吐會提高但是寫請求的吞吐會下降绝葡。
[if !supportLists]2、[endif]ZAB協(xié)議
ZAB協(xié)議是Zookeeper 專門設(shè)計(jì)的一種支持崩潰恢復(fù)的原子廣播協(xié)議腹鹉。
當(dāng)整個zookeeper集群剛剛啟動或者 Leader 服務(wù)器宕機(jī)藏畅、重啟或者網(wǎng)絡(luò)故障導(dǎo)致不存在過半的服務(wù)器與 Leader 服務(wù)器保持正常通信時，所有進(jìn)程（服務(wù)器）進(jìn)入崩潰恢復(fù)模式种蘸，首先選舉產(chǎn)生新的 Leader 服務(wù)器墓赴，然后集群中 Follower 服務(wù)器開始與新的 Leader 服務(wù)器進(jìn)行數(shù)據(jù)同步，當(dāng)集群中超過半數(shù)機(jī)器與該 Leader服務(wù)器完成數(shù)據(jù)同步之后航瞭，退出恢復(fù)模式進(jìn)入消息廣播模式诫硕，Leader 服務(wù)器開始接收客戶端的事務(wù)請求生成事物提案來進(jìn)行事務(wù)請求處理。
Zab協(xié)議兩種模式 ：恢復(fù)模式（選主）刊侯，廣播模式（同步）
恢復(fù)模式（選主）分兩種情況：全新集群leader選舉章办、非全新集群leader選舉；
集群中過半數(shù)Server啟動后滨彻，才能選舉出Leader藕届；投票信息結(jié)構(gòu)為(sid, zxid)，服務(wù)器ID亭饵，事務(wù)ID休偶；規(guī)則為：zxid大的server勝出；zxid相等辜羊，sid大的勝出
選主后的數(shù)據(jù)同步踏兜，進(jìn)行廣播模式
leader構(gòu)建NEWLEADER封包，包含leader中最大的zxid值八秃；廣播給其它follower碱妆；follower收到后，如果自己的最大zxid小于leader的昔驱，則需要與leader狀態(tài)同步疹尾；否則不需要；leader給需要同步的每個follower創(chuàng)建LearnerHandler線程骤肛，負(fù)責(zé)數(shù)據(jù)同步請求纳本；leader主線程等待LearnHandler線程處理結(jié)果；只有多數(shù)follower完成同步腋颠，leader才開始對外服務(wù)繁成，響應(yīng)寫請求、
該協(xié)議需要做到以下幾點(diǎn)：
（1）集群在半數(shù)以下節(jié)點(diǎn)宕機(jī)的情況下秕豫，能正常對外提供服務(wù)朴艰；
（2）客戶端的寫請求观蓄，全部轉(zhuǎn)交給leader來處理，leader需確保寫變更祠墅，能實(shí)時同步給所有follower及observer侮穿；
（3）leader宕機(jī)或整個集群重啟時，需要確保那些已經(jīng)在leader服務(wù)器上提交的事務(wù)最終被所有服務(wù)器都提交毁嗦，確保丟棄那些只在leader服務(wù)器上被提出的事務(wù)亲茅，并保證集群能快速恢復(fù)到故障前的狀態(tài)。?
3狗准、DFS HA方案
主要分兩部分：①元數(shù)據(jù)同步 ②主備切換
①元數(shù)據(jù)同步：
·在同一個HDFS集群克锣，運(yùn)行兩個互為主備的NameNode節(jié)點(diǎn)，在主備切換過程中腔长，新的Active NameNode必須確保與原Active NamNode元數(shù)據(jù)同步完成袭祟，才能對外提供服務(wù)。
·用JournalNode集群作為共享存儲系統(tǒng)捞附，客戶端對HDFS做操作 巾乳，同時會記錄到JournalNode集群，存儲HDFS新產(chǎn)生的元數(shù)據(jù)鸟召。
·當(dāng)有新數(shù)據(jù)寫入JournalNode集群時胆绊，Standby NameNode能監(jiān)聽到此情況，將新數(shù)據(jù)同步過來欧募。這樣压状，Active NameNode(寫入)和Standby NameNode(讀取)實(shí)現(xiàn)元數(shù)據(jù)同步 。
②主備切換：
·每個NameNode節(jié)點(diǎn)上各有一個ZKFC進(jìn)程跟继，ZKFC會監(jiān)控NameNode的健康狀況种冬，當(dāng)發(fā)現(xiàn)Active NameNode異常時，通過Zookeeper集群進(jìn)行namenode主備選舉还栓，完成Active和Standby狀態(tài)的切換
4碌廓、四種類型的數(shù)據(jù)節(jié)點(diǎn) Znod
·（1）PERSISTENT-持久節(jié)點(diǎn)
除非手動刪除传轰，否則節(jié)點(diǎn)一直存在于Zookeeper上
·（2）EPHEMERAL-臨時節(jié)點(diǎn)
臨時節(jié)點(diǎn)的生命周期與客戶端會話綁定剩盒，一旦客戶端會話失效（客戶端與
zookeeper連接斷開不一定會話失效），那么這個客戶端創(chuàng)建的所有臨時節(jié)點(diǎn) 都會被移除慨蛙。
·（3）PERSISTENT_SEQUENTIAL-持久順序節(jié)點(diǎn)
基本特性同持久節(jié)點(diǎn)辽聊，只是增加了順序?qū)傩裕?jié)點(diǎn)名后邊會追加一個由父節(jié) 點(diǎn)維護(hù)的自增整型數(shù)字期贫。
·（4）EPHEMERAL_SEQUENTIAL-臨時順序節(jié)點(diǎn)
基本特性同臨時節(jié)點(diǎn)跟匆，增加了順序?qū)傩裕?jié)點(diǎn)名后邊會追加一個由父節(jié)點(diǎn)維 護(hù)的自增整型數(shù)字通砍。
5玛臂、Server工作狀態(tài)
服務(wù)器具有四種狀態(tài)烤蜕，分別是LOOKING、FOLLOWING迹冤、LEADING讽营、OBSERVING。
1泡徙、LOOKING：尋找Leader狀態(tài)橱鹏。當(dāng)服務(wù)器處于該狀態(tài)時，它會認(rèn)為當(dāng)前集群中
沒有Leader堪藐，因此需要進(jìn)入 Leader 選舉狀態(tài)莉兰。
2、FOLLOWING：跟隨者狀態(tài)礁竞。表明當(dāng)前服務(wù)器角色是Follower糖荒。
3、LEADING：領(lǐng)導(dǎo)者狀態(tài)模捂。表明當(dāng)前服務(wù)器角色是Leader寂嘉。
4、OBSERVING：觀察者狀態(tài)枫绅。表明當(dāng)前服務(wù)器角色是Observer泉孩。
6、zk節(jié)點(diǎn)宕機(jī)如何處理并淋？
Zookeeper本身也是集群寓搬，推薦配置不少于 3 個服務(wù)器。Zookeeper 自身也要保證當(dāng)一個節(jié)點(diǎn)宕機(jī)時县耽，其他節(jié)點(diǎn)會繼續(xù)提供服務(wù)句喷。
·如果是一個Follower宕機(jī)，還有 2 臺服務(wù)器提供訪問兔毙，因?yàn)?Zookeeper 上的數(shù)據(jù)是有多個副本的唾琼，數(shù)據(jù)并不會丟失；
·如果是一個Leader宕機(jī)，Zookeeper 會選舉出新的 Leader倘要。 ZK 集群的機(jī)制是只要超過半數(shù)的節(jié)點(diǎn)正常互广，集群就能正常提供服務(wù)。只有在 ZK 節(jié)點(diǎn)掛得太多祭饭，只剩一半或不到一半節(jié)點(diǎn)能工作，集群才失效叙量。
·所以
3個節(jié)點(diǎn)的 cluster 可以掛掉 1 個節(jié)點(diǎn)(leader 可以得到 2 票>1.5)
2個節(jié)點(diǎn)的 cluster 就不能掛掉任何 1 個節(jié)點(diǎn)了(leader 可以得到 1 票<=1)
7倡蝙、集群支持動態(tài)添加機(jī)器嗎？
Zookeeper在水平擴(kuò)容這方面不太好绞佩。兩種方式：
全部重啟：關(guān)閉所有Zookeeper服務(wù)寺鸥，修改配置之后啟動猪钮。不影響之前客戶端的
會話。
逐個重啟：在過半存活即可用的原則下胆建，一臺機(jī)器重啟不影響整個集群對外提供
服務(wù)躬贡。這是比較常用的方式。
3.5版本開始支持動態(tài)擴(kuò)容眼坏。
8拂玻、Zk的java客戶端都有哪些？
java客戶端：zk 自帶的 zkclient 及 Apache 開源的 Curator宰译。
常用命令：ls get set create delete等
??七檐蚜、Kafka
·kafka是一個分布式消息系統(tǒng)。具有高性能沿侈、持久化闯第、多副本備份、橫向擴(kuò)展能力缀拭。將消息保存在磁盤中咳短，以順序讀寫方式訪問磁盤，避免隨機(jī)讀寫導(dǎo)致性能瓶頸蛛淋。生產(chǎn)者往隊(duì)列里寫消息咙好，消費(fèi)者從隊(duì)列里取消息進(jìn)行業(yè)務(wù)邏輯。
·Kafka集群包含一個或多個服務(wù)器褐荷，服務(wù)器節(jié)點(diǎn)稱為broker勾效，broker存儲topic的數(shù)據(jù)。broker可分為Controller與follower叛甫。Controller管理集群broker的上下線层宫，所有topic的分區(qū)副本分配和leaderPartition選舉等工作
·每條發(fā)布到Kafka集群的消息都有一個類別Topic，Topic像一個消息隊(duì)列其监，每個topic包含一個或多個partition萌腿，Kafka分配的單位是partition。每個partition有多個副本抖苦，其中有且僅有一個作為Leader毁菱，Leader是當(dāng)前負(fù)責(zé)數(shù)據(jù)的讀寫的partition，其他partition為flower作為備用選主睛约。當(dāng)Follower與Leader掛掉鼎俘、卡住或者同步太慢哲身，leader會把這個follower從“in sync replicas”（ISR）列表中刪除辩涝，重新創(chuàng)建一個Follower。
·offset：消費(fèi)者在對應(yīng)分區(qū)上已經(jīng)消費(fèi)的消息數(shù)(位置)勘天，kafka0.8 版本之前offset保存在zookeeper上怔揩。之后offset保存在kafka集群上捉邢。
1、kafka的文件存儲機(jī)制
·同一個topic下商膊，有多個不同的partition伏伐，每個partition為一個目錄。partition命名的規(guī)則是晕拆，topic的名稱加上一個序號藐翎，序號從0開始。
·每一個partition目錄下的文件实幕，被平均切割成大小相等的數(shù)據(jù)文件（每一個數(shù)據(jù)文件都被稱為一個段（segment file）吝镣；每一個segment段消息，數(shù)量不一定相等昆庇，使得老的segment可以被快速清除末贾。默認(rèn)保留7天的數(shù)據(jù)，每次滿1G后整吆，在寫入到一個新的文件中拱撵。
·每一個partition只需要支持順序讀寫就可以，也就是說它只會往文件的末尾追加數(shù)據(jù)表蝙，這就是順序?qū)懙倪^程拴测，生產(chǎn)者只會對每一個partition做數(shù)據(jù)的追加（寫操作）。
·在partition目錄下府蛇，有兩類文件昼扛，一類是以log為后綴的文件，一類是以index為后綴的文件欲诺，每一個log文件和一個index文件相對應(yīng)抄谐，這一對文件就是一個segment file，也就是一個段扰法。log文件：就是數(shù)據(jù)文件蛹含，里面存放的就是消息， index文件：是索引文件塞颁，記錄元數(shù)據(jù)信息浦箱。
·元數(shù)據(jù)指向，對應(yīng)的數(shù)據(jù)文件（log文件）中消息的物理偏移地址祠锣。log文件達(dá)到1個G后滾動重新生成新的log文件酷窥。
2、Kafka內(nèi)部數(shù)據(jù)不丟失
調(diào)整Producer伴网，consumer蓬推，broker的各項(xiàng)參數(shù)，保證Kafka內(nèi)部數(shù)據(jù)不丟失
①producer：acks參數(shù)澡腾、retry參數(shù)沸伏、
高可用型糕珊，配置：acks = all，retries > 0 retry.backoff.ms=100(毫秒) (并根據(jù)實(shí)際情況設(shè)置retry可能恢復(fù)的間隔時間)
優(yōu)點(diǎn)：這樣保證了producer端每發(fā)送一條消息都要成功毅糟，如果不成功并將消息緩存起來红选，等異常恢復(fù)后再次發(fā)送姆另。缺點(diǎn)：這樣保證了高可用喇肋，但是這會導(dǎo)致集群的吞吐量不是很高，因?yàn)閿?shù)據(jù)發(fā)送到broker之后迹辐，leader要將數(shù)據(jù)同步到fllower上苟蹈，如果網(wǎng)絡(luò)帶寬、不穩(wěn)定等情況時右核，ack響應(yīng)時間會更長
2.折中型慧脱，配置：acks = 1retries > 0 retries時間間隔設(shè)置 (并根據(jù)實(shí)際情況設(shè)置retries可能恢復(fù)的間隔時間)
優(yōu)點(diǎn)：保證了消息的可靠性和吞吐量，是個折中的方案贺喝；缺點(diǎn)：性能處于2者中間
3.高吞吐型菱鸥，配置：acks = 0
優(yōu)點(diǎn)：可以相對容忍一些數(shù)據(jù)的丟失，吞吐量大躏鱼，可以接收大量請求氮采；缺點(diǎn)：不知道發(fā)送的消息是否成功
②?Consumer： group.id 、auto.offset.reset 染苛、enable.auto.commit
1設(shè)置consumergroup分組的id鹊漠，group.id:如果為空，則會報異常
2設(shè)置從何處開始進(jìn)行消費(fèi)auto.offset.reset = earliest(最早) /latest(最晚)
3設(shè)置是否開啟自動提交消費(fèi)位移的功能,默認(rèn)開啟 enable.auto.commit= true/false(默認(rèn)true)
③Broker：replication-factor茶行、min.insync.replicas躯概、unclean.leander.election.enable
1.replication-factor >=2
在創(chuàng)建topic時會通過replication-factor來創(chuàng)建副本的個數(shù)，它提高了kafka的高可用性畔师，同時娶靡，它允許n-1臺broker掛掉，設(shè)置好合理的副本因子對kafka整體性能是非常有幫助的看锉，通常是3個姿锭，極限是5個，如果多了也會影響開銷伯铣。
2.min.insync.replicas = 2
分區(qū)ISR隊(duì)列集合中最少有多少個副本呻此，默認(rèn)值是1
3.unclean.leander.election.enable = false
是否允許從ISR隊(duì)列中選舉leader副本，默認(rèn)值是false,如果設(shè)置成true,則可能會造成數(shù)據(jù)丟失腔寡。
3焚鲜、kafka調(diào)優(yōu)，提升生產(chǎn)者的吞吐量
1）設(shè)置發(fā)送消息的緩沖區(qū)buffer.memory：默認(rèn)32MB。如果發(fā)送消息速度小于寫入消息速度恃泪，就會導(dǎo)致緩沖區(qū)寫滿郑兴，此時生產(chǎn)消息就會阻塞住犀斋，所以說這里就應(yīng)該多做一些壓測贝乎，盡可能保證說這塊緩沖區(qū)不會被寫滿導(dǎo)致生產(chǎn)行為被阻塞住叽粹；
2）設(shè)置壓縮compression.type览效，默認(rèn)是none，不壓縮虫几，但是也可以使用lz4壓縮锤灿，效率還是不錯的，壓縮之后可以減小數(shù)據(jù)量辆脸，提升吞吐量但校，但是會加大producer端的cpu開銷。
3）設(shè)置batch的大小batch.size啡氢，默認(rèn)16kb状囱，就是一個batch滿了16kb就發(fā)送出去，一般在實(shí)際生產(chǎn)環(huán)境倘是，這個batch的值可以增大一些來提升吞吐量亭枷。如果batch太小，會導(dǎo)致頻繁網(wǎng)絡(luò)請求搀崭，吞吐量下降叨粘；如果batch太大，會導(dǎo)致一條消息需要等待很久才能被發(fā)送出去瘤睹，而且會讓內(nèi)存緩沖區(qū)有很大壓力升敲，過多數(shù)據(jù)緩沖在內(nèi)存里
4）設(shè)置消息的發(fā)送延遲linger.ms，這個值默認(rèn)是0轰传，意思就是消息必須立即被發(fā)送冻晤，但是這是不對的。一般設(shè)置一個100毫秒之內(nèi)的绸吸，這樣的話就是說鼻弧，這個消息被發(fā)送出去后進(jìn)入一個batch锦茁，如果100毫秒內(nèi)笨篷，這個batch滿了16kb，自然就會發(fā)送出去托慨。但是如果100毫秒內(nèi)柿祈，batch沒滿虚茶，那么也必須把消息發(fā)送出去了，不能讓消息的發(fā)送延遲時間太長或粮，也避免給內(nèi)存造成過大的一個壓力导饲。
4、sparkStreaming整合kafka
sparkStreaming對接kafka兩種方式：
[if !supportLists]1.?[endif]Receiver模式被啼，由kafka將數(shù)據(jù)發(fā)送數(shù)據(jù)帜消，Spark Streaming被動接收數(shù)據(jù)棠枉；
在spark的executor當(dāng)中啟動了一些receiver的線程浓体，專門去kafka拉取數(shù)據(jù)，拉取回來的數(shù)據(jù)這些receiver不會處理辈讶，然后另外一些線程專門來處理數(shù)據(jù)命浴，基于kafka的high level API進(jìn)行消費(fèi)，offset自動保存到了zk當(dāng)中去了贱除，不用我們主動去維護(hù)offset的值
問題：拉取數(shù)據(jù)的線程以及處理數(shù)據(jù)的線程互相不會通信生闲，造成問題：處理數(shù)據(jù)線程掛掉了，拉取數(shù)據(jù)的線程還在繼續(xù)拉取數(shù)據(jù)月幌，數(shù)據(jù)全部都堆積在execotr里面了? ? ??
2. Direct模式碍讯，由Spark Streaming主動去kafka中拉取數(shù)據(jù)。
不再單獨(dú)啟動線程去拉取數(shù)據(jù)扯躺，獲取到的數(shù)據(jù)也不用保存在executor內(nèi)存里面了录语，獲取到的數(shù)據(jù)直接就進(jìn)行處理虽缕。
問題：使用kafka的low level API進(jìn)行消費(fèi)江耀，需要自己手動的維護(hù)offset值
sparkStreaming整合kafka官網(wǎng)提供兩個jar包：
一個是基于0.8版本整合：提供兩種方式整合，receiver和direct方式建车；一個是基于0.10版本整合：只提供了direct方式整合。
5领斥、在Kafka中broker的意義是什么？
在Kafka集群中嚼黔，broker指Kafka服務(wù)器盛撑。
術(shù)語解析：
名稱說明
Topic主題，可以理解為一個隊(duì)列
Partition分區(qū)，為了實(shí)現(xiàn)擴(kuò)展性，一個非常大的topic可以分布到多個broker（即服務(wù)器）上总滩，一個topic可以分為多個partition闰渔，每個partition是一個有序的隊(duì)列铐望。partition中的每條消息都會被分配一個有序的id（offset）茂附。kafka只保證按一個partition中的順序?qū)⑾l(fā)給consumer督弓，不保證一個topic的整體（多個partition間）的順序
Offset偏移量，kafka的存儲文件都是按照offset.kafka來命名愚隧，用offset做名字的好處是方便查找荞胡。例如你想找位于2049的位置响委，只要找到2048.kafka的文件即可窖梁。當(dāng)然the first offset就是00000000000.kafka
Broker一臺kafka服務(wù)器就是一個broker。一個集群由多個broker組成夹囚。一個broker可以容納多個topic
Producer消息生產(chǎn)者纵刘，向kafka broker發(fā)消息的客戶端
Consumer消息消費(fèi)者，向kafka broker取消息的客戶端
Consumer Group消費(fèi)者組荸哟，這是kafka用來實(shí)現(xiàn)一個topic消息的廣播（發(fā)給所有的consumer）和單播（發(fā)給任意一個consumer）的手段假哎。一個topic可以有多個CG。topic的消息會復(fù)制（不是真的復(fù)制鞍历，是概念上的）到所有的CG舵抹，但每個partion只會把消息發(fā)給該CG中的一個consumer。如果需要實(shí)現(xiàn)廣播劣砍，只要每個consumer有一個獨(dú)立的CG就可以了惧蛹。要實(shí)現(xiàn)單播只要所有的consumer在同一個CG。用CG還可以將consumer進(jìn)行自由的分組而不需要多次發(fā)送消息到不同的topic刑枝；
6香嗓、Kafka服務(wù)器能接收到的最大信息是多少？
Kafka服務(wù)器可以接收到的消息的最大大小是1000000字節(jié)装畅。
7靠娱、Kafka中的ZooKeeper是什么？Kafka是否可以脫離ZooKeeper獨(dú)立運(yùn)行掠兄？
Zookeeper是一個開放源碼的像云、高性能的協(xié)調(diào)服務(wù)锌雀，它用于Kafka的分布式應(yīng)用。
不可以迅诬，不可能越過Zookeeper直接聯(lián)系Kafka broker汤锨，一旦Zookeeper停止工作，它就不能服務(wù)客戶端請求百框。
Zookeeper主要用于在集群中不同節(jié)點(diǎn)之間進(jìn)行通信闲礼，在Kafka中，它被用于提交偏移量铐维，因此如果節(jié)點(diǎn)在任何情況下都失敗了柬泽，它都可以從之前提交的偏移量中獲取，除此之外嫁蛇，它還執(zhí)行其他活動锨并，如: leader檢測、分布式同步睬棚、配置管理第煮、識別新節(jié)點(diǎn)何時離開或連接、集群抑党、節(jié)點(diǎn)實(shí)時狀態(tài)等等包警。
8、解釋Kafka的用戶如何消費(fèi)信息底靠？
在Kafka中傳遞消息是通過使用sendfile API完成的害晦。它支持將字節(jié)Socket轉(zhuǎn)移到磁盤，通過內(nèi)核空間保存副本暑中，并在內(nèi)核用戶之間調(diào)用內(nèi)核壹瘟。
9、解釋如何提高遠(yuǎn)程用戶的吞吐量鳄逾？
如果用戶位于與broker不同的數(shù)據(jù)中心稻轨，則可能需要調(diào)優(yōu)Socket緩沖區(qū)大小，以對長網(wǎng)絡(luò)延遲進(jìn)行攤銷雕凹。
10泳炉、解釋一下樊销，在數(shù)據(jù)制作過程中唇跨，你如何能從Kafka得到準(zhǔn)確的信息殊橙？
在數(shù)據(jù)中，為了精確地獲得Kafka的消息俄精，你必須遵循兩件事: 在數(shù)據(jù)消耗期間避免重復(fù)询筏，在數(shù)據(jù)生產(chǎn)過程中避免重復(fù)。
這里有兩種方法竖慧，可以在數(shù)據(jù)生成時準(zhǔn)確地獲得一個語義:
每個分區(qū)使用一個單獨(dú)的寫入器嫌套，每當(dāng)你發(fā)現(xiàn)一個網(wǎng)絡(luò)錯誤逆屡，檢查該分區(qū)中的最后一條消息，以查看您的最后一次寫入是否成功
在消息中包含一個主鍵(UUID或其他)踱讨，并在用戶中進(jìn)行反復(fù)制
11魏蔗、解釋如何減少ISR中的擾動？broker什么時候離開ISR痹筛？（☆☆☆☆☆）
ISR是一組與leaders完全同步的消息副本莺治，也就是說ISR中包含了所有提交的消息。ISR應(yīng)該總是包含所有的副本帚稠，直到出現(xiàn)真正的故障谣旁。如果一個副本從leader中脫離出來，將會從ISR中刪除滋早。
12榄审、Kafka為什么需要復(fù)制？
Kafka的信息復(fù)制確保了任何已發(fā)布的消息不會丟失杆麸，并且可以在機(jī)器錯誤搁进、程序錯誤或更常見些的軟件升級中使用。
13昔头、如果副本在ISR中停留了很長時間表明什么饼问？
如果一個副本在ISR中保留了很長一段時間，那么它就表明减细，跟蹤器無法像在leader收集數(shù)據(jù)那樣快速地獲取數(shù)據(jù)匆瓜。
14、請說明如果首選的副本不在ISR中會發(fā)生什么未蝌？
如果首選的副本不在ISR中，控制器將無法將leadership轉(zhuǎn)移到首選的副本茧妒。
15萧吠、Kafka有可能在生產(chǎn)后發(fā)生消息偏移嗎？
在大多數(shù)隊(duì)列系統(tǒng)中桐筏，作為生產(chǎn)者的類無法做到這一點(diǎn)纸型，它的作用是觸發(fā)并忘記消息。broker將完成剩下的工作梅忌，比如使用id進(jìn)行適當(dāng)?shù)脑獢?shù)據(jù)處理狰腌、偏移量等。
作為消息的用戶牧氮，你可以從Kafka broker中獲得補(bǔ)償琼腔。如果你注視SimpleConsumer類，你會注意到它會獲取包括偏移量作為列表的MultiFetchResponse對象踱葛。此外丹莲，當(dāng)你對Kafka消息進(jìn)行迭代時光坝，你會擁有包括偏移量和消息發(fā)送的MessageAndOffset對象。
16甥材、kafka?的消息投遞保證機(jī)制以及如何實(shí)現(xiàn)盯另？（☆☆☆☆☆）
Kafka支持三種消息投遞語義：
①?At?most once?消息可能會丟，但絕不會重復(fù)傳遞
②?At least one 消息絕不會丟洲赵，但可能會重復(fù)傳遞
③?Exactly once?每條消息肯定會被傳輸一次且僅傳輸一次鸳惯，很多時候這是用戶想要的
consumer在從broker讀取消息后，可以選擇commit叠萍，該操作會在Zookeeper中存下該consumer在該partition下讀取的消息的offset悲敷，該consumer下一次再讀該partition時會從下一條開始讀取。如未commit俭令，下一次讀取的開始位置會跟上一次commit之后的開始位置相同后德。
可以將consumer設(shè)置為autocommit，即consumer一旦讀到數(shù)據(jù)立即自動commit抄腔。如果只討論這一讀取消息的過程瓢湃，那Kafka是確保了Exactly once。但實(shí)際上實(shí)際使用中consumer并非讀取完數(shù)據(jù)就結(jié)束了赫蛇，而是要進(jìn)行進(jìn)一步處理绵患，而數(shù)據(jù)處理與commit的順序在很大程度上決定了消息從broker和consumer的delivery guarantee semantic。
·讀完消息先commit再處理消息悟耘。這種模式下落蝙，如果consumer在commit后還沒來得及處理消息就crash了，下次重新開始工作后就無法讀到剛剛已提交而未處理的消息暂幼，這就對應(yīng)于At most once筏勒。
·讀完消息先處理再commit消費(fèi)狀態(tài)(保存offset)。這種模式下旺嬉，如果在處理完消息之后commit之前Consumer crash了管行，下次重新開始工作時還會處理剛剛未commit的消息，實(shí)際上該消息已經(jīng)被處理過了雨效，這就對應(yīng)于At least once。
·如果一定要做到Exactly once徽龟，就需要協(xié)調(diào)offset和實(shí)際操作的輸出叮姑。經(jīng)典的做法是引入兩階段提交，但由于許多輸出系統(tǒng)不支持兩階段提交顿肺，更為通用的方式是將offset和操作輸入存在同一個地方戏溺。比如旷祸，consumer拿到數(shù)據(jù)后可能把數(shù)據(jù)放到HDFS耕拷，如果把最新的offset和數(shù)據(jù)本身一起寫到HDFS，那就可以保證數(shù)據(jù)的輸出和offset的更新要么都完成闰围，要么都不完成赃绊，間接實(shí)現(xiàn)Exactly once。（目前就high level API而言羡榴，offset是存于Zookeeper中的碧查，無法存于HDFS，而low level API的offset是由自己去維護(hù)的校仑，可以將之存于HDFS中）忠售。
總之，Kafka默認(rèn)保證At least once迄沫，并且允許通過設(shè)置producer異步提交來實(shí)現(xiàn)At most once稻扬，而Exactly once要求與目標(biāo)存儲系統(tǒng)協(xié)作，Kafka提供的offset可以較為容易地實(shí)現(xiàn)這種方式羊瘩。
17泰佳、如何保證Kafka的消息有序（☆☆☆☆☆）
Kafka對于消息的重復(fù)、丟失尘吗、錯誤以及順序沒有嚴(yán)格的要求逝她。
Kafka只能保證一個partition中的消息被某個consumer消費(fèi)時是順序的，事實(shí)上摇予，從Topic角度來說汽绢，當(dāng)有多個partition時，消息仍然不是全局有序的侧戴。
18、kafka數(shù)據(jù)丟失問題,及如何保證
1）數(shù)據(jù)丟失:
acks=1的時候(只保證寫入leader成功)跌宛，如果剛好leader掛了酗宋。數(shù)據(jù)會丟失。
acks=0的時候疆拘，使用異步模式的時候蜕猫，該模式下kafka無法保證消息，有可能會丟哎迄。
2）brocker如何保證不丟失:
acks=all: 所有副本都寫入成功并確認(rèn)回右。
retries = 一個合理值隆圆。
min.insync.replicas=2 ?消息至少要被寫入到這么多副本才算成功。
unclean.leader.election.enable=false 關(guān)閉unclean leader選舉翔烁，即不允許非ISR中的副本被選舉為leader渺氧，以避免數(shù)據(jù)丟失。
3）Consumer如何保證不丟失
如果在消息處理完成前就提交了offset蹬屹，那么就有可能造成數(shù)據(jù)的丟失侣背。
enable.auto.commit=false 關(guān)閉自動提交offset
處理完數(shù)據(jù)之后手動提交。
19慨默、kafka的balance是怎么做的
官方原文
Producers publish data to the topics of their choice. The producer is able to choose which message to assign to which partition within the topic. This can be done in a round-robin fashion simply to balance load or it can be done according to some semantic partition function (say based on some key in the message). More on the use of partitioning in a second.
翻譯：
生產(chǎn)者將數(shù)據(jù)發(fā)布到他們選擇的主題贩耐。生產(chǎn)者可以選擇在主題中分配哪個分區(qū)的消息。這可以通過循環(huán)的方式來完成厦取，只是為了平衡負(fù)載潮太，或者可以根據(jù)一些語義分區(qū)功能（比如消息中的一些鍵）來完成。更多關(guān)于分區(qū)在一秒鐘內(nèi)的使用虾攻。
20铡买、kafka的消費(fèi)者方式
consumer采用pull（拉）模式從broker中讀取數(shù)據(jù)。
push（推）模式很難適應(yīng)消費(fèi)速率不同的消費(fèi)者台谢，因?yàn)橄l(fā)送速率是由broker決定的寻狂。它的目標(biāo)是盡可能以最快速度傳遞消息，但是這樣很容易造成consumer來不及處理消息朋沮，典型的表現(xiàn)就是拒絕服務(wù)以及網(wǎng)絡(luò)擁塞蛇券。而pull模式則可以根據(jù)consumer的消費(fèi)能力以適當(dāng)?shù)乃俾氏M(fèi)消息。
對于Kafka而言樊拓，pull模式更合適纠亚，它可簡化broker的設(shè)計(jì)，consumer可自主控制消費(fèi)消息的速率筋夏，同時consumer可以自己控制消費(fèi)方式——即可批量消費(fèi)也可逐條消費(fèi)蒂胞，同時還能選擇不同的提交方式從而實(shí)現(xiàn)不同的傳輸語義。
pull模式不足之處是条篷，如果kafka沒有數(shù)據(jù)骗随，消費(fèi)者可能會陷入循環(huán)中，一直等待數(shù)據(jù)到達(dá)赴叹。為了避免這種情況鸿染，我們在我們的拉請求中有參數(shù)，允許消費(fèi)者請求在等待數(shù)據(jù)到達(dá)的“長輪詢”中進(jìn)行阻塞乞巧。
21涨椒、為什么kafka可以實(shí)現(xiàn)高吞吐？單節(jié)點(diǎn)kafka的吞吐量也比其他消息隊(duì)列大，為什么蚕冬？
八免猾、spark
spark是針對于大規(guī)模數(shù)據(jù)處理的統(tǒng)一分析引擎，它是基于內(nèi)存計(jì)算框架囤热，計(jì)算速度非常之快猎提，但是它僅僅只是涉及到計(jì)算，并沒有涉及到數(shù)據(jù)的存儲赢乓，后期需要使用spark對接外部的數(shù)據(jù)源忧侧，比如hdfs。
1牌芋、速度快蚓炬，job的輸出結(jié)果可以保存在內(nèi)存，spark任務(wù)以線程的方式運(yùn)行在進(jìn)程中躺屁。
2肯夏、易用性，可通過java/scala/python/R/SQL等不同語言
3犀暑、通用性驯击，一個生態(tài)系統(tǒng)，包含了很多模塊耐亏。sparksql：通過sql去開發(fā)spark程序做一些離線分析徊都；sparkStreaming：主要是用來解決公司有實(shí)時計(jì)算的這種場景；Mlib：它封裝了一些機(jī)器學(xué)習(xí)的算法庫广辰；Graphx：圖計(jì)算
4暇矫、兼容性，任務(wù)要運(yùn)行就需要計(jì)算資源（內(nèi)存择吊、cpu李根、磁盤，可以把spark程序提交到哪里去運(yùn)几睛。standAlone模式房轿，自帶的獨(dú)立運(yùn)行模式，整個任務(wù)的資源分配由spark集群的老大Master負(fù)責(zé)所森；yarn模式囱持，把spark程序提交到y(tǒng)arn中運(yùn)行，整個任務(wù)的資源分配由yarn中的老大ResourceManager負(fù)責(zé)焕济；mesos洪唐，它也是apache開源的一個類似于yarn的資源調(diào)度平臺
1、spark集群的架構(gòu)
[if !supportLists]·?[endif]Cluster Manager：在standalone模式中即為Master主節(jié)點(diǎn)吼蚁，控制整個集群，監(jiān)控worker。在YARN模式中為資源管理器
[if !supportLists]·?[endif]Worker節(jié)點(diǎn)：從節(jié)點(diǎn)肝匆，負(fù)責(zé)控制計(jì)算節(jié)點(diǎn)粒蜈，啟動Executor或者Driver。
[if !supportLists]·?[endif]Driver： 運(yùn)行Application 的main()函數(shù)
[if !supportLists]·?[endif]Executor：執(zhí)行器旗国，是為某個Application運(yùn)行在worker node上的一個進(jìn)程
2枯怖、運(yùn)行原理
程序代碼-> Driver ->調(diào)用main() ->?創(chuàng)建sparkContext ->?與spark集群交互
sparkContext ->連接ClusterManager ->?申請資源 ->?解析成多個task??->分發(fā)給workNode ->?執(zhí)行task ->?執(zhí)行完畢釋放資源
①注冊并申請資源辨赐，Driver端向資源管理器（Standalone，Mesos京办，Yarn）申請運(yùn)行Executor資源掀序，?發(fā)送注冊和申請計(jì)算資源的請求；
②分配資源惭婿，Master通知對應(yīng)的worker節(jié)點(diǎn)啟動executor進(jìn)程(計(jì)算資源)不恭，?executor進(jìn)程向Driver端發(fā)送注冊并且申請task請求。
③注冊并申請task审孽，?Driver端運(yùn)行客戶端的main方法县袱，構(gòu)建SparkContext對象，在SparkContext對象內(nèi)部依次構(gòu)建DAGScheduler和TaskScheduler
④executer運(yùn)行task佑力，按照客戶端代碼rdd的一系列操作順序式散，生成DAG有向無環(huán)圖。DAGScheduler拿到DAG有向無環(huán)圖之后打颤，按照寬依賴進(jìn)行stage的劃分暴拄。每一個stage內(nèi)部有很多可以并行運(yùn)行的task，最后封裝在一個一個的taskSet集合中编饺，然后把taskSet發(fā)送給TaskScheduler乖篷。TaskScheduler得到taskSet集合之后，依次遍歷取出每一個task提交到worker節(jié)點(diǎn)上的executor進(jìn)程中運(yùn)行
⑤注銷透且，所有task運(yùn)行完成撕蔼，Driver端向Master發(fā)送注銷請求豁鲤，Master通知Worker關(guān)閉executor進(jìn)程，Worker上的計(jì)算資源得到釋放鲸沮，最后整個任務(wù)也就結(jié)束了琳骡。
3、RDD五大特性
RDD（Resilient Distributed Dataset）叫做彈性 分布式 數(shù)據(jù)集讼溺，是Spark中最基本的數(shù)據(jù)抽象楣号，它代表一個不可變、可分區(qū)怒坯、里面的元素可并行計(jì)算的集合.
Dataset:就是一個集合炫狱，存儲很多數(shù)據(jù).
Distributed：它內(nèi)部的元素進(jìn)行了分布式存儲，方便于后期進(jìn)行分布式計(jì)算.
Resilient： 表示彈性剔猿，rdd的數(shù)據(jù)是可以保存在內(nèi)存或者是磁盤中.?
①?有一個分區(qū)列表
一個rdd有很多分區(qū)视译，每一個分區(qū)內(nèi)部是包含了該rdd的部分?jǐn)?shù)據(jù)， spark中任務(wù)是以task線程的方式運(yùn)行艳馒， 一個分區(qū)就對應(yīng)一個task線程憎亚，分區(qū)數(shù)決定了并行計(jì)算的力度∨浚可以在創(chuàng)建RDD時指定RDD的分區(qū)個數(shù)第美，如果沒有指定，那么就會采用默認(rèn)值陆爽，默認(rèn)值就是程序所分配到的CPU Core的數(shù)目什往。
②?每個分區(qū)都會有計(jì)算函數(shù)
Spark的RDD的計(jì)算函數(shù)是以分片為基本單位的，每個RDD都會實(shí)現(xiàn) compute函數(shù)慌闭，對具體的分片進(jìn)行計(jì)算别威，RDD中的分片是并行的，所以是分布式并行計(jì)算驴剔。
③?一個rdd依賴其他rdd
窄依賴RDD會形成類似流水線一樣的前后依賴關(guān)系省古，寬依賴后面的RDD具體的數(shù)據(jù)分片會依賴前面所有的RDD的所有數(shù)據(jù)分片
④?key-value型的RDD，可以設(shè)置分區(qū)函數(shù)
類似于mapreduce當(dāng)中的paritioner接口丧失，控制Key分到哪個reduce豺妓。
當(dāng)前Spark中實(shí)現(xiàn)了兩種類型的分片函數(shù)，一個是基于哈希的HashPartitioner布讹，另外一個基于范圍的RangePartitioner琳拭。只有對于key-value的RDD，才會有Partitioner描验，非key-value的RDD的Partitioner的值是None白嘁。Partitioner函數(shù)不但決定了RDD本身的分片數(shù)量，也決定了parent RDD Shuffle輸出時的分片數(shù)量膘流。
⑤每個分區(qū)都有一個優(yōu)先位置列表
移動數(shù)據(jù)不如移動計(jì)算絮缅，數(shù)據(jù)在哪臺機(jī)器上鲁沥，任務(wù)就啟在哪個機(jī)器上，數(shù)據(jù)在本地上盟蚣，不用走網(wǎng)絡(luò)黍析。不過數(shù)據(jù)進(jìn)行最后匯總的時候就要走網(wǎng)絡(luò)。（進(jìn)行任務(wù)調(diào)度時會盡可能地將任務(wù)分配到處理數(shù)據(jù)的數(shù)據(jù)塊所在的具體位置。
4茫打、saprk調(diào)優(yōu)
5驻谆、Shuffle
Shuffle就是對數(shù)據(jù)進(jìn)行重組，在DAG調(diào)度的過程中喊废，Stage階段的劃分是根據(jù)是否有shuffle過程，也就是是否存在寬依賴的時候。spark劃分 stage 的整體思路是：從后往前推逞度，遇到寬依賴就斷開，劃分為一個stage妙啃；遇到窄依賴就將這個 RDD 加入該 stage 中档泽。
需要進(jìn)行shuffle，這時候會將作業(yè)job劃分成多個Stage揖赴，每一個stage內(nèi)部有很多可以并行運(yùn)行的task馆匿，stage與stage之間的過程就是shuffle階段，
在Spark的中燥滑，負(fù)責(zé)shuffle過程的執(zhí)行渐北、計(jì)算和處理的組件主要就是ShuffleManager，也即shuffle管理器铭拧。ShuffleManager隨著Spark的發(fā)展有兩種實(shí)現(xiàn)的方式赃蛛，分別為HashShuffleManager（spark1.2之前使用）和SortShuffleManager（spark1.2之后使用），
? spark1.2版本以前：hashShuffleManager搀菩、未經(jīng)優(yōu)化的hashShuffleManager呕臂、經(jīng)過優(yōu)化的hashShuffleManager；
spark1.2版本以后：SortShuffleManager肪跋、普通機(jī)制ByPass機(jī)制
HashShuffleManager的運(yùn)行機(jī)制主要分成兩種歧蒋。 一種是普通運(yùn)行機(jī)制，另一種是合并的運(yùn)行機(jī)制澎嚣。合并機(jī)制主要是通過復(fù)用buffer來優(yōu)化Shuffle過程中產(chǎn)生的小文件的數(shù)量疏尿，Hash shuffle是不具有排序的Shuffle
SortShuffleManager的運(yùn)行機(jī)制主要分成兩種，一種是普通運(yùn)行機(jī)制易桃；另一種是bypass運(yùn)行機(jī)制褥琐。
6、spark程序?qū)崿F(xiàn)單詞統(tǒng)計(jì)
object WordCount {
??defmain(args: Array[String]): Unit = {
????//1晤郑、構(gòu)建sparkConf對象 設(shè)置application名稱和master地址
????val sparkConf: SparkConf =new?SparkConf().setAppName("WordCount").setMaster("local[2]")
????//2敌呈、構(gòu)建sparkContext對象,該對象非常重要贸宏，它是所有spark程序的執(zhí)行入口
????//它內(nèi)部會構(gòu)建?DAGScheduler和 TaskScheduler 對象
????val?sc?=?new?SparkContext(sparkConf)
????//設(shè)置日志輸出級別
????sc.setLogLevel("warn")
????//3、讀取數(shù)據(jù)文件
????val data: RDD[String] = sc.textFile("E:\\words.txt")
????//4磕洪、 切分每一行吭练，獲取所有單詞
????val words: RDD[String] = data.flatMap(x=>x.split(" "))
????//5、每個單詞計(jì)為1
????val wordAndOne: RDD[(String, Int)] = words.map(x => (x,1))
????//6析显、相同單詞出現(xiàn)的1累加
????val result: RDD[(String, Int)] = wordAndOne.reduceByKey((x,y)=>x+y)
????//按照單詞出現(xiàn)的次數(shù)降序排列鲫咽，第二個參數(shù)默認(rèn)true表示升序
????val sortedRDD: RDD[(String, Int)] = result.sortBy( x=> x._2,false)
????//7、收集數(shù)據(jù)打印
????val finalResult: Array[(String, Int)] = sortedRDD.collect()
????finalResult.foreach(println)
????//8谷异、關(guān)閉sc
????sc.stop()
??}}
九Flume（☆☆☆☆）
1分尸、Flume使用場景（☆☆☆☆☆）
線上數(shù)據(jù)一般主要是落地（存儲到磁盤）或者通過socket傳輸給另外一個系統(tǒng)，這種情況下歹嘹，你很難推動線上應(yīng)用或服務(wù)去修改接口箩绍，實(shí)現(xiàn)直接向kafka里寫數(shù)據(jù)，這時候你可能就需要flume這樣的系統(tǒng)幫你去做傳輸尺上。
2材蛛、Flume丟包問題（☆☆☆☆☆）
單機(jī)upd的flume source的配置，100+M/s數(shù)據(jù)量怎抛，10w qps flume就開始大量丟包卑吭，因此很多公司在搭建系統(tǒng)時，拋棄了Flume抽诉，自己研發(fā)傳輸系統(tǒng)陨簇，但是往往會參考Flume的Source-Channel-Sink模式。
一些公司在Flume工作過程中迹淌，會對業(yè)務(wù)日志進(jìn)行監(jiān)控河绽，例如Flume?agent中有多少條日志，F(xiàn)lume到Kafka后有多少條日志等等唉窃，如果數(shù)據(jù)丟失保持在1%左右是沒有問題的耙饰，當(dāng)數(shù)據(jù)丟失達(dá)到5%左右時就必須采取相應(yīng)措施。
3纹份、Flume與Kafka的選取
采集層主要可以使用Flume苟跪、Kafka兩種技術(shù)。
·Flume：Flume 是管道流方式蔓涧，提供了很多的默認(rèn)實(shí)現(xiàn)，讓用戶通過參數(shù)部署元暴，及擴(kuò)展API铜秆。Kafka：Kafka是一個可持久化的分布式的消息隊(duì)列淹真。
Kafka 是一個非常通用的系統(tǒng)连茧。你可以有許多生產(chǎn)者和很多的消費(fèi)者共享多個主題Topics值纱。相比之下搀愧，F(xiàn)lume是一個專用工具被設(shè)計(jì)為旨在往HDFS搓幌，HBase發(fā)送數(shù)據(jù)。它對HDFS有特殊的優(yōu)化，并且集成了Hadoop的安全特性堂污。所以盟猖，Cloudera 建議如果數(shù)據(jù)被多個系統(tǒng)消費(fèi)的話式镐，使用kafka；如果數(shù)據(jù)被設(shè)計(jì)給Hadoop使用价说，使用Flume。
?Flume內(nèi)置很多的source和sink組件彻磁。然而尘喝，Kafka明顯有一個更小的生產(chǎn)消費(fèi)者生態(tài)系統(tǒng)置吓，并且Kafka的社區(qū)支持不好衍锚。希望將來這種情況會得到改善，但是目前：使用Kafka意味著你準(zhǔn)備好了編寫你自己的生產(chǎn)者和消費(fèi)者代碼戴质。如果已經(jīng)存在的Flume Sources和Sinks滿足你的需求踢匣，并且你更喜歡不需要任何開發(fā)的系統(tǒng)，請使用Flume符糊。
Flume可以使用攔截器實(shí)時處理數(shù)據(jù)凫海。這些對數(shù)據(jù)屏蔽或者過量是很有用的男娄。Kafka需要外部的流處理系統(tǒng)才能做到建瘫。
Kafka和Flume都是可靠的系統(tǒng),通過適當(dāng)?shù)呐渲媚鼙ＷC零數(shù)據(jù)丟失。然而粒梦，F(xiàn)lume不支持副本事件荸实。于是匀们，如果Flume代理的一個節(jié)點(diǎn)奔潰了，即使使用了可靠的文件管道方式准给，你也將丟失這些事件直到你恢復(fù)這些磁盤泄朴。如果你需要一個高可靠行的管道，那么使用Kafka是個更好的選擇露氮。
Flume和Kafka可以很好地結(jié)合起來使用祖灰。如果你的設(shè)計(jì)需要從Kafka到Hadoop的流數(shù)據(jù)，使用Flume代理并配置Kafka的Source讀取數(shù)據(jù)也是可行的：你沒有必要實(shí)現(xiàn)自己的消費(fèi)者畔规。你可以直接利用Flume與HDFS及HBase的結(jié)合的所有好處局扶。你可以使用Cloudera Manager對消費(fèi)者的監(jiān)控，并且你甚至可以添加攔截器進(jìn)行一些流處理叁扫。
4详民、數(shù)據(jù)怎么采集到Kafka，實(shí)現(xiàn)方式
使用官方提供的flumeKafka插件陌兑，插件的實(shí)現(xiàn)方式是自定義了flume的sink，將數(shù)據(jù)從channle中取出由捎，通過kafka的producer寫入到kafka中兔综，可以自定義分區(qū)等。
5狞玛、flume管道內(nèi)存软驰，flume宕機(jī)了數(shù)據(jù)丟失怎么解決
1）Flume的channel分為很多種，可以將數(shù)據(jù)寫入到文件心肪。
2）防止非首個agent宕機(jī)的方法數(shù)可以做集群或者主備
6锭亏、flume配置方式，flume集群（問的很詳細(xì)）
Flume的配置圍繞著source硬鞍、channel慧瘤、sink敘述，flume的集群是做在agent上的固该，而非機(jī)器上锅减。
7、flume不采集Nginx日志伐坏，通過Logger4j采集日志怔匣，優(yōu)缺點(diǎn)是什么？
優(yōu)點(diǎn)：Nginx的日志格式是固定的桦沉，但是缺少sessionid每瞒，通過logger4j采集的日志是帶有sessionid的金闽，而session可以通過redis共享，保證了集群日志中的同一session落到不同的tomcat時剿骨，sessionId還是一樣的代芜，而且logger4j的方式比較穩(wěn)定，不會宕機(jī)懦砂。
缺點(diǎn)：不夠靈活蜒犯，logger4j的方式和項(xiàng)目結(jié)合過于緊密，而flume的方式比較靈活荞膘，拔插式比較好罚随，不會影響項(xiàng)目性能。
8羽资、flume和kafka采集日志區(qū)別淘菩，采集日志時中間停了，怎么記錄之前的日志屠升。
Flume采集日志是通過流的方式直接將日志收集到存儲層潮改，而kafka試講日志緩存在kafka集群，待后期可以采集到存儲層腹暖。
Flume采集中間停了汇在，可以采用文件的方式記錄之前的日志，而kafka是采用offset的方式記錄之前的日志脏答。
9糕殉、flume有哪些組件，flume的source殖告、channel阿蝶、sink具體是做什么的
1）source：用于采集數(shù)據(jù)，Source是產(chǎn)生數(shù)據(jù)流的地方黄绩，同時Source會將產(chǎn)生的數(shù)據(jù)流傳輸?shù)紺hannel羡洁，這個有點(diǎn)類似于Java IO部分的Channel。
2）channel：用于橋接Sources和Sinks爽丹，類似于一個隊(duì)列筑煮。
3）sink：從Channel收集數(shù)據(jù)，將數(shù)據(jù)寫到目標(biāo)源(可以是下一個Source习劫，也可以是HDFS或者HBase)咆瘟。
10、你是如何實(shí)現(xiàn)flume數(shù)據(jù)傳輸?shù)谋O(jiān)控的
11诽里、你們的Flume怎么做數(shù)據(jù)監(jiān)聽袒餐？有沒有做ETL?
