暂无图片
暂无图片
暂无图片
暂无图片
暂无图片

快手短视频领域为例的领域数据探索

数聚慧 2021-09-24
660

导读:本次分享的是快手短视频领域为例的领域数据建设探索。今天的分享会分为四个板块,首先会介绍2020年之前早期数据建设历程;接下来会介绍我们从2020年开始在领域建设这个方向上的一些探索,以及一些案例;最后会给大家讲讲在未来一段时间内工作以及方向上的规划。

  • 快手的早期数据建设

  • 快手领域建设探索

  • 快手短视频领域建设实践

  • 未来规划


▌快手早期数据建设

1.  主题域划分+分层建设

快手的数仓建设最早可以追溯到16年的11月,核心思路是主题域划分和分层设计。由于快手是较早进入短视频赛道的企业之一,行业内并没有很好的主题域设计范例。因此在主题划分上,我们更多的是基于快手自身的业务形态。基于人和内容的方向,将快手划分为四个主题,分别是:用户域、设备域、生产域及消费域;层级上也做了四个层级的切割:贴源层、明细层、聚合层及应用层。

这样的设计持续了一年多的时间,比较好的适配了快手数据分析的冷启阶段。但从17年开始,快手开始在同城、搜索、直播等模块开始尝试一些垂直化的探索,同时数据分析也从早期的描述性分析问题转换为诊断和预测类的分析问题。数据使用的广度和深度变大,加重了数据研发同学的交付压力,同时新增的数据模型在已有的主题域归属上,也开始出现模糊不清的问题。因此,18年我们开始基于以上问题进行2.0版本的升级。


上面是我们2.0版本的示意图,有两个比较显著的改进:

1)扩展主题域

我们将主题域从之前的四个新增到了现在的十多个主题域(由于篇幅原因图中只放了七个)。随着业务的发展,增加了社交域、搜索域、财务域等。另外由于直播等内容消费品类的涌现,我们把之前的生产和消费衍生成内容供给和内容消费域。通过主题域扩充,主要解决模型归属不清的问题。

2)新增主题层

我们在聚合层和应用层中间,新增了主题层。主题层用于承载核心实体宽表和核心业务过程宽表。通过在宽表中冗余大量业务使用的分析属性和指标,引导用户通过低成本的自助取数,降低数据建设压力。随着时间的检验,再将通用模型进行下沉。


2.  未解决的问题

技术架构升级后,快手在数据建设上依然还存在两类未解决的问题:

1)供需矛盾

除了初始化阶段,我们大部分时间都处于数据建设追赶业务的状况。虽然主题层的设计可以帮助我们提升复用性,但是这里面有个隐含的问题:宽表常态下需要引用再加工才能直接应用在实际场景分析中。这里边基本上就是一个需求一个轮子的现象,所以我们烟囱式的建设并没有得到特别好的缓解,反而随着快手整体业务的迅速发展愈演愈烈。

2)自我视角

近些年来,陆续都能收到“难找数”的反馈。我们进行分析后发现,用户在找数时会有一个非常长的查找路径:首先要对场景做指标、维度的拆解;其次还需要对我们的数据建设框架有大致了解(例如每个主题域里大概是解决什么类型的分析问题,每个层级里大概存的什么粒度的数据)。这就造成用户找数时,入门门槛和时间成本都比较高。当前数仓的建设和能力输出更多技术人的视角,而很少站在用户的视角。

上述两个问题在技术架构层面很难得到解决,更多需要靠组织或者能力规划层面来解决。因此在确定维持数据建设技术不变的前提下,我们在20年开始尝试进行一些相应的探索性工作。


▌快手领域建设探索

1.  目标

快手领域建设探索的目标拆解成三个方向:

  • 业务满足率:希望做到业务满足率高

  • 使用成本:用户使用成本低

  • 复用性:模型复用性变强

从这三个方向,我们去拆解策略升级应该往哪个方向去做?


2.  策略:业务满足率

首先是提升业务满足率。之前我们是通过先交付再治理的分层设计来加速交付节奏:APP层个性化开发,快速支持;宽表层做需求转移;公共层过一段时间再下沉。新的策略中,我们希望能提前去预判、识别业务问题,提前进行数据的规划和建设。


3.  策略:使用成本

然后是降低用户使用成本。之前的问题在于用户的使用流程过于复杂。用户最了解的是场景和业务问题,我们不应该过分执著去向用户阐述主题域和层级是什么,而应该重点阐述我的能力是适用于什么样的场景,我在这个场景中能解决什么问题。通过阐述资产的场景服务能力去缩短用户的路径,降低相关的使用成本。


