当业务倒退到肯定规模，实时数据仓库是一个必要的根底服务。从数据驱动方面思考，多维实时数据分析系统的重要性也显而易见。然而当数据量微小的状况下，拿腾讯看点来说，一天上报的数据量达到万亿级的规模，要实现极低提早的实时计算和亚秒级的多维实时查问是有技术挑战的。

本文将介绍信息流场景下，腾讯看点的实时数据仓库和多维实时数据分析系统的技术架构。

1、可解决的痛点

能够先看一下，多维实时数据分析系统能够解决哪些痛点。比方：

• 举荐同学 10 分钟前上了一个举荐策略，想晓得在不同人群的举荐成果怎么样？
• 经营同学想晓得，在广东省的用户中，最火的广东地区内容是哪些，不便做地区 Push。
• 审核同学想晓得，过来 5 分钟，游戏类被举报最多的内容和账号是哪些？
• 老板可能想理解，过来 10 分钟有多少用户在看点生产了内容，对生产人群有一个宏观理解。

2、调研

在进行开发之前，咱们做了这些调研。

1. 离线数据分析平台是否满足这些需要，论断是不能满足。离线数据分析平台不行的起因如下。

• C 侧数据上报过去，须要通过 Spark 的多层离线计算，最终后果出库到 MySQL 或者 ES 提供给离线剖析平台查问。这个过程的延时起码 3-6 个小时，目前比拟常见的都是提供隔天的查问，所以很多实时性要求高的业务场景都是不能满足的。
• 另一个问题是，腾讯看点的数据量太大，带来的不稳定性也比拟大，常常会有预料不到的提早。所以，离线剖析平台是无奈满足很多需要的。

2. 实时数据分析平台的话，事业群外部提供了准实时数据查问的性能，底层技术用的是 Kudu+Impala，Impala 尽管是 MPP 架构的大数据计算引擎，并且拜访以列式存储数据的 Kudu。然而对于实时数据分析场景来说，查问响应的速度和数据的提早都还是比拟高，查问一次实时 DAU，返回后果耗时至多几分钟，无奈提供良好的交互式用户体验。所以（Kudu+Impala）这种通用大数据处理框架的速度劣势更多的是相比（Spark+Hdfs）这种离线剖析框架来说的，对于咱们这个实时性要求更高的场景，是无奈满足的。

3、我的项目背景

通过方才的介绍，再来看下咱们这个我的项目的背景。作者发文的内容被内容核心引入，通过内容审核链路，启用或者下架。启用的内容给到举荐零碎和经营零碎，而后举荐零碎和经营零碎将内容进行 C 侧散发。内容分发给 C 侧用户之后，用户会产生各种行为，曝光、点击、举报等，通过埋点上报实时接入到音讯队列中。接下来咱们做了两局部工作，就是图中有色彩的这两局部。

• 第一局部构建了一个腾讯看点的实时数据仓库。
• 第二局部就是基于 OLAP 存储引擎，开发了多维实时数据分析系统。

咱们为什么要构建实时数仓，因为原始的上报数据量十分大，一天上报峰值就有上万亿条。而且上报格局凌乱。不足内容维度信息、用户画像信息，上游没方法间接应用。而咱们提供的实时数仓，是依据腾讯看点信息流的业务场景，进行了内容维度的关联，用户画像的关联，各种粒度的聚合，上游能够十分不便的应用实时数据。

4、计划选型

那就看下咱们多维实时数据分析系统的计划选型，选型咱们比照了行业内的当先计划，抉择了最合乎咱们业务场景的计划。

