继上篇OpenLookeng简介，大家对它有了基本了解。这篇文章重点介绍一下OpenLookeng的一些关键特性，便于深入了解它为什么适合这些业务场景。
- Connector框架
openLooKeng 支持 ANSI SQL2003 语法，用户使用 openLooKeng 语法进行查询时，无论底层数据源是 RDBMS 还是 NoSQL 或者其他数据管理系统，借助 openLooKeng 的 Connector 框架，数据可以依然存放在原始的数据源中，从而实现数据“0搬迁”的查询。
- 多种多样的数据源接入Connector：正如数据管理系统的多种多样一样，openLooKeng 针对这些数据管理系统开发了多种多样的数据源Connector，包括RDBMS（Oracle Connector、HANA Connector等），NoSQL（Hive Connector、HBase Connector 等），全文检索数据库（ElasticSearch Connector 等）
- 支持跨DC的Connector：openLooKeng 不仅提供跨多种数据源联合查询的能力，还将跨源查询的能力进一步延伸，开发了跨域跨 DC 查询的 DataCenter Connector。通过这个新 Connector 可以连接到远端另外的 openLooKeng 集群，从而提供在不同数据中心间协同计算的能力
- 高性能查询优化特性
- 算子下推：openLooKeng通过Connector框架连接到RDBMS等数据源时，由于RDBMS具有较强的计算能力，一般情况下将算子下推到数据源进行计算可以获取到更好的性能。openLooKeng目前支持多种数据源的算子下推，包括Oracle、HANA等，特别地，针对DC Connector也实现了算子下推，从而实现了更快的查询时延响应。
- 启发式索引：openLooKeng提供基于Bitmap Index、Bloom Filter以及Min-max Index等索引。通过在现有数据上创建索引，并且把索引结果存储在数据源外部，在查询计划编排时便利用索引信息过滤掉不匹配的文件，减少需要读取的数据规模，从而加速查询过程。
- 多种缓存：openLooKeng提供丰富多样的Cache，包括元数据cache、执行计划cache、ORC行数据cache等。通过这些多样的cache，可加速用户多次对同一SQL或者同一类型SQL的查询时延响应。
- 动态查询：所谓的动态过滤是指是在运行时（run time）将join一侧表的过滤信息的结果应用到另一侧表的过滤器的优化方法，openLooKeng不仅提供了多种数据源的动态过滤优化特性，还将这一优化特性应用到了DataCenter Connector，从而加速不同场景关联查询的性能。
- 数据压缩：在数据传输期间进行序列化之前，先使用 GZIP 压缩算法对数据进行压缩，以减少通过网络传输的数据量
- 高可用性
- HA 双活：openLooKeng引入了高可用的AA特性，支持coordinator AA双活机制，能够保持多个coordinator之间的负载均衡，同时也保证了openLooKeng在高并发下的可用性
- Auto-scalling：openLooKeng的弹性伸缩特性支持将正在执行任务的服务节点平稳退服，同时也能将处于不活跃状态的节点拉起并接受新的任务。openLooKeng通过提供“已隔离”与“隔离中”等状态接口供外部资源管理者（如Yarn、Kubernetes等）调用，从而实现对coordinator和worker节点的弹性扩缩容
若有收获，就点个赞吧
0 人点赞
