openLooKeng，一款面向海量、跨 DC 的大数据分析利器

本文介绍的内容包括四部分，然后第一部分是 openLooKeng 是什么，然后第二部分是 openLooKeng 的典型应用场景。第三部分是 openLooKeng 的架构解析和关键特性。

1. openLooKeng 是什么

1.1 openLooKeng 打破数据和应用壁垒，快速实现数据价值

首先我们在介绍 openLooKeng 之前，我们大致的介绍一下当前大数据面临的一些困难。然后主要是困难就是包括左边的三个方面。第一个就是我们看到的我现在一个很典型的场景，就是很典型的问题，就带大数据的。在大数据中心里面，我们都会有很多的引擎，比如说有 OLTP 的、 OLAP 的，同时有 hadoop 还有 noSQl 的，然后不同的引擎又有不同的语法。然后通常我们还要面临的是跨地域的一个访问。所以说总结起来就有三个部分的困难。一个就是用数难，对于我们面临的开发的组件越多，老开发语言越多，这样的话导致的开发成本越高。但是说我们要从不同的数据语言中，如果进行关联分析的话，我们需要掌握的语言会很多。

第二个问题就是找树难，找树难一个典型特性是数据比较分散，然后管理复杂，流动性差，查询效率也低。第三部分就是数据的取数难，跨源分析通常需要数据的半天效率不高。通常我们在进行分析的时候要从一个数据源导到另一个数据源，这样的话导致数据存在多份拷贝，然后数据迁移的效率有部分也很低。而 openLooKeng 的出现就是为了打破数据壁垒，然后快速实现数据的价值。openLooKeng 有三个比较典型的特征，就是用数极简，找数极速取数高效。在下面的 App 中灰着重的讲述这几份方面。然后用数极简的话，第一个方面就说的是在 openLooKeng 我们提供一个统一的简化的接口，就是 SQL 语言，然后找数取数的话就是我们会在 openLooKeng 里面利用了很多的增强特性来提高数据的查询速度。然后取数高效，就是我数据在分析的时候不需要搬迁，我们可以实现一个跨源跨域以及跨数据中心的一个联合的查询，从而实现快速的查找数据。

1.2 openLooKeng 统一高效的数据虚拟化引擎，让大数据变简单

openLooKeng 用一句话来说就是 openLooKeng 是一个跨域的高效的虚拟化查询引擎。它主要是分为三个部分，第一部分就是统一接口层，向外接口的话，我们向上层次提供 2003 兼容的 SQL 语法。然后中间一层是内核引擎层在内核引擎层我们做了很多的优化，比如说启发式索引动态过滤算子下推以及包括一些企业级特性 AA 的高可用以及权限的控制。

第三部分就是数据源层，openLooKeng 提供了一个抽象的数据源框架 data connect framework ，这样的话针对的不同的数据源，我们只要复写它提供的一些接口，就可以简单高效的把数据源接入到 openLooKeng 引擎里面来。当前 openLooKeng 支持的数据源应该有二十种，然后重新开发一种数据源也是非常简单的。同时我们也实现了一个跨 DC 的 connect 也就是说我们通过 openLooKeng 的 DC connect 可以去访问另一个 openLooKeng 集群，这样的话我们形成一个跨域的级联的分析。总体整体来说就是说 openLooKeng 有四个特点。第一个就是同一路口化环为点，单一引擎支持多场景。然后第二部分就是内核增强，高性能查询。第三部分就是跨源关联分析，数据消费零搬迁。

然后第四部分就是我们提供了一个的 DC connect 实现跨域的协同分析、广域网的部署、局域网的体验。我们在 DC connect 里面实现了多重的优化，包括数据压缩、断点续传以及算子下推，从而实现在 DC connect 性能跨域访问性能的增强。

2.3 openLooKeng:统一高效的数据虚拟化引擎

我们接下来看一下就是 openLooKeng 在大数据一个整体的解决方案中的一个位置。我们可以看到就是 openLooKeng 属于一个在引擎层的位置，它属于数据查询的一个组件。但是相比于 Spark Hive 参数来看的话，它处于一个更高的层次，因为它下层可以接的数据源就包括了 MySQL hive， hbase 等。而底层的硬件设备是可以支持 Kunpeng 和 X86 都是可以的。然后上层 openLooKeng 的上层就是 ISV 的大数据解决方案，这个大数据解决方案可以是数据中台等的解决方案。再上层就是我们的数据使能层。数据使能层就包括数据开发的工具、调度工具，然后再上层就是我们的应用。比如说我们典型的五大应用，政府、金融、安频、互联网、电力加三大运营商。

