前言在大數(shù)據(jù)分布式中，分區(qū)，分桶，分片是設(shè)計(jì)框架的重點(diǎn)。此篇就來(lái)總結(jié)各個(gè)框架。建議收藏

目錄

Hive分區(qū)與分桶

ES分片

Kafka分區(qū)

HBase分區(qū)

Kudu分區(qū)

HiveHive分區(qū)

是按照數(shù)據(jù)表的某列或者某些列分為多區(qū)，在hive存儲(chǔ)上是hdfs文件，也就是文件夾形式。現(xiàn)在最常用的跑T+1數(shù)據(jù)，按當(dāng)天時(shí)間分區(qū)的較多。

把每天通過(guò)sqoop或者datax拉取的一天的數(shù)據(jù)存儲(chǔ)一個(gè)區(qū)，也就是所謂的文件夾與文件。在查詢時(shí)只要指定分區(qū)字段的值就可以直接從該分區(qū)查找即可。創(chuàng)建分區(qū)表的時(shí)候，要通過(guò)關(guān)鍵字 partitioned by （column name string）聲明該表是分區(qū)表，并且是按照字段column name進(jìn)行分區(qū)，column name值一致的所有記錄存放在一個(gè)分區(qū)中，分區(qū)屬性name的類(lèi)型是string類(lèi)型。

當(dāng)然，可以依據(jù)多個(gè)列進(jìn)行分區(qū)，即對(duì)某個(gè)分區(qū)的數(shù)據(jù)按照某些列繼續(xù)分區(qū)。

向分區(qū)表導(dǎo)入數(shù)據(jù)的時(shí)候，要通過(guò)關(guān)鍵字partition（（column name=“xxxx”）顯示聲明數(shù)據(jù)要導(dǎo)入到表的哪個(gè)分區(qū)

設(shè)置分區(qū)的影響

首先是hive本身對(duì)分區(qū)數(shù)有限制，不過(guò)可以修改限制的數(shù)量；

set hive.exec.dynamic.partition=true;

set hive.exec.max.dynamic.partitions=1000;

set hive.exec.dynamic.partition.mode=nonstrict;

set hive.exec.parallel.thread.number=264;

hdfs對(duì)單個(gè)目錄下的目錄數(shù)量或者文件數(shù)量也是有限制的，也是可以修改的；

NN的內(nèi)存肯定會(huì)限制，這是最重要的，如果分區(qū)數(shù)很大，會(huì)影響NN服務(wù)，進(jìn)而影響一系列依賴于NN的服務(wù)。所以最好合理設(shè)置分區(qū)規(guī)則，對(duì)小文件也可以定期合并，減少NN的壓力。

Hive分桶

在分區(qū)數(shù)量過(guò)于龐大以至于可能導(dǎo)致文件系統(tǒng)崩潰時(shí)，我們就需要使用分桶來(lái)解決問(wèn)題

分桶是相對(duì)分區(qū)進(jìn)行更細(xì)粒度的劃分。分桶則是指定分桶表的某一列，讓該列數(shù)據(jù)按照哈希取模的方式隨機(jī)、均勻的分發(fā)到各個(gè)桶文件中。因?yàn)榉滞安僮餍枰鶕?jù)某一列具體數(shù)據(jù)來(lái)進(jìn)行哈希取模操作，故指定的分桶列必須基于表中的某一列（字段）要使用關(guān)鍵字clustered by 指定分區(qū)依據(jù)的列名，還要指定分為多少桶

create table test（id int，name string） cluster by （id） into 5 buckets 。..。..。

insert into buck select id ，name from p cluster by （id）

Hive分區(qū)分桶區(qū)別

分區(qū)是表的部分列的集合，可以為頻繁使用的數(shù)據(jù)建立分區(qū)，這樣查找分區(qū)中的數(shù)據(jù)時(shí)就不需要掃描全表，這對(duì)于提高查找效率很有幫助

不同于分區(qū)對(duì)列直接進(jìn)行拆分，桶往往使用列的哈希值對(duì)數(shù)據(jù)打散，并分發(fā)到各個(gè)不同的桶中從而完成數(shù)據(jù)的分桶過(guò)程

