哈希聚簇(Hash Clustering)表通过设置表的Shuffle和Sort属性,进而MaxCompute根据数据已有的存储特性,优化执行计划,提高效率,节省资源消耗。本文为您介绍在MaxCompute中如何使用Hash Clustering表。
背景信息
id
列连接起来。SELECT t1.a, t2.b FROM t1 JOIN t2 ON t1.id = t2.id;
Join在MaxCompute内部主要有三种实现方法:- Broadcast Hash Join
当Join表中存在一个很小的表时,MaxCompute采用此方式,即把小表广播传递到所有的Join Task Instance上面,然后直接和大表做Hash Join。
- Shuffle Hash Join
如果Join表比较大,就不能直接广播了。这时候把两个表按照Join Key做Hash Shuffle,由于相同的键值Hash结果也是一样的,这就保证了相同的Key的记录会收集到同一个Join Task Instance上面。然后每个Instance对数据量小的一路建Hash表,数据量大的顺序读取Join。
- Sort Merge Join如果Join的表数据更大一些,Shuffle Hash Join方法也用不了,因为内存已经不足以容纳建立一个Hash Table。这时的实现方法是:先按照Join Key做Hash Shuffle,然后再按照Join Key做排序(Sort),最后对Join双方做一个归并,具体流程如下图所示:实际上对于MaxCompute目前数据量和规模,绝大多数情况下都是使用的Sort Merge Join,但这其实是非常昂贵的操作。从上图可以看到,Shuffle的时候需要一次计算,并且中间结果需要落盘,后续Reducer读取的时候,又需要读取和排序的过程。对于
M
个Mapper和R
个Reducer的场景,将产生M x R
次的IO读取。对应的Fuxi物理执行计划如下所示,需要两个Mapper Stage,一个Join Stage,其中红色部分为Shuffle和Sort操作:与此同时,有些Join是可能反复发生的,比如将Query改为:
虽然选择的列不一样了,但是Join是完全一样的,整个Shuffle和Sort的过程也是完全一样的。SELECT t1.c, t2.d FROM t1 JOIN t2 ON t1.id = t2.id;
又或者将Query改为:
这个时候对表t1和t3来Join,但实际上对于t1而言,整个Shuffle和Sort过程还是完全一样。SELECT t1.c, t3.d FROM t1 JOIN t3 ON t1.id = t3.id;
于是,考虑如果初始表数据生成时,按照Hash Shuffle和Sort的方式存储,那么后续查询中将避免对数据的再次Shuffle和Sort。这样做的好处是,虽然建表时付出了一次性的代价,却节省了将来可能产生的反复的Shuffle和Join。这时Join的Fuxi物理执行计划变成了如下,不仅节省了Shuffle和Sort的操作,并且查询从3个Stage变成了1个Stage完成:
使用说明
创建Hash Clustering表
- 命令语法
CREATE TABLE [IF NOT EXISTS] <table_name> [(<col_name> <data_type> [comment <col_comment>], ...)] [comment <table_comment>] [PARTITIONED BY (<col_name> <data_type> [comment <col_comment>], ...)] [CLUSTERED BY (<col_name> [, <col_name>, ...]) [SORTED BY (<col_name> [ASC | DESC] [, <col_name> [ASC | DESC] ...])] INTO <number_of_buckets> BUCKETS] [AS <select_statement>]
- 使用示例。
- 非分区表。
CREATE TABLE T1 (a string, b string, c bigint) CLUSTERED BY (c) SORTED by (c) INTO 1024 BUCKETS;
- 分区表。
CREATE TABLE T1 (a string, b string, c bigint) PARTITIONED BY (dt string) CLUSTERED BY (c) SORTED by (c) INTO 1024 BUCKETS;
- 非分区表。
- 属性说明
- CLUSTERED BY
指定Hash Key,MaxCompute将对指定列进行Hash运算,按照Hash值分散到各个Bucket里面。为避免数据倾斜,避免热点,取得较好的并行执行效果,CLUSTERED BY列适宜选择取值范围大、重复键值少的列。此外为了达到Join优化的目的,也应该考虑选取常用的Join或Aggregation Key,即类似于传统数据库中的主键。
- SORTED BY
指定在Bucket内字段的排序方式,建议Sorted By和Clustered By一致,以取得较好的性能。此外当SORTED BY子句指定之后,MaxCompute将自动生成索引,并且在查询的时候利用索引来加速执行。
- INTO number_of_buckets BUCKETS
指定哈希桶的数目,这个数字必须提供,由数据量大小来决定。Bucket越多并发度越大,Job整体运行时间越短,但同时如果Bucket太多的话,可能导致小文件太多,另外并发度过高也会造成CPU时间的增加。目前推荐设置让每个Bucket数据大小在500MB ~ 1GB之间,如果是特别大的表,这个数值可以适当增加。对于Join优化的场景,两个表的Join要去掉Shuffle和Sort步骤,要求哈希桶数目成倍数关系,比如
256
和512
。目前建议桶的数目统一使用2的N次幂,比如512、1024、2048、4096,这样系统可以自动进行哈希桶的分裂和合并时,也可以去除Shuffle和Sort的步骤。
- CLUSTERED BY
更改表的Hash Clustering属性
- 命令语句
--更改表为Hash Clustering表 ALTER TABLE <table_name> [CLUSTERED BY (<col_name> [, <col_name>, ...]) [SORTED BY (<col_name> [ASC | DESC] [, <col_name> [ASC | DESC] ...])] INTO <number_of_buckets> BUCKETS]; --更改Hash Clustering表为非Hash Clustering表 ALTER TABLE <table_name> NOT CLUSTERED;
- 注意事项
- ALTER TABLE语句改变聚集属性,只对于分区表有效,非分区表一旦聚集属性建立就无法改变。
- ALTER TABLE语句只会影响分区表的新建分区(包括insert overwrite生成的),新分区将按新的聚集属性存储,老的数据分区保持不变。
- 由于ALTER TABLE语句只影响新分区,所以该语句不可以再指定PARTITION。
表属性显式验证
Extended Info
里面。DESC EXTENDED <table_name>;
返回结果示例如下图所示。对于分区表,除了使用以上命令查看表属性之后,还需要通过以下命令查看分区的属性。DESC EXTENDED <table_name> partition(<pt_spec>);
返回结果示例如下图所示。Hash Clustering优势
Bucket Pruning和Index优化
CREATE TABLE t1 (id bigint,
a string,
b string)
CLUSTERED BY (id)
SORTED BY (id) into 1000 BUCKETS;
...
SELECT t1.a, t1.b FROM t1 WHERE t1.id=12345;
对于普通表,这个通常意味着全表扫描操作,如果表非常大的情况下,资源消耗量是非常大的。但是因为我们已经对id
做Hash Shuffle,并且对id
做排序,查询可以极大简化:- 通过查询值
12345
找到对应的Hash Bucket,这时候我们只需要在1个Bucket里面扫描,而不是全部1000个Bucket里面扫描。称之为Bucket Pruning。 - 因为Bucket内数据按
id
排序存放,MaxCompute会自动创建Index,利用Index lookup直接定位到相关记录。
例如一个大数据任务,一共起了1111个Mapper,读取了427亿条记录,最后找符合条件记录26条,总共耗时1分48秒。同样的数据、同样的查询,使用Hash Clustering表来做,可以直接定位到单个Bucket,并利用Index只读取包含查询数据的Page,只用4个Mapper,读取10000条记录,总共耗时只需要6秒。
Aggregation优化
SELECT department, SUM(salary) FROM employee GROUP BY (department);
通常情况下会对department
列数据进行Shuffle和Sort,然后做Stream Aggregate,统计每一个department
Group。但是如果表数据已经CLUSTERED BY (department) SORTED BY (department),那么这个Shuffle和Sort的操作,也就相应节省掉了。存储优化
即便不考虑以上所述的各种计算上的优化,单单是把表Shuffle并排序存储,都会对于存储空间节省上有很大帮助。因为MaxCompute底层使用列存储,通过排序,将键值相同或相近的记录存放到一起,对于压缩、编码都会更加友好,从而使得压缩效率更高。在实际测试中,某些极端情况下,排序存储的表可以比无序表的存储空间节省50%。对于生命周期很长的表,使用Hash Clustering存储,是一个很值得的优化。
lineitem
表,包含了int
、double
、string
等多种数据类型,在数据和压缩方式等完全一样的情况下,对比使用Hash Clustering和未使用Hash Clustering的表存储大小,使用Hash Clustering的表存储节省了约10%
,如下图所示。- 未使用Hash Clustering。
- 使用Hash Clustering。
测试数据及分析
对于Hash Clustering整体带来的性能收益,通过标准的TPC-H测试集进行衡量。测试使用1TB数据,统一使用500 Buckets,除了nation
和region
两个极小的表以外,其余所有表均按照第一个列作为Cluster和Sort Key。整体测试结果表明,在使用了Hash Clustering之后,总CPU时间减少了约17.3%
,总的Job运行时间减少了约12.8%
。
需要注意到是TPC-H里并不是所有的Query都可以利用到Clustering属性,特别是两个耗时最长的Query没有办法利用上,所以从总体上的效率提升并不是非常惊人。但如果单看可以利用上Clustering属性的Query,收益还是非常明显的,比如Q4快了约68%
、Q12快了约62%
、Q10快了约47%
等。