步骤一:创建HBase表 #创建表create 'my_table', {NAME => 'cf', SALT_BUCKETS => 10} 1. 2. 这段代码将创建一个名为my_table的HBase表,并设置SALT_BUCKETS为10,表示将数据分散到10个桶中。 步骤二:设置SALT_BUCKETS #修改表属性alter 'my_table', METHOD => 'table_att', 'SALT_BUCKETS' => ...
SALT_BUCKETS 定义了盐值的数量,决定了数据的分散程度。 getSaltedRowKey 方法通过行键的哈希值生成盐值,拼接到原始行键前面,打乱了行键的顺序。 这种设计确保了写入的数据可以均匀分布在不同的Region上,避免热点问题。 监控与调优 在HBase集群运行时,监控各个Region的负载情况非常重要。如果发现某些Region的负载过高或...
CREATE TABLE test (host VARCHAR NOT NULL PRIMARY KEY, description VARCHAR) SALT_BUCKETS=16; 1. SALT_BUCKETS的值范围在(1 ~ 256); salted table可以自动在每一个rowkey前面加上一个字节,这样对于一段连续的rowkeys,它们在表中实际存储时,就被自动地分布到不同的region中去了。当指定要读写该段区间内的...
SALT_BUCKETS | MULTI_TENANT | VIEW_STATEMENT | VIEW_TYPE | INDEX_TYPE | TRANSACTIONAL | IS_NAMESPACE_MAPPED | G | +---+---+---+---+---+---+---+---+---+---+---+---+---
可以看到,加盐前的Rowkey默认会在第2个region中,加盐后的Rowkey数据会分布在3个region中,理论上处理后的吞吐量应是之前的3倍。由于前缀是随机的,读这些数据时需要耗费更多的时间,所以Salt增加了写操作的吞吐量,不过缺点是同时增加了读操作的开销。 ΩΩ3、Hash散列或者Mod ...
salt salt这个东西最好根据自己HBase集群规模去配置,它有2个配置: tsd.storage.salt.width # 默认1,1基本够了,不用调整tsd.storage.salt.buckets # 打散到几个bucket去,默认20 查询的时候会并发 tsd.storage.salt.buckets 个Scanner到HBase上,所以如果这个配置太大,对查询影响比较大,容易打爆HBase。这里其实...
SALT_BUCKETS 取余数,并将结果(上面的例子中是 0~5)作为 byte 插入到 row key 的第一位,根据这个数值将数据分到不同 Region 中,由于是作为 byte 存储,所以 SALT_BUCKETS 能取的最大值是 256,拥有相同 salt byte 的 row 会被分到相同的 region server,所以通常取 region server 的数量作为 SALT_BUCKETS ...
这个解决方案就是加盐,其实叫分桶(salt buckets)更准确。数据在桶内保序,桶之间随机。写入时按桶个数取模,数据随机落在某个桶里,保证写请求在桶之间是均衡的。查询时读取所有的桶来保证结果集的有序和完备。 副作用: 写瓶颈:由于桶内保序,所以即使region不断split变多,全表实际上还是只有数量为buckets的region...
tsd.storage.salt.width # 默认1,1基本够了,不用调整 tsd.storage.salt.buckets # 打散到几个bucket去,默认20 查询的时候会并发tsd.storage.salt.buckets个Scanner到HBase上,所以如果这个配置太大,对查询影响比较大,容易打爆HBase。这里其实是一个权衡,写入热点和查询压力。默认20其实我个人觉得有点多,配置3～...
设计event事件的Rowkey为:两位随机数Salt + eventId + Date + kafka的Offset 这样设计的好处是: 设计加盐的目的是为了增加查询的并发性,假如Salt的范围是0~n,那我们在查询的时候,可以将数据分为n个split同时做scan操作。经过我们的多次测试验证,增加并发度能够将整体的查询速度提升5～20倍以上。随后的eventId和Dat...