分區(qū)和分桶最大的區(qū)別就是分桶隨機(jī)分割數(shù)據(jù)庫(kù)，分區(qū)是非隨機(jī)分割數(shù)據(jù)庫(kù)

ElasticSearch分片主分片：用于解決數(shù)據(jù)水平擴(kuò)展的問(wèn)題，一個(gè)索引的所有數(shù)據(jù)是分布在所有主分片之上的（每個(gè)主分片承擔(dān)一部分?jǐn)?shù)據(jù)，主分片又分布在不同的節(jié)點(diǎn)上），一個(gè)索引的主分片數(shù)量只能在創(chuàng)建時(shí)指定，后期無(wú)法修改，除非對(duì)數(shù)據(jù)進(jìn)行重新構(gòu)建索引（reindex操作）。

副本分片：用于解決數(shù)據(jù)高可用的問(wèn)題，一個(gè)副本分片即一個(gè)主分片的拷貝，其數(shù)量可以動(dòng)態(tài)調(diào)整，通過(guò)增加副本分片也可以實(shí)現(xiàn)提升系統(tǒng)讀性能的作用。

在集群中唯一一個(gè)空節(jié)點(diǎn)上創(chuàng)建一個(gè)叫做 blogs 的索引。默認(rèn)情況下，一個(gè)索引被分配 5 個(gè)主分片

{

“settings”： {

“number_of_shards”： 5，

“number_of_replicas”： 1

}

}

到底分配到那個(gè)shard上呢？

shard = hash（routing） % number_of_primary_shards

routing 是一個(gè)可變值，默認(rèn)是文檔的 _id ，也可以設(shè)置成一個(gè)自定義的值。routing 通過(guò) hash 函數(shù)生成一個(gè)數(shù)字，然后這個(gè)數(shù)字再除以 number_of_primary_shards （主分片的數(shù)量）后得到余數(shù) 。這個(gè)在 0 到 number_of_primary_shards 之間的余數(shù)，就是所尋求的文檔所在分片的位置。

如果數(shù)量變化了，那么所有之前路由的值都會(huì)無(wú)效，文檔也再也找不到了

分片過(guò)少如15個(gè)節(jié)點(diǎn)，5個(gè)主分片，1個(gè)副本會(huì)造成每個(gè)索引最多只能使用10個(gè)節(jié)點(diǎn)（5個(gè)主分片，5個(gè)從分片），剩余5節(jié)點(diǎn)并沒(méi)有利用上；資源浪費(fèi)如：3節(jié)點(diǎn)；3分主分片，1副本當(dāng)數(shù)據(jù)量較大的時(shí)，每個(gè)分片就會(huì)比較大

分片過(guò)多

創(chuàng)建分片慢：es創(chuàng)建分片的速度會(huì)隨著集群內(nèi)分片數(shù)的增加而變慢。

集群易崩潰：在觸發(fā)es 自動(dòng)創(chuàng)建Index時(shí)，由于創(chuàng)建速度太慢，容易導(dǎo)致大量寫(xiě)入請(qǐng)求堆積在內(nèi)存，從而壓垮集群。

寫(xiě)入拒絕：分片過(guò)多的場(chǎng)景中，如果不能及時(shí)掌控業(yè)務(wù)的變化，可能經(jīng)常遇到單分片記錄超限、寫(xiě)入拒絕等問(wèn)題。

分片的注意事項(xiàng)

避免使用非常大的分片，因?yàn)檫@會(huì)對(duì)群集從故障中恢復(fù)的能力產(chǎn)生負(fù)面影響。對(duì)分片的大小沒(méi)有固定的限制，但是通常情況下很多場(chǎng)景限制在 30GB 的分片大小以內(nèi)。

當(dāng)在ElasticSearch集群中配置好你的索引后， 你要明白在集群運(yùn)行中你無(wú)法調(diào)整分片設(shè)置。 既便以后你發(fā)現(xiàn)需要調(diào)整分片數(shù)量， 你也只能新建創(chuàng)建并對(duì)數(shù)據(jù)進(jìn)行重新索引。

如果擔(dān)心數(shù)據(jù)的快速增長(zhǎng)， 建議根據(jù)這條限制： ElasticSearch推薦的最大JVM堆空間 是 30~32G， 所以把分片最大容量限制為 30GB， 然后再對(duì)分片數(shù)量做合理估算。例如， 如果的數(shù)據(jù)能達(dá)到 200GB， 則最多分配7到8個(gè)分片。

