上篇文章啰里啰嗦說了那么多，不知道大家理解的怎么樣！寫本文也是銜接上篇文章繼續(xù)學(xué)習(xí)以便加深對Flink原理的理解。接下來主要是梳理一下-p, -yn 和實(shí)際Flink作業(yè)提交成功之后生成TaskManager的個(gè)數(shù)之間的關(guān)系。
繼續(xù)往下看?
①yn參數(shù)官網(wǎng)解釋： -yn,--yarncontainer <arg> Number of YARN container to allocate (=Number of Task Managers)。按照這個(gè)參數(shù)解釋，那就是我們設(shè)置了job中有多少個(gè)TaskManagers，但是事實(shí)是不是這樣的呢？？？？那看一下下面提交的job:
flink run \
-m yarn-cluster \
-ynm AliyunNginxStudy20190328 \
-yn 3 \
-ys 3 \
-p 3 \
-yjm 2048m \
-ytm 8192m \
-c --classpath /opt/jars/online_aliyun_ls_parse_nginx_test.jar \
--output ${elasticsearch} \
--ipDbPath /opt/lib/ \
--windowSize 10
下圖是具體提交到y(tǒng)arn上，F(xiàn)link最終TaskManagers和Task Slots的數(shù)量情況。
圖8
通過上面圖8的反應(yīng)的情況，證明-yn并不能決定TaskManager的數(shù)量。其實(shí)在flink-1.7版本提交任務(wù)的時(shí)候就可以通過日志信息發(fā)現(xiàn)這個(gè)參數(shù)是棄用的。flink-1.6日志雖然沒有提醒，但該參數(shù)也是處于廢棄狀態(tài)。
v-1.7
flink-1.7
v-1.6
flink-1.6
繼續(xù)往下看>>>>>>
說到底還是確定不了TaskManager最終的數(shù)量誰來決定的，通過親自測試得到圖9的結(jié)果，測試中flink配置文件中的默認(rèn)并行度是1(parallelism.default: 1)，代碼中沒有單獨(dú)設(shè)置operators的并行度。
yn(實(shí)際) = Math.ceil(p/ys)
ys(總共) = yn(實(shí)際) * ys(指定)
ys(使用) = p(指定)
下圖中的腳本指定參數(shù)是指我們提交flink任務(wù)指定的，實(shí)際參數(shù)情況是指flink 任務(wù)提交成功之后所產(chǎn)生的。
圖9
為了驗(yàn)證上面的說法，咱們繼續(xù)提交一個(gè)job來去測試。如果網(wǎng)友有時(shí)間可以實(shí)際操作一下。
flink run \
-m yarn-cluster \
-ynm AliyunNginxStudy20190328 \
-yn 3 \
-ys 2 \
-p 3 \
-yjm 2048m \
-ytm 8192m \
-c --classpath /opt/jars/online_aliyun_ls_parse_nginx_test.jar \
--output ${elasticsearch} \
--ipDbPath /opt/lib/ \
--windowSize 10
下圖可以清楚的看到，實(shí)際的TaskManagers數(shù)和Task Slots數(shù)驗(yàn)證了上面所說的。
圖10
