POI操作Excel

posted @ 2020-03-20 10:13 鴻雁 閱讀(114) | 評(píng)論 (0) | 編輯 收藏

python操作文件存在的問(wèn)題解決辦法

posted @ 2019-05-14 23:04 鴻雁 閱讀(159) | 評(píng)論 (0) | 編輯 收藏

Hadoop-2.4.1學(xué)習(xí)之QJM HA的自動(dòng)故障轉(zhuǎn)移

前面學(xué)習(xí)了使用命令hdfs haadmin -failover手動(dòng)進(jìn)行故障轉(zhuǎn)移，在該模式下，即使現(xiàn)役NameNode已經(jīng)失效，系統(tǒng)也不會(huì)自動(dòng)從現(xiàn)役NameNode轉(zhuǎn)移到待機(jī)NameNode，下面學(xué)習(xí)如何配置部署HA自動(dòng)進(jìn)行故障轉(zhuǎn)移。自動(dòng)故障轉(zhuǎn)移為HDFS部署增加了兩個(gè)新組件：ZooKeeper和ZKFailoverController（ZKFC）進(jìn)程。ZooKeeper是維護(hù)少量協(xié)調(diào)數(shù)據(jù)，通知客戶端這些數(shù)據(jù)的改變和監(jiān)視客戶端故障的高可用服務(wù)。HA的自動(dòng)故障轉(zhuǎn)移依賴于ZooKeeper的以下功能：

• 故障檢測(cè)：集群中的每個(gè)NameNode在ZooKeeper中維護(hù)了一個(gè)持久會(huì)話，如果機(jī)器崩潰，ZooKeeper中的會(huì)話將終止，ZooKeeper通知另一個(gè)NameNode需要觸發(fā)故障轉(zhuǎn)移。
• 現(xiàn)役NameNode選擇：ZooKeeper提供了一個(gè)簡(jiǎn)單的機(jī)制用于唯一的選擇一個(gè)節(jié)點(diǎn)為active狀態(tài)。如果目前現(xiàn)役NameNode崩潰，另一個(gè)節(jié)點(diǎn)可能從ZooKeeper獲得特殊的排外鎖以表明它應(yīng)該成為現(xiàn)役NameNode。

       ZKFC是自動(dòng)故障轉(zhuǎn)移中的另一個(gè)新組件，是ZooKeeper的客戶端，也監(jiān)視和管理NameNode的狀態(tài)。每個(gè)運(yùn)行NameNode的主機(jī)也運(yùn)行了一個(gè)ZKFC進(jìn)程，ZKFC負(fù)責(zé)：