4.  策略:复用性

最后是加强模型复用性。实际上在团队内部我们一直在强调模型复用性,但在分析大家具体的执行路径时,我们发现:模型整合更多发生在物理模型阶段,大家在需求所需的粒度一致的情况下,才会去寻求模型的复用。新的策略中,我们希望大家能更多在设计规划阶段,分析场景之间的相似性,来指导最后资产的设计。

在明确三个方向的具体策略后,我们发现常被用于软件开发领域的【DDD领域驱动设计】思想和我们的的策略升级具有非常强的关联性。


5.  领域驱动设计DDD

  • 构建领域知识

通过对某业务方向进行内容理解,拆解业务问题,构建相应的领域知识。通过领域问题驱动做业务建模,来提升数据能力覆盖。

  • 统一通用语言

通过统一通用语言让用户和技术同学使用一样且较易理解的语言进行资产能力沟通。

  • 复用领域模型

强调业务逻辑上的整合,通过复用领域模型而不是复用物理模型去做前期的整合,再通过前期的整合缩并去指导后续真正的物理模型的落地。


6.  动作拆解

  • 领域知识

领域知识的核心是抽象出本域的相关概念。大致存在两个阶段,首先是知识初始化的冷启阶段;其次为了保证认知和业务发展能保持节奏上的一致,我们还需要在日常阶段持续进行领域知识的迭代。

  • 通用语言

第二个是通用语言。在数据建设中,我们认为内外的通用语言是场景,我们应该基于场景去做沟通,推导后续的模型设计。

  • 领域模型复用

第三个是领域模型复用。我们要处理解决的是一个逻辑概念,而场景就是这个逻辑概念里的最小单位。我们基于场景去做业务问题的拆解与合并,基于场景去做数据能力升级和数据资产的迭代。


7.  建设流程

核心动作拆解完毕之后,我们可以对比一下快手数据建设的新老建设流程。之前更多的是从技术视角,关注的是一个建设的阶段:执行细节更多的是数仓相关(我们应该怎么去做主题域归属,怎么去做层级的划分,在对应的层级,在对应的主题里面应该做一个什么样的物理模型)。在新的流程里,更加强调领域知识构建的抓手:申报和运营阶段。申报对应的是怎么去做好一个领域知识的冷启,而运营阶段则是帮助我们把领域知识迭代做成例行化的一个手段。另外建设阶段也会有一些不同,建设阶段里面我们重点去强调场景的输入,而之前更多的是基于单点的问题去做。

整体的快手领域建设方法,我认为主要用12个字就可以去总结:一个组织、三个阶段和五个步骤。

  • 一个组织

组织是维持我们一个流程能够有效并且长期运行的一个前置条件。我们在快手里新增了业务领域数据管理小组:角色构成较为多元,有实际BP业务的前台同学,有具备较多专家经验的中台同学,另外也会有产品或者运营的同学加入。小组更多的履行审核和监督的职能。

  • 三个阶段

申报、建设和运营阶段

  • 五个步骤

指导大家在不同的阶段里知道有哪些里程碑是必须要去经历,必须要去落实的。


▌快手短视频领域建设实践


1.  申报阶段:领域知识冷启

整个方法论有了初步的脉络之后,我们选取短视频作为案例给大家做一些阐述。

首先是申报阶段,此阶段第一个部分我们需要做好领域知识的冷启,有四个要素是必须充分讨论且认知清楚的。

  • 领域名称

要求对这个领域的定义,及其描述是准确和清晰的。作为领域建设的第一部分,内外部同学通过领域名称能够清楚地知道大家应该要讨论的焦点是什么,大家应该要关注的是哪个方向,其实是起到一个收敛聚焦和收敛和集中讨论的一个作用。

  • 领域描述

需要关注在这个方向里,真正的业务问题是什么,业务想要做什么业务,想要拿到什么业务,想要做到这些东西的参与角色是什么?所以要求大家在领域描述这块,需要阐述清楚上述信息以明确业务方向的价值。

  • 领域目标

数据同学在业务领域中能做到什么样的能力输出,能够解决什么样的业务问题,需要在这里面明确下来。这样的话也是帮助我们在每一个阶段的建设之后,去check我们实际拿到的结果和我们想要拿到的目标是不是匹配的。

  • 领域拆解

在这个部分,我们经历的是抽象变具体的一个过程。提炼不同子领域中的关联业务过程,并且拆解成多个业务动作。


2.  申报阶段:领域公示

在通过四要素的梳理后,我们对领域内要做的事情有了一些认知。下一步就进入到申报阶段的第二部分-领域公示。

