本文从多个项目实际经验，总结一些提高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版本