CDW PG大规模在线数仓技术构架分享
如果无法正常显示,请先停止浏览器的去广告插件。
1. CDW PG 大规模在线数仓
技术构架分享
张倩
腾讯云数据库专家工程师
2.
3. 个人简介
腾讯云数据库专家工程师,中国人民大
学博士,具备多年数据库内核研发经验,
曾在Teradata天睿公司以及华为公司高
斯实验室工作多年。加入腾讯后,负责
CDW PG数据仓库内核优化器、执行器
等多项核心功能研发。
4. • CDW PG 发展历程介绍
• 整体构架演进
• 自研列式存储
• 执行引擎能力提升
5. •
CDW PG 是腾讯基于 PostgreSQL 自主研发的
•
无共享
MPP
分布式在线关系型数据仓库
行列混合
存储
超大规模
集群支持
超高速计
算能力
6. CDW PG整体架构
GTM(事务管理器)
Coordinator(协调节点CN)
全局事务管理器,协调集群集群
事务,并管理全局对象
指标监控
业务访问入口,每个节点对等,对外提供一致视图
GTM-M
Coordinator
Transation Info
Global object
Coordinator
Global catalog
Global catalog
Coordinator
Global catalog
运维管理
Data Forward Bus
集群数据交互总线
实时告警
GTM-S
安全审计
Transation Info
Global object
Datanode1
Local catalog
Local Data
数据治理
Datanode2
Local catalog
Local Data
Datanode3
Local catalog
Local Data
Datanode(数据节点DN) 业务数据存储节点
Datanode4
Local catalog
Local Data
7. • CDW PG发展历程介绍
• 整体构架演进
• 自研列式存储
• 执行引擎能力提升
8. 大规模集群面临的挑战
集群扩展性挑战,分布式JOIN消耗大量网络连接和对应资源
DN1
DN2
DN3
常见做法:
① 第一次重分布: A join B
200 个 DN 节点,100 个并发查询,
每个查询 5 个重分布
((200 - 1) * 100)*5 = 2万 * 5 = 10 万
连接,每个连接在节点对应一个进程
(N – 1) * P 个连接
(N – 1) * P 个进程
DN1
DN2
DN3
① 第二次重分布:(A Join B)Join C
DN1
DN2
DN3
(N – 1) * P 个连接
(N – 1) * P 个进程
问题:单节点连接数太多:
限制分布式数据库扩展性的核心问题之一:
服务器连接数过高
9. 异步执行框架
Projection
为了简化,hash join只画出了一条
inner path路径
CDW PG分布式逻辑框架:
• 在查询优化阶段分析物理查询计划,
统一创建DN上的各层执行进程。
• 保证进程间不需要建立冗余进程及连
接。
• 不同层级进程间可以异步的启动执
行。
• 假设N个节点,M层Join,则会产生
M*N个进程数。
Hash Join Hash Join Hash Join
Remote Subplan Remote Subplan Remote Subplan
Router Router Router
Router Router Router
M*N个进程
Remote Subplan
Remote Subplan
Remote Subplan
10. 数据转发节点支持超大规模集群
Projection
为了简化,hash join只画出了一条
inner path路径
CDW PG分布式物理框架:
• 进一步引入Forward Node(FN)来
进行节点间数据交互。每台物理机一
个FN节点。 Hash Join Hash Join Hash Join
• FN与CN/DN通过共享内存进行数据
交互,本机数据交互可以不走网络
层。 Remote Subplan Remote Subplan Remote Subplan
• 假设N个节点,M层Join,且不管查询
多复杂,只有N*(N-1)个网络连接数。 Forward Node Forward Node Forward Node
Remote Subplan Remote Subplan Remote Subplan
N*(N-1)个连接
M*N个进程
11. 查询计划分片
FID 1
Remote subplan
•
包括数据重分布代价在内,优化
器生成代价估算最优的执行计
划。
•
递归遍历执行计划,对计划树划
Hash Join
FID 2
Remote subplan
FID 4
Hash Join
Remote subplan
分分片(Fragment)。
Seq scan
•
Seq scan
FID 3
通过FID对计划分片进行管理。
Remote subplan
Seq scan
12. 查询分片通过FN节点进行交互
DN 1
•
CN下发每个分片对应的执行计
DN 2
FID 1
FID 1
Send Remote subplan Send Remote subplan
Join Join
划片段。
•
每个分片在每个执行节点上创建
Seq scan
一个进程,执行对应的执行计
Recv Remote subplan
Seq scan
Recv Remote subplan
划。
FN
•
FN
不同层级的进程异步启动执行,
通过FN进行数据交互。
DN 1
DN 2
FID 2
FID 2
Send Remote subplan Send Remote subplan
Seq scan Seq scan
13. • CDW PG发展历程介绍
• 整体构架演进
• 自研列式存储
• 执行引擎能力提升
14. 支持行列混合存储
•
•
支持按照行存储和列存储建表
列表和行表之间可以进行相互操
作
•
行列表之间的混合查询保证事务
一致性
姓名 部门 年龄 蜘蛛侠 部门 年龄
蜘蛛侠 工程部 18 超人 工程部 18
超人 外联部 100 火箭浣熊 外联部 100
火箭浣熊 外联部 6 闪电侠 外联部 6
闪电侠 工程部 17 蜘蛛侠 工程部 17
按行存储表: 按列存储表:
1、每行数据存储所有列 1、每列单独存储,多个列逻辑组成一行
2、一次磁盘IO可以访问一行中所有列 2、一次磁盘IO只包含一列数据
3、适合OLTP场景 3、方便做数据压缩
4、适合OLAP场景
按行存储
按列存储
15. 基于Timestamp的分布式提交协议
GTM集群
GTS核心要点
01
CN
数据库节点
CN
MVCC能力
段页式存储的MVCC是整个并发控制的基
础;同时约定:事务的gts_start > gts_min
并且gts_max没有提交或者gts_start <
gts_max才能看到对应的事务
GTS从哪里来
02
逻辑时钟从零开始内部单向递增且唯一,由
GTM维护,定时和服务器硬件计数器对
齐;硬件保证时钟源稳定度
DN
DN
GTM单点可靠性问题
MVCC原理
gts_min gts_max
1 -1
7
03
balance
10
记录结构
Update balance-=5;gts(7)
Select balance;gts(6)
7
-1
5
Select balance;gts(8)
04
多个GTM节点构成集群,主节点对外提供
服务;主备之间通过日志同步时间戳状态,
保证GTS核心服务可靠性
GTM单点瓶颈问题
根据测试推算,TS85服务器每秒能够处
理1200万QPS,几乎能满足所有场景需
要
16. CDW PG自研列式存储
17. 列存数据压缩能力增强
write
read
轻量级压缩
透明压缩
Column store
•
•
透明压缩算法:zstd, Lz4
轻量级压缩算法:Delta, RLE, Dictionary
压缩级别 文本类型 整数类型
Numeric类型
low Lz4 Delta+RLE middle Dict / Lz4
(Dict优先级高) Delta+RLE+Lz4 1) 能转化为int32/int64:Delta+RLE+Lz4;
2)不能转化的:Lz4
high Dict / Zstd
(Dict优先级高) Delta+RLE+Zstd 1) 能转化为int32/int64:
Delta+RLE+Zstd;
2)不能转化的:Zstd
1) 能转化为int32/int64:Delta+RLE;
2)不能转化的:Lz4
18. 列存储延迟物化扫描优化
支持Late Read(a)多列扫描时、逐
列进行predicate。相比传统方式(b)
减少后续列的数据扫描量。
19. 列存储索引支持及优化
B-Tree索引
Hash索引
20. 列存Stash表自动合并能力
Stash Table(Row Format)
小数据量插入
小数据量更新
自动 Stash
Merge
批量导入
批量更新
列存表支持创建配套Stash行存表
小数据量插入/更新会进入Stash表中
批量插入更新会直接写列存Silo格式
PM背景Auto Stash Merge进程自动判
Columnar Format
Silo1 Silo1
Silo2 Silo2
Silo3 Silo3
断stash表大小进行列存格式规整。
通过列存+stash表达到RO/WO的统
一。
21. • CDW PG发展历程介绍
• 整体构架演进
• 自研列式存储
• 执行引擎能力优化
22. 多层级并行能力提升
select * from tbl_a, tbl_b where tbl_a.f1 = tbl_b.f2;
TBL_A(f1--分布列, f2)
节点级并行
TBL_B(f1--分布列, f2)
CN
全并行计算可以榨干硬件的潜力
是做复杂查询的必经之路。
TBL_A.f1 = TBL_B.f2
DN1 DN2 DN3
TBL_A.f1 = TBL_B.f2 TBL_A.f1 = TBL_B.f2 TBL_A.f1 = TBL_B.f2
进
程
级
并
行
X4
X3
X2
X1
SSE 2/3 OP
SIMD指令级并行
X4
X3
X2
X1
SSE 2/3 OP
Y4
Y3
Y2
Y1
X4 X3 X2 X1
Y4 Y3 Y2 Y1
SSE 2/3 OP
Y4
Y3
Y2
Y1
23. 向量化执行引擎
传统的查询执行引擎与向量化查询执行引擎对比
传统查询执行引擎采用火山模型,按照一次处理一个元组的方
式,逻辑简单,但效率比较低。
CPU时间大部分在遍历查询操作树,而不是真正处理数据。
数据和指令的缓存命中率低,需要从内存或者磁盘读取。
无法利用现有新硬件提供的SIMD能力来加速查询的执行。
向量化查询执行引擎仍然采用火山模型,但是按照一次处理一
组元组的方式,需要批量处理,效率高。
减少函数调用开销,提高指令、数据的缓存命中率,提升CPU的执行
效率。
按照列组织形式可以将一组元组表示成一组列向量,每个列向量对应
的一整块连续数据可以读入缓存进行处理。
24. Plan Hint自动调优能力
25. 集群资源管理
CN1
CN2
并发控制
CN3
由leader CN节点统一规划资源组使用情况
优化器根据memory_limit来设置query中不同
内存控制
算子的work_mem内存占用。
CPU通过cgropu来配置占用百分比或者绑
核,所有当前资源组启动的backend进程会挂
CPU控制
Admin group Admin group Admin group
Default group Default group Default group
User group User group User group
C Group C Group C Group
在对应cgroup上。
用户可以通过sql查询资源使用情况。
26. CDW PG高效数据交互工具
数据导入
• TDX服务器负责外部数据源对接
• CDW PG引擎通过外部表定义与TDX服务
器资源进行绑定。
• 数据由DN节点并行进行导入与数据重分布,
充分利用分布式系统资源。
数据导出
• 支持并行多任务导入导出、管道、错误表
等高级功能,提高用户体验。
• 相比传统Copy入库出库性能有数十倍提升。
27. 多平面能力提供一致的读扩展性
业
务
读/写请求
读写分离
只读请求
VPCGW
Coordinator
Datanode
Coordinator
Datanode
Data Forward Bus
Datanode
VPCGW
Coordinator
Datanode
集群数据交互总线
读写平面
Coordinator
内
部
复
制
Datanode
Coordinator
Datanode
Data Forward Bus
Datanode
Coordinator
Datanode
集群数据交互总线
只读平面1
28. 后续规划
腾讯云上线
构架优化
持续打造生态
异步执行框架 列存优化升级 持续融合PG社区能力
FN能力提升 向量化引擎深度优化 Oracle兼容能力持续提升
自研列存储 算子并行计算优化 支持大数据生态对接
分布式延迟物化技术 SIMD优化场景覆盖 机器学习算法支持
29.
30.