数据库系统Greenplum 研究
分布式数据库TPC-H测试_XXX
分布式数据库TPC-H测试（GREENPLUM）1、引言如今，多样的交易模式以及大众消费观念的改变使得数据库应用领域不断扩大，现代的大型分布式应用系统的数据膨胀也对数据库的海量数据处理能力和并行处理能力提出了更高的要求，如何在数据呈现海量扩张的同时提高处理速度和应用系统的可用性，使客户能同时得到更高的处理速度、更高的数据可用性和更大的数据集，是数据库系统面临的一个挑战。
通过TPC-H基准测试，可获得数据库单位时间内的性能处理能力，为评估数据库系统的现有性能服务水平提供有效依据，通过横向对比促进数据库系统的整体质量提升，能更好地在重大信息化工程中实现推广。
2、TPC-H原理简介TPC-H是由TPC(Transaction Processing Performance Council)事务处理性能委员会公布的一套针对数据库决策支持能力的测试基准，通过模拟数据库中与业务相关的复杂查询和并行的数据修改操作考察数据库的综合处理能力，获取数据库操作的响应时间和每小时执行的查询数指标(QphH@Size)。
TPC-H基准模型中定义了一个数据库模型，容量可以在1GB~10000GB的8个级别中进行选择。
数据库模型包括CUSTOMER、LINEITEM、NATION、ORDERS、PART、PARTSUPP、REGION和SUPPLIER 8张数据表，涉及22条复杂的select查询流语句和2条带有insert和delete程序段的更新流语句。
测试分为Power测试和Throughout测试两种类型，Power测试是随机执行22条查询流中的一条测试流和2条更新流中的一条测试流，考核指标为QppH@Size;Throughout测试执行的是多条查询流和一条更新流对数据库的混合操作，考核指标是QthH@Size，Power测试和Throughout测试通过数理方式合成的结果为TPC-H基准测试中最关键的一项指标：每小时数据库查询数(QphH@Size)，是QppH@Size和QthH@Size结果的乘积的1/2次方。
Greenplum介绍
因为GP的算法优化有关，行迁移操作将导致混乱
每个操作都是独立的。
GP Query Plans查询计划
查询计划是从下向上的。
如果操作设计table scans、joins等操作，要涉及到多个Segment合力完成，这时多个节点之间将会有数据的移动-----motion/这样是非常消耗性能的。（多个节点在数据交互是产生的）
每个子节点必须是在不同的网段。
详细将Greenplum Interconnect
GP内部连接实际上是网络基础（实际上是指Internet，多节点并行计算，多个节点之间是有数据交互的，这个交互就是通过Interconnect来进行）。
GP将内部连接（Interconnnent）称之为Inter-process communication---IPC内部进行通信。
Segment Failover and Recovery机制
当挂掉其中的一个子节点时，整个系统仍然可以运行（有Mirror Segment），如果是read-only模式，对于客户端来说只有查询功能，没有写功能。
好处为：当子节点恢复时是恢复到Mirror Segment之前点的数据，这样Primary Segment和Mirror Segment之间不会出现数据差异。
缺点：造成节点上的数据量不同。
优点：在做joins时可以避免节点与节点中的数据交互，节省大量资源
在查询是SQL语句通过Master进行解析、优化并将查询转为并行的查询计划，实现并行查询。
如表扫描table scans 连接joins统计aggregations排序sorts都是并行进行的，而不是串行的。
每一个slice都至少有一个worker process assigned（工作处理被指派）是独立与执行计划的，这时也是并行的。
Greenplum最佳实践
Greenplum最佳实践⼀、最佳实践数据库参数部分GP数据库参数配置以下配置存于⽂件–postgresql.conf中，仅列出⼀些最常⽤的参数。
shared_buffers：刚开始可以设置⼀个较⼩的值，⽐如总内存的15%，然后逐渐增加，过程中监控性能提升和swap的情况。
effective_cache_size : 这个参数告诉PostgreSQL的优化器有多少内存可以被⽤来缓存数据，以及帮助决定是否应该使⽤索引。
这个数值越⼤，优化器使⽤索引的可能性也越⼤。
因此这个数值应该设置成shared_buffers加上可⽤操作系统缓存两者的总量。
通常这个数值会超过系统内存总量的50%。
work_mem: 当PostgreSQL对⼤表进⾏排序时，数据库会按照此参数指定⼤⼩进⾏分⽚排序，将中间结果存放在临时⽂件中，这些中间结果的临时⽂件最终会再次合并排序，所以增加此参数可以减少临时⽂件个数进⽽提升排序效率。
当然如果设置过⼤，会导致swap的发⽣，所以设置此参数时仍需谨慎，刚开始可设定为总内存的5%。
temp_buffers: 即临时缓冲区，拥有数据库访问临时数据，GP中默认值为1M，在访问⽐较到⼤的临时表时，对性能提升有很⼤帮助。
gp_fts_probe_threadcount: 设置ftsprobe线程数，此参数建议⼤于等于每台服务器segments的数⽬。
gp_hashjoin_tuples_per_bucket: 此参数越⼩，hash_tables越⼤，可提升join性能。
gp_interconnect_setup_timeout: 此参数在负载较⼤的集群中，应该设置较⼤的值。
gp_vmem_protect_limit:控制了每个段数据库为所有运⾏的查询分配的内存总量。
如果查询需要的内存超过此值，则会失败。
使⽤下⾯公式确定合适的值：(swap + (RAM * vm.overcommit_ratio)) * .9 / number_of_Segments_per_server1例如，具有下⾯配置的段服务器：8GB 交换空间128GB 内存vm.overcommit_ratio = 508 个段数据库1234(8 + (128 * .5)) * .9 / 8 = 8 GB，则设置gp_vmem_protect_limit为 8GB：gp_statement_mem:服务器配置参数 gp_statement_mem 控制段数据库上单个查询可以使⽤的内存总量。
greenplum数据库函数
greenplum数据库函数（原创实用版）目录1.介绍 Greenplum 数据库2.概述 Greenplum 数据库函数3.Greenplum 数据库函数的分类4.实例解析 Greenplum 数据库函数5.总结正文1.介绍 Greenplum 数据库Greenplum 是一种基于 PostgreSQL 的开源数据库，它为大数据处理提供了强大的支持。
Greenplum 数据库采用了一种称为“列式存储”的存储方式，使得其在处理大规模数据时具有高效的性能。
此外，Greenplum 还提供了许多高级功能，如外部表、分布式查询等，使其在处理大数据时更加灵活。
2.概述 Greenplum 数据库函数在 Greenplum 数据库中，函数是一种预先定义好的可重复使用的代码片段，它可以帮助用户简化查询语句，提高查询效率。
Greenplum 数据库提供了丰富的函数，包括聚合函数、数学函数、字符串函数等。
这些函数可以帮助用户在查询过程中实现各种复杂的操作。
3.Greenplum 数据库函数的分类Greenplum 数据库函数主要分为以下几类：（1）聚合函数：聚合函数是对一组数据进行统计或汇总的函数，如COUNT、SUM、AVG 等。
（2）数学函数：数学函数是用于执行各种数学运算的函数，如加、减、乘、除等。
（3）字符串函数：字符串函数是用于处理字符串的函数，如字符串连接、字符串查找、字符串替换等。
（4）日期和时间函数：日期和时间函数是用于处理日期和时间的函数，如获取当前日期、计算日期间隔等。
（5）其他函数：除了上述几类函数之外，Greenplum 数据库还提供了其他一些实用函数，如数组操作函数、JSON 函数等。
4.实例解析 Greenplum 数据库函数以 COUNT 函数为例，该函数用于统计一组数据的记录数。
在Greenplum 数据库中，可以使用如下语法来实现 COUNT 函数：```sqlSELECT COUNT(*) FROM table_name;```其中，`table_name` 是要统计的表名。
greenplum 使用场景
Greenplum是基于低成本的开放平台基础上提供强大的并行数据计算性能和海量数据管理能力。
其主要特点是查询速度快、数据装载速度快、批量DML处理快、性能可以随着硬件的添加呈线性增加、拥有非常良好的可扩展性。
主要适用于面向分析的应用，如构建企业级ODS/EDW、数据集市等。
Greenplum主要定位在OLAP领域，例如：数据仓库系统、ODS系统、ACRM系统、历史数据管理系统、电信流量分析系统、移动信令分析系统、SANDBOX自助分析沙箱、数据集市等等。
此外，Greenplum支持行存和列存，对应的是堆表和AO表。
行存以行为形式组织存储，查询的时候需要全表扫描要扫描更多的数据块，压缩比较低，读取任意列的成本不一样，越靠后的列，成本越高。
列存以列为形式组织存储，每列对应一个或一批文件。
读取任一列的成本是一样的，但是如果要读取多列，需要访问多个文件，访问的列越多，开销越大。
压缩比高，读取任意列的成本是一样的，非常适合向量计算、JIT架构。
对大批量数据的访问和统计，效率更高，读取很多列时，由于需要访问更多的文件，成本更高。
总之，Greenplum在大数据计算或分析平台等场景下应用广泛。
如有更多关于Greenplum的问题，建议咨询技术专家或查阅相关技术手册获取帮助。
greenplum集群原理
greenplum集群原理
Greenplum是一种基于PostgreSQL的开源数据仓库系统，设计用于处理大规模数据集。
它使用MPP（大规模并行处理）架构，将数据分散到多个节点上，并使用这些节点进行并行查询处理，以提高查询性能。
Greenplum集群的基本原理是将数据分散到多个节点上，每个节点都有自己的存储和计算资源。
这种分布式架构允许多个节点同时处理查询，从而显著提高了大规模数据的查询性能。
在Greenplum集群中，有一个主节点（Master）和多个工作节点（Segment）。
主节点负责管理集群中的所有节点，协调查询请求并分发数据。
工作节点负责存储数据和执行查询操作。
当客户端发送查询请求时，主节点首先将查询计划分发给工作节点。
每个工作节点执行查询计划并返回结果给主节点。
主节点再将这些结果合并并返回给客户端。
Greenplum集群还具有强大的数据并行处理能力。
它将查询分成多个子任务，并将这些子任务分发给多个工作节点。
这些工作节点可以并行处理子任务，并在执行过程中自动进行数据分片和负载均衡。
这使得Greenplum集群能够高效地处理大规模数据集，提高查询性能。
greenplum数据库中hashagg的原理
greenplum数据库中hashagg的原理绿色积木（Greenplum）数据库中的HashAgg操作是一种聚合操作，用于对数据进行分组并进行聚合计算。
本文将详细讨论HashAgg的原理，以及它是如何在Greenplum数据库中工作的。
一、HashAgg的概述在大规模数据处理中，聚合操作是非常常见的，它用于对一组行进行分组并计算每个组的汇总信息，如平均值、求和等。
而在Greenplum数据库中，HashAgg 通过使用哈希算法来实现这种分组和计算的过程。
HashAgg操作的基本原理是将输入的数据根据指定的分组列进行哈希计算，将相同哈希值的数据分配到同一个哈希槽（或桶）中。
然后在每个哈希槽中，对分组列进行分组，并计算其他需要聚合的列的值。
最后将每个哈希槽的结果进行合并，得到最终的聚合结果。
二、HashAgg的实现步骤Greenplum数据库中的HashAgg操作主要由以下几个步骤组成：1. 哈希函数计算：首先，HashAgg操作根据指定的分组列，对输入的数据进行哈希计算。
哈希计算是将输入值通过哈希函数转换成固定长度的哈希码的过程。
通常情况下，哈希函数应该具有良好的均匀分布性，以确保数据可以平均地分配到不同的哈希槽中。
2. 数据分配：哈希计算完成后，HashAgg操作将哈希值相同的数据分配到同一个哈希槽中。
这里使用哈希槽的目的是为了在后续的计算中提高聚合操作的效率。
每个哈希槽都有一个聚合缓冲区，用于存储对应哈希值的分组和聚合结果。
3. 分组和聚合：在每个哈希槽中，HashAgg操作对分组列进行分组，并计算其他需要聚合的列的值。
分组操作是将相同分组列值的数据进行归类的过程，而聚合操作是计算每个分组中其他列的汇总结果，如平均值、求和等。
Greenplum 数据库中通常使用了一些优化技术，如group by position和group by hashing，来加速分组和聚合的过程。
4. 结果合并：在每个哈希槽中完成分组和聚合操作后，HashAgg操作将每个哈希槽的聚合结果进行合并。
greenplum和hive，各有什么特点，哪个适合做数据仓库呢
greenplum和hive，各有什么特点，哪个适合做数据仓库呢
Greenplum和Hive都自称是数据仓库，但是两种体系架构和使用场景有非常大的不同。
1.Greenplum是MPP数据库，适合处理传统的结构化、半结构化数据库，可以处理PB级别数据。
Hive是SQl on Hadoop，是分布式数据库，适合处理超大规模数据，比如100个节点以上。
小规模集群下速度比较慢，一般适合做离线计算。
2.使用场景；
•离线计算：1PB数据以下，只有结构化数据，Greenplum首选。
非结构化数据，用MapReduce或者Spark处理。
处理后的结果放到Greenplum中查询。
•1PB以上数据，其实非结构化数据偏多，用Spark/Mapreduce 处理，GP查询。
•业务分析：Greenplum首选，Hive查询速度比Greenplum要差10倍。
•机器学习：Spark
•地理信息分析：Greenplum+PostGIS。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
数据库系统Greenplum研究目录1. Greenplum简介 (1)2. Greenplum技术特点 (1)2.1 无共享架构 (2)2.2 基础架构MPP (3)2.3 Greenplum应用实例 (5)3. Greenplum同其他数据仓库的对比研究 (6)4. 总结 (7)摘要Teradata 作为渤海商业银行使用的的数据库仓库系统，为银行查询统计功能提供了稳定和高可用性的服务。
作为2014 年重点项目，目前我司的Teradata 版本已经升级到13.1，有效存放数据的容量到到18TB。
本文对时下新兴的数据库系统Greenplum 进行探索和研究，并将Greenplum 同其他主流数据库进行技术分析和对比。
1. Greenplum 简介Greenplum 成立于2003 年6 月，总部位于美国的加利福尼亚州，最初由Sun 公司资助，由Teradata 的几位资深工程师合作创建的为全球大型企业用户提供新型企业级数据仓库(EDW)、企业级数据云(EDC)和商务智能(BI)解决方案和咨询服务的公司。
2010 年7 月，EMC公司将Greenplum 收购，使得其研发和资本实力大大增强，成为数据仓库的一名新锐。
目前已经在纽约证券交易所、eBay、中信银行、淘宝、支付宝等具有较大型数据业务的公司中使用。
渤海商业银行数据仓库组对Greenplum 在数据仓库中的应用进行了可行性分析，并对该公司的运行情况进行了解和访问，鉴于Greenplum 公司与EMC 公司的整合需要一定时间的磨合，以及Greenplum 中国公司的重组，我们认为该企业的成熟度和对中国用户的服务速度还不是十分明确，但Greenplum 作为后起之秀有其值得研究和学习的方面。
2. Greenplum 技术特点Greenplum 成立的时间较晚，因此将主要精力放到了较为新颖的技术：新一代数据仓库和大规模分析处理数据库。
Greenplum 采用了基于相关标准的方法，可以帮助客户创建数据仓库，充分利用低成本的商用服务器、存储和联网设备，通过经济的方式升级到千万亿字节的系统。
它的主要技术和卖点主要有两个：无共享架构(Shared-Nothing Architecture) 和大规模并行处理（简称MPP ，Massively Parallel Processing)。
2.1 无共享架构当今的数据仓库解决方案通常是借助通用数据库（比如Oracle）或基于硬件的专用平台（比如Teradata、Netezza）而创建的。
通用数据库（比如Oracle）是针对OLTP（在线实时查询）功能设计的，在运行大量小规模交易查询数据时效果最好。
从结构上来说，他们采用了“完全共享”或“磁盘共享”体系（图1）。
“完全共享”体系局限于单一服务器（通常是价格比较昂贵的SMP 服务器），其扩展性和性能受到相应的限制。
“磁盘共享”体系（比如Oracle RAC）允许系统带有多个服务器，这些服务器与SAN 或其它共享存储设备相连。
这种体系需要通过一个狭窄的数据管道将所有I/O 信息过滤到昂贵的共享磁盘子系统。
（在“完全不共享”体系中，对每个使用直接相连磁盘的节点来说，其I/O 带宽都近似等于通往共享磁盘子系统的数据管道）。
实践证明：这些通用磁盘共享体系复杂、脆弱，在处理万亿字节数据时难以胜任。
与此相比，基于硬件的数据仓库平台（比如Teradata、Netezza、Greenplum）采用的是“完全不共享”体系。
在这种体系下，在主机上规划查询项目，并将其分成若干部分在集群上并行执行，所有通讯功能都在一个高宽带网络互连体系上实现。
这种体系的一个重要优势就是每个节点都有一个通往本地磁盘的独立高速通道，从而简化了体系，并提供扩展性很好的并行扫描和查询处理功能。
2.2 基础架构MPPGreenplum 数据库采用MPP 无共享架构，对数据进行均匀散列分布。
Greenplum 支持50PB(1PB=1000TB)级海量数据的存储和处理，Greenplum 将来自不同源系统的、不同部门、不同平台的数据集成到数据库中集中存放，并且存放详尽历史的数据轨迹，业务用户不用再面对一个又一个信息孤岛，也不再困惑于不同版本数据导致的偏差，同时也降低管理维护工作的复杂度。
Greenplum 数据库由Master 和Segment 节点构成（图2），Master 节点负责建立与客户端的连接和管理；SQL 的解析并形成执行计划；执行计划向Segment 的分发；收集Segment 的执行结果；Master 不存储应用业务数据，只存储数据字典。
Segment 节点负责：业务数据的存储和存取；用户查询SQL 的执行。
Master 节点和Segment 节点之间通过应用gNet 软件互联技术的网卡和交换机相连接。
此结构使得Greenplum 数据库体系简化，并具有良好的扩展性以及较高的并行扫描和查询能力。
在MPP 系统中，每个SMP 节点也可以运行自己的操作系统、数据库等。
换言之，每个节点内的CPU 不能访问另一个节点的内存。
节点之间的信息交互是通过节点互联网络实现的，这个过程一般称为数据重分配(Data Redistribution) 。
与传统的SMP 架构明显不同，通常情况下，MPP 系统因为要在不同处理单元之间传送信息，所以它的效率要比SMP 差一点，但是这也不是绝对的，因为MPP 系统不共享资源，因此对它而言，资源比SMP 要多，当需要处理的事务达到一定规模时，MPP 的效率要比SMP 好。
这要看通信时间占用计算时间的比例而定，如果通信时间比较多，那MPP 系统就不占优势了，相反，如果通信时间比较少，那MPP 系统可以充分发挥资源的优势，达到高效率，使得数据加载可以并发执行，数据加载速度达4.5TB/h，因此MPP 系统在决策支持和数据挖掘方面显示了优势。
2.3 Greenplum 应用实例Greenplum 在国内主要应用在金融、交通、电信互联网等行业，其中数据量和中国结算相差不大的代表性企业有中信银行。
中信银行为中国大陆第七大银行，其总资产为12000 逾亿港元，共有13485 名员工及416 间分行。
以中信银行为例，其数据仓库的功能和定位为：实现信息资源的集成、整合和共享；信用卡中心数据仓库；支持防欺诈、营销支持等多种挖掘专题应用。
采用2 个Master 节点加4 个Segment 节点构成。
Master 节点使用Sun X4240，Segment 节点使用Sun X4540，Master 节点和Segment 节点间使用Cisco-4948 万兆交换机连接。
中信银行现有数据库的数据量为6TB，每日增长40GB+，依靠ETL ToolBox 等第三方BI 工具。
其中数据库的DW 层采用的Greenplum 数据库，DB2作为上层数据源。
在进行查询分析和决策时，将响应时间缩短到之前的30%。
中信银行的数据库结构如图3 所示。
当前我司数据仓库采用基于MPP 无共享技术的Teradata 数据库和EMC 的智能存储设备。
硬件设备系统采用Teradata 公司生产的6 台WorldMark 5450 作为查询统计系统生产服务器，WorldMark 4475 作为ETL 服务器，IBM X366 作为BRIO 应用服务器，EMC2 公司的DMX3-3500 和Teradata 6288 作为系统存储设备，STK 6466 和STK SL500 磁带库作为数据备份设备。
现有数据总量约为5TB，每日加载数据30GB+，每日加载耗时约一小时。
数据仓库功能主要是历史数据的存储与查询，暂不涉及数据挖掘与分析。
第三方BI 工具采用MSTR，从功能实现上考虑，Greenplum 可以胜任大多数金融机构对于数据仓库功能的要求。
3. Greenplum 同其他数据仓库的对比研究目前在商业应用占有率比较高的数据仓库主要有Netezza、Teradata、Oracle、IBM、Greenplum 等，它们在金融业、制造业、服务业都有广泛的应用。
分析数据仓库优劣的主要指标有开源度、稳定性、海量数据存储和处理效率、高并发支持、线性扩展支持、硬件产品的依赖、共享技术、容量可扩展性能和价格等因素。
本文以稳定性、海量数据存储和处理效率、共享技术、硬件产品的依赖、容量可扩展性能和性价比等指标为标准，对市场占有率前五位的数据库进行分析和对比，如表1 所示，其中绿色代表优秀，黄色代表一般，灰色代表较差。
4. 总结将Greenplum 数据库和渤海商业银行现有的Teradata 数据库进行比较，Greenplum 具有两点优势：第一是硬件方面，Greenplum可以跨平台组建系统，对于我司目前的生产系统来说，可以充分利用业务系统升级换代后的IBM 机器，降低技术系统整体成本，且构建Greenplum 数据库系统的费用会大幅低于使用Teradata 系统。
第二是软件方面，由于Greenplum 与Teradata 有历史渊源，二者都采用MPP无共享架构和数据均匀散列分布，现有的查询前端除了界面需要移植，SQL 语句查询部分可以直接迁移至Greenplum 数据库系统，有利于降低人工成本。
但是Greenplum 也有显著不足，即Greenplum 目前缺乏证券行业内大型企业长期稳定的应用实例，系统的成熟度以及大数据量下的稳定性尚有待考验；同时对于Greenplum 在合作方式和人员的培训方面能够提供的服务也不十分明确。
我司对于数据仓库系统的稳定性和正确性要求很高，现有的数据加载性能完全能够满足要求，将我司现有数据仓库系统移植到Greenplum 上虽然有硬件成本低、软件易移植的优点，但同时需要承担系统稳定性的风险和改造查询前端需要的人力成本，因此Greenplum 在我司的应用条件尚不如Teradata 数据仓库成熟。