Greenplum 精粹文集 21 Greenplum 数据库在该客户发展如此迅猛，与产品在高吞吐、开放性、 易扩展等方面的卓越表现是分不开的 。 1. 高吞吐 该客户大数据平台的 ODS 区，接入了源端近百个业务系统的生产数据， 每天需要加载进来的数据大概 5TB 左右。标准化处理完成后，需要给 后端的公共访问、类别繁多的沙箱类应用供数。 每月月初，业务繁忙时段，保守估计平均每天需要给下游系统提供 还有plpythonu，这个是Greenplum自带的language，一些通用的函数， 用 plpythonu 来编写也是极其不错的选择。 关于这两种语言，可以参考 PostgreSQL 文档的【服务器端编程】章节， 以及 Perl 和 Python 语言。 Greenplum 是开放的数据库，又是开源的数据库，可以分享的知识其 实真的很多，如果你这方面的知识基础还不是很高，可以多读一些文 章然后收藏起来，慢慢进步。 密要求。解密数据、确定用户是否可以访问全部或者部分的数据也是 采用一个相似的流程。 此功能通过在加密之前捕获用户信息并将凭证传递至安装在所有 Greenplum 节点上的本地 Protegrity 代理完成加密流程。此流程与维 护、存取和应用策略 (Policy) 目录的服务器通信，在加密期间，此功 能将访问策略以应用、确定用户的数据访问权限，并根据策略解密和 掩盖数据。 Big Date2.indd

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 默认DB的名称为dev，你可以选择除了“test”、“postgres”、“template”、“template0”、“template1” 、 “default”之外的其他名称。 DB管理员⽤⼾名不能为“postgres”。端⼝固定为 5432，暂不提供修改。 快速上⼿ Greenplum数据仓库 UDW Copyright © 2012-2021 UCloud 优刻得 12/206 4.确认⽀付 快速上⼿ Greenplum数据仓库

.................................................................................. - 31 - 第四章：配置客户端认证 ................................................................................................. ...................................................................................... - 36 - 客户端/服务端间的加密连接 ......................................................................................... - ...................... - 39 - 支持的客户端应用 ............................................................................................................ - 39 - GP 的客户端应用程序 ...............................

每当有⼀个客户端连接⾄ PG 时，就会有⼀个⼦进程被创建出来。postmaster 进程和 postgres 进程之间采⽤共享内存进⾏通信 client 和 PG 之间的通信过程 client 调⽤ libpq 库向 PG 的 Postmaster 进程发起连接请求 PG fork 出⼀个 postgres 进程与该客户端建⽴连接，postmaster 进程不再处理与该客户端的相关请求 postgres 进程接收客户端的请求，处理并返回结果。当然，响应需要经过 libpq 库的处理 基本查询流程 Query Dispatcher 当 client 向 Master 发起查询请求时，Master 节点上的 postmaster 进程将会 fork 出⼀个⼦进程，叫做 Query Dispatcher（分发 器），简称为 QD 进程 QD 进程会对收到的查询请求 进程，所以仍然由 postmaster 进程负责监听端⼝，由 Query Executor（QE 进程）进程处理相关查询 QD 进程将查询计划发送给 QE 进程并执⾏，同时 QD 与 QE 进程之间、QE 与 QE 进程之间使⽤ interconnect 进⾏通信，⽽⾮ libpq 最终，QD 进程将 QEs 中得到的结果进⾏汇总，并通过 libpq 返回给客户端

reserved. Greenplum 架构 6 Pivotal Confidential–Inter nal Use Only 平台概况 产品特性 客户端访问和工具 多级容错机制 无共享大规模并行处理 先进的查询优化器 多态存储系统 客户端访问 ODBC, JDBC, OLEDB, etc. 核心MPP 架构 并行数据流引擎 高速软数据交换机制 MPP Scatter/Gather Confidential–Inter nal Use Only 解析器 主节点Segment 系统表 优化器 分布式事务 调度器 执行器 解析器执行词法分 析、语法分析并生 成 解析树 客户端 主节点接受客户连接， 处理请求，执行认证 解析器 主节点 17 Pivotal Confidential–Inter nal Use Only 优化器 本地存储 主节点Segment 本地存储 主节点Segment 系统表 分布式事务 Interconnect 执行器 解析器 发送查询计划给各 个Segments 分配处理查询需要 的集群资源，收集 并返回结果给客户 端 主节点 Segment 实例 本地事务 执行器 系统表 本地存储 Segment 主机 Segment 实例 Local TM 执行器Executor Catalog 本地存储Storage

