解读 Kylin 3.0.0 | 更敏捷、更高效的 OLAP 引擎

在近期的 Apache Kylin Meetup 成都站上,我们邀请到 Kyligence 架构师 & Apache Kylin Committer 倪春恩对 Kylin 3.0.0 版本的一些重要功能及改进从使用到原理进行了介绍。

△ Meetup 现场视频

Apache Kylin 在今年 4 月 18 日发布了 3.0.0 Alpha 版本,我今天的分享也围绕Release notes内提到的三个功能,即:基于 Curator 的作业调度器,使用 Apache Livy 提交 Spark 任务,实时 OLAP。

基于 Curator 的作业调度器

首先讲一下作业调度器。Kylin 支持集群部署, Kylin 实例主要有三种模式。一种是 Job 模式(用作任务构建),一种是 Query 模式(用作 Query 查询),配置成all模式的节点既做 Query 节点又做 Job节点。之前,我们需要先设置配置项,配置 kylin.server.cluster-servers 为集群中所有节点,这样各节点便可互相通信,比如元数据的同步。

我们可以通过 Ngnix 等工具配一个对 Kylin 集群查询的多活,即便有某个节点挂掉了,也不会影响 Kylin 的查询使用。但在原有的默认模式下,是不支持任务构建的高可用的。在默认的任务调度模式下,Job 节点会在 ZooKeeper 的一个路径下生成一个临时节点作为并发锁,只有持有锁的节点才会启动任务调度器。但如果发生一些情况,这个任务节点退出了,或者是 ZooKeeper 服务异常,都会导致所有的构建任务、merge 任务无法执行,别的任务节点也没有办法把这些任务 takeover 起来。

另外,所有的 Kylin 节点都需要配置集群节点列表的配置项 kylin.server.cluster-servers,一旦需要往集群添加节点,所有的节点配置项都必须改,非常不利于集群的扩展,一旦某个节点没有配正确,就会发生很多异常情况。

接下来介绍 Curator。Curator 是一个 Apache 的孵化项目,Curator 框架提供了一套高级的 API, 简化了 ZooKeeper 的操作。它增加了很多使用 ZooKeeper 开发的特性,可以处理 ZooKeeper 集群复杂的连接管理和重试机制。Service Discovery 是 Curator 的一个模块,他提供了 Service 的注册机制,对一个新 Service的注册,Service 的状态变更事件,别的 Service 能够立即得到相应。

基于 Curator 的作业调度器的配置方法很简单,把配置项 kylin.job.scheduler.default 配置成 100 即可。启动后,所有节点都会往 ZK 里面去注册临时节点,每个临时节点写有节点 url,模式等基本信息。

在此模式下的任务调度,只会有一个被选举出来的任务节点,来执行任务调度。多节点的 Leader 选举,是基于 Curator 的 Leader 选举。它具有这样的特点:

  • 每个实例都能公平获取领导权

  • 获取领导权的实例在释放领导权之后,该实例还有机会再次获取领导权

每个 Job 或 All 节点会往 leader 路径下创建节点,获得领导权的任务节点会启动任务调度器。失去了领导权后,该节点会中断所有的构建任务,另一台节点会紧接着获取新的领导权,把所有的任务给恢复起来。

另外在系统页面会有一个节点监控页面,用户可以看到各节点的类型与状态。

该任务调度模式的优点有:

  • 实现了 HA,保证构建任务的持续执行

  • 方便进行节点扩展

  • 配置方便,减少运维成本

  • 便于监控

使用 Apache Livy 提交 Spark 任务

第二个 Feature 是支持使用 Apache Livy 提交 Spark 任务,Livy 是一个基于 Spark 的开源 REST 服务,它能够通过 REST 的方式将代码片段或是序列化的二进制代码提交到 Spark 集群中去执行。它提供了以下这些基本功能:

  • 提交 Scala、Python 或是 R 代码片段到远端的 Spark 集群上执行

  • 提交 Java、Scala、Python 所编写的 Spark 作业到远端的 Spark 集群上执行

  • 提交批处理应用在集群中运行

对应到 Kylin,需要作如下配置:

  • kylin.engine.livy-conf.livy-enabled=true

  • kylin.engine.livy-conf.livy-url={url of Livy server}

  • kylin.engine.livy-conf.livy-key.file={path for kylin job jar}

  • kylin.engine.livy-conf.livy-arr.jars={paths for dependencies}

首先开关 kylin.engine.livy-conf.livy-enabled 需要打开,默认是关闭的。其次是配上 Livy rest server 的 url 到 kylin.engine.livy-conf.livy-url,另外需要配上任务 jar 包的路径到 kylin.engine.livy-conf.livy-key.file,最后是 kylin.engine.livy-conf.livy-arr.jars 需配置为任务依赖的 jar 包。下图为使用 Livy 服务进行 Spark 构建发送的请求日志,从中可以看到相应的参数。

默认情况下,每个 Kylin 节点都要配置自己的 Spark home,有了此功能,所有的任务节点都需要往一个 Spark Uil 去提交任务,这样就比较方便管理和监控。

实时 OLAP

Kylin 在 2014 年由 eBay 开发完成,初衷是解决海量数据快速交互式分析的问题,数据源只支持 Hive。Kylin 在 v1.6 引入的准实时数据摄入,但是还是需要触发构建,至少会有数分钟的延迟。eBay 开发团队基于 Kylin 开发了 Real-time OLAP 的特性,实现了 Kylin 对 Kafka 流式数据的实时查询。eBay 内部已将此功能用于生产,并稳定运行超过一年时间。该 feature 于 2018 年下半年开源,并在 v3.0-alpha 里正式发布。

