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，分析首页过去一天的展示次数。
代码语言：javascript复制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 的构建。
