周淳：DM针对大数据量环境下分析型应用的支持方案v2063.docx

DTCC2011

DM针对大数据量环境下分析型
应用的支持方案

大纲

·一个实际案例

·挑战和解决方案

·下一步工作规划


DTCC2011

DTCC2011

一个实际案例

案例简介


DTCC2011

· 海量数据
· 基于已有硬件投资
– 单服务器节点
– 操作库和分析库合并
· 以查询分析为主，兼顾少量数据维护

硬件与拓扑

千兆交换机


DTCC2011

应用服务
器

数据汇总
文本
数据
源

文本 Excel
数据


数据清洗与入
库


数据库
服务器
P550
Cpu x 4
Mem 32GB
P550
Cpu x 4
Mem 32GB

源
源

16 X 1TB SAS
RAID 5

文本
数据
源
数据

案例简介-数据


DTCC2011

· 以常规数据为主，主要为数值、字符串、
时间类型

· 日增长数据量为约56G，3亿条元组

· 当前数据量3TB

· 最大单表为计费表，目前约150亿条记录

· 数据保存20年后归档为历史数据

· 在线数据规模将超过400TB

典型业务流程


DTCC2011

– 源数据清洗入库
– 分析统计型查询
· 第一步过滤的筛选条件不确定
· 试错式的查询分析过程，成功后固化，一般包含20多个步骤
· 大规模的连接查询、子查询、联合查询、数据分组与排序、临
时结果集与临时表等
· 复杂SQL不多，但IO非常大
– 日常数据维护
· 手工修改记录内容
· 批量删除
· 定期维护

案例需求


DTCC2011

· 关键在查询性能
– 第一个过滤步骤
· 筛选字段由用户随机定义，因此无法使用索引
· 一般会得到千万级别的结果集
– 大量的多表连接查询
· 数据装载性能
· 初始入库48亿条，近1T：限48小时，相当于3万条/s
· 后续每3天入库一次，9亿条，168G，限10小时内完成

DTCC2011

挑战-核心是性能

原有产品难以支持分析型应用DTCC2011

·
·
·
·
·
·
·


只支持行式存储

查询优化器比较简陋

虚拟机实现不尽合理

物理存储设计有待优化

日志系统过于复杂

不能充分利用多机资源提升性能

数据分片技术不完善

于2009年开始新一代产品DM7的研制

DTCC2011

实验室原型
技术积累阶段
实现各类标准


持续的技术积累
5.6引入物理操作符,虚拟机
6.0引入高级特性和oracle 兼容特性


5


DM7

2011

稳定性及功能
与开源系
统有差距


3


DM5.6
4


DM6

2009

对DM4-DM6的技
术总结
融合列存储与行
存储

基于向量数据的

1
DM1-DM3
2

DM4

2004
2007
执行内核
原生的MVCC
OLAP应用的支
持

1988-
2003

DM系统研制历程

对于性能的理解


DTCC2011

应用系统的
设计

表达式计算


优化器

综合性能

数据/控制权
传递


I/O效率

并发/并行

数据控制权传递-批量技术 DTCC2011

– 向量数据处理
– 在数据泵一次传送一批数据
– 减少控制转移的CPU损耗；
– 有利于批量的表达式计算

传统的数据传递

PROJECT

FILTER


一次只传递一条记录

每个操作符一次只处理一
行记录

1


1


1


…


控制权需要反复传递

SCAN

DTCC2011

向量式的数据传递

PROJECT

减少控制权限的反复传递

提升CPU的有效利用率

FILTER
便于表达式批量计算

SCAN

1
2
…
N

1
2
…
N
…
…
…
…

DTCC2011

批量技术-数据入库


DTCC2011

– 将系统的初始数据入库
– 原有BCP接口达到5000条/s，仍无法满足要求
– 改进：
· 在服务器端实现批量，减少执行流程中的控制跳转
· 效率提升８倍

批量技术-全表更新


DTCC2011

普通

批量


普通批量
绑定

针对大表更
新的特定的
批量绑定消
息


计划生成

生成特定计
划，减少执
行流程


单趟扫描一个ID进行
更新，执行20万次

