生产实践 | 基于 Flink 的直播实时数据建设 （一）| 需求和架构篇

❝本系列每篇文章都是从一些实际生产实践需求出发，解决一些生产实践中的问题，抛砖引玉，以帮助小伙伴们解决一些实际生产问题。相信大家或多或少都观看过直播，那大家有没有想过，如果自己负责建设公司内整体直播实时数据，会怎样去建设呢？本系列文章主要介绍直播实时数据建设的整个过程，如果对小伙伴有帮助的话，欢迎点赞 + 再看~ ❞

首先思考几个问题

• 「WHAT：相信大家或多或少都观看过直播，甚至自己就是一名主播或负责的业务就是直播相关的，那大家有没有思考过，在直播业务场景中，你最关心什么指标以及需要关注、建设什么直播数据？」
• 「WHY：为什么需要建设实时的直播数据？离线不能满足吗？」
• 「HOW：实时的直播数据可以怎样赋能业务？怎样根据公司直播场景的需求去划分直播实时数据的模块？怎样去建设直播实时数据？」
• 「WHO：在建设直播实时数据的过程中，需要使用什么样的组件进行建设？每个组件都负责哪一部分？」

让我们带着以上几个问题出发~

直播 + 短视频，内容运营的下一个战场

随着互联网络技术的发展，网络直播受到越来越多人的关注，直播在经过几年前的喷涌式大爆发之后，近段时间热度有所降低。内容的同质化和变现困难是直播现在面临的主要问题，随着移动终端普及和网络的提速，短视频以短平快的大流量传播方式快速获得各大平台、粉丝和资本的青睐，所以众多直播软件开始接入短视频的功能。同时，一些以短视频为主发展起来的 app 也在软件中加入了直播功能，直播和短视频两者互相弥补不足，相辅相成，给用户带来了更好的使用体验，也给各大平台带来更多的流量，"直播 + 短视频"的模式已经也成为新的发展趋势。

本系列文章主要围绕着直播实时数据建设而展开。本文是本系列文章的的第一篇，需求和架构篇，主要分为三个部分，按顺序为「WHY - WHAT - HOW」，以这三个角度出发，解答开头提出的三个问题，其中 「WHO」部分在本系列文章的后续建设细节篇进行介绍！

WHY：为什么需要建设实时直播数据？

相比短视频的生产消费来说，直播的主播和观看直播的观众的纽带都是在直播间建立的，相互之间的互动行为也都只在直播间内产生，并且通常情况下，一场直播的时长也就在几个小时之内，因此直播的生产消费时效性相比短视频会更强，因而直播数据对于实时性的诉求也就更高。

WHAT：需要关注、建设什么直播实时数据？

需要关注、建设什么直播实时数据？换一句话来说就是根据「数据分析业务的需求」出发，决定建设什么样的直播实时数据。

直播就是一个主播和观众联络互动的纽带，其中一切操作都是围绕着主播和观众而展开的，数据分析的同学都会以这个最基础的角度出发进行分析，因此首先我们就可以将整个直播的数据按照「直播生产」和「直播消费」进行最基本的划分。

除此角度之外，数据分析的同学也还会从「全局直播业务洞察」和「单个直播间洞察」不同粒度上进行分析洞察，因此还可以按照「大盘数据」、「单直播间数据」进行划分。

从这两个角度出发，基本可以涵盖对于直播业务分析场景的诉求，因此直播实时数据也自然可以从这两个角度进行划分和建设。

综上整体「直播实时数据业务划分和赋能应用架构」如下图所示。

业务划分和赋能应用架构

其中

「直播大盘实时数据」在宏观上监控直播业务，提供预测大盘的能力；其中分钟粒度时间序列可快速定位直播各行为的高峰时刻，可以基于该时刻进行详细归因。除此之外，当直播在做运营活动时，也能快速基于实时数据来看运营活动的活动效果，赋能活动策略实时优化。

「单直播间直播实时数据」可以以细粒度监控单直播间的直播业务，用来在直播过程中对外输出直播数据战报、以及可基于数据战报效果实时对单直播间进资源投放进行实时效果评估和合理调配。

详细的直播实时数据需求和样例如下文。

大盘

「生产侧」

• 「指标」：总体开播直播间数...
• 「维度」：直播间画像、主播用户画像
• 「举例」：[开播直播间为游戏类直播]的[总开播主播数]

「消费侧」

• 「指标」：总体观众观看、点赞、评论数...
• 「维度」：观众用户画像、日志上报其他维度
• 「举例」：[目前在河北观看直播]的[总观众数]

单直播间

「生产侧」单直播间一般都是一些画像信息，所以此类指标较少，暂时不做讨论。

「消费侧」

• 「指标」：单直播间观众观看、点赞、评论数...
• 「维度」：观众用户画像、日志上报其他维度
• 「举例」：某直播间[18-23岁年龄段]的[总观众数]

目前已经了解了要建设直播实时数据都包含了什么内容，接下来就是大干一场的时候了。

HOW：怎样去建设？

怎样去建设？换一句话来说就是从技术的角度出发，怎样将「直播实时数据的业务需求」转化为「直播实时数据的技术方案」进行落地？

从技术角度出发，上述直播实时数据需要建设的需求内容总结下来就是一个词：「直播实时多维指标」。

多维

即产出指标是多维度的，包含公共维度和非公共维度。

第一类是「公共维度」。包含三部分，直播间画像，主播用户画像，观众用户画像，公共两字代表这类维度是可以被多个指标进行共享使用的。举例：某直播间开播之后，该直播间画像只需要一次建设，就可以被多个指标多次重复使用，不但可以作为大盘侧生产、消费指标的维度，也可以作为单直播间生产、消费指标的维度。

第二类是「非公共维度」。非公共维度是和特定消费行为绑定的，也就是和某个指标绑定的，随着日志上报一同上报的维度。举例：某观众观看直播时的客户端类型（安卓？IOS？），观看直播时的省份等维度，这类维度只和当前的消费行为相关，不能被其他指标所共享。

多维

指标

其实都是 pv，uv 类指标。简单理解就是各个维度下对应的 xx 量。

指标

直播实时数据建设技术架构

对应到直播实时数据建设的过程主要包含两部分：公共部分和非公共部分。

公共部分就是实时公共维表的建设。

非公共部分就是指标非公共维度以及对应生产、消费指标建设。

直接给出总体「技术架构」图，本系列后续的文章进行介绍这样进行整体架构设计的详细原因。

技术架构

简单说明下。

其中数据源包含生产侧，消费侧数据源；

数据处理部分包含公共实时维表建设，和指标建设，其中一部分公共维表的建设也使用了离线建设的方式提供了支持；

最后就是数据汇部分，产出了生产侧，消费侧的多维指标供数据分析师使用。

以上就是整个「WHY - WHAT - HOW」的分析过程，本篇先给出技术架构设计，后续篇对使用到的技术方案进行详细介绍~

总结

本文首先提出了几个关于直播实时数据建设的问题。以这几个问题触发，引出了以下三小节。

第一节简单介绍了直播时效性强的原因，因此直播对于实时数据的需求更加强烈。

第二节从数据分析的角度出发，引出了我们需要建设的直播实时数据都包含哪些内容，并且从大盘/单直播间，生产/消费角度进行了模块划分。

第三节对数据需求进行了技术方案的整体架构设计。

最后一节对本文进行了总结。

如果你也有相同的建设需求或者你已经建设了直播实时数据，欢迎留言或者留下你的文章链接，相互交流~