10 分钟了解 Apache Kylin（业务篇）

（原文有删改）

目录

• 1. 什么是 OLAP 数据分析（懂的可以直接跳过本节）

• 2. Kylin 适用场景

• 基本盘

• 数据可视化

• 适用场景扩展

• 官方的功能简介

• 3. Kylin 商业化

• 4. 用户案例分析

• 用新版本

• 数据规模

• 数据可视化

• 权限

• SQL 转发层

• 近实时和实时

• 存储层优化

Kylin 是由 eBay 公司开源，中国人主导的大数据中间件，解决海量数据分析查询的问题。目前 Kyligence 公司在做 Kylin 的商业化推广。

本文希望让你了解 Kylin 是什么，适用于哪些数据分析场景，二次开发要做哪些工作。

作者是刚刚看完 Kylin 和 Kyligence 官网文档的新人一枚，素材主要来自于 Kyligence 的在线文档，官方博客，如有任何问题请指正。

1. 什么是 OLAP 数据分析（懂的可以直接跳过本节）

OLAP (Online Analytical Processing) is the technology behind many Business Intelligence (BI) applications. OLAP is a powerful technology for data discovery, including capabilities for limitless report viewing, complex analytical calculations, and predictive “what if” scenario (budget, forecast) planning.

An OLAP cube is a multidimensional database that is optimized for data warehouse and online analytical processing (OLAP) applications.

An OLAP cube is a method of storing data in a multidimensional form, generally for reporting purposes. In OLAP cubes, data (measures) are categorized by dimensions. OLAP cubes are often pre-summarized across dimensions to drastically improve query time over relational databases. The query language used to interact and perform tasks with OLAP cubes is multidimensional expressions (MDX). The MDX language was originally developed by Microsoft in the late 1990s, and has been adopted by many other vendors of multidimensional databases. 

Although it stores data like a traditional database does, an OLAP cube is structured very differently.  Databases, historically, are designed according to the requirements of the IT systems that use them. OLAP cubes, however, are used by business users for advanced analytics. Thus, OLAP cubes are designed using business logic and understanding. They are optimized for analytical purposes, so that they can report on millions of records at a time. Business users can query OLAP cubes using plain English.

个人理解，数据分析就是基于原始数据做计算，找到隐藏在数据中的某种规律/现象/决策依据，产生商业价值。

立方体就是数据按不同查询维度汇总的维度集合，维度就是有过滤/分组属性的字段。类似量子理论观察者效应，因为业务分析需要，产生了各种查询，由查询确定了如何对数据进行建模。也就是说，立方体的数据模型是由分析查询决定的，而不是数据本身的内在关系决定的。

对一个只懂 SQL 的程序猿来说，OLAP 就是对明细表用各种 SQL 函数，窗口函数，聚合分组，join 联合，计算出统计结果。再来个数据可视化转成图表，复制粘贴到 ppt，搞定。对查询进行建模，就是数据分析模型。

2. Kylin 适用场景

基本盘

数据分析领域常见的计时标准是，分析师一杯咖啡的时间。

大数据分析比数据分析多了一个大字，数据海量。由于数据多，数据分析需要的时间变长了，喝完一杯咖啡却没有计算出结果。怎么办？

再喝一杯，但咖啡喝多了失眠。为了解决分析师的失眠问题，Kylin 应运而生。

海量数据，分析师用别的工具要喝好几杯咖啡，用 Kylin 却能在一秒内，最多几秒内得到需要的结果，这就是 Kylin 的核心价值。

原始数据亿条甚至百亿条，用其他工具基本都要几十秒甚至几十分钟才能得到数据分析结果，Kylin 为什么能这么快？

Kylin 的工作原理是把所有可能用得上的分析结果都预先计算好，并将计算结果存下来。

用户查询时，复杂查询会变成一个简约而不简单的根据 key 查 value，不用计算了，所以快。

既然要预先计算所有有查询可能的计算结果，那么分析结果的数据量是随维度（字段数）指数递增的。所以一般 15 个维度内较佳。

