共计 5965 个字符，预计需要花费 15 分钟才能阅读完成。
大数据分析的现状及问题
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 我的项目，解决更多的用户问题，让大数据更简略。
• • •
openLooKeng 是一款开源的高性能数据虚拟化引擎，提供对立 SQL 接口，具备跨数据源 / 数据中心剖析能力，为大数据用户提供极简的数据分析体验。欢送退出 openLooKeng 社区，一起做点有意思的事儿，让大数据更简略！
openLooKeng 开源社区官方网站: openlookeng.io/zh-cn/
openLooKeng 代码仓地址: gitee.com/openlookeng