• 第一块是实时数仓的选型，咱们抉择的是业界比拟成熟的 Lambda 架构，他的长处是灵活性高、容错性高、成熟度高和迁徙成本低；毛病是实时、离线数据用两套代码，可能会存在一个口径批改了，另一个没改的问题，咱们每天都有做数据对账的工作，如果有异样会进行告警。
• 第二块是实时计算引擎选型，因为 Flink 设计之初就是为了流解决，SparkStreaming 严格来说还是微批处理，Strom 用的曾经不多了。再看 Flink 具备 Exactly-once 的准确性、轻量级 Checkpoint 容错机制、低延时高吞吐和易用性高的特点，咱们抉择了 Flink 作为实时计算引擎。
• 第三块是实时存储引擎，咱们的要求就是须要有维度索引、反对高并发、预聚合、高性能实时多维 OLAP 查问。能够看到，Hbase、Tdsql 和 ES 都不能满足要求，Druid 有一个缺点，它是依照时序划分 Segment，无奈将同一个内容，寄存在同一个 Segment 上，计算全局 TopN 只能是近似值，所以咱们抉择了最近两年大火的 MPP 数据库引擎 ClickHouse。

5、设计指标与设计难点

咱们多维实时数据分析系统分为三大模块

1. 实时计算引擎
2. 实时存储引擎
3. App 层

难点次要在前两个模块：实时计算引擎和实时存储引擎。

1. 千万级 /s 的海量数据如何实时接入，并且进行极低提早维表关联。
2. 实时存储引擎如何反对高并发写入、高可用分布式和高性能索引查问，是比拟难的。

这几个模块的具体实现，看一下咱们零碎的架构设计。

6、架构设计

前端采纳的是开源组件 Ant Design，利用了 Nginx 服务器，部署动态页面，并反向代理了浏览器的申请到后盾服务器上。

后盾服务是基于腾讯自研的 RPC 后盾服务框架写的，并且会进行一些二级缓存。

实时数仓局部，分为了接入层、实时计算层和实时数仓存储层。

• 接入层次要是从千万级 /s 的原始音讯队列中，拆分出不同行为数据的微队列，拿看点的视频来说，拆分过后，数据就只有百万级 /s 了；
• 实时计算层次要负责，多行行为流水数据进行行转列，实时关联用户画像数据和内容维度数据；
• 实时数仓存储层次要是设计出合乎看点业务的，上游好用的实时音讯队列。咱们临时提供了两个音讯队列，作为实时数仓的两层。一层 DWM 层是内容 ID- 用户 ID 粒度聚合的，就是一条数据蕴含内容 ID- 用户 ID 还有 B 侧内容数据、C 侧用户数据和用户画像数据；另一层是 DWS 层，是内容 ID 粒度聚合的，一条数据蕴含内容 ID，B 侧数据和 C 侧数据。能够看到内容 ID- 用户 ID 粒度的音讯队列流量进一步减小到十万级 /s，内容 ID 粒度的更是万级 /s，并且格局更加清晰，维度信息更加丰盛。

实时存储局部分为实时写入层、OLAP 存储层和后盾接口层。

• 实时写入层次要是负责 Hash 路由将数据写入；
• OLAP 存储层利用 MPP 存储引擎，设计合乎业务的索引和物化视图，高效存储海量数据；
• 后盾接口层提供高效的多维实时查问接口。

7、实时计算

这个零碎最简单的两块，实时计算和实时存储。

先介绍实时计算局部：分为实时关联和实时数仓。

7.1 实时高性能维表关联

实时维表关联这一块难度在于。百万级 / s 的实时数据流，如果间接去关联 HBase，1 分钟的数据，关联完 HBase 耗时是小时级的，会导致数据提早重大。

咱们提出了几个解决方案：

• 第一个是，在 Flink 实时计算环节，先依照 1 分钟进行了窗口聚合，将窗口内多行行为数据转一行多列的数据格式，通过这一步操作，本来小时级的关联耗时降落到了十几分钟，然而还是不够的。
• 第二个是，在拜访 HBase 内容之前设置一层 Redis 缓存，因为 1000 条数据拜访 HBase 是秒级的，而拜访 Redis 是毫秒级的，拜访 Redis 的速度根本是拜访 HBase 的 1000 倍。为了避免过期的数据节约缓存，缓存过期工夫设置成 24 小时，同时通过监听写 HBase Proxy 来保障缓存的一致性。这样将拜访工夫从十几分钟变成了秒级。
• 第三个是，上报过程中会上报不少非常规内容 ID，这些内容 ID 在内容 HBase 中是不存储的，会造成缓存穿透的问题。所以在实时计算的时候，咱们间接过滤掉这些内容 ID，避免缓存穿透，又缩小一些工夫。
• 第四个是，因为设置了定时缓存，会引入一个缓存雪崩的问题。为了避免雪崩，咱们在实时计算中，进行了削峰填谷的操作，错开设置缓存的工夫。