• 健康監(jiān)測(cè)：ZKFC使用一個(gè)健康檢查命令定期地ping與之在相同主機(jī)的NameNode，只要該NameNode及時(shí)地回復(fù)健康狀態(tài)，ZKFC認(rèn)為該節(jié)點(diǎn)是健康的。如果該節(jié)點(diǎn)崩潰，凍結(jié)或進(jìn)入不健康狀態(tài)，健康監(jiān)測(cè)器標(biāo)識(shí)該節(jié)點(diǎn)為非健康的。
• ZooKeeper會(huì)話管理：當(dāng)本地NameNode是健康的，ZKFC保持一個(gè)在ZooKeeper中打開(kāi)的會(huì)話。如果本地NameNode處于active狀態(tài)，ZKFC也保持一個(gè)特殊的znode鎖，該鎖使用了ZooKeeper對(duì)短暫節(jié)點(diǎn)的支持，如果會(huì)話終止，鎖節(jié)點(diǎn)將自動(dòng)刪除。
• 基于ZooKeeper的選擇：如果本地NameNode是健康的，且ZKFC發(fā)現(xiàn)沒(méi)有其它的節(jié)點(diǎn)當(dāng)前持有znode鎖，它將為自己獲取該鎖。如果成功，則它已經(jīng)贏得了選擇，并負(fù)責(zé)運(yùn)行故障轉(zhuǎn)移進(jìn)程以使它的本地NameNode為active。故障轉(zhuǎn)移進(jìn)城與前面描述的手動(dòng)故障轉(zhuǎn)移相似，首先如果必要保護(hù)之前的現(xiàn)役NameNode，然后本地NameNode轉(zhuǎn)換為active狀態(tài)。

       在典型部署中，ZooKeeper守護(hù)進(jìn)程運(yùn)行在三個(gè)或者五個(gè)節(jié)點(diǎn)上，但由于ZooKeeper本身需要較少的資源，所以將ZooKeeper部署在與現(xiàn)役NameNode和待機(jī)NameNode相同的主機(jī)上，還可以將ZooKeeper部署到與YARN的ResourceManager相同的節(jié)點(diǎn)上。建議配置ZooKeeper將數(shù)據(jù)存儲(chǔ)在與HDFS元數(shù)據(jù)不同的硬盤(pán)上以得到最好的性能和隔離性。在配置自動(dòng)故障轉(zhuǎn)移之前需要先停掉集群，目前在集群運(yùn)行時(shí)還不可能將手動(dòng)故障轉(zhuǎn)移的安裝轉(zhuǎn)換為自動(dòng)故障轉(zhuǎn)移的安裝。接下來(lái)看看如何配置HA的自動(dòng)故障轉(zhuǎn)移。首先在hdfs-site.xml中添加下面的參數(shù)，該參數(shù)的值默認(rèn)為false：

       在core-site.xml文件中添加下面的參數(shù)，該參數(shù)的值為ZooKeeper服務(wù)器的地址，ZKFC將使用該地址。

       在HA或者HDFS聯(lián)盟中，上面的兩個(gè)參數(shù)還需要以NameServiceID為后綴，比如dfs.ha.automatic-failover.enabled.mycluster。除了上面的兩個(gè)參數(shù)外，還有其它幾個(gè)參數(shù)用于自動(dòng)故障轉(zhuǎn)移，比如ha.zookeeper.session-timeout.ms，但對(duì)于大多數(shù)安裝來(lái)說(shuō)都不是必須的。

       在添加了上述的配置參數(shù)后，下一步就是在ZooKeeper中初始化要求的狀態(tài)，可以在任一NameNode中運(yùn)行下面的命令實(shí)現(xiàn)該目的，該命令將在ZooKeeper中創(chuàng)建znode：

       在啟用自動(dòng)故障轉(zhuǎn)移的集群中，start-dfs.sh腳本將在任何運(yùn)行NameNode的主機(jī)上自動(dòng)啟動(dòng)ZKFC守護(hù)進(jìn)程，一旦ZKFC啟動(dòng)完畢，它們將自動(dòng)選擇一個(gè)NameNode為現(xiàn)役NameNode。如果手動(dòng)管理集群中的服務(wù)，需要在每臺(tái)運(yùn)行NameNode的主機(jī)上手動(dòng)啟動(dòng)ZKFC，命令為：

       如果正在運(yùn)行一個(gè)安全的集群，可能想確保存儲(chǔ)在ZooKeeper中的信息也是安全的，這將阻止惡意的客戶端修改ZooKeeper中的元數(shù)據(jù)或者潛在地觸發(fā)一個(gè)錯(cuò)誤的故障轉(zhuǎn)移。為了保護(hù)ZooKeeper中的信息，首先在core-site.xml中添加下面的參數(shù)：

       參數(shù)值中的@字符表示參數(shù)值保存在@后的硬盤(pán)文件中。第一個(gè)配置文件指定了ZooKeeper的認(rèn)證列表，其格式與ZK CLI使用的相同，例如：digest:hdfs-zkfcs:mypassword，其中hdfs-zkfcs為ZooKeeper的用戶名，mypassword為密碼。其次使用下面的命令為該認(rèn)證生成一個(gè)ZooKeeper訪問(wèn)控制列表：

       拷貝->之后的字符串并添加digest:前綴，然后粘貼到zk-acls.txt中，例如：digest:hdfs-zkfcs:vlUvLnd8MlacsE80rDuu6ONESbM=:rwcda。要想使ACLs生效，需要再次運(yùn)行zkfc –formatZK。最后可能像下面這樣在ZK CLI中驗(yàn)證ACLs：

       在安裝完成自動(dòng)故障轉(zhuǎn)移后，或許需要測(cè)試一下。首先定位現(xiàn)役NameNode，可以通過(guò)訪問(wèn)NameNode的web頁(yè)面來(lái)確定哪個(gè)NameNode是active狀態(tài)的。一旦確定了處于active狀態(tài)的NameNode，就需要在該節(jié)點(diǎn)上制造點(diǎn)故障，比如使用命令kill -9 <pid of NN>模擬JVM崩潰，或重啟主機(jī)或拔掉網(wǎng)線來(lái)模擬不同的中斷。一旦觸發(fā)了自動(dòng)故障轉(zhuǎn)移，另一個(gè)NameNode應(yīng)該自動(dòng)在幾秒鐘內(nèi)變?yōu)閍ctive狀態(tài)。檢測(cè)到故障并觸發(fā)故障轉(zhuǎn)移由參數(shù)ha.zookeeper.session-timeout.ms控制，該參數(shù)為與core-site.xml中，默認(rèn)為5秒。如果測(cè)試不成功，可能是配置問(wèn)題，檢查ZKFC和NameNode進(jìn)程的日志以進(jìn)一步診斷問(wèn)題，通常錯(cuò)誤都是很明顯的。

posted @ 2017-08-13 18:49 鴻雁 閱讀(431) | 評(píng)論 (0) | 編輯 收藏

Yarn 調(diào)度器Scheduler詳解

