13面試問(wèn)題（2）

是否存在i+1<i的數(shù)

存在，int最大值

redis的五種數(shù)據(jù)類型是指

value的類型，key只能是string類型

企業(yè)站內(nèi)搜索技術(shù)選型

單獨(dú)使用Lucene實(shí)現(xiàn)站內(nèi)搜索需要開(kāi)發(fā)的工作量較大，因此不建議采用。

solr是基于Lucene的全文搜索服務(wù)器,能滿足搜索技術(shù)

esearch是更加新的技術(shù)

4、解釋內(nèi)存溢出和內(nèi)存泄漏，不用的對(duì)象需要置為null嗎？

內(nèi)存溢出 out of memory，是指程序在申請(qǐng)內(nèi)存時(shí)，沒(méi)有足夠的內(nèi)存空間供其使用

內(nèi)存泄露 memory leak，是指程序在申請(qǐng)內(nèi)存后，無(wú)法釋放已申請(qǐng)的內(nèi)存空間

內(nèi)存泄露會(huì)導(dǎo)致內(nèi)存溢出

需要，能釋放內(nèi)存空間

定時(shí)任務(wù)

直接修改/etc/crontab文件

每星期日的6:30執(zhí)行l(wèi)s命令：

30 6 * * 0 ls

每15分鐘執(zhí)行一次ls命令：

*/15 * * * * ls

幾種垃圾回收機(jī)制

標(biāo)記－清除收集器

標(biāo)記－壓縮收集器

復(fù)制收集器

Fs命令與dfs命令有什么不同的地方

fs可以操作任何文件系統(tǒng)

dfs：只能操作HDFS文件系統(tǒng)

10大數(shù)據(jù)習(xí)題集

1.kafka集群的規(guī)模，消費(fèi)速度是多少。

答：一般中小型公司是10個(gè)節(jié)點(diǎn)，每秒20M左右。

hadoop的shuffle過(guò)程

一、Map端的shuffle

　　Map端會(huì)處理輸入數(shù)據(jù)并產(chǎn)生中間結(jié)果，這個(gè)中間結(jié)果會(huì)寫(xiě)到本地磁盤(pán)，而不是HDFS。每個(gè)Map的輸出會(huì)先寫(xiě)到內(nèi)存緩沖區(qū)中，當(dāng)寫(xiě)入的數(shù)據(jù)達(dá)到設(shè)定的閾值時(shí)，系統(tǒng)將會(huì)啟動(dòng)一個(gè)線程將緩沖區(qū)的數(shù)據(jù)寫(xiě)到磁盤(pán)，這個(gè)過(guò)程叫做spill。

　　在spill寫(xiě)入之前，會(huì)先進(jìn)行二次排序，首先根據(jù)數(shù)據(jù)所屬的partition進(jìn)行排序，然后每個(gè)partition中的數(shù)據(jù)再按key來(lái)排序。partition的目是將記錄劃分到不同的Reducer上去，以期望能夠達(dá)到負(fù)載均衡，以后的Reducer就會(huì)根據(jù)partition來(lái)讀取自己對(duì)應(yīng)的數(shù)據(jù)。接著運(yùn)行combiner(如果設(shè)置了的話)，combiner的本質(zhì)也是一個(gè)Reducer，其目的是對(duì)將要寫(xiě)入到磁盤(pán)上的文件先進(jìn)行一次處理，這樣，寫(xiě)入到磁盤(pán)的數(shù)據(jù)量就會(huì)減少。最后將數(shù)據(jù)寫(xiě)到本地磁盤(pán)產(chǎn)生spill文件(spill文件保存在{mapred.local.dir}指定的目錄中，Map任務(wù)結(jié)束后就會(huì)被刪除)。

　　最后，每個(gè)Map任務(wù)可能產(chǎn)生多個(gè)spill文件，在每個(gè)Map任務(wù)完成前，會(huì)通過(guò)多路歸并算法將這些spill文件歸并成一個(gè)文件。至此，Map的shuffle過(guò)程就結(jié)束了。

二、Reduce端的shuffle

　　Reduce端的shuffle主要包括三個(gè)階段，copy、sort(merge)和reduce。

　　首先要將Map端產(chǎn)生的輸出文件拷貝到Reduce端，但每個(gè)Reducer如何知道自己應(yīng)該處理哪些數(shù)據(jù)呢？因?yàn)镸ap端進(jìn)行partition的時(shí)候，實(shí)際上就相當(dāng)于指定了每個(gè)Reducer要處理的數(shù)據(jù)(partition就對(duì)應(yīng)了Reducer)，所以Reducer在拷貝數(shù)據(jù)的時(shí)候只需拷貝與自己對(duì)應(yīng)的partition中的數(shù)據(jù)即可。每個(gè)Reducer會(huì)處理一個(gè)或者多個(gè)partition，但需要先將自己對(duì)應(yīng)的partition中的數(shù)據(jù)從每個(gè)Map的輸出結(jié)果中拷貝過(guò)來(lái)。

　　接下來(lái)就是sort階段，也成為merge階段，因?yàn)檫@個(gè)階段的主要工作是執(zhí)行了歸并排序。從Map端拷貝到Reduce端的數(shù)據(jù)都是有序的，所以很適合歸并排序。最終在Reduce端生成一個(gè)較大的文件作為Reduce的輸入。

　　最后就是Reduce過(guò)程了，在這個(gè)過(guò)程中產(chǎn)生了最終的輸出結(jié)果，并將其寫(xiě)到HDFS上。

5.spark streming在實(shí)時(shí)處理時(shí)會(huì)發(fā)生什么故障，如何停止

StreamingContext.stop會(huì)把關(guān)聯(lián)的SparkContext對(duì)象也停止，如果不想把SparkContext對(duì)象也停止的話可以把StremingContext.stop的可選參數(shù)stopSparkContext設(shè)為flase。

7.說(shuō)一下你對(duì)hadoop生態(tài)圈的認(rèn)識(shí)。

說(shuō)一下大數(shù)據(jù)PPT

8.yarn的理解：

ResourceManager：負(fù)責(zé)整個(gè)集群的資源管理和調(diào)度 ApplicationMaster：負(fù)責(zé)應(yīng)用程序相關(guān)事務(wù)，比如任務(wù)調(diào)度、任務(wù)監(jiān)控和容錯(cuò)等。 目前可以支持多種計(jì)算框架運(yùn)行在YARN上面，比如MapReduce、storm、Spark、Flink。

6、兩個(gè)文件合并的問(wèn)題：給定a、b兩個(gè)文件，各存放50億個(gè)url，每個(gè)url各占用64字節(jié)，內(nèi)存限制是4G，如何找出a、b文件共同的url？

? 1）主要的思想是把文件分開(kāi)進(jìn)行計(jì)算，在對(duì)每個(gè)文件進(jìn)行對(duì)比，得出相同的URL,因?yàn)橐陨险f(shuō)是含有相同的URL所以不用考慮數(shù)據(jù)傾斜的問(wèn)題。詳細(xì)的解題思路如下：

? ? a、可以估計(jì)每個(gè)文件的大小為5G*64=300G，遠(yuǎn)大于4G。所以不可能將其完全加載到內(nèi)存中處理?？紤]采取分而治之的方法。

? ? b、遍歷文件a，對(duì)每個(gè)url求取hash(url)%1000，然后根據(jù)所得值將url分別存儲(chǔ)到1000個(gè)小文件（設(shè)為a0,a1,...a999）當(dāng)中。這樣每個(gè)小文件的大小約為300M。

? ? b、遍歷文件b，采取和a相同的方法將url分別存儲(chǔ)到1000個(gè)小文件(b0,b1....b999)中。這樣處理后，所有可能相同的url都在對(duì)應(yīng)的小文件(a0 vs b0, a1 vs b1....a999 vs b999)當(dāng)中，不對(duì)應(yīng)的小文件（比如a0 vs b99）不可能有相同的url。然后我們只要求出1000對(duì)小文件中相同的url即可。

? ? c、比如對(duì)于a0 vs b0，我們可以遍歷a0，將其中的url存儲(chǔ)到hash_map當(dāng)中。然后遍歷b0，如果url在hash_map中，則說(shuō)明此url在a和b中同時(shí)存在，保存到文件中即可。

? ? d、如果分成的小文件不均勻，導(dǎo)致有些小文件太大（比如大于2G），可以考慮將這些太大的小文件再按類似的方法分成小小文件即可

7、按照需求使用spark編寫(xiě)一下程序？

? A、當(dāng)前文件a.text的格式如下，請(qǐng)統(tǒng)計(jì)每個(gè)單詞出現(xiàn)的個(gè)數(shù)和第四列每個(gè)元素出現(xiàn)的個(gè)數(shù)

A,b,c,d

B,b,f,e

A,a,c,f