2. openLooKeng 的典型应用场景

2.1 openLooKeng 面对行业应用四大场景持续发力

openLooKeng 面临的四大场景，也就是 openLooKeng 跟主要发力的四大场景。第一个就是单引擎覆盖交互式的场景。然后现在一个比较典型特征就是比如说我要进行一个数据分析的话，首先数据是导到 Hive 里面，然后经过 ETL 的过程导到一个专题数据库里面，这样的话就有两个烟串，两份数据管理复杂查询数据搬迁的效率也差。

那这是第一个场景，通过 openLooKeng 的话，我们可以使用它的域跨源能力实现数据关联分析。第二个就是大数据实时数据实时分析场景，这个主要是通过 openLooKeng 的 Kafka connector 这种数据兼容能力，可以实现数据实时的录入，然后实时的对数据进行分析。第三个的就是引擎接口，就是实现一个跨域跨源的数据分析，比如说我的底程有 Hive 和 mpb 数据源，由于这两种数据源它的本身的接口是不一样的，Hive 使用的是 Hsql ，然后 MPPDB 所是使用的是标准的 SQL ，他们在分析的时候由于他们俩的接口不一样，然后需要写不同的语言对他的数据进行一个读取，然后在上层的平台进行一个关联分析，然后下面的几个应用场景也是在实在实际中用到的一个场景。第一个就是 OPPO 跟的用 OPPO 跟去替换 Hive 或者 Spark 目标的场景是这样子的，交互场景目的是为了分析人员提供或是为数据分析人员提供更方便快捷的机器查询能力，性能的要求是很高的，通常是秒级查询。这个是在我司应用的一个场景，他开当前的话之前他们用的是 Hive 然后中间的有一个比较明显特征是中间结果落盘次数比较多，然后调度效率低。而通过使用 open 螺根然后同时以使用了 open 螺根的启发式索引、执行计划、cache 等一些技术。然后还有一个比较典型的特征是 OPPO 跟本来是基于一个内存的全 pipeline 的一个数执行模式，这样的时候数据是没有落盘的，最终效率是提高了两至十倍。这是一个在我市应用的一个场景。然后第二个就是融合分析的场景，就统一 SQL 跨源融合分析。我们看就是下沉有三个数据源，一个是 Hive 一个是 hbase 一个是 ES 这样话通过以前的话就你可要通过不同通过他们各自的 connect client 把它的数据拉取上来，然后通过一块源的综合分析程序来实现一个关联分析。那么的话这个一个就是你的开发成本很高，然后你的效率也很低。就很完美的解决这个问题。

然后第四个场景就是一个跨域的协同分析的场景。现在的跨如果需要两个 DC 之间需要做一个关联分析，首先比如说我 DC 1 要访问 DC 2 的数据到 dcr，需要把数据放到前置机上，然后通过共享交互平台的方式把数据传送给 DC 1，这样的话肯定是不能做到一个 T+0 准确的分析。通常的话是一个 T+ 1 的分析模式。那通过 openLooKeng 的跨域的 disconnector 就可以实现一个跨域的实时分析。+

2.2 即席服务提供秒级查询能力

下面的几个应用场景也是在实际中用到的场景。第一个就是用 openLooKeng 去替换 Hive 或者 Spark 目标的场景，交互场景目的是为了分析人员提供或是为数据分析人员提供更方便快捷的机器查询能力，性能的要求是很高的，通常是秒级查询。这个是在我司应用的一个场景，当前的话之前用的是 Hive 然后中间的有一个比较明显特征是中间结果次数比较多，然后调度效率低。而通过使用 openLooKeng 启发式索引、执行计划、cache 等一些技术。然后还有一个比较典型的特征是 openLooKeng 本来是基于一个内存的全 pipeline 的一个执行模式，这样数据是没有落盘的，最终效率是提高了两至十倍。这是一个在我司应用的一个场景。然后第二个就是融合分析的场景，就统一 SQL 跨源融合分析。我们看就是下面有三个数据源，一个是 Hive ，一个是 hbase ，一个是 ES 这样话通过以前的话就你可要通过不同通过他们各自的 connect client 把它的数据拉取上来，然后通过一跨源的综合分析程序来实现一个关联分析。那么的话这个一个就是你的开发成本很高，然后你的效率也很低。

