Greenplum在企业生产中的最佳实践（下）

原文地址

今天，我们将分享国内客户在使用GP时遇到的问题及相关建议。同时，架构师就大家经常遇到的技术问题进行了细致的说明，相信对您有所启迪！

第一个案例——底层数据文件报错处理

在一个金融客户的案例中发现RAID卡故障导致底层的数据文件损坏了。这是什么意思呢？假如通过操作系统的命令找到这个文件，去cat这个文件或者去做这样的一些操作的时候，是正常的，是没有任何问题的。但是通过GP去查这个表的时候，就会报错，说底下的数据文件有问题。这是因为这个数据块有它自己的特殊的组织方式，会有一些校验。当时认为既然这是因为有硬件问题导致的数据文件的损坏，那就强制地把这个primary切到mirror节点。切到mirror节点之后，查这个表同样的报错，这就比较奇怪。因为出故障的只是primary节点，但切到mirror之后，同样发现了问题。

后来分析到，是因为这个客户数据量非常大，他在里面使用了heap表，heap表是原生的数据存储方式。在GP里面，目前它对于heap表在读写或者同步的时候是没有做校验的。就是在一些极端异常的情况下，比如说底层的数据文件，比如RAID卡bug等等，数据写到一半，导致块损坏的情况下。假如去更新这个块，块上损坏了某一行记录而更新的数据就是另外一行，那在更新完成之后，通过块复制的方式，它就会把这个坏块复制到对应的mirror节点上去。这个时候，因为它没有这种文件校验机制，所以切到mirror之后，对于heap表来说也是报错，就是用之前的primary的坏块把原来的数据库给覆盖掉了。所以这样的话会导致数据的损坏。

所以建议在企业里如果有非常大的表，并且会有经常的读写访问的话，还是使用GP的appendonly表，因为appendonly表本身在底层存储，会在每一个块上算一个MD5值，这样的话当文件损坏再去扫这个表的时候，就会做一个校验，发现真正读取的数据和保存的MD5值不匹配，就会报错退出。因为已经报错退出，就不会做接下来数据写入的动作，就不会把坏的数据块同步到mirror节点。所以对于appendonly表，不会有这种情况。

另外，在GP即将发布的5.0的版本，也会对heap表做一些底层的改进。在这种极端异常的情况下，对于heap表，也不会说因为硬件的故障在写入的时候，导致主备节点的数据同步，导致主备数据都损坏的情况。

第二个案例——网卡的自动降级

某一个地市银行客户，在集群空负载的情况下，因为磁盘损坏了，要换磁盘，把服务器停掉，把磁盘换上去之后，重启集群，做同步。因为是空负载，这个阶段没有任何的数据写入和数据变更，应该是很快可以完成的，但这个主备的数据同步花了将近两个小时。

刚才提到对于数据文件在底下GP同步的时候，会通过实时的同步给同步过去，但是它底下还有一些xlog日志文件等等，对这样的一些日志每次做同步的时候，都会用primary全部覆盖到mirror节点。这是因为这个客户同样是使用了大量的heap表，导致xlog非常庞大，在这个节点起来之后，由于网络配置的是千兆网络，自动的把千兆网络降成百兆了，两台机器同步的带宽大概只有10MB/s的带宽， xlog又非常大，所以导致主备同步花了非常长的时间。同步完成之后，后面要跑业务，因为本身带宽已经下降了将近10倍左右，所以对整个业务造成了非常大的影响。
可以在操作系统层面，包括在交换机层面，禁止了网卡的自动降级的方式，去避免这个问题。

第三个案例——恢复硬件故障的性能

某省移动客户出现了一种情况，它底下的硬盘虽然有了一些坏块，但它在写入时，在RAID卡控制器层面并没有真正把磁盘标记出来，直接把坏的部分offline掉，然后再做rebuild。因为它磁盘本身会有一些容错机制，它会不断地尝试去读取数据。虽然硬盘有一些坏块，但是硬件层面并没有彻底的把它隔离。硬盘处于将坏不坏之间，对整个集群的性能造成了非常大的影响 。

正确的处理是，直接把物理节点进行强制的物理隔离，就是把它给shutdown掉，让它自动地切换到mirror节点，通过这种方式去恢复它的性能。