sc.textFile(“a.text”).flatMap(_.split(“,”)).map((_,1)).ReduceByKey(_+_).foreach(println)

sc.textFile(“a.text”).map(line=>{(line.split(",")(3),1)}).reduceByKey(_+_).foreach(println)

? B、HDFS中有兩個(gè)文件a.text與b.text,文件的格式為(ip,username),如：a.text,b.text

a.text

127.0.0.1? xiaozhang

127.0.0.1? xiaoli

127.0.0.2? wangwu

127.0.0.3? lisi

B.text

127.0.0.4? lixiaolu

127.0.0.5? lisi

每個(gè)文件至少有1000萬(wàn)行，請(qǐng)用程序完成以下工作，

1)出現(xiàn)在b.text而沒(méi)有出現(xiàn)在a.text的IP

rdd22.filter(x=>{!x.contains(rdd11)}).foreach(println)

8.kafka 重啟是否會(huì)導(dǎo)致數(shù)據(jù)丟失

不會(huì) 因?yàn)閗afka會(huì)做持久化，并且offset會(huì)保存在zk中，重啟后每次讀取都會(huì)從kafka最新的offset讀取（可以從zk里面指定kafka的offset實(shí)現(xiàn)從指定位置讀?。?/p>

9.講講checkpoint

checkpoint的作用就是將DAG中比較重要的中間數(shù)據(jù)做一個(gè)檢查點(diǎn)將結(jié)果存儲(chǔ)到一個(gè)高可用的地方(通常這個(gè)地方就是HDFS里面)，防止很長(zhǎng)的計(jì)算過(guò)程出錯(cuò)時(shí)還要從頭計(jì)算，并且為整合歷史數(shù)據(jù)提供了可能

10.spark streaming 的優(yōu)缺點(diǎn)

和storm與flink對(duì)比來(lái)說(shuō)

11.kafka的message包括哪些信息

一個(gè)Kafka的Message由一個(gè)固定長(zhǎng)度的header和一個(gè)變長(zhǎng)的消息體body組成

12.怎么查看kafka的offset

consumer.position()

13.?rdd 怎么分區(qū)寬依賴和窄依賴

寬依賴：父RDD的分區(qū)被子RDD的多個(gè)分區(qū)使用? ?例如 groupByKey、reduceByKey、sortByKey等操作會(huì)產(chǎn)生寬依賴，會(huì)產(chǎn)生shuffle

窄依賴：父RDD的每個(gè)分區(qū)都只被子RDD的一個(gè)分區(qū)使用? 例如map、filter、union等操作會(huì)產(chǎn)生窄依賴

14.怎么解決kafka的數(shù)據(jù)丟失

producer端：

宏觀上看保證數(shù)據(jù)的可靠安全性，肯定是依據(jù)分區(qū)數(shù)做好數(shù)據(jù)備份，設(shè)立副本數(shù)。

broker端：

topic設(shè)置多分區(qū)，分區(qū)自適應(yīng)所在機(jī)器，為了讓各分區(qū)均勻分布在所在的broker中，分區(qū)數(shù)要大于broker數(shù)。

分區(qū)是kafka進(jìn)行并行讀寫(xiě)的單位，是提升kafka速度的關(guān)鍵。

Consumer端

consumer端丟失消息的情形比較簡(jiǎn)單：如果在消息處理完成前就提交了offset，那么就有可能造成數(shù)據(jù)的丟失。由于Kafka consumer默認(rèn)是自動(dòng)提交位移的，所以在后臺(tái)提交位移前一定要保證消息被正常處理了，因此不建議采用很重的處理邏輯，如果處理耗時(shí)很長(zhǎng)，則建議把邏輯放到另一個(gè)線程中去做。為了避免數(shù)據(jù)丟失，現(xiàn)給出兩點(diǎn)建議：

enable.auto.commit=false? 關(guān)閉自動(dòng)提交位移

在消息被完整處理之后再手動(dòng)提交位移

3.0請(qǐng)寫(xiě)出以下的shell命令

（1）殺死一個(gè)job

（2）刪除hdfs上的 /tmp/aaa目錄

答：（1）hadoop job –list 得到j(luò)ob的id，然后執(zhí) 行 hadoop job -kill jobId就可以殺死一個(gè)指定jobId的job工作了。

（2）hadoopfs -rmr /tmp/aaa

12.0 請(qǐng)簡(jiǎn)述mapreduce中的combine和partition的作用

答：combiner是發(fā)生在map的最后一個(gè)階段，其原理也是一個(gè)小型的reducer，主要作用是減少輸出到reduce的數(shù)據(jù)量，緩解網(wǎng)絡(luò)傳輸瓶頸，提高reducer的執(zhí)行效率。

partition的主要作用將map階段產(chǎn)生的所有kv對(duì)分配給不同的reducer task處理，可以將reduce階段的處理負(fù)載進(jìn)行分?jǐn)?/p>

31.數(shù)據(jù)的三范式

答：

第一范式（）無(wú)重復(fù)的列

第二范式（2NF）屬性完全依賴于主鍵 [消除部分子函數(shù)依賴]

第三范式（3NF）屬性不依賴于其它非主屬性 [消除傳遞依賴]

35.MapReduce優(yōu)化經(jīng)驗(yàn)（即hive調(diào)優(yōu)、即hadoop調(diào)優(yōu)）

答：(1.)設(shè)置合理的map和reduce的個(gè)數(shù)。合理設(shè)置blocksize

(2.)避免出現(xiàn)數(shù)據(jù)傾斜

(4.對(duì)數(shù)據(jù)進(jìn)行壓縮

(5.小文件處理優(yōu)化：事先合并成大文件，用MR中的combineTextInputformat

103. hive 中的壓縮格式 RCFile、TextFile、SequenceFile各有什么區(qū)別？

其余兩個(gè)都進(jìn)行了壓縮，但是不可以直接打開(kāi)，在創(chuàng)建hive表時(shí)需要指定文件格式才能使用

14、有可能使hadoop任務(wù)輸出到多個(gè)目錄中嗎？如果可以，怎么做？

自定義outputformat或者用multioutputs工具

四、 你們數(shù)據(jù)庫(kù)怎么導(dǎo)入hive 的,有沒(méi)有出現(xiàn)問(wèn)題

像blob或clob之類的數(shù)據(jù)，采取不抽取

增量全量導(dǎo)入配置的參數(shù)不同

空值問(wèn)題、分隔符問(wèn)題

infa導(dǎo)入時(shí)數(shù)據(jù)長(zhǎng)度問(wèn)題

sqoop導(dǎo)入時(shí)還要注意字段類型轉(zhuǎn)換問(wèn)題

五、hdfs-site.xml的3個(gè)主要屬性?

dfs.name.dir決定的是元數(shù)據(jù)存儲(chǔ)的路徑以及DFS的存儲(chǔ)方式(磁盤(pán)或是遠(yuǎn)端)

dfs.data.dir決定的是數(shù)據(jù)存儲(chǔ)的路徑

fs.checkpoint.dir用于第二Namenode

八、hadoop和spark都是并行計(jì)算，那么他們有什么相同和區(qū)別？

兩者都使用mr模型來(lái)進(jìn)行并行計(jì)算，hadoop的一個(gè)作業(yè)稱為job，job里面分為map task和reduce task，每個(gè)task都是在自己的進(jìn)程中運(yùn)行的，當(dāng)task結(jié)束時(shí)，進(jìn)程也會(huì)結(jié)束。

Spark用戶提交的任務(wù)稱為application，一個(gè)application對(duì)應(yīng)一個(gè)SparkContext，app中存在多個(gè)job，沒(méi)觸發(fā)一個(gè)action操作就會(huì)產(chǎn)生一個(gè)job。

這些job可以并行或者串行執(zhí)行，每個(gè)job有多個(gè)stage，stage是shuffle過(guò)程中DAGSchaduler通過(guò)RDD之間的依賴關(guān)系劃分job而來(lái)的，每個(gè)stage里面有多個(gè)task，組成taskset有TaskSchaduler分發(fā)到各個(gè)executor中執(zhí)行，executor的生命周期是和application一樣的，即使沒(méi)有job運(yùn)行也是存在的，所以task可以快速啟動(dòng)讀取內(nèi)存進(jìn)行計(jì)算的。

Hadoop的job只有map和reduce操作，表達(dá)能力比較欠缺而且在mr過(guò)程中會(huì)重復(fù)的讀寫(xiě)hdfs，造成大量的io操作，多個(gè)job需要自己管理關(guān)系。

Spark的迭代計(jì)算都是在內(nèi)存中進(jìn)行的，API中提供了大量的RDD操作join，groupby等，而且通過(guò)DAG圖可以實(shí)現(xiàn)良好的容錯(cuò)。

十一、簡(jiǎn)單說(shuō)一下hadoop和spark的shuffle過(guò)程

Hadoop：map端保存分片數(shù)據(jù)，通過(guò)網(wǎng)絡(luò)收集到reduce端。

Spark：spark的shuffle實(shí)在DAGSchedular劃分Stage的時(shí)候產(chǎn)生的，TaskSchedular要分發(fā)Stage到各個(gè)worker的executor。減少shuffle可以提高性能。

十六、請(qǐng)列出正常的hadoop集群中hadoop都分別需要啟動(dòng) 哪些進(jìn)程，他們的作用分別都是什么，請(qǐng)盡量列的詳細(xì)一些。

namenode：負(fù)責(zé)管理hdfs中文件塊的元數(shù)據(jù)，響應(yīng)客戶端請(qǐng)求，管理datanode上文件block的均衡，維持副本數(shù)量

Secondname:主要負(fù)責(zé)做checkpoint操作；也可以做冷備，對(duì)一定范圍內(nèi)數(shù)據(jù)做快照性備份。

Datanode:存儲(chǔ)數(shù)據(jù)塊，負(fù)責(zé)客戶端對(duì)數(shù)據(jù)塊的io請(qǐng)求

Jobtracker :管理任務(wù)，并將任務(wù)分配給 tasktracker。

Tasktracker: 執(zhí)行JobTracker分配的任務(wù)。

Resourcemanager、Nodemanager、Journalnode、Zookeeper、Zkfc

1.Kudu優(yōu)勢(shì)在于：

提供快速的全量數(shù)據(jù)分析與實(shí)時(shí)處理功能

結(jié)構(gòu)化的數(shù)據(jù)模型，支持標(biāo)準(zhǔn)SQL語(yǔ)法，支持?jǐn)?shù)據(jù)的更新操作。

