全渠道运营腾讯看点王展雄：实时数仓与多维实时分析系统搭建

 

 

近几年，数字驱动的口号越喊越响，在这样一个用数据说话的时代，数据在一定程度上决定企业的业务和决策。而从数据驱动的方面考虑，多维实时数据分析系统的重要性也不言而喻。但是当数据量巨大的情况下，企业对数据技术也提出了更高的要求，但是要实现极低延迟的实时计算和亚秒级的多维实时查询还是有难度的。

 

以腾讯看点来说，一天上报的数据量达到万亿级的规模，企业要如何知道在不同人群的推荐效果怎么样？在不同地域中最火的内容分别是什么？被举报最多的内容和账号是哪些？在某个时间段内有多少用户消费了内容？

 

以下内容根据其演讲整理：

 

 

<>01调研

在分享一开始，王展雄首先总结了多维实时数据分析系统可以解决的主要痛点问题，比如：

 

推荐同学10分钟前上了一个推荐策略，想知道在不同人群的推荐效果怎么样？

运营同学想知道，在广东省的用户中，最火的广东地域内容是哪些？

审核同学想知道，过去5分钟，游戏类被举报最多的内容和账号是哪些？

老板可能想了解，过去10分钟有多少用户在看点消费了内容？

 

腾讯看点在实时数仓与多维实时分析系统搭建之前，首先做的就是进行调研，即离线数据分析平台能否解决以上这些需求？结论是不能。

 

首先，C端的行为数据上报过来需要经过Spark多层离线计算，把最终结果初步过ES，初步之后再提供离线数据平台进行查询。这个过程延时最少在3-6小时，目前最常见的就是隔天的查询。加之腾讯看点的数据量大，稳定性较弱，离线分析平台难以满足多样化的需求。

 

此外，企业内部现有的准实时数据查询平台的底层技术用的是Kudu+Impala，Impala虽然是MPP架构的大数据计算引擎，并且访问以列式存储数据的Kudu。但是Kudu+Impala这种通用大数据处理框架只是相比Spark+Hdfs这种离线分析框架而言具有速度优势，对于实时数据分析场景来说，查询响应的速度和数据的延迟仍然比较高，无法满足实时性要求更高的场景，无法提供良好的交互式用户体验。

 

<>02了解项目背景

技术研发是要根据企业的业务需求进行的，腾讯看点内容业务的运行模式是作者发布的内容被内容中心引入，经过内容审核链路，审核结果启用或者下架。启用的内容给到推荐系统和运营系统，然后推荐系统和运营系统将内容通过手机QQ、微信、QQ浏览器，还有一些独立端的APP进行C侧分发。内容分发给C侧用户之后，用户会产生各种行为，曝光、点击、举报等，通过埋点上报实时接入到消息队列中。

 

 

而工程技术人员接下来要做两件事，一个是构建腾讯看点的实时数据仓库，另一个则是基于OLAP存储引擎，开发多维实时数据分析系统。

            

实时数据仓库能够按照信息流的业务场景进行内部维度关联、用户画像关联，聚合各种内容，提高下游使用实时数据的便捷性。多维实时数据分析系统可以实时分析系统消费了上一轮数据实时数据仓库，然后利用了OLAP存储计算引擎，让海量的数据进行了高效的存储，提供高性能的查询。

 

<>03方案选型

       

每种方案都有不足，腾讯看点对比行业内的领先方案，最终选择最符合企业业务场景的方案。

 

 

实时数仓的选型：腾讯看点选择了业界比较成熟的Lambda架构，Lambda架构具有灵活性高、容错性高、成熟度高和迁移成本低众多有点；缺点是实时、离线数据需要使用两套代码，可能业务逻辑修改了，但是批次没有跟上。腾讯看点对这个问题的处理方法是每天都进行数据对账工作，如果有异常则进行告警。

 

实时计算引擎选型：选择了Flink作为实时计算引擎。因为Flink设计之初就是为了流处理，此外，Flink还具有Exactly-once的准确性、轻量级Checkpoint容错机制、低延时高吞吐和易用性高的特点，是最佳选择。

 

实时存储引擎选型：腾讯看点的业务对维度索引、支持高并发、预聚合、高性能实时多维OLAP查询有要求，而Hbase、Tdsql和ES都不能满足。Druid存在按照时序划分Segment的缺陷，无法将同一个内容，存放在同一个Segment上，计算全局TopN只能是近似值。综合对比，最终选择了MPP数据库引擎ClickHouse。

<>04设计目标与设计难点分析

腾讯看点的多维实时数据分析系统分为三大模块：实时计算引擎、实时存储引擎、App层。

#p#分页标题#e#

 

难点主要在实时计算引擎和实时存储引擎两个模块：要实现千万级/s的海量数据实时接入，并且进行极低延迟的实时维表关联；实现高并发写入、高可用分布式和高性能索引查询。

             

<>05难点攻克

王展雄指出，腾讯看点的前端采用的是开源组件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存储引擎，设计符合业务的索引和物化视图，高效存储海量数据；

后台接口层提供高效的多维实时查询接口。

<>实时计算

实时计算分为实时关联和实时数仓。

 

1 、实时高性能维表关联

 

在实时高性能维表关联上，王展雄指出，百万级/s的实时数据流，如果直接去关联HBase，1分钟的数据，关联完HBase耗时是小时级的，会导致数据延迟严重。

 

为此，腾讯看点提出了以下几个解决方案：

第一个是，在Flink实时计算环节，先按照1分钟进行了窗口聚合，将窗口内多行行为数据转一行多列的数据格式，经过这一步操作，原本小时级的关联耗时下降到了十几分钟，但是还是不够的。

             

