整套解决方案:腾讯看点基于 Flink 的实时数仓及多维实时数据分析实践

　　整套解决方案:腾讯看点基于 Flink 的实时数仓及多维实时数据分析实践

　　当业务发展到一定规模时，实时数仓是必不可少的基础服务。从数据驱动的角度来看，多维实时数据分析系统的重要性不言而喻。但在数据量巨大的情况下，以腾讯为例，一天上报的数据量达到万亿级规模，实现极低延迟的实时计算和亚秒级多维实时查询。

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

　　1.可解决的痛点

　　我们先来看看多维实时数据分析系统能解决的痛点。例如：

　　2.研究

　　在进行开发之前，我们进行了这些调查。

　　1、线下数据分析平台能否满足这些需求，结论是不能满足。离线数据分析平台不起作用的原因如下。

　　2.实时数据分析平台，业务群提供准实时数据查询功能。底层技术采用Kudu+Impala，虽然Impala是MPP架构的大数据计算引擎，接入Kudu，数据以列格式存储。但是对于实时数据分析场景，查询响应速度和数据延迟还是比较高的。查询一个实时 DAU 并返回结果至少需要几分钟，无法提供良好的交互用户体验。因此，通用大数据处理框架（Kudu+Impala）的速度优势要大于离线分析框架（Spark+Hdfs）。对于我们对实时性要求较高的场景，是无法满足的。的。

　　三、项目背景

　　刚刚介绍完之后，我们再来看看我们项目的背景。作者发布的内容由内容中心介绍，内容审核链接后启用或下架。启用的内容交给推荐系统和操作系统，然后推荐系统和操作系统将内容分发到C端。内容分发给C端用户后，用户会有曝光、点击、举报等各种行为，并通过埋点举报实时接入消息队列。接下来我们做了两个部分的工作，也就是图中有颜色的两个部分。

　　为什么要建实时数仓，因为原创上报的数据量非常大，一天的高峰就有上万亿的上报。报告格式令人困惑。缺乏内容维度信息和用户画像信息，下游无法直接使用。我们提供的实时数仓基于腾讯手表信息流的业务场景，进行内容维度的关联、用户画像的关联、各种粒度的聚合。下游可以很方便地使用实时数据。

　　4、方案选择

　　再来看看我们的多维实时数据分析系统的方案选择。我们对比了业界领先的解决方案，选择了最适合我们业务场景的解决方案。

　　五、设计目标和设计难点

　　我们的多维实时数据分析系统分为三个模块

　　实时计算引擎 实时存储引擎 应用层

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

　　如何实时访问数千万/秒的海量数据并进行极低延迟的维表关联。实时存储引擎很难支持高并发写入、高可用、分布式和高性能索引查询。

　　对于这些模块的具体实现，看一下我们系统的架构设计。

　　6.架构设计

　　

　　前端使用开源组件Ant Design，使用Nginx服务器将静态页面和反向代理浏览器请求部署到后端服务器。

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

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

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

　　7.实时计算

　　该系统最复杂的两个部分是实时计算和实时存储。

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

　　7.1 实时高性能维表关联

　　实时维表关联的难点在于。百万级/秒的实时数据流，如果直接关联HBase，1分钟的数据关联HBase需要几个小时，会造成严重的数据延迟。

　　我们提出了几种解决方案：

　　可以看到，优化前后，数据量从百亿减少到数十亿，耗时从几小时减少到几十秒，减少了99%。

　　7.2 下游服务提供

　　实时数仓的难点在于它是一个比较新的领域，各个公司的业务都有很大的差距。

　　我们先来看看实时数据仓库是做什么的。实时数据仓库只是几个消息队列。不同的消息队列存储不同聚合粒度的实时数据，包括内容ID、用户ID、C端行为数据、B端内容。维度数据和用户画像数据等

　　我们构建实时数仓的方式是，上述实时计算引擎的输出存储在消息队列中，可以提供给下游的多用户复用。

　　我们可以看看在构建实时数据仓库之前和之后开发实时应用程序的区别。在没有数据仓库的情况下，我们需要先消费千万/s的原创队列，进行复杂的数据清洗，再进行用户画像关联和内容维度关联，获取符合要求格式的实时数据，开发和扩张的成本。会比较高。如果你想开发一个新的应用程序，你必须再次经历这个过程。有了数据仓库之后，如果要开发内容ID粒度的实时应用，可以直接申请TPS级别为10000/s的DWS层的消息队列。开发成本更低，资源消耗更小，可扩展性更强。

　　让我们举一个实际的例子。为了开发我们系统的实时数据屏幕，我们最初需要执行以上所有操作来获取数据。现在只需要消耗 DWS 层消息队列，写一条 Flink SQL，只消耗 2 个 CPU 核和 1G 内存。

