OpenLookeng是华为开源的MPP SQL引擎，其实是基于PrestoSQL(v316)做的二次开发和优化。
Doc链接

看一个对比图

image.png

华为团队在开源上目前还挺活跃（国内），open欧拉（操作系统），open罗庚（异构数据源统一检索引擎），open高斯（对标greenplum这种传统数仓）鲲鹏社区（CPU架构生态），等等，路子铺的很开。还搞了一些大赛，活动，meetup。

B站还有一些官方团队的视频（Blog/使用介绍/甚至PMC团队会议...）
Link

一、概括

openLooKeng是一个跨数据源、【数据中心】的SQL计算引擎（不存数据），通过连接器对接RDBMS和NOSQL，甚至流数据Kafka，提到计算层（内存），
实现统一SQL入口和视图，用于交互式查询分析

二、与presto共同点/特性（对比双方文档和代码目录）

1）多种权限认证方式
2）WEB管理回话、SQL列表和进度、节点状态监控
3）REST接口/CLI/JDBC
4）队列、配额、内存控制、并发控制
5）管理节点HA
6）可扩展的连接器（后端存储系统）默认都支持10-20个（rdbms数据库、文件、内存、nosql等）
7）扩展类型和自定义函数
8）

三、不同点

1）支持了ODBC
2）openlookeng额外支持carbondata/hbase/华为自家一些东西如hana内存计算/ VDM（类似视图）；presto多了redis/carssandra/mongodb等（可能是openlookeng没列或者其presto版本较低 支持较少）
3）对已有数据的外置索引（位图、bloom过滤器、minmax稀疏索引，Btree，StarTree（类似kylin的cube 预聚合）
4）界面做了一些扩展
5）一些函数扩展
6）专门为跨域、跨集群定制的DataCenter Connector
7）

小结：
外置索引这块还是挺有意思，可以试试。
但是presto也在不断优化，如Raptorx分层缓存计划。（注：这是prestoDB的，不是prestoSql（现在较Trino）的）
说到底还是看社区的人有多投入去优化这个东西。。
不知道值不值得去跟进。。

[TODO 继续研究和测试]

实测后 新增点：

• 重要改变：WEBUI与presto差别很大，dashboard风格，节点监控/metrics/QueryHistory/以及最主要的SQL面板 终于可以在界面执行了(就是有点卡 等优化？）
• 集成了Ranger权限
• 动态catalog：不需要重启去添加新的catalog。。
• 动态filter ：join上的优化
  举个例子说明：关联的时候 动态收集小表的关联列信息（比如set/bloomfilter/maxmin等稀疏索引） 作用到大表的Scan节点上去过滤，能减少很多提到上层真正去关联的数据量。
  适合于筛选率很高（即匹配结果不多）的情况。
• task级别容错重试
  （还是stage级？反正增加了snapshot持久化和分布式重试的逻辑）
  更正：这个是实验性功能。。文档上说只对hive上的insert语句生效。。
• State Store：好像是用在HA和动态filter上的
• ORC Cache：功能也挺全的【If enabled, workers automatically cache file tail, stripe footer, row index, bloom index of all ORC files because they are small.】
• 提供了一些Cache命令（CACHE TABLE, SHOW CACHE, and DROP CACHE）
• Meta Store: 看了下源码貌似主要是给索引用的 因为一些索引元数据 不知道放哪。。当然设计上，其他多个功能以后可能也会用到metastore。
  HeuristicIndexerManager

WEB界面如下：

image.png

PS 实测结论：部署和运行与presto差不多，性能的话确实好一些（索引这块没详细测）

更新

openlookeng的索引支持和实现：提供了一些索引相关的语法支持，和元数据维护（JSON文件保存到本地或者hdfs），索引生成后的数据文件放在hdfs，使用时会读到coordinator。
索引按stripe/file/partiton有多个粒度。

• maxmin稀疏索引 比如存储数值类型 过滤掉无关数据块。直接读到内存使用。
• bloomfilter过滤器索引 快速判断不存在的值。直接读到内存使用。
• btree索引 支持范围 和点查。不同的是，使用了org.mapdb这个工具包，轻量java集合本地存储的支持（堆外/磁盘 100GB+）。即先从hdfs索引文件反序列化到本地。。
• bitmap 位图索引。也是使用了org.mapdb存储。

综上考虑，主要有几方面问题：

• 其一支持的数据量级明显不能很大，内存根本放不下。10-100TB的数据的索引大小，maxmin级别的大概10G（单列），Bloomfilter就不好说了（结合数据基数/设置的错误率)
  感觉数据量大了用不上，数据量小了还不如直接放GP这些mpp，反正有connector。。。
• 其二是索引的效果，比如maxmin是需要结合排序去做的，暂时不清楚索引构建时是不是重写了文件，否则需要依赖用户自己给数据排序后建索引，不然很可能maxmin过滤不了东西。
• 其三是这个索引可能只支持稳定的表或者分区，否则建立索引后，追加的数据进来，索引就无意义了。

注：当前，启发式索引仅支持ORC存储格式的Hive数据源。

因此，使用者需要明确这几点才建议使用索引功能。。

202109再次PS：
看了索引的相关源码，实现起来感觉就像普通java程序员。。与原本源码各种异步、lambda嵌套看起来简单舒服多了，也low多了。。明显是两个画风了。大量中间对象创建，大量不优雅的做法，臃肿笨重的hashmap，每个split的循环逻辑，比如用:::去分隔索引的key，比如一层层的if{}，。。。说实话有点凑数的感觉。

总之，索引这个东西，个人感觉，比较鸡肋