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.

ホーム - Wiki
Copyright © 2011-2024 iteam. Current version is 2.137.1. UTC+08:00, 2024-11-15 17:38
浙ICP备14020137号-1 $お客様$