ID进行排序，单趟扫描20
万个ID并进行更新

性能提升100倍以上，控制在2秒以内

批量技术-LIKE谓词

· select count(*) from orders where
o_comment not like
'%special%requests%‘


DTCC2011

DBMS ‘O’ 11g:


3.3

DBMS ‘S’ 2005: 10

DM7:

0.4

orders : 1,500,000记录

cpu 2.2G,多次执行

DTCC2011

· 一个表达式出现多次
– Select sum(2 * c1), sum(3 * (2 * c1)) from t

· 只计算一次，结果缓存
– v1 = 2 * c1；
– Select sum(v1), sum(3 * v1) from t

· 类似思路：中间结果重用
– 一个复杂查询在一条sql语句中使用多次的情况
– 将复杂查询提取，并将结果缓存，多次使用

表达式计算-表达式结果重用

批量表达式计算
for (i = 0; i < n; i++)
{
r = (int64)opr1[i] + opr2;

if (r != (int)r)
return EC_DATA_OVERFLOW;

}


res[i]


= (int)r;

·
·
·


一次计算一批数据

利用CPU的CACHE
利用CPU的SIMD特性

·
避免传统DBMS的函数反复调用代价

·
·
接近于C的效率
比一次一行模式快10-100倍以上

·
虚拟机支持批量计算指令
DTCC2011

批量尺寸对性能的影响

·


SF=1, TPCH Q1

· BDTA_SIZE: 可配
置的批量大小参数

· 增大BDTA_SIZE
可以有效的提高执
行效率

DTCC2011

DTCC2011

TPCH
DM7
DBMS
‘O’11
PGSQL8.
3
DBMS
‘S’20
05
Q12
1.57
9.15
4.62
2.08
Q13
1.73
4.47
5.13
12.03
Q14
0.71
8.97
2.80
1.16
Q15
0.66
8.98
5.51
1.04
Q16
0.87
0.33
4.52
5.41
Q17
1.03
8.94
>100
1.80
Q18
1.27
9.21
22.01
2.90
Q19
1.92
9.06
5.62
4.17
Q20
0.78
9.23
>100
0.79
Q21
2.2
48.88
33.01
5.49
Q22
0.24
0.34
>100
1.16

TPCH
DM7
DBMS
‘O’11
PGSQL8.3
DBMS
‘S’20
05
Q1
1.314
9.09
16.01
12.87
Q2
0.16
0.046
0.19
0.14
Q3
0.86
21.61
9.30
2.78
Q4
0.98
9.03
0.80
0.68
Q5
1.4
9.05
4.61
1.58
Q6
0.78
9
2.72
0.96
Q7
1.61
11.73
19.54
2.35
Q8
2.3
0.28
2.97
2.01
Q9
3
1.61
18.01
5.45
Q10
1.36
9.16
5.83
2.23
Q11
0.19
44.67
0.55
0.46

TPC-H /SF=1对比测试(S)

优化器-分析器流程


DTCC2011

SQL脚本

语法分析

语法树
语义分析

SFW结构
关系代数变换

关系树

代价优化

优化了的关系树

物理计划生成

执行计划

智能优化器

· 基于多趟分析的代价优化器

· 语义分析、代价优化过程分离

· 灵活的计划变换控制

· 基于时间单位(ms)的代价计算

· 解决统计信息的使用性问题

· 增加频率直方图

· 增加高度直方图的桶数


DTCC2011

查询优化：关系变换


DTCC2011

· SFW结构转换为关系树


Select : ID , name

From : T

SFW结构

–投影(PROJECT)

–连接(JOIN)

–半连接(SEMI JOIN)

–选择(SELECT)

–基本表(BASE TABLE)

Where : ID = 10

PROJECT
(ID , name )

SELECT

(ID = 10)

BASE _
TABLE (T)
关系树

查询优化：关系变换的关键DTCC2011

· 消除子查询，“平坦”的关系树

· 子查询一律转化为半连接（SEMI JOIN）

例：select from T1 where t1.id in (select ID from T2)

PROJECT

SEMI
JOIN

T1


T2

查询优化：待选关系树的生成DTCC2011

