共计 1375 个字符，预计需要花费 4 分钟才能阅读完成。
当初有各种各样的数据管理系统来存储与治理数据：关系型数据库、NoSQL 数据库，文档数据库、Key-value 数据库，对象存储系统等等。状态多样的数据管理系统为企业组织在治理数据上带来便当的同时，随之而来的是治理与充分利用这些数据系统存储的数据的难题。
数据分析师想要剖析某一种数据管理系统的数据，为了对不同数据源进行联结查问，那么就得在利用程序逻辑中应用不同的客户端去连贯不同的数据源， 整个剖析过程架构简单，编程入口多，系统集成艰难 ，这对于波及海量数据的数据分析师而言这样的剖析过程非常苦楚。
明天 Gitee 举荐的这款开源我的项目就是针对解决这个问题而生，它就是数据虚拟化引擎 openLooKeng。
项目名称： openLooKeng
我的项目作者： openLooKeng
开源许可协定： Apache-2.0
我的项目地址：https://gitee.com/openlookeng/hetu-core
我的项目简介
openLooKeng 是一种 ” 开箱即用 ” 的引擎，反对在任何地点（包含天文上的近程数据源）对任何数据进行原位剖析。它通过 SQL 2003 接口提供了所有数据的全局视图。openLooKeng 具备高可用性、主动伸缩、内置缓存和索引反对，为企业工作负载提供了所需的可靠性。
openLooKeng 用于反对数据摸索、即席查问和批处理，具备 100+ 毫秒至分钟级的近实时时延，而无需挪动数据。openLooKeng 还反对层次化部署，使天文上近程的 openLooKeng 集群可能参加雷同的查问。利用其跨区域查问打算优化能力，波及近程数据的查问能够达到靠近“本地”的性能。
利用场景
- 高性能的交互式查问场景
- 跨源异构的查问场景
- 跨域跨 DC 的查问场景
- 计算存储拆散的场景
- 疾速进行数据摸索的场景
我的项目个性
- 专为海量数据设计的内存计算框架
openLooKeng 具备 SQL on Hadoop 的分布式解决架构，采纳了存储与计算拆散的设计理念，可不便的实现计算或存储节点的程度扩大。
- ANSI SQL2003 语法的反对
用户应用 openLooKeng 语法进行查问时，无论底层数据源是 RDBMS 还是 NoSQL 或者其余数据管理系统，借助 openLooKeng 的 Connector 框架，数据能够仍然寄存在原始的数据源中，从而实现数据“0 搬迁”的查问。
- 多种多样的数据源 Connector
openLooKeng 针对这些数据管理系统开发了多种多样的数据源 Connector，包含 RDBMS，NoSQL，全文检索数据库。openLooKeng 能够通过这些多样的 Connector 不便的获取到数据源数据，从而进一步进行基于内存的高性能联结计算。
- 跨域跨 DC 的 DataCenter Connector
通过这个新 Connector 能够连贯到远端另外的 openLooKeng 集群，从而提供在不同数据中心间协同计算的能力。
- 高性能的查问优化技术
openLooKeng 在内存计算框架的根底上，还利用动静过滤、算子下推等多种查问优化技术来满足高性能的交互式查问的须要。
参加共建
openLooKeng 目前也在期待宽广对大数据感兴趣的开发者们一起退出到 openLooKeng 开源社区中，如果你想要看看它的代码长什么样，那么就点击前面的链接去我的项目主页看看吧：https://gitee.com/openlookeng/hetu-core