kafka分區(qū)生產(chǎn)者

分區(qū)的原因

方便在集群中擴(kuò)展，每個(gè)Partition可以通過(guò)調(diào)整以適應(yīng)它所在的機(jī)器，而一個(gè)topic又可以有多個(gè)Partition組成，因此整個(gè)集群就可以適應(yīng)任意大小的數(shù)據(jù)了；

可以提高并發(fā)，因?yàn)榭梢砸訮artition為單位讀寫(xiě)了。

分區(qū)的原則

指明 partition 的情況下，直接將指明的值直接作為 partiton 值；

沒(méi)有指明 partition 值但有 key 的情況下，將 key 的 hash 值與 topic 的 partition 數(shù)進(jìn)行取余得到 partition 值；

既沒(méi)有 partition 值又沒(méi)有 key 值的情況下，第一次調(diào)用時(shí)隨機(jī)生成一個(gè)整數(shù)（后面每次調(diào)用在這個(gè)整數(shù)上自增），將這個(gè)值與 topic 可用的 partition 總數(shù)取余得到 partition 值，也就是常說(shuō)的 round-robin 算法。

消費(fèi)者

分區(qū)分配策略

一個(gè)consumer group中有多個(gè)consumer，一個(gè) topic有多個(gè)partition，所以必然會(huì)涉及到partition的分配問(wèn)題，即確定那個(gè)partition由哪個(gè)consumer來(lái)消費(fèi)Kafka有三種分配策略，一是RoundRobin，一是Range。高版本還有一個(gè)StickyAssignor策略將分區(qū)的所有權(quán)從一個(gè)消費(fèi)者移到另一個(gè)消費(fèi)者稱為重新平衡（rebalance）。當(dāng)以下事件發(fā)生時(shí)，Kafka 將會(huì)進(jìn)行一次分區(qū)分配：

同一個(gè) Consumer Group 內(nèi)新增消費(fèi)者

消費(fèi)者離開(kāi)當(dāng)前所屬的Consumer Group，包括shuts down 或 crashes

Range分區(qū)分配策略

Range是對(duì)每個(gè)Topic而言的（即一個(gè)Topic一個(gè)Topic分），首先對(duì)同一個(gè)Topic里面的分區(qū)按照序號(hào)進(jìn)行排序，并對(duì)消費(fèi)者按照字母順序進(jìn)行排序。然后用Partitions分區(qū)的個(gè)數(shù)除以消費(fèi)者線程的總數(shù)來(lái)決定每個(gè)消費(fèi)者線程消費(fèi)幾個(gè)分區(qū)。如果除不盡，那么前面幾個(gè)消費(fèi)者線程將會(huì)多消費(fèi)一個(gè)分區(qū)。假設(shè)n=分區(qū)數(shù)/消費(fèi)者數(shù)量，m=分區(qū)數(shù)%消費(fèi)者數(shù)量，那么前m個(gè)消費(fèi)者每個(gè)分配n+1個(gè)分區(qū)，后面的（消費(fèi)者數(shù)量-m）個(gè)消費(fèi)者每個(gè)分配n個(gè)分區(qū)。假如有10個(gè)分區(qū)，3個(gè)消費(fèi)者線程，把分區(qū)按照序號(hào)排列

0，1，2，3，4，5，6，7，8，9

消費(fèi)者線程為

C1-0，C2-0，C2-1

那么用partition數(shù)除以消費(fèi)者線程的總數(shù)來(lái)決定每個(gè)消費(fèi)者線程消費(fèi)幾個(gè)partition，如果除不盡，前面幾個(gè)消費(fèi)者將會(huì)多消費(fèi)一個(gè)分區(qū)。在我們的例子里面，我們有10個(gè)分區(qū)，3個(gè)消費(fèi)者線程，10/3 = 3，而且除除不盡，那么消費(fèi)者線程C1-0將會(huì)多消費(fèi)一個(gè)分區(qū)，所以最后分區(qū)分配的結(jié)果看起來(lái)是這樣的：

C1-0：0，1，2，3

C2-0：4，5，6

C2-1：7，8，9