然后通过 openLooKeng 的跨源分析能力，我们可以通过增加新的 connector 把数据源数据接入到 openLooKeng 引擎里面来。然后通常的话开发一个 connector 只需要一人/月的成本。如果说你很熟悉的话，通常两个礼拜就好了。

然后通过这种模式，同时 openLooKeng 又是一个标准的 mppDB 架构的一个分析引擎，通过它的统一的北向接口，南向的抽象 connect 的访问模式，就可以把数据实现一个跨源的融合分析场景。一个很典型特征就是它可通过一个统一的 SQL 2003 的接口，屏蔽了异构数据源访问差异，简化应用程序开发提高点，极大的提升了开发效率。然后就是一个高性能提供百毫秒级的一个分析能力。

2.3 融合分析:跨 DC 联合查询,更强的数据分析能力

第三个场景就是跨 DC 的融合关联分析。之前的话都是一个手动处理的一个模式，然后它是 T +1 的一个数据分析能力。然后通过 openLooKeng 的 DC connect 我们可以实现的一个 T +0 的实时的共享分析能力。那比如说他当前的新的一个业务痛点就是数据量膨胀，导致数据分级分散，存储各省二十一个地市 3000 多的数据源，每天接入的数据总量大于 200 TB ，分析目标人群，分析业务跨域分析效率低。

通常的话我们是需要把数据手动的导入到需要访问它的一个 DC 里面去通 openLooKeng 的 DC connect ，无需人工的去搬运数据，然后同时通过 openLooKeng DC connect 提供的比如说算子下断点续传以及数据压缩并行传输等特点来提升跨域的一个访问能力，把之前的从天级别的分析速度提高到分钟级的一个分析能力。

2.4 融合分析:一份数据，节约存储成本

以前有一个典型的流程就是生产数据经，首先是流到 Hive 或者是流到其他系统，然后再流到一个专题的数据库里面。比如说 Oracle 、mppdb 这种的话，一个典型的特征就是 ETL 流程长，数据重复搬迁，一致性差。同时有个很大的业务痛点就是提拉高了建设成本。

然后通过 openLooKeng 引擎我们也看到就是数据只需要录到一个数据源中，然后通过 openLooKeng 的跨源跨域的分析能力，这样的话数据在数据源中只会存在一部分，也存在一份数据，减少了 ETL 过程和不必要的数据的搬迁。

3. openLooKeng 架构解析和关键特性

下面一张图就是显示了 openLooKeng 的一个典型的架构。首先 openLooKeng 是一个典型的 mppdb 的结构。你它是由 coordinator 和 worker 组成的， coordinator 是负责接收应用层来的 SQL 然后经过他的执行优化再通过他的调度把任务调度到 worker 上去执行。同时每个 worker 是负责整个 SQL 的一部分的数据。然后底层的数据源通过 data connect framework 的方式接入到数据源里面来。然后 data connect framework 提供了两个很重要的接口。一个就是分片的机制就是你要告诉 connector 数据语是怎么分片的，从而实现了一个就是分布式并行处理的一个能力。第二个就是告诉我数据是怎么读取的。其实 connector 就是要告诉引擎就数据是怎么分片的。

第二个就是数据是怎么从你的数据源里面读取的。比如说我拿一个很简单的例子，拿 Hive 举例的话，就是它首先会告它的 support manager 就是我们的分片的管理的一个模块，它会告诉 openLooKeng 引擎我的数据按照 DFS block 的大小来调度它。通常一个 block 可能会比较大，可能会按照四分之一个 block 也就是 32 道或者是 60 道的单位来进行一个调度。引擎告诉 worker 在执行的时候怎么去获取这个数据。然后针对于 Hive 数据源的话，它其实就是通过访问文件的方式。首先它会从 HMS 去获取它的元数据，获取它元数据之后就知道它存储在 Hive 哪个地方。这样的话 worker 在执行的时候就会去用 three reader 去解析这个 strip ，然后 strip 就解析里面的 strap，这样的话就是可以对数据进行一个分析。图中另外还显示了一个就是跨 DC 的能力。

DC connector 走的是 JDBC 的方案，openLooKeng 是一个典型的 MPP 架构，高可用无，单点无单点故障。因为之前 codinator 是单节点的，现在我们已经实现了 codinator 一个双活的特性。然后 openLooKeng 是一个向量化的存储引擎，是基于内存的流水线处理。相比于 Spark 的话，它是一个基于内存的完全的 pipeline 的一个处理引擎，这也是 openLooKeng 相比于 Spark 性能有提升的一个重要的原因。

3.1 openLooKeng 关键技术概览