集成Impala，利用Imapla SQL語(yǔ)法可操作Kudu數(shù)據(jù)。

與mapreduce、spark以及其它hadoop生態(tài)系統(tǒng)集成。

利用Cloudera Manager，方便管理和維護(hù)。

高可用。Tablet Servers and Masters利用Raft Consensus Algorithm.確保只要有一半的副本可用，則tablet可用（可讀寫(xiě)）。

對(duì)數(shù)據(jù)順序掃描(scan)和隨機(jī)訪問(wèn)(random access)同時(shí)具有高性能，簡(jiǎn)化用戶復(fù)雜的混合架構(gòu)。

2.kudu的基本結(jié)構(gòu)

Table

Table就是你在Kudu里存儲(chǔ)數(shù)據(jù)的地方，可以理解為一個(gè)表

Tablet

Tablet是存儲(chǔ)的最小單位，類似HDFS的block，HBase的region。

Tablet Server

類似HDFS的DataNode, tablet server上存了多個(gè)Tablet，每個(gè)Tablet有多個(gè)副本存放在不同的Table Server上，每個(gè)Tablet副本同時(shí)只有一個(gè)Leader，Leader對(duì)用戶提供寫(xiě)操作，然后同步給其它follower，其它follower只提供讀服務(wù)，不提供寫(xiě)服務(wù)。當(dāng)Leader節(jié)點(diǎn)發(fā)生故障后，通過(guò)算法 Raft Consensus Algorithm來(lái)重新選舉Leader節(jié)點(diǎn)。

Master Server

類似HDFS的NameNode, Master負(fù)責(zé)管理元數(shù)據(jù)。這些元數(shù)據(jù)包括talbet的基本信息，位置信息。Master還作為負(fù)載均衡服務(wù)器，監(jiān)聽(tīng)Tablet Server的健康狀態(tài)

Catalog Table

Catalog table存儲(chǔ)著元數(shù)據(jù)信息：

3.Spark Streaming的三種運(yùn)用場(chǎng)景

1、無(wú)狀態(tài)操作

???????? 只關(guān)注當(dāng)前新生成的小批次數(shù)據(jù)，所有計(jì)算都只是基于這個(gè)批次的數(shù)據(jù)進(jìn)行處理。

2、狀態(tài)操作

???????? 除了當(dāng)前新生成的小批次數(shù)據(jù)，但還需要用到以前所生成的所有的歷史數(shù)據(jù)

3、window操作

???????? 關(guān)注窗口內(nèi)的批次數(shù)據(jù)

7.? ? ? “jps”命令的用處？

解答：

這個(gè)命令可以檢查Namenode、Datanode、Task Tracker、 Job Tracker是否正常工作。

12.??請(qǐng)列出你所知道的 hadoop 調(diào)度器，并簡(jiǎn)要說(shuō)明其工作方法？

解答：

1.FIFO schedular:默認(rèn)，先進(jìn)先出的原則

2.Capacity schedular:計(jì)算能力調(diào)度器，選擇占用最小，優(yōu)先級(jí)高的先執(zhí)行，以此類推。

3.Fair schedular:公平調(diào)度，所有的job具有相同的資源。

22.??hadoop 的 namenode 宕機(jī),怎么解決

解答：

先分析宕機(jī)后的損失，宕機(jī)后直接導(dǎo)致client無(wú)法訪問(wèn)，內(nèi)存中的元數(shù)據(jù)丟失，但是硬盤(pán)中的元數(shù)據(jù)應(yīng)該還存在，如果只是節(jié)點(diǎn)掛了，重啟即可，如果是機(jī)器掛了，重啟機(jī)器后看節(jié)點(diǎn)是否能重啟，不能重啟就要找到原因修復(fù)了。但是最終的解決方案應(yīng)該是在設(shè)計(jì)集群的初期就考慮到這個(gè)問(wèn)題，做namenode的HA。

27.? 在hadoop中文件的壓縮帶來(lái)了兩大好處：

解答：

（1）它減少了存儲(chǔ)文件所需的空間；

（2）加快了數(shù)據(jù)在網(wǎng)絡(luò)上或者從磁盤(pán)上或到磁盤(pán)上的傳輸速度；

28.java類型如何轉(zhuǎn)化為hadoop基本類型？

調(diào)用hadoop類型的構(gòu)造方法，或者調(diào)用set()方法。

new LongWritable(123L);

29.hadoop基本類型如何轉(zhuǎn)化為java類型？

對(duì)于Text，需要調(diào)用toString()方法，其他類型調(diào)用get()方法。

3.? ? ? 生產(chǎn)環(huán)境中為什么建議使用外部表？

解答：

1、因?yàn)橥獠勘聿粫?huì)加載數(shù)據(jù)到hive，減少數(shù)據(jù)傳輸、數(shù)據(jù)還能共享。

2、hive不會(huì)修改數(shù)據(jù)，所以無(wú)需擔(dān)心數(shù)據(jù)的損壞

3、刪除表時(shí)，只刪除表結(jié)構(gòu)、不刪除數(shù)據(jù)。

8.??????假如一個(gè)分區(qū)的數(shù)據(jù)錯(cuò)誤怎么通過(guò)hivesql刪除

解答：

alter table ptable drop partition (daytime='20140911',city='bj');

元數(shù)據(jù)，數(shù)據(jù)文件都刪除，但目錄daytime= 20140911還在

9.? ? ? Hive里面用什么代替in查詢

解答：

提示：Hive中的left semi join替換sql中的in操作

7.??????HBase的檢索支持3種方式：

解答：

（1） 通過(guò)單個(gè)Rowkey訪問(wèn)，即按照某個(gè)Rowkey鍵值進(jìn)行g(shù)et操作，這樣獲取唯一一條記錄；

（2） 通過(guò)Rowkey的range進(jìn)行scan，即通過(guò)設(shè)置startRowKey和endRowKey，在這個(gè)范圍內(nèi)進(jìn)行掃描。這樣可以按指定的條件獲取一批記錄；

（3） 全表掃描，即直接掃描整張表中所有行記錄。

08hadoop生態(tài)圈復(fù)習(xí)筆記

Zookeeper概述

Zookeeper介紹

Zookeeper是分布式應(yīng)用程序的協(xié)調(diào)服務(wù)框架，是Hadoop的重要組件。ZK要解決的問(wèn)題：

1.分布式環(huán)境下的數(shù)據(jù)一致性。

2.分布式環(huán)境下的統(tǒng)一命名服務(wù)

3.分布式環(huán)境下的配置管理

4.分布式環(huán)境下的分布式鎖

5.集群管理問(wèn)題

分布式編程容易出現(xiàn)的問(wèn)題

1.活鎖：

多個(gè)線程爭(zhēng)用一個(gè)資源，但是沒(méi)有任何一個(gè) 線程能拿到這個(gè)資源。如此循環(huán)往復(fù)，就形成了活鎖?；铈i會(huì)耗盡Cpu資源（在做無(wú)意義的調(diào)度）

2.死鎖：

有一個(gè)線程拿到資源，但相互等待互不釋放造成死鎖

3.需要考慮集群的管理問(wèn)題：