理想情況下，我們應(yīng)用對(duì)Yarn資源的請(qǐng)求應(yīng)該立刻得到滿足，但現(xiàn)實(shí)情況資源往往是有限的，特別是在一個(gè)很繁忙的集群，一個(gè)應(yīng)用資源的請(qǐng)求經(jīng)常需要等待一段時(shí)間才能的到相應(yīng)的資源。在Yarn中，負(fù)責(zé)給應(yīng)用分配資源的就是Scheduler。其實(shí)調(diào)度本身就是一個(gè)難題，很難找到一個(gè)完美的策略可以解決所有的應(yīng)用場(chǎng)景。為此，Yarn提供了多種調(diào)度器和可配置的策略供我們選擇。

一、調(diào)度器的選擇

在Yarn中有三種調(diào)度器可以選擇：FIFO Scheduler ，Capacity Scheduler，FairS cheduler。

FIFO Scheduler把應(yīng)用按提交的順序排成一個(gè)隊(duì)列，這是一個(gè)先進(jìn)先出隊(duì)列，在進(jìn)行資源分配的時(shí)候，先給隊(duì)列中最頭上的應(yīng)用進(jìn)行分配資源，待最頭上的應(yīng)用需求滿足后再給下一個(gè)分配，以此類推。

FIFO Scheduler是最簡(jiǎn)單也是最容易理解的調(diào)度器，也不需要任何配置，但它并不適用于共享集群。大的應(yīng)用可能會(huì)占用所有集群資源，這就導(dǎo)致其它應(yīng)用被阻塞。在共享集群中，更適合采用Capacity Scheduler或Fair Scheduler，這兩個(gè)調(diào)度器都允許大任務(wù)和小任務(wù)在提交的同時(shí)獲得一定的系統(tǒng)資源。

下面“Yarn調(diào)度器對(duì)比圖”展示了這幾個(gè)調(diào)度器的區(qū)別，從圖中可以看出，在FIFO 調(diào)度器中，小任務(wù)會(huì)被大任務(wù)阻塞。

而對(duì)于Capacity調(diào)度器，有一個(gè)專門(mén)的隊(duì)列用來(lái)運(yùn)行小任務(wù)，但是為小任務(wù)專門(mén)設(shè)置一個(gè)隊(duì)列會(huì)預(yù)先占用一定的集群資源，這就導(dǎo)致大任務(wù)的執(zhí)行時(shí)間會(huì)落后于使用FIFO調(diào)度器時(shí)的時(shí)間。

在Fair調(diào)度器中，我們不需要預(yù)先占用一定的系統(tǒng)資源，F(xiàn)air調(diào)度器會(huì)為所有運(yùn)行的job動(dòng)態(tài)的調(diào)整系統(tǒng)資源。如下圖所示，當(dāng)?shù)谝粋€(gè)大job提交時(shí)，只有這一個(gè)job在運(yùn)行，此時(shí)它獲得了所有集群資源；當(dāng)?shù)诙€(gè)小任務(wù)提交后，F(xiàn)air調(diào)度器會(huì)分配一半資源給這個(gè)小任務(wù)，讓這兩個(gè)任務(wù)公平的共享集群資源。

需要注意的是，在下圖Fair調(diào)度器中，從第二個(gè)任務(wù)提交到獲得資源會(huì)有一定的延遲，因?yàn)樗枰却谝粋€(gè)任務(wù)釋放占用的Container。小任務(wù)執(zhí)行完成之后也會(huì)釋放自己占用的資源，大任務(wù)又獲得了全部的系統(tǒng)資源。最終的效果就是Fair調(diào)度器即得到了高的資源利用率又能保證小任務(wù)及時(shí)完成。

Yarn調(diào)度器對(duì)比圖: 

二、Capacity Scheduler（容器調(diào)度器）的配置

2.1 容器調(diào)度介紹

Capacity 調(diào)度器允許多個(gè)組織共享整個(gè)集群，每個(gè)組織可以獲得集群的一部分計(jì)算能力。通過(guò)為每個(gè)組織分配專門(mén)的隊(duì)列，然后再為每個(gè)隊(duì)列分配一定的集群資源，這樣整個(gè)集群就可以通過(guò)設(shè)置多個(gè)隊(duì)列的方式給多個(gè)組織提供服務(wù)了。除此之外，隊(duì)列內(nèi)部又可以垂直劃分，這樣一個(gè)組織內(nèi)部的多個(gè)成員就可以共享這個(gè)隊(duì)列資源了，在一個(gè)隊(duì)列內(nèi)部，資源的調(diào)度是采用的是先進(jìn)先出(FIFO)策略。

通過(guò)上面那幅圖，我們已經(jīng)知道一個(gè)job可能使用不了整個(gè)隊(duì)列的資源。然而如果這個(gè)隊(duì)列中運(yùn)行多個(gè)job，如果這個(gè)隊(duì)列的資源夠用，那么就分配給這些job，如果這個(gè)隊(duì)列的資源不夠用了呢？其實(shí)Capacity調(diào)度器仍可能分配額外的資源給這個(gè)隊(duì)列，這就是“彈性隊(duì)列”(queue elasticity)的概念。