　　可以看出，以50个消费者为例，在建立实时数仓前后，下游开发一个实时应用可以减少98%的资源消耗。包括计算资源、存储资源、人工成本和开发者学习访问成本等。而且消费者越多，节省的越多。以 Redis 存储为例，每月可节省数百万*敏*感*词*。

　　8.实时存储

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

　　

　　本节分为三个部分来介绍

　　8.1 分布式高可用性

　　我们这里听的是Clickhouse官方的建议，借助ZK实现高可用方案。数据写入一个shard，只写入一个副本，然后再写入ZK。ZK用来告诉同一个shard的其他副本，其他副本来拉数据，保证数据的一致性。

　　这里不使用消息队列进行数据同步，因为 ZK 更轻量级。并且在写入的时候，任意一个副本都被写入，其他副本都可以通过ZK获得一致的数据。并且即使其他节点第一次获取数据失败，只要发现与ZK上记录的数据不一致，就会再次尝试获取数据以保证一致性。

　　8.2 海量数据——写入

　　数据写入遇到的第一个问题是，如果直接将海量数据写入Clickhouse，ZK的QPS会太高。解决办法是使用Batch来写。批量设置有多大？如果batch太小，不会缓解ZK的压力，batch也不宜太大，否则上游内存压力太大。通过实验，我们最终选择了几十万的batch。

　　第二个问题是，随着数据量的增长，每天可能会有数百亿的数据写入单个视点的视频内容。默认的解决方案是写分布式表，这样会导致单机磁盘瓶颈。，特别是Clickhouse的底层使用了Mergetree，原理类似于HBase和RocketsDB的底层LSM-Tree。在合并的过程中，会出现写放大的问题，会增加磁盘的压力。峰值是每分钟几千万条数据，写入需要几十秒。如果在做Merge，写请求会被阻塞，查询会很慢。我们做了两个优化方案：一是在磁盘上做RAID，提高磁盘的IO；

　　第三个问题，虽然我们的写法是按照shards来划分的，但是这里介绍一个分布式系统中的一个常见问题，就是本地Top不是全局Top。例如，相同内容ID的数据落在不同的分片上，计算全局Top100读取的内容ID。有一个content ID在shard 1上是Top100，在其他shard上不是Top100，汇总时会丢失。影响最终结果的部分数据。我们做的优化是在写之前加了一层路由，将所有具有相同content ID的记录路由到同一个shard，解决了这个问题。

　　写完介绍，接下来就是介绍Clickhouse的高性能存储和查询。

　　8.3 高性能-存储-查询

　　Clickhouse 的高性能查询的一个关键点是稀疏索引。稀疏索引的设计非常讲究。好的设计可以加快查询速度，但不好的设计会影响查询效率。我是基于我们的业务场景，因为我们的大部分查询都是和时间和内容ID相关的，比如对于某个内容，在过去N分钟内，它在各个人群中的表现如何？我有一个按日期、分钟粒度时间和内容 ID 的稀疏索引。对于某个内容的查询，稀疏索引建立后，文件扫描可以减少99%。

　　另一个问题是我们现在有太多的数据和太多的维度。以看点的视频内容为例，每天有数百亿的视频，在某些维度上有上百个类别。如果一次性预聚合所有维度，数据量会呈指数级增长，查询速度会变慢，而且会占用大量内存空间。我们的优化针对不同维度构建了相应的预聚合视图，以空间换时间，可以缩短查询时间。

　　分布式表查询也存在问题。查询单个内容ID的信息，分布式表会将查询发送到所有分片，然后返回查询结果进行汇总。事实上，因为路由，一个内容ID只存在于一个分片上，其余分片都是空的。对于这种查询，我们的优化是按照相同的规则路由后台，直接查询目标shard，减少了N-1/N的负载，可以大大缩短查询时间。并且因为我们提供OLAP查询，所以数据可以满足最终的一致性，通过主从副本分离读写可以进一步提升性能。

　　我们还在后台做了 1 分钟的数据缓存。对于同一个查询，后台会直接返回。

　　8.4 扩展

　　在这里，我们将介绍我们的扩张计划，并调查一些业内常见的解决方案。

　　例如，在 HBase 中，原创数据存储在 HDFS 中。扩容只是Region Server的扩容，不涉及原创数据的迁移。但是Clickhouse的各个分片数据都是本地的，属于比较底层的存储引擎，不能像HBase那样容易扩展。

　　Redis 是一种类似于一致性哈希的哈希槽，是比较经典的分布式缓存方案。虽然在 Rehash 过程中 Redis slot 暂时不可用，但迁移一般比较方便，从原来的 h[0] 到 h[1]，最后删除 h[0]。但是Clickhouse大部分是OLAP批量查询，不是点查询，而且由于列存储不支持删除的特性，一致性哈希方案不是很适合。