需要有一套機(jī)制來(lái)檢測(cè)到集群里節(jié)點(diǎn)的狀態(tài)變化。zk是通過(guò)臨時(shí)節(jié)點(diǎn)監(jiān)控哪個(gè)服務(wù)器掛掉的?。。。。?！

4.如果用一臺(tái)機(jī)器做集群管理：

存在單點(diǎn)故障問(wèn)題，所以針對(duì)集群管理，也需要形成一個(gè)集群（奇數(shù)臺(tái)，至少3臺(tái)）

5.管理集群里L(fēng)eader的選舉問(wèn)題（要根據(jù)一定的算法和規(guī)則來(lái)選舉），包括要考慮Leader掛掉之后，如何從剩余的follower里選出Leader

6.分布式鎖的實(shí)現(xiàn)，用之前學(xué)的重入鎖，同步代碼塊是做不了的（因?yàn)橹皩W(xué)的鎖都是單機(jī)鎖）

Zk數(shù)據(jù)結(jié)構(gòu)

1.ZK有一個(gè)最開(kāi)始的節(jié)點(diǎn)

2.每個(gè)znode節(jié)點(diǎn)都可存儲(chǔ)數(shù)據(jù)

3.Znode樹(shù)的維系實(shí)在內(nèi)存中，目的是供用戶快速的查詢

4.每個(gè)znode節(jié)點(diǎn)都是一個(gè)路徑（通過(guò)路徑來(lái)定位這個(gè)節(jié)點(diǎn)）

5.每個(gè)路徑名都是唯一的。

想要執(zhí)行以下指令，需要先啟動(dòng)zk服務(wù)器端（bash zkServer.sh start），再啟動(dòng)zk客戶端（bash zkCli.sh）

ZK指令

ls/create/delete/get/set

Zk集群搭建完畢后的數(shù)據(jù)一致性：

如果用java代碼連接該集群中的任何一個(gè)服務(wù)器，對(duì)其做的節(jié)點(diǎn)上的修改，在其余服務(wù)器也會(huì)產(chǎn)生同樣的修改（即：集群中的服務(wù)器保證數(shù)據(jù)完全一致）

Zookeeper事務(wù)概念?

1.每一個(gè)創(chuàng)建節(jié)點(diǎn)、修改節(jié)點(diǎn)、刪除節(jié)點(diǎn)操作都是一個(gè)事務(wù)，每一個(gè)事務(wù)都用一個(gè)事務(wù)id來(lái)代表，叫：zxid

2.zxid 是全局唯一，并且全局遞增的。作用就是可以根據(jù)最大事務(wù)id，找到最新的事務(wù)

Zookeeper選舉機(jī)制

Leader選舉出來(lái)之后

Leader身上一般是有最新數(shù)據(jù)的（有最大事務(wù)id的），所以首先做的就是原子廣播（通過(guò)原子廣播端口發(fā)送事物給其余服務(wù)器）。

原子廣播的目的：

一、是為了確保數(shù)據(jù)一致性（即客戶端無(wú)論通過(guò)哪個(gè)zk服務(wù)器查看數(shù)據(jù)，數(shù)據(jù)都是一樣的）

二、是為了防止leader掛掉之后，數(shù)據(jù)的丟失問(wèn)題

節(jié)點(diǎn)類型及特點(diǎn)

persistent（持久節(jié)點(diǎn)）：

ephemeral（臨時(shí)節(jié)點(diǎn)）：

如果和他綁定的服務(wù)器宕機(jī)了，他則消失

觀察者模式

觀察者模式的產(chǎn)生意義：

為了提高Zk選舉性能，處理思想就是減少投票人數(shù)。（前提是滿足過(guò)半機(jī)制），

由此，zk引出了觀 察者模式 觀察者特點(diǎn)：

1.不參與投票（選舉的投票以及事務(wù)更新的投票）

2.觀察者會(huì)跟隨最后的投票結(jié)果

Zookeeper的特性

數(shù)據(jù)一致性（單一視圖）

client不論連接到哪個(gè)Zookeeper，展示給它都是同一個(gè)視圖，即查詢的數(shù)據(jù)都是一樣的。這是zookeeper最重要的性能。

原子性

對(duì)于事務(wù)決議的更新，要么都更新成功，要么都不更新。

可靠性

一旦服務(wù)端發(fā)生改變，那么這次變更將會(huì)一直保留下來(lái)，除非有另一個(gè)事務(wù)又對(duì)其進(jìn)行了改變。

實(shí)時(shí)性

Zookeeper保證客戶端將在非常短的時(shí)間間隔范圍內(nèi)獲得服務(wù)器的更新信息，或者服務(wù)器失效 的信息，或者指定監(jiān)聽(tīng)事件的變化信息。（前提條件是：網(wǎng)絡(luò)狀況良好）

過(guò)半性 zookeeper

集群必須有半數(shù)以上的機(jī)器存活才能正常工作。因?yàn)橹挥袧M足過(guò)半數(shù)，才能滿足選 舉機(jī)制選出Leader。因?yàn)橹挥羞^(guò)半，在做事務(wù)決議時(shí)，事務(wù)才能更新。 所以一般來(lái)說(shuō)，zookeeper集群的數(shù)量最好是奇數(shù)個(gè)。

Zk的腦裂

腦裂的定義：

在管理集群里，出現(xiàn)兩個(gè)Leader的狀況，造成數(shù)據(jù)混亂，造成整個(gè)集群出現(xiàn)問(wèn)題。腦裂問(wèn)題是不可控和不可模擬的。出現(xiàn)腦裂問(wèn)題的根源是選舉機(jī)制自集群的選舉。 并且普遍存在于Master-slave架構(gòu)（主從架構(gòu)）里。

Zk腦裂的預(yù)防 ：

為選舉的Leader分配遞增id，根據(jù)id的大小去判斷是否老Leader或新Leader，如果是老Leader， 就不接受其指令。

hadoop

什么是Hadoop？

Hadoop是將海量數(shù)據(jù)在分布式集群上儲(chǔ)存（通過(guò)HDFS（分布式數(shù)據(jù)儲(chǔ)存系統(tǒng)）），并運(yùn)行分布式分析數(shù)據(jù)（基于mapreduce的一套數(shù)據(jù)處理框架）

Hadoop能儲(chǔ)存和抽取非關(guān)系型數(shù)據(jù)，但并沒(méi)有查詢語(yǔ)言介入，因此不能說(shuō)它是一個(gè)數(shù)據(jù)庫(kù)，它更像一個(gè)數(shù)據(jù)倉(cāng)庫(kù)，只有通過(guò)mapreduce這樣的工具才能進(jìn)行真正的數(shù)據(jù)處理

HDFS的特點(diǎn)

HDFS概述(HDFS架構(gòu)圖):

HDFS中存在:

一個(gè)名字節(jié)點(diǎn)NameNode（對(duì)應(yīng)一臺(tái)服務(wù)器）和多個(gè)數(shù)據(jù)節(jié)點(diǎn)DataNode（對(duì)應(yīng)多臺(tái)服務(wù)器）

NameNode

存儲(chǔ)元數(shù)據(jù)信息（元數(shù)據(jù)：描述數(shù)據(jù)的數(shù)據(jù)）

元數(shù)據(jù)保存在內(nèi)存/磁盤(pán)中

保存文件、block、datanode之間的映射關(guān)系

DataNode

存儲(chǔ)block內(nèi)容

存儲(chǔ)在磁盤(pán)中

HDFS優(yōu)點(diǎn)

1.支持超大文件。

2.檢測(cè)和快速應(yīng)對(duì)硬件故障

3.使應(yīng)用程序能以流的形式訪問(wèn)數(shù)據(jù)集，增大了數(shù)據(jù)的吞吐量

4.大部分hdfs操作文件時(shí)，需要一次寫(xiě)入，多次讀取，不會(huì)修改，有利于提高吞吐量

5.高容錯(cuò)性（數(shù)據(jù)自動(dòng)保存多個(gè)副本，副本丟失后自動(dòng)恢復(fù)）

6.可構(gòu)建在廉價(jià)機(jī)器上，提高集群存儲(chǔ)能力

HDFS缺點(diǎn)

不適用于低延遲數(shù)據(jù)訪問(wèn)的場(chǎng)景（因?yàn)樘岣吡藬?shù)據(jù)吞吐量，而犧牲了獲取數(shù)據(jù)的延遲）

不適用于大量的小文件儲(chǔ)存的場(chǎng)景（namenode的內(nèi)存大小，決定了hdfs文件系統(tǒng)可保存的文件數(shù)量。大量的小文件會(huì)在namenode上產(chǎn)生大量的記錄，占用其空間）

不適用于多用戶寫(xiě)入文件、修改文件的場(chǎng)景，只有這樣數(shù)據(jù)的吞吐量才能大。

