Greenplum

关于greenplum:greenplum-常用链接

GP release 列表 GP6 release notes GP6 extension兼容性 GP6 对graph的反对-基于MADLAB GP6 对postgis的反对 GP6 postgis gppkg GP6 postgis github GP6 常用工具 gpbackup/gprestore官网文档 gpbackup/gprestore gppkg gpbackup/gprestore github pivotal VMware Tanzu list GP postgis培训

关于greenplum:greenplum-源码安装-all

内容蕴含源码编译装置greenplum的过程gp版本：6.22.2os: centos8virtualbox+vagrant 集群布局host角色dw1-cnmasterdw1-seg1segmentdw1-seg2segment装置过程step1，2相当于编译装置gp和系统配置，这两步对于master和segment是通用的。我是在一个vm中实现step1,2，作为master，而后在vagrant中将其导出为box，再通过这个box init 各个segment节点。这样省去了在segment节点上执行step1，2的工作。源码编译装置系统配置# 以1，2失去的vm打包boxvagrant package --base dw1-cn --output ../../boxes/dw-base.box# add boxcd ../../boxes/vagrant box add dw-base dw-base.box# 新建vm dw1-seg1vagrant.exe upvagrant ssh-config > vagrant-ssh## 批改ssh -F vagrant-ssh dw1-seg1# 新建vm dw1-seg2vagrant.exe upvagrant ssh-config > vagrant-ssh## 批改ssh -F vagrant-ssh dw1-seg2互信配置配置数据目录节点测试-TBD初始化gp

关于greenplum:greenplum-安装-6-数据目录配置

init gp

关于greenplum:greenplum-安装-4-数据目录配置

为master及segment节点配置数据目录，因为master比拟非凡，存储数据较少，目录设置和segment不同。数据目录配置 master配置master节点root用户下 mkdir -p /data/masterchown gpadmin:gpadmin /data/mastermaster-standby配置master节点root用户下 # source /usr/local/gpdb/greenplum_path.sh # gpssh -h smdw -e 'mkdir -p /data/master'# gpssh -h smdw -e 'chown gpadmin:gpadmin /data/master'segment的配置master节点root用户下创立文件hostfile_gpssh_segonly，蕴含所有segment节点dw1-seg1dw1-seg2创立 # source /usr/local/gpdb/greenplum_path.sh # gpssh -f hostfile_gpssh_segonly -e 'mkdir -p /data/primary'# gpssh -f hostfile_gpssh_segonly -e 'mkdir -p /data/mirror'# gpssh -f hostfile_gpssh_segonly -e 'chown -R gpadmin /data/primary'# gpssh -f hostfile_gpssh_segonly -e 'chown -R gpadmin /data/mirror'遇到问题(未考察)看起来是dw1-cn无奈免明码登陆dw1-seg1，dw1-seg2。但试验ssh免明码登陆没有问题 [root@dw1-cn ~]# gpssh -f hostfile_gpssh_segonly -e 'mkdir -p /data/primary'[ERROR] unable to login to dw1-seg1Could not acquire connection.[ERROR] unable to login to dw1-seg2Could not acquire connection.

关于greenplum:greenplum-安装-3-互信配置

配置 /etc/hosts172.28.128.6 dw1-cn172.28.128.11 dw1-seg1172.28.128.12 dw1-seg2# dw1-seg1, dw1-seg2上删除127.0.1.1 dw1-cn dw1-cn配置互信，过程如下参考Enabling Passwordless SSH 设置环境变量master的gpadmin用户下 source /usr/local/gpdb/greenplum_path.sh配置master到其它 node的passworldless sshmaster的gpadmin用户下 ssh-copy-id dw1-seg1ssh-copy-id dw1-seg2### 过程为将dw1-cn的publickey增加到dw1-seg1，dw1-seg2的/home/gpadmin/.ssh/id_rsa.pub### 我的dw1-seg1，dw1-seg2是通过dw1-cn打的box创立的，他们的/home/gpadmin/.ssh/id_rsa.pub来自于dw1-cn，且曾经通过setup_gpadmin_user.bash配置好。这一步实际上能够不做。配置所有的节点listmaster的gpadmin用户下编辑~/hostfile_exkeys dw1-cndw1-seg1dw1-seg2n-n互信master的gpadmin用户下 gpssh-exkeys -f hostfile_exkeys查看互信master的gpadmin用户下 gpssh -f hostfile_exkeys -e 'ls -l /usr/local/gpdb'

关于greenplum:Greenplum日期函数记录

工作中常常用到greenplum日期函数，特此记录，以便查阅！查问工夫戳对应的年月日时分秒 select extract(century from timestamp '2018-08-01 12:12:13');> 21select extract(year from timestamp '2018-08-01 12:12:13');> 2018select extract(month from timestamp '2018-08-01 12:12:13');> 8select extract(day from timestamp '2018-08-01 12:12:13');> 1select extract(hour from timestamp '2018-08-01 12:12:13');> 12select extract(min from timestamp '2018-08-01 12:12:13');> 12select extract(sec from timestamp '2018-08-01 12:12:13');> 13查问日期之间的天数差，date_depart参数为day时，返回两个日期之间的天数差，month 不起作用，hour则只截取两个日期的hour做差，不能用；月份差可在天数差的根底上除以30，算作根底的月份差。 select date_part('day','2022-05-01 00:00:00'::timestamp - '2021-03-01 00:00:00'::timestamp)> 61select date_part('month','2022-05-01 12:00:00'::timestamp - '2021-03-01 00:00:00'::timestamp)> 0select date_part('hour','2022-05-01 12:00:00'::timestamp - '2021-03-01 00:00:00'::timestamp)> 12select date_part('day','2022-05-01 00:00:00'::timestamp - '2021-03-01 00:00:00'::timestamp)/30> 2查问分组的字符串拼接函数string_agg(A,B)，需配合分组应用，A是拼接字段，B是分隔符号以及字符串拼接的排序，与mysql中的group_contact()是一个作用。例如，返回订单表中不同用户的累计信息渠道，一个用户可能在一个信息渠道停留屡次，须要去重，不同的信息渠道进行拼接，且针对所有用户拼接字段的程序要雷同统一： ...

关于greenplum:小工具Greenplum数据库中AO表和非AO表获取

