前言

当公司发展到了一定的规模之后,一般都会有多个数据中心,或者多个机房,在大数据场景下就会涉及到数据会存放在不同的数据中心HDFS上,有时又需要使用多个数据中心的数据一起计算某些业务逻辑,我们可以称之为东数西算,说简单点就是跨机房读取数据。但是跨机房读取数据就会涉及到需要消耗大量昂贵的带宽资源,同时容易影响查询的性能,为此openlookeng 基于移动数据不如移动计算的理念,可以把计算逻辑发送到远端机房集群,让计算更靠近数据,预先在远端机房计算一部分逻辑,再传输少量的数据到本地机房集群进行后续计算,通过 openlookeng(presto / trino) 的connector plugin机制设计了一个可以跨域查询的datacenter connector,同时对于用户侧来说,只要写自己的业务SQL,不需要关心底层数据的分布。下面让我们一起来看一下openlookeng是如何实现datacenter connector的:

架构设计

贴一张官方的图,大体思想就是把远端集群当作一个connector来使用,执行具体的查询操作。

mysql 冷热数据 实现方案 冷热数据识别原理_openlookeng

实现原理

在讲实现原理之前我们可以通过下面这张图来回顾一下openlookeng大体的架构和执行流程

mysql 冷热数据 实现方案 冷热数据识别原理_trino_02

datacenter connector同样是通过Plugin接口进行注册的connector,而connector内部的执行流程和已有connector的实现思路也差不多,都是获取Page数据进行计算,不同的是获取Page的方式是DC client发送一条由openlookeng生成的SQL到另外一个集群获取Page数据。

mysql 冷热数据 实现方案 冷热数据识别原理_mysql 冷热数据 实现方案_03

Page获取的方式大概是下面这样的,其实和用户自己使用presto client提交SQL获取数据的流程是类似的。

mysql 冷热数据 实现方案 冷热数据识别原理_trino_04

Page的生成是这样的,Remote 的Coordinator接收到SQL之后会提交执行,同时由PageProducer生产Page放到Queue里面,PageConsumer会负责异步返回Page数据,采用的是生产者消费者模式,中间使用的是一个固定大小的Queue。

mysql 冷热数据 实现方案 冷热数据识别原理_openlookeng_05

总结

datacenter connector相对于原来直接跨机房读取数据的好处是可以将计算下推到另一个数据中心所在的集群,从而实现本数据中心读取数据和计算数据,然后将已经下推计算后的数据跨IDC传输到原来的集群,这样做就减少了跨IDC的网络数据传输。实现思路就是上面讲的这样,但是具体实现细节方面包括如何自动兼容dc connector的四段式语法和实现有关语法,如何注册dc 有关的catalog,如何生成需要发送到remote集群的SQL,如何进行下推操作将计算尽可能的下推到remote集群,以及其他的类似execution plan cache,metadata cache,如何提高网络数据传输效率等等很多,后续可以再逐一和大家一起学习一下代码细节。

参考

https://openlookeng.io/docs/docs/connector/datacenter.html https://github.com/openlookeng/hetu-core