在正常的操作中，Capacity調(diào)度器不會(huì)強(qiáng)制釋放Container，當(dāng)一個(gè)隊(duì)列資源不夠用時(shí)，這個(gè)隊(duì)列只能獲得其它隊(duì)列釋放后的Container資源。當(dāng)然，我們可以為隊(duì)列設(shè)置一個(gè)最大資源使用量，以免這個(gè)隊(duì)列過(guò)多的占用空閑資源，導(dǎo)致其它隊(duì)列無(wú)法使用這些空閑資源，這就是”彈性隊(duì)列”需要權(quán)衡的地方。

2.2 容器調(diào)度的配置

假設(shè)我們有如下層次的隊(duì)列：

root ├── prod └── dev     ├── eng     └── science 

下面是一個(gè)簡(jiǎn)單的Capacity調(diào)度器的配置文件，文件名為capacity-scheduler.xml。在這個(gè)配置中，在root隊(duì)列下面定義了兩個(gè)子隊(duì)列prod和dev，分別占40%和60%的容量。需要注意，一個(gè)隊(duì)列的配置是通過(guò)屬性yarn.sheduler.capacity.<queue-path>.<sub-property>指定的，<queue-path>代表的是隊(duì)列的繼承樹(shù)，如root.prod隊(duì)列，<sub-property>一般指capacity和maximum-capacity。

我們可以看到，dev隊(duì)列又被分成了eng和science兩個(gè)相同容量的子隊(duì)列。dev的maximum-capacity屬性被設(shè)置成了75%，所以即使prod隊(duì)列完全空閑dev也不會(huì)占用全部集群資源，也就是說(shuō)，prod隊(duì)列仍有25%的可用資源用來(lái)應(yīng)急。我們注意到，eng和science兩個(gè)隊(duì)列沒(méi)有設(shè)置maximum-capacity屬性，也就是說(shuō)eng或science隊(duì)列中的job可能會(huì)用到整個(gè)dev隊(duì)列的所有資源（最多為集群的75%）。而類似的，prod由于沒(méi)有設(shè)置maximum-capacity屬性，它有可能會(huì)占用集群全部資源。

Capacity容器除了可以配置隊(duì)列及其容量外，我們還可以配置一個(gè)用戶或應(yīng)用可以分配的最大資源數(shù)量、可以同時(shí)運(yùn)行多少應(yīng)用、隊(duì)列的ACL認(rèn)證等。

2.3 隊(duì)列的設(shè)置

關(guān)于隊(duì)列的設(shè)置，這取決于我們具體的應(yīng)用。比如，在MapReduce中，我們可以通過(guò)mapreduce.job.queuename屬性指定要用的隊(duì)列。如果隊(duì)列不存在，我們?cè)谔峤蝗蝿?wù)時(shí)就會(huì)收到錯(cuò)誤。如果我們沒(méi)有定義任何隊(duì)列，所有的應(yīng)用將會(huì)放在一個(gè)default隊(duì)列中。

注意：對(duì)于Capacity調(diào)度器，我們的隊(duì)列名必須是隊(duì)列樹(shù)中的最后一部分，如果我們使用隊(duì)列樹(shù)則不會(huì)被識(shí)別。比如，在上面配置中，我們使用prod和eng作為隊(duì)列名是可以的，但是如果我們用root.dev.eng或者dev.eng是無(wú)效的。

三、Fair Scheduler（公平調(diào)度器）的配置

3.1 公平調(diào)度

Fair調(diào)度器的設(shè)計(jì)目標(biāo)是為所有的應(yīng)用分配公平的資源（對(duì)公平的定義可以通過(guò)參數(shù)來(lái)設(shè)置）。在上面的“Yarn調(diào)度器對(duì)比圖”展示了一個(gè)隊(duì)列中兩個(gè)應(yīng)用的公平調(diào)度；當(dāng)然，公平調(diào)度在也可以在多個(gè)隊(duì)列間工作。舉個(gè)例子，假設(shè)有兩個(gè)用戶A和B，他們分別擁有一個(gè)隊(duì)列。當(dāng)A啟動(dòng)一個(gè)job而B(niǎo)沒(méi)有任務(wù)時(shí)，A會(huì)獲得全部集群資源；當(dāng)B啟動(dòng)一個(gè)job后，A的job會(huì)繼續(xù)運(yùn)行，不過(guò)一會(huì)兒之后兩個(gè)任務(wù)會(huì)各自獲得一半的集群資源。如果此時(shí)B再啟動(dòng)第二個(gè)job并且其它job還在運(yùn)行，則它將會(huì)和B的第一個(gè)job共享B這個(gè)隊(duì)列的資源，也就是B的兩個(gè)job會(huì)用于四分之一的集群資源，而A的job仍然用于集群一半的資源，結(jié)果就是資源最終在兩個(gè)用戶之間平等的共享。過(guò)程如下圖所示： 

