Greenplum数据库最佳实践-V1.2

第1页共103页第一章体系结构1.1发展历程Greenplum是2003年成立的，核心技术团队成员来自各个顶级数据库公司和大规模并行计算公司的资深软件架构师，Greenplum数据库软件是业内首创的无共享、大规模并行处理（massivelyparallelprocessing(MPP)）的数据库软件产品，它包含大规模并行计算技术和数据库技术最新的研发成果：包括无共享/MPP，按列存储数据库，数据库内压缩，MapReduce，永不停机扩容，多级容错等等。该数据库软件被业界认可为扩展能力最大的分析型（OLAP）数据库软件。已有100多家世界级重大客户采用该软件，这些客户中大多数Greenplum数据仓库所管理的数据量都超过100TB，其中，全球最大的有6500TB，中国最大的有400TB。每一天，全球有数亿级的用户在直接、间接用到Greenplum发明的数据库平台。Greenplum数据仓库软件是业界首创将大规模并行计算技术，应用到了数据库软件领域。该类技术同样应用在Google搜索引擎的中。主要事件参考如下：2003年：Greenplum由ScottYara和LukeLonergan成立。2005年：Greenplum数据库第一个版本发布。2006年：与Sun公司合作，成为其合伙人。2008年：GreenplumMapReduce发布，同年12月份进入中国市场，一年多后，Greenplum正式宣布在中国独立运营。2010：Greenplum被EMC收购，并被整合到EMC的云计算战略中。2011-2012：Greenplum社区版发布，GreenplumChorus发布并开源。2013：VMware和EMC联合宣布将成立合资公司Pivotal，并将GreenplumDB整合过来。2014：Greenplum4.3发布。第2页共103页2015：10月27日，Pivotal宣布开源GreenplumDB，并将代码托管到github，使用Apache2的版权协议。1.2体系结构面对海量数据的处理需求，发展起来的MPPShareNothing（海量并行处理+完全无共享）技术是唯一解决之道，只有无共享的MPP并行处理技术才能满足海量数据的性能需求；我们可以看到过去几十年数据库计算架构的发展历程。早期（70年代）是Shared-Everthing架构，数据库计算和数据访问都在一个单一的SMP节点上完成，当数据量到达TB级后，这种架构在数据计算和I/O方面都存在很大的瓶颈；随后在90年代，一些数据库厂商（以OracleRAC典型代表）在SMP节点的基础上进行改进，将数据库的计算单元分离出来做并行化处理，进而提高系统的计算能力，但数据访问上还是采用共享方式Share-Storage，这个方式虽有效的解决了计算方面的瓶颈，但我们都知道，数据库性能由两个主要因素决定，一个是CPU计算能力，另外一个就是数据从Disk上的I/O吞吐性能，而计算机技术发展中，CPU性能的技术发展比磁盘要快的多，因此I/O对于数据库性能来说是更为重要的制约因素，而Share-storge没有解决I/O性能瓶颈的问题，当数据量到达5T~10T后，这种架构难以满足性能处理的需求；针对老的架构的不足，业界在90年代末期（以Greenplum典型代表）创新出了MPP+Sharenothing架构，采用完全无共享的并行处理架构，完全避免了集群中各节点在并行处理过程中的CPU/IO/内存/网络等的资源争夺，第3页共103页将I/O和CPU的能力发挥到极致，为海量数据的处理提供了最大化并行的计算处理架构，满足大规模数据的处理性能需求。Greenplum数据库内部架构参考如下：Master节点是整个集群的接入点，负责处理客户端请求，并将客户端提交的SQL生产查询计划，优化后分配到Segment，协调各Segment节点进行并行计算，最后将Segment的计算结果收集后返回客户端，Mastere节点不存储用户数据，只存放数据字典，如DDL；Segment节点，是执行并行计算的节点，所有的用户数据都分布存储在所有的Segment节点中，接收到Master的指令后进行并行计算处理；1.3核心功能1.3.1无共享MPPGreenplum数据库软件将数据平均分布到系统的所有节点服务器上，所以节点存储每张表或表分区的部分行，所有数据加载和查询都是自动在各个节点服务器上并行运行，并且该架构支持扩展到上万个节点。第4页共103页1.3.2多态存储Greenplum发明支持混合按列或按行存储数据，每张表或表分区可以由管理员根据应用需要，分别指定存储和压缩方式。基于这个功能，用户可以对任何表或表分区选择按行或按列存储数据和处理方式。这些是在建表或表分区的DDL语句中配置的，只需在建表或表分区时指定：这个功能基于Greenplum的多态维数据存储技术。第5页共103页1.3.3多层次容错Greenplum数据仓库软件自己包含多层次容错和冗余能力，这是云计算架构软件的一个重要特征。该功能保证整个数据仓库系统在遇到硬件、软件的故障的情况下，任然自动继续运行。第6页共103页1.3.4在线扩容在系统中增加节点服务器即可增加存储容量，处理性能和加载性能。当系统扩展时，数据仓库保持在线，并且完全可用，扩展进程在后台运行。增加节点服务器，性能和容量线性增加。1.3.5负载管理具有系统资源管控能力，并且可控制给各个查询分配各自系统资源。允许管理员指派资源队列，从而管理数据仓库的队列进入执行情况。在运行的查询的优先级可以随时调整。1.3.6高效数据装载基于MPPScatter/Gather流技术的高性能并行加载功能。加载速度随着节点线性增加，实际超过4TB/小时。第7页共103页1.3.7灵活外部访问数据仓库软件可在任意外部数据源上并行运行常规SQL，不论外部数据源的位置，格式或存储介质。1.3.8数据压缩利用业界领先的压缩技术，进一步提高性能，并极大地节省了数据存储空间。用户可获得3-10倍的空间节省，并且同时获得相应有效I/O性能提升。1.3.9多层次表分区允许灵活地按照时间、范围、值域划分表分区。表分区由DDL设定，分区层级不限。数据仓库软件的查询优化器自动从查询执行计划中略去不涉及的表分区。第8页共103页1.3.10索引功能Greenplum支持各种数据库索引技术，包括B-Tree，Bitmap等等。按列存储、按行存储数据库表都支持索引。1.3.11完全遵从SQL最新标准遵从SQL-92，SQL-99，至SQL2003标准，并包括SQL2003OLAP扩展项。所有SQL查询都是在系统上并行执行。1.3.12原生MapReduce功能MapReduce由Google发明，已被证实为一个高扩展性的文本非结构化数据分析的技术。Greenplum的并行数据库软件核心可原生运行MapReduce程序。第9页共103页1.3.13支持SQL2003OLAP扩展标准对SQL语言包括其OLAP扩展标准，都是在Greenplum数据仓库软件实现并行执行。全面支持SQL2003OLAP标准，包括Window函数，Rollup，Cube等等。1.3.14丰富的访问接口及第三方工具完全支持数据库技术接口标准，例如:SQL,ODBC,JDBC,OLEDB，SAS,R语言等。同时，广泛地支持各个BI和ETL软件工具。综上所述，Greenplum数据仓库软件技术构成如下图：第10页共103页1.4对比分析GreenplumTeradataNetezzaExadataDB2无共享MPP架构是?是支持开放硬件平台是是高级负载管理是是是是在线系统扩容是是?按列存储是按行存储是是是是是In-DBMapReduce是支持SQL2003及OLAP是?是?是第11页共103页选项性能线性扩展是是是?加载能力线性扩展是Pipelinedinterconnect是是DAS容错是表分区是是?是是索引是是是是最少的管理/调优是是第12页共103页第二章最佳实践概述2.1概述本文介绍PivotalGreenplumDatabase数据库（以下简称：Greenplum数据库，或GPDB）的最佳实践。最佳实践是指能持续产生比其他方法更好结果的方法或者技术，它来自于实战经验，并被证实了遵循这些方法可以获得可靠的预期结果。本最佳实践旨在通过利用所有可能的知识和技术为正确使用GPDB提供有效参考。本文不是在教您如何使用Greenplum数据库的功能，而是帮助您在设计、实现和使用Greenplum数据库时了解需要遵循哪些最佳实践。关于如何使用和实现具体的Greenplum数据库特性，请参考上的Sandbox和实践指南。本文目的不是要涵盖整个产品或者产品特性，而是概述GPDB实践中最重要的因素。本文不涉及依赖于GPDB具体特性的边缘用例，后者需要精通数据库特性和您的环境，包括SQL访问、查询执行、并发、负载和其他因素。通过掌握这些最佳实践知识，会增加GPDB集群在维护、支持、性能和可扩展性等方面的成功率。本部分概述了Greenplum数据库最佳实践所涉及的概念与要点。2.2数据模型GPDB是一个基于大规模并行处理(MPP)和无共享架构的分析型数据库。这种数据库的数据模式与高度规范化的事务性SMP数据库显著不同。通过使用非规范化数据库模式，例如具有大事实表和小维度表的星型或者雪花模式，GPDB在处理MPP分析型业务时表现优异。跨表关联(JOIN)时字段使用相同的数据类型。堆存储和追加优化存储(Append-Optimized，下称AO)若表和分区表需要进行迭代式的批处理或者频繁执行单个UPDATE、DELETE或INSERT操作，第13页共103页使用堆存储。若表和分区表需要并发执行UPDATE、DELETE或INSERT操作，使用堆存储。若表和分区表在数据初始加载后更新不频繁，且仅以批处理方式插入数据，则使用AO存储。不要对AO表执行单个INSERT、UPDATE或DELETE操作。不要对AO表执行并发批量UPDATE或DELETE操作，但可以并发执行批量INSERT操作。2.3行列存储若数据需要经常更新或者插入，则使用行存储。若需要同时访问一个表的很多字段，则使用行存储。对于通用或者混合型业务，建议使用行存储。若查询访问的字段数目较少，或者仅在少量字段上进行聚合操作，则使用列存储。若仅常常修改表的某一字段而不修改其他字段，则使用列存储。2.4数据压缩对于大AO表和分区表使用压缩，以提高系统I/O。在字段级别配置压缩。考虑压缩比和压缩性能之间的平衡。2.5数据分布为所有表定义分布策略：要么定义分布键，要么使用随机分布。不要使用缺省分布方式。优先选择可均匀分布数据的单个字段做分布键。不要选择经常用于WHERE子句的字段做分布键。不要使用日期或时间字段做分布键。第14页共103页分布键和分区键不要使用同一字段。对经常执行JOIN操作的大表，优先考虑使用关联字段做分布键，尽量做到本地关联，以提高性能。数据初始加载后或者每次增量加载后，检查数据分布是否均匀。尽可能避免数据倾斜。2.6内存管理设置vm.overcommit_memory为2不要为操作系统的页设置过大的值使用gp_vmem_protect_limit设置单个节点数据库（SegmentDatabase）可以为所有查询分配的最大内存量。不要设置过高的gp_vmem_protect_limit值，也不要大于系统的物理内存。gp_vmem_protect_limit的建议值计算公式为：(SWAP+(RAM*vm.overcommit_ratio))*0.9/number_Segments_per_server使用statement_mem控制节点数据库为单个查询分配的内存量。使用资源队列设置队列允许的当前最大查询数（ACTI