数据虚拟化引擎 openLooKeng 介绍

Posted 2021-05-02 openLooKeng

21世纪是信息爆炸的世纪，随着 IT 技术的飞速发展，越来越多的应用源源不断的产生数以亿计的数据。

在过去的近一个世纪里，科学家与工程师发明了各种各样的数据管理系统来存储与管理各种各样的数据：关系型数据库、NoSQL 数据库、文档数据库、key-value 数据库、对象存储系统等等。

形态多样的数据管理系统为企业组织在管理数据上带来便利的同时，随之而来的是管理与充分利用这些数据系统存储的数据的难题。

大数据分析的现状及问题

无论是关系型数据库中的 PostgreSQL 或者 mysql，抑或是 Hadoop 体系下的 Hive 或者 HBase，这些目前业界通用的数据管理系统都有自成体系的一套 SQL 方言。

数据分析师想要分析某一种数据管理系统的数据，就得熟练掌握某一种 SQL 方言；为了对不同数据源进行联合查询，那么就得在应用程序逻辑中使用不同的客户端去连接不同的数据源，整个分析过程架构复杂、编程入口多、系统集成困难，这对于涉及海量数据的数据分析师而言这样的分析过程十分痛苦。

为了解决多数据源形成的数据孤岛的联合查询问题，业界正在广泛使用数据仓库这一解决方案。

数据仓库在过去的数年里快速发展，它通过抽取（Extract）、转换（Transform）、加载（Load）各种各样数据源中的数据，经过 ETL 这一整套流程，将加工后的数据集中保存在专题数据仓库中，供数据分析师或用户使用。

但随着数据规模的进一步增长，业界已经逐渐认识到将数据搬运到数据仓库的过程是昂贵的，除了数据仓库的硬件或软件的成本，维护与更新整个 ETL 逻辑系统的人力成本也逐渐成为数据仓库的重要开销之一。

数据仓库 ETL 流程同时也是笨重且耗时的，为了获取到想要的数据，数据分析师或用户不得不妥协于数据仓库 T+1 的数据分析模式，想要快速进行业务分析探索对于数据分析师来说一直是一个待解的难题。

人们为了解决各种各样的数据管理系统的数据孤岛问题，针对不同的业务应用又发明了专题数据仓库，但随着业务应用的增多，日益增多的专题数据仓库又变成了数据孤岛。

所以英勇的“屠龙勇士”随着时间的流逝都不可避免的会变成“恶龙”吗？是否有一种系统架构简洁、编程入口统一、系统集成度好的解决方案呢？也许今天，我们是时候回到最初的起点，来从头看看大数据数据分析的另一种范式了。

数据虚拟化引擎 openLooKeng：我们不搬运数据，我们是数据的”连接器“

所以当我们回头来看数据仓库碰到的各种各样的问题的时候，您很容易发现，数据仓库这个”屠龙勇士“之所以逐渐变成“恶龙”，是因为它在不停的搬运数据。搬运数据正是导致数据仓库的建立与分析过程繁重、费时、昂贵的“元凶”。

既然搬运数据导致了这些问题，那么让我们回到大数据分析的出发点，考虑下“林中的另一条路”，而这条路正是 openLooKeng 正在走的变数据搬运为数据连接的路。

简明扼要的讲，openLooKeng 数据虚拟化引擎分析数据的方式是通过各种各样的数据源 Connector 连接到各个数据源系统，用户在发起查询时，通过各个 Connector 实时的去获取数据并进行高性能的计算，从而在秒级或分钟级内得到分析结果。这与以往的数据仓库通过 T+1 的 ETL 数据搬运过程处理好数据再给用户使用的方式有很大差异。

与以往数据分析师需要学习各种各样的 SQL 方言不同的是，现在数据分析师只需要熟练掌握ANSI SQL2003 语法。而各种各样的数据管理系统在 SQL 标准上的差异则由 openLooKeng 作为中间层进行了屏蔽，用户不用再学习各种SQL方言，这些繁杂的 SQL 方言转换的工作都将由 openLooKeng 来完成。

通过将用户从各种各样的 SQL 方言中“解放”出来，用户可以专注于构建高价值的业务应用查询分析逻辑，这些分析逻辑形成的无形资产往往才是企业商业智能的核心，openLooKeng 正是出于帮助用户快速构建高价值的业务分析逻辑这一目的来构建自己的整个技术架构的。

由于无需搬运数据，用户的分析查询灵感可以快速的使用 openLooKeng 进行验证，从而达到比以往 T+1 的数据仓库分析处理过程更快的分析效果。

让我们站得更高一点来看，既然 openLooKeng 可以通过 Connector 连接到关系型数据库、NoSQL 数据库等数据管理系统，那么可不可以将 openLooKeng 自身也作为一个 Connector 呢？

答案是肯定的。

