你与顶级程序员只差一个实时麒麟，干货狠戳！

何为麒麟？

Apache Kylin是一个开源的分布式分析引擎，提供Hadoop之上的SQL查询接口及多维分析(OLAP)能力以支持超大规模数据，最初由eBay Inc.开发并贡献至开源社区。Kylin Streaming作为eBay的实时分析解决方案，可以将数据准备的延迟时间从几天或几小时缩短到毫秒或秒级。

为何应用？

企业在进行数据分析时，通常使用商业智能工具(BI)例如MSTR, tableau或SQL进行数据分析。但是当越来越多的数据从传统数据仓库迁移时(例如从Teradate迁移到Hadoop)，他们将面临一些挑战。比如传统的BI工具对于Hadoop的支持有限，Hadoop没有成熟的SQL接口，交互式查询在Hadoop上会花费过⻓的时间，而Kylin弥补了Hadoop在OLAP领域的空缺。

2017年12月14日、15日

eBay开展Kylin技术课堂

快速度

飞一般的感觉

Apache Kylin的神奇之处在于它根据定义的维度进行预计算。因此在进行查询时，不需要扫描PB级别的源数据，而是扫描比源数据小得多的预计算后构建的cube，从而加快查询速度。但预计算并构建cube的过程需要花费大量的时间，这在支持实时分析用例时是一个巨大的挑战。

自Kylin 1.6以来，Apache社区提供了一个可以从Kafka topic构建cube的流式计算解决方案，它使用MapReduce作业定期摄取Kafka数据，然后以批处理方式构建cube。与传统的从hive批量构建cube的方式相比，流式计算可以从小时到分钟级别显著减少cube构建与cube查询之间的等待时间。但是这个解决方案在eBay还有一些限制，主要包括:

★分钟级的cube构建延迟

★创建了过多的小型HBase表

★过于依赖Kafka

★难以将Hive和Kafka结合在一起

★eBay的Hadoop集群没法直接连通Kafka集群

为了构建真正的“实时OLAP”，不仅查询可以亚秒返回，而且数据准备延迟也在亚秒级，我们设计了新的Kylin Streaming解决方案。在新的解决方案中，我们将流数据分为三个阶段:

1.内存阶段

系统会从流数据源不断的获取数据，并根据预先定义好的模型，在内存中做一定的聚合。

2.磁盘阶段

当内存中的数据到达一定的阈值，或者过了某个预先配置好的时间之后，数据会被刷到磁盘，按列存储，并建立索引以加速查询。

3.Full Cubing阶段

一段时间之后，根据一定的配置，磁盘中的某些数据段会变成不可变段。这些不可变段会被存到HDFS，然后构建引擎会根据一定规则触发cube构建，并将构建结果存到HBase中。

这样设计的优点是三级数据存储均支持查询，当第一阶段数据被存储在Kylin平台的内存时，数据就可以被查询，从内存到磁盘到HBase的数据转换对用户来讲是透明的。因此数据准备的延迟很低，并且所有旧的大数据最终都将被完全预计算为一个OLAP cube，然后存储到HBase中。这就是为什么Kylin实时分析平台依然能够实时保持对PB级数据的亚秒延迟查询能力。

强架构

加强引擎的拓展

上图展示了新的Kylin Streaming架构，其中蓝色方框内是新引入的组件，下面将对其中的组件进行介绍。

1.Streaming Receiver负责从流数据源获取数据并在本地构建实时段；

2.Metadata Store用于存储与流相关的元数据，例如cube的信息分配、cube的构建状态信息等；

3.Coordinator负责做一些协调工作。例如当新的streaming cube上线时，决定哪些Streaming Receiver可以分配给cube进行构建 ；

4.对现有的构建引擎和查询引擎进行了拓展，以支持实时构建cube ；

5.通过监视和管理组件，对cube构建的状态以及集群的状态进行监视，并进行一些集群管理工作。

细流程

Cube Engine

1.Coordinator问数据源所要构建的cube包含哪些分区；

2.Coordinator决定分配哪些Replica Set用于消费流数据以及何时让Streaming Receiver开始消费数据；

3.Streaming Receiver开始消费数据并对流事件建立索引，以提供实时数据的查询；

4.一段时间后，Streaming Receiver将不可变的段从本地文件复制到远程HDFS文件；

5.Streaming Receiver通知Coordinator某个段已经被保存到HDFS；

6.Coordinator在所有receiver都提交了相关实时段之后，会提交一个Job给构建引擎

7.构建引擎从流HDFS文件构建所有的cuboids；

8.构建引擎将cube数据存入HBase；

9.存入HBase后，Coordinator通知所有Streaming Receiver删除相关的临时段。

细流程

Query Engine

1.Query Engine询问Coordinator哪些Streaming Receiver包含cube的实时段数据

2.Query Engine发送查询请求到相关的Streaming Receiver查询实时分段

3.Query Engine发送查询请求到HBase查询历史分段

4.第二步和第三步是并发执行的，当结果返回后，Query Engine聚合查询结果，并将响应发送回客户端。

多角度

更多细节剖析

段窗口和状态

▲段按照事件时间来划分

新创建的段首先会处于Active状态，在设置的一段时间内如果一个段没有新的数据进来，段的状态会变为Immutable，然后被写入远程HDFS，这个时间是可以在cube设计时定义，每个cube可以有不同的设置。

基于列的片段文件格式

▲数据基于列进行存储

1.对于每个维度，我们有三部分的数据

2.维度词典信息，用于存储维度值到id的映射关系

3.维度的字典编码记录

4.索引数据，当前主要是反向索引

Replica Set

Replica Set的设计和其他分布式系统例如Kafka、Mongo、Kubernetes等的设计是类似的，目的是通过冗余保证高可用性。Streaming Receiver实例会被预分配到Replica Set中，在同一个Replica Set中的Streaming Receiver有完全相同的本地状态。

在一个Replica Set中的所有Streaming Receiver共有相同的assignment信息。通过zookeeper做lead选举，Lead负责将实时分段上传到HDFS。（作者/eBay Kylin开发团队）