原Greenplum集群在进行10亿*1亿的关联查询时达到极限，无法支撑更大数据量级的关联查询。使用DorisDB替换Greenplum构建新的集群，在进行736亿*15亿的超大量级数据关联查询时，不仅可以顺利完成，并且耗时很短，对业务的整体提升巨大。

　　　　一、使用背景

　　　　1.1选用原因

　　我司原有业务查询使用的数据库为Greenplum，在数据源变更后，数据量从原来的日增千万级别(近百G)暴增至日增千亿(10T)级别，原有的12台GP集群在数据量增长后存在以下痛点：

　　1、数据导入

　　原有的数据导入借助于gpload的工具，在有索引的情况下，数据导入随着数据量的增加会变慢，在千亿级日增情况下，有索引的表根本无法导入。即使使用先导入数据，后建索引的方式，导入过程还是不理想，建索引的时间会由于数据量的增长而增长，由于机器资源在现有的基础上增加的的可能性不是很大，使用该方式做数据导入，整个流程耗时相当长，无法满足业务需求。

　　2、数据存储

　　GP在数据存储这一块，如果使用heap表的方式创建表，数据来说是不做任何压缩进行存储，比较占用存储资源。如果采用列存表的方式，需要手动指定压缩等级和字段，但是使用者在不清楚数据重复的具体情况下设置该参数就只能是想当然去做，然后在生产中根据数据实际情况进行更改，在查询时，cpu会进行解压缩操作，增加了cpu的计算耗时。

　　3、数据计算

　　计算瓶颈其实是我们数据量增长之后主要的痛点。在原有的使用过程中，针对于业务A的整体运行时长，从客户触发到 终显示，需要大概100分钟左右，数据量增长后，业务A的基本跑不动。其次，在日常的etl过程中，一些定时表关联在原GP的处理过程中只能是对事实表按照时间粒度做切分，小部分小部分的进行关联，然后再进行合并处理，数据量增长之后的关联，在现有资源下也无法实现。

　　在GP无法承受如此巨大的数据量，满足不了业务的需求时，我们将目光转向其他解决方案，在测试了DorisDB，clickhouse以及其他olap产品后，结合自身的业务特点和使用上的易用性， 终选用了DorisDB作为MPP的解决方案。此文档也是基于DorisDB进行详细的业务测试过程中整理的文档。

　　　　1.2集群配置

　　此次测试使用的机器资源如下所示(只部署了DorisDB的环境)：

　　机器数量：10台

　　机器系统：centos7.6

　　机器内存：256G

　　机器磁盘：7200转机械硬盘，每台机器为8T*4,做了raid0

　　网络带宽：内网万兆光迁

　　CPU:2*12 core

　　此次部署的DorisDB的集群详情如下(未使用spark load，没有安装spark的客户端)：

　　fe数量：3台(1 master+2 follower)

　　be数量：10台

　　broker数量：10台

　　　　1.3集群配置参数

　　针对自身业务特点，修改了以下参数：

　　fe:

　　broker load的参数

　　1.允许运行的 大的broker数量

　　max_broker_concurrency=10

　　2.每个be处理的数据量

　　max_bytes_per_broker_scanner=32212254720

　　上述两个参数影响broker load导入时be处理数据的并发数量和单个be处理的数据量

　　be:

　　文件合并的参数

　　1.be节点base compaction线程数量

　　base_compaction_num_threads_per_disk=4

　　2.base compaction时写磁盘的限速，单位为M

　　base_compaction_write_mbytes_per_sec=20

　　3.be节点cumulative compaction的线程数量

　　cumulative_compaction_num_threads_per_disk=8

　　4.be节点cumulative compactiond写磁盘的限速，单位为M

　　cumulative_compaction_write_mbytes_per_sec=300

　　5.be节点cumulative compactiond线程轮询的间隔

　　cumulative_compaction_check_interval_seconds=2

　　上述五个参数主要控制DorisDB对于文件合并的效率，可以根据自身的硬件性能和实际业务情况调整该参数。大量数据导入到DorisDB中时，DorisDB需要根据排序key做排序，根据字段的值做压缩合并的操作，此时会占用磁盘性能，调整该参数(业务闲时)可以加速这一过程，使DorisDB专注于计算。

　　以上参数仅提供参考，请根据自身资源和实际情况酌情调整

　　　　二、数据导入

　　由于数据源的特殊性，数据存放在文件中，原始文件为压缩文件，因此在实际测试过程中，我们主要对以下几种导入进行了测试(spark load未测试成功)， 终选取了broker load的方式作为 终的数据导入的方案。该方案能够实现单任务200W+/s的导入速度，并且支持并行的方式，进一步提高数据导入速度。

　　　　2.1 stream load