【PPT 下载】最佳实践|爱奇艺如何处理千亿级数据

Author
林豪
爱奇艺大数据服务 OLAP 组负责人
2020年 8月 10日

在「718 Apache Kylin Meetup」直播上,爱奇艺的资深研发工程师林豪为大家带来了精彩的分享:他介绍了爱奇艺使用 Kylin 代替传统的 Hive + MySQL 模式,在爱奇艺 BI、推荐等 20+ 个业务场景的应用、具体落地效果,遇到的坑和一些优化经验,以及未来的计划,比如简化 Cube 调整难度等。

以下是 Meetup 回顾,需要 PPT 的同学可以点击此链接获取~


使用 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 会有较多的重复计算,通常优化的不是特别好,在资源上也是有很大的浪费。


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 秒,能够较好地满足需求。


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 种常见的错误,每一种错误都给出易于理解的原因,修复意见,并附有手册详细描述。平台会采集任务的失败信息,和常见的错误进行匹配,下图是一个错误在平台上看到的效果。用户能基于诊断结果进行自助排障。


参数优化
Hive 构建全局字典

在 Kylin 3.0 中引入,之前版本中构建全局字典是通过一个单线程完成,往往会成为 Cube 构建的瓶颈。下图是优化后的效果,可以看到构建时间缩短至之前 1/3。


高基数维度构建字典并发配置

即 Kylin 可以指定一个列是高基数维度,并指定其构建字典的并发度(kylin.engine.mr.uhc-reducer-count=5)。例如 Hive 表有 9 个维度列,其中 8 个基数小,1个基数大,则构建字典任务的 9 个 Reducer 会有一个特别慢。使用上述配置高基数维度会以 5 并发构建,有效地缩短了时间。


未来展望

后续,我们计划朝以下几个方面发展:

1. 自动构建 Cube

当前落地的业务场景都是强需求,Cube 构建是业务主动来做。后续希望能够分析现有的 Hive 查询,自动发现内聚度高的表,构建 Cube 并代替掉原有的查询;

2. 集群化

当前每个业务一个实例,稍微有一些大查询就会引起性能波动。若给每个业务部署多个实例,则平时利用率又非常低。通过集群化部署的模式,每个用户都能用到全部的实例,稳定性会大幅提升;

3. 平台化

平台化也会继续深入,降低业务构建 Cube 的代价。通过平台来托管,业务无需自行管理 Cube 的构建。




关于作者

林豪,爱奇艺资深研发工程师,任大数据服务 OLAP 组负责人,自 2016 年起推进公司内 OLAP 技术架构升级。



想第一时间获得 Apache Kylin 资讯,请扫二维码,关注 Apache Kylin 官方微信公众号。