基于OLAP和指标体系的电商数据服务底座
导读在数据驱动的时代,电商业务线所面临的数据挑战是前所未有的。从用户行为到商品管理,从市场趋势到内容投放,每一个环节都蕴含着巨大的数据价值。如何有效地构建、管理、利用这些数据需要持续地探索和创新。本文将探讨如何利用OLAP技术有效组织和分析电商业务数据,并通过指标管理构建覆盖实时加离线,宏观、中观、微观各层用数群体的产品矩阵,以系统地解决业务问题。
在开始正题之前,先来分享几个小的场景。
在业务快速发展的过程中,运营同学每天都会给技术人员提数据需求,需求通常很简单,一般是希望提供一个包含某个数据的Excel表,每次需求的数据都是不一样的,但又非常的神似,执行的同学只需要改参数或者关联额外的维表就能大致实现数据的产出。
随着数据团队越来越大,不同业务方向的同学对外交付的看板数据会不一致,存在同名不同义的情况,每次汇报,从老板到中间执行层再到底层,每一层都要做指标和数据的反复核对,效率非常低。
即使已经构建好了对应的离线模型,在构建实时场景时,从数据明细层DWD层到数据服务层DWS层也都要重新构建一次,指标也需要重新拉齐一下,这与团队的划分和业务阶段是强相关的。
接下来的文章中就将介绍快手电商是如何解决这些问题的。主要包括五大部分:
1. 电商业务介绍
2. 解决方案
3. 建设成果
4. 未来规划和展望
5. Q&A
01
电商业务介绍
1.电商业务介绍
第一部分是快手吸引大的品牌商或者白牌供货商入驻。例如周大福等品牌进入平台供货,会有主播进行对应的选品,选完之后在自己的直播间或者其他私域场进行导流和售卖。 第二部分是快手邀请有自有供给的主播入驻。例如辛巴,他有自己的品牌和供给,他本身是有货的,只是需要一个场域来卖货。
有了货之后,重点是把货分销到对应的场域进行销售。快手当前最核心的场域有如下几个:
直播间,主播在直播间内过品,用户通过点击小黄车买货。
短视频,主播发一个短视频,下面会有一个购买链接。
泛货架,类似于一个店铺页,这个地方没有主播,也就是没有售货员,这类场景统称为货架场景。
大促,大促场景是在618和双十一期间上线的大促独立页面,上面会有大促会场和二级页等新的成交场。
站外场,不在快手上,例如通过口令分享到微信和朋友圈或者像一些微商分享到自己的万人大群,引流到快手进行成交。
2.业务阶段
3.面临的困难
用户规模大:服务电商内部有数十个团队,全部门数据用户数千人,服务商家数千万人。 产品形态多:支撑各种形态多样的产品,比如小店后台、跟播助手、生意通、分销产品、快递物流等几十条产品线。 业务系统多:支持B端、C端、O端、经营决策等数十个系统。
1. 解决方案 打基础-统一基础数据建设
缺少一致性维度层,当时大家使用的买家维表和商家维表有几十张,这些维表大部分是相同的,但是会有一些微小的差异。 缺少一致性事实层,DWS层的核心是对粒度和一致性指标的管理。没有这一层就没有办法统一开发,也没有办法统一OLAP的指标。
业务梳理。当时业务已经有数据资产的沉淀了,因此需要独立的人力资源进行业务的梳理,包括对业务流程、业务系统、实体关系和业务角色等的详细梳理。 需求梳理。需求梳理完成后,会完成指标梳理和粒度确定,指标和粒度是构建指标体系和OLAP应用的核心,也是后续提效的关键,因为提效首先需要复用,而复用的就是指标和粒度的组合。 模型设计。基于上面的梳理结果构建中间层,也就是核心数仓,包括DIM、DWD和DWS这三层。这里需要用到一些表设计的基本规范,比如公共逻辑下沉、数据可回滚、成本性能平衡、命名清晰等。 开发上线。
3. 解决方案 打基础-统一场景数据建设
围绕核心的分析场景,如经营决策、流量转化、服务体验等,这也是在20年的时候最核心的需要建设的点。 围绕核心的业务实体,我们的业务实体当时主要是用户,之后是商家,现在扩展到用户、商家、商品等。
4. 解决方案 提效率-统一数据服务建设
第一是建立对应的Oncall群,大家所有的问题都在 Oncall 群中进行解答,例如一个对应的大群,其中业务大概有几百人,每天会提几十个问题,这些问题都会得到及时的反馈; 第二是分不同的人群进行运营,例如DA团队重点关注的是指标的业务含义,运营团队更多关注自己的目标以及跟踪目标的进展,需要针对不同的人产出对应的指标说明,给出合理性的使用案例。
1. 建设成果-多维分析
首先勾选指标“支付订单金额【GMV】“、维度“商品主营类目“; 然后点击“+日期对比”,选择对比日期的开始时间; 第三选择想要展示的图表类型,可以是折线图或者饼图等; 最后点击“发起查询”,即可获得想要的查询结果。
下面介绍一下落地过程中整体的成果和衡量指标。整个平台是边建边运营的,构建一部分数据之后,立即就会进行推广和运营。 从多维分析使用趋势来看,自2021年1月到2021年的10月,平台使用次数从1000+次左右涨到了7.5万次,现在已经达到了几十万次;使用人数从20多个人增长到了900+人,基本上完成了对所有核心人员的覆盖。 从运营效率看,与其他数据团队比我们的运营效率是遥遥领先的。运营效率提升的要点是我们可以贴身服务业务,让业务知道我们有什么,同时他的问题也可以及时得到解决。
Q1: 数据团队是如何将多个相似名字或者相似口径的指标统一成一个的?怎么样推动使用方愿意去做这些改变?
A1: 这个问题分成两部分来讲,我们确实也碰到这个问题。怎么去解决同名不同义,同义不同名的建设问题。我们从各个业务方收集对应的指标,然后拆解成所有的原子指标和维度。这块我们给出一个标准定义,例如A团队的GMV含什么的不含什么的,B团队的GMV含什么的,可能含a业务不含b业务等等,这些都是有一些差异的。我们把不同团队的这定义或者目标都全部拉齐,拉齐之后去两边看和他们的理解是不是一致。如果不一致,我们会直接上升到管理层,因为所有的指标都是用来做未来业绩的预测和目标管理的,管理层有最终解释权。目标管理就是怎么给产品团队、运营团队下目标,他们怎么去拆解自己的动作。这块的核心解释权在管理层。多个业务团队之间口径拉不齐或者说希望调口径的场景,如果是OKR制定、目标拆解、过程监控等,这些执行团队其实是没有身位自行制定的,因为他可能会站在自己的立场从自己的利益出发去调。所以核心的业务目标我们是直接上升到管理层去拉齐,各个团队只能被动接受。指标一致无外乎分几层,从上到下来说,上面是计算口径,你的计算口径到底含什么不含什么;最底层是数据源,数据源从什么地方来,是埋点日志、前端日志还是后端日志,这些都是可以捋清楚并针对每一层进行对齐和讲解。Q2: 大模型依赖标准化指标建设吗?A2: 是需要依赖标准化指标建设的。如果我们有足够大的行为数据,大模型也是能找到一个最优解的。但是在我们内部只有我们几千人使用约几十上百个看板,十几个数据产品,这样的场景下,因为数据量不足,让大模型自己找到正确的答案效率非常低。如果我们有现成的人工梳理好的数据喂给大模型,大模型重点去解决基础数据产品和人的自然语言交互问题,这块效率会很高。Q3: 冷存Hive与热存CK,为什么这样设计?有什么考虑吗?A3: 第一,冷存的Hive,因为快手的数据量级每天增量大约是数万亿,这样海量的数据只能放冷存。第二,只有关键的指标层才会建设好之后存到CK 中,并通过CK提供OLAP服务。冷存层首先会做历史长期数据的存储,例如说三年、五年的数据;其次为无法通过OLAP支持的场景提供数据支持,例如说算法团队可能直接使用Hive中间数据。所以冷存层是必须要有的,冷存层只有一部分数据会对接到热存中,例如高频查询的指标和接口需要用到的数据。这两层可以类比国外一些公司部署的金集群和银集群这样的架构。Q4: 数据整体架构中基础数据和场景数据怎么不同设计不同布局?A4: 基础数据还是面向业务本身的,也就是业务有什么我们就构建什么,重点是要解决业务场景的覆盖度以及业务的一致性。数据尽量完成整体覆盖,而不仅仅是业务是高频使用的。业务高频使用的数据是围绕着核心的业务实体的,例如用户的宽表、商家的画像表以及商家商品的标签表等;或者一些流量全链路或者说黄金链路的分析场景是最高频使用的。这一层完全依赖于前面的基础层进行构建,底层可以认为是DWD+DWS 层,而业务场景重点是DWS 和 Topic 层。Q5: 数据提取的一个难点是数据权限问题,如果是基于SQL的话,可能粒度会比较粗,还有一个是基于指标API,大模型提取是基于指标API还是基于SQL的?A5: 权限问题目前确实还没有考虑到,因为现在还是在探索期。但是刚才问到的问题会作为我们的输入,影响我们后续的方案设计。数据安全问题,业界也在尝试,可能会基于隐私计算有一些相关的解决方案,我们可能会把数据做一些模糊处理等等。智能交互是基于SQL 还是基于指标API,这两个都是有场景的。但是如果要把大模型提取做好的话,还是建议要基于标准化的数据来做,准确性会更高,因为我们把指标维度都管理好了,那用户问到指标维度的问题,依靠元数据就能够充分地理解到用户的意图,转换为指标维度的查询提取数据。整个链路是先拿到用户的问题,然后做语义理解,这里面会借助于向量数据库存储context以及相似度检索能力,再然后借助大模型理解需求,转换成我们的查询接口。Q6: ClickHouse中热数据相互有join吗?实际使用中遇到什么问题吗?未来会继续沿用CK吗?A6: 目前是有的,Join非常多。数据导入之后就变成一个星型模型了,所有的维度都会频繁地被引用。当前碰到的最大的问题是查询的性能问题。例如P90我们希望控制到5秒以内,但是实际上现在是二三十秒。我们目前没有考虑过换引擎,当前的解决方案是以另外一种方式完成,例如优化关联的维表,把一个大表的热数据拿出来变成小表,或者以增加稀疏索引和hash索引的方式去提升性能。今天的分享就到这里,谢谢大家。分享嘉宾
INTRODUCTION
于帅
快手
资深大数据专家
快手资深大数据专家,11年大数据研发管理经验。在快手依次负责公司上市项目、电商基建数据团队、电商C端数据团队的搭建与管理,在数据的采建管用等方面有丰富经验。
峰会推荐
限时免费资料
往期推荐