不支持超強(qiáng)的事務(wù)（沒(méi)有像關(guān)系型數(shù)據(jù)庫(kù)那樣，對(duì)事務(wù)有強(qiáng)有力的支持）

HDFS細(xì)節(jié)說(shuō)明

Block塊概念

數(shù)據(jù)塊（block）是HDFS為文件提供的切塊后的數(shù)據(jù)儲(chǔ)存的空間，其默認(rèn)大小為128M，若文件小于128M，則塊的大小為文件大小

NameNode

A.NameNode維護(hù)著HDFS中的元信息，數(shù)據(jù)格式參照如下：

/test/a.log（哪個(gè)文件）,3（備份了幾份）,{b1,b2}（切了幾塊）,[{b1:[h0,h1,h3]}（第一塊的位置都在哪些datanode上）,{b2:[h0,h2,h4]}（第二塊的位置都在哪些datanode上）

B.NameNode中的元數(shù)據(jù)（metadata）信息存儲(chǔ)在：

內(nèi)存/文件中，內(nèi)存中為實(shí)時(shí)信息，文件中為數(shù)據(jù)鏡像作為持久化存儲(chǔ)使用。

這些文件包括：

fsimage ：元數(shù)據(jù)鏡像文件。存儲(chǔ)某NameNode元數(shù)據(jù)信息，但并不是實(shí)時(shí)同步內(nèi)存中的數(shù)據(jù)。

edits ：記錄操作的日志文件

元數(shù)據(jù)具體儲(chǔ)存流程如下：

NameNode會(huì)首先將元數(shù)據(jù)寫(xiě)到edits文件中，寫(xiě)入成功后才會(huì)修改內(nèi)存中的元數(shù)據(jù)，并向客戶端返回這才請(qǐng)求的結(jié)果。

此時(shí)不會(huì)更新fsimage中的元數(shù)據(jù)，所以，fsimage中的元數(shù)據(jù)并不是實(shí)時(shí)的元數(shù)據(jù)，只有在達(dá)到條件時(shí)再根據(jù)edits進(jìn)行更新，更新過(guò)程需要SecondaryNameNode（相當(dāng)于NN的助理，專門(mén)負(fù)責(zé)合并的工作）參與。

上圖所示：達(dá)到條件后 snn會(huì)將nn中的fsimage和edits文件拷貝過(guò)來(lái)，同時(shí)nn中會(huì)創(chuàng)建一個(gè)新的edits.new文件，新的讀寫(xiě)請(qǐng)求會(huì)寫(xiě)入到這個(gè)edits.new中，在snn中將拷貝過(guò)來(lái)的fsimage和edits合并為一個(gè)新的fsimage，最后snn將合并完成的fsimage文件拷貝回nn中替換之前的fsimage，nn再將edtis.new改為edits

問(wèn)：ssn可以對(duì)元數(shù)據(jù)做一定程度的備份，但不是熱備，對(duì)不對(duì)？那什么情況下可能造成NameNode元數(shù)據(jù)信息丟失?

snn并不是nn的熱備，但是能保存大部分備份數(shù)據(jù)。原因就在于在合并過(guò)程中，如果nn發(fā)生故障，那edits.new中的數(shù)據(jù)丟失了就找不回來(lái)了，找回來(lái)的只能是用于合并的原edits，因此通常NameNode和SNN要放置到不同機(jī)器中以此提升性能，并提供一定的元數(shù)據(jù)安全性。

何時(shí)觸發(fā)數(shù)據(jù)合并？：

根據(jù)配置文件設(shè)置的時(shí)間間隔：fs.checkpoint.period 默認(rèn)3600秒；

根據(jù)配置文件設(shè)置的edits log大小 fs.checkpoint.size 默認(rèn)64MB；

DataNode

DataNode節(jié)點(diǎn)會(huì)不斷向NameNode節(jié)點(diǎn)發(fā)送心跳報(bào)告。

初始化時(shí)，每個(gè)數(shù)據(jù)節(jié)點(diǎn)將當(dāng)前存儲(chǔ)的數(shù)據(jù)塊告知NameNode節(jié)點(diǎn)。

通過(guò)向NameNode主動(dòng)發(fā)送心跳保持與其聯(lián)系（3秒一次）

后續(xù)DataNode節(jié)點(diǎn)在工作的過(guò)程中，數(shù)據(jù)節(jié)點(diǎn)仍會(huì)不斷的更新NameNode節(jié)點(diǎn)與之對(duì)應(yīng)的元數(shù)據(jù)信息，并接受來(lái)自NameNode節(jié)點(diǎn)的指令，創(chuàng)建、移動(dòng)或者刪除本地磁盤(pán)上的數(shù)據(jù)塊。

如果10分鐘都沒(méi)收到dn的心跳，則認(rèn)為其已經(jīng)lost，并copy其上的block到其他dn

Block三個(gè)副本放置策略：

第一個(gè)副本：如果上傳文件的服務(wù)器本身就是DataNode，就放置在上傳文件的DN；如果是外部客戶端向集群上傳，就隨機(jī)選擇一臺(tái)磁盤(pán)不太滿，cpu不太忙的節(jié)點(diǎn)

第二個(gè)副本：放置在第一個(gè)副本不同機(jī)架的節(jié)點(diǎn)上（會(huì)自動(dòng)找到不同機(jī)架）

第三個(gè)副本：放置在與第二個(gè)副本相同機(jī)架的節(jié)點(diǎn)上（機(jī)架內(nèi)通訊比機(jī)架間通訊塊）

HDFS執(zhí)行流程

HDFS讀流程圖

1.OpenFile:使用HDFS提供的客戶端開(kāi)發(fā)庫(kù)Client，向遠(yuǎn)程的Namenode發(fā)起RPC請(qǐng)求；

Get Block: Namenode會(huì)視情況返回文件的部分或者全部block列表，對(duì)于每個(gè)block，Namenode都會(huì)返回有該block拷貝的三個(gè)三個(gè)DataNode地址；

客戶端開(kāi)發(fā)庫(kù)Client會(huì)選取離客戶端最接近的DataNode來(lái)讀取block；如果客戶端本身就是DataNode,那么將從本地直接獲取數(shù)據(jù).

讀取完當(dāng)前block的數(shù)據(jù)后，關(guān)閉與當(dāng)前的DataNode連接，并為讀取下一個(gè)block尋找最佳的DataNode，每讀取完一個(gè)block都會(huì)進(jìn)行checksum驗(yàn)證，如果讀取datanode時(shí)出現(xiàn)錯(cuò)誤，客戶端會(huì)通知Namenode，然后再?gòu)南乱粋€(gè)擁有該block拷貝的datanode繼續(xù)。當(dāng)讀完列表的block后，且文件讀取還沒(méi)有結(jié)束，客戶端開(kāi)發(fā)庫(kù)會(huì)繼續(xù)向Namenode獲取下一批的block列表。

當(dāng)文件最后一個(gè)塊也都讀取完成后，datanode會(huì)連接namenode告知關(guān)閉文件。

HDFS寫(xiě)流程（存入文件）

1.使用HDFS提供的客戶端開(kāi)發(fā)庫(kù)Client，向遠(yuǎn)程的Namenode發(fā)起RPC請(qǐng)求；Namenode會(huì)檢查要?jiǎng)?chuàng)建的文件是否已經(jīng)存在，創(chuàng)建者是否有權(quán)限進(jìn)行操作，成功則會(huì)為文件創(chuàng)建一個(gè)記錄(賬本（edits）上記錄一條)，否則會(huì)讓客戶端拋出異常；

當(dāng)客戶端開(kāi)始寫(xiě)入文件的時(shí)候，開(kāi)發(fā)庫(kù)Client會(huì)將文件切分成多個(gè)packets（數(shù)據(jù)包，每個(gè)包是64k）（注意：文件會(huì)被切成數(shù)據(jù)包而非數(shù)據(jù)塊,數(shù)據(jù)塊是HDFS所提供的儲(chǔ)存這些數(shù)據(jù)包的空間），并在內(nèi)部以數(shù)據(jù)隊(duì)列"data queue"的形式管理這些packets，并向Namenode申請(qǐng)新的blocks。

開(kāi)發(fā)庫(kù)把packet以流的方式寫(xiě)入第一個(gè)datanode中的block，該block把該packet存儲(chǔ)之后，再將其傳遞給的下一個(gè)datanode中的block，直到最后一個(gè)datanode中的block，這種寫(xiě)數(shù)據(jù)的方式呈流水線的形式。

最后一個(gè)datanode成功存儲(chǔ)之后會(huì)返回一個(gè)信息，向上傳遞至客戶端，在客戶端的開(kāi)發(fā)庫(kù)成功收到信息后，會(huì)從數(shù)據(jù)隊(duì)列中移除相應(yīng)的packet。

6當(dāng)所有的塊都存放完后，通知NameNode關(guān)閉文件。

HDFS的刪除流程

