如何分析数据虚拟化引擎openLooKeng
今天就跟大家聊聊有关如何分析数据虚拟化引擎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有进一步的了解吗？如果还想了解更多知识或者相关内容，请关注行业资讯频道，感谢大家的支持。