如果有11個(gè)分區(qū)將會(huì)是：

C1-0：0，1，2，3

C2-0：4，5，6，7

C2-1：8，9，10

假如我們有兩個(gè)主題T1，T2，分別有10個(gè)分區(qū)，最后的分配結(jié)果將會(huì)是這樣：

C1-0：T1（0，1，2，3） T2（0，1，2，3）

C2-0：T1（4，5，6） T2（4，5，6）

C2-1：T1（7，8，9） T2（7，8，9）

RoundRobinAssignor分區(qū)分配策略

RoundRobinAssignor策略的原理是將消費(fèi)組內(nèi)所有消費(fèi)者以及消費(fèi)者所訂閱的所有topic的partition按照字典序排序，然后通過(guò)輪詢方式逐個(gè)將分區(qū)以此分配給每個(gè)消費(fèi)者。使用RoundRobin策略有兩個(gè)前提條件必須滿足：

同一個(gè)消費(fèi)者組里面的所有消費(fèi)者的num.streams（消費(fèi)者消費(fèi)線程數(shù)）必須相等；

每個(gè)消費(fèi)者訂閱的主題必須相同。

加入按照 hashCode 排序完的topic-partitions組依次為

T1-5， T1-3， T1-0， T1-8， T1-2， T1-1， T1-4， T1-7， T1-6， T1-9

我們的消費(fèi)者線程排序?yàn)?/p>

C1-0， C1-1， C2-0， C2-1

最后分區(qū)分配的結(jié)果為：

C1-0 將消費(fèi) T1-5， T1-2， T1-6 分區(qū)

C1-1 將消費(fèi) T1-3， T1-1， T1-9 分區(qū)

C2-0 將消費(fèi) T1-0， T1-4 分區(qū)

C2-1 將消費(fèi) T1-8， T1-7 分區(qū)

StickyAssignor分區(qū)分配策略

Kafka從0.11.x版本開(kāi)始引入這種分配策略，它主要有兩個(gè)目的：

分區(qū)的分配要盡可能的均勻，分配給消費(fèi)者者的主題分區(qū)數(shù)最多相差一個(gè)

分區(qū)的分配盡可能的與上次分配的保持相同。

當(dāng)兩者發(fā)生沖突時(shí)，第一個(gè)目標(biāo)優(yōu)先于第二個(gè)目標(biāo)。鑒于這兩個(gè)目的，StickyAssignor策略的具體實(shí)現(xiàn)要比RangeAssignor和RoundRobinAssignor這兩種分配策略要復(fù)雜很多。

假設(shè)消費(fèi)組內(nèi)有3個(gè)消費(fèi)者

C0、C1、C2

它們都訂閱了4個(gè)主題：

t0、t1、t2、t3

并且每個(gè)主題有2個(gè)分區(qū)，也就是說(shuō)整個(gè)消費(fèi)組訂閱了

t0p0、t0p1、t1p0、t1p1、t2p0、t2p1、t3p0、t3p1這8個(gè)分區(qū)

最終的分配結(jié)果如下：

消費(fèi)者C0：t0p0、t1p1、t3p0

消費(fèi)者C1：t0p1、t2p0、t3p1

消費(fèi)者C2：t1p0、t2p1

這樣初看上去似乎與采用RoundRobinAssignor策略所分配的結(jié)果相同

此時(shí)假設(shè)消費(fèi)者C1脫離了消費(fèi)組，那么消費(fèi)組就會(huì)執(zhí)行再平衡操作，進(jìn)而消費(fèi)分區(qū)會(huì)重新分配。如果采用RoundRobinAssignor策略，那么此時(shí)的分配結(jié)果如下：

消費(fèi)者C0：t0p0、t1p0、t2p0、t3p0

消費(fèi)者C2：t0p1、t1p1、t2p1、t3p1

如分配結(jié)果所示，RoundRobinAssignor策略會(huì)按照消費(fèi)者C0和C2進(jìn)行重新輪詢分配。而如果此時(shí)使用的是StickyAssignor策略，那么分配結(jié)果為：

消費(fèi)者C0：t0p0、t1p1、t3p0、t2p0

消費(fèi)者C2：t1p0、t2p1、t0p1、t3p1