3.2 啟用Fair Scheduler

調(diào)度器的使用是通過(guò)yarn-site.xml配置文件中的yarn.resourcemanager.scheduler.class參數(shù)進(jìn)行配置的，默認(rèn)采用Capacity Scheduler調(diào)度器。如果我們要使用Fair調(diào)度器，需要在這個(gè)參數(shù)上配置FairScheduler類的全限定名： org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler。

3.3 隊(duì)列的配置

Fair調(diào)度器的配置文件位于類路徑下的fair-scheduler.xml文件中，這個(gè)路徑可以通過(guò)yarn.scheduler.fair.allocation.file屬性進(jìn)行修改。若沒(méi)有這個(gè)配置文件，F(xiàn)air調(diào)度器采用的分配策略，這個(gè)策略和3.1節(jié)介紹的類似：調(diào)度器會(huì)在用戶提交第一個(gè)應(yīng)用時(shí)為其自動(dòng)創(chuàng)建一個(gè)隊(duì)列，隊(duì)列的名字就是用戶名，所有的應(yīng)用都會(huì)被分配到相應(yīng)的用戶隊(duì)列中。

我們可以在配置文件中配置每一個(gè)隊(duì)列，并且可以像Capacity 調(diào)度器一樣分層次配置隊(duì)列。比如，參考capacity-scheduler.xml來(lái)配置fair-scheduler： 

隊(duì)列的層次是通過(guò)嵌套<queue>元素實(shí)現(xiàn)的。所有的隊(duì)列都是root隊(duì)列的孩子，即使我們沒(méi)有配到<root>元素里。在這個(gè)配置中，我們把dev隊(duì)列有分成了eng和science兩個(gè)隊(duì)列。

Fair調(diào)度器中的隊(duì)列有一個(gè)權(quán)重屬性（這個(gè)權(quán)重就是對(duì)公平的定義），并把這個(gè)屬性作為公平調(diào)度的依據(jù)。在這個(gè)例子中，當(dāng)調(diào)度器分配集群40:60資源給prod和dev時(shí)便視作公平，eng和science隊(duì)列沒(méi)有定義權(quán)重，則會(huì)被平均分配。這里的權(quán)重并不是百分比，我們把上面的40和60分別替換成2和3，效果也是一樣的。注意，對(duì)于在沒(méi)有配置文件時(shí)按用戶自動(dòng)創(chuàng)建的隊(duì)列，它們?nèi)杂袡?quán)重并且權(quán)重值為1。

每個(gè)隊(duì)列內(nèi)部仍可以有不同的調(diào)度策略。隊(duì)列的默認(rèn)調(diào)度策略可以通過(guò)頂級(jí)元素<defaultQueueSchedulingPolicy>進(jìn)行配置，如果沒(méi)有配置，默認(rèn)采用公平調(diào)度。

盡管是Fair調(diào)度器，其仍支持在隊(duì)列級(jí)別進(jìn)行FIFO調(diào)度。每個(gè)隊(duì)列的調(diào)度策略可以被其內(nèi)部的<schedulingPolicy> 元素覆蓋，在上面這個(gè)例子中，prod隊(duì)列就被指定采用FIFO進(jìn)行調(diào)度，所以，對(duì)于提交到prod隊(duì)列的任務(wù)就可以按照FIFO規(guī)則順序的執(zhí)行了。需要注意，prod和dev之間的調(diào)度仍然是公平調(diào)度，同樣eng和science也是公平調(diào)度。

盡管上面的配置中沒(méi)有展示，每個(gè)隊(duì)列仍可配置最大、最小資源占用數(shù)和最大可運(yùn)行的應(yīng)用的數(shù)量。

3.4 隊(duì)列的設(shè)置

Fair調(diào)度器采用了一套基于規(guī)則的系統(tǒng)來(lái)確定應(yīng)用應(yīng)該放到哪個(gè)隊(duì)列。在上面的例子中，<queuePlacementPolicy> 元素定義了一個(gè)規(guī)則列表，其中的每個(gè)規(guī)則會(huì)被逐個(gè)嘗試直到匹配成功。例如，上例第一個(gè)規(guī)則specified，則會(huì)把應(yīng)用放到它指定的隊(duì)列中，若這個(gè)應(yīng)用沒(méi)有指定隊(duì)列名或隊(duì)列名不存在，則說(shuō)明不匹配這個(gè)規(guī)則，然后嘗試下一個(gè)規(guī)則。primaryGroup規(guī)則會(huì)嘗試把應(yīng)用放在以用戶所在的Unix組名命名的隊(duì)列中，如果沒(méi)有這個(gè)隊(duì)列，不創(chuàng)建隊(duì)列轉(zhuǎn)而嘗試下一個(gè)規(guī)則。當(dāng)前面所有規(guī)則不滿足時(shí)，則觸發(fā)default規(guī)則，把應(yīng)用放在dev.eng隊(duì)列中。

