74 74 74 74 75 76 76 79 81 82 90 92 101 102 103 104 106 128 访问 访问UDW数据仓库 数据仓库 1 客⼾端⼯具访问UDW 2 图形界⾯的⽅式访问UDW 数据导⼊ 数据导⼊ insert加载数据 copy加载数据 外部表并⾏加载数据 从hdfs加载数据 从mysql中导⼊数据 从oracle中导⼊数据 优刻得 7/206 1. Client：访问 UDW 的客⼾端 ⽀持通过 JDBC、ODBC、PHP、Python、命令⾏ Sql 等⽅式访问 UDW 2. Master Node：访问 UDW 数据仓库的⼊⼝ 接收客⼾端的连接请求 负责权限认证 处理 SQL 命令 调度分发执⾏计划 汇总 Segment 的执⾏结果并将结果返回给客⼾端 3. Compute Node： Compute Node Copyright © 2012-2021 UCloud 优刻得 8/206 如上图所⽰： 1. Compute Node 中任⼀ Segment 都会有⼀个 Mirror Segment 备份到其他的 Compute Node 上，当 Primary Segment 出现不可⽤的时候会⾃动切换到 Mirror Segment， 当 Primary Segment 恢复之后，Primary Segment

长期驻场支持，有临时的功能支持，甚至可能会作为用户看不见的后端支持，总之，我 们的目标是，努力解决用户的一切不违背自然规律的诉求，我们跟随着 Greenplum 的 成长，见证了 Greenplum 从闭源到开源的成长历程，一路给 Greenplum 做各种补丁 脚本，也看到了 Greenplum 的大幅进步，甚至我们以前的小技巧也不再需要，持续的 进步，带来的是生态的蓬勃发展。 Greenplum .................................................................................. - 31 - 第四章：配置客户端认证 ................................................................................................. ...................................................................................... - 36 - 客户端/服务端间的加密连接 ......................................................................................... -

Greenplum 集群通常由一个 Coordinator 节点、一 个 Standby Coordinator 节点以及多个 Segment 节点组成 l Coordinator 是整个数据库的入口，客户端只会连接 至 Coordinator 节点，并执行相关的查询操作 l Standby 节点为 Coordinator 提供高可用支持 l Mirror 则为 Segment 提供高可用支持 7 Hash/Randomly/Replicated Confidential │ ©2021 VMware, Inc. 8 数据存储分布化是分布式数据库要解决的第一个问题。 通过将海量数据分散到多个节点上，一方面大大降低了单个节点处理的数据量，另一方面也为处理 并行化奠定了基础，两者结合起来可以极大的提高系统的性能。譬如在 100 个节点的集群上，每 个节点仅保存总数据量的 1/100，100 中，tuple 要么保留在原有节点中，要么迁移至新的节点中，从而实现最小数据迁移。 Confidential │ ©2021 VMware, Inc. 11 随机分布则采用随机的方式将数据存储到不同的节点。当不确定一张表的哈希分布键，或者是不存 在合理的避免数据倾斜的分布键时，即可采用随机分布的方式。 随机分布与复制分布 复制分布则表示整张表在每个节点上都有一份完整的拷贝，假设我们有 100

每个Instance都是一套独立的进程，当客户端 发起一个请求时，每个Instance都将FORK子进 程并行工作； • 对于并发请求高、面向于复杂的灵活查询的系 统，建议每个Segment配置4个或以下Instance， 这样来保证每个Instance所需资源，保证系统 系统运行稳定性，例如，减少OOM发生的概率； • 对于以批处理、串行工作为主的系统，可以配 置到8个Instance，这样可以尽可能的发挥每个 Analyze， 只在结果中返回的列无需收集统计信息；  对于频繁创建表删表的系统，可关闭gp_autostate_mode(on_no_stats=> on_change) ，数据变化量达 到一定阀值才收集统计信息； – gp_autostats_mode = on_change – gp_autostats_on_change_threshold = 5000000（资料依据项目而定） 注：delete all用truncate代替，truncate无需回收垃圾空间 垃圾空间回收  Vacuum：标记垃圾空间为可再利用 Vacuum用于将数据表垃圾空间标记到FSM（自由空间映射），一般也不回收空间，当往该表插入新数据时，数据库会重 新这些空间。 FSM驻留在内存中，FSM的大小必须足够标记数据库中的所有过期记录。如果尺寸不够大,超出自由映像空间的过期记录

