Pivotal 姚延栋&吕正华 Greenplum 混合交易与分析处理 (HTAP) 之路

CodeWarrior

2019/07/08 发布于 编程 分类

GIAC2019 

文字内容
1. Greenplum 混合交易/分析处理 (HTAP)之路 姚延栋 吕正华 Pivotal Pivotal 研发总监 高级软件工程师
2. Greenplum 混合交易/分析处理 (HTAP)之路 姚延栋 吕正华 Pivotal Pivotal 研发总监 高级软件工程师
3. Pivotal PivotalR BOSH KUBO
4. ⼀ 、⼤纲 • Greenplum 介绍 • Greenplum 架构 • Greenplum 路线图 • Greenplum 混合负载(HTAP)优化
5. Greenplum 介绍
6. 数据库领域牛人: 4位图灵奖得主 Charles Bachman 1973 Edgar ’Ted’ Codd 1981 Jim Gray 1998 Michael Stonebraker 2014
7. PostgreSQL Thomas Lockhart Jolly Chen Vadim Mikheev Jan Wieck Andrew Yu Tom Lane Bruce Momjian Marc Fournier
8. Greenplum: 2003年创立,基于 PostgreSQL 的分布式集 群 Scott Yara 创始⼈ Luke Lonergan 创始⼈ Ray Feng Greenplum中国研发创始⼈
9. Gartner 2019 排名: 经典分析全球第三;实时分析并列第四;前⼗唯⼀开源
10. Hadoop 市场是SQL市场,是分析型数据市场 ● Hadoop 含义的演进: HDFS/MR/Hive/Hbase ● Hadoop 发布在技术未成熟前已经过时(Gartner 2017) ● 70%的Hadoop部署未达成目标(整合困难,技能不足) ● Strata+Hadoop à Strata (2018 年) ● Cloudera:75% 的 Hadoop 市场是 SQL 市场, ● Facebook: 95+% Hive ● Spark: 即使是 Spark, Spark SQL 70%
11. 大数据 ≈ 分布式数据库
12. Greenplum 架构
13. Greenplum: 是集群化的 PostgreSQL
14. 集群化 – 为用户提供一个逻辑上透明的数据库
15. Greenplum 极简拓扑
16. Greenplum 最突出的架构特色:MPP(大规模并行处理)
17. 对用户透明的分布式数据库 pg_catalog master sales 1. 分布式数据存储 2. 分布式查询处理 customers pg_catalog pg_catalog 3. 分布式ACID sales customers sales segment customers pg_catalog sales customers segment
18. 分布式数据存储:数据分布 sales c1 c2 c3 segment segment segment segment segment segment
19. 分布式查询处理:分布式查询优化 CREATE TABLE students (id int, name text) DISTRIBUTED BY (id); CREATE TABLE classes(id int, classname text, student_id int) DISTRIBUTED BY (id); SELECT s.name student_name, c.classname FROM students s, classes c WHERE s.id=c.student_id
20. 分布式查询处理:查询执行 QD Gather receiver Master QE:s2 QE:s2 Motion Sender Motion Sender HashJoin HashJoin Gang 2 Hash Motion receiver QE:s1 Hash SeqScan students Motion receiver QE:s1 Motion sender Motion sender SeqScan classes SeqScan classes Gang 1 Segment 1 Segment 2 SeqScan students
21. 分布式 ACID: 2阶段提交 à A(原子性) 和 D(持久性) 分布式事 务管理器 all prepared 阶段 1 ar s p pre e: ye t veo pre evot par yes e: segment 1 yes 分布式事 务管理器 segment 2 yes done 阶段 2 mi m co ack t com t a mi ck segment 1 comm it segment 2 commi t
22. 分布式ACID:全局快照 + Lock à I(隔离性) Global snapshots Used slot
23. 分布式ACID:全局快照 + 全局锁管理器 à C
24. Greenplum 路线图
25. Greenplum 6: 预计 2019年7⽉发布 • 内核升级: PostgreSQL 8.4, 9.0, 9.1, 9.2, 9.3, 9.4, 9.4.20 • 基于流复制的全新高可用机制:扩展性强、无代码侵入性 • 在线扩容:不停机、不停业务、数据移动量少(一致性Hash) • 混合负载增强(HTAP):性能提升60x • 流式数据支持:Kafka à gpkafka à Greenplum • 磁盘配额 • Zstd 压缩算法 • 灵活的数据分布:横向 + 纵向 • Kubernetes 原生支持:SIGMOD paper • 数据库内建机器学习、深度学习增强(Apache MADLib) • GPCC (Greenplum Command Center)
26. Greenplum 7: 预计 2020年底 • 内核升级: PostgreSQL 9.5 (几乎结束),PostgreSQL 9.6 • 行级安全控制 • BRIN 索引 • 全新的DR机制 • OLAP 性能、并发 • 单机单segment部署(基于PostgreSQL 9.6 并行扫描) • 物化视图 • Greenplum 联邦 • 混合负载、OLTP 能力持续增强 • … 10/11/12: JIT、pluggable 存储、分区 (Greenplum 8.0)
27. Greenplum 6 性能:TPCB 60x;单条查找 3.5x https://greenplum.cn/2019/05/14/greenplum-6-oltp-60x/
28. Greenplum 6 性能:单条更新 70x;单条插⼊:3.6x https://greenplum.cn/2019/05/14/greenplum-6-oltp-60x/
29. Greenplum 混合负载优化
30. OLTP 优化 • 内核升级 • 复制表 • 全局死锁检测 • 锁优化 • 事务优化
31. 全局死锁检测(Global Deadlock Detector) • 局部死锁和全局死锁 • 解决全局死锁的思路 • 全局死锁的案例分析 • 全局死锁检测算法
32. 局部死锁——Postgres的deadlock模块 • 死锁发生在同一个segment(Postgres Instance)内 • Postgres已经有完善的模块检测并破解这类死锁 • 当一个事务超过一定时间拿不到某个锁会发出SIGALRM信号 • SIGALRM信号的handler会扫描共享内存进行寻找死锁等待环 • 检测出死锁,Postgres会强制结束等待环中的关键事务,从而破解死锁
33. 局部死锁̶̶例⼦ • Postgres基于MVCC的并发控制,update delete操作会把当前事务号写入 到tuple的xmax里 • 当并发的事务update delete同一个tuple的时候(读提交隔离级),会先检测 该tuple的xmax,如果被设置了且对应的事务没有结束,则必须等待xmax 对应的事务提交
34. 局部死锁̶̶例⼦ • 一个事务内的语句间存在对同一个对象升锁行为,会极大提升死锁的概 率 • Postgres的文档里明确不建议用户在实际环境中编写这样的SQL程序 • 同一句Statement执行过程中会对同一个对象反复拿锁,这个过程也是严 格控制不能升锁
35. 全局死锁̶̶Greenplum 5以及之前版本的解决⽅案 • Postgres在insert update delete语句中对目标表持RowExclusiveLock,因此它们 可以并行的执行 • Greenplum 5(及以前版本)不具备全局死锁检测模块,因此为了杜绝这类全局死 锁,在QD上的parse和plan阶段,在insert update delete语句中对目标表持 ExclusiveLock • 虽然杜绝了这类全局死锁的发生,但矫枉过正,insert delete update同一个表无 法并行
36. 全局死锁̶̶例⼦ • 假设Greenplum仿照Postgres的持锁行为,会产生怎样的全局死锁呢? • 不论seg0还是seg1都没有死锁,因此Postgres的死锁检测模块无法破解这个 全局死锁 • Master上的任何一个事务都无法结束(在seg0和seg1分别等候对方结束)
37. 全局死锁检测̶̶解决⽅案综述 • 为了保证混合负载的性能,在QD上必须保持和Postgres一致的持锁行为,即在 Update Delete中对目标表只有RowExclusiveLock,让这些事务在Greenplum中并 发执行 • 在QD上引入global deadlock detector进程,周期的从各个segment获取全局事 务之间的等候信息,汇总后执行死锁检测算法 • Greenplum在处理全局死锁上的策略是检测,而非规避 • 周期性从Master上触发一次检测行为(区别于Postgres的SIGALRM触发) • GUC控制GDD的开关: gp_enable_global_deadlock_detector • 上面的GUC打开的情况下, gp_global_deadlock_detector_period控制检测周期 • gp_dist_wait_status这个UDF可以返回每个segment上的等候关系
38. 全局死锁检测̶̶核⼼算法 • 全局死锁检测和核心算法在收集到了每个segment(含master)的等候关系后,如 何寻找死锁环的 • 用全局事务号表示等待关系图的顶点 • 每个segment上的所有等待关系,构成一个子图,称为局部子图 • 全局的等待关系由所有局部子图联合构成 • 每个等候关系有一个附件属性(solid or dotted) • A -> B: solid等候,只有事务B结束(commit或abort),等候关系才消失 • A ··> B: dotted等候,等候关系可以在事务B没有结束的之前消失 • 贪心算法 • 全局贪心: 删除全局出度为0的顶点和指向它的所有边(等候关系) • 局部贪心: 每个局部子图中,假设局部出度为0的顶点是C(每个局部子图之 多有一个),删除所有指向C的dotted等候关系
39. 全局死锁检测̶̶核⼼算法 • 重复执行贪心删除策略,直到无法删除任何边(等候关系)为止 • 如果这时候还有边(等候关系)剩下,且剩下的所有顶点对应的全局事务都还没有 结束,则判定全局死锁发生 • 贪心策略配合最后的事务存在性检测,可以保证算法的正确性 • 破解死锁可以采用不同的策略,如: • 优先强制结束最“年轻”的事务 • 优先强制结束消耗资源最多的事务
40. 全局死锁检测̶̶复杂的例⼦
41. 全局死锁检测̶̶复杂的例⼦
42. 全局死锁检测̶̶开发回顾于思考 • 最终的算法非常简洁且优雅,但开发的过程涉及到多次团队的讨论和 工程师深入的思考,回顾这个过程: • 测试先行:在没有代码原型之前,已经写好了test cases,这个过 程不仅是TDD开发,思考解决每个test cases的特点和难点直接诱 导出算法的细节(Pivotal软件开发的管理流程) • 前人的思路:2016年的时候再Greenplum Dev mailing list里 Heikki等工程师提出了多个版本的思路,仔细分析这些思路的本 质,让团队深入理解了全局死锁问题(开源社区的重要性) • Corner case:select for update等语句的混合负载优化,复制表 和AO表的并发控制持锁行为等,都得到了深入的研究 • 很多额外的收获:GPexpand在进行数据重分布的时候,会修改 status表,Greenplum 5之前是串行的,有GDD后并发,提升了 GPexpand重分布大量小表的性能
43. 其他优化 • 减少轻量级锁冲突: • Greenplum中文社区的博文: https://greenplum.cn/2019/06/20/greenplum-kernel-optimization/ • 优化分布式事务: • 只读的事务不需要创建分布式snapshot • 单条语句的事务如果只dispatch到一个segment,可以不用两阶 段提交 • 只读的事务(在segment上没有产生XLOG)不需要两阶段提交 • 带有locking clause的Select语句的优化 • 更多优化还将根据需求持续进行
44. 欢迎加入Greenplum中文社区: http://greenplum.cn 关注公众号获得 更多案例实践
45. 欢迎关注msup微信公众账号 关注大会微信公共账号,及时了解大会动态、 日程及每日更新的案例! 关注公众号获得 更多案例实践
46. 2008:MapReduce 是技术大倒退 作为一种数据处理模式,MapReduce 是一种大倒退。 ● 模式(Schema)很有价值 ● 实现糟糕,不支持 Access Method ● 高级访问语言很有价值 Google 内部2011年放弃MR,2015年公开放弃
47. NoSQL 的局限性 ● 不支持SQL,开发人员自己实现复杂的代码,进行聚集分析等。 ● 不支持ACID和事务,实现大量代码处理数据不一致 ● 不支持关联,只得使用宽表,引起数据冗余,维护代价高 ● 使用低级查询语言,数据独立性差,灵活性差,维护代价高。 ● 缺少标准接口,学习代价高,应用使用代价高,需要大量胶水代码 ● 缺少生态,从数据迁移、ETL、报表、BI、可视化都要从头开发 ● 多种 NoSQL 产品的引入,数据整合代价高 ● 人才缺乏,企业积累的大量SQL人才和资产浪费