关于openLooKeng:openLooKeng-新版本v120介绍

42次阅读

共计 1669 个字符,预计需要花费 5 分钟才能阅读完成。

自开源以来,openLooKeng 社区失去越来越多敌人的反对。小伙伴们对 openLooKeng 的性能给予了必定和赞叹,同时也给出了许多有价值的倡议。暖春 3 月,openLooKeng 迎来了新版本 V1.2.0。基于小伙伴们的体验和倡议,新版本新增一些技术,以进步引擎性能,争取为大家带来更丝滑晦涩的体验。

于引擎内核来说,次要加强两个维度:交融剖析场景和性能。

  • 查问容错加强,进步引擎执行的可靠性
    在批查询处理运行的过程中,当某个工作节点呈现故障时,可在其余节点上复原工作,比方对 Hive 数据源的 insert 和 create table as select 操作。针对长时间运行的批查询处理工作,相比上一个版本,稳定性和可靠性有了极大的晋升。
  • 查问性能的优化:基于 StarTree 的查问预聚合能力加强
    StarTree 旨在优化低提早、聚合查问语句。咱们通过 StarTree 查问预聚合能力,为用户构建所须要的不同维度和不同聚合操作的 cube。在当前的查问过程中,如果遇到任何可匹配的聚合子查问,引擎将间接从 cube 中读取数据,防止在原始表上执行查问,从而进步查问性能。
  • 引入 CTE(公共表表达式)优化技术,缩小内存应用
    在执行打算优化过程中引入 CTE(公共表表达式)技术。当一个简单查问中,存在某个子查问(例如 with 语句)被屡次应用,优化器会为反复的子查问主动生成一个 CTE 节点,该 CTE 节点的输入会被执行打算流程中的多个父节点生产。也就是说,反复的子查问只会执行一次,化繁为简,同时也缩小内存占用,引擎取得更好的性能。
  • 通用算子下推框架,让 Connectors 参加到执行打算优化中
    为了让算子下推过程更加简略灵便,咱们采纳新的通用算子下推框架,让每个 Connector 能够参加到执行打算优化中。引擎在进行执行打算优化时,可能自行利用 Connector 的优化规定,使得算子下推过程变得更加高效。
  • 加强 HIVE ORC 的数据保护性能
    该个性优化了数据写入和数据批改(更新和删除)的处理速度,并不影响『读性能』的晦涩度;反对并发拜访 Hive Metastore,进步元数据操作性能,从而进一步优化数据写入和批改的性能。

于引擎门户来说,次要集中在南向生态方面的优化。

  • HBase Connector 性能优化
    针对单表查问性能的晋升,咱们新增了分片算法。另外,该性能反对 HBase 拜访 Snapshot 的模式,从而晋升多并发查问性能。
  • 数据源 UDF(User-Defined Function)反对下推
    引擎反对内部函数(UDF)的注册,也反对将其下推到 JDBC 数据源。为了让大家领有更好的体验,用户能够在不迁徙本人数据源 UDF 的状况下,应用已有的 UDF, 进步 UDF 的复用度。

以上便是 openLooKeng 新版本 V1.2.0 在性能优化上较为亮眼的中央。当然 ,作为大数据畛域的要害我的项目,openLooKeng 非常看重引擎的易用性和安全性。 针对这两点,新版本 V1.2.0 做出如下加强:

  • 易用性 | 加强 Admin Dashboard UI 用户体验
    优化定时全量加载导致的 UI 页面卡顿,
    加强查问历史和查问后果的分页显示,
    优化新增连接器的参数配置,
    UI 界面反对 Kerberos 和明码登录,反对查问历史按用户进行过滤。
  • 安全性 | 基于 Ranger 的细粒度权限管控:反对行过滤和列掩码
    减少行过滤和列掩码,减少认证用户模仿权限管制,提供更细化的权限管制粒度。

看了这么多,是不是很想入手一试?感兴趣的敌人能够下载体验。
下载地址: https://openlookeng.io/zh-cn/…

如果您对新版本 v1.2.0 有其余倡议,欢送发邮件至 users@openlookeng.io 告知咱们。openLooKeng 社区感激敌人们的反对,期待并欢送更多敌人们的参加。

欢送退出 openLooKeng 社区,一起做点有意思的事儿,让大数据更简略!

openLooKeng 开源社区官方网站: https://openlookeng.io/zh-cn/

openLooKeng 代码仓地址: https://gitee.com/openlookeng

正文完
 0