和 Master- Slave 有何区别? 在 Master-Slave 模型下，Master 和 Slave 拥有相同的数据，并且 Master 是存储和处理数据的唯⼀⼊⼝，Slave 仅复制 Master 的 数据。⽐如 MySQL 的主从模型、Redis 的主从模型 在 Master-Segment 模型下，⾸先 Master 节点不存储数据，其次就是数据将会以分⽚的⽅式存储在多个 Segment 节点中。这⾥可以 类⽐ Redis Cluster，只不过 Redis Cluster 是去中⼼化的。在 Master-Segment 模型中通常也会包含 Master-Slave 模型，也就是增 加数据副本，以实现⾼可⽤ 简单地来说，Master-Slave 主要进⾏数据复制（冗余），⽽ Master-Segment 则会同时进⾏数据分区（⽔平扩展）和复制（冗余） 分区与分⽚ 某种规则将数据尽可能均匀地分布到各个节点上 ，这个过程通常称之为分⽚ GP 同时⽀持数据的分⽚和分区，具体的分⽚和分区规则将会 在后⾯的总结中详述 同时，GP 在存储上⽀持多态存储，也就是对于同⼀份数据，既可以选择基于⾏的存储⽅式，也可以选择基于列的存储⽅式，并且⽀持诸如 S3、HDFS 等外部存储 GP 基本查询流程 PostgreSQL 进程模型 PostgreSQL（以下简称

Greenplum 的起源 Greenplum 最早是在 10 多年前（大约在 2002 年）出现，基本上 和 Hadoop 是同一时期（Hadoop 约是 2004 年前后出现的，早期的 Nutch 可追溯到 2002 年）。 互联网行业经过之前近 10 年的由慢到快的发展，累积了大量信息和数 据，数据在爆发式增长，这些海量数据急需新的计算方式，需要一场 计算方式的革命。 传统的主机计算模式在海量数据面前，除了造价昂贵外，在技术上也 MapReduce 并行计算框架的理论，分布式计算模式在互联网 行业特别是收索引擎和分词检索等方面获得了巨大成功。 Big Date2.indd 1 16-11-22 下午3:38 2 由此，业界认识到对于海量数据需要一种新的计算模式来支持，这种 模式就是可以支持 Scale-out 横向扩展的分布式并行数据计算技术。 当时，开放的X86服务器技术已经能很好的支持商用，借助高速网络（当 时是千兆以太网）组建的 是必备的利器，缺少这些关键功能非常致命，将难于在 OLAP 领域充当大任。我们最近对基于 MYSQL 的某内存分布式数据库做 对比测试时，发现其优点是 OLTP 非常快，TPS 非常高（轻松搞定 几十万），但一到复杂多表关联性能就立马下降，即使其具有内存 计算的功能也无能为力，就其因估计还是受到 mysql 在这方面限制。 3) 扩展性方面，Postgresql 比 mysql 也要出色许多，Postgres

备份通过rsync传输到同机房ETL服务器 Ø 各机房ETL服务器在备份到备份服务器 • 结果数据备份 Ø Greenplum集群与postgresql集市备份 Ø 结果数据csv文件备份 Ø 结果数据到备份postgresql实例 28 Greenplum运维体系 数据库数据传输与同步 • 数据同步情况分类 Ø reader端与writer端 Ø 全量，id列增量，date列增量 Ø datax,csv 继续建设多样化的postgresql数据集市，满足不同需求 • 优化现有业务的调度实现 Ø 时间周期的考量 Ø 并发与功能实现的权衡 Ø 增强任务可控性和可度量性 • 支持符合条件的新业务 Ø 抽象业务模型，整合使用分类 Ø 简化上线模型，优化上线方式 40 Greenplum扩展规划 新业务上线流程 • 把握三个方面，解决三个问题 Ø 确认数据来源与传输，解决原始数据从那里来的问题 Ø 确认数据如何计算，解决数据存储和计算加工的问题

