支持频繁更新、即席查询：ClickHouse在爱奇艺视频生产的应用

众所周知，爱奇艺拥有海量视频，在视频生产过程中产生的上千QPS的实时数据、T级别的数据存储。要支持这样的数据进行即席查询和多个大表的JOIN，是爱奇艺视频生产团队大数据应用的难点。

具体来说有以下几点：

1)实时性的要求，需要实时的解决方案。

2)生产数据更新频繁，OLAP 需支持更新。

3)生产需要大表 Join 方案。码流属性（亿级，百G）和节目属性（亿级，百G）经常放在一起做分析。

 

此外，爱奇艺视频生产数据还有一个特点，数据来源于OLTP 数据中台，其数据持久化在 Mongo，消息变动写入 Kafka， Kafka中：curData 是当前更新数据，oriData是历史为变动数据，这样的结构化数据为配置化开发提供了可能。

爱奇艺视频生产团队负责爱奇艺的视频生产，涵盖“素材、成片、运营流、图片”各个方面，并围绕生产进行了中台化建设、监控建设、数据报表建设等，旨在为视频生产提效，节省编辑精力，更快更好的产出优质视频。

针对以上痛点，爱奇艺视频生产团队进行了一系列努力。本文将详细叙述ClickHouse在爱奇艺视频生产实时数仓的应用：包括业务数据是如何通过 Spark / Spark Streaming 计算引擎处理，并将 HBase 作为维表数据存储，进行实时Join，最终写入ClickHouse，实现即席查询的。

最终的建设成果也比较显著，原本报表开发周期由天级缩短到小时级，满足了频繁更新的实时、离线可 Join 的报表需求。

01

背景及发展历史

选择Spark+ClickHouse实时数仓建设方案，基于爱奇艺视频生产的历史发展阶段及数据特点。

随着各种大数据技术蓬勃发展，爱奇艺视频生产的数据业务经历了两个阶段。

早期阶段一：团队基于公司内部 BabelX 离线数据同步工具，引入 Hive 技术，来做报表开发。

在阶段一中，缺点是每天跑全量数据，成本高，实时性低，修改纬度字段时，整条链路都要修改；ETL 完全依赖 Hive 内置函数，可复用性低，运维成本高。

早期阶段二：随着生产数据增多，Mysql 提供的可视化查询性能遇到瓶颈，且实效性要求提高，数据报表进入了第二阶段，引进 ClickHouse 进行实时报表开发。

在引进clickHouse的过程中，我们也研究了业界如druid、kudu等其他方案，结论是：Druid、kudu在用户视频数少，时间跨度大的情况下，性能表现还不错；当用户视频数超过1千万后