當(dāng)NameNode執(zhí)行delete方法時(shí)，它只標(biāo)記操作涉及的需要被刪除的數(shù)據(jù)塊，而不會(huì)主動(dòng)聯(lián)系這些數(shù)據(jù)塊所在的DataNode節(jié)點(diǎn)。

當(dāng)保存著這些數(shù)據(jù)塊的DataNode節(jié)點(diǎn)向NameNode節(jié)點(diǎn)發(fā)送心跳時(shí)，在心跳應(yīng)答里，NameNode節(jié)點(diǎn)會(huì)向DataNode發(fā)出指令，從而把數(shù)據(jù)刪除掉。

所以在執(zhí)行完delete方法后的一段時(shí)間內(nèi)，數(shù)據(jù)塊才能被真正的刪除掉。

安全模式

何時(shí)會(huì)進(jìn)入安全模式，此時(shí)的特點(diǎn)：

在啟動(dòng)HDFS后，會(huì)立即進(jìn)入安全模式，此時(shí)不能操作hdfs中的文件，只能查看目錄文件名等，讀寫(xiě)操作都不能進(jìn)行。

為什么要進(jìn)入安全模式？安全模式中所進(jìn)行的任務(wù)：

namenode啟動(dòng)時(shí)，需要載入fsimage文件到內(nèi)存，同時(shí)執(zhí)行edits文件中各項(xiàng)操作

一旦在內(nèi)存中成功建立文件系統(tǒng)元數(shù)據(jù)的映射，則創(chuàng)建一個(gè)新的fsimage文件（這個(gè)步驟不需要SNN的參與）和一個(gè)空的編輯文件。

在此階段NameNode收集各個(gè)DataNode的報(bào)告，當(dāng)每個(gè)數(shù)據(jù)塊都備份了三份以上時(shí)（不足的會(huì)自動(dòng)復(fù)制到三份以上），再經(jīng)過(guò)若干時(shí)間，安全模式結(jié)束

補(bǔ)充：數(shù)據(jù)塊的具體存放位置是由誰(shuí)來(lái)維護(hù)的？

Namenode只是告訴哪個(gè)datanode中要放哪些數(shù)據(jù)塊，而具體放在datanode中的哪個(gè)位置，由datanode決定（其內(nèi)部維護(hù)了一個(gè)數(shù)據(jù)塊列表）

MapReduce

概述

MapReduce是一個(gè)分布式計(jì)算框架（HDFS是一個(gè)分布式文件儲(chǔ)存系統(tǒng)），解決了海量數(shù)據(jù)的計(jì)算問(wèn)題。

MapReduce框架的節(jié)點(diǎn)組成結(jié)構(gòu)

1、 ResourceManager工作職能：

A.知道管理哪些機(jī)器，即管理哪些NodeManager。

B.要有檢測(cè)機(jī)制，能夠檢測(cè)到NodeManager的狀態(tài)變換，通過(guò)RPC心跳來(lái)實(shí)現(xiàn)。

C.任務(wù)的分配和調(diào)度

2、 NodeManager工作職能：

A.能夠收到ResourceManager發(fā)過(guò)來(lái)的任務(wù)，并進(jìn)行任務(wù)的處理。這里處理任務(wù)指的是Map任務(wù)或Reduce任務(wù)。

Map、Reduce的執(zhí)行步驟

要能說(shuō)清整個(gè)流程

Map和reduce個(gè)數(shù)的確定：

要處理的文件被分成了幾塊儲(chǔ)存在HDFS上，當(dāng)使用MR進(jìn)行文件處理時(shí)，就會(huì)調(diào)用幾個(gè)map任務(wù)來(lái)處理這幾塊的數(shù)據(jù)；對(duì)map的輸出進(jìn)行洗牌（shuffle），設(shè)置分區(qū)個(gè)數(shù)（相同key肯定在同一個(gè)區(qū)，但是不同的key也可能在同一個(gè)區(qū)）后，分了幾個(gè)區(qū)就會(huì)創(chuàng)建幾個(gè)reduce來(lái)處理這些分區(qū)中的數(shù)據(jù)

Mapreduce執(zhí)行溢寫(xiě)原理

1.Mapper

每個(gè)MapperTask有一個(gè)環(huán)形內(nèi)存緩沖區(qū)，用于存儲(chǔ)map任務(wù)的輸出。默認(rèn)大小100MB，一旦達(dá)到閥值0.8,一個(gè)后臺(tái)線程把內(nèi)容寫(xiě)到磁盤(pán)的指定目錄下的新建的一個(gè)溢出寫(xiě)文件。

寫(xiě)磁盤(pán)前，要partition,sort,Combiner（這些就是在shuffle中要做的事情）。如果有后續(xù)的數(shù)據(jù)，將會(huì)繼續(xù)寫(xiě)入環(huán)形緩沖區(qū)中，最終寫(xiě)入下一個(gè)溢出文件中。

等最后記錄寫(xiě)完，合并全部溢出寫(xiě)文件為一個(gè)分區(qū)且排序的文件。

2.Reducer

Reducer通過(guò)Http方式得到輸出文件的分區(qū)。

NodeManager為分區(qū)文件運(yùn)行Reduce任務(wù)。復(fù)制階段把Map輸出復(fù)制到Reducer的內(nèi)存或磁盤(pán)（一但Map任務(wù)完成，Reduce就開(kāi)始復(fù)制map輸出）

小文件處理

小文件的定義

小文件指的是：

那些size比HDFS?的block?size(128M)小的多的文件。如果在HDFS中存儲(chǔ)海量的小文件，會(huì)產(chǎn)生很多問(wèn)題。

大量小文件在HDFS中的問(wèn)題

問(wèn)題：太占namenode內(nèi)存空間（1000個(gè)1M比1個(gè)1000M多占1000倍的namenode空間）

因此HDFS并不是為了有效的處理大量小文件而存在的。它主要是為了流式的訪問(wèn)大文件而設(shè)計(jì)的。

大量小文件在mapreduce中的問(wèn)題

Map?tasks通常是每次處理一個(gè)block的input，如果有大量小文件，就會(huì)有很多block，就會(huì)產(chǎn)生大量的map?tasks。Hadoop里每個(gè)task任務(wù)（map任務(wù)或reduce任務(wù)）的執(zhí)行都會(huì)啟動(dòng)JVM來(lái)運(yùn)行。啟動(dòng)一個(gè)新的JVM將耗時(shí)1秒左右，對(duì)于運(yùn)行時(shí)間較長(zhǎng)（比如1分鐘以上）的job影響不大，但如果都是時(shí)間很短的task，那么頻繁啟停JVM會(huì)有開(kāi)銷。

解決方法：

1.可以在一個(gè)JVM中允許task?reuse，以支持在一個(gè)JVM中運(yùn)行多個(gè)map?task，以此來(lái)減少一些JVM的啟動(dòng)消耗(通過(guò)設(shè)置mapred.job.reuse.jvm.num.tasks屬性，默認(rèn)為1，－1為無(wú)限制)。

2.將多個(gè)小文件合成一個(gè)spilt，即用一個(gè)map任務(wù)來(lái)處理。

flume

1.flume概述

1.1.flume概念（日志收集）

1.1.1.flume概念

flume是分布式的，可靠的，高可用的，用于對(duì)不同來(lái)源的大量的日志數(shù)據(jù)進(jìn)行有效收集、聚集和移動(dòng)，并以集中式的數(shù)據(jù)存儲(chǔ)的系統(tǒng)。

運(yùn)行原理：

將日志信息的每一行，包裝成json格式，再傳入flume系統(tǒng)中進(jìn)行管理

補(bǔ)：json格式：

{“header”:{“name”:“l(fā)iming”,“age”:“18”},body:{日志中每一行字符串}}

2.flume中的概念、模型和特點(diǎn)

2.1.flume中的一些重要概念

2.1.1.flume Event：

flume 事件，被定義為一個(gè)具有有效荷載的字節(jié)數(shù)據(jù)流和可選的字符串屬性集。

2.1.2.flume Agent：

flume 代理，是一個(gè)進(jìn)程承載從外部源事件流到下一個(gè)目的地的過(guò)程。包含source channel 和 sink。

2.1.3.Source

數(shù)據(jù)源，消耗外部傳遞給他的事件，外部源將數(shù)據(jù)按照f(shuō)lume Source 能識(shí)別的格式將Flume 事件發(fā)送給flume Source。

2.1.4.Channel

數(shù)據(jù)通道，是一個(gè)被動(dòng)的存儲(chǔ)，用來(lái)保持事件，直到由一個(gè)flume Sink消耗。

2.1.5.Sink

數(shù)據(jù)匯聚點(diǎn)，代表外部數(shù)據(jù)存放位置。發(fā)送flume event到指定的外部目標(biāo)。

