关于数据库:Hashcopy与Hashexport工具的使用

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次要有如下几点改良:

  1. 应用步骤大幅简化,一条命令即能够实现表数据的导出,不像内部表,须要先启动gpfdist服务器过程,而后创立内部表,执行 select insert into 操作将数据写到内部表,最初是一系列清理工作,包含删除内部表,进行 gpfdist 服务器过程。
  2. 与Hashcopy相似,Hashexport也是基于copy on segment to program机制,两头数据传输反对多种压缩算法,整体执行效率远优于基于内部表的实现。
  3. 数据通过网络达到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 Y

04 总结

在篇文章中,咱们介绍了Hashcopy和Hashexport两款工具,别离用于将数据迁徙到HashData集群和将数据从HashData集群卸载进去。到目前,咱们的客户利用Hashcopy实现了数十个公有部署的Greenplum Database上云(迁徙到云端的HashData零碎),波及超百万张表、近10PB的数据量。其中最大的一个集群有7万多张表,1PB左右的数据(在一个周末两天内实现整体的迁徙),而 Hashexport每天从近百个HashData集群向外卸载数十TB的数据。

评论

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

这个站点使用 Akismet 来减少垃圾评论。了解你的评论数据如何被处理