能够看到，优化前后，数据量从百亿级缩小到了十亿级，耗时从小时级缩小到了数十秒，缩小 99%。

7.2 上游提供服务

实时数仓的难度在于：它处于比拟新的畛域，并且各个公司各个业务差距比拟大，怎么能设计出不便，好用，合乎看点业务场景的实时数仓是有难度的。

先看一下实时数仓做了什么，实时数仓对外就是几个音讯队列，不同的音讯队列外面寄存的就是不同聚合粒度的实时数据，包含内容 ID、用户 ID、C 侧行为数据、B 侧内容维度数据和用户画像数据等。

咱们是怎么搭建实时数仓的，就是下面介绍的实时计算引擎的输入，放到音讯队列中保留，能够提供给上游多用户复用。

咱们能够看下，在咱们建设实时数据仓库前后，开发一个实时利用的区别。没有数仓的时候，咱们须要生产千万级 /s 的原始队列，进行简单的数据荡涤，而后再进行用户画像关联、内容维度关联，能力拿到符合要求格局的实时数据，开发和扩大的老本都会比拟高，如果想开发一个新的利用，又要走一遍这个流程。有了数仓之后，如果想开发内容 ID 粒度的实时利用，就间接申请 TPS 万级 /s 的 DWS 层的音讯队列。开发成本变低很多，资源耗费小很多，可扩展性也强很多。

看个理论例子，开发咱们零碎的实时数据大屏，本来须要进行如上所有操作，能力拿到数据。当初只须要生产 DWS 层音讯队列，写一条 Flink SQL 即可，仅耗费 2 个 CPU 外围，1G 内存。

能够看到，以 50 个消费者为例，建设实时数仓前后，上游开发一个实时利用，能够缩小 98% 的资源耗费。包含计算资源，存储资源，人力老本和开发人员学习接入老本等等。并且消费者越多，节俭越多。就拿 Redis 存储这一部分来说，一个月就能省下上百万人民币。

8、实时存储

介绍完实时计算，再来介绍实时存储。

这块分为三个局部来介绍

• 第一是 分布式 - 高可用
• 第二是 海量数据 - 写入
• 第三是 高性能 - 查问

8.1 分布式 - 高可用

咱们这里听取的是 Clickhouse 官网的倡议，借助 ZK 实现高可用的计划。数据写入一个分片，仅写入一个正本，而后再写 ZK，通过 ZK 通知同一个分片的其余正本，其余正本再过去拉取数据，保证数据一致性。

这里没有选用音讯队列进行数据同步，是因为 ZK 更加轻量级。而且写的时候，任意写一个正本，其它正本都可能通过 ZK 取得统一的数据。而且就算其它节点第一次来获取数据失败了，前面只有发现它跟 ZK 上记录的数据不统一，就会再次尝试获取数据，保障一致性。

8.2 海量数据 - 写入

数据写入遇到的第一个问题是，海量数据间接写入 Clickhouse 的话，会导致 ZK 的 QPS 太高，解决方案是改用 Batch 形式写入。Batch 设置多大呢，Batch 太小的话缓解不了 ZK 的压力，Batch 也不能太大，不然上游内存压力太大，通过试验，最终咱们选用了大小几十万的 Batch。

第二个问题是，随着数据量的增长，单 QQ 看点的视频内容每天可能写入百亿级的数据，默认计划是写一张分布式表，这就会造成单台机器呈现磁盘的瓶颈，尤其是 Clickhouse 底层使用的是 Mergetree，原理相似于 HBase、RocketsDB 的底层 LSM-Tree。在合并的过程中会存在写放大的问题，减轻磁盘压力。峰值每分钟几千万条数据，写完耗时几十秒，如果正在做 Merge，就会阻塞写入申请，查问也会十分慢。咱们做的两个优化计划：一是对磁盘做 Raid，晋升磁盘的 IO；二是在写入之前进行分表，间接离开写入到不同的分片上，磁盘压力间接变为 1/N。