· 考虑三个因素
· A.确定的连接次序
· B.确定的卡特兰2叉树形状
· C.是否下放过滤条件
· 采用临时结果减少重复计算
· 代价模型基本覆盖所有情况
· 对连接表的个数非常多的情况,特殊处理

查询优化：统计信息


DTCC2011

· 记录数据分布情况，用于精确行数估计，
特别是数据分布不规则的情况，对基数及
代价计算有重大影响

· 频率直方图：不同值较少

500
450
400
350
300
250


400


200


238


432


300

200
150
100
50
0
124
167

w_id = 0
w_id = 1
w_id = 2
w_id = 3
w_id = 4
w_id = 5
w_id = 6

· 等高直方图：不同值较多


4050
4000


4002


3990


4032


3980

3950
3900
3850
3800
3950
3960

3888

DTCC2011

· 列存储:
– 数据按列存储
– 结合自适应压缩技术
– 与批量计算技术紧密结合

· 列存储优缺点
– 大幅提升扫描性能
– 适合批量装载与删除
–不适合频繁的插入、删除和更新

· 融合列存储和行存储
– 提供按列存储选项
–结合分区技术
– 同时适应OLAP和OLTP应用需求

I/O效率-融合列存储和行存储

I/O效率

· 行存储优化

–简化物理记录格式

–字段物理次序与逻辑次序分离

· 多buffer类型

–常驻内存和常规方式淘汰

–用户可以指定

· 批量读：预处理

· 支持垂直分区和水平分区


DTCC2011

提高并发度

· 支持并行插入的物理数据存储
· 并行备份和恢复
· 分区技术及相应的并行查询操作符号


DTCC2011

典型场景一：大结果集


DTCC2011

· 场景描述
– 某表T，31个字段，48亿条记录
– 随机基于某字段筛选：SELECT * FROM T WHERE
FLD1=753
– 查询符合条件的结果集达到千万条记录
· 分析

–
–
–
–
SQL语句非常简单，没有更优的等效语句
结果集筛选条件不确定，无法使用索引

服务器内存为32G，在扫描的过程中必然出现页面淘汰
由于基础数据量大，因此即使命中率不高（0.2%），
也会生成960万条记录的结果集

典型场景一：大结果集


DTCC2011

从3个方向入手，提升全表扫描的IO效率

· 批量技术

· 降低结果集处理的时间消耗

· 调整数据页读取策略

典型场景一：大结果集


DTCC2011

· 返回结果集策略改进
– 优化前
· 根据通信块大小决定结果集分批次返回的数量
· 第一批结果集返回后，自动完成后续结果集获取和返回
– 优化后
· 由应用设定第一批结果集的大小和返回的时机
· 当返回第一批结果集后，工作线程暂停SQL查询请求，直到下
一批结果集请求到来或开始新事务
– 效果
· 快速返回部分结果集，提高用户体验
· 避免自动返回所有结果集，降低服务器资源消耗

典型场景一：大结果集


DTCC2011

· 调整数据读取策略
– 数据页（page）是数据读写的单位
– 优化前的全表扫描：按页读取，每次IO只扫描
一个页

– 优化后：一次扫描多个页，减少IO数量
– 测试：经过优化后，磁盘的吞吐量提升1倍

典型场景二：大表连接


DTCC2011

· 场景描述
– 表T1，31个字段，5000W条记录，数据类型包括int、
varchar、datetime、Dec；表T2,15个字段，500W条记录，
数据类型包括varchar、datetime、Dec；
– SELECT T1.NAME, T2.TITLE FROM PERSON.PERSON
T1, RESOURCES.EMPLOYEE T2 WHERE
T1.PERSONID = T2.PERSONID AND T1.SEX = 'M';
– 连接查询字段由最终用户临时指定，表上未建索引
– 结果集不大，但查询表数据量大，连接查询响应时间陡增

典型场景二：大表连接


DTCC2011

· 分析
· 行存储特性：连接查询所连接的字段在数据页中的
存储非连续，进行连接查询，需将所有数据页读到
内存，IO消耗巨大；
· 连接匹配时，要对读入缓存中的所有页进行扫描。
· 行存储：
–连接列分散在每个数据页中

Cn+1