各種不同Source（提供了不同類型的數(shù)據(jù)源，只需要在配置文件中更改source的配置）

1.Avro source:（用的最多）

監(jiān)聽(tīng)Avro客戶端，將監(jiān)聽(tīng)到的事件流作為數(shù)據(jù)源

3.Spooling Directory Source:

監(jiān)聽(tīng)自動(dòng)收集目錄，如果有文件傳入，flume就會(huì)以日志的形式解析，并收集這些文件，這些傳入的文件就相當(dāng)于數(shù)據(jù)源

4.Netcat Source:

監(jiān)聽(tīng)指定端口，并將接受到的數(shù)據(jù)每一行轉(zhuǎn)換為一個(gè)事件作為數(shù)據(jù)源

各種不同的Sink（是指收到的外部數(shù)據(jù)存放位置，只需要在配置文件中更改sink的配置）：

2.File Roll Sink:

每隔指定時(shí)長(zhǎng)，生成文件，保存這段時(shí)間收到的外部數(shù)據(jù)

3.Avro Sink:

作為多級(jí)流動(dòng)、扇入、扇出的數(shù)據(jù)儲(chǔ)存中介使用，是多級(jí)流動(dòng)、扇入、扇出的基礎(chǔ)

4.HDFS Sink:

將收到的外部數(shù)據(jù)儲(chǔ)存到HDFS中

各種不同的channel（是指收到的外部數(shù)據(jù)在中間過(guò)渡時(shí)的存放位置，只需要在配置文件中更改channel的配置）：

1.Memory channel:

數(shù)據(jù)被臨時(shí)保存在內(nèi)存中的指定大小的隊(duì)列

3.File Channel:

數(shù)據(jù)被持久保存在硬盤(pán)中

4.Spillable Memory Channel:

數(shù)據(jù)被保存在內(nèi)存隊(duì)列和硬盤(pán)中（相當(dāng)于1和3的結(jié)合，最常用）

Selector:

選擇器，用于扇出的兩種模式下，指定數(shù)據(jù)發(fā)送給哪個(gè)channel

Interceptors:

攔截器，在數(shù)據(jù)發(fā)送給channel前，對(duì)數(shù)據(jù)進(jìn)行修改或刪除

1.Timestamp Interceptors:

修改數(shù)據(jù)，在event頭中加入當(dāng)前處理時(shí)間（即：系統(tǒng)時(shí)間）

6.Search and Replace Interceptor:

先檢查event的body中數(shù)據(jù)，再替換（撿查和替換都是基于字符串的正則表達(dá)式的）

Processor:

用于實(shí)現(xiàn)負(fù)載均衡和失敗恢復(fù)的工具

1.Default Sink Processor:

這是默認(rèn)情況下的使用，即：一個(gè)sink對(duì)應(yīng)一個(gè)channel

2.Failover Sink Processor:

這是用于失敗恢復(fù)的情況（如：3個(gè)sink對(duì)應(yīng)一個(gè)channel，分別設(shè)置優(yōu)先級(jí)，優(yōu)先級(jí)高的優(yōu)先使用，如果高的壞了，第二高的可以頂替他繼續(xù)工作，注：同時(shí)只能有一臺(tái)在工作，其余相當(dāng)于備用的）

3.Load Balancing? Sink Processor:

這是用于負(fù)載均衡的情況（有輪詢或隨機(jī)兩種方式）

hive

分區(qū)表的含義：

hive支持分區(qū)表，當(dāng)文件中數(shù)據(jù)量很大，且常常出現(xiàn)按某一字段查詢（如：...where country=’...’，這就叫按country字段進(jìn)行查詢），需要對(duì)數(shù)據(jù)進(jìn)行分區(qū)，因?yàn)檫@樣可以極大的提高查詢時(shí)的效率?。。。](méi)分區(qū)時(shí)需要在所有數(shù)據(jù)中先提取符合該字段的數(shù)據(jù)，分區(qū)以后可以直接在這個(gè)country分區(qū)中查詢了?。?/p>

六、HIVE語(yǔ)法（相當(dāng)于數(shù)據(jù)庫(kù)的sql）

9.補(bǔ)充：

增加分區(qū):

ALTER TABLE book add? PARTITION (category = 'zazhi') location '/user/hive/warehouse/datax.db/book/category=zazhi';

刪除分區(qū):

ALTER TABLE table_name DROP partition_spec, partition_spec,...

重命名表:

ALTER TABLE table_name RENAME TO new_table_name

修改列名:

ALTER TABLE table_name CHANGE [COLUMN] col_old_name col_new_name column_type [COMMENT col_comment] [FIRST|AFTER column_name]

增加/替換列:

ALTER TABLE table_name ADD|REPLACE COLUMNS (col_name data_type [COMMENT col_comment], ...)

查看表名，部分匹配

SHOW TABLES 'page.*';

SHOW TABLES '.*view';

查看某表的所有Partition，如果沒(méi)有就報(bào)錯(cuò)：

SHOW PARTITIONS page_view;

查看某表結(jié)構(gòu)：

DESCRIBE invites;

查看分區(qū)內(nèi)容

SELECT a.foo FROM invites a WHERE a.ds='2008-08-15';

Hbase（了解）

一、HBASE概述

HBASE與HIVE的區(qū)別：

HBASE：是基于hadoop的數(shù)據(jù)庫(kù)工具（把hadoop作為數(shù)據(jù)庫(kù)）

HIVE：是基于hadoop的數(shù)據(jù)倉(cāng)庫(kù)工具（把hadoop作為數(shù)據(jù)倉(cāng)庫(kù)）

優(yōu)點(diǎn)：

1.是一種 NoSQL 非關(guān)系型的數(shù)據(jù)庫(kù) 不符合關(guān)系型數(shù)據(jù)庫(kù)的范式 （關(guān)系型數(shù)據(jù)庫(kù)的范式：可以將數(shù)據(jù)放在行列構(gòu)成的很多表中，進(jìn)行表的關(guān)聯(lián)，從而闡明數(shù)據(jù)之間的關(guān)系）

2.適合存儲(chǔ)：半結(jié)構(gòu)化（如：json格式）與非結(jié)構(gòu)化的數(shù)據(jù)（不能用行列表示的數(shù)據(jù)，如圖片，視頻，音頻；語(yǔ)音識(shí)別技術(shù)、圖像識(shí)別技術(shù)、機(jī)械學(xué)習(xí)技術(shù)實(shí)際上就是在處理非結(jié)構(gòu)化數(shù)據(jù)）

3.適合存儲(chǔ)稀疏的數(shù)據(jù)，hbase中空的數(shù)據(jù)不占用空間（mysql中空數(shù)據(jù)也占用空間）

為什么會(huì)出現(xiàn)空數(shù)據(jù)呢？

因?yàn)槭欠墙Y(jié)構(gòu)化的數(shù)據(jù)，因此勢(shì)必有些格中沒(méi)有數(shù)據(jù)

4.面向列(族)進(jìn)行存儲(chǔ)，方便對(duì)數(shù)據(jù)進(jìn)行壓縮 （mysql是以行進(jìn)行存儲(chǔ)）

5.提供實(shí)時(shí)增刪改查的能力 是一種真正的數(shù)據(jù)庫(kù)

6.可以存儲(chǔ)海量數(shù)據(jù)，性能也很強(qiáng)大，可以實(shí)現(xiàn)上億條記錄的毫秒級(jí)別的查詢

7.是一個(gè)高可靠性，高性能，面向列，可伸縮的分布式存儲(chǔ)系統(tǒng) 利用hbase技術(shù)可以在廉價(jià)的PC上搭建起大規(guī)模結(jié)構(gòu)化存儲(chǔ)集群。

8.HBase利用HadoopHDFS作為其文件存儲(chǔ)系統(tǒng)，利用Hadoop的MapReduce來(lái)處理HBase中的海量數(shù)據(jù)，利用Zookeeper作為協(xié)調(diào)工具

缺點(diǎn)：

不能提供嚴(yán)格的事務(wù)控制，只能在行級(jí)別保證事務(wù)

(2)邏輯結(jié)構(gòu)

hbase通過(guò)表來(lái)存儲(chǔ)數(shù)據(jù) 但是表的結(jié)構(gòu)和關(guān)系型數(shù)據(jù)庫(kù)非常的不一樣

行鍵（RowKey ）：

列族（Column Family ）：

列（Column）：

單元格與時(shí)間戳（cell timestamp ）

kafka

一、Kafka概述

分布式消息隊(duì)列

按topic分類開(kāi)放數(shù)據(jù)

Producer Consumer

Broker

使用zookeeper做為集群的協(xié)調(diào)工具

kafka的特點(diǎn)：

高吞吐量

Kafka 每秒可以生產(chǎn)約50 MB消息，每秒處理 110 MB消息

持久化數(shù)據(jù)存儲(chǔ)

將消息持久化到磁盤(pán)

