Sql 等⽅式访问 UDW 2. Master Node：访问 UDW 数据仓库的⼊⼝ 接收客⼾端的连接请求 负责权限认证 处理 SQL 命令 调度分发执⾏计划 汇总 Segment 的执⾏结果并将结果返回给客⼾端 3. Compute Node： Compute Node 管理节点的计算和存储资源 每个 Compute Node 由多个 Segment 组成 Segment 负责业务数据的存储、⽤⼾ \w [⽂件名] 将查询缓冲区写出到⽂件 4. 输⼊∕输出选项 \echo [字串] 向标准输出写出⽂本 /i ⽂件名 执⾏来⾃⽂件的命令 \o [⽂件名] 向⽂件或者 |管道 发送所有查询结果 5. 信息选项 \d [名字] 描述表, 索引, 序列, 或者视图 \d{t|i|s|v|S} [模式] (加 "+" 获取更多信息) 列出表/索引/序列/视图/系统表 \da [模式] | NOT DEFERRABLE ] [ INITIALLY DEFERRED | INITIALLY IMMEDIATE ] 命令: CREATE TABLE AS 描述: 以⼀个查询的结果定义⼀个新的表 开发指南 Greenplum数据仓库 UDW Copyright © 2012-2021 UCloud 优刻得 114/206 语法: CREATE [ [ GLOBAL

外部表“方 式来访问、加载 HadoopFS 的数据，虽然 Greenplum 的 Hadoop 外部 表性能大幅低于 MPP 内部表，但比 Hadoop 自身的 HIVE 要高很多（在 某金融客户的测试结果，比 HIVE 高 8 倍左右），因此可以考虑在项 目中同时部署 MPP 数据库和 Hadoop，MPP 用于交互式高性能分析， Hadoop 用于数据 Staging、MPP 的数据备份或一些 ETL 、 易扩展等方面的卓越表现是分不开的 。 1. 高吞吐 该客户大数据平台的 ODS 区，接入了源端近百个业务系统的生产数据， 每天需要加载进来的数据大概 5TB 左右。标准化处理完成后，需要给 后端的公共访问、类别繁多的沙箱类应用供数。 每月月初，业务繁忙时段，保守估计平均每天需要给下游系统提供 10TB 的压缩数据。如此大规模数据处理，加上严格的数据时效性要求， 不选择 Greenplum 节点是对外服务的入口，用户所有的请求都必须 先经过 master，所以 master 节点的可用性直接关系到集群的稳定， 但从实践经验来看，由于 master 节点只存元数据，只负责 SQL 的解析、 分发以及最终计算结果的展现，所以承担的负载一般都非常小，故障 率也极低，在我们维护阿里 Greenplum 集群 3 年的时间里，以及接触 到的客户中，基本上没有碰到由于 master 故障导致集群不可用的情况， 唯一一次，还是因为客户误操作同时将

业的建议和解决方案，提供最专业的技术支持服务，提供最专业的落地实施支持。 十多年来，参与过的项目不计其数，有 POC 测试，有开发支持，有故障支持，有 长期驻场支持，有临时的功能支持，甚至可能会作为用户看不见的后端支持，总之，我 们的目标是，努力解决用户的一切不违背自然规律的诉求，我们跟随着 Greenplum 的 成长，见证了 Greenplum 从闭源到开源的成长历程，一路给 Greenplum 做各种补丁 作，用户可以像使用一个普通的单机数据库那样，进行访问和执行 SQL 操作。其中 Master 是整个系统的访问入口，负责处理客户端的连接和 SQL 命令、协调系统中的 其他实例协同工作，计算实例负责管理和处理具体的业务数据，并将处理结果反馈给 Master。 这一章节介绍组成 GP 数据库系统的组件及如何协同工作：  管理节点：Master  计算实例：Instance  内联网络：Interconnect Instance 上。 Master 负责客户端的登录认证、SQL 命令接收并生成并行执行计划、对执行计划进行 优化、在 Instance 之间分发执行计划、整合 Instance 处理结果、将 Instance 的 处理结果汇总并反馈给客户端程序。 目前，GP 还不支持 Master 的自动故障切换，不过，已经有很多人适用工具或者 脚本的形式实现了 Master 和 Standby 的自动 FailOver

体系架构：海量并行处理体系，针对商务智能/数据仓库 进行了优化，解决了所有数据流瓶颈问题 Greenplum数据引擎 全球最强大的分析数据仓库 海量并行查询 • 可以比以往更快地获取 查询结果 • 在数据增长的同时确保 高性能分析 统一的分析处理功能 • 为数据仓库、市场、 ELT、文本挖掘、统计 运算提供统一的平台 • 可以使用SQL、 MapReduce、R等在 所有层次上对任何数 客户投产环境：针对表C的一个子表（记录数约为C表的1/10） 进行全表扫 描，历时超过20分钟。 结论：如果采用DWA替代现有环境，获得超过120倍的性能提升。 • 真实应用测试 – DWA测试结果：完成应用的全过程仅耗时48分钟。 – 客户投产环境：客户11月份月度处理时，完成本项任务需要65小时。 结论：如果采用DWA替代现有环境，获得超过80倍的性能提升。 案例分享：阿里巴巴 • 业务用例 本项测试的目的是通过SQL查询检验Greenplum数据库引擎处理Query计算的响应 速度。 测试方法：针对数据加载测试中的三张大表，模拟生产业务需求进行复杂SQL语句查 询(参看附录)。 测试结果如下面两表： 语句名 Oracle查 询时长 Greenplu m查询时 长 GP提升倍数 备注 SQL1 1800秒+ 33.16秒 54X+ SQL2 A 1800秒+ 17.49秒 105X+

LD_LIBRARY_PATH=/path/to/your/psql/lib 2.2.7 gpstart 失败，并且原因不明 $ gpstart -v // 使用 verbose 模式，显示每个执行的命令以及其结果。 遇到的一个问题报错如下： unable to import module: No module named psutil 原因是 psutil 这个python包没有安装，但是使用 python rows=2 width=12) Optimizer status: legacy query optimizer 使用 explain.pl 可以生成如下的查询计划图：(把上面的explain结果保存到一个名为 a.plainplan 的文件中） $ explain.pl -opt jpg < /tmp/a.plainplan > /tmp/a.jpg 从上图可以很明显看出该计划包含两个 接收 数据。发送数据者可以根据不同的策略将数据发送给接收方，现在支持的策略有1）重分布（ redistribution）；2）广播（broadcast）。 最后每个segment执行结束后，将结果发送给 Master。Master 对最终的数据整合（Gather Motion），返回给客户端。 4. 调试 Greenplum MPP 数据库 4.1 调试 Master 节点Backend进程

特性 2017.thegiac.com 客户端 数据库服务器器 Master Segment 1 Segment 2 Segment n … SQL 存储过程 结果集 String 聚集 psql … 执⾏行行流程 2017.thegiac.com External Sources Load, streaming, etc. org/wiki/PageRank 示例例 - PageRank 2017.thegiac.com 计算 数据 示例例 - PageRank 2017.thegiac.com 计算结果 示例例 - PageRank 2017.thegiac.com Greenplum 集群规模: ● 1 主 ● 4 数据节点 ● 每个节点6个segment 每个定点有50个边的图 100 分钟 ● 934 特征 ● 1,438 ⾏行行代码 ● 30 分钟 多 495 个特征，快 3.33x 信息价值 ● ~450 个变量量，~30分 钟计算结果并写⼊入 excel ● 在 GPDB 中花 58 秒计 算 ~200 个变量量的IV 13.7x/变量量 建模 ● < 50 个变量量，运⾏行行⼀一 次逻辑回归迭代需要 ~30

1 业务数据的产生 —— OLTP • 2 业务数据的中转 —— ETL服务器 • 3 数据的存储和计算 —— OLAP集群 • 4 结果数据的展现 —— 数据集市 • 5 访问接口的封装 —— API接口服务器 • 6 最终数据的显示 —— 前端界面 • 7 结果数据的交互 —— OLTP，趋势分析 • 8 OLAP数据流转 —— dbsync平台 7 数据仓库体系架构 数据架构示意图 8 各机房ETL服务器在备份到备份服务器 • 结果数据备份 Ø Greenplum集群与postgresql集市备份 Ø 结果数据csv文件备份 Ø 结果数据到备份postgresql实例 28 Greenplum运维体系 数据库数据传输与同步 • 数据同步情况分类 Ø reader端与writer端 Ø 全量，id列增量，date列增量 Ø datax,csv,load,copy Ø 数据同步结果确认与显示 • Greenplum扩展规划 新业务上线流程 • 把握三个方面，解决三个问题 Ø 确认数据来源与传输，解决原始数据从那里来的问题 Ø 确认数据如何计算，解决数据存储和计算加工的问题 Ø 确认数据集市状态，解决结果数据最终展示的问题 • 实现方式 Ø OLAP与OLTP不同，没有非常固定的方式 Ø 没有事务性工作 Ø 只有针对每个业务需求的架构新、探索性、创新性工作 41 Greenplum扩展规划

自从开源以来，可以通过 cn.greenplum.org 网站下载和编译的版本与商业版将具有相同的内核（只有 个别微小差别），这是近年来致力于扩展和融入以 Greenplum 为中心的生态系统和社区的结果，用户可基于开放的 完全兼容欧拉开源操作系统的 HTAP 数据平台 Greenplum tools 中的 99 个查询任务，并记录查询时间。 4. 重复 5 次测试。 以下所有测试数据均由 5 次测试后计算得出的均值。在各操作系统进行的 Greenplum TPC-DS 测试结果如下，参数说 明： 完全兼容欧拉开源操作系统的 HTAP 数据平台 Greenplum ms(毫秒)。查询所消耗的时间越小性能越好。 最后对全部执行 99 个查询的总耗时进行了统计。 *限于测试资源仅做了较小数据集，测试结果仅供参考 e. 结果展示 Greenplum 6.17.0 on openEuler(ARM)测试结果如下： 自此，Greenplum 在欧拉开源操作系统上的合作工作介绍完毕，已经满足客户的可用性，但是仍然需要在性能方面继 续努力。

调度器 本地存储 主节点Segment 系统表 分布式事务 Interconnect 执行器 解析器 发送查询计划给各 个Segments 分配处理查询需要 的集群资源，收集 并返回结果给客户 端 主节点 Segment 实例 本地事务 执行器 系统表 本地存储 Segment 主机 Segment 实例 Local TM 执行器Executor Catalog Only 执行器 本地存储 主节点Segment 系统表 分布式事务 Interconnect 解析器 发送查询计划给各 个Segments 分配处理查询需要 的集群资源，收集 并返回结果给客户 端 主节点 Segment 实例 本地事务 执行器 系统表 本地存储 Segment 主机 Segment 实例 Local TM 执行器Executor Catalog Interconnect 本地存储 主节点Segment 系统表 分布式事务 Interconnect 解析器 发送查询计划给各 个Segments 分配处理查询需要 的集群资源，收集 并返回结果给客户 端 主节点 Segment 实例 本地事务 执行器 系统表 本地存储 Segment 主机 Segment 实例 Local TM 执行器Executor Catalog

Distribution) 数据分布策略 Confidential │ ©2021 VMware, Inc. 10 哈希分布是分布式数据库最为常用的数据分布方式。根据用户自定义的分布键计算哈希值，然后将 哈希结果映射到某个 Segment 上。在 Greenplum 6 中，默认采用一致性哈希(Jump Consistent Hash)分布策略。 哈希分布 当增加一个新的节点时，需要对原有数据进行重新映 Broadcast Motion Confidential │ ©2021 VMware, Inc. 19 Gather Motion 用于收集 Segments 所发送的所有数据，不一定是最终结果数据，Coordinator 可能需要对收集的数据进行进一步地加工和处理，例如对 Segments 所发来的有序 Tuples 进行 Merge 操作。 Gather Motion postgres=# 节点上负责处理用户查询请求的进程称为 QD (Query Dispatcher) 进程。当 QD 进 程收到客户的 SQL 时，就会对其进行解析、重写和优化，并将分布式查询计划发送给 Segment 节点进行执行，并将最终结果返回给客户端。 Segment 节点上负责执行 QD 分发来的查询任务的进程称为 QE (Query Executor) 进程，递归 遍历 QD 发来的计划树，对每一个节点按照拉模型 (火山模型)