分布式计划举例 Confidential │ ©2022 VMware, Inc. 13 分布式执行和事务 Ø 火山/流水线模型 Ø QD(query dispatcher)负责下发查询，QE(query executor)负责执行查询 Ø 查询的生命周期: 1) 客户端连接coordinator, coordinator fork出QD 2) QD 拿到纯文本的查询，解析、优化、生成一个树形结构的分布式计划 5) QD 从QE归集结果，返回给客户端 Confidential │ ©2022 VMware, Inc. 14 分布式执行和事务 Ø MVCC q Xmin, Xmax 是节点本地的 Ø 分布式快照 q QD生成，下发给QE q segment本地事务异步两阶段提交，保持一致性 Ø HTAP 优化 q 全局死锁检测 q 只读事务、只涉及到某个节点的操作、vacuum Ø SIGMOD Kafka和其它流式来源 Confidential │ ©2022 VMware, Inc. 21 Greenplum 7的亮点：PostgreSQL v12 和新特性 Ø 6000+ 冲突 Ø 从9.4升级到12 Ø 80多万行改动 Ø Upsert, BRIN, JIT, … Confidential │ ©2022 VMware, Inc. 22 Greenplum 7的亮点：Greenplum

• 高性价比 • 高效率 数据库管理系统（DBMS）的 规模/容量 11 需要采用一种新的方法 •“一切皆可商用”：商业即用型x86 服务器、存储设备、网络 •通过软件很容易将处理能力扩展到 1000s的内核/系统 Greenplum • “黑盒子” • “大铁箱” • 大磁盘 过去Google™ 曾经用来实现信息搜索功能的技术， 现在被Greenplum用于数据仓库 现在的解决方案 通过Greenplum超级数据处 理引擎增强竞争优势 Greenplum数据引擎：内容和方式 价值主张 – 性价比： 性能可达到传统方案（Oracle、Teradata）的 10到100倍， 而成本只是其一小部分 – 可伸缩性：从较低的万亿字节扩展到千万亿字节 – 开放式系统：在通用系统和开放源软件的基础上创建 前提条件 – 硬件：基于开放式标准硬件 – 软件：Postgres和Greenplum – 统一的分析处理功能 • 为数据仓库、市场、 ELT、文本挖掘、统计 运算提供统一的平台 • 可以使用SQL、 MapReduce、R等在 所有层次上对任何数 据进行并行分析 19 通过经济的方案扩展 到千万亿字节规模 • 不用担心数据增长或 者开始的规模太小 • 在商用硬件上通过线 性、经济的方式扩展 Greenplum数据引擎体系 主机 网络互连 并行查询规划和调度 区段服务器

reserved. Greenplum 架构 6 Pivotal Confidential–Inter nal Use Only 平台概况 产品特性 客户端访问和工具 多级容错机制 无共享大规模并行处理 先进的查询优化器 多态存储系统 客户端访问 ODBC, JDBC, OLEDB, etc. 核心MPP 架构 并行数据流引擎 高速软数据交换机制 MPP Scatter/Gather Instance Segment Instance 节点N 8 Pivotal Confidential–Inter nal Use Only 数据分布: 并行化的根基 最重要的策略和目标是均匀分布数据到各个数据节点。 43 Oct 20 2005 12 64 Oct 20 2005 111 45 Oct 20 2005 42 46 Oct 20 2005 64 77 Oct 20 2005 Segment 3C Segment 3D 10 Pivotal Confidential–Inter nal Use Only 多级分区存储 • 哈希Distribution：数据均 匀的分布到各个数据节点 • 范围分区： 数据节点内部， 根据多种规则分区，降低扫 描量 数据集 Segment 1A Segment 1C Segment 1D Segment 2A Segment 2B