可以看到分配結(jié)果中保留了上一次分配中對(duì)于消費(fèi)者C0和C2的所有分配結(jié)果，并將原來(lái)消費(fèi)者C1的“負(fù)擔(dān)”分配給了剩余的兩個(gè)消費(fèi)者C0和C2，最終C0和C2的分配還保持了均衡。

如果發(fā)生分區(qū)重分配，那么對(duì)于同一個(gè)分區(qū)而言有可能之前的消費(fèi)者和新指派的消費(fèi)者不是同一個(gè)，對(duì)于之前消費(fèi)者進(jìn)行到一半的處理還要在新指派的消費(fèi)者中再次復(fù)現(xiàn)一遍，這顯然很浪費(fèi)系統(tǒng)資源。StickyAssignor策略如同其名稱中的“sticky”一樣，讓分配策略具備一定的“粘性”，盡可能地讓前后兩次分配相同，進(jìn)而減少系統(tǒng)資源的損耗以及其它異常情況的發(fā)生。

到目前為止所分析的都是消費(fèi)者的訂閱信息都是相同的情況，我們來(lái)看一下訂閱信息不同的情況下的處理。

舉例，同樣消費(fèi)組內(nèi)有3個(gè)消費(fèi)者：

C0、C1、C2

集群中有3個(gè)主題：

t0、t1、t2

這3個(gè)主題分別有

1、2、3個(gè)分區(qū)

也就是說(shuō)集群中有

t0p0、t1p0、t1p1、t2p0、t2p1、t2p2這6個(gè)分區(qū)

消費(fèi)者C0訂閱了主題t0

消費(fèi)者C1訂閱了主題t0和t1

消費(fèi)者C2訂閱了主題t0、t1和t2

如果此時(shí)采用RoundRobinAssignor策略：

消費(fèi)者C0：t0p0

消費(fèi)者C1：t1p0

消費(fèi)者C2：t1p1、t2p0、t2p1、t2p2

如果此時(shí)采用的是StickyAssignor策略：

消費(fèi)者C0：t0p0

消費(fèi)者C1：t1p0、t1p1

消費(fèi)者C2：t2p0、t2p1、t2p2

此時(shí)消費(fèi)者C0脫離了消費(fèi)組，那么RoundRobinAssignor策略的分配結(jié)果為：

消費(fèi)者C1：t0p0、t1p1

消費(fèi)者C2：t1p0、t2p0、t2p1、t2p2

StickyAssignor策略，那么分配結(jié)果為：

消費(fèi)者C1：t1p0、t1p1、t0p0

消費(fèi)者C2：t2p0、t2p1、t2p2

可以看到StickyAssignor策略保留了消費(fèi)者C1和C2中原有的5個(gè)分區(qū)的分配：

t1p0、t1p1、t2p0、t2p1、t2p2。

從結(jié)果上看StickyAssignor策略比另外兩者分配策略而言顯得更加的優(yōu)異，這個(gè)策略的代碼實(shí)現(xiàn)也是異常復(fù)雜。

注意

在實(shí)際開(kāi)發(fā)過(guò)程中，kafka與spark或者flink對(duì)接的較多，一個(gè)分區(qū)對(duì)應(yīng)的是一個(gè)并行度，如果并行度不夠，這個(gè)時(shí)候會(huì)多個(gè)分區(qū)數(shù)據(jù)集中到一個(gè)并行度上。所以需要合理設(shè)置并行度

HBase分區(qū)HBase每張表在底層存儲(chǔ)上是由至少一個(gè)Region組成，Region實(shí)際上就是HBase表的分區(qū)。HBase新建一張表時(shí)默認(rèn)Region即分區(qū)的數(shù)量為1，一般在生產(chǎn)環(huán)境中我們都會(huì)手動(dòng)給Table提前做 “預(yù)分區(qū)”，使用合適的分區(qū)策略創(chuàng)建好一定數(shù)量的分區(qū)并使分區(qū)均勻分布在不同regionserver上。一個(gè)分區(qū)在達(dá)到一定大小時(shí)會(huì)自動(dòng)Split，一分為二

HBase分區(qū)過(guò)多有哪些影響：