Ø  实时 OLAP 基本架构

在新的架构下,数据查询请求根据时间分区列(Timestamp Partition Column)分为两部分, 历史数据的查询请求仍将发送给 HBase Region Server,最新时间段的查询请求将发送到实时计算节点,Query Server 需要将两者的结果整合后返回给查询客户端。

与此同时,实时计算节点会不断将本地数据上传到 HDFS,在满足一定条件时会通过 Hadoop 来构建 segment,从而完成实时数据向历史数据的转化,并且实现了降低实时计算节点压力的目的。

Ø  Real-time OLAP 的概念和角色

为实现 Real-time OLAP, Kylin 引入了一些新的概念。

1. Streaming Receiver

Streaming Receiver 的角色是 worker,每个 receiver 是一个 Java 进程,受 Coordinator 的管理,它的主要职责包含:

  • 实时摄入数据

  • 在内存构建 cuboid,定时将保存在内存的 cuboid 数据 flush 到磁盘,形成 Fragment 文件

  • 定时 checkpoint 和合并 Fragment 文件

  • 接受对它所负责的 Partition 的查询请求

  • 当 segment 变为不可变后,上传到 HDFS 或者从本地删除(依据配置)

2. Receiver Cluster

Streaming Receiver 组成的集合称为 Receiver 集群。

3. Streaming Coordinator

Streaming Coordinator 作为 Receiver 集群的 Master 节点,主要职责是管理 Receiver,包括将 Kafka topic 的 partition 分配/解除分配到指定的 Replica set、 暂停或者恢复消费、收集和展示各项统计指标(例如 message per second)。当 kylin.server.mode 被设置为 all 或者 stream_coordinator,这个进程就成为一个Streaming Coordinator。Coordinator 只处理元数据和集群调度,不摄入消息。

4. Coordinator Cluster

多个Coordinator 可以同时存在,组成一个 Coordinator 集群。在多个 Coordinator 中,同一时刻只存在一个 Leader,只有 Leader 才可以响应请求,其余进程作为 standby/backup。

5. Replica Set

Replica Set 是一组 Streaming Receiver,它们动作一致。Replica Set 作为任务分配的最小单位,Replica Set 下的所有 Receiver 做相同的工作(即摄入相同的一组 partition),互为 backup。当集群中存在一些 Receiver 进程无法访问,能保证每一个 Replica Set 至少存在一个健康的 Receiver,那么集群仍能正常工作并且返回合理的查询结果。在一个 Replica Set 中,将存在一个 Leader Receiver 来做额外的工作,其余的 Receiver 作为 Follower。

Ø  Real-time OLAP 的整体架构

下图为 Kylin 实时 OLAP 的整体架构,数据流向方面,是从 Kafka 到 Receiver,再由 Receiver 上传到 HDFS,最后由 MapReduce 程序合并和重新加工 Segment 进入 HBase。

查询方面,查询请求由 Query Server 发出,根据查询条件中出现的时间分区列,分发请求到 Receiver 和 HBase Region Server 两端。

Topic Partition 的分配和 Rebalance、Segment 状态管理和作业提交由 Coordinator 负 责。

另外在实时构建中,Kylin 使用 ZooKeeper 进行元数据的存储。

提问: Kylin 实时 OLAP 的数据消费都是针对 Kafka,我最近也在去做 POC,就是针对 Kylin v3.0。我发现了在消费 Kafka 数据的时候,3 个 Server 里,有的 Server 摄取了全量数据,有的不是,这个我不太清楚具体是什么一个情况。

回答: 你可以点击某一个 Receiver,可以看到这个 Receiver 对这个 Cube 的消费统计数据。

提问: 还有消费延迟,这个怎么去解决这个问题呢?

回答: 数据消费延迟在我们的测试环境也有,目前来讲处理的方法是通过 Server 的扩容。

提问: 刚才也听您说了很多 Kylin 实时的一些原理,同 Spark Streaming 和 Flink 相比,有什么优点?

回答: Kylin 和他们不是在一个层面的,Spark Streaming 和 Flink 是更加通用的计算框架,而 Kylin 是一个 OLAP 的应用,通过预计算,对于一个查询,它的目标是直接去拿到一个结果。

提问: 我想问的就是刚才那个保留状态,他能保证比如说数据没处理到的,可以实现端到端一次性不丢失吗?就是在消费过来的数据时服务挂掉了,这时候进来的那部分数据会丢失吗,就是从 Kafka 数据去消费的时候?

回答: 这个还是得看时间窗口的配置,Kylin Realtime 会按配置接受一定时间延迟的数据进来。但如果过了这个配置的最大时间,是没办法被构建的,因为对应的 Segment 已经变成一个本地的只可读不可写的状态。

往期案例与实践

向 Kylin 添加实时 OLAP 能力

本地快速体验 Kylin「分析篇」

10 分钟了解 Apache Kylin(业务篇)

Kylin 在 58 集团的实践和应用

Kylin 在小米大数据中的应用

首届 Kylin Data Summit 大会将于7月12日在上海隆重召开。在本次峰会上,包括Gartner、微软、ebay等企业的大咖为你洞悉数据分析的未来趋势,包含针对增强分析以及云上分析的洞见,更有金融、制造、零售、互联网等行业的知名企业分析自己的成功经验。

目前大会购票火热进行中,5 人团购享全网最低价, 戳此 了解更多大会详情

#社区福利# Apache Kylin 社区 Contributor 可联系 K 小助(微信号:uncertainly5)获取赠票 ,添加为好友后需回复“赠票”。

点“阅读原文”了解大会详情

我来评几句
登录后评论

已发表评论数()

相关站点

+订阅
热门文章