--执行阐明/*该脚本是用来获取数据库中每个 schema 下是否是 AO 表，如果有 AO 表,将会存储于长期表 *tab_aotable中,如果是非 AO 表,那么将会存储于长期表 tab_naotable 中，因为存储非AO *表和AO表都是存储于长期表中的，因而在会话退出后，长期表将会主动销毁，如果须要获取， *请从新执行以下语句 */drop table if exists tab_aotable;drop table if exists tab_naotable;create temporary table tab_aotable(table_oid oid,table_name text,aotable text,cond char(1)) distributed by (table_oid);create temporary table tab_naotable(table_oid oid,table_name text,naotable text,cond char(1)) distributed by (table_oid);create or replace function f_get_aotable()returns void as$$declare v_list_toid oid; v_list_tname text; v_sql text; v_is_ao_tablename text; v_table_oid oid; v_table_name text; v_is_ao_table text; cur1 CURSOR FOR SELECT a.oid, c.nspname ||'.' || b.tablename FROM pg_class a, pg_tables b, pg_namespace c WHERE a.relname = b.tablename AND c.oid = a.relnamespace AND a.relname !~ '^pg|^gp|^_|^sql';begin open cur1; loop fetch cur1 into v_list_toid,v_list_tname; exit when not found; v_sql = 'SELECT relid, t1.nspname||''.''||t1.tablename, t1.reloptions FROM pg_appendonly t, (SELECT a.oid, a.reloptions, b.tablename, c.nspname FROM pg_class a, pg_tables b, pg_namespace c WHERE a.relname = b.tablename AND c.oid = a.relnamespace AND a.relname !~ ''^pg|^gp|^_|^SQL'') t1 WHERE t.relid = t1.oid AND t1.oid = ' ||v_list_toid ; execute v_sql into v_table_oid,v_table_name,v_is_ao_table; if v_table_oid is not null then insert into tab_aotable values(v_table_oid,v_table_name,v_is_ao_table,'1'); else insert into tab_naotable values(v_list_toid,v_list_tname,'no ao table','0'); end if; end loop; raise notice 'PLPGSQL Exec Successfully'; close cur1;end;$$language plpgsql;/*以下为执行示例 ...

关于greenplum:特性分析-GreenPlum-的并行查询优化策略详解

本文首发于 2016-11-21 09:43:07架构GreenPlum 采纳 Share Nothing 的架构，良好的施展了便宜PC的作用。自此I/O不在是 DW(data warehouse) 的瓶颈，相同网络的压力会大很多。然而 GreenPlum 的查问优化策略可能防止尽量少的网络替换。对于首次接触 GreenPlum 的人来说，必定耳目一新。查问优化器GreenPlum 的 master 节点负责 SQL 解析和执行打算的生成，具体来说，查问优化器会将 SQL 解析成每个节点（segments）要执行的物理执行打算。 GreenPlum 采纳的是基于老本的优化策略：如果有多条执行门路，会评估执行代价，找出代价最小、最有效率的一条。不像传统的查问优化器，GreenPlum 的查问优化器必须全局的思考整个集群，在每个候选的执行打算中思考到节点间挪动数据的开销。比方有 join，那么 join 是在各个节点别离进行的（每个节点只和本身数据做 join），所以它的查问很快。查问打算包含了一些传统的操作，比方：扫描、Join、排序、聚合等等。 GreenPlum 中有三种数据的挪动操作： Broadcast Motion (N:N)：播送数据。每个节点向其余节点播送须要发送的数据。Redistribute Motion (N:N)：从新散布数据。利用 join 列数据的 hash 值不同，将筛选后的数据在其余 segment 从新散布。Gather Motion (N:1)：聚合汇总数据。每个节点将 join 后的数据发到一个单节点上，通常是发到主节点 master 。示例示例1explain select d.*,j.customer_id from data d join jd1 j on d.partner_id=j.partner_id where j.gmt_modified> current_date -80; QUERY PLAN ---------------------------------------------------------------------------------------- Gather Motion 88:1 (slice2) (cost=3.01..939.49 rows=2717 width=59) -> Hash Join (cost=3.01..939.49 rows=2717 width=59) Hash Cond: d.partner_id::text = j.partner_id::text -> Seq Scan on data d (cost=0.00..260.74 rows=20374 width=50) -> Hash (cost=1.91..1.91 rows=88 width=26) -> Broadcast Motion 88:88 (slice1) (cost=0.00..1.91 rows=88 width=26) -> Seq Scan on jd1 j (cost=0.00..1.02 rows=1 width=26) Filter: gmt_modified > ('now'::text::date - 80) 执行打算须要自下而上剖析： ...

关于greenplum:特性分析-GreenPlum-PrimaryMirror-同步机制

本文首发于 2016-01-21 20:02:26引言PostgreSQL 主备同步机制是通过流复制实现，其原理见 PG主备流复制机制。 Greenplum 是基于 PostgreSQL 开发的，它的主备也是通过流复制实现，然而 Segment 节点中的 Primary 和 Mirror 之间的数据同步是基于文件级别的同步实现的。为什么Primary和Mirror不能再应用流复制实现呢？次要有两个起因: Append Only 表不写 WAL 日志，所以 Append Only 表的数据就不能通过 XLOG 发送到 Mirror 再 Apply 。pg_control等文件也是不写 WAL 日志，也只能通过文件形式同步到 Mirror 。GreenPlum 总体构造Greenplum 的架构采纳了 MPP 无共享体系。在 MPP 零碎中，每个数据节点有本人的CPU、磁盘和内存(Share nothing)，每个节点内的 CPU 不能拜访另一个节点的内存。节点之间的信息交互是通过节点互联网络实现的，这个过程个别称为数据重调配(Data Redistribution)。 Master 负责协调整个集群，一个数据节点能够配置多个节点实例(Segment Instances)，节点实例并行处理查问(SQL)。 Primary和Mirror同步机制Primary 和 Mirror 同步的内容次要有两局部，即文件和数据。之所以 Primary 和 Mirror 要同步文件，是 Primary 和 Mirror 之间能够主动 failover，只有两者放弃同步能力互相代替。如果只把数据同步过来，pg_control、pg_clog、pg_subtrans 没有同步，那么从 Primary 切换到 Mirror 会呈现问题。 Master 和 slave 却不必放心这些问题，Append Only 表的数据只会存在 Segment，所以 WAL 日志足够放弃 Master 和 slave 同步(只有是流复制，pg_control、pg_clog、pg_subtrans 这些文件Slave会自动更新，无需从 Master 同步)。 ...

关于greenplum:CentOS75-部署Greenplum614集群源码安装

环境p5-thhidam-datacle-green02p5-thhidam-datacle-green01p5-thhidam-datacle-green03 一、零碎设置（所有主机）1、操作系统环境CentOS 7.5.1804，64位操作系统，没有更新过 [root@localhost tools]# cat /etc/redhat-release CentOS Linux release 7.5.1804 (Core) 2、敞开防火墙 systemctl stop firewalld.service #进行firewall systemctl disable firewalld.service3、敞开NetworkManagersystemctl stop NetworkManager 4、敞开selinuxroot@p5-thhidam-datacle-green01 gpAdminLogs]# cat /etc/selinux/config # This file controls the state of SELinux on the system.# SELINUX= can take one of these three values:# enforcing - SELinux security policy is enforced.# permissive - SELinux prints warnings instead of enforcing.# disabled - No SELinux policy is loaded.SELINUX=disabled# SELINUXTYPE= can take one of three two values:# targeted - Targeted processes are protected,# minimum - Modification of targeted policy. Only selected processes are protected. # mls - Multi Level Security protection.SELINUXTYPE=targeted 5、配置/etc/sysctl.conf[root@p5-thhidam-datacle-green02 ~]# grep -v "#" /etc/sysctl.conf net.ipv4.ip_forward = 0net.ipv4.conf.default.rp_filter = 1net.ipv4.conf.default.accept_source_route = 0kernel.core_uses_pid = 1net.ipv4.tcp_syncookies = 1kernel.msgmnb = 65536kernel.msgmax = 65536net.ipv4.conf.all.promote_secondaries = 1net.ipv4.conf.default.promote_secondaries = 1net.ipv6.neigh.default.gc_thresh3 = 4096 net.ipv4.neigh.default.gc_thresh3 = 4096kernel.softlockup_panic = 1kernel.sysrq = 1net.ipv6.conf.all.disable_ipv6=0net.ipv6.conf.default.disable_ipv6=0net.ipv6.conf.lo.disable_ipv6=0kernel.numa_balancing = 0kernel.shmmax = 68719476736kernel.printk = 5net.ipv6.conf.all.disable_ipv6 = 1net.ipv6.conf.default.disable_ipv6 = 1net.ipv4.neigh.default.gc_stale_time=120net.ipv4.conf.default.arp_announce = 2net.ipv4.conf.all.arp_announce=2net.ipv4.conf.lo.arp_announce=2net.ipv4.icmp_echo_ignore_broadcasts = 1net.ipv4.icmp_ignore_bogus_error_responses = 1net.ipv4.ip_forward = 0net.ipv4.conf.all.send_redirects = 0net.ipv4.conf.default.send_redirects = 0net.ipv4.conf.all.rp_filter = 1net.ipv4.conf.default.rp_filter = 1net.ipv4.conf.all.accept_source_route = 0net.ipv4.conf.default.accept_source_route = 0kernel.sysrq = 0kernel.core_uses_pid = 1net.ipv4.tcp_syncookies = 1kernel.msgmnb = 65536kernel.msgmax = 65536kernel.shmmax = 68719476736kernel.shmall = 4294967296net.ipv4.tcp_max_tw_buckets = 6000net.ipv4.tcp_sack = 1net.ipv4.tcp_window_scaling = 1net.ipv4.tcp_rmem = 4096 87380 4194304net.ipv4.tcp_wmem = 4096 16384 4194304net.core.wmem_default = 8388608net.core.rmem_default = 8388608net.core.rmem_max = 16777216net.core.wmem_max = 16777216net.core.netdev_max_backlog = 262144net.ipv4.tcp_max_orphans = 3276800net.ipv4.tcp_max_syn_backlog = 262144net.ipv4.tcp_timestamps = 0net.ipv4.tcp_synack_retries = 1net.ipv4.tcp_syn_retries = 1net.ipv4.tcp_tw_recycle = 1net.ipv4.tcp_tw_reuse = 1net.ipv4.tcp_mem = 94500000 915000000 927000000net.ipv4.tcp_fin_timeout = 1net.ipv4.tcp_keepalive_time = 1800net.ipv4.tcp_keepalive_probes = 3net.ipv4.tcp_keepalive_intvl = 15net.ipv4.ip_local_port_range = 1024 65000net.netfilter.nf_conntrack_max=655350net.netfilter.nf_conntrack_tcp_timeout_established=1200net.ipv4.conf.all.accept_redirects = 0net.ipv4.conf.default.accept_redirects = 0net.ipv4.conf.all.secure_redirects = 0net.ipv4.conf.default.secure_redirects = 0vm.max_map_count = 1000000fs.nr_open = 10000000fs.file-max = 11000000net.ipv4.conf.all.arp_filter = 1 ##############次要是这一条###################6、配置/etc/security/limits.conf* soft nofile 65536* hard nofile 65536* soft nproc 131072* hard nproc 1310727、手动执行命令让参数失效，也能够重启零碎#sysctl -p8、批改/etc/hosts文件配置主机与ip地址的映射192.xxxx.x.x p5-thhidam-datacle-green01192.xx.x.x p5-thhidam-datacle-green02192.x.x.x p5-thhidam-datacle-green039、创立gpadmin用户--每台服务器都做groupadd -g 530 gpadminuseradd -g 530 -u 530 -m -d /data/gpadmin -s /bin/bash gpadminchown -R gpadmin:gpadmin /data/gpadminecho "gpadmin" | passwd --stdin gpadmin二、装置和散发CentOS7.5 部署Greenplum6.14集群源码装置 ...

关于greenplum:带你认识PostgreSQL检索神器Brin-Index

引言 Greenplum是一款弱小而稳固的企业级分布式数据库。尽管基于 PostgreSQL，但Greenplum针对大数据的场景和用户对性能的极致谋求开发了大量的个性和做了极致甚至刻薄的优化。此外，Greenplum严密拥抱Postgres社区，以麻利的形式疾速降级Postgres内核。在Postgres 9.5的内核中，Postgres引入了一种全新的索引类型，名为Brin Index，本文将具体介绍Brin Index的外部实现以及性能体现。 01 什么是Brin Index Brin全称Block Range Indexes，顾名思义即数据块范畴的索引，它的设计初衷是为了解决当数据表极其宏大时的迅速扫描问题。家喻户晓，Heap表以页面为单位进行组织，所以表的扫描也是以页面为单位。Brin索引的根本思维就是在索引中记录一组间断页面中字段值的大抵统计信息，例如间断页面里某字段的最大值和最小值，页面扫描的时候依据Brin统计信息和查问条件间接跳过显著不合乎查问条件的页面，从而达到疾速扫描的成果。在理论的查问打算中，位图扫描基于Brin索引实现整个扫描过程，如下所示： gpadmin=# explain select * from t1 where c1 > 10 and c1 < 100;-----------QUERY PLAN--------------Gather Motion 3:1 (slice1; segments: 3) (cost=400.00..404.04 rows=1 width=64) -> Bitmap Heap Scan on t1 (cost=400.00..404.02 rows=1 width=64) Recheck Cond: ((c1 > 10) AND (c1 < 100)) -> Bitmap Index Scan on t1_idx_1 (cost=0.00..400.00 rows=1 width=0) Index Cond: ((c1 > 10) AND (c1 < 100))第一局部，Bitmap Index Scan应用Brin索引和查问条件结构位图，记录无效页面并过滤掉绝大多数无用的页面，第二局部，Bitmap Heap Scan基于位图精准扫描无效的页面并应用查问条件对页面内元组进行二次过滤。实际上，在Brin索引呈现之前，位图扫描通常应用Btree索引来结构位图，对于位图扫描的具体介绍，读者能够参考咱们的另外一篇文章Greenplum执行器位图——让查问更无效。 ...

关于greenplum:带你认识PostgreSQL检索神器Brin-Index

关于greenplum:GreenplumSpark-Connector-介绍

1. 前序Greenplum 是一款优良的 mpp 数据库产品，官网举荐了几种将内部数据写入 Greenplum 形式，蕴含：通用的 Jdbc，gpload 以及 Pivotal Greenplum-Spark Connector 等。 Jdbc：Jdbc 形式，写大数据量会很慢。gpload：适宜写大数据量数据，能并行写入。但其毛病是须要装置客户端，包含 gpfdist 等依赖，装置起来很麻烦。须要理解能够参考 gpload。Greenplum-Spark Connector：基于 Spark 并行处理，并行写入 Greenplum，并提供了并行读取的接口。也是接下来该文重点介绍的局部。2. Greenplum-Spark Connector 读数据架构一个 Spark application，是由 Driver 和 Executor 节点形成。当 Spark Application 应用 Greenplum-Spark Connector 加载 Greenplum 数据时，其 Driver 端会通过 JDBC 的形式申请 Greenplum 的 master 节点获取相干的元数据信息。Connector 将会依据这些元数据信息去决定 Spark 的 Executor 去怎么去并行的读取该表的数据。 Greenplum 数据库存储数据是按 segment 组织的，Greenplum-Spark Connector 在加载 Greenplum 数据时，须要指定 Greenplum 表的一个字段作为 Spark 的 partition 字段，Connector 会应用这个字段的值来计算，该 Greenplum 表的某个 segment 该被哪一个或多个 Spark partition 读取。 ...

关于greenplum:基于GreenplumKafka的实时数据处理

在谋求数据时效性的明天，如何高效解决低延时的流数据，逐步成为大家越来越关注的问题。流数据处理能力已成为掂量大数据平台计算实力的一个重要指标。Greenplum研发团队在开源Greenplum的根底上，提供了新的高速流数据引擎GPKafka，从而将Greenplum弱小的SQL解决能力引入到流计算畛域。来自掌数科技的吴贤川将在本视频中为大家具体解析基于Kafka+Greenplum的实时数据处理。基于Kafka+Greenplum的实时数据处理 ???? 手把手教你GPkafka实战 ???? 您能够通过链接（https://www.bilibili.com/video/BV12z411e7kH/）返回Greenplum中文社区B站频道进行观看）对于掌数科技来自金融中心上海的上海掌数科技有限公司（新意科技成员企业，以下简称：掌数科技），是一家聚焦于证券和大资管行业的金融科技企业，它致力于大数据、人工智能技术在金融科技领域的利用钻研，目前在证券行业的覆盖率高达60%以上。

实战系列Greenplum-版本4到5升级避坑指南

Greenplum大数据分析平台 6版本曾经于2019年9月4号在 Greenplum 用户大会上正式公布了，Greenplum 5 曾经进入稳定期和保护期，在不久的未来，Greenplum 4 将逐步完结生命周期。同时，从 5版本，Greenplum 继续对 PostgreSQL 内核进行降级，新的PostgreSQL内核将带来更多的性能和性能的体验。因而从用户长期应用和保护Greenplum的角度来说，降级是不可避免的。在本文中，咱们分两个局部来介绍 Greenplum 4 降级到 Greenplum 5 的教训分享： Greenplum 5 绝对于 Greenplum 4 的次要个性加强Greenplum 4 到 Greenplum 5 版本升级过程中可能遇到的问题以及如何解决一、Greenplum 5绝对于Greenplum 4的次要个性加强ORCA默认优化器本义符Text类型隐式转换内部表谬误记录数据类型变动性能加强1. ORCA成为Greenplum 5的默认优化器在Greenplum 5中 ORCA 成为默认的优化器。ORCA是Pivotal历经多年研发的新一代查问优化器，在多表关联，简单分区表，简单查问等场景更有劣势。经用户生产验证，ORCA开启的状况下，查问性能有显著的晋升。当然，目前ORCA并不能齐全代替legacy优化器，SQL的简单状况是各种各样的，在多数场景，可能legacy优化器会体现的更好，有时咱们须要通过设置参数显式的在SQL中敞开ORCA，就像这样： set optimizer to off; 当然，您也能够把这样的设置包在一个function中，也能够在View中调用这个function，这样都能够使得设置在SQL中失效。 2. 本义符对于本义符，在Greenplum 5之前，字符串内的反斜线[\]缺省被作为本义符，而从Greenplum 5开始，为了遵循更标准的PostgreSQL规范，字符串内的反斜线缺省将作为字符自身看待，除非您应用[E’…’]这样的格局以明确指定字符串内进行转译。您还能够通过如下操作使得数据库与之前版本体现统一，但咱们并不倡议你这样做： set standard\_conforming\_strings=off3. Text类型隐式转换 Text类型隐式转换，这可能是Greenplum 5降级过程中对现有语句影响最为宽泛的变动，在Greenplum 5公布初期，咱们也摸索过创立一些Operator以兼容以前版本的隐式类型转换，然而，咱们须要明确强调的是，咱们不举荐这么做，明确的类型匹配将有利于防止难以发现的潜在BUG，因为有时候，一些类型的隐式转换会导致匹配生效，这种问题往往是难以发现的。不过，在施行过程中，咱们发现，有些类型转换的场景能够通过补充一些Function来解决，比方： create or replace function substr(numeric, integer,integer )returns text as $$ select substr($1::text,$2,$3); $$ language sql IMMUTABLE strict; create or replace function pg\_catalog.btrim(str numeric) returns text as $$ return $\_\[0\]; $$ language plperl IMMUTABLE strict; create or replace function to\_date(timestamp, text) returns date as $$ select to\_date($1::text,$2); $$ language sql IMMUTABLE strict; create or replace function to\_date(integer, text) returns date as $$ select to\_date($1::text,$2); $$ language sql IMMUTABLE strict;而有些场景将难以避免的须要批改SQL以适应Greenplum 5的特点。所以，在Greenplum 5之前，咱们须要进行必要的测试验证，以确保所有的SQL都能够在Greenplum 5失常运行，尽管这个验证的工作量可能不会很大，然而很有必要。 ...

3分钟快速搭建Greenplum集群

Greenplum作为一个分布式计算平台，集群中有不同角色的节点，比方master，segment，甚至专门的etl服务器。残缺的部署一个Greenplum集群通常须要多个物理机，并破费数天甚至数周的工夫。而利用docker和docker-compose，启动一个gp集群其实只须要几分钟而已。本文将介绍如何疾速在docker中启动Greenplum 集群。 1、筹备工作首先从github下载docker的配置文件： git clone https://github.com/lij55/gphost.git而后从Greenplum官网(https://network.pivotal.io/)...，gphost的docker应用的CentOS7镜像。如果用gp5的环境，就将对应的rpm放到example5/目录；如果用gp6的环境，就将对应的rpm放到example6/目录。这里以gp6为例，下载6.8的安装文件greenplum-db-6.8.0-rhel7-x86_64.rpm，放到example6目录下，执行ls能够看到内容大抵如下: $ ls -1 example6build.shdocker-compose.yamlDockerfilegreenplum-db-6.8.0-rhel7-x86_64.rpmreadme.orgreset2、运行容器docker-compose.yaml文件中定义了运行时依赖的docker容器，默认有1个master节点，2个segment节点和1个etl服务器。如果须要减少更多segment机器或者批改端口，能够批改docker-compose.yaml。而后启动容器： # cd example6docker build . -t mygreenplum6docker-compose up -d容器启动好之后，能够通过ssh或者docker-compose的exec命令连贯到master节点；这里须要留神的是肯定要用gpadmin用户，假设master上ssh端口为6222，ssh的登录命令为: ssh -p 6222 gpadmin@127.0.0.1明码为changeme 3、初始化集群在master节点，执行如下命令来，生成初始化配置的脚本 artifiact/prepare.sh -s 2 -n 2-s 示意有2个segment机器（容器）-n 示意在每个segment机器上创立2个primary节点而后运行gpinitsystem命令来进行初始化。 gpinitsystem -a -c gpinitsystem_config不出意外的话greenplum集群就启动成了。preprare.sh脚本还生成了env.sh文件，不便配置gp须要的环境变量。此外，还有artifact/post.sh脚本会进行一些不便的设置，例如关上gpadmin的近程无明码拜访，将env.sh退出gpadmin用户的bash环境变量等。间接执行即可： artifact/postinstall.sh4、治理集群集群创立后，能够通过docker-compose命令来治理集群: docker-compose exec -u gpadmin mdw bash -i -c "gpstop -a"而重新启动集群的命令为: docker-compose exec -u gpadmin mdw bash -i -c "gpstart -a"gp的服务映射到本机的6432端口，能够用任何gp的客户端工具，比方dbeavor或者pgadmin进行拜访。 5、后续工作减少mirror和standby master的反对反对更多的组件，比方pxf，madlib等反对开源版gp进一步简须要手动执行的操作欢送大家到github上提issue，PR

HAWQ行列转换插件tablefunc安装和使用

阐明此性能只在测试环境论证过，没有在生产环境论证，如需应用，请自行评估危险HAWQ版本PostgreSQL 8.2.15 (Greenplum Database 4.2.0 build 1) (HAWQ 2.4.0.0 build dev) on x86_64-unknown-linux-gnu, compiled by GCC gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-39) compiled on Mar 28 2020 17:33:50获取和编译tablefunc>$ mkdir -p /home/demo/tablefunc>$ cd /home/demo/tablefunc>$ wget https://ftp.postgresql.org/pub/source/v8.2.15/postgresql-8.2.15.tar.gz >$ tar zxvf postgresql-8.2.15.tar.gztablefunc装置>$ source /usr/local/hawq/greenplum_path.sh>$ cd /home/demo/tablefunc/postgresql-8.2.15/contrib/tablefunc>$ make USE_PGXS=1 installgcc -O3 -std=gnu99 -Wall -Wmissing-prototypes -Wpointer-arith -Wendif-labels -Wformat-security -fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations -I/usr/include/libxml2 -fpic -I. -I/usr/local/hawq.my_rh7.x/include/postgresql/server -I/usr/local/hawq.my_rh7.x/include/postgresql/internal -D_GNU_SOURCE -I/opt/script/hawq-9c7ca3c2ce0b825c7236eaf208abf2475d9c992f/depends/libhdfs3/build/install/include -I/opt/script/hawq-9c7ca3c2ce0b825c7236eaf208abf2475d9c992f/depends/libyarn/build/install/include -c -o tablefunc.o tablefunc.cgcc -O3 -std=gnu99 -Wall -Wmissing-prototypes -Wpointer-arith -Wendif-labels -Wformat-security -fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations -I/usr/include/libxml2 -fpic -L/usr/local/hawq.my_rh7.x/lib -L/usr/local/hawq.my_rh7.x/lib -Wl,--as-needed -L/opt/script/hawq-9c7ca3c2ce0b825c7236eaf208abf2475d9c992f/depends/libhdfs3/build/install/lib -L/opt/script/hawq-9c7ca3c2ce0b825c7236eaf208abf2475d9c992f/depends/libyarn/build/install/lib -Wl,-rpath,'/usr/local/hawq.my_rh7.x/lib',--enable-new-dtags -shared -o tablefunc.so tablefunc.o/bin/sh /usr/local/hawq.my_rh7.x/lib/postgresql/pgxs/src/makefiles/../../config/install-sh -c -m 644 ./uninstall_tablefunc.sql '/usr/local/hawq.my_rh7.x/share/postgresql/contrib'/bin/sh /usr/local/hawq.my_rh7.x/lib/postgresql/pgxs/src/makefiles/../../config/install-sh -c -m 644 tablefunc.sql '/usr/local/hawq.my_rh7.x/share/postgresql/contrib' /bin/sh /usr/local/hawq.my_rh7.x/lib/postgresql/pgxs/src/makefiles/../../config/install-sh -c -m 755 tablefunc.so '/usr/local/hawq.my_rh7.x/lib/postgresql'/bin/sh /usr/local/hawq.my_rh7.x/lib/postgresql/pgxs/src/makefiles/../../config/install-sh -c -m 644 ./README.tablefunc '/usr/local/hawq.my_rh7.x/docs/contrib'rm tablefunc.otablefunc.so包发送到其余机器>$ gpscp -f all_nomaster /usr/local/hawq/lib/postgresql/tablefunc.so =:/usr/local/hawq/lib/postgresql/>$ gpssh -f all_nomaster "chmod 755 /usr/local/hawq/lib/postgresql/tablefunc.so">$ psql postgres -f /usr/local/hawq/share/postgresql/contrib/tablefunc.sql行列转换测试表create table score(name varchar,subject varchar,score bigint);测试数据insert into score values('Lucy','English',100),('Lucy','Physics',90),('Lucy','Math',85),('Lily','English',76),('Lily','Physics',57),('Lily','Math',86),('David','English',57),('David','Physics',86),('David','Math',100),('Simon','English',88),('Simon','Physics',99),('Simon','Math',65);原数据查问select * from score; name | subject | score -------+---------+------- Lucy | English | 100 Lucy | Physics | 90 Lucy | Math | 85 Lily | English | 76 Lily | Physics | 57 Lily | Math | 86 David | English | 57 David | Physics | 86 David | Math | 100 Simon | English | 88 Simon | Physics | 99 Simon | Math | 65(12 rows)sql规范实现select name, sum(case when subject='English' then score else 0 end) as "English", sum(case when subject='Physics' then score else 0 end) as "Physics", sum(case when subject='Math' then score else 0 end) as "Math" from score group by name order by name desc; name | English | Physics | Math -------+---------+---------+------ Simon | 88 | 99 | 65 Lucy | 100 | 90 | 85 Lily | 76 | 57 | 86 David | 57 | 86 | 100(4 rows)postgres内嵌函数实现select * from crosstab('select name,subject,score from score order by name desc', --name:分组规范,subject:聚合规范,score:聚合规范下通过计算的值 $$values('English'::text),('Physics'::text),('Math'::text)$$ ) as score(name text,English bigint,Physics bigint,Math bigint); --显示字段name,English,Physics,Math [name是分组规范;English,Physics,Math是聚合规范产生的字段名] name | english | physics | math -------+---------+---------+------ Simon | 88 | 99 | 65 Lucy | 100 | 90 | 85 Lily | 76 | 57 | 86 David | 57 | 86 | 100(4 rows)报错汇总报错/usr/local/hawq/include/postgresql/server/storage/fd.h:61:23: 致命谬误：hdfs/hdfs.h：没有那个文件或目录 #include "hdfs/hdfs.h" ^编译中断。make: *** [tablefunc.o] 谬误 1解决办法文件中/usr/local/hawq.my_rh7.x/include/postgresql/server/storage/fd.h将#include "hdfs/hdfs.h" 替换成#include "/usr/local/hawq.my_rh7.x/include/hdfs/hdfs.h"参考:http://www.bubuko.com/infodet... ...

让你的数据库飞起来Greenplum查询优化解析

6月19日，Greenplum原厂内核研发郭峰和大家直播分享了《深入浅出Greenplum内核》系列直播的第三期《Greenplum内核揭秘之查询优化》。没有参加活动的小伙伴也不用失望，我们已经将视频上传至Greenplum中文社区B站频道，通过点击这里即可观看。本文概括了文章的精华内容，欢迎留言交流。直播视频（腾讯频道） https://v.qq.com/x/page/i3107m0gi47.html 本文将主要包括两大部分，第一部分是查询优化器的介绍，第二部分是查询优化的具体处理过程，整个过程将被分为四个阶段：查询树的预处理，扫描/连接优化，扫描/连接之外的优化，计划树的后处理，我们将在本文中一一展开。首先我们来介绍一下查询优化器是做什么的。对于给定的查询语句，查询优化器会找到“代价”最小的查询计划。这里的“代价”在不同的应用场景会有不同的维度或者是定义，比如可能是找到一个执行时间最短，或者找到一个执行占用资源最少的查询计划。对于同一个查询语句，一般可以由多种方式去执行，因此查询优化器尽可能去遍历每一种可能的执行方式，找到“代价”最小的执行方式，并把它转换成可执行的计划树。下图是一个例子，A JOIN B on a.i = b.i，对于这个Query，我们有几种执行方式，这里我们来介绍三种执行方式。第一种执行方式中，我们可以先对b做一个索引扫描，再对a做一个顺序扫描，再去执行一个Nested Loop。第二种执行方式中，我们可以对a做一个顺序扫描，把扫描的结果建一个哈希表，再对b做一个顺序扫描，最后用Hash Join得到一个结果。第三种方式是对a做一个顺序扫描，根据a.i为序的键值做一个sort排序，再对b做一个索引扫描，最后做一个Merge Join，得到最后的结果。大家可以看到这三种执行方式，后面的“代价”（cost）信息是不同的，优化器会根据cost信息选出一个“代价”最小的方式，形成最后的执行方案。前面介绍了查询优化器，这里我们再来介绍一下查询计划。一个查询计划就是一个由计划节点组成的树，每个计划节点代表了一个特定类型的处理操作，计划节点中包含了执行器执行所需的全部信息。在执行时，计划节点产生输出元组，一般来说，扫描节点从数据表中获取输入元组，大部分其他节点从它们的子计划节点中获取输入元组，并处理产生输出元组。计划节点可以分为三个类型，扫描节点包括顺序扫描，索引扫描，位图扫描等；连接节点包括Nestloop，hash，merge等；非SPJ节点包括Sort，aggregate，set operations（UNION等）下面我们再来看一个例子。对于例子中的Query，查询计划就如下图所示，其中Seq Scan on a 和Seq Scan on b都是扫描节点，扫描的结果去做Hash Join，是一个连接节点。Hash Join之上，做了一个HashAggregate，这是一个聚集节点，最后再对聚集的节点做排序，这是一个排序节点。在讲完查询优化和查询计划，我们再来看一下Greenplum查询优化的具体处理过程。Greenplum查询优化主要包括四个阶段，具体过程请看下图。接下来我们来逐一解析这四个阶段分别做了什么。 1. 简化常量表达式在表达式中，有一些常量表达式，在做计划时，可以对其做一些简化，例如对于函数表达式，可以对下图的两种类型做简化：函数本身是严格的如果一个表达式的输入是NULL，输出也是NULL或者是FALSE，在这种情况下，我们就可以说这个函数就是“严格”的。我们可以通过CATELOG表中的属性，来查看某个函数是否是严格的，如果函数本身是严格的，并且输入的参数中包含一个NULL值，在做计划时，就可以用NULL来代替这个函数表达式。函数本身是“IMMUTABLE”函数是”IMMUTABLE”是指如果输入是固定的，则输出也是不变的。我们也可以通过CATELOG表中的属性查看这个函数是否是“IMMUTABLE”。如果函数本身是“IMMUTABLE”的，并且输入参数全都是常量，则可以先求值，并用常量去代替函数表达式。对于布尔表达式，在一些情况下也可以坐简化，比如下图的两种情况。对于CASE表达式，如果某个分支条件是一个常量的话，也可以做简化。比如下图的这个例子中的2+2=4，可以把整个CASE表达式简化为x+1。虽然在else里与1/0，但是由于我们做了简化，因此表达式就不会报这样的除0的错误。我们为什么要在做计划这个阶段去简化常量表达式呢？通过简化常量表达式可以带来以下好处：仅需做一次计算，而不是为每行元组都做一次计算视图展开和函数内联都可能会带来新的常量表达式简化的机会简化常量表达式也为统计信息类的函数减少了计算量2. 内联简单的SQL函数查询树的预处理在早期做的第二件事是内联简单的SQL函数，比如下图的例子中，SELECT incr4(a) FROM foo可以内联成SELECT a+4 FROM foo。而这里不止做了个内联，还做了个常量表达式的简化。通过内联简单的SQL函数，可以避免SQL函数调用的代价为简化常量表达式提供新的机会3. 提升子链接子链接是指出现在表达式中的子查询，通常出现在WHERE或者JOIN/ON子句中。比如下面这个例子中，子查询出现在了一个WHERE子句中，因此就被归类为一个子链接，在这种情况下，我们就可以把一个EXISTS的子链接变成一个SEMI JOIN。 ...

用户实测HTAP性能Greenplum-OLAP-完胜TiDB和CockroachDBOLTP性能优异

传统数据库领域包含两大业务场景：OLTP和OLAP。过去，两大业务场景需要依赖不同的数据库产品，数据在不同数据库之间融通的过程中往往容易产生数据孤岛、数据的时效性、数据的一致性等问题。因此，近年来支持HTAP混合负载的数据库产品正在受到越来越多的关注。如何实现一款优秀的HTAP数据库，业界有不同的声音。一方面，以TiDB为代表的新兴数据库厂商选择从头做起，搭建一款HTAP原生数据库。另一方面，以Greenplum为代表的成熟数据库厂商选择在自己的优势产品中引入对HTAP的支持。其中，Greenplum6.0通过引入全局死锁检测、优化全局事务、升级PG内核等优化，实现了在OLTP上性能的飞跃。那么，这些HTAP数据库的性能究竟如何呢？近日，来自金风科技的社区小伙伴马晓亮对三款数据库：Greenplum、CockroachDB和TiDB 进行了相关场景的性能测试。下面，让我们来看一下测试结果。此次性能测试场景分为OLTP的TPC-C和TPC-B测试以及简单的OLAP统计聚合场景（作为一款OLAP数据库，Greenplum对复杂场景支持优异，而大多数新兴HTAP数据库还不能很好的支持复杂场景，所以本测试只测试简单OLAP场景），所有测试都是通过186代理节点进行测试，CockroachDB（后文简称CRDB）和Greenplum使用相同的节点进行分段测试，由于是使用的虚拟机性能对三个分布式来说不会太高，废话不多说直接上测试数据，我们先看下整体的对比情况：一、基础环境1. 硬件环境： 2. 软件环境：二、整体的OLTP测试情况对比sysbench测试脚本是为PostgreSQL设计，其中用到了SELECT FOR UPDATE。Greenplum 6.x还不支持 SELECT FOR UPDATE，所以通过pgbench对Greenplum再进行一轮测试。（Greenplum 7将支持SELECT FOR UPDATE） Greenplum 6.7.1pgbench测试，通过自己写的脚本实现的三个场景。三、OLAP简单场景统计性能对比t1、t2表各生成1亿记录：包含id、int类型、字符类型、时间类型、浮点型。由于TiDB和CRDB对复杂的统计分析场景支持不好（如窗口函数、CTE等），所以采取简单场景测试：准备测试表： CRDB create table t1 (id int primary key, c1 float4, c2 text, c3 timestamp, c4 float4);TIDB create table t1 (id int, c1 float, c2 text, c3 timestamp, c4 float);Greenplum create table t1 (id int, c1 float, c2 text, c3 timestamp, c4 float);由于CRDB、TiDB一个事务中生成1亿记录未能完成（CRDB异常、TiDB异常缓慢），所以通过程序实现分段提交实现： ...

实战系列GPRoaringbitmap亿级会员十万级标签毫秒级查询

在大数据处理和应用场景中经常需要从亿级甚至十亿级会员中搜索出符合特定标签的会员。很多企业都会使用 HBase 或者 Hive + Hadoop 的方式，这样的方式查询效率非常慢，在标签非常多的情况下计算，更是让人无法忍受。这里我们介绍一种 Greenplum + Roaringbitmap 的组合使用方案，亿级甚至十亿级会员_万级标签_的条件下查询毫秒级出结果。业务系统的场景图如下。数据从业务系统经过处理后流进 OLAP 分析平台，OLAP 平台的底层支持就是使用 Greenplum + Roaringbitmap。 Greenplum 是一个分布式大数据平台数据库，基于 MPP 架构的模式来达到快速分析效果的。关于 Greenplum 的官方介绍：About the Greenplum Architecture（ http://gpdb.docs.pivotal.io/5..._guide/intro/arch_overview.html ）。 Roaringbitmap 是压缩的 bitmap 的一种实现，参考文档： RoaringBitmap/RoaringBitmap（ https://github.com/RoaringBit... ）。如何实现？具体实现参照如下步骤：实验硬件配置： Master 1 台,Segment Host 2 台, 3 Segments 每台HostCPU: 2.40GHz 32 coresMemory:128GDisk: SATA 1T用户表schema：用户标签表schema: 2亿会员数据导入GP，耗时60s GP分区影响：分区后查询效率提升 5-10 倍。创建用户标签表： ...

用户实测HTAP性能Greenplum-OLAP-完胜TiDB和CockroachDBOLTP性能优异

MADlibIndatabase-分析介绍

今年QCon大会，蚂蚁金服发布了开源SQLConnectAI产品SQLFlow，旨在“降低人工智能应用的技术门槛，让技术人员调用AI像SQL一样简单”。 SQLFlow 的思想最早可以追溯到2005年，当时 Thomas Tileston 提出了 In-database 分析，将数据库与数据挖掘、机器学习有机地统一了起来。 In-database 分析通过扩充SQL的能力，降低了企业应用机器学习技术的门槛，同时解决了数据在不同系统间移动所产生的一系列问题。 In-databse分析主要具有以下特性：易用性，降低机器学习门槛，掌握SQL的技术人员即可完成大部分的机器学习模型训练及预测任务，掌握TensorFlow和Scikit-learn的技术人员比掌握SQL的技术人员少很多。本地性，减少数据的移动，存储在数据库中的数据在原地进行机器学习建模和推理，提高了分析效率同时，避免了数据移动过程中存在的安全问题，减少了team间沟通成本，以及建造单独数据分析基础设施的IT成本。可扩展性，单机机器学习到集群机器学习的扩展通用性，即支持的机器学习算法的丰富性。从2005年 Thomas Tileston 提出了 In-database 分析至今，已经涌现出很多 In-database 分析的产品，它们部分或全部支持 In-database 分析的特性，我们将主要的产品和时间线总结在图1. 图1 In-database分析时间线从时间线可以看出，2009年 MAD Skills 在 VLDB 的发表和2011年 MADlib 项目的诞生可以作为 In-database 分析的里程碑。MADlib 是由 Pivotal Greenplum DB 团队和高校联合研发的，参与的大学包括伯克利大学加州分校、斯坦福大学、威斯康辛麦迪逊大学、佛罗里达大学。2017年 MADlib 正式毕业成为 Apache 顶级项目。MADlib 的第一篇论文“MAD skills: new analysis practices for big data”，目前Google引用已达555次，Spark SQL，BigQuery ML 等产品均引用了 MADlib 的工作，MADlib 被认为是 In-database 分析的先驱者和领路人。 In-database分析产品众多，不同厂商对 In-database 分析的理解也不尽相同。从架构来区分，In-database 分析可以分为以下四种： SQL wrapper, 将扩展的SQL语法翻译成AI引擎可以执行的程序，它不涉及对机器学习算法的重构，而是直接调用底层AI引擎。SQL on AI engine, 让AI引擎支持SQL语法及相应的查询优化器，但SQL的执行器使用AI引擎自身，从而实现了AI engine as a database 的架构。SQL based AI algotithm, 基于SQL重写机器学习算法，并将这些算法内置到数据库中。UDA based AI algorithm, 基于数据库的 User Defined Agrregation（UDA）实现机器学习算法。基于不同场景，UDA语言可以是Python，R或者是高效的C／C++。这些算法同样被内置到数据库中。上述四种 In-database 分析的架构对 In-database 分析的特性有不同程度的支持，我们选取SQLFlow，Spark SQL，Bigquery ML 和 MADlib 作为这四种架构的典型代表。表1展示了四个典型In-database分析产品和它们对In-database分析特性的支持。 ...

助力Greenplum数据库开发之接口篇上GolangCPython和Perl

Greenplum 作为一款强大的 HTAP 数据库，针对大多数流行语言都有相应的连接库。大部分均是与 PostgreSQL 采用相同的接口，但是也有部分接口是 Greenplum 专门优化后用于自身使用的。今天，我们将给大家分享一系列语言接口的连接库及使用方式。1. GolangGolang 作为 Google 开源的一款编译型开发语言，经过多年发展，在开发界占据了很大的份额，市面上针对 Greenplum 的 Golang 连接库也有很多，但是最著名的还是 github.com/lib/pq。 Golang 为连接数据库专门提供了一个公共包叫 database/sql，在进行数据库连接时，只需要遵循该库的注册方式将 lib/pq（https://github.com/lib/pq）注册为 postgres 驱动即可。支持列表目前该包支持全系列 Greenplum 产品，提供的一些功能如下：支持数据库增删改查支持在数据库中直接执行DDL或维护语句（VACUUM等）支持所有普通数据类型支持 bytea支持 hstore支持 SSL支持 COPY FROM支持 pgpass安装方法与其他的 Go 包安装方式一样，只需要在 go/src 目录下执行 go get 命令即可将需要的包下载。go get github.com/lib/pq 如果网络条件有限，不能直接 go get 联网下载，也可以直接在外网机器上用 go get 或者 git 下载好，然后将代码复制到对应格式的目录下（放到 go 文件夹下的 src 文件夹下的 github.com 文件夹下的 lib 文件夹下的 pq 下）。使用方法下面展示一段 Golang 连接数据库查询的代码，进行简单分析。 package mainimport ( "database/sql" "fmt" _ "github.com/lib/pq" "log")func main() { db, err := sql.Open("postgres", "user=chris password=123 dbname=postgres host=127.0.0.1 port=5432 sslmode=disable") if err != nil { log.Fatal(err) } defer db.Close() //查询数据 rows, err := db.Query("select version()") for rows.Next() { var version string rows.Scan(&version) fmt.Println(version) }}从上面代码可以看到，我们需要首先导入 database/sql 和 lib/pq 两个包。 ...

揭秘GPGreenplum-数据库进军深度学习领域

深度学习（Deep Learning）开始成为企业计算的一个更重要的部分，这是因为人工神经网络在自然语言处理，图像识别，欺诈检测和推荐系统等领域非常有效。在过去的五到十年中，计算机的计算能力有了极大的增强，以及海量数据的出现，这一切促使人们对使用深度学习算法解决问题产生了兴趣。另一方面，企业的业务系统大多基于SQL的基础架构，在软件和员工培训方面进行了大量投资。然而，深度学习的主要创新发生在SQL世界之外，因此企业使用深度学习算法是需要采用独立的深度学习基础设施。因此，在传统的SQL架构之外搭建深度学习系统，不仅需要考虑到额外的费用和工作量，也需要考虑开发新数据孤岛的风险。此外，在系统之间移动大型数据集效率不高。如果企业可以在MPP关系数据库中使用流行的深度学习框架（如Keras和TensorFlow）执行深度学习算法，那么，这将使企业能够利用他们在SQL中的现有投资，使深度学习更容易，更平易近人。此外，另一个需要考虑因素是当今许多数据科学问题中需要应用多种模型。一般情况下，数据科学家在分析数据特征工程上经常花费大量时间采用多种方法来解决问题，在这种情况下数据分析的结果通常是多种模型的结合体。在这种情况下，使用同一个计算引擎进行所有的计算将比使用不同系统分别计算然后组合结果更有效率。为此，在数据库内部内建一组机器学习和分析功能，可以使这些计算数据库内执行，这样减少甚至消除在不同的计算环境之间的数据移动，极大的提高计算效率。 Greenplum上使用GPU加速深度学习算法下图（图1）为Greenplum+GPU的架构图。Keras [1]和TensorFlow [2]等标准深度学习算法库部署在Greenplum的segment节点上，GPU同时也部署在segment节点上，每个节点上的segment共享GPU计算资源。图1：用于深度学习的Greenplum架构这种架构设计的目的是为了消除segment和GPU之间互连的传输延迟。在这种架构下，每个segment只需要处理本地数据得出结果，与Greenplum 集成在一起的开源机器学习库Apache MADlib负责将每个segment的模型合并在一起得到最终的模型。这种计算方式，利用了MPP的水平横向扩展功能。 MADlib程序设计使用MADlib进行程序设计非常简单，只需要在SQL中调用Apache MADlib函数即可。在下面的示例中，我们使用MADlib提供的算法在CIFAR-10 [4]图像数据集上训练模型，具体的SQL如下：在这个SQL运行结束后，训练的模型存储在表model_arch_library中，model_arch_library中的数据是训练模型卷积神经网络（CNN）的JSON表示。CNN是一种特殊的神经网络，非常擅长图像分类[5]。在上面的SQL中，有一个有用的参数–GPU per host（每个节点的GPU数量），该参数指定每个segmeng节点上用于训练模型的GPU的个数。将参数指定0意味着使用CPU而不是GPU进行训练，这样的话可以在较小数据集上使用浅层神经网络的来调试和试运行。试运行甚至可以在PostgreSQL上。试运行通过之后可以转移到配备昂贵的GPU的Greenplum集群上使用整个数据集上训练深度神经网络。模型训练完成后，我们可以使用上面训练的模型来进行图像分类，具体的SQL如下：性能和可伸缩性现代的GPU具有高内存带宽而且每个芯片的处理单元数量是CPU的200倍，这是因为它们针对并行数据计算（如矩阵运算）进行了优化。CPU则设计的更为通用以执行更多种类的任务。因此使用GPU训练深度神经网络所带来的性能提升是众所周知的。图2显示了常规CPU Greenplum集群与GPU加速Greenplum集群之间的简单深度CNN [6]的性能提升。在这个测试中，我们使用了一个较小的Greenplum集群（具有4个segment）测试了CIFAR-10数据集的的训练时间，结果如下图所示：图2：Greenplum数据库GPU与CPU的培训性能* 仅仅使用CPU的情况下Greenplum集群需要超过30分钟的培训时间才能在测试集上达到75％的准确率，而使用GPU加速Greenplum集群在不到15分钟内达到75％的准确率。CIFAR-10图像分辨率仅为32×32 RGB，因此GPU的性能提升则低于高分辨率图像。对于具有256×256 RGB图像的Places数据集[7]，我们发现使用GPU加速训练模型比仅使用CPU快6倍[8]。使用GPU加速模型训练的关键益处是减少模型的训练时间，这意味着数据科学家可以更快地进行模型训练的迭代，并且可以更快地将新训练的模型部署到生产环境中。例如，在欺诈检测的用例下，更快的新模型训练和部署带来的直接益处是财务损失的减少。推断（inference）的含义是使用训练模型对新数据进行分类。使用Greenplum这样的MPP数据库非常适合批量处理; 吞吐量随着数据库集群的大小以线性方式增加。例如，使用我们上面训练的CNN模型，表1显示了对50,000个新的32x32RGB图像执行批量推断所需的时间。表1：Greenplum数据库集群上的批量分类测试结果未来的工作作为Apache MADlib项目的一部分，MADlib社区计划在每个版本中逐步添加新的深度学习功能。例如，一种常见的数据科学工作流程是参数的选择和调整。参数的调整不仅仅包括以模型的参数调整，也涉及模型结构的调整，例如网络层数和组成。这些一般涉及训练几十种到几百种模型的组合，以便找到具有最佳准确度/培训成本概况的组合。在这样大的训练压力下，使用Greenplum这样的MPP数据库，借助并行计算功能可以极大的提高模型训练的效率。本文使用的测试环境基础平台：Google Cloud Platform Greenplum 版本：Greenplum 5 Segment节点配置：32个核心vCPU，150 GB内存 Segment节点GPU配置：NVIDIA Tesla P100 GPU 参考资料 [1] https://keras.io/ [2] https://www.tensorflow.org/ [3] http://madlib.apache.org/ [4] CIFAR-10 dataset, https://www.cs.toronto.edu/~k... [5] Le Cun, Denker, Henderson, Howard, Hubbard and Jackel, Handwritten digit recognition with a back-propagation network, in: Proceedings of the Advances in Neural Information Processing Systems (NIPS), 1989, pp. 396–404. ...

揭秘GPVLDB-创始人为什么和其他相比Greenplum-是最好的

导读：从最初的 Greenplum 开始，到现在已经超过15年的验证，我们一直是 Greenplum 的用户。多年来，随着我们对产品和支持的信心不断增强，它已逐渐成为VLDB的默认平台。希望本文讲述的这些原因能解除大家的困惑。本文翻译自 VLDB Co-founder Paul Johnson 发布于 Linkedin 上的《 Why Greenplum Is The Best…Of The Rest 》，原文链接： https://www.linkedin.com/pulse/why-greenplum-bestof-rest-paul-johnson/?from=groupmessage&isappinstalled=0。面向数据仓库领域的数据库众多，带头进入这一领域的老大哥是上世纪80年代创立的Teradata。早在20世纪80年代，Teradata 公司在市场上推出了与其公司同名的分析型数据库，当时大体量的数据还在用 Terabyte（TB）表示。那时，确切的说是在 Teradata DBC1012 上运行查询。这张图片是我1988年刚开始接触 Teradata 时的参考卡片。早在20世纪80年代，Teradata公司在市场上推出了与其公司同名的分析型数据库，当时大体量的数据还在用Terabyte（TB）表示。那时，确切的说是在Teradata DBC1012上运行查询。这张图片是我1988年刚开始接触Teradata时的参考卡片。在过去的几年中，数据仓库领域已经大大升温。现在有比之前更多的选择。Teradata可能仍然是市场领导者，但并非每个人都需要Teradata。那么，如果Teradata仍然是市场上的老大哥，那么其余的呢？在这里，我们要告诉那些一直在关注该领域的人，我们很久以来一直是Greenplum的死忠粉。出于“推崇共享”（显然共享很重要）的价值观，我们展开阐述“ VLDB团队”成为Greenplum粉丝的十大原因。 1. Greenplum“可以在任何地方构建”，而不仅仅在云上构建传统数据仓库系统针对本地物理硬件进行了优化。这并不奇怪，因为旧系统要早于AWS，Azure和Google等公有云的出现。相比之下，Redshift，BigQuery和Snowflake等“现代数据仓库系统”是“仅运行在云上”的。这些现代数据仓库系统都不支持非云环境部署。Redshift仅适用于AWS，BigQuery仅适用于Google。用户的选择并不多 - 要么选择数据库要么选择平台，但不能两者都选。 Greenplum则是“可以在任何地方构建”的数据仓库。Greenplum可以在物理硬件、VMWare私有云和AWS或Azure或Google等公有云平台上运行。为了跟上时代前沿，还支持Kubernetes（K8S）部署。只要您选择的平台支持Linux，就可以使用Greenplum。 2. Greenplum是MPP架构公认的是，通用SMP数据库（例如Oracle，SQL Server和MySQL）无法一直扩展以满足数据仓库系统的需求。与通用SMP数据库不同，Greenplum部署为“大规模并行处理”（MPP）体系结构的群集。与SMP体系不同，MPP体系结构是线性的可扩展的，因此可以不断地添加更多的计算、存储或网络带宽资源。多亏了Teradata的朋友，MPP架构在现实世界中已有30年的成功记录。 Greenplum的可扩展MPP体系结构使您可以从单个节点开始，根据需要扩展集群，以满足不断变化的容量、吞吐量和性能需求。借助经过验证的MPP架构，您始终可以扩展Greenplum集群以满足您的确切要求。 3. Greenplum是并行的Postgres数据库数据仓库通常是现代企业中的关键报告、查询分析和决策支持系统。所以将此类活动赋予一个具有明确可追踪记录的系统是至关重要的。 Greenplum是一个“大规模并行Postgres”系统，并且是“ 唯一”的开源MPP数据仓库系统。 Postgres数据库拥有30年的历史，被誉为“世界上最先进的开源数据库”。诸如Greenplum和Netezza（RIP）的并行Postgres数据库已有15年的历史，并且已经证明了基于Postgres构建MPP平台的优势。 Greenplum最初是在2005年从Postgres分拆出来的，从那时开始，Greenplum的内核一直保持在较老版本（Postgres 8.2）。自从2015年开源以来，Greenplum研发团队明显加快了合并Postgres新版本代码的速度，目标是在2020年合并到当前最新版本的Postgres。在所有并行Postgres数据库系统中，Greenplum是唯一具有详细近期开发路线图的数据库，可实现最新最完整的Postgres代码整合并合理利用Postgres全球开源社区开发的新功能来完善自己。 ...

如何用gpss实现Oracle到Greenplum的增量同步

之前我们在《如何用gpss实现MySQL到Greenplum的增量同步》中详细介绍了MySQL到Greenplum增量同步的实现步骤。今天将给大家讲一讲Oracle到Greenplum又是如何实现的。 Oracle数据库虽然在OLTP领域仍有着毋庸置疑的优势地位，但在OLAP领域与Greenplum则是差距显著。如今已经有越来越多的分析型业务从Oracle迁移到Greenplum，在《如何从Oracle迁移到Greenplum》系列文章中，详细介绍了业务的迁移的最佳实践；而数据迁移中最核心的就是如何实现数据的实时增量同步。对增量同步而言，gpss作为一个流计算框架，与源端是解耦的，因此只要Kafka topic中的消息，包含足够的信息，gpss都可以提取变化的数据并重放到gp中。之前介绍了如何利用gpss同步来自Maxwell和Mysql的增量数据，这里再以Oracle Golden Gate为例，介绍如何实时同步来自Oracle的增量数据。 1 测试环境OracleOracle Golden GateKafka 2.2.2Greenplum 6.4.0GPSS 1.3.6我们要完成的工作是: 通过GoldenGate将Oracle中的增量数据以json格式发送到Kafka （略）利用gpss解析kafka中的json消息将变化的数据更新到Greenplum的目标表中2 测试数据简介测试使用的表在Oracle中定义如下： CREATE TABLE SIEBEL_TEST.TEST_POC( ID numeric, NAME varchar2 (50), BIRTHDAY date)其中 ID 列为键，用来唯一标识一条记录， NAME 和 BIRTHDAY 为更新字段。在源端分别对这个表进行了insert，update和delete操作。 Insert语句为: insert into test_poc values (1, 'Igor', '01-JAN-2000');Update语句为: update test_poc set birthday=add_months(birthday,1) where id <3;Delete语句为: delete from test_poc where id=3;3 Kafka的消息格式接下来我们对Golden Gate的这三种类型的消息进行简单的分析。 Insert时生成的消息示例如下： { "table": "SIEBEL_TEST.TEST_POC", "op_type": "I", "op_ts": "2019-11-21 10:05:34.000000", "current_ts": "2019-11-21T11:05:37.823000", "pos": "00000000250000058833", "tokens": { "TK_OPTYPE": "INSERT", "SCN": "" }, "after": { "ID": 1, "NAME": "Igor", "BIRTHDAY": "2000-01-01 00:00:00" }}Table表示源表的表名，current_ts表示操作发生的时间，这里我们用它做排序；op_type和after表示执行的操作及对应的数据。 Delete生成的消息如下，op_type为"D"，同时before中包含了完整的内容。 { "table": "SIEBEL_TEST.TEST_POC", "op_type": "D", "op_ts": "2019-11-21 10:13:19.000000", "current_ts": "2019-11-21T11:13:23.060002", "pos": "00000000250000059999", "tokens": { "TK_OPTYPE": "DELETE", "SCN": "" }, "before": { "ID": 3, "NAME": "Gianluca", "BIRTHDAY": "2002-01-01 00:00:00" }}Update除了包含新数据(after)外，还包含了更新之前的数据(before), op_type类型为'U'。 ...

Greenplum-分布式数据库内核揭秘下篇

点击查看Greenplum 分布式数据库内核揭秘(上篇) 1. 分布式执行器现在有了分布式数据存储机制，也生成了分布式查询计划，下一步是如何在集群里执行分布式计划，最终返回结果给用户。 Greenplum 执行器相关概念先看一个 SQL 例子及其计划： test=# CREATE TABLE students (id int, name text) DISTRIBUTED BY (id); test=# CREATE TABLE classes(id int, classname text, student_id int) DISTRIBUTED BY (id); test=# INSERT INTO students VALUES (1, 'steven'), (2, 'changchang'), (3, 'guoguo'); test=# INSERT INTO classes VALUES (1, 'math', 1), (2, 'math', 2), (3, 'physics', 3); test=# explain SELECT s.name student_name, c.classname test-# FROM students s, classes c test-# WHERE s.id=c.student_id; QUERY PLAN ---------------------------------------------------------- Gather Motion 2:1 (slice2; segments: 2) (cost=2.07..4.21 rows=4 width=14) -> Hash Join (cost=2.07..4.21 rows=2 width=14) Hash Cond: c.student_id = s.id -> Redistribute Motion 2:2 (slice1; segments: 2) (cost=0.00..2.09 rows=2 width=10) Hash Key: c.student_id -> Seq Scan on classes c (cost=0.00..2.03 rows=2 width=10) -> Hash (cost=2.03..2.03 rows=2 width=12) -> Seq Scan on students s (cost=0.00..2.03 rows=2 width=12) Optimizer status: legacy query optimizer ...