页1


…


Cn+1


页N

C1
C2
…
Cn

C1
…
Cm
…
…
…
…

C1
C2
…
Cn

C1
…
Cm
…
…
…
…

典型场景二：大表连接


DTCC2011

· 优化方向：列存储
–按字段存储
–连接列被集中存储

Cn+1 Cn+1

…

页1

Cn+1


页N

–读入缓存中的数据页明显减少，系统IO下降

C1
C1
…
C1

C2
C2
…
C3
…
…
…
…

…

…
Cm
…
…
…
…

典型场景二：大表连接

· 优化方向：存储压缩
– 适用于列存储模式的压缩算法
– 初步压缩结果：


DTCC2011

·
·
·
·
采用本案例数据进行测试
Float 54%（压缩后大小/压缩前大小）

Double 33%

Dec 52%

·
字符

56%

典型场景二：大表连接

· 优化效果

从17小时降至10分钟以内


DTCC2011

典型场景三：全表查询建表DTCC2011

· 场景描述
– 表T,15个字段，500W条记录，数据类型包括int、
varchar、datetime、Dec ；
– 根据T进行查询建表：CREATE TABLE TT as SELECT * FROM
T;

典型场景三：全表查询建表DTCC2011

· 分析
– 大表进行查询建表时，需经过以下五个步骤

初始
化目
标表


全表
扫描


生成
结果
集


插入
结果


事务
提交

– 这个过程中可优化的操作有：查询与结果集的
生成和大量数据的插入操作

典型场景三：全表查询建表DTCC2011

· 直接B树操作

– 避免结果集处理与数据插入
操作
– 直接复制根节点和叶子是在
内存中进行操作，速度更快

· 优化效果
对案例中的T进行建表查询
– 优化前耗时约35S
– 优化后耗时约4S，性能提升
9倍
装载表数据到内存

源表B树扫描

复制B树

典型场景四：重复表达式计算DTCC2011

· 场景描述
– 针对500万条记录的表进行如下查询
– SELECT IDnum,sub(6,8,IDnum) as 生日,(now()-
sub(6,8,IDnum)) as 年龄 from …
· 问题分析

· 表达式sub(6,8,IDnum) 可重用

典型场景四：重复表达式计算DTCC2011

· 改进优化：
– 一个表达式出现多次，只计算一次
– 本例中性能提升70%。其他场景性能提升程度
取决于计算表达式的复杂度与数据量

典型场景五：并行查询插入DTCC2011

· 场景描述
– 同结构的表T1~T10，每张表500万条记录，需要将10
张表的所有数据合并到一个临时表Ttmp中
– INSERT INTO Ttmp SELECT * FROM T1
– INSERT INTO Ttmp SELECT * FROM T2。。。
– 应用的并行化并没有带来较大的提升
– 分析
– Ttmp成为瓶颈：原有的逻辑Rowid成为资源瓶颈
– 逻辑Rowid：不代表物理存储位置，更新、插入、重组
等操作代价降低，但Rowid需要通过临界资源获取
– 原有产品针对OLTP业务场景，OLTP事务以分散、短
小事务为主，原有的RowID机制不会成为突出瓶颈

典型场景五：并行查询插入DTCC2011

· 改进
– 物理RowID：代表记录的物理存储位置

– 多个工作线程进行插入操作，无需进入临界资
源获取rowid，每个工作线程自行生成RowID
– 实现真正意义上的并发插入

应用优化


DTCC2011

· 好的性能需要应用与数据库的配合实现
– 应用架构设计应站在系统全局考虑性能问题
– 应用与数据库应该取长补短
· 数据存储
– 基于分区表进行数据划分
· 应用的并行化
– 复杂事务分解为多个可并行的简单事务

应用优化-手段


DTCC2011

·
·
·
·


保存第一步过滤结果集

利用视图减少中间结果集的保存

数据按月份分区
TOP查询减少不必要的全结果集

应用优化-大表的全表扫描 DTCC2011

· 典型场景
– 5000万无索引TOP查询：SELECT * FROM T6
WHERE NAME LIKE ‘张三’
– 优化前：数据库服务器CPU满载而应用服务器没有
负载
– 在最坏情况下，将需要扫描整个表
· 分析：
– 系统设计需要站在全局角度，充分考虑应用、
中间件、数据库之间的负载分配
– 充分利用已有的硬件