当我们将 openLooKeng 自身也作为一个数据源提供给另一个 openLooKeng 集群时，可以得到这样的好处：之前由于跨地域或者跨 DC 的网络带宽或者时延限制，导致的多个数据中心之间的数据要实现实时联邦查询基本上是不可用的，而现在 openLooKeng 集群1将本地数据进行计算后将结果再传递给 openLooKeng 集群2进行进一步分析，避免了大量原始数据的传输，从而规避了跨域跨 DC 查询的网络问题。

openLooKeng 的统一 SQL 入口，丰富的南向数据源生态，一定程度上解决了以往跨源查询架构复杂、编程入口太多、系统集成度差的问题，实现了数据从“搬运”到“连接”的模式转换，方便了用户快速实现海量数据的价值变现。

openLooKeng 的关键特性

也许在看了上面的介绍之后，您已经迫不及待的想知道 openLooKeng 能在哪些场景下使用了，从而来解决目前业务应用的痛点问题。但在继续介绍 openLooKeng 适用的业务场景之前，让我们先来看看 openLooKeng 的一些关键特性，以便于您更深入的理解 openLooKeng 为什么适合这些业务场景，甚至您也可以基于 openLooKeng的这些能力进一步探索更多的业务场景。

专为海量数据设计的内存计算框架：openLooKeng 从一诞生便是针对 TB 甚至 PB 级海量数据的查询分析任务而设计的，其对于 Hadoop 文件系统具有天然的亲和性，其 SQL on Hadoop 的分布式处理架构，采用了存储与计算分离的设计理念，可方便的实现计算或存储节点的水平扩展。

同时 openLooKeng 内核采用基于内存的计算框架，所有数据的处理都在内存中以并行的流水线式作业完成，可提供秒级到分钟级的查询时延响应。

ANSI SQL2003 语法的支持：openLooKeng 支持 ANSI SQL2003 语法，用户使用 openLooKeng 语法进行查询时，无论底层数据源是 RDBMS 还是 NoSQL 或者其他数据管理系统，借助 openLooKeng 的 Connector 框架，数据可以依然存放在原始的数据源中，从而实现数据“0搬迁”的查询。

通过 openLooKeng 的统一 SQL 入口，可实现对底层各种数据源 SQL 方言的屏蔽，用户无需再关心底层数据源的SQL方言便可获取到该数据源的数据，方便了用户消费数据。

多种多样的数据源 Connector：正如数据管理系统的多种多样一样，openLooKeng 针对这些数据管理系统开发了多种多样的数据源Connector，包括RDBMS（Oracle Connector、HANA Connector等），NoSQL（Hive Connector、HBase Connector 等），全文检索数据库（ElasticSearch Connector 等）。

openLooKeng 可以通过这些多样的Connector 方便的获取到数据源数据，从而进一步进行基于内存的高性能联合计算。

跨域跨 DC 的 DataCenter Connector：openLooKeng 不仅提供跨多种数据源联合查询的能力，还将跨源查询的能力进一步延伸，开发了跨域跨 DC 查询的 DataCenter Connector。通过这个新 Connector 可以连接到远端另外的 openLooKeng 集群，从而提供在不同数据中心间协同计算的能力。其中的关键技术如下：

并行数据访问：worker 可以并发访问数据源以提高访问效率， 客户端也可以并发从服务端获取数据以加快数据获取速度。

数据压缩：在数据传输期间进行序列化之前，先使用 GZIP 压缩算法对数据进行压缩，以减少通过网络传输的数据量。

跨 DC 动态过滤：过滤数据以减少从远端提取的数据量，从而确保网络稳定性并提高查询效率。

高性能的查询优化技术：openLooKeng 在内存计算框架的基础上，还利用许多查询优化技术来满足高性能的交互式查询的需要。

• 索引： openLooKeng 提供基于 Bitmap Index、Bloom Filter 以及 Min-max Index 等索引。 通过在现有数据上创建索引，并且把索引结果存储在数据源外部，在查询计划编排时便利用索引信息过滤掉不匹配的文件，减少需要读取的数据规模，从而加速查询过程。
• Cache：openLooKeng 提供丰富多样的 cache，包括元数据 cache、执行计划 cache、ORC 行数据 cache 等。通过这些多样的 cache，可加速用户多次对同一 SQL 或者同一类型 SQL 的查询时延响应。
• 动态过滤：所谓的动态过滤是指是在运行时（run time）将 join 一侧表的过滤信息的结果应用到另一侧表的过滤器的优化方法，openLooKeng 不仅提供了多种数据源的动态过滤优化特性，还将这一优化特性应用到了 DataCenter Connector，从而加速不同场景关联查询的性能。

• 算子下推：openLooKeng 通过 Connector 框架连接到 RDBMS 等数据源时，由于 RDBMS 具有较强的计算能力，一般情况下将算子下推到数据源进行计算可以获取到更好的性能。openLooKeng 目前支持多种数据源的算子下推，包括 Oracle、HANA 等，特别地，针对 DC Connector 也实现了算子下推，从而实现了更快的查询时延响应。

