01 背景
作为一款企业级云端数据仓库，每天有大量的新数据需要加载到HashData数据仓库中，与历史数据融合分析处理后又会产生很多新数据。在数仓产生的新数据中，相当一部分是需要从数仓卸载出来，供其它业务系统使用的。每一款成熟的商业数据仓库产品，都会有根据其自身产品特点而设计实现的高效数据加载和卸载工具，例如Teradata的fastload和fastexport ，Snowflake的Snowpipe 等，HashData也不例外。因此，我们重点介绍两款工具Hashcopy 和 Hashexport ，分别用于数据迁移和数据卸载。为了最大限度地提升性能，这两款工具在设计实现中充分考虑了HashData数据仓库分布式架构的特点，让每个计算节点直接参与数据的传输，从而可以应用整个集群的并行处理能力和通信带宽。
02 Hashcopy
严格意义讲，Hashcopy不是一款通用的数据加载工具，设计初始主要用于帮助客户将线下部署的Greenplum Database集群整体（包括数据库对象定义和数据）迁移到云上的HashData集群，此后也用于不同的HashData集群之间的数据迁移复制（灾备的考虑）和某些版本升级（对于某些生命周期比较短的版本，出于工作量的考虑，我们不提供原地升级的功能，而是将旧版本集群整体迁移到新版本集群，然后让旧版本集群下线）。
架构原理
Hashcopy的架构示意图如下，对应源集群（例如Greenplum Database集群）与目标集群（HashData集群）计算节点数量相同的情况。原理直观可见：在源集群计算节点和目标集群计算节点之间建立一一对应关系，直接完成数据在两个集群之间的迁移，充分利用所有计算节点的并行处理能力和通信带宽。
除了这种两个集群计算节点数量相同的情况，Hashcopy还支持大集群到小集群、小集群到大集群的迁移。对于从Greenplum Database迁移到HashData的情况，不管哪种，如果数据表在Greenplum Database集群是哈希分布的，那么数据到HashData后会自动做重分布，因为两者采取的哈希算法不一样，前者是哈希取模，后者是一致性哈希。对于HashData到HashData的情况，当两个集群计算节点数量一样的时候，数据不用重分布；当节点数不一样的时候，重分布会自动执行。
Hashcopy的实现机制是基于Greenplum Database的copy on segment to program功能，与以外部表为实现基础的gptransfer相比，性能更高，稳定性更好。同时，考虑到copy on segment to program的机制需要在源集群每个计算节点和目标集群每个计算节点上分别创建helper进程（不同于计算节点为执行SQL语句而fork出来的QE进程），启动代价比较大，特别是在大集群的情况下。所以，针对数据量不大的表，Hashcopy会选择另外一种策略，直接在两个集群的master节点之间传输数据。Hashcopy是根据源集群统计信息来判断一张表是大表（走计算节点与计算节点之间的数据传输）还是小表（走master节点与master节点之间的数据传输），所以，为了提高Hashcopy的判断准确率，我们建议客户在进行数据迁移前，在源集群对需要迁移的数据库、命名空间或者表进行analyze操作，从而得到更准确的统计信息。
考虑到在客户实际生产环境中，原有的Greenplum Database集群跟云上的HashData集群往往不在同一个机房，需要通过专线连接，而专线带宽一般比较有限（或者昂贵），为了降低实际传输的数据量，Hashcopy会对数据进行压缩，提供的压缩算法包括snappy、zlib 和 zstd ，客户可以根据自己的硬件情况自由选择。
功能实践
Hashcopy主要支持四种级别的数据库对象迁移：整个集群，指定数据库，指定命名空间和指定表。迁移过程包含两部分，首先是迁移元数据，也就是数据库对象的定义；其次是用户表数据的迁移。
- 集群迁移
将一个集群完整迁移到另外一个集群，包括所有的元数据和数据。以下为示意例子:
hashcopy --source-host=127.0.0.1 --source-port=15432 --source-user=hdw --dest-host=127.0.0.1 --dest-port=25432 --dest-user=hdw1 –full
重要参数说明:
- 数据库迁移
将源集群的某个数据库完整迁移到另外一个集群，如果目标集群不存在同名数据库，则会创建一个新的数据库。以下为示意例子:
hashcopy --source-host=127.0.0.1 --source-port=15432 --source-user=hdw --dest-host=127.0.0.1 --dest-port=25432 --dest-user=hdw1
--dbname="gpadmin" --truncate 重要参数说明:
- 命名空间迁移
将源集群的某个数据库下的某个命名空间（schema）迁移到另外一个集群，如果目标集群不存在同名命名空间，则会创建一个新的命名空间。以下为示意例子:
将源集群的某个数据库下的某个命名空间（schema）迁移到另外一个集群，如果目标集群不存在同名命名空间，则会创建一个新的命名空间。以下为示意例子:
hashcopy --source-host=127.0.0.1 --source-port=15432 --source-user=hdw --dest-host=127.0.0.1 --dest-port=25432 --dest-user=hdw1 --schema="gpadmin.schema1" --turncate`重要参数说明:
- 表迁移
将源集群的某些表迁移到另外一个集群，如果目标集群不存在同名表，则会创建新的表。以下为示意例子:
hashcopy --source-host=127.0.0.1 --source-port=15432 --source-user=hdw --dest-host=127.0.0.1 --dest-port=25432 --dest-user=hdw1 --include-table="gpadmin.public.aaa,gpadmin.public.bbb" --truncate 重要参数说明:
03 Hashcopy
Hashexport主要用于将数据从HashData集群中卸载到其它业务系统，例如Oracle数据库。
无论是设计哲学还是实现原理，Hashexport跟Hashcopy是非常相似的，尽可能利用集群多个计算节点的处理能力和通信带宽，加快数据卸载速度。继承于Greenplum Database，HashData支持基于gpfdist协议的外部表，也一定程度上能够实现数据的并行卸载。Hashexport主要有如下几点改进:
- 使用步骤大幅简化，一条命令即可以完成表数据的导出，不像外部表，需要先启动gpfdist服务器进程，然后创建外部表，执行 select insert into 操作将数据写到外部表，最后是一系列清理工作，包括删除外部表，停止 gpfdist 服务器进程。
- 与Hashcopy类似，Hashexport也是基于copy on segment to program机制，中间数据传输支持多种压缩算法，整体执行效率远优于基于外部表的实现。
- 数据通过网络到达ETL服务器后，Hashexport可以灵活地将数据流重定向到各种管道，从而支持各式各样的数据消费者，包括落盘成为文件、直接加载到其它数据库系统(例如Oracle)，不像gpfdist只能产生固定类型的输出。
功能实践
上述的架构图是针对大表的传输策略，让每个计算节点直接向ETL服务器传输数据，实现数据的并行卸载。对于小表，基于与Hashcopy相同的原因，通过master节点向ETL服务器卸载数据会更高效，不过不同于Hashcopy会自动根据统计信息选择合适的策略，Hashexport需要用户自己指定策略，原因是 Hashcopy是迁移整表的数据，而Hashexport支持卸载过滤后的数据(即SQL语句执行结果)，很难通过统计信息得到合理的判断。
- 从master节点卸载
以下为示意例子:
hashexport -h 192.168.111.234 -p 5432 -d warehouse -r schema1.t1 -u gpadmin -s gpadmin -c “utf8” -l “col1,col2,col3” -w “where 1=1”
-m 0 -i “@” -f N -e Y -o /tmp/t1.dat -v N -t N重要参数说明:
- 从计算节点并行卸载
以下为示意例子:
hashexport -h 192.168.111.234 -p 5432 -d warehouse -r schema1.t1 -u gpadmin -s gpadmin -c “utf8” -l “col1,col2,col3” -w “where 1=1”
-m 0 -i “@” -f N -e Y -o /tmp/t1.dat -v N -t Y04 总结
在篇文章中，我们介绍了Hashcopy和Hashexport两款工具，分别用于将数据迁移到HashData集群和将数据从HashData集群卸载出来。到目前，我们的客户利用Hashcopy完成了数十个私有部署的Greenplum Database上云（迁移到云端的HashData系统），涉及超百万张表、近10PB的数据量。其中最大的一个集群有7万多张表，1PB左右的数据（在一个周末两天内完成整体的迁移），而 Hashexport每天从近百个HashData集群向外卸载数十TB的数据。