更高性能表现、更低资源占用,高精度计算数据类型 DecimalV3 揭秘
数值运算是数据库中十分常见的需求,例如计算数量、重量、价格等,为了适应多样化运算场景,数据库系统通常支持精准的数字类型和近似的数字类型,当我们需要精确地表示小数并计算小数时,通常会考虑使用 Decimal 数据类型。区别于浮点小数,Decimal 作为定点小数类型,可以支持高精度的小数运算,因此适用于各种高精度计算的场景,常见的应用场景有以下几种:
- 金融行业:在金融交易中经常涉及到小数,比如利息、金额的计算,金融场景对数字准确的要求极高,因此精确的小数运算是必要的。
- 财务软件:财务软件通常需要进行复杂的财务计算,Decimal 类型可以提供精确的小数计算,避免计算过程中产生的舍入误差。
- 科学计算、工程计算等其他场景。
DecimalV3 功能介绍
在 Apache Doris 1.2.1 之前的版本中,我们已对 Decimal(precision, scale)(precision<=27) 数据类型进行了支持,随着 Apache Doris 用户的持续增长,银行、证券、基金等金融领域的用户也随之快速增长,对高精度的小数计算场景也提出了更高的要求,旧的 Decimal 数据类型已无法满足。因此,我们在 Apache Doris 1.2.1 推出了精度更高、速度更快的 DecimalV3(precision, scale)(precision<=38),实现了真正意义上的高精度定点数,相比于老版本中的 Decimal ,DecimalV3 有以下核心优势:
- 可表示范围更大。DECIMALV3 对 Precision 和 Scale 的取值范围进行扩充。
- 内存占用更低,性能更高。老版本的 Decimal 需要占用 16 Bytes 的内存,而 DecimalV3 对内存可进行自适应调整,如下所示。
+----------------------+-------------------+ | precision | 占用空间(内存/磁盘)| +----------------------+-------------------+ | 0 < precision <= 8 | 4 bytes | +----------------------+-------------------+ | 8 < precision <= 18 | 8 bytes | +----------------------+-------------------+ | 18 < precision <= 38 | 16 bytes | +----------------------+-------------------+
- 更完备的精度推演。
精度推演规则
DECIMALV3 有一套很复杂的类型推演规则,针对不同的表达式,会应用不同规则进行精度推演,下面来介绍一下推演规则:
- 四则运算
- 加法 / 减法:DECIMALV3(a, b) + DECIMALV3(x, y) -> DECIMALV3(max(a - b, x - y) + max(b, y), max(b, y)),即整数部分和小数部分都分别使用两个操作数中较大的值。
- 乘法:DECIMALV3(a, b) * DECIMALV3(x, y) -> DECIMALV3(a + x, b + y)
- 除法:DECIMALV3(a, b) / DECIMALV3(x, y) -> DECIMALV3(a + y, b)
- 聚合运算
- SUM / MULTI_DISTINCT_SUM:SUM(DECIMALV3(a, b)) -> DECIMALV3(38, b)。
- AVG:AVG(DECIMALV3(a, b)) -> DECIMALV3(38, max(b, 4))(鉴于每个系统 AVG 的精度不同,且不同用户对精度的需求也不一样,经调研,决定选择与 SQLServer 相同的策略,因此选择“4”既能保证较好的性能,也不会有较大的精度损失。)
- 默认规则
除上述提到的函数外,其余表达式都使用默认规则进行精度推演。即对于表达式 expr(DECIMALV3(a, b))
,结果类型同样也是 DECIMALV3(a, b)。
结果精度调整
上述几种规则为当前 Doris 的默认行为,而不同场景对 DECIMALV3 的精度要求各不相同,远超出以上几种规则。当用户有不同的精度需求,可以通过以下方式进行精度调整:
- 当期望的结果精度大于默认精度时,可通过调整入参精度来调整结果精度。例如用户期望计算
AVG(col)
得到DECIMALV3(x, y)作为结果,其中col
的类型为 DECIMALV3(a, b),则可以改写表达式为AVG(CAST(col as DECIMALV3(x, y)))
。 - 当期望的结果精度小于默认精度时,可通过对输出结果求近似得到想要的精度。例如用户期望计算
AVG(col)
得到DECIMALV3(x, y)作为结果,其中col
的类型为DECIMALV3(a, b),则可以改写表达式为ROUND(AVG(col), y)
。
使用演示
这里我们采用 Bitcoin 的数据集对 DecimalV3 进行演示。
Bitcoin 的数据集部分示例如下:
- Unix - 时间戳
- Date - 时间
- Symbol - 时间序列数据所指代的交易品种
- Open - 该时间段的开盘价
- High - 该时间段的最高价
- Low - 该时间段的最低价
- Close - 该时间段的收盘价
- Volume BTC - BTC 金额
- Volume USD - USD 金额
以下是在 Doris 中的建表存储数据,其中小数的列分别用 DecimalV3 进行存储:
CREATE TABLE `btc` ( `unix` bigint(20) NOT NULL, `date` datetime NULL, `symbol` varchar(30) NULL, `open` decimalv3(8, 2) NULL, `high` decimalv3(8, 2) NULL, `low` decimalv3(8, 2) NULL, `close` decimalv3(7, 2) NULL, `Volume_BTC` decimalv3(10, 8) NULL, `Volume_USD` decimalv3(38, 30) NULL ) ENGINE=OLAP DUPLICATE KEY(`unix`) COMMENT 'OLAP' DISTRIBUTED BY HASH(`unix`) BUCKETS 4 PROPERTIES ( "replication_allocation" = "tag.location.default: 1" );
我们来计算一下 2022 年 1 月 1 日这一天的平均 Volume_BTC/Volume_USD 以及总的 Volume_BTC/Volume_USD:
mysql> select avg(Volume_BTC),avg(Volume_USD),sum(Volume_BTC),sum(Volume_USD) from btc where to_date(date)='2022-01-01'; +-------------------+--------------------------------------+-------------------+-----------------------------------------+ | avg(`Volume_BTC`) | avg(`Volume_USD`) | sum(`Volume_BTC`) | sum(`Volume_USD`) | +-------------------+--------------------------------------+-------------------+-----------------------------------------+ | 0.51494486 | 24236.665942788256243957638888888888 | 741.52060313 | 34900798.957615088991299000000000000000 | +-------------------+--------------------------------------+-------------------+-----------------------------------------+
通过 SQL 的执行结果可以看到,通过 DecimalV3,在 Volume_USD 这一列的平均结果和总和上,实现了保留 30 位的小数。而旧的 Decimal 类型在这个例子中只能实现保留不超过 20 位。
性能对比
我们采用 TPC-H Benchmark 100G 来对比 DecimalV3 与老版本 Decimal 的执行速度、存储占用、内存占用等性能。
我们在两个库分别对新版 DecimalV3 和老版本 Decimal 进行建表。建表完成如下:
tpch1库为DecimalV3
tpch2库为老版本Decimal
执行速度
采用 TPC-H Benchmark 对执行速度进行测试:
select /*+SET_VAR(exec_mem_limit=8589934592, parallel_fragment_exec_instance_num=16, enable_vectorized_engine=true, batch_size=4096, disable_join_reorder=false, enable_cost_based_join_reorder=false, enable_projection=false) */ l_returnflag, l_linestatus, sum(l_quantity) as sum_qty, sum(l_extendedprice) as sum_base_price, sum(l_extendedprice * (1 - l_discount)) as sum_disc_price, sum(l_extendedprice * (1 - l_discount) * (1 + l_tax)) as sum_charge, avg(l_quantity) as avg_qty, avg(l_extendedprice) as avg_price, avg(l_discount) as avg_disc, count(*) as count_order from lineitem where l_shipdate <= date '1998-12-01' - interval '90' day group by l_returnflag, l_linestatus order by l_returnflag, l_linestatus;
tpch1库(DecimalV3)的 SQL 执行结果为 6.38s
tpch2 库(老版本 Decimal)的 SQL 执行结果为 8.13s
SQL Q1 所查询的表是上述展示字段的表 Lineitem,我们可以看到在 DecimalV3 的情况下,查询 速度较老版本有 27.4% 的提升。
存储占用
tpch1库(DecimalV3)的 Lineitem 表的存储占用为 18.475GB
tpch2 库(老版本 Decimal)的 Lineitem 表的存储占用为 20.893GB
可以看到在有四个字段由 Decimal 改为 DecimalV3 的情况下,存储占用有 13.1%的降低。
内存占用
内存占用测试我们同样使用 Lineitem 表,采用自己改写的一条 SQL
select count(*) from ( select l_quantity,l_extendedprice,l_discount,l_tax from lineitem where l_shipdate < '1995-01-01' group by l_quantity,l_extendedprice,l_discount,l_tax )tmp;
下图的 Grafana 监控中可以看到执行测试前的 Doris 内存稳定为 12.2GB
分别在两个库执行上述 SQL
在 tpch1库(DecimalV3)下执行,内存占用峰值为 26.6GB
内存回落正常后,在 tpch2 库(老版本 Decimal)下执行,内存占用峰值为 30.8GB
从上方三张图中可以看到,这条 SQL 在 DecimalV3 的情况下不仅内存占用降低了 15.8%,执行时间也缩短了10s。
总结
Apache Doris 1.2.1 版本推出的 DecimalV3 实现了更高的精度,更高的性能,更完备的精度推演,使得 Doris 更加适用于金融财务、科学计算等有精确计算需求的应用场景,结合 Apache Doris 强大的分析计算性能,给相关用户及行业提供了更准确、完善的数据服务。
接下来,社区还将实现 JDBC 外表对 DecimalV3 类型的支持,JDBC Catalog 可以通过标准 JDBC 协议,连接其他数据源,连接后 Doris 会自动同步数据源下的 Database 和 Table 的元数据,以便快速访问这些外部数据。基于 JDBC 的通用性,结合 Apache Doris 的 高性能分析能力,实现对各类数据库数据联邦查询的高精度计算。
本文作者:
钟永康,SelectDB 生态研发工程师
李文强,SelectDB 数据库内核研发工程师,Apache Doris Committer

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
一文走进多核架构下的内存模
一、走进多核编程 CPU 发展早期阶段,性能的提升主要来自于主频的提升和架构的优化,当这条优化途径出现瓶颈后,多核 CPU 开始流行起来。多核心同时执行任务极大地提高了系统整体性能,但也对硬件架构和软件编写提出了更大的挑战。各个核心都有自己的 Cache,以及不同层级的 Cache,彼此共享内存。一个典型的多核 CUP 架构如下图所示: 利用多核心的优势在各个核之间互相配合完成任务,如何进行各个核心间的数据同步(各个核心所属 L1 Cache/L2 Cache 数据的同步)是问题的关键所在。虽然发展出多种数据同步方式,以及流水线乱序执行的模式,但数据在各个核之间的一致性和可见性并不是那么理想;再加上编译器也会做优化,最终导致各个核的指令执行顺序和各个变量值的可见性变得不确定。 这种现象可以通称为重排,即原本应该有全序的内存读写操作被打乱。不过无论产生什么样的重排,都会保证对于单线程内部的执行结果不会有任何区别。下面是一个简单例子: 1.//Thread1 2.//readywasinitializedtofalse 3.p.init(); 4.ready=true; 1./...
- 下一篇
让人眼前一亮的应用「GitHub 热点速览」
大开眼界的一期 GitHub 热门项目,类似 Django 存在的 pynecone,搞定 Windows、Office 激活的 Microsoft-Activation-Scripts,都让我的收藏夹蠢蠢欲动。最不能错过的应该是 hyperswitch,搞定你的支付业务。当然,还有 GitHub Trending 常客 ui 项目 ui,有着漂亮的画风和过硬的技术背景。最后是压轴的密钥找寻器——trufflehog,翻遍记录也要帮你把那些敏感信息找出来。 以下内容摘录自微博@HelloGitHub 的 GitHub Trending 及 Hacker News 热帖(简称 HN 热帖),选项标准:新发布 | 实用 | 有趣,根据项目 release 时间分类,发布时间不超过 14 day 的项目会标注 New,无该标志则说明项目 release 超过半月。由于本文篇幅有限,还有部分项目未能在本文展示,望周知 🌝 本文目录 1. 本周特推 1.1 纯 Python 应用:pynecone 1.2 PDF 生成:QuestPDF 2. GitHub Trending 周榜 2.1 Wi...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- CentOS8编译安装MySQL8.0.19
- SpringBoot2初体验,简单认识spring boot2并且搭建基础工程
- Hadoop3单机部署,实现最简伪集群
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- CentOS7,8上快速安装Gitea,搭建Git服务器
- CentOS7设置SWAP分区,小内存服务器的救世主
- SpringBoot2全家桶,快速入门学习开发网站教程
- CentOS8安装Docker,最新的服务器搭配容器使用
- Docker安装Oracle12C,快速搭建Oracle学习环境
- Docker使用Oracle官方镜像安装(12C,18C,19C)