第二个是，在访问HBase内容之前设置一层Redis缓存，因为1000条数据访问HBase是秒级的，而访问Redis是毫秒级的，访问Redis的速度基本是访问HBase的1000倍。为了防止过期的数据浪费缓存，缓存过期时间设置成24小时，同时通过监听写HBase Proxy来保证缓存的一致性，并将访问时间从十几分钟变成了秒级。

#p#分页标题#e#

 

第三个是，上报过程中会上报不少非常规内容ID，这些内容ID在内容HBase中是不存储的，会造成缓存穿透的问题。所以在实时计算的时候，系统直接过滤掉这些内容ID，防止缓存穿透，又减少一些时间。

 

第四个是，因为设置了定时缓存，会引入一个缓存雪崩的问题。为了防止雪崩，我们在实时计算中，进行了削峰填谷的操作，错开设置缓存的时间。

 

优化后，数据量从百亿级减少到了十亿级，耗时从小时级减少到了数十秒，减少99%。

 

2 、下游提供服务

 

而实时数仓的难度在于，它处于比较新的领域，并且各个公司各个业务差距比较大，要设计出方便，好用，符合看点业务场景的实时数仓是有难度的。

 

实时数仓对外就是几个消息队列，不同的消息队列里面存放的就是不同聚合粒度的实时数据，包括内容ID、用户ID、C侧行为数据、B侧内容维度数据和用户画像数据等。

 

腾讯看点搭建数仓通过上面介绍的实时计算引擎的输出，放到消息队列中保存，可以提供给下游多用户复用。

 

在没有数仓的时候，需要消费千万级/s的原始队列，进行复杂的数据清洗，然后再进行用户画像关联、内容维度关联，才能拿到符合要求格式的实时数据，开发和扩展的成本都会比较高，如果想开发一个新的应用，又要走一遍这个流程。有了数仓之后，如果想开发内容ID粒度的实时应用，就直接申请TPS万级/s的DWS层的消息队列。开发成本变低很多，资源消耗小很多，可扩展性也强很多。

 

开发腾讯看点系统的实时数据大屏，原本需要进行如上所有操作，才能拿到数据。现在只需要消费DWS层消息队列，写一条Flink SQL即可，仅消耗2个cpu核心，1G内存。可以看到，以50个消费者为例，建立实时数仓前后，下游开发一个实时应用，可以减少98%的资源消耗。包括计算资源，存储资源，人力成本和开发人员学习接入成本等等。并且消费者越多，节省越多。就拿Redis存储这一部分来说，一个月就能省下上百万人民币。

 

 

<>实时储存

 

表引擎以什么方式存储？以什么方式加载？以及数据表又有什么特性？这些问题都与实时储存技术相关。

 

分布式-高可用

腾讯看点听取了Clickhouse官方的建议，借助ZK实现高可用的方案。数据写入一个分片，仅写入一个副本，然后再写ZK，通过ZK告诉同一个分片的其他副本，其他副本再过来拉取数据。ZK更加轻量级，写的时候，任意写一个副本，其它副本都能够通过ZK获得一致的数据。此外，即便其它节点第一次来获取数据失败了，后面只要发现它跟ZK上记录的数据不一致，就会再次尝试获取数据，保证数据一致性。

 

海量数据-写入

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

 

第二个问题是，如果采取默认方案，随着数据量的增长，会造成单台机器出现磁盘的瓶颈，在合并的过程中会存在写放大的问题，加重磁盘压力。峰值每分钟几千万条数据，写完耗时几十秒，如果正在做Merge，就会阻塞写入请求，查询也会非常慢。为此腾讯看点做了两个优化方案：一是对磁盘做Raid，提升磁盘的IO；二是在写入之前进行分表，直接分开写入到不同的分片上，磁盘压力直接变为1/N。

 

第三个问题是，虽然写入按照分片进行了划分，但是存在一个分布式系统常见的问题，就是局部的Top并非全局Top的问题，导致汇总的时候，会丢失一部分数据，影响最终结果。腾讯看点内部在写入之前加上一层路由，将同一个内容ID的记录，全部路由到同一个分片上，解决了该问题。

#p#分页标题#e#

 

高性能-查询

Clickhouse高性能查询的一个关键点是稀疏索引。稀疏索引这个设计就很有讲究，设计得好可以加速查询，设计不好反而会影响查询效率。腾讯看点根据自身的业务场景，针对某个内容的查询，建立稀疏索引之后，可以减少99%的文件扫描。

 

但是腾讯看点的数据量太大，维度太多，如果一次性把所有维度进行预聚合，数据量会指数膨胀，查询反而变慢，并且会占用大量内存空间。针对不同的维度，腾讯看点建立对应的预聚合物化视图，用空间换时间，缩短查询时间。

 

此外，分布式表查询还有一个问题，查询单个内容ID的信息，分布式表会将查询下发到所有的分片上，然后再返回查询结果进行汇总。实际上，因为做过路由，一个内容ID只存在于一个分片上，剩下的分片都在空跑。针对这类查询，腾讯看点的优化方案是后台按照同样的规则先进行路由，直接查询目标分片，这样减少了N-1/N的负载，可以大量缩短查询时间。而且由于我们是提供的OLAP查询，数据满足最终一致性即可，通过主从副本读写分离，可以进一步提升性能。在后台再做一个1分钟的数据缓存，针对相同条件查询，后台就直接返回了。

              

分享最后，王展雄指出，腾讯看点的实时分析系统力亚秒级的响应查询请求，在未命中缓存情况下，过去30分钟的查询，99%的请求耗时在1秒内；过去24小时的查询，90%的请求耗时在5秒内，99%的请求耗时在10秒内。