　　目前的扩容方案是消费另外一份数据，写入新的Clickhouse集群，两个集群一起运行一段时间，因为实时数据存储3天，3天后，后台服务直接访问新集群。

　　9. 结果

　　腾讯看点实时数仓：DWM层和DWS层，数据延迟1分钟。

　　Foresight多维实时数据分析系统：多维条件查询请求亚秒级响应，在缓存未命中的情况下，过去30分钟99%的查询耗时不到1秒；过去 24 小时内的查询，90% 的请求不到 5 秒，99% 的请求不到 10 秒。

　　技巧:关键词分析-免费同行网站流量来源全面分析工具

　　关键词分析，我们需要在构建网站之前选择关键词来优化网站。哪个关键词能获得更多的流量和更高的转化率，这些转化率高的好关键词自然需要我们更多的关注，而最直接的方法就是分析同行网站，通过对端网站的域名链接，抓取对端网站的所有关键词布局进行分析！

　　目录：

　　对等 网站TDK 标签

　　同行网站的收录和外链分析

　　同行网站开启速度

　　网站更新频率和文章质量

　　1.对等网站TDK标签

　　TDK是网站的标题、描述和关键词（关键字），TDK是网站的一个很重要的元素，它是蜘蛛爬你的网站第一眼看到的之后，所以设置TDK对网站的优化很关键。

　　标题：标题要有吸引力，同时收录用户的需求点，长度要合理。标题不能收录太多关键词，最好在3个以内，太多容易导致权重分散，不利于排名。

　　

　　描述（description）：描述是为了突出公司或其主营业务的服务，是对整个网页的简单概括。描述标签的字符一般控制在200以内。如果是网站的首页，可以写公司的主要经营范围或公司介绍。如果是内页，可以填写本页内容的概要。例如，如果您是产品页面，请编写产品页面。简单来说，如果是文章页面，写下文章的主要内容是什么，这样蜘蛛就可以抓取到，让用户更好的知道你写了什么。如果不想每次发送文章都写描述，可以设置自动抓取文章的前一部分作为描述。

　　关键词（关键字）：关键词为简洁明了，多个关键词用“,”分隔，关键词最好设置在3以内，网站后发展到比较高的权重，可以增加到5左右。关键词对网站的排名也有很大的影响，蜘蛛在抓取你的网页时也会判断你的关键词 ，如果你不设置 关键词 ，它将基于你的标题。

　　2. 竞争对手的外部链接和收录

　　外链情况：分析对手的外链数量。一般来说，排名越高的网站，外链数据越多。要保证外链的数量，还要保证外链的质量。优质的外链决定了网站在搜索引擎中的权重。发送外链时，一定要在网站上以高权重发布有效的外链。

　　收录情况：先列出关键词和长尾关键词，用工具查询收录的文章使用的收录的情况关键词，如果想让你的网站有排名，前提是收录，收录越多，关键词在搜索中的排名就越好引擎等于机会越大

　　3.网站的开启速度

　　网站的打开速度直接影响网站的收录和用户体验，所以网站的打开速度太重要了！

　　

　　1、网站服务器配置偏低，网站流量大/爬虫爬取或者服务器内存快满等都会影响网站的打开速度。

　　2.网站服务器支持的区域少或机房带宽差时，会导致本地访问者访问本地网站的延迟，导致网站的打开速度变慢>。

　　3. 网站服务器是否使用gzip压缩功能。压缩网站可以大大压缩网站占用的用户带宽，提高网站的访问速度。

　　4. 网站更新频率和文章质量

　　众所周知，蜘蛛喜欢新鲜事物，所以我们每天都要给我们的网站添加一些新的内容，只有先喂这些蜘蛛，搜索引擎才会对我们的网站进行排名，那么我们在更新文章的时候应该注意哪些方面呢？

　　1. 文章 的质量

　　首先，我们在更新网站的时候，一定要保证我们更新的内容是高质量的，也就是说内容是和我们的网站相关的。我正在做SEO优化。如果我更新的内容都是关于卖靴子或买衣服的。我的内容再好也不过是一片云而已，对我的网站关键词排名用处不大，所以我们在更新网站文章一定要质量好，可读性强，让用户喜欢我们的文章，搜索引擎根据用户体验来判断，好的用户体验才是王道。

　　2. 文章是否原创

　　现在很多人觉得写文章太难了，干脆把网上的内容修改一下，发出去。结果这个文章的重复率达到了80%，这样的文章@文章效果不大，而且搜索引擎很可能不会收录，最好我们伪原创的方式就是看别人的文章然后根据自己的理解说一二三，这样的文章不再是伪原创，是绝对的原创，当然前提是你对这个行业比较熟悉，可以写的好文章加油。