LoL最新赛事- 2025年最佳英雄联盟投注网站作为一款企业级云端数据仓库，每天有大量的新数据需要加载到HashData数据仓库中，与历史数据融合分析处理后又会产生很多新数据。在数仓产生的新数据中，相当一部分是需要从数仓卸载出来，供其它业务系统使用的。每一款成熟的商业数据仓库产品，都会有根据其自身产品特点而设计实现的高效数据加载和卸载工具，例如Teradata的fastload和fastexport ，Snowflake的Snowpipe 等，HashData也不例外。因此，我们重点介绍两款工具Hashcopy 和 Hashexport ，分别用于数据迁移和数据卸载。为了最大限度地提升性能，这两款工具在设计实现中充分考虑了HashData数据仓库分布式架构的特点，让每个计算节点直接参与数据的传输，从而可以应用整个集群的并行处理能力和通信带宽。

　　严格意义讲，Hashcopy不是一款通用的数据加载工具，设计初始主要用于帮助客户将线下部署的Greenplum Database集群整体（包括数据库对象定义和数据）迁移到云上的HashData集群，此后也用于不同的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操作，从而得到更准确的统计信息。

　　上述的架构图是针对大表的传输策略，让每个计算节点直接向ETL服务器传输数据，实现数据的并行卸载。对于小表，基于与Hashcopy相同的原因，通过master节点向ETL服务器卸载数据会更高效，不过不同于Hashcopy会自动根据统计信息选择合适的策略，Hashexport需要用户自己指定策略，原因是 Hashcopy是迁移整表的数据，而Hashexport支持卸载过滤后的数据(即SQL语句执行结果)，很难通过统计信息得到合理的判断。

　　在篇文章中，我们介绍了Hashcopy和Hashexport两款工具，分别用于将数据迁移到HashData集群和将数据从HashData集群卸载出来。到目前，我们的客户利用Hashcopy完成了数十个私有部署的Greenplum Database上云（迁移到云端的HashData系统），涉及超百万张表、近10PB的数据量。其中最大的一个集群有7万多张表，1PB左右的数据（在一个周末两天内完成整体的迁移），而 Hashexport每天从近百个HashData集群向外卸载数十TB的数据。