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 的数据。