关键词：
众所周知，爱奇艺拥有海量视频，在视频生产过程中产生的上千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千万后，Druid会受聚合影响，速度大幅度降低，甚至会出现超时的情况。最终我们选择了clickHouse，通过它的引擎的选择，我们还支持了频繁的数据更新。
这个阶段其缺点是：不支持连表操作，业务库仅支持 JDBC/ODBC 类型，Merge引擎不支持更新，Mysql导入 ClickHouse再Truncate，期间数据存在丢失。
在此基础上，我们完善系统，最终形成了如下的新的架构体系。
02
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引擎来支持频繁更新呢？
03
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 更简单，且离线和实时数据连接点，不存在异常。缺点是不保证没有重复的数据出现。
接下来介绍下数据的准确性保证。
04
数据准确性保证
离线数据的准确性保证方面，我们主要做了以下两点。
首先是离线重跑数据时，如果 ClickHouse 是 Merge 引擎，重跑时将 Drop 重跑分区。然后是离线全量重跑近 N 天数据，执行 Spark 任务前会先 Truncate 表。
而实时数据的数据准确性保证，首先是 在 Spark 消费 Kafka 时，offset不自动提交，待本次微批数据的所有业务逻辑均处理完成后，再手动提交 offset，以此达到最少一次消费的目的，保证不会丢数据，而 ClickHouse ReplacingMergeTree 引擎写入是幂等的。然后针对 ClickHouse，每间隔 time 时间主动进行 Merge，考虑服务器压力，只 Merge 最近 time * 2 时间段内修改的分区。目前 time 是 5 min。如下图：
自动Merge示意图
到此针对实时数仓的架构细节已经基本讲完了。
05
配置化开发
然而，面对源源而来的报表需求，每个需求花费几天去开发，不仅耗费人力，而且重复的工作也让开发人员无法抽身。考虑到爱艺奇视频生产都是结构化数据，这就为配置化开发提供了可能。
整个过程主要用到了程序参数解析器 - Apache Commons CLI，一款开源的命令行解析工具。它可以帮助开发者快速构建启动命令，并且帮助你组织命令的参数、以及输出列表等。
参数解析器结构图
06
价值与规划
爱奇艺视频生产实时数仓目前的建设方案完成后，我们基本实现了代码 0 开发，原本报表开发周期由天级缩短到小时级。满足频繁更新的实时、离线可 Join 的报表需求。目前已支持 4 个离线报表任务，3 个实时报表任务，其中 1 个离线 Join 需求，1 个实时 Join 需求，后续可能更多。
后续我们会在爱奇艺视频生产平台提供页面化操作，将同步工具产品化，首先与 Hive、HBase、ClickHouse 等打通，自动建表，然后将任务创建、运行、监控状态逻辑通过调度自动化 。通过技术创新去支持和落地新的业务场景，继续推动爱奇艺的数据和产品向着实时化的方向发展。
clickhouse在爱奇艺视频生产实时数仓的应用
众所周知，爱奇艺拥有海量视频，在视频生产过程中产生的上千QPS的实时数据、T级别的数据存储。要支持这样的数据进行即席查询和多个大表的JOIN，是爱奇艺视频生产团队大数据应用的难点。具体来说有以下几点... 查看详情
flink在爱奇艺广告业务的实践
...术经理韩红根在5月22日北京站FlinkMeetup分享的议题《Flink在爱奇艺广告业务的实践》，内容包括：业务场景业务实践Flink使用过程中的问题及解决未来规划一、业务场景实时数据在广告业务的使用场景主要可以分为四个方... 查看详情
flink在爱奇艺广告业务的实践
...术经理韩红根在5月22日北京站FlinkMeetup分享的议题《Flink在爱奇艺广告业务的实践》，内容包括：业务场景业务实践Flink使用过程中的问题及解决未来规划一、业务场景实时数据在广告业务的使用场景主要可以分为四个方... 查看详情
flink在爱奇艺广告业务的实践
...术经理韩红根在5月22日北京站FlinkMeetup分享的议题《Flink在爱奇艺广告业务的实践》，内容包括：业务场景业务实践Flink使用过程中的问题及解决未来规划GitHub地址https://github.com/apache/flink欢迎大家给Flink点赞送star~一、 查看详情
数仓系列第11篇:实时数仓
...仓库的发展3.数据仓库建设方法论4.数据仓库架构的演变5.实时数仓案例6.实时数仓与离线数仓的对比导读：本文将从数据仓库的简介、经历了怎样的发展、如何建设、架构演变、应用案例以及实时数仓与离线数仓的对比六个... 查看详情
datafuntalk：阿里建设一站式实时数仓的经验分享
导读：大数据计算正从规模化走向实时化，实时大数据建设过程中开始面临很多的痛点和问题。本文内容整理于阿里资深技术专家姜伟华在DataFunTalk上的演讲，为大家介绍阿里巴巴基于一站式实时数仓Hologres建设实时... 查看详情
爱奇艺数据中台建设方案
...生：数据工作的痛点、数据中台的产生、中台的实质爱奇艺数据中台的定义：理解数据中台、数据中台的发展历程、输出和定位爱奇艺数据中台的建设：中台建设、Pingback体系、数仓体系、数仓平台、离线数仓架构、... 查看详情
实时数仓在有赞的实践(代码片段)
前言随着实时技术的不断发展和商家实时应用场景的不断丰富，有赞在实时数仓建设方面做了大量的尝试和实践。本文主要分享有赞在建设实时数仓过程中所沉淀的经验，内容包括以下五个部分：建设背景应用场景方... 查看详情
从阿里核心场景看实时数仓的发展趋势
简介：随着2021年双11的完美落幕，实时数仓技术在阿里双11场景也经历了多年的实践和发展。从早期的基于不同作业的烟囱式开发，到基于领域分层建模的数仓引入，再到分析服务一体化的新型融合式一站式架构&#... 查看详情
clickhouse微信基于clickhouse的实时数仓
...1日过年了过年了发几个博客庆祝一下。1.概述直播回放：ClickHouseOnlineSummerMeetupChina20222、背景数据分析场景2.Hadoop数仓下的困境视频号等推荐系统的对个性化体验强烈诉求，催生了“亚秒级”分析系统的诞生设计目标:亚秒级响应:... 查看详情
flink在顺丰的应用实践
简介： 顺丰基于Flink建设实时数仓的思路，引入HudiOnFlink加速数仓宽表，以及实时数仓平台化建设的实践。本⽂由社区志愿者苗文婷整理，内容源⾃顺丰科技大数据平台研发工程师龙逸尘在FlinkForwardAsia2020分享的... 查看详情
数仓系列第11篇:实时数仓
...仓库的发展3.数据仓库建设方法论4.数据仓库架构的演变5.实时数仓案例6.实时数仓与离线数仓的对比导读：本文将从数据仓库的简介、经历了怎样的发展、如何建设、架构演变、应用案例以及实时数仓与离线数仓的对比六个... 查看详情
基于flink构建企业级实时数仓（附项目源码）
...景，要把链路延时降低到秒级，就需要基于Flink的实时数仓出马了。企业级实时数仓的应用场景很多，比如：实时OLAP分析；实时数据看板；实时业务监控；实时数据接口服务。很多公司实时数仓的 查看详情
各厂实时数仓案例大全(代码片段)
目录前言：一、实时数仓建设目的二、实时数仓建设方案1.滴滴顺风车实时数仓案例2.快手实时数仓场景化案例3.腾讯看点实时数仓案例4.有赞实时数仓案例前言：实时需求日趋迫切目前各大公司的产品需求和内部决策对于... 查看详情
如何刷爱奇艺vip 爱奇艺vip免费领取爱奇艺vip怎么刷
参考技术A在爱奇艺和PPS合并之后，受关注度越来越高，身边也有很多朋友都开始在爱奇艺上面看电影、电视剧了。但是片头的广告也是比较多的，今天就给大家说下如何免费刷爱奇艺的VIP吧，这个既能跳过片头的广告，又能看... 查看详情
bigo使用flink做olap分析及实时数仓的实践和优化(代码片段)
cnt1,cnt2cntxtable_auid更多Flink相关技术问题，可扫码加入社区钉钉交流群～ 戳我，查看原文视频&演讲PDF～ 查看详情
基于seatunnel连通hive数仓和clickhouse的实战(代码片段)
...进行分析等，Presto不能满足需求，在这个阶段我们引入了ClickHouse，用来建设性能更强悍，响应时间更短的数据分析平台，以满足实时性要求，但如何连通Hive数仓和ClickHouse呢？没错，当然是Seatunnel啦！官方推荐的 查看详情
基于flink构建实时数仓实践
...会员、游戏等非常多的业务板块。与此同时产品及运营对实时数据需求逐渐增多，帮助他们更快的做出决策，更好的进行产品迭代，实时数仓的建设变得越发重要起来。本文主要介绍用户增长业务基于Flink构建实时数... 查看详情