从HANA到Greenplum

最近有幸参与了一个非常有意思的项目POC,客户是一家行业排名第一的科技型制造企业，生产系统大部分都采用的是SAP的应用，数据库也有很多HANA。本文不想讨论数据仓库选型和架构设计方面的话题，只是站在数据集成的角度看看，假如客户需要将数据从生产系统的HANA复制到Greenplum进行分析，为什么HVR是最佳的解决方案。

众所周知，HANA作为SAP的内存计算平台，其主要的几个特点就是速度快，数据压缩比高。而速度快，尤其是分析查询速度快以及速度压缩存储的特性又是跟它的列式存储模式紧密相关的。所以即便是OLTP类应用，SAP原厂方案也广泛使用列式存储的表，而不是使用行表方案。

而Greenplum也是Pivotal的拳头产品，主要使用场景就是数据仓库和数据湖。主要特点也是列式存储和MPP架构，具有非常强悍的横向扩展能力。为了实现数据高速装载，Greenplum提供了gpfdist服务实现外部文件数据并行加载的功能。普遍使用的gpload其实是对gpfdist服务的简单封装而已。

由于客户生产系统是7*24小时，且数据量巨大，不太可能提供足够的数据抽取窗口时间，所以本次POC，对数据集成工具主要就是考察数据从HANA增量复制到Greenplum。尤其是为了避免对生产造成过大的负载影响，客户希望能够采用基于日志的变化捕获技术来实现数据的实时复制。

通过这次POC，一方面也展示了HVR强悍的数据同步性能和异构支持的能力，另外一方面也深入了解和学习了由于HANA的特殊性所带来的一些方案设计上需要注意的地方。

首先在HVR的部署上，无论是HANA做源还是做目标（对，本次测试因为比较顺利，客户还考察了将数据实时同步的HANA的场景）都必须要在HANA服务商安装启动hvr remote listener。这个监听服务是随着HVR安装包提供，仅需要按照下面的语法启动即可，不需要做额外的安装配置。

$hvrremotelistener -d -N 4343

此外，HANA上还需要安装unixodbc driver manager和HANA Client，安装完毕后再odbcinst.ini文件里写入HANA的ODBC驱动信息即可

[HDBODBC]

Description = ODBC Driver for SAP HANA

Driver =/hana/shared/NCF/hdbclient/libodbcHDB.so

然后就可以在HVR里配置HANA的location：

为了实现基于日志的数据捕获，还需要对复制用户做一些授权工作，这里就不做赘述了，联机手册上有详细指导。

对Greenplum的安装也是类似，为了性能方面最优，也需要在GP的服务器上安装启动HVR的监听服务。HVR使用DataDirectConnect64 XE ODBC连接GP数据库，

为了提高数据装载到GP的速度，还需要启动gpfdist服务

/opt/gpfdist-4.3.0/gpfdist-p 8181-d /data/pocdata1 -l /tmp/gpfdist.log -m 10485760

其中-m参数是为了防止当出现源数据行过长时超出gpfdist的限制，尤其是在源数据有lob字段时尤其需要注意这一点。

HVR配置GP的location也同样很简单:

但是需要主要额外配置locationproperties的/StagingDirectoryHvr和/StagingDirectoryDb项。如下：

/StagingDirectoryHvr=/data/pocdata1

/StagingDirectoryDb=gpfdist://172.26.64.111:8181

HANA和GP的Location定义好之后，就可以配置channel了。在本次测试里仅使用了一张测试表：

由于HANA的特殊性，没有supplemental logging，HVR还需要配置一个hvr_rowid作为虚拟主键来唯一确定数据行。配置方法就是添加2个columnproperties action：

在源组配置columnproperties /Name=hvr_rowid /CaptureFromRowid /SurrogateKey

在目标组配置columnproperties /Name=hvr_rowid /SurrogateKey

这样带来一个副作用就是目标表上会多一个hvr_rowid的字段，这个字段仅仅为了复制存在，不会影响数据分析的结果和性能。也由此可见，目前HVR在做方案设计时，需要避免直接将HVR复制到文件型的目标，例如hdfs和Kafka，也不能做timekey的复制。

压力测试是通过工具并行对测试表做插入，更新删除操作，每1000条提交一次。HVR采用的单通道的配置方式，评估单条链路的复制性能。下面是一些测试结果：

1. 存量数据初始化同步

HVR refresh功能可以实现异构环境的初始化同步，并且可以自动在目标库上创建对应的表。

单表的初始化性能显得并不是很快，这可能有2个原因，一是因为数据量只有50万条，比较小，难以体现gpfdist并行装载的能力；二是因为HVR刷新过程，对单个表来说是串行操作，数据首先从源库导出为文件，然后压缩传送到HUB，再从HUB传输到GP服务器，然后再调用gpfdist服务装载到GP库（不需要解压缩，gpfdist服务可以直接从压缩文件装载）。

2. 数据比较性能

对同样的50万条数据比较的速度就快很多了

全表比较仅需要6.2秒。这与数据库的查询速度能力是分不开的。

3. Capture性能

在压测过程中，并没有观察到Capture追不上源端数据产生的速度现象，所以可见Capture的能力还远没有到其上限。

通过观察capture的日志，以红色部分为例，我们可以看到捕获速度超过65000笔/秒

4. Integration性能

测试过程，Integraton速度是整体复制的瓶颈，我们同样可以从日志里看出，

由于HVR的数据装载算法特点，会合并对同一条记录的多次操作（例如一个insert，跟着对这条记录做若干次update，会被合并为一个insert操作）。以上面日志里红色的条目为例，我们可以看出HVR写入速度实际为48713笔/秒，对应的源端操作为50377笔/秒。

除了性能强悍外，HVR还提供了丰富的统计报表，帮助管理了解复制的历史状况：

注（延迟部分，由于服务器之间时钟没有校准，有5.5分钟的差值，所以延迟也有5.5分钟的固定值）