Greenplum 集群通常由一个 Coordinator 节点、一 个 Standby Coordinator 节点以及多个 Segment 节点组成 l Coordinator 是整个数据库的入口，客户端只会连接 至 Coordinator 节点，并执行相关的查询操作 l Standby 节点为 Coordinator 提供高可用支持 l Mirror 则为 Segment 提供高可用支持 7 16 当我们插入数据时，Coordinator 将会根据分布键以及分布策略将数据分布到不同的节点中去。那 么在查询时，就需要各个节点将数据处理完毕后发送至 Coordinator 节点并返回给客户端用户。 分布式查询优化器 l 对于普通查询，只需要将 Segment 上的数据汇总即可，如果有 filter， 则在 segment 上执行条件过滤 l 对于 JOIN，我们需要考虑两张表的分布键以及分 实例。当客户端和 Coordinator 建立连接时，postmaster 会 fork 出一个子进程来为该连接提供服务。 Coordinator 节点上负责处理用户查询请求的进程称为 QD (Query Dispatcher) 进程。当 QD 进 程收到客户的 SQL 时，就会对其进行解析、重写和优化，并将分布式查询计划发送给 Segment 节点进行执行，并将最终结果返回给客户端。 Segment

postmaster.opts -rw------- 1 postgres postgres 95 Dec 9 09:02 postmaster.pid 这里是监听哪台服务器，而不是监听哪个客户端，控制哪 个客户端 -bash-4.1$ cat postgresql.conf |grep listen_address #listen_addresses = 'localhost' # 正规 的叫法是角色，role）。 多个用户以逗号分隔。 允许的客户端（ADDRESS） 格式为ip-address/mask 采用local连接方式不必填写，该项可以是IPv4地址或IPv6地址，可以定义某 台主机或某个网段。 认证方法（METHOD） METHOD指定如何处理客户端的认证。常用的有ident，md5，password， trust，reject。

• Instance是GPDB的最小并行单元，每个Segment 节点一般配置4~8个Instance，初始化完成后很 难修改，需要提前规划； • 每个Instance都是一套独立的进程，当客户端 发起一个请求时，每个Instance都将FORK子进 程并行工作； • 对于并发请求高、面向于复杂的灵活查询的系 统，建议每个Segment配置4个或以下Instance， 这样来保证每个Instance所需资源，保证系统 基于gpfdist和外部表实现，比基于命名管道的gptransfer更稳定高效  两个集群之间必须互相网络连通  集群之间无需ssh互信  源端与目标端对象名称可不一致  条件源端过滤，降低带条件场景的网络压力  源端可以是视图，自劢识别是否使用快速模式  命令可部署在可在集群外执行  自劢识别低速模式，快速模式和全速模式  可指定并发数(同时多张表传输

查询的生命周期: 1) 客户端连接coordinator, coordinator fork出QD 2) QD 拿到纯文本的查询，解析、优化、生成一个树形结构的分布式计划 3) QD 生成slice结构，生成每个slice的一系列进程结构（Gang） 4) QD 连接segment节点，segment节点fork出QE，QE执行分布式计划 5) QD 从QE归集结果，返回给客户端 Confidential

天天拍车运用互联网技术，从根本上解决了二手车跨各区域成交和流 通效率低下等问题，持续推进行业升级变革。全国二手车经销商传统 的线下收车方式正在被快速颠覆——二手车经销商通过天天拍车的在 线竞拍系统，在手机端就能轻松竞拍到全国海量优质车源，收车效率 和运营效率得以提升，这有助于二手车经销商专注于车辆整备和二手 车零售，加速行业专业化分工、实现规模化发展。 同时，天天拍车也正在布局二手车金融、二手车保卖等创新业务。截 网络带宽利用率低，且支持数据的安全传输 一些事前没有考虑到的问题： 1. 数据质量问题 0000-00-00 00:00:00 28:00:00 2. 数据乱码问题 3. DDL复制 4. 生产端历史数据purge问题 5. …… 参考：https://mp.weixin.qq.com/s/zgCfcbMKOJRYROdxjW6RNA Data lake dilemma Big+Open