高可用特性

HA AA 双活：openLooKeng 引入了高可用的 AA 特性，支持 coordinator AA 双活机制，能够保持多个 coordinator 之间的负载均衡，同时也保证了 openLooKeng 在高并发下的可用性。

Auto-scaling：openLooKeng 的弹性伸缩特性支持将正在执行任务的服务节点平稳退服，同时也能将处于不活跃状态的节点拉起并接受新的任务。openLooKeng 通过提供“已隔离”与“隔离中”等状态接口供外部资源管理者（如 Yarn、Kubernetes 等）调用，从而实现对 coordinator 和 worker 节点的弹性扩缩容。

openLooKeng 的常见应用场景

通过上述对 openLooKeng 关键特性的介绍，想必您的脑海中已经浮现出了不少 openLooKeng 的应用场景，下面让我们一起来看看它在现实业务的应用场景吧。

高性能的交互式查询场景：openLooKeng 基于内存的计算框架，充分利用内存并行处理、索引、Cache、分布式的流水线作业等技术手段来快速的进行查询分析，可以处理 TB 甚至 PB 级的海量数据。以往使用 Hive、Spark 甚至 Impala 来构建查询任务的交互式分析应用系统都可以使用 openLooKeng 查询引擎来进行换代升级，从而获取更快的查询性能。

跨源异构的查询场景：正如前文所述，RDBMS、NoSQL 等数据管理系统在客户的各种应用系统中广泛使用；为了处理这些数据而建立起来的 Hive 或者 MPPDB 等专题数据仓库也越来越多。而这些数据库或者数据仓库往往彼此孤立形成独立的数据孤岛，数据分析师常常苦于：

查询各种数据源需要使用不同的连接方式或者客户端，以及运行不同的 SQL 方言，这些不同导致额外的学习成本以及复杂的应用开发逻辑。

如果不将各种数据源的数据再次汇聚到一起，则无法对不同系统的数据进行联邦查询。

使用 openLooKeng 可实现 RDBMS、NoSQL 等数据库以及 Hive 或 MPPDB 等数据仓库的联合查询，借助 openLooKeng 的跨源异构查询能力，数据分析师可实现海量数据的分钟级甚至秒级查询分析。

跨域跨 DC 的查询场景：对于省-市、总部-分部这样两级或者多级数据中心的场景，用户常常需要从省级（总部）数据中心查询市级（分部）数据中心的数据，这种跨域查询的主要瓶颈在于多个数据中心之间的网络问题（带宽不足、时延大、丢包等），从而导致查询时延长、性能不稳定等。

openLooKeng 专为这种跨域查询设计了跨域跨 DC 的解决方案 DataCenter Connector，通过 openLooKeng 集群之间传输计算结果的方式，避免了大量原始数据的网络传输，规避了带宽不足、丢包等带来的网络问题，一定程度上解决了跨域跨 DC 查询的难题，在跨域跨 DC 的查询场景有较高的实用价值。

计算存储分离的场景：openLooKeng 自身是不带存储引擎的，其数据源主要来自各种异构的数据管理系统，因而是一个典型的存储计算分离的系统，可以方便的进行计算、存储资源的独立水平扩展。

openLooKeng 存储计算分离的技术架构可实现集群节点的动态扩展，实现不断业务的资源弹性伸缩，适合于需要计算存储分离的业务场景。

快速进行数据探索的场景：如前文所述，客户为了查询多种数据源中的数据，通常的做法是通过 ETL 过程建立专门的数据仓库，但这样带来昂贵的人力成本、ETL 时间成本等问题。

对于需要快速进行数据探索而不想构建专门的数据仓库的客户，将数据复制并加载到数据仓库的做法显得既费时又费力，而且还可能得不到用户想要的分析结果。

openLooKeng 可通过标准语法定义出一个虚拟的数据集市，结合跨源异构的查询能力连接到各个数据源，从而在这个虚拟的数据集市语义层定义出用户需要探索的各种分析任务。

使用 openLooKeng 的这种数据虚拟化能力，客户可快速的建立起基于各种数据源的探索分析服务，而无需构建复杂的、专门的数据仓库，从而节约人力与时间成本，对于想快速进行数据探索从而开发新业务的场景使用 openLooKeng 是最佳的选择之一。

展望未来

数据虚拟化引擎 openLooKeng 在探索跨域跨DC的交互式查询场景上有了一定的进展。展望未来，还有不少问题需要我们去验证和解决，比如除了交互式分析场景，如何解决 openLooKeng 在流处理和批处理上的问题？用户还需要什么样的数据源 Connector？衷心期待广大用户和开发者加入到 openLooKeng 开源社区中来，携手开发 openLooKeng 项目，解决更多的用户问题，让大数据更简单。