如果维度较多，需要预计算并存储的结果集会非常大。在满足分析需求的前提下，如何更快更省资源的预计算、存储，非常有挑战，很考验技术细节的打磨，不像报表场景算固定的值那么容易。

作为kylin的基本盘，Kylin 在预计算场景使用了很多较为先进的技术理念。比如根据实际的业务场景，把维度（字段）按必要维度，聚合组维度，层级维度进行建模，只计算并保存有实际业务意义的结果集， 避免结果集快速膨胀。对计算 topN,去重统计等数据分析常用的场景，使用若干精妙的算法/数据结构/字典编码让计算更快，资源消耗更少。对可以接受误差的去重统计场景提供基于统计学的近似去重算法。支持spark纯内存计算模型提高计算速度，等等。

在适用的大数据分析领域，Kylin 就是最好的选择。

数据可视化

如果说内在价值是数据的灵魂，那么可视化图表就是数据的皮囊。好看的皮囊千篇一律，有趣的灵魂万里挑一。但事实是，好看才能吸引别人去了解灵魂....所以数据可视化很重要。

既然基本盘是给分析师使用，那就应该适配分析师的使用习惯。

Kylin 可以无缝整合传统 BI 工具，如 Tableau，PowerBI/Excel，MSTR，QlikSense。分析师使用传统 BI 工具，不用学习新东西，很赞。所以 Kylin 很适合金融行业，传统行业，那些用传统 BI 分析工具的公司。

而新兴互联网公司的特点是不给钱广泛使用开源，所以 Kylin 也支持无缝连接 Superset。Superset，一个基于 web 的数据可视化开源产品，支持 47 种图表展示，图表丰富美观，可视化功能强大，易集成到公司内部的数据平台。不少使用 Kylin 的互联网公司选择了 Superset 作为可视化工具。

适用场景扩展

不想当将军的士兵不是好士兵，没有统一大数据分析领域的梦想不是好开源。在基本盘建立后，Kylin 也想做更多的事情。

首先是报表。

既然能支持灵活查询，固定格式的报表自然水到渠成。Kylin 不是做报表的唯一选择，但既然已经用 Kylin 了，报表也用 Kylin 会降低运维和开发成本。

其次是没有提前定义好数据模型，临时起意的分析查询。

没有预计算结果怎么办？社区新版本支持查询下压，可以将不能直接获得结果的分析查询，转调用 Hive，SparkSQL 等其他引擎来计算。

最后是实时方向的演进。

由于要预计算，原生 Kylin 比较适合 t+1 的分析查询，无法满足近实时数据分析的场景。比如直播，再比如某个热门线上活动，那些需要根据实时信息及时调整，时效性较高的场景。

实时数据分析领域有个开源产品 Druid 做的还不错，Kylin 应该借鉴了设计思路。技术路线上，Kylin 首先支持近实时场景，可以用于分析几十分钟一个小时内的数据。最新的版本支持了秒级延时的实时场景，离实时数据分析又近了一步。如果 Kylin 在实时数据分析领域能跟 Druid 差不多，就能逐步统一大数据分析领域了。因为 Kylin 在预计算，整合 BI 工具方面，优势明显。

官方的功能简介

亚秒级查询百亿规模数据。

标准 SQL 接口。

自定义数据模型和立方体。

无缝整合 BI 工具，如 Tableau，PowerBI/Excel，MSTR，QlikSense，Hue和 SuperSet。

增量更新。

提供管理和监控功能。

访问权限控制。

3. Kylin 商业化

商业化，就要明确告诉潜在付费用户，跟直接用开源相比，付费版究竟有什么优势？

一般来说，商业版的优势，就是开源产品的不足。所以做 Kylin 的二次开发，也可以参考商业化的内容。

Kyligence 官网有在线文档详细介绍了与直接用开源 Kylin 相比，用商业化版本有什么好处，总结如下。

BI 产品认证，基于 SLA 的商业支持

金融行业讲究花钱买平安。为什么金融行业大多使用 Oracle/DB2？稳定，出问题有人负责解决，有兜底。所以有认证，有 SLA 承诺，有商业支持，对金融行业那些不差钱的用户很重要。

多租户，Cube，行，列及单元格级别权限控制

