如何高效简洁的完成OushuDB与Greenplum之间数据对接
- GP集群间对接
- 方案优点
- 方案缺点
- OushuDB架构
- 如何实现
- OushuDB与GP对接
最近有项目需要做偶数云原生数据库(后简称：OushuDB)与Greenplum(后简称：GP)之间数据对接。主要背景是客户使用GP已经有一定历史，很多生态都是按照GP的方式完成，OushuDB需要接入就要兼容原有的接口，这样不仅可以快速上线，还能最小化开发成本。其中有一个需求就是打通OushuDB与GP之间的数据通道，OushuDB的结果数据可以高效简便的导入GP，并且要实现原有的接口。
GP集群间对接
因为本人之前做GP运维多年，所以看到需求后发现GP原有方式，是之前某GP大神的作品，作用在GP集群间做高效复制数据，在某一范围内传播宽泛。我们先来看看这个流程以及他的优缺点。
可以看到GP是通过libpq的Copy接口完成数据对导，这个方案巧妙的利用了GP实例的特性，通过UDF（数据库自定义函数）完成分布式拷贝，当然集群间实例数的差异，只要有一个Mapping规则就行。
方案优点
1、 高效，通过分布式对接完成实例到实例的分布式操作，效率非常高效。
2、 数据不落地，完成了内存对拷。
3、 操作简单，用户通过编写好的UDF在数据库内执行函数就能完成操作(存储过程)。
方案缺点
当然也有缺点：
1、 很明显拷贝是先进入临时表后才导入正式表，这是因为通过这种方式对拷数据分布完全是拷贝时Mapping的分布规则，违背了表设计的分布策略，如果是Hash分布数据分布会混乱。这时候需要有一个临时中间表(随机策略)做一个中转，那么这个拷贝其实还不能算真正完成，后面还要进行一步导入。
2、 由于UDF为外部程序完成，这部分内存，数据库不可能全部监管，高并发时有可能与数据库有资源竞争
3、当然该方案的好处足以掩盖他的劣势，因为其他方式一样可能带来上述的问题并且可能更多。
OushuDB架构
好的，让我们来看看OushuDB的架构：
OushuDB的架构主要是通过虚拟Segment计算，这样给OushuDB带来了巨大的优势
OushuDB可以动态的在系统、表、Session级别指定一个SQL的虚拟Segment数，从而更加灵活合理的开启并行，与资源分配，这在并发情况下，有天生的架构优势。
但是，问题来了，这样OushuDB就很难与GP的Copy对接，因为OushuDB是动态虚拟Segment，没办法通过Copy取数。
如何实现
那么怎么才能完成与GP的对接呢？分析下
1、 OushuDB架构为计算与存储分离，存储有HDFS、MAGMA（自研）、S3等等，默认的OushuDB一定会有HDFS存储，如果能把HDFS文件作为第一个对象(一般OushuDB存储会有多个HDFS文件),一个文件作为一个单元(相当于一个GP实例目录)。
2、 文件确定了，那么是不是最好能使用虚拟Segment分布式操作这些文件，并且与GP的Segment对接呢。
OushuDB与GP对接
通过上面的分析，经过大量的实验，以及研发同事的指点，最终完成一个比较靠谱的方案，上图：
流程说明：
1、 OushuDB将想要的结果导入一张HDFS外表(虽然多了一步，但是由于每次导入或许会有条件，这样做比较安全，另外性能也不会有多少损失)。
2、 导入的HDFS外表会在HDFS上生成多个文件。
3、 OushuDB通过WEB EXTERNAL TABLE可以指定N个虚拟Segment，通过libhdfs3分布式操作HDFS文件。
4、 GP段保持不变，接收OushuDB的虚拟Segment的数据就行
5、 这样就会有HDFS文件与虚拟Segment与GP
Segment三个实体的Mapping，比GP多一个Mapping关系，也多了一步导入到HDFS外表的操作。
最后，通过改造完全可以与GP原有接口对接，并且保证高效简洁。当然实际可用，还需要测试与优化。
也希望通过这个案例，能够提供从一个角度了解OushuDB与GP架构的资料。
