這篇文章將為大家詳細(xì)講解有關(guān)Spark Streaming+Spark SQL的數(shù)據(jù)傾斜示例分析，文章內(nèi)容質(zhì)量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關(guān)知識有一定的了解。

從事綿陽服務(wù)器托管，服務(wù)器租用，云主機(jī)，網(wǎng)頁空間，域名與空間，CDN，網(wǎng)絡(luò)代維等服務(wù)。

1.現(xiàn)象

三臺機(jī)器都有產(chǎn)生executor，每臺都會產(chǎn)生tasks，但是其中只有一臺的task有input數(shù)據(jù)，其他機(jī)器的tasks都沒有數(shù)據(jù)。



2.猜想
2.1是不是數(shù)據(jù)傾斜?
是

2.2是數(shù)據(jù)量過大，group by時，導(dǎo)致key分布不均?
比如key1 有98萬，key2有2萬,那么shuffle時，肯定數(shù)據(jù)傾斜。但是我剛開始數(shù)據(jù)量不是很大，所以pass  （就算數(shù)據(jù)量大，也很簡單處理，一般處理時key加上隨機(jī)前綴數(shù)）

2.3是不是數(shù)據(jù)量太少 不夠分區(qū)的？
也懷疑過，不過還沒去驗證

2.4 flume流到kafka，是snappy壓縮格式，而spark作為kafka的消費者，雖然能夠自動識別壓縮格式，但是這種snappy格式不支持切分
也懷疑過，不過還沒去修改支持spilt的壓縮格式，也還沒去驗證

2.5 spark streaming分區(qū)數(shù)目是有誰決定的?
使用direct這種模式是由kafka的分區(qū)數(shù)目決定，
使用receiver這種模式由流的數(shù)目決定也就是由receiver數(shù)目決定。

3.修改分區(qū)數(shù)
[root@sht-sgmhadoopdn-02 kafka]#bin/kafka-topics.sh --alter  --zookeeper 172.16.101.58:2181,172.16.101.59:2181,172.16.101.60:2181/kafka --topic logtopic --partitions 3
[root@sht-sgmhadoopdn-02 kafka]# bin/kafka-topics.sh --describe --zookeeper 172.16.101.58:2181,172.16.101.59:2181,172.16.101.60:2181/kafka --topic logtopic
Topic:logtopic      PartitionCount:3        ReplicationFactor:3     Configs:
        Topic: test     Partition: 0    Leader: 3       Replicas: 3,1,2 Isr: 3,1,2
        Topic: test     Partition: 1    Leader: 1       Replicas: 1,2,3 Isr: 1,2,3
        Topic: test     Partition: 2    Leader: 2       Replicas: 2,3,1 Isr: 2,3,1
[root@sht-sgmhadoopdn-02 kafka]#

4.驗證(每個executor都有input數(shù)據(jù))

關(guān)于Spark Streaming+Spark SQL的數(shù)據(jù)傾斜示例分析就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學(xué)到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。

當(dāng)前標(biāo)題：SparkStreaming+SparkSQL的數(shù)據(jù)傾斜示例分析-創(chuàng)新互聯(lián)
標(biāo)題路徑：http://weahome.cn/article/gshsp.html