的限制#xff0c;而分布式数据库则通过数据划分的规则#xff0c;将数据打散分布至不同的机器或节点上#xf…数据分片Sharding是分布式数据库分而治之

(Divide

这一设计思想的体现。

过去的单机数据库在大数据量下往往面临存储和

的限制而分布式数据库则通过数据划分的规则将数据打散分布至不同的机器或节点上形成分布式存储因此突破了单机存储空间和

的瓶颈、使库表数据量可以无限拓展。

数据分片主要有范围分片或哈希分片这两种方式而在实际数据库的实现中往往呈现为分区和分桶两种形式。

分区一般是按照时间或其他连续值对数据进行划分在执行查询操作时可以通过分区裁剪过滤不必要的范围扫描提升执行效率同时也使得对分区数据的增删改等管理操作更为便捷。

而分桶则是按照某个关键字执行哈希运算将相同哈希值的数据放到一起这样可以有效定位数据、避免数据倾斜。

在

Apache

中同样也遵从一定的数据分布规则。

数据以关系表Table的形式进行呈现会依次按照先分区Partition、再分桶Bucket的方式划分最终在同一个分桶中的数据会形成数据分片Tablet。

Tablet

Apache

中多副本高可用、集群间数据调度与均衡的最小物理存储单位。

图1Table-Partition-Tablet

现状与问题在

中分区与分桶是如何创建的我们以一个网站站点的建表实例说明分区与分桶的创建方式该网站的站点建表语句如下--

CREATE

相当于对分区的列值进行枚举因此选择的分区列最好是有区分度的可枚举值例如本例中的

city

的创建会生成一个左闭右开的区间定义一个分区只需要指定右边界该分区的左边界由上一个分区的右边界确定PARTITION_DESC可以写为--

日期处于[min,

2023-01-02)的数据都放到名为p20230101的分区下

日期处于[2023-01-02,

的右边界确定。

需注意的是此处为了举例说明动态分区使用了一个很大的边9999-12-31实际业务中很少会直接创建从

2023-01-02

Partition上述静态的分区需要手动指定边界分区个数太多使用起来也不方便。

动态

Range

帮助我们解决了这个问题只需指定一些分区的参数即可动态创建PARTITION_DESC

RANGE(sdate)()剩余参数需要在PARTITION进行配置PROPERTIES

true,dynamic_partition.time_unit

p,dynamic_partition.create_history_partitiontrue,replication_num

);动态分区参数说明如下创建分桶分桶在物理层面即数据分片Tablet。

在数据表完成分区后指定部分列作为分桶列将这些列数据中相同哈希值的数据合到一起形成了

Tablet

仅作为示例合适的分桶个数需要根据分区大小来确定。

实际上单个分桶即

Tablet

个是合适的。

不足与思考从以上对分区分桶的介绍相信有不少用户和读者仍能发现其中一些不足之处分区数量过多的情况下使用

List

Partition则需要掌握多个参数使用方式不友好且学习成本较高而当存在大量历史冷数据来说动态

Range

只能指定单一粒度无法灵活组合不同的分区粒度分桶个数的设置十分依赖用户对

Apache

数据分布机制和业务数据本身的理解使用门槛较高。

不合理的分桶设置将对系统性能和稳定性造成一定程度冲击分桶数太多将导致单个

Tablet

的数据量过小数据聚合效果不佳、查询性能不能得到有效发挥并且元数据管理压力大个数太少则单个

Tablet

版本中我们新增了批量创建分区功能简洁的语法和灵活的使用方式让批量创建历史分区更加得心应手而针对分桶设置带来的学习成本Apache

Doris

自动分桶推算功能分桶个数不再依赖于人工设置通过规则的智能计算即可保证合理的数据划分降低用户学习成本的同时还可以最大化提升用户开发效率。

批量创建分区批量创建分区功能在前期充分调研了用户的需求本着简洁、强大、易用的设计目标将设计核心锁定在几个要素中时间区间范围会考虑开闭问题时间跨度即每个分区的时间维度的大小时间单位年、月、日、时、周等结合前面提到的网站站点模型假设其数据包含从几年前直到现在的全量信息想要将十年内的数据按每一天一个分区进行创建。

在批量分区功能中PARTITION_DESC只需要一句并且不用在PARTITION中设置分区相关参数--

当然分区创建个数受到max_multi_partition_num参数控制该值默认为4096有需求可以修改

PARTITION

来看批量分区功能的语法更为简洁但该功能的易用性和灵活性远不止于此。

从这个

case

来看批量分区功能的语法更为简洁但该功能的易用性和灵活性远不止于此。

假设有另一批数据公司前几年的数据量较大且为冷数据故可以将一年的数据合到一个分区里面而后来因为业务迅速发展需要将每一月的数据作为一个分区随着公司业务进一步发展按月分区已经不能满足快速增长的数据需求需要按周进行分区……时至今日公司每天产生海量数据可能需要按小时分区才能符合需求。

根据这个场景不难写出批量分区创建的

PARTITION_DESC--

此处需要注意如果要使用小时级别的分区则分区列必须是datetime类型

同样的分区创建个数也受到max_multi_partition_num参数控制

PARTITION

之前的数据归到一个名为pold分区中我们可以将静态分区和批量分区组合起来PARTITION_DESC如下PARTITION

RANGE(sdate)

)批量分区创建功能支持不同时间粒度其语法简洁有力且各种类型分区可以灵活组合在面对大量历史分区和部分特殊分区的需求时该功能显得游刃有余可以极大提高开发效率。