第三个问题是，尽管咱们写入依照分片进行了划分，然而这里引入了一个分布式系统常见的问题，就是部分的 Top 并非全局 Top 的问题。比方同一个内容 ID 的数据落在了不同的分片上，计算全局 Top100 浏览的内容 ID，有一个内容 ID 在分片 1 上是 Top100，然而在其它分片上不是 Top100，导致汇总的时候，会失落一部分数据，影响最终后果。咱们做的优化是在写入之前加上一层路由，将同一个内容 ID 的记录，全副路由到同一个分片上，解决了该问题。

介绍完写入，下一步介绍 Clickhouse 的高性能存储和查问。

8.3 高性能 - 存储 - 查问

Clickhouse 高性能查问的一个关键点是稠密索引。稠密索引这个设计就很有考究，设计得好能够减速查问，设计不好反而会影响查问效率。我依据咱们的业务场景，因为咱们的查问大部分都是工夫和内容 ID 相干的，比如说，某个内容，过来 N 分钟在各个人群体现如何？我依照日期，分钟粒度工夫和内容 ID 建设了稠密索引。针对某个内容的查问，建设稠密索引之后，能够缩小 99% 的文件扫描。

还有一个问题就是，咱们当初数据量太大，维度太多。拿 QQ 看点的视频内容来说，一天流水有上百亿条，有些维度有几百个类别。如果一次性把所有维度进行预聚合，数据量会指数收缩，查问反而变慢，并且会占用大量内存空间。咱们的优化，针对不同的维度，建设对应的预聚合物化视图，用空间换工夫，这样能够缩短查问的工夫。

分布式表查问还会有一个问题，查问单个内容 ID 的信息，分布式表会将查问下发到所有的分片上，而后再返回查问后果进行汇总。实际上，因为做过路由，一个内容 ID 只存在于一个分片上，剩下的分片都在空跑。针对这类查问，咱们的优化是后盾依照同样的规定先进行路由，间接查问指标分片，这样缩小了 N-1/N 的负载，能够大量缩短查问工夫。而且因为咱们是提供的 OLAP 查问，数据满足最终一致性即可，通过主从正本读写拆散，能够进一步晋升性能。

咱们在后盾还做了一个 1 分钟的数据缓存，针对雷同条件查问，后盾就间接返回了。

8.4 扩容

这里再介绍一下咱们的扩容的计划，调研了业内的一些常见计划。

比方 HBase，原始数据都寄存在 HDFS 上，扩容只是 Region Server 扩容，不波及原始数据的迁徙。然而 Clickhouse 的每个分片数据都是在本地，是一个比拟底层存储引擎，不能像 HBase 那样不便扩容。

Redis 是哈希槽这种相似一致性哈希的形式，是比拟经典分布式缓存的计划。Redis slot 在 Rehash 的过程中尽管存在短暂的 ask 读不可用，然而总体来说迁徙是比拟不便的，从原 h[0] 迁徙到 h[1]，最初再删除 h[0]。然而 Clickhouse 大部分都是 OLAP 批量查问，不是点查，而且因为列式存储，不反对删除的个性，一致性哈希的计划不是很适宜。

目前扩容的计划是，另外生产一份数据，写入新 Clickhouse 集群，两个集群一起跑一段时间，因为实时数据就保留 3 天，等 3 天之后，后盾服务间接拜访新集群。

9、成绩

腾讯看点实时数据仓库：DWM 层和 DWS 层，数据提早 1 分钟。

远见多维实时数据分析系统：亚秒级响应多维条件查问申请，在未命中缓存状况下，过来 30 分钟的查问，99% 的申请耗时在 1 秒内；过来 24 小时的查问，90% 的申请耗时在 5 秒内，99% 的申请耗时在 10 秒内。