11 月 19 - 20 日 Apache Pulsar 社区年度盛会来啦,立即报名! 了解详情
写点什么

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

  • 2021-04-19
  • 本文字数:3703 字

    阅读完需:约 12 分钟

支持频繁更新、即席查询: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 的报表需求。

背景及发展历史

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

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


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

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


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


在引进 clickHouse 的过程中,我们也研究了业界如 druid、kudu 等其他方案,结论是:Druid、kudu 在用户视频数少,时间跨度大的情况下,性能表现还不错;当用户视频数超过 1 千万后,Druid 会受聚合影响,速度大幅度降低,甚至会出现超时的情况。最终我们选择了 clickHouse,通过它的引擎的选择,我们还支持了频繁的数据更新。

这个阶段其缺点是:不支持连表操作,业务库仅支持 JDBC/ODBC 类型,Merge 引擎不支持更新,Mysql 导入 ClickHouse 再 Truncate,期间数据存在丢失。

在此基础上,我们完善系统,最终形成了如下的新的架构体系。

Spark+ClickHouse 实时数仓

话不多说,先上架构图

整体结构


ClickHouse 是面向列的数据库管理系统(DBMS),用于对查询进行联机分析处理(OLAP)。由俄罗斯 IT 公司 Yandex 为 Yandex.Metrica 网络分析服务开发的。允许分析实时更新的数据,该系统以高性能为目标,且储存明细数据。


Spark 是用于大规模数据处理的统一分析引擎,高效的支撑更多计算模式,包括交互式查询和流处理。一个主要特点是能够在内存中进行计算,即使依赖磁盘进行复杂的运算,Spark 依然比 MapReduce 更加高效。Spark Streaming 是核心 Spark API 的扩展,可实现实时数据流的可伸缩,高吞吐量,容错流处理。其基于微批,和其他基于“一次处理一条记录” 架构的系统相比, 它的延迟会相对高一些,但是吞吐量也会有一定优势。而批量插入 ClickHouse,又是 ClickHouse 所推崇的。


结合 Spark/Spark Streaming 与 ClickHouse 的特性,这一方案优势也就显而易见了:

ClickHouse 支持更新且速度极快;Spark Streaming 微批,更适合写入 clickHouse。

具体建设过程主要分为三个部分。

离线数据加工

首先通过 Spark 计算引擎,将 mongo 数据例行全量导入 Hive(担心业务库稳定性)。然后通过 Spark 计算引擎, 将 Hive 数据例行进行 ETL 处理,并离线导入 ClickHouse。

实时数据加工

历史存量数据的处理是通过 Spark 计算引擎,将 Mongo 数据写入 ClickHouse(只执行一次,可以直接从业务库导。因为例行导入 Hive 表本身就是我们在做)。实时数据的处理就是 Spark 技术引擎直接处理 Kafka 消息写入 ClickHouse 了。如果不需要历史存量数据,只需要消费 Kafka,实时计算导入 ClickHouse 就可以了。具体实时架构如下:

实时方案流程图


这里离线数据和实时数据连接点需要注意一下:ReplacingMergeTree 引擎由于幂等性质,可将 Kafka offset 向前多重置一些,保证最少一次。其他引擎存在误差数据。除非 Kafka 能够重放 Mongo 中历史所有数据。

Join 需求

存在 Join 需求时,由于两个表目前都是百 G 的存储,使用 Redis、CB 内存太浪费,我们最终选择了使用 HBase。以 HBase 作为纬度表,在 Spark 计算引擎中,进行合并处理,并写入事实表。


大表 Join 方案流程图


除了以上工作,这里有一些注意事项:

1. 实时导入 ClickHouse,维表数据必须早于事实表产生。

2. 增量离线同步或者实时同步 ClickHouse 时,需保证 维表数据基本不变 或者 维表数据变化后,实时、离线增量数据也会发生变化。

3. 否则维表变化不会在 ClickHouse 输出表中体现。

看到这里,整体架构已经很清晰了。那么如何选择 ClickHouse 引擎来支持频繁更新呢?

ClickHouse 支持频繁更新

针对频繁更新请求,ClickHouse 可以选择 ReplacingMergeTree 和 VersionedCollapsingMergeTree 引擎:


ReplacingMergeTree(覆盖更新)

以 id 作为主键,会删除相同的重复项。

不保证没有重复的数据出现。


VersionedCollapsingMergeTree(折叠更新)

在数据块合并算法中添加了折叠行逻辑。


针对离线数据,有两种选择方案。


方案一是用 ReplacingMergeTree 引擎的增量同步方案:先用 Spark 计算引擎将 Mongo 数据例行同步到 Hive,再用 Spark 计算引擎消费 Hive 增量数据写入 ClickHouse。其优点是增量同步,压力小。缺点是 Join 时,增量离线同步,需保证 维表数据基本不变 或者 维表数据变化后,实时表数据也会发生变化。否则维表变化不会再事实表中体现。


方案二是用 MergeTree 引擎的全量同步方案:先用 Spark 计算引擎将 Mongo 数据定时同步到 Hive,然后 Truncate ClickHouse 表,最后使用 Spark 消费 Hive 近 N 天数据写入 ClickHouse。其优点是可解决方案一 Join 时问题。缺点是全量同步,仅保存近 N 天数据,压力大。

针对实时数据,也有两种选择方案。


方案一是用 VersionedCollapsingMergeTree 引擎的增量同步方案:先用 Spark 计算引擎将 Mongo 存量数据一次性同步到 ClickHouse,再重置 Kafka 消费位置,将实时数据同步到 ClickHouse。其优点是即使有重复数据,也可使用变种 SQL 避免数据误差。缺点是实时数据强依赖 OLTP 数据中台 提供的 Kafka 消息(oriData、currData)准确性,且离线和实时数据连接点,存在无法折叠现象。