批量分区功能

PR*https://github.com/apache/doris/pull/13772*****Auto

Bucket

自动分桶推算以往创建分桶时需要手动设定分桶数而自动分桶推算功能是

Apache

可以动态地推算分桶个数使得分桶数始终保持在一个合适范围内让用户不再操心桶数的细枝末节。

首先说明一点为了方便阐述该功能该部分会将桶拆分为两个时期的桶即初始分桶以及后续分桶。

这里的初始和后续只是本文为了描述清楚该功能而采用的术语Apache

Doris

从上文中创建分桶一节我们知道BUCKET_DESC非常简单但是需要指定分桶个数而在自动分桶推算功能上BUCKET_DESC的语法直接将分桶数改成Auto并新增一个

Properties

properties(estimate_partition_size

100G)新增的配置参数estimate_partition_size表示一个单分区的数据量。

该参数是可选的如果没有给出则

Doris

10GB。

从上文中已经得知一个分桶在物理层面就是一个Tablet为了获得最好的性能建议

Tablet

大小处于这个范围内的呢总结起来不外乎几个原则若是整体数据量较小则分桶数不要设置过多若是整体数据量较大则应使桶数跟总的磁盘块数相关充分利用每台

机器和每块磁盘的能力初始分桶推算从原则出发理解自动分桶推算功能的详细逻辑就变得简单了首先来看初始分桶先根据数据量得出一个桶数

5按文本格式存入

x;有了上述算法咱们再引入一些例子来更好地理解这部分逻辑case

1:数据量

200可以看到详细逻辑与原则是匹配的。

后续分桶推算上述是关于初始分桶的计算逻辑后续分桶数因为已经有了一定的分区数据可以根据已有的分区数据量来进行评估。

后续分桶数会根据最多前

EMA[1]短期指数移动平均线值作为estimate_partition_size

进行评估。

此时计算分桶有两种计算方式假设以天来分区往前数第一天分区大小为

S7往前数第二天分区大小为

天内的分区数据每日严格递增则此时会取趋势值有6个delta值分别是S7

delta1,S6

S7)根据上述算法初始分桶个数以及后续分桶个数都能被计算出来。

跟之前只能指定固定分桶数不同由于业务数据的变化有可能前面分区的分桶数和后面分区的分桶数不一样这对用户是透明的用户无需关心每一分区具体的分桶数是多少而这一自动推算的功能会让分桶数更加合理。

自动分桶推算功能

PRhttps://github.com/apache/doris/pull/15250效果当我们有了合适的分区分桶时导入数据导到

Doris

后数据会依照建表语句中的分区分桶列进行存储。

上述网站站点数据的存储示例如图示图2Doris

SQL

个。

则经过明确的分区分桶谓词下推则可以将数据全表扫描量变为原来的

1/60030

总结整体来看批量创建分区功能语法简洁有力解决了用户针对大量历史数据分区创建的难题既避免了手动创建大量分区的低效语法又避免了动态分区大量参数的学习使用成本且方式灵活多变、随意搭配组合各种类型的分区大大提升了

Doris

在建表过程中的易用性。

自动分桶推断功能智能高效用户不需再关心分桶的细枝末节系统自动帮助用户扩缩不同分区的分桶数真正做到桶随业务变降低学习成本的同时更是提升了查询效率。

在与社区用户持续沟通中我们也不断收获着许多新的需求例如分区列为非时间列等因此后续我们仍将继续完善对其他分区列的支持例如数字分区列的批量创建等。

最后我们期待倾听更多用户的声音在不断回馈用户以极简易用的使用体验的同时也期待有更多人参与到

Apache

https://zhuanlan.zhihu.com/p/587187198作者介绍许瑞亮SelectDB

存储研发工程师胡得潮SelectDB