众所周知,爱奇艺拥有海量视频,在视频生产过程中产生的上千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千万后