當(dāng)然，我們可以不配置queuePlacementPolicy規(guī)則，調(diào)度器則默認(rèn)采用如下規(guī)則：

<queuePlacementPolicy> <rule name="specified" /> <rule name="user" /> </queuePlacementPolicy> 

上面規(guī)則可以歸結(jié)成一句話，除非隊(duì)列被準(zhǔn)確的定義，否則會(huì)以用戶名為隊(duì)列名創(chuàng)建隊(duì)列。

還有一個(gè)簡(jiǎn)單的配置策略可以使得所有的應(yīng)用放入同一個(gè)隊(duì)列（default），這樣就可以讓所有應(yīng)用之間平等共享集群而不是在用戶之間。這個(gè)配置的定義如下：

<queuePlacementPolicy> <rule name="default" /> </queuePlacementPolicy> 

實(shí)現(xiàn)上面功能我們還可以不使用配置文件，直接設(shè)置yarn.scheduler.fair.user-as-default-queue=false，這樣應(yīng)用便會(huì)被放入default 隊(duì)列，而不是各個(gè)用戶名隊(duì)列。另外，我們還可以設(shè)置yarn.scheduler.fair.allow-undeclared-pools=false，這樣用戶就無(wú)法創(chuàng)建隊(duì)列了。

3.5 搶占（Preemption）

當(dāng)一個(gè)job提交到一個(gè)繁忙集群中的空隊(duì)列時(shí)，job并不會(huì)馬上執(zhí)行，而是阻塞直到正在運(yùn)行的job釋放系統(tǒng)資源。為了使提交job的執(zhí)行時(shí)間更具預(yù)測(cè)性（可以設(shè)置等待的超時(shí)時(shí)間），F(xiàn)air調(diào)度器支持搶占。

搶占就是允許調(diào)度器殺掉占用超過(guò)其應(yīng)占份額資源隊(duì)列的containers，這些containers資源便可被分配到應(yīng)該享有這些份額資源的隊(duì)列中。需要注意搶占會(huì)降低集群的執(zhí)行效率，因?yàn)楸唤K止的containers需要被重新執(zhí)行。

可以通過(guò)設(shè)置一個(gè)全局的參數(shù)yarn.scheduler.fair.preemption=true來(lái)啟用搶占功能。此外，還有兩個(gè)參數(shù)用來(lái)控制搶占的過(guò)期時(shí)間（這兩個(gè)參數(shù)默認(rèn)沒(méi)有配置，需要至少配置一個(gè)來(lái)允許搶占Container）：

- minimum share preemption timeout - fair share preemption timeout 

如果隊(duì)列在minimum share preemption timeout指定的時(shí)間內(nèi)未獲得最小的資源保障，調(diào)度器就會(huì)搶占containers。我們可以通過(guò)配置文件中的頂級(jí)元素<defaultMinSharePreemptionTimeout>為所有隊(duì)列配置這個(gè)超時(shí)時(shí)間；我們還可以在<queue>元素內(nèi)配置<minSharePreemptionTimeout>元素來(lái)為某個(gè)隊(duì)列指定超時(shí)時(shí)間。

與之類似，如果隊(duì)列在fair share preemption timeout指定時(shí)間內(nèi)未獲得平等的資源的一半（這個(gè)比例可以配置），調(diào)度器則會(huì)進(jìn)行搶占containers。這個(gè)超時(shí)時(shí)間可以通過(guò)頂級(jí)元素<defaultFairSharePreemptionTimeout>和元素級(jí)元素<fairSharePreemptionTimeout>分別配置所有隊(duì)列和某個(gè)隊(duì)列的超時(shí)時(shí)間。上面提到的比例可以通過(guò)<defaultFairSharePreemptionThreshold>(配置所有隊(duì)列)和<fairSharePreemptionThreshold>(配置某個(gè)隊(duì)列)進(jìn)行配置，默認(rèn)是0.5。

posted @ 2017-08-05 00:35 鴻雁 閱讀(360) | 評(píng)論 (0) | 編輯 收藏

hive大數(shù)據(jù)傾斜總結(jié)

在做Shuffle階段的優(yōu)化過(guò)程中，遇到了數(shù)據(jù)傾斜的問(wèn)題，造成了對(duì)一些情況下優(yōu)化效果不明顯。主要是因?yàn)樵贘ob完成后的所得到的Counters是整個(gè)Job的總和，優(yōu)化是基于這些Counters得出的平均值，而由于數(shù)據(jù)傾斜的原因造成map處理數(shù)據(jù)量的差異過(guò)大，使得這些平均值能代表的價(jià)值降低。Hive的執(zhí)行是分階段的，map處理數(shù)據(jù)量的差異取決于上一個(gè)stage的reduce輸出，所以如何將數(shù)據(jù)均勻的分配到各個(gè)reduce中，就是解決數(shù)據(jù)傾斜的根本所在。規(guī)避錯(cuò)誤來(lái)更好的運(yùn)行比解決錯(cuò)誤更高效。在查看了一些資料后，總結(jié)如下。