应用优化-大表的全表扫描 DTCC2011

· 改进：
· 数据进行分表和分区
· DM已实现的分区表并行查询操作符，提供了
分区表优化的支持
· 应用依据分表更改查询模块，从单线程改为
多线程
· 在应用服务器将各分表的查询结果合并
· 效果：
· 按最坏情况测试，查询时间由原来的不可预
期，提升到2分钟内

应用优化-数据清洗与入库 DTCC2011

– 最初方式：
– 基于JDBC驱动的数据迁移工具进行清洗和入库
操作

– 批量绑定

– 迁移工具的资源消耗随着迁移时间的持续增加，
导致迁移速度在运行3天后急剧下降
– 初始数据（1T）入库时间达到1个月，相当于
400条/s

应用优化-数据清洗与入库 DTCC2011

– 问题分析：
– 超过100亿条记录，即使每5000条提交一次，
也有2百万次的解析-计划-代价-执行流程
– 大量的数据库redo与undo日志操作
– 解决方案
– 利用批量＋ＢＣＰ
– 利用并行化充分发挥多CPU处理能力，增加IO
的吞吐量
– JDBC方式转变为JNI+ODBC
– 实现动态编译型的ETL脚本引擎

DTCC2011

图 DMETL 内嵌BCP

应用优化-DM ETL的技术改进

DTCC2011

应用优化-数据划分和并行化

应用优化-BCP


DTCC2011

· 将清洗与入库分离
· 并行化清洗和装载入库
· 入库应用BCP方式
· 通过批量绑定减少了网络开销
· 服务器内部为BCP专门实现了”bcp_fast_insert”方法
· 绕过SQL处理流程，直接操作B树叶子节点
· 不进行Redo与Undo
· 不进行约束检查
· 对原有BCP也进行了服务器端的批量化处理

最终效果：性能提升100倍，能够在8小时内完成

海量数据备份的难题


DTCC2011

· 备份的效率问题
– 整库备份操作耗时太长

· 备份粒度问题

– 需要灵活的针对整库、文件组、表、分区的多
种粒度备份手段

· 备份文件尺寸问题
– 备份文件太大，消耗存储空间严重

· 备份文件传输效率问题
– 传输大尺寸备份文件，网络传输成为瓶颈

本案例中的备份需求


DTCC2011

根据数据量、变化频度等确定不同的备份策略

对象
更新特点
备份策略
XX1、XX2、XX3…
一次入库后不再更新
一次全量备份
YY1、YY2…
2周~1月，数据量1~2
亿条
随更新即时全备
ZZ1
周期不定，平均每次
500G数据
随更新即时增量备份

应用优化-备份


DTCC2011

· 选用dmloader作为表级备份方式
– 导出为纯文本，可与压缩相结合
– 基于B树叶节点顺序扫描，高速高效
– 支持多个loader进程同时执行导出，提高IO并发度
· 离线数据提取工具
– 实现全库数据的快速备份
– 绕过数据库服务器，直接读取数据文件
– 实现异步/并行的读数据与写多个文件，进一步提高效
率

DTCC2011

直面挑战—下一步规划

达梦分布式架构DM MPP


DTCC2011

· 海量存储环境下的终极解决方案必然是分
布式处理

· DM MPP：SHARE NOTHING架构

EP1-1 EP1-2 EP1-m
DP1-2 DP1-2 DP1-m
服务器1

数据片1-2
数据片2-2
数据片n-2
……


EP2-1 EP2-2 EP2-m
DP2-2 DP2-2 DP2-m
服务器2

数据片1-1
数据片2-1
数据片n-1
……

数据存储区


EPn-1 EPn-2 EPn-m
DPn-2 DPn-2 DPn-m
服务器n

数据片1-m
数据片2-m
数据片n-m
……

DTCC2011

The End
谢谢

达梦数据库（武汉）有限公司 达梦数据库（上海）有限公司
达梦数据库（北京）有限公司 达梦数据库（广州）有限公司