对于GP来说，企业客户遇到80%、90%的问题往往都是硬件故障或者操作不当，使用表设计不当造成的影响。所以在整个集群规划部署，包括使用的过程当中，一般还是要尽量遵循最佳的实践，包括在搭建的时候，磁盘的选择、RAID的做法以及底下的primary的放置，还有定期做一些备份的动作，对于这种异常情况，我们就可以通过刚刚提到的GP自带的一些工具，还有Linux的一些命令去定位一些比较难定位的问题。

---

-- Q&A --

1.Greenplum使用外部存储的多吗？

GP一般建议还是使用本地的X86自带的SAS盘做数据的存放，我们在一些金融客户里面也有比如他用SAN存储做的GP数据的存放，但是它之间的网络带宽一般都会用光纤网络去接入到GP的X86服务器，也有这种案例。但是真实生产里面用的比较少，因为SAN存储，首先是成本比较高。另外，它对整个网络拓扑也会要求比较高一些。另外，当性能不太好的时候，扩容也会带来一些问题。因为GP本身从严格意义来讲，就和我们这种Hadoop方式不太一样，还是一种比较集约型的管理方式，数据打散在本地的X86服务器，这样在后续计算的时候，能用到很多之前已经预设好的优化的方式，来提升性能。
你用外部存储的话，相当于它很多的优化的方案，实际内部做的优化已经用不到了。但是对于一些目前包括阿里云等云上的客户，因为外部的存储越来越多，我们现在在云上也有一些基于GP的使用案例。

2.对于Greenplum这种master节点有standby的架构，如何保证它的高可用？

对于GP来说，当master节点挂掉之后，切换动作虽然非常快，但是还是需要人工去做这样的触发的动作。我们在真实的企业里面，建议切换master的时候，一般情况下还是要看一下，你要确定一下元数据有没有同步。另外，要看一下是什么故障导致的，要简单的分析一下。另外，你做成这种全自动的方式是很容易的，自动化脚本切换是很容易的，但是前面还是有一些判断的动作，我们也有客户把这个判断和切换的逻辑封装在一起，做成自动化脚本的 。

3.GP有没有比较自动化的日志分析功能？

因为GP主要还是做一个结构化的数据处理，目前我们有一个GP text组件，是可以直接部署在GP上面，底层是做非结构化的数据的处理，如果有这种日志分析的话，可以尝试一下GP text组件。

4.GP如何管理非结构化数据？

对GP来说，主要还是处理结构化数据，因为GP在底层存储，还是通过表这种方式，虽然现在已经支持了一些XML等半结构化的数据，但是在真实的企业里面做分析的时候，比如做一些图像的处理，完全的非结构化数据处理的话，我们往往还是需要通过转换，比如把二进制的数据转化成结构化数据存储到GP里面，然后通过并行的方式做分析。因为导出的话，还是需要非结构化数据。所以要再把它转化成非结构化数据，因为GP里面支持非常多的函数，包括C等语言，我们都可以灵活的去自定义这样的一些函数，去做一些非结构化的数据的处理。但是总的来说，它在处理非结构化数据的话，还是要做一些转化，转化成结构化数据再做处理。

5.另外一个问题，刚刚提到某一个客户那边在机器重启之后，带宽自动降级的情况。

说实话，我们当时没有仔细排查这个原因，因为带宽一般是在交换机和主机层面有一个协商，协商一个带宽。我们当时没有具体排查原因，最后我们在操作系统层面把带宽强制成千兆了。一般我们在企业部署的话，比如在交换机、主机，禁止带宽协商，让它强制成我们标准化最大的带宽，避免这种问题。

6.使用本地盘做RAID，是基于成本考虑还是其他原因？

我们这边RAID一个是成本，一个是从性能上说，因为目前X86服务器配24块盘已经是市面上比较常见的了，单台X86服务器有机是在顺序IO上，整个顺序的吞吐并不比SSD或者SAN存储差很多，就是说机器多了之后，并不会有很大的差异。对于标准化的X86服务器来说，我们一般还是建议用本地盘做RAID，它不同于Hadoop这种方式，因为Hadoop目前能够在块级别设备份的副本数。对GP来说，在软件层面是支持一副本，底层还需要通过RAID这种方式在硬件层面也做一份高可用，实际上来说，它的数据可靠性相比于Hadoop 3副本来说还是高的。