公示阶段,除去领域名称等四个领域要素,还新增了领域接口人的信息公开。我们希望通过公示,对外可以输出规划,和业务方拉齐步调;对内,可以让团队内部的人知道规划或者已有的能力是什么。当实际业务支持时发现类似场景,能通过领域接口人在前期即进入合作模式。而不是走到最后一步,可能在物理模型阐述的时候,固定的评审会上,才发现说原来我们可以去做一些整合的事情,或者说甚至他可能都不知道有一些这样的烟囱式的建设。


3.  申报阶段:案例

上图是我们对于短视频领域完成的四要素填充。

领域名称:短视频领域

领域描述:涉及7个阶段,生产->存储->审核->理解->推荐->消费->导流。不同的阶段里,每一个方向都是有想要拿到的一些业务目标。比如说生产,我们会强调说是不是可以提升我们的规模和多样性;在理解里,我们是不是可以强调说我们在内容语音相关的一些识别上;在推荐这,强调的是说我们的分发精准,是不是能把合适的内容推荐给合适的群体;那么在消费这一块,更多的去强调说我们的用户在我们的社区里对于我们的内容是不是感兴趣,它的效果怎么样,这样的一个消费群体是什么样的;在导流里,更多的是说我们怎么能够把视频消费这个行为的用户导到快手的可能垂类的一些内容上。

领域目标:帮助业务“看清楚”。

领域拆解:首先是四个子领域的拆分:视频供给、视频分发、视频消费和视频导流,紧接着是不同方向的业务过程及动作拆解。


4.  建设阶段

申报阶段完成之后,我们就进入建设阶段。图中,建设阶段右半部分,更多的是数据比较习惯的视角。但实际中,我们会强调非常细致的场景推导,需要有真正的业务驱动的视角,而不是大家习惯的从技术上去做拆解。例如下面我们在短视频领域中的一个实际案例,大部分的时间会聚焦在规划视角里。比如说供给里,我们会发现用户的分析的重点会更多的聚焦供给大盘供给品类,或者说黄金链路的监控;在分发这里,大家会聚焦于分级相关的一些分析;在消费这一块可能会强调链路用户推荐相关的这样的场景;在导流这一块入口转化收益。


5.  运营阶段

通过现阶段识别未来场景指导大家完成物理模型设计和落地后,就到了我们第三部分:运营阶段。在这个阶段,我们思考的是:怎么能够去把领域知识通过运营做好相应沉淀,并且保持知识处于一个长期更新且最新的状态,同时在每一个建设阶段里应该如何做好数据资产能力的输出?

首先讲讲领域资产沉淀里的领域思想沉淀。早期做数据模型输出的时候,更多的是去强调主题和层级的归属,在新的资产里我们则重点去阐述场景和能力,我们希望通过用户习惯的语言去帮助用户找到对应的资产。所以在新的资产查找路径里,我们会发现所有查找的关键点都在于用户本身对于场景的理解深不深刻,而这个确实是用户最擅长的方向,所以我们整体的一个资产输出其实是围绕着业务问题来进行。这里给大家做这样的对比,历史版本和现在版本的不同。


在运营阶段完成之后,就是领域沉淀:做好知识更新,做好资产的沉淀。这里需要进行领域知识和资产定期的盘点和评估。


6.  收益

短视频领域的建设探索完成后,由于我们对短视频领域知识有了较为整体的构建,对于供给和消费之外的场景也前置性的完成了能力覆盖。另外,由于大家在场景层面就进行了充分的讨论和整合,整体的资产是比较收敛的。

而在短视频相关的系统级产品支持上,不同业务线或多或少之前维护着一些产品,并且各自为战进行了较多烟囱式的数据建设。新的领域资产完成后,我们基于场景进行能力输出,不仅快速的完成了不同系统的数据管道替换,同时对于相似场景的重复建设和沟通成本上有了较好的抑制。整体的研发效率也有一个比较好的提升。


▌未来规划

在短视频领域建设的实践中,我们有了相对比较清楚的方法论,拿到了比较正向的收益,也坚定了我们持续使用领域建设的方法来指导快手后续数据能力建设的信心。

前面提到我们在2020年,做了短视频和活动两个业务领域。我们希望后续能够有快手十大明星领域的建设和输出。例如上图中给出的一些明确识别的方向,需要尽快落地。

另外,我们不可忽视的是,场景的增加和复杂度的提高会引入成本增加的问题,或者带来更多的技术难点。那么在未来,如何通过数据技术上的迭代,或者在数据管制上迭代去保证我们一个能力和成本的平衡性,也是我们需要去关注的一个点。


文章转载自数聚慧,如果涉嫌侵权,请发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论