1. 使用 Kylin 的缘由
爱奇艺 OLAP 服务演变
爱奇艺大数据 OLAP 服务演变的过程可以用如下架构图说明：
数据处理流程分为如下几个层级：
最下方是采集平台，收集业务的埋点和日志；
数据按时效性分为两种类型：离线类型的灌入到 HDFS，实时数据灌入到 Kafka；
往上是各种分析引擎，Hive 用于 PB 级别的离线分析，Kylin 用于每日报表，针对相对固定的维度进行分析，Impala 用户 Ad-hoc 场景，Kudu 支持实时更新和分析，Druid 针对的是实时事件流；
在这些引擎之上是统一的 SQL 引擎 -- Pilot，负责引擎和数据源的智能路由，基于此构建了 BI 分析平台，工作流平台，自定义 SQL 查询平台，实时分析平台等。
爱奇艺发展的大体时间线，2015 年前以离线分析为主，技术上是经典的 Hive + MySQL 方案，但缺点是报表查询比较慢，而且数据时效性差；2016 - 2018 年致力于将查询耗时提升至交互式级别，分为两大类：Kylin 针对固定报表，在维度比较有限的情况下，通过一个预处理，TB 级别数据延时能在秒级，而 Impala 则针对 Ad-hoc 类场景，可以查询任意明细数据；2018 年以后从离线往实时去发力，其中 Kudu 支持实时插入和更新，Druid 支持事件流场景。
Kylin 典型需求
数据分析中一个典型场景是用户行为分析，譬如用户在 APP 上进行一次点击，采集之后进行分析。下面为一个示例 SQL，分析首页过去一天的展示次数。
SELECT COUNT(1) as cnt
FROM hive_table_user_act
WHERE act_type = 'display’
AND page = 'home'
AND dt = '2020-07-18';
此类查询传统是用 Hive 表去做分析，具有如下几个特点：
维度固定：分析的模式每日变化不大；
时效不高：分析昨日（T+1）的使用情况；
交互延时：查询延时要求比较高，通常在秒级；
数据量大：每日规模百亿行的量级。
经典的技术架构如下图所示：
即撰写预计算的 SQL，通过 Spark 或 Hive 查询，将结果集存入到 MySQL，用户报表查询直接 MySQL 里面去读取。这个方案有以下几个缺点：
预处理慢
Hive/Spark 任务随着预计算 SQL 数量的增加（因维度增加），耗时会随之增加，甚至超过一天；
扩展性差
当预计算结果集大到 MySQL 单机无法存下时，Cube 自身也面临扩展性问题；
变更困难
每当分析师有新的需求，均需工程师修改预处理 SQL，排期进行开发，迭代慢且开发量大；
资源浪费
手动书写的预计算 SQL 会有较多的重复计算，通常优化的不是特别好，在资源上也是有很大的浪费。
2. Kylin 在爱奇艺的现状
Kylin 简介
为了克服 Hive + MySQL 方案的上述缺点，爱奇艺引入了 Kylin 来进行固定报表分析。Kylin 是一款基于 Hadoop 产品针对固定报表的 SQL 分析引擎，核心思想是预计算，即提前将报表分析结果（Cube）算好存入到 HBase，报表查询直接从 Cube 里读取，查询速度非常快。
以前文用户行为分析为例，爱奇艺改用 Kylin 后取得了如下效果：
预处理快
处理时间缩短至 1/10，从一天跑不完到 2.5 小时跑完；
扩展性好
一个输入量级在百亿每天的表，构建 9 维 Cube 都比较轻松；
易于调整
Kylin 在页面拖拽即可调整分析的维度和度量，无需开发；
节约成本
实测下来节省了 50% 的计算资源。
下图为当时选型的测试结果：
除了 Kylin，当时也调研了 Impala。Impala 相比 Hive 优势明显，查询延时从十几分钟缩短到 1 分钟以内，但毕竟要从原始数据开始查询，带宽等物理限制决定了查询速度的上限，相比于 Kylin 预构建的模式来说速度还是有明显差距。针对报表类交互式查询，Kylin 是更为合适的。
Kylin 在爱奇艺落地
现在，Kylin 在爱奇艺被广泛使用，已经在 20 多个业务落地，包括 BI、搜索、推荐。总计有 268 个 Cube，每天输入数据在 4 千亿行，每天构造出来的 Cube 有 3TB，Cube 总量在 800TB；查询估计一天有上万个，分析下来查询耗时 P95 < 10 秒，能够较好地满足需求。
3. Kylin 在爱奇艺的优化
业务架构影响
采用 Kylin 对业务架构也起到了积极的作用，最直接的就是业务的使用成本降低了。以推荐为例，分析各个模型的推荐效果，会采用如下图所示架构：
用户点击行为被存放于 Hive Pingback 表，而视频特征被存放于 Hive 维度表，如果要分析 3 个维度，每个维度 3 个度量，则需要对每种维度和度量的组合，撰写一个 SQL 去处理，总计 9 个预处理 SQL，Pingback 表和度量表被 JOIN 了 9 次，并且数量随着分析的增加还会继续膨胀。
而 Kylin 会将事实表和维度表处理成大宽表，后续的计算复用大宽表，从而 JOIN 的数量从 9 降低至 1，计算耗时、成本均大幅降低。此外 Kylin 还大幅降低需求变更的难度，原先增加一个维度/度量，需要改多个脚本，几天的开发量；现在只需在页面上调整，做一下测试，然后重新构建一下即可，小时内即可完成。除此之外，Kylin 还提供精确去重的功能，原先业务是自己在脚本里实现，依赖于脚本书写的好坏，Kylin 提供了一个标准、精确的实现，对业务去重的精度也有提升。
独立 HBase 集群
爱奇艺 Kylin Cube 的量级比较大，早期，我们按照社区的标准部署模式，也就是复用现有公共集群的 HBase，面临了种种挑战。
混布模式下，每一个 Hadoop 集群都有 HBase 服务，Kylin 把预处理的结果加载到本集群 HBase。这个模式有两个痛点：
稳定性差
HBase 集群上还有其他业务，若其他业务读写压力较大，Kylin 查询会受影响；反过来 Kylin 大量查询时，也会对其他业务产生影响。当有很多个 HBase 集群时，任意 HBase 不稳定都有部分 Kylin 业务受影响；
资源浪费
并非所有部署了 Hive 服务的集群都有 HBase，想在该集群使用 Kylin 还需在集群上部署 HBase 服务。
我们参考社区的建议，采用了独立 HBase 集群的部署模式。即 Kylin 还是从 Hive 集群读取数据，构建 Cube，最终结果跨集群加载到 Kylin 专用 HBase 集群。这个方案需要配置一下跨集群作业，参照社区的案例也不复杂；除了解决以上两个痛点，还有一个额外的好处，就是该方案能对独立 HBase 做针对性优化。因为 Kylin 专用 HBase 集群没有写入，而是通过 Bulkload 加载，故可针对读进行优化。如把内存绝大部分用于读缓存、读写线程池也偏向于读、采用固定分裂策略，Cube 表不存在分裂或合并。
采用独立 HBase 部署模式后效果明显。稳定性上，查询不可用时间相比于混布 HBase 降低至 25%。查询速度上，平均下来有 30% 的提升。
Kylin 服务平台
Kylin 服务平台定位是统一收集、存储各集群的信息，包括元信息、任务、查询，用于诊断和优化。
Kylin 自身也具备一定排障能力，比如通过 Web UI 查看 Cube 大小、失败任务等，但其信息是割裂的，部署几十个实例后，不可能每天打开几十个 Web 逐一分析。故此我们决定开发 Kylin 服务平台，其架构如下图所示：
基本思想是把需要的信息采集起来，统一存储，提供 API 和统一的 Web 界面，并开发智能诊断的逻辑，包括 Cube 膨胀率过大、Job 失败过多、查询变慢等等。
Cube 生命周期管理
用户平台的一个落地场景是 Cube 生命周期管理。如果不做管理，Kylin 对 HBase 的压力是很大的，包括表数量、Region 数量、超大 Cube，轻易即可压垮 HBase 集群。原先都是集群异常后，我们再手动分析 Region 来源，推动业务优化。现在通过用户平台的诊断，很容易分析出常见的不合理场景：Cube 未配置 TTL、未配置 Merge 策略、膨胀率过高、Cube 过大等等。平台也可基于历史的查询分析，判断出多久的数据不被访问，自动给出 TTL 的建议值。下图为诊断的效果图：
任务智能诊断
用户平台另一个落地是任务智能诊断。之前，业务构建任务失败后通过 Kylin Web 能看到如下图所示的失败信息，但分析师很难理解错误的含义，只能提交一个运维工单，由 Kylin 运维人员进行修复。这个过程对双方都很痛苦：分析师的错误响应很慢，而运维人员则需要处理大量的工单。
为此，我们开发了任务智能诊断模块。我们总结了 18 种常见的错误，每一种错误都给出易于理解的原因，修复意见，并附有手册详细描述。平台会采集任务的失败信息，和常见的错误进行匹配，下图是一个错误在平台上看到的效果。用户能基于诊断结果进行自助排障。
参数优化
1. Hive 构建全局字典
在 Kylin 3.0 中引入，之前版本中构建全局字典是通过一个单线程完成，往往会成为 Cube 构建的瓶颈。下图是优化后的效果，可以看到构建时间缩短至之前 1/3。
2. 高基数维度构建字典并发配置
即 Kylin 可以指定一个列是高基数维度，并指定其构建字典的并发度（kylin.engine.mr.uhc-reducer-count=5）。例如 Hive 表有 9 个维度列，其中 8 个基数小，1个基数大，则构建字典任务的 9 个 Reducer 会有一个特别慢。使用上述配置高基数维度会以 5 并发构建，有效地缩短了时间。
4. 未来展望
后续，我们计划朝以下几个方面发展：
1. 自动构建 Cube
当前落地的业务场景都是强需求，Cube 构建是业务主动来做。后续希望能够分析现有的 Hive 查询，自动发现内聚度高的表，构建 Cube 并代替掉原有的查询；
2. 集群化
当前每个业务一个实例，稍微有一些大查询就会引起性能波动。若给每个业务部署多个实例，则平时利用率又非常低。通过集群化部署的模式，每个用户都能用到全部的实例，稳定性会大幅提升；
3. 平台化
平台化也会继续深入，降低业务构建 Cube 的代价。通过平台来托管，业务无需自行管理 Cube 的构建。