企业应用，权限管理，资源隔离很重要。作为一个数据库产品，可以在上层业务系统里实现权限控制，类似 web 系统访问关系型数据库，但这有开发工作量。作为商业产品，提供更完善的权限系统，资源隔离机制，减少二次开发工作量，挺重要。

使用 Hybrid OLAP 引擎，支持明细查询，智能查询下压

个人理解，这是在 Kylin 之上包装了 SQL 转发层，统一 SQL 入口，统计信息查 Kylin，明细信息查 Presto/SparkSQL。

智能查询下压，社区新版本已经支持了。SQL转发层技术上不难，很多使用 Kylin 的互联网用户基于 Kylin 老版本自己实现了一套。

商业化版本减少二次开发工作量，对不差钱的金融用户，不具备二次开发能力的传统行业用户，挺有用。

 

智能建模，智能诊断优化

核心是分析构建日志，查询日志，基于存储代价和查询时间，优化建模。文档说使用了自适应的机器学习系统，有专利。

要建好数据模型，需要对查询场景做全面梳理。而让甲方提前梳理出全部的查询场景，否则查询会有问题？这是在为难我胖虎。所以智能建模对商业化来说非常重要，也是一大卖点。

而互联网用户自建，自动的建模优化就不是强需求了。业务方查询场景没搞清楚，还想自动优化？不支持，要排期，自己改。大悟。

读写分离，自动化部署运维

读写分离本质上也是一种部署方式。自动化部署运维是商业化必须的，但附加值并不高。

这是因为自动化部署虽然有用，但价值也就是几个运维人员一定时间的工作量，部署脚本写起来并不难。

对私有云来说，买产品肯定乙方负责安装，自动化部署就是帮自己减轻工作量。

对公有云来说，一键式部署并没有太高的技术门槛。如果真的有利可图，云厂商分分钟自己搞。竞争不是公平的，云厂商自己可以调用内部接口，可以产品免费其他方面收费。所以第三方供应商只靠部署运维很难赚到钱，Cloudera Manager 叫好不叫座就是个很好的例子。

4. 用户案例分析

Kyligence 官网提供了 5 个解决方案场景，7 个解决方案行业，14 页技术博客，十几个真实用户的使用案例。看了一圈小结如下。

用新版本

用户案例往往是这样的，详细介绍了使用 Kylin 中遇到什么问题，如何解决，最后说这个问题在社区的x.x版本已解决。所以只要没有历史包袱，一定要用新版本。

数据规模

事实表单表一般在十亿到几百亿行，单立方体最大几百亿行，日查询量最多几百万次，延时基本在秒内。想要快，就加机器。

数据可视化

不差钱的用BI工具，互联网用户用Superset。还有个别用户 web 自建，可能有历史包袱。

权限

有些互联网用户自己实现了细粒度的权限认证，资源隔离。不难。

SQL 转发层

有些互联网用户自己实现了 SQL 转发层，查明细基本都走的 Presto。个人认为 Phoenix 更适合查询明细的场景，应该是因为原始数据都存在 Hive里，用 Presto 可以直接查不用再导出一份到 HBase，节约存储空间，方便管理。

近实时和实时

近实时案例是半小时到一小时延时的近实时数据分析。实时案例是 5 分钟延时的数据分析，暂无秒级延时的案例。

存储层优化

美团搞了套 Kylin on Druid，代替 Kylin on HBase。

目的是解决用 HBase 存储结果集，维度后缀匹配和单维度查询，扫描数据过多的问题。个人理解，这个问题本质是建模时做了取舍，只预计算了部分维度的汇总信息。比如只预计算了 A,B,C,D 四个维度组合的汇总信息，查询 A,B,C,D 四个维度的汇总信息没问题。但如果要查 B,C,D 维度或 A 维度的汇总信息，用 HBase 这种主键前缀有序的引擎，二次计算需要扫描的数据量太多，查询就慢了。使用 Druid 作为底层存储，在需要二次计算的场景可以扫描更少的数据，查询性能得以提升。

这个方案有明确的使用场景和限制约束，在特定场景下很有用。