openLooKeng 重要特征，一个就是索引。索引的会创建一个外置索引，我们提供了 create index 等命令，让用户去根据需要去创建比如说 mini max brow failed bitmap 以及 B +树这种索引。然后在数据读取的时候，我们会去用这用索引去过滤分片，同时也可以用这种索引去获取。

另外一个是动态过滤。在左右表作用的时候，通过把右表的列建立一个 felt 去过滤左表的数据，这种效果其实特别的明显。

3.2 高性能:对标 PrestoSql*，源自开源，领先开源

openLooKeng 引擎相对与其他引擎的一个性能的优势，对标的是 PrestoSql，源自开源，领先开源。我们当前是用的是十一个节点，每个节点是有 238 G 的内存，CPU 的特征列在上面，大家可以仔细看一下，然后测试的数据集是 10 TB 的。我们首先我们可以看一下整体的耗时。 openLooKeng 是用了大概 11,000 多。然后是然后 PrestoSq 347 是用了将近 24,00。也就说 openLooKeng 1.2 相对于 PrestoSql 347 提高了 52%，其中有 76% 的 SQL 用时使用率是低于 PrestoSql 347 的。可以看到一些典型的，就有有一些 SQL 是体现的很明显的。

3.3 高性能:对标 impala*，性能领先

第二个就是对标 impala，可以看到它整个的环境还是和之前一样。是十一个节点，内存稍微小一点，数据量是 2 TB。首先看一下它的整个的延时 openLooKeng 大概在 1400 秒，然后 impala 是在 2100 多秒。openLooKeng 是对 tpc-ds 是 100% 的支持的，impala 它仅仅是支持了 78%，它有一些算子是不支持的。

3.4 高性能:对标 spark 2.3.2

再看一下对标 Spark2.3.2，是同一个数据集群，然后测试数据集是 1 TB。openLooKeng 的用时大概是 1600 秒，然后 Spark 用时大概是在 4700s。其实相对于 Spark 的话 openLooKeng 相当于有两倍的性能提升，其实这个性能提升还是很好理解的，因为本身 Spark 它是一个基于 stage ，然后每个 stage 要等待上一个 stage 所有的 task 执行完。

3.5 OmniRuntime: the Foundation for High-Performance Data Analytics

openLooKeng 当前正在做的一些优化，runtime 就是现在针对于所有引擎就是做一个 CA comment big data ，简单来说就是一个 native 的 code 键的一个执行环境，用于减少 CPU 指令。

看到整体的之前的话，相对于之前的话我们有优势的话就是之前 PrestoSql spark Hive 它都自己在做这种 local optimization ，然后我们的目标是实现一个统一的，就是可以供所有人应用的一个 big data 的 runtime 。

3.6 OmniRuntime:Analytics Operator Ecosystem

OmniRruntime 主要也就是包含有四个部分，然后一个就是 Omni flex ，第二个部分就是 Omni operator ，第三个部分就是 Omnicache ，然后第四部分是 Omni change，在这里主要是介绍一下 Omni vector 还有 Omni operator ，Omni vector 就是在内存中的一个数据存储格式，就是数据在内存中是怎么表示的。Omni operator 就是我们用 C++重新写了一个算子。

Omni cache 现在还正在设计，omni change 是一个兼容 RDMA 和 TCP 的一个传输传输方式。

3.7 OmniRuntime: Performance Evaluation

首先是从 operator 级别，然后是端到端的一个性能提升，可以看得出来就是在算子级别，OmniRuntime:提升的还是特别的明显的。举个例子，就是 filter hash X 其他都是有数倍的提升，最大的提升可能有 10 倍，但是单个算子在整个的 SQL 中的占比会比较少。比如说整个 SQL 中 hash 贡献只占了 20%，那最多也就是提升 20% 。我们可以看一下单个就是针对于端到端的一个性能提升， tbch 的 Q1，可以看在一并发和四并发以及十发的时候，它大概都有 30% 左右的一个提升。

3.8 大数据 OmniData 算子下推

下面介绍是 OmniData 数据计算，就是比如说我们现在要做一个数据分析，通常我要去分析一个表，然后通常我们会带那种过滤条件，然后我从下拿 8 亿行的数据，然后通过 OmniData 推到数据存储端去计算。、原理就是一个 NTP 的数据计算的一个原理，就把数据的把算子把能够推的算子推到进数据端去执行。然后我们可以看到它最终上来的数据只有 78.7 万行，然后执行时间从之前的 3800 多秒下降到了 2084 秒，这个是在我司的一个真实的案例。