頻繁刷寫(xiě)：我們知道Region的一個(gè)列族對(duì)應(yīng)一個(gè)MemStore，假設(shè)HBase表都有統(tǒng)一的1個(gè)列族配置，則每個(gè)Region只包含一個(gè)MemStore。通常HBase的一個(gè)MemStore默認(rèn)大小為128 MB，見(jiàn)參數(shù)hbase.hregion.memstore.flush.size。當(dāng)可用內(nèi)存足夠時(shí)，每個(gè)MemStore可以分配128 MB空間。當(dāng)可用內(nèi)存緊張時(shí)，假設(shè)每個(gè)Region寫(xiě)入壓力相同，則理論上每個(gè)MemStore會(huì)平均分配可用內(nèi)存空間。因此，當(dāng)節(jié)點(diǎn)Region過(guò)多時(shí)，每個(gè)MemStore分到的內(nèi)存空間就會(huì)很小。這個(gè)時(shí)候，寫(xiě)入很小的數(shù)據(jù)量就會(huì)被強(qiáng)制Flush到磁盤(pán)，將會(huì)導(dǎo)致頻繁刷寫(xiě)。頻繁刷寫(xiě)磁盤(pán)，會(huì)對(duì)集群HBase與HDFS造成很大的壓力，可能會(huì)導(dǎo)致不可預(yù)期的嚴(yán)重后果。

壓縮風(fēng)暴：因Region過(guò)多導(dǎo)致的頻繁刷寫(xiě)，將在磁盤(pán)上產(chǎn)生非常多的HFile小文件，當(dāng)小文件過(guò)多的時(shí)候HBase為了優(yōu)化查詢性能就會(huì)做Compaction操作，合并HFile減少文件數(shù)量。當(dāng)小文件一直很多的時(shí)候，就會(huì)出現(xiàn) “壓縮風(fēng)暴”。Compaction非常消耗系統(tǒng)io資源，還會(huì)降低數(shù)據(jù)寫(xiě)入的速度，嚴(yán)重的會(huì)影響正常業(yè)務(wù)的進(jìn)行。

MSLAB內(nèi)存消耗較大：MSLAB（MemStore-local allocation buffer）存在于每個(gè)MemStore中，主要是為了解決HBase內(nèi)存碎片問(wèn)題，默認(rèn)會(huì)分配 2 MB 的空間用于緩存最新數(shù)據(jù)。如果Region數(shù)量過(guò)多，MSLAB總的空間占用就會(huì)比較大。比如當(dāng)前節(jié)點(diǎn)有1000個(gè)包含1個(gè)列族的Region，MSLAB就會(huì)使用1.95GB的堆內(nèi)存，即使沒(méi)有數(shù)據(jù)寫(xiě)入也會(huì)消耗這么多內(nèi)存。

Master assign region時(shí)間較長(zhǎng)：HBase Region過(guò)多時(shí)Master分配Region的時(shí)間將會(huì)很長(zhǎng)。特別體現(xiàn)在重啟HBase時(shí)Region上線時(shí)間較長(zhǎng)，嚴(yán)重的會(huì)達(dá)到小時(shí)級(jí)，造成業(yè)務(wù)長(zhǎng)時(shí)間等待的后果。

影響MapReduce并發(fā)數(shù)：當(dāng)使用MapReduce操作HBase時(shí)，通常Region數(shù)量就是MapReduce的任務(wù)數(shù)，Region數(shù)量過(guò)多會(huì)導(dǎo)致并發(fā)數(shù)過(guò)多，產(chǎn)生過(guò)多的任務(wù)。任務(wù)太多將會(huì)占用大量資源，當(dāng)操作包含很多Region的大表時(shí)，占用過(guò)多資源會(huì)影響其他任務(wù)的執(zhí)行。

具體計(jì)算HBase合理分區(qū)數(shù)量

（（RS memory） * （total memstore fraction）） / （（memstore size）*（column families））

字段解釋

RS memory表示regionserver堆內(nèi)存大小，即HBASE_HEAPSIZE

total memstore fraction表示所有MemStore占HBASE_HEAPSIZE的比例，HBase0.98版本以后由hbase.regionserver.global.memstore.size參數(shù)控制，老版本由hbase.regionserver.global.memstore.upperLimit參數(shù)控制，默認(rèn)值0.4

memstore size即每個(gè)MemStore的大小，原生HBase中默認(rèn)128M