方案二是用 ReplacingMergeTree 引擎的增量同步方案:先用 Spark 计算引擎将 Mongo 存量数据一次性同步到 ClickHouse,再重置 Kafka 消费位置,将实时数据同步到 ClickHouse ReplacingMergeTree。其优点是相比与 VersionedCollapsingMergeTree 更简单,且离线和实时数据连接点,不存在异常。缺点是不保证没有重复的数据出现。


接下来介绍下数据的准确性保证。

数据准确性保证

离线数据的准确性保证方面,我们主要做了以下两点。


首先是离线重跑数据时,如果 ClickHouse 是 Merge 引擎,重跑时将 Drop 重跑分区。然后是离线全量重跑近 N 天数据,执行 Spark 任务前会先 Truncate 表。


而实时数据的数据准确性保证,首先是 在 Spark 消费 Kafka 时,offset 不自动提交,待本次微批数据的所有业务逻辑均处理完成后,再手动提交 offset,以此达到最少一次消费的目的,保证不会丢数据,而 ClickHouse ReplacingMergeTree 引擎写入是幂等的。然后针对 ClickHouse,每间隔 time 时间主动进行 Merge,考虑服务器压力,只 Merge 最近 time * 2 时间段内修改的分区。目前 time 是 5 min。如下图:

自动 Merge 示意图


到此针对实时数仓的架构细节已经基本讲完了。

配置化开发 

然而,面对源源而来的报表需求,每个需求花费几天去开发,不仅耗费人力,而且重复的工作也让开发人员无法抽身。考虑到爱艺奇视频生产都是结构化数据,这就为配置化开发提供了可能。


整个过程主要用到了程序参数解析器 - Apache Commons CLI,一款开源的命令行解析工具。它可以帮助开发者快速构建启动命令,并且帮助你组织命令的参数、以及输出列表等。


参数解析器结构图

价值与规划

爱奇艺视频生产实时数仓目前的建设方案完成后,我们基本实现了代码 0 开发,原本报表开发周期由天级缩短到小时级。满足频繁更新的实时、离线可 Join 的报表需求。目前已支持 4 个离线报表任务,3 个实时报表任务,其中 1 个离线 Join 需求,1 个实时 Join 需求,后续可能更多。


后续我们会在爱奇艺视频生产平台提供页面化操作,将同步工具产品化,首先与 Hive、HBase、ClickHouse 等打通,自动建表,然后将任务创建、运行、监控状态逻辑通过调度自动化 。通过技术创新去支持和落地新的业务场景,继续推动爱奇艺的数据和产品向着实时化的方向发展。


本文转载自:爱奇艺技术产品团队(ID:iQIYI-TP)

原文链接:支持频繁更新、即席查询:ClickHouse在爱奇艺视频生产的应用

2021-04-19 14:003287

评论 1 条评论

发布
用户头像
2021-04-25 16:32
回复
没有更多了
发现更多内容

架构方法论之“极限审视法”

凌晞

架构 方法论 设计思维

高难度对话读书笔记——目的篇

wo是一棵草

2020南京国际工业互联网及工业通讯展览会

InfoQ_caf7dbb9aa8a

技术革新的脉络及趋势

凌晞

技术 进步

我就不服了,看完这篇文章,5大常见消息队列开发你还学不会

小Q

Java 编程 程序员 开发 消息队列

MySQL-技术专题-Join语法以及性能优化

洛神灬殇

万万没想到!ModelArts与AppCube组CP了

华为云开发者联盟

AI 技术 华为云

2020第十三届南京国际大数据产业博览会

InfoQ_caf7dbb9aa8a

Java 客户端操作 FastDFS 实现文件上传下载替换删除

哈喽沃德先生

Java 文件系统 分布式文件存储 fastdfs 文件服务器

架构师训练营第一期 - 第四周课后 - 作业二

极客大学架构师训练营

“三段三域法”应用架构模型

凌晞

架构 架构设计 技术架构

SpringBoot 实战:如何优雅的处理异常

看山

springboot 实战 优雅响应

创新者谈

善宝橘

创新

什么是 Kubeless?| 玩转 Kubeless

donghui

Kubernetes kubeless

轻言业务架构图

凌晞

架构 企业架构 架构设计 架构设计原则 业务架构

手把手教你锤面试官 04——假装精通redis

慵懒的土拨鼠

MySQL-技术专题-实战技巧

洛神灬殇

第3周学习总结

饭桶

2020第十三届南京国际智慧停车展览会

InfoQ_caf7dbb9aa8a

2020南京国际人工智能产品展览会

InfoQ_caf7dbb9aa8a

人工智能

从戚家军看组织战斗力塑造(组织的六脉神剑)

凌晞

组织

Redis-技术专题-数据结构

洛神灬殇

深圳派发数字人民币红包!个人数字人民币钱包即将亮相

CECBC

数字货币 数字人民币

晨间日记的奇迹

熊斌

读书笔记

MySQL-技术专题-SQL性能分析

洛神灬殇

转型敏捷123

研发管理Jojo

PanDownload复活了!60MB/s!附下载地址

程序员生活志

PanDownload 网盘 下载器

2020第十三届南京国际智慧工地装备展览会

InfoQ_caf7dbb9aa8a

SpringBoot-技术专题-@Async异步注解

洛神灬殇

技术解码 | 玩转视频播放,自适应码流技术

腾讯云音视频

音视频 转码

第3周作业提交

饭桶

支持频繁更新、即席查询:ClickHouse在爱奇艺视频生产的应用_大数据_爱奇艺技术产品团队_InfoQ精选文章