1數(shù)據(jù)傾斜的原因

1.1操作：

1.2原因：

1)、key分布不均勻

2)、業(yè)務(wù)數(shù)據(jù)本身的特性

3)、建表時(shí)考慮不周

4)、某些SQL語(yǔ)句本身就有數(shù)據(jù)傾斜

1.3表現(xiàn)：

任務(wù)進(jìn)度長(zhǎng)時(shí)間維持在99%（或100%），查看任務(wù)監(jiān)控頁(yè)面，發(fā)現(xiàn)只有少量（1個(gè)或幾個(gè)）reduce子任務(wù)未完成。因?yàn)槠涮幚淼臄?shù)據(jù)量和其他reduce差異過(guò)大。

單一reduce的記錄數(shù)與平均記錄數(shù)差異過(guò)大，通常可能達(dá)到3倍甚至更多。 最長(zhǎng)時(shí)長(zhǎng)遠(yuǎn)大于平均時(shí)長(zhǎng)。

2數(shù)據(jù)傾斜的解決方案

2.1參數(shù)調(diào)節(jié)：

hive.map.aggr=true

Map 端部分聚合，相當(dāng)于Combiner

hive.groupby.skewindata=true

有數(shù)據(jù)傾斜的時(shí)候進(jìn)行負(fù)載均衡，當(dāng)選項(xiàng)設(shè)定為 true，生成的查詢計(jì)劃會(huì)有兩個(gè) MR Job。第一個(gè) MR Job 中，Map 的輸出結(jié)果集合會(huì)隨機(jī)分布到 Reduce 中，每個(gè) Reduce 做部分聚合操作，并輸出結(jié)果，這樣處理的結(jié)果是相同的 Group By Key 有可能被分發(fā)到不同的 Reduce 中，從而達(dá)到負(fù)載均衡的目的；第二個(gè) MR Job 再根據(jù)預(yù)處理的數(shù)據(jù)結(jié)果按照 Group By Key 分布到 Reduce 中（這個(gè)過(guò)程可以保證相同的 Group By Key 被分布到同一個(gè) Reduce 中），最后完成最終的聚合操作。

2.2 SQL語(yǔ)句調(diào)節(jié)：

如何Join：

關(guān)于驅(qū)動(dòng)表的選取，選用join key分布最均勻的表作為驅(qū)動(dòng)表

做好列裁剪和filter操作，以達(dá)到兩表做join的時(shí)候，數(shù)據(jù)量相對(duì)變小的效果。

大小表Join：

使用map join讓小的維度表（1000條以下的記錄條數(shù)） 先進(jìn)內(nèi)存。在map端完成reduce.

大表Join大表：

把空值的key變成一個(gè)字符串加上隨機(jī)數(shù)，把傾斜的數(shù)據(jù)分到不同的reduce上，由于null值關(guān)聯(lián)不上，處理后并不影響最終結(jié)果。

count distinct大量相同特殊值

count distinct時(shí)，將值為空的情況單獨(dú)處理，如果是計(jì)算count distinct，可以不用處理，直接過(guò)濾，在最后結(jié)果中加1。如果還有其他計(jì)算，需要進(jìn)行g(shù)roup by，可以先將值為空的記錄單獨(dú)處理，再和其他計(jì)算結(jié)果進(jìn)行union。

group by維度過(guò)小：

采用sum() group by的方式來(lái)替換count(distinct)完成計(jì)算。

特殊情況特殊處理：

在業(yè)務(wù)邏輯優(yōu)化效果的不大情況下，有些時(shí)候是可以將傾斜的數(shù)據(jù)單獨(dú)拿出來(lái)處理。最后union回去。

3典型的業(yè)務(wù)場(chǎng)景

3.1空值產(chǎn)生的數(shù)據(jù)傾斜

場(chǎng)景：如日志中，常會(huì)有信息丟失的問(wèn)題，比如日志中的 user_id，如果取其中的 user_id 和 用戶表中的user_id 關(guān)聯(lián)，會(huì)碰到數(shù)據(jù)傾斜的問(wèn)題。

解決方法1： user_id為空的不參與關(guān)聯(lián)（紅色字體為修改后）

select * from log a   join users b   on a.user_id is not null   and a.user_id = b.user_id union all select * from log a   where a.user_id is null;

解決方法2 ：賦與空值分新的key值

select *   from log a   left outer join users b   on case when a.user_id is null then concat(‘hive’,rand() ) else a.user_id end = b.user_id;

