GBase 8a如何提高加载性能,影响性能的因素有哪些

本文从多个项目实际经验,总结一些提高GBase 8a影响加载性能的方因素和提高加载性能的方法。

参考

GBase 8a 加载大量小文件时,通过NOSPLIT参数较少执行计划耗时
GBase 8a集群86版本加载相关参数

加载过程

解析

语法解析,拿到锁,然后连接数据源,获得数据文件大小,根据加载机数量做切分,然后把任务下发到分发节点(选几个计算节点)。

如果数据数压缩的无法切分,或者数据文件数量是分发节点的整倍数,比如10个分发节点,加载10个、20个、30个大小相当的文件,此时可以通过nosplit参数,不再获得数据文件的大小,也不再做切分。 详情参考 GBase 8a 加载大量小文件时,通过NOSPLIT参数较少执行计划耗时

分发

分发节点,串行的从数据源获得数据,然后根据表的分布方法,将数据分发到集群计算节点上。

如果数据量大,可以通过提高分发节点数量的方法(gcluster_loader_max_data_processors参数),让更多的计算节点参与数据读取,分发。详情参考 GBase 8a集群86版本加载相关参数

保存

集群计算节点拿到数据后,保存到本地数据文件。

提交

发送commit,完成加载任务,释放锁。

加载性能影响点

数据源

已知如下几种情况,导致数据源性能差

系统负载

包括出现SWAP, 磁盘性能差,CPU降频等,基本都是操作系统级的问题。

协议

sftp协议由于加密,其性能先天就比ftp性能差。

数据大量小文件

大量的小文件,不仅影响了磁盘IO,也影响了网络传输。建议在实时性满足的前提下,尽量提高单个文件的尺寸,比如GB级。

压缩文件

GBase 8a支持gz、SNAPPY、lzo等压缩格式文件,减少了文件容量和网络传输量,但同时解压缩是需要耗资源的,而且压缩文件只能单个分发级流式处理,不能再分。所以压缩一般会带来性能下降,除非数据源的磁盘或者网络性能是瓶颈。

网络

网络瓶颈

常见的万兆网,每秒传输1GB数据,但有些业务数据量极大,如果只有1个数据源,会发生无法满足的情况,此时就需要一次加载,多个数据源同时提供才可以。建议通过hadoop等自带高可用的数据源。

网络降速

发生过万兆网,降速到千兆和百兆的事后,且有可能发生在部分节点之间,包括数据源和集群之间,和集群各个节点之间。 在云环境下,也出现过部分节点之间网络只有1-3MB/s的性能,正常的能达到150MB/s。这个需要网络层面进行排查。

GBase 8a 集群

系统负载

和数据源一样的操作系统级的问题

数据库负载

数据库的业务负载高,比如SQL涉及的数量大,SQL并发高,导致系统资源繁忙,耗时变长。

数据库锁

GBase 8a对同一张表,只能有一个DML/DDL操作,其它的需要排队等候。所以如果多个加载任务同时向一个表加载,会导致串行执行。

建议合并加载任务,一次加载多个数据源的数据文件。同时尽量减少或控制对表的其它DML操作。

分发节点数量等参数

部分解释请见前面的分发部分。

gcluster_loader_max_data_processors 默认16个,如果文件很大,很多,建议提高该参数,如果很少很小,那么建议减少数量。同时要考虑到并发加载的影响。我这面遇到单表最大的每天在2000亿行,几十TB,分发节点用了40个。

gcluster_loader_min_chunk_size 该参数是切分建议,低于这个的就不切分了,避免10M文件也被切分成40份。默认64M.

其它参数请参考 GBase 8a集群86版本加载相关参数 , 同样适用于V95版本