7.GP单节点的数据量有建议上限吗？一般不超过多少？

单节点的数据量是没有上限的，因为我们GP一般建议底下的文件系统是使用XfS文件系统，而XfS文件系统对单个文件就受限于本身文件系统的限制，因为XfSP本身对单个文件的支持是非常大的，并且支持的数目也是非常多的。所以说对单节点的数据量是没有限制的，受限于文件系统本身，还有本身这个盘的大小的影响。
我们的建议是，在空间使用，就是在真实生产上布的话，不要超过70%，超过70%当然也可以正常去跑，但是当空间再多的时候，比如说大的文件内存不够，这时候可能会对机器的性能或者软件正常运行造成一些影响。所以一般的情况是，单节点的数据量是受限于本身的硬件。

8.GP在哪个数量级别以上会有明显性能下降？

GP在底下的数据容量上，不管是TB、PB、ZB，在数据容量上是看不出来的，因为说到底就是用底层的物理资源，比如IO、吞吐、CPU、内存去做相应的计算，但是对于GP这样一种MP的架构来说，一般情况下对大的查询来说，会发到所有的节点去执行。对于集群的规模，还会有一些影响。

GP建议我们在实验室环境下，MPP这种架构节点数尽量还是不要超过一千个节点，因为一千个节点之后，在网络的交互和通信方面都会有一些影响。虽然GP内部已经有UDPFC协议，已经对协议层做了一些改进，但是当集群规模非常大了之后，对于这种短的查询、小查询，数据量不是特别多的查询，还会有一些影响。对于底层数据量的话，是没有明显影响的。

我们国内客户超过PB级别，就是压缩之后整个数据量已经超过PB级别，压缩之前GP一般在银行的压缩级别可能是3到5左右，在电信那边可能也有3左右。真实的数据量可能已经到3、4PB左右了。

9.GP与HAWQ应用场景有什么不同？

现在来说，HAWQ也是我们公司的另外一个基于Hadoop的原生的SQL引擎。简单来说，目前HAWQ能做的事情GP都可以做，但是HAWQ不能做的事情GP也能做。因为它底基层是基于HDFS，上面包括表的update、索引目前还不支持，在GP里面如果有索引查询，还有一些数据更新的场景的话，对于GP来说还是比较合适的。

HAWQ一个典型的应用场景就是，如果你已经有了一个Hadoop集群，上面也存了很多数据，想用它做一些原生的分析的话，我们用HAWQ还是比较方便的。因为HAWQ和GP架构不太一样，就是我们2.0做的最大的变化，它在底层起计算实例的话，对GP来说，比如一个大的SQL放下来，所有的postgre实例都会起来做相应的计算。但对HAWQ来说，它会根据你底下真正的数据块的规模和分布情况，就是它能比较灵活的来起相应的计算的节点去做计算。所以说对于这种云计算和Hadoop这样的故障率比较高的场景来说，使用HAWQ是比较合适的。

GP对HAWQ也真实测试过，比如都采用相同的分布件，对这种大的查询来说，因为HAWQ底层是基于HDFS，所以性能可能要比GP有将近20%的性能损耗。但是相比其他的Hadoop上的引擎，HAWQ是GP做了十几年的并行引擎，直接放在上面也做了很多优化，它的性能还是非常强的，并且在SQL支持层面应该是目前最好的。

10.HAWQ会替代GP吗?

我个人感觉未来的云化的数据，包括存储与计算分离，是一个方向。但是目前很多SQL Hadoop引擎打着要替换MPP的宣传标语去做这样的一些事情，但是目前来说，我刚刚提到的，比如在功能性上，包括在性能上的一些限制，目前来说它还是没有办法去替代的。未来如果是在云上的话，我们选择HAWQ也是一个非常不错的方案。

11.Greenplum与Hadoop有什么区别？应用场景各有所长吗？

这个就是刚刚提到的，GP的这种MPP架构之前的数据存放相当于已经对数据做了一些预设置，比如数据怎么分布、数据模型等等方面已经帮你提前做了一些规划，所以它之后再做一些查询的时候，能用到之前的这些设计，所以在性能上比传统的Hadoop上跑SQL的引擎，性能上会有非常大的明显的性能的提升。这个只是SQL类的。