column families即表的列族數(shù)量，通常情況下只設(shè)置1個(gè)，最多不超過(guò)3個(gè)

假如一個(gè)集群中每個(gè)regionserver的堆內(nèi)存是32GB，那么節(jié)點(diǎn)上最理想的Region數(shù)量應(yīng)該是32768*0.4/128 ≈ 102，所以，當(dāng)前環(huán)境中單節(jié)點(diǎn)理想情況下大概有102個(gè)Region最理想情況是假設(shè)每個(gè)Region上的填充率都一樣，包括數(shù)據(jù)寫(xiě)入的頻次、寫(xiě)入數(shù)據(jù)的大小，但實(shí)際上每個(gè)Region的負(fù)載各不相同，可能有的Region特別活躍負(fù)載特別高，有的Region則比較空閑。所以，通常我們認(rèn)為2-3倍的理想Region數(shù)量也是比較合理的，針對(duì)上面舉例來(lái)說(shuō)，大概200-300個(gè)Region算是合理的。

如果實(shí)際的Region數(shù)量比2~3倍的計(jì)算值還要多，就要實(shí)際觀察Region的刷寫(xiě)、壓縮情況了，Region越多則風(fēng)險(xiǎn)越大。經(jīng)驗(yàn)告訴我們，如果單節(jié)點(diǎn)Region數(shù)量過(guò)千，集群可能存在較大風(fēng)險(xiǎn)

Kudu分區(qū)為了提供可擴(kuò)展性，Kudu 表被劃分為稱為 tablets 的單元，并分布在許多 tablet servers 上。行總是屬于單個(gè) tablet 。將行分配給 tablet 的方法由在表創(chuàng)建期間設(shè)置的表的分區(qū)決定。kudu提供了3種分區(qū)方式：

Range Partitioning（范圍分區(qū)）范圍分區(qū)可以根據(jù)存入數(shù)據(jù)的數(shù)據(jù)量，均衡的存儲(chǔ)到各個(gè)機(jī)器上，防止機(jī)器出現(xiàn)負(fù)載不均衡現(xiàn)象

create table people（id Type.INT32， name Type.STRING ， age Type.INT32）

RANGE （age） （

PARTITION 0 <= VALUES < 10，

PARTITION 10 <= VALUES < 20，

PARTITION 20 <= VALUES < 30，

PARTITION 30 <= VALUES < 40，

PARTITION 40 <= VALUES < 50，

PARTITION 50 <= VALUES < 60，

PARTITION 60 <= VALUES < 70，

PARTITION 70 <= VALUES < 80，

PARTITION 80 <= VALUES < 120

）

Hash Partitioning（哈希分區(qū)）哈希分區(qū)通過(guò)哈希值將行分配到許多 buckets （ 存儲(chǔ)桶 ）之一；哈希分區(qū)是一種有效的策略，當(dāng)不需要對(duì)表進(jìn)行有序訪問(wèn)時(shí)。哈希分區(qū)對(duì)于在 tablet 之間隨機(jī)散布這些功能是有效的，這有助于減輕熱點(diǎn)和 tablet 大小不均勻。

create table rangeTable（id Type.INT32， name Type.STRING ， age Type.INT32）

HASH （id） PARTITIONS 5，

RANGE （id） （

PARTITION UNBOUNDED

）

Multilevel Partitioning（多級(jí)分區(qū)）

create table rangeTable（id Type.INT32， name Type.STRING ， age Type.INT32）

HASH （age） PARTITIONS 5，

RANGE （age） （

PARTITION 0 <= VALUES < 10，

PARTITION 10 <= VALUES < 20，

PARTITION 20 <= VALUES < 30，

PARTITION 30 <= VALUES < 40，

PARTITION 40 <= VALUES < 50，

PARTITION 50 <= VALUES < 60，

PARTITION 60 <= VALUES < 70，

PARTITION 70 <= VALUES < 80，

PARTITION 80 <= VALUES < 120

哈希分區(qū)有利于最大限度地提高寫(xiě)入吞吐量，而范圍分區(qū)可避免 tablet 無(wú)限增長(zhǎng)的問(wèn)題；hash分區(qū)和range分區(qū)結(jié)合，可以極大提升kudu性能。

責(zé)任編輯：haq