結(jié)論：方法2比方法1效率更好，不但io少了，而且作業(yè)數(shù)也少了。解決方法1中 log讀取兩次，jobs是2。解決方法2 job數(shù)是1 。這個(gè)優(yōu)化適合無(wú)效 id (比如 -99 , ’’, null 等) 產(chǎn)生的傾斜問(wèn)題。把空值的 key 變成一個(gè)字符串加上隨機(jī)數(shù)，就能把傾斜的數(shù)據(jù)分到不同的reduce上 ,解決數(shù)據(jù)傾斜問(wèn)題。

3.2不同數(shù)據(jù)類型關(guān)聯(lián)產(chǎn)生數(shù)據(jù)傾斜

場(chǎng)景：用戶表中user_id字段為int，log表中user_id字段既有string類型也有int類型。當(dāng)按照user_id進(jìn)行兩個(gè)表的Join操作時(shí)，默認(rèn)的Hash操作會(huì)按int型的id來(lái)進(jìn)行分配，這樣會(huì)導(dǎo)致所有string類型id的記錄都分配到一個(gè)Reducer中。

解決方法：把數(shù)字類型轉(zhuǎn)換成字符串類型

select * from users a   left outer join logs b   on a.usr_id = cast(b.user_id as string)

3.3小表不小不大，怎么用 map join 解決傾斜問(wèn)題

使用 map join 解決小表(記錄數(shù)少)關(guān)聯(lián)大表的數(shù)據(jù)傾斜問(wèn)題，這個(gè)方法使用的頻率非常高，但如果小表很大，大到map join會(huì)出現(xiàn)bug或異常，這時(shí)就需要特別的處理。 以下例子:

select * from log a   left outer join users b   on a.user_id = b.user_id;

users 表有 600w+ 的記錄，把 users 分發(fā)到所有的 map 上也是個(gè)不小的開(kāi)銷，而且 map join 不支持這么大的小表。如果用普通的 join，又會(huì)碰到數(shù)據(jù)傾斜的問(wèn)題。

解決方法：

select /*+mapjoin(x)*/* from log a   
left outer join (     
select  /*+mapjoin(c)*/d.*  from ( 
select distinct user_id from log ) c  join users d       
on c.user_id = d.user_id     ) x   
on a.user_id = b.user_id;  

假如，log里user_id有上百萬(wàn)個(gè)，這就又回到原來(lái)map join問(wèn)題。所幸，每日的會(huì)員uv不會(huì)太多，有交易的會(huì)員不會(huì)太多，有點(diǎn)擊的會(huì)員不會(huì)太多，有傭金的會(huì)員不會(huì)太多等等。所以這個(gè)方法能解決很多場(chǎng)景下的數(shù)據(jù)傾斜問(wèn)題。

4總結(jié)

使map的輸出數(shù)據(jù)更均勻的分布到reduce中去，是我們的最終目標(biāo)。由于Hash算法的局限性，按key Hash會(huì)或多或少的造成數(shù)據(jù)傾斜。大量經(jīng)驗(yàn)表明數(shù)據(jù)傾斜的原因是人為的建表疏忽或業(yè)務(wù)邏輯可以規(guī)避的。在此給出較為通用的步驟：

1、采樣log表，哪些user_id比較傾斜，得到一個(gè)結(jié)果表tmp1。由于對(duì)計(jì)算框架來(lái)說(shuō)，所有的數(shù)據(jù)過(guò)來(lái)，他都是不知道數(shù)據(jù)分布情況的，所以采樣是并不可少的。

2、數(shù)據(jù)的分布符合社會(huì)學(xué)統(tǒng)計(jì)規(guī)則，貧富不均。傾斜的key不會(huì)太多，就像一個(gè)社會(huì)的富人不多，奇特的人不多一樣。所以tmp1記錄數(shù)會(huì)很少。把tmp1和users做map join生成tmp2,把tmp2讀到distribute file cache。這是一個(gè)map過(guò)程。

3、map讀入users和log，假如記錄來(lái)自log,則檢查user_id是否在tmp2里，如果是，輸出到本地文件a,否則生成<user_id,value>的key,value對(duì)，假如記錄來(lái)自member,生成<user_id,value>的key,value對(duì)，進(jìn)入reduce階段。

4、最終把a(bǔ)文件，把Stage3 reduce階段輸出的文件合并起寫(xiě)到hdfs。

如果確認(rèn)業(yè)務(wù)需要這樣傾斜的邏輯，考慮以下的優(yōu)化方案：

1、對(duì)于join，在判斷小表不大于1G的情況下，使用map join

2、對(duì)于group by或distinct，設(shè)定 hive.groupby.skewindata=true

3、盡量使用上述的SQL語(yǔ)句調(diào)節(jié)進(jìn)行優(yōu)化

posted @ 2017-07-31 19:57 鴻雁 閱讀(184) | 評(píng)論 (0) | 編輯 收藏