分布式系統(tǒng)易于擴(kuò)展

所有的 producer、broker 和 consumer 都會(huì)有多個(gè)，均為分布式的。無(wú)需停機(jī)即可擴(kuò)展機(jī)器。

客戶端consumer自己維護(hù)自己的狀態(tài)（狀態(tài)即：該讀取什么數(shù)據(jù)了）

消息被處理的狀態(tài)是在 consumer 端維護(hù)，而不是由 server 端維護(hù)。當(dāng)失敗時(shí)能自動(dòng)平衡。

二、Kafka中的基本概念

Kafka將消息以topic為單位進(jìn)行歸納。

將向Kafka topic發(fā)布消息的程序稱為producers.

將預(yù)訂topics并消費(fèi)消息的程序稱為consumer.

Kafka以集群的方式運(yùn)行，可以由一個(gè)或多個(gè)服務(wù)組成，每個(gè)服務(wù)叫做一個(gè)broker.

producers通過(guò)網(wǎng)絡(luò)將消息發(fā)送到Kafka集群，集群向消費(fèi)者提供消息。

客戶端和服務(wù)端通過(guò)TCP協(xié)議通信。Kafka提供了Java客戶端，并且對(duì)多種語(yǔ)言都提供了支持。

三、Topics、Producers、Consumers

1.Topics（主題）

1.一個(gè)topic是對(duì)一組消息的歸納。（topic的作用：可以讓多個(gè)不同的團(tuán)隊(duì)使用同一個(gè)kafka，而不會(huì)發(fā)生數(shù)據(jù)混亂）

2.對(duì)每個(gè)topic，Kafka 對(duì)它的日志進(jìn)行了分區(qū)（類似于圖書(shū)館的圖書(shū)分類擺放，實(shí)現(xiàn)了負(fù)載均衡，并且每個(gè)分區(qū)在Kafka集群的若干服務(wù)器中都有副本，這樣這些持有副本的服務(wù)可以共同處理數(shù)據(jù)和請(qǐng)求（類似于leader和flower的關(guān)系），副本數(shù)量是可以配置的。）

3.分區(qū)中的每個(gè)消息都有一個(gè)連續(xù)的序列號(hào)叫做offset,用來(lái)在分區(qū)中唯一的標(biāo)識(shí)這個(gè)消息。

4.在一個(gè)可配置的時(shí)間段內(nèi)，Kafka集群保留所有發(fā)布的消息，不管這些消息有沒(méi)有被消費(fèi)。比如，如果消息的保存策略被設(shè)置為2天，那么在一個(gè)消息被發(fā)布的兩天時(shí)間內(nèi)，它都是可以被消費(fèi)的，不論其是否被消費(fèi)過(guò)，之后它將被丟棄以釋放空間。

5.kafa的最大優(yōu)點(diǎn)：

Kafka的性能是和數(shù)據(jù)量無(wú)關(guān)的常量級(jí)的，所以保留太多的數(shù)據(jù)并不是問(wèn)題。（其性能由硬件決定）

6.將日志分區(qū)的目的：

首先這使得每個(gè)日志的數(shù)量不會(huì)太大，可以在單個(gè)服務(wù)上保存。另外每個(gè)分區(qū)可以單獨(dú)發(fā)布和消費(fèi)，為并發(fā)操作topic提供了一種可能。并且在kafka中通過(guò)分區(qū)實(shí)現(xiàn)了負(fù)載均衡和失敗恢復(fù)

2.Producers

Producer將消息發(fā)布到它指定的topic中,并負(fù)責(zé)決定發(fā)布到哪個(gè)分區(qū)。通常簡(jiǎn)單的由負(fù)載均衡機(jī)制隨機(jī)選擇分區(qū)，但也可以通過(guò)特定的分區(qū)函數(shù)選擇分區(qū)。

3.Consumers

**實(shí)際上每個(gè)consumer唯一需要維護(hù)的數(shù)據(jù)是消息在日志中的位置，也就是offset.這個(gè)offset由consumer來(lái)維護(hù)

**消費(fèi)消息通常有兩種模式：隊(duì)列模式（queuing）和發(fā)布-訂閱模式(publish-subscribe)。

(1)隊(duì)列模式

隊(duì)列模式中，多個(gè)consumers可以同時(shí)從服務(wù)端讀取消息，每個(gè)消息只被其中一個(gè)consumer讀到；

(2)發(fā)布訂閱模式

發(fā)布-訂閱模式中消息被廣播到所有的consumer中。

如果所有的consumer都在一個(gè)組中，這就成為了傳統(tǒng)的隊(duì)列模式，在各consumer中實(shí)現(xiàn)負(fù)載均衡。

如果所有的consumer都不在不同的組中，這就成為了發(fā)布-訂閱模式，所有的消息都被分發(fā)到所有的consumer中。

為什么大數(shù)據(jù)環(huán)境下的消息隊(duì)列常選擇kafka？

分布式存儲(chǔ)數(shù)據(jù)，提供了更好的性能 可靠性 可擴(kuò)展能力，且按照主題、分區(qū)來(lái)分布式存放數(shù)據(jù)，持久化存儲(chǔ)，提供海量數(shù)據(jù)存儲(chǔ)能力，性能和磁盤(pán)的性能相關(guān)和數(shù)據(jù)量的大小無(wú)關(guān)

storm

一、Storm作用：

分布式實(shí)時(shí)計(jì)算系統(tǒng)

二、Storm組件

1.結(jié)構(gòu)

storm結(jié)構(gòu)稱為topology(拓?fù)?，由stream(數(shù)據(jù)流),spout(噴嘴-數(shù)據(jù)流的生成者),bolt(閥門(mén)-數(shù)據(jù)流運(yùn)算者)組成(參考圖:Storm組成結(jié)構(gòu))。

不同于Hadoop中的job,Storm中的topology會(huì)一直運(yùn)行下去，除非進(jìn)程被殺死或取消部署。

2.Stream

Storm的核心數(shù)據(jù)結(jié)構(gòu)是tuple(元組)，本質(zhì)上是包含了一個(gè)或多個(gè)鍵值對(duì)的列表。Stream是由無(wú)限制的tuple組成的序列。

3.spout

spout連接到數(shù)據(jù)源，將數(shù)據(jù)轉(zhuǎn)化為一個(gè)個(gè)的tuple，并將tuple作為數(shù)據(jù)流進(jìn)行發(fā)射,通常不會(huì)用于處理業(yè)務(wù)邏輯，從而可以很方便的實(shí)現(xiàn)spout的復(fù)用。開(kāi)發(fā)一個(gè)spout的主要工作就是利用API編寫(xiě)代碼從數(shù)據(jù)源消費(fèi)數(shù)據(jù)流。

spout的數(shù)據(jù)源可以有很多種來(lái)源：

Kafka

Hbase

Mysql

Redis

hdfs

4.bolt（真正進(jìn)行業(yè)務(wù)處理的部分）

bolt主要負(fù)責(zé)數(shù)據(jù)的運(yùn)算，將接收到的數(shù)據(jù)實(shí)施運(yùn)算后，選擇性的輸出一個(gè)或多個(gè)數(shù)據(jù)流。

一個(gè)bolt可以接收多個(gè)由spout或其他bolt發(fā)射的數(shù)據(jù)流，從而可以組建出復(fù)雜的數(shù)據(jù)轉(zhuǎn)換和處理的網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)。

bolt常見(jiàn)的典型功能：

過(guò)濾

連接和聚合

計(jì)算

數(shù)據(jù)庫(kù)的讀寫(xiě)

Hadoop常見(jiàn)參數(shù)控制+調(diào)優(yōu)策略

配置所在文件 參數(shù) 參數(shù)默認(rèn)值 作用

hdfs-site.xml dfs.heartbeat.interval 3 DN的心跳間隔，秒

在集群網(wǎng)絡(luò)通信狀態(tài)不好的時(shí)候，適當(dāng)調(diào)大

hdfs-site.xml dfs.blocksize 134217728 塊大小，默認(rèn)是128MB

必須得是1024的整數(shù)倍

mapred-site.xml mapreduce.task.io.sort.mb 100 任務(wù)內(nèi)部排序緩沖區(qū)大小，默認(rèn)是100MB

此參數(shù)調(diào)大，能夠減少Spil溢寫(xiě)次數(shù)，減少磁盤(pán)I/O

mapred-site.xml mapreduce.reduce.shuffle.parallelcopies 5 Reduce Task 啟動(dòng)的并發(fā)拷貝數(shù)據(jù)的線程數(shù)

建議，盡可能等于或接近于Map任務(wù)數(shù)量，

但是不易過(guò)多。

mapred-site.xml io.sort.factor 10 merge文件合并因子，如果結(jié)果文件數(shù)量太多，可以適當(dāng)調(diào)大，從而減少I/O次數(shù)