但是对于一些非结构化的数据，刚刚也提到，因为Hadoop底层就是一个分布式的文件系统，你如果有一些非结构化的数据，使用Hadoop还是非常适合的。

另外，Hadoop是可以到非常大的规模，就是Hadoop可以到五千个节点，以阿里举例，飞天已经到五千个规模。这样从原理上来说，Hadoop比如在做一些请求的做，可以采用HAWQ类似的架构，你虽然五千个节点，但是我在跑SQL的时候，我可以根据具体的情况，可以在里面只用三四个节点做计算。真正的数据交互并不是说我一个SQL下去，五千个节点都要做这样的数据交互。所以说对于MPP和Hadoop来说，这个集群规模本身的设计，MPP包括GP的规模，应该还是达不到Hadoop这样的规模。但是从它的执行效率，包括在数据仓库里面的一些使用场景做一些分析计算来说，GP比Hadoop还是有非常强的、明显的优势。

12.SAN网的速度应该没问题吧？

这个就看你具体的网络部署。我们当时在最开始平安银行有一套GP集群，就是基于SAN网络，也跑了很长的时间，这是完全没有问题的。还要看你底下SAN采用什么存储，你接入GP的时候的网络，还受限于硬件的拓扑。但是你使用SAN的话，本身GP做的一些优化实际上是用不到的。

13.一般X86服务器最多插多少块盘？

目前我们市面上看到的比较多的是24块盘，就是数据盘是24块盘。前面前置的可能会有两块SSD的做RAID1，放操作系统。这是市面上我们见的比较多的24块盘2U的机器。如果采用4U的机器的话，盘数还会更多。

但现在本身RAID卡的接口带宽有些限制，盘多的话可能会达到RAID卡的性能的瓶颈。假如24块盘，底下都是用SSD，在这种情况下有可能达到RAID卡的性能瓶颈，导致IO上不去。即使磁盘性能很强，对于MPP这种架构经常会有数据跨网络之间的交互，即使IO能力很强，但网络比如只有一万兆的带宽，也会受限于网络的带宽。所以说在整个集群搭建和服务器选型的时候，我们往往会是一个综合的考虑，就是IO和网络之间达到一个均衡的状态。

14.如果在私有云上部署GP性能较物理机会明显下降吗？

还是要提到受限于本身这个云上的磁盘，还有这之间的网络，包括硬件设备的影响。我们在真实的企业客户里面，比如我们在国泰航空里面，他们做了一层虚拟化去做相应的GP的部署，就是生产环境上也是采用私有云做了部署。

当时我们具体测试下来的结果就是，在IO层面会有一些性能损耗，但是对整个集群的使用影响也不大，大概下降了10%到20%。

15.GP搭建大数据集成平台的时候要注意什么？

第一，硬件选型要均衡，不能有明显的性能短板。

第二，数据容量和未来业务的发展要提前规划好。因为存储层面、容量层面是最容易规划的，这个定了之后，可以选择你采用胖机器还是瘦机器。胖机器就是比如单台机器配置非常高，比如可以有1TB的内存，24块1.8T或者2TB的盘。

对于GP来说，一般情况下如果能用小的规模，就是可以用小的胖机器能满足你业务要求的话，还是尽量选择胖机器，因为胖机器本身规模大了之后，硬件出故障的概率还是比较高的。所以说对于选型的时候，大数据平台搭建的时候，我们主要还是从业务和未来性能和空间的规划来考量具体怎么去选硬件、怎么去做部署。

16.GP什么时候用heap表，什么时候用AO表？

目前对GP来说我们的建议是，一个总的原则是，能用AO表的就尽量用AO表，不能用AO表的时候你再用heap表。因为之前对GP来说，在4.2之前的版本，appendonly表因为本身做压缩、做一些东西的时候，是不能做update、delate，目前GP AO表已经能做了。因为AO表我们刚刚也提到，在底层的数据校验，包括在写AO表的时候，写的WAL日志都非常少，你写heap表的话，除了写本身的数据文件还要写大量的日志文件，并且heap表不能压缩。

一个总的原则，能用AO表的就尽量用AO表。那heap表什么时候用呢？因为在heap表上可以建主键索引，现在目前AO表还不支持，如果有主键这种约束的情况下，我们还可以使用heap表。

原文地址