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

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

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 进行元数据的存储。

Q & A

提问：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 已经变成一个本地的只可读不可写的状态。