基于OLAP和指标体系的电商数据服务底座

2023-11-14 15:36·DataFunTalk

导读在数据驱动的时代，电商业务线所面临的数据挑战是前所未有的。从用户行为到商品管理，从市场趋势到内容投放，每一个环节都蕴含着巨大的数据价值。如何有效地构建、管理、利用这些数据需要持续地探索和创新。本文将探讨如何利用OLAP技术有效组织和分析电商业务数据，并通过指标管理构建覆盖实时加离线，宏观、中观、微观各层用数群体的产品矩阵，以系统地解决业务问题。

在开始正题之前，先来分享几个小的场景。

• 在业务快速发展的过程中，运营同学每天都会给技术人员提数据需求，需求通常很简单，一般是希望提供一个包含某个数据的Excel表，每次需求的数据都是不一样的，但又非常的神似，执行的同学只需要改参数或者关联额外的维表就能大致实现数据的产出。
• 随着数据团队越来越大，不同业务方向的同学对外交付的看板数据会不一致，存在同名不同义的情况，每次汇报，从老板到中间执行层再到底层，每一层都要做指标和数据的反复核对，效率非常低。
• 即使已经构建好了对应的离线模型，在构建实时场景时，从数据明细层DWD层到数据服务层DWS层也都要重新构建一次，指标也需要重新拉齐一下，这与团队的划分和业务阶段是强相关的。

接下来的文章中就将介绍快手电商是如何解决这些问题的。主要包括五大部分：

1. 电商业务介绍

2. 解决方案

3. 建设成果

4. 未来规划和展望

5. Q&A

分享嘉宾｜于帅 快手 资深大数据专家

内容校对｜李瑶

出品社区｜DataFun

01电商业务介绍

1.电商业务介绍

电商业务简单来说，就是一个标准的人货场模型，下面我们分模块来讲解。

快手电商的货主要由两部分组成：

• 第一部分是快手吸引大的品牌商或者白牌供货商入驻。例如周大福等品牌进入平台供货，会有主播进行对应的选品，选完之后在自己的直播间或者其他私域场进行导流和售卖。
• 第二部分是快手邀请有自有供给的主播入驻。例如辛巴，他有自己的品牌和供给，他本身是有货的，只是需要一个场域来卖货。

有了货之后，重点是把货分销到对应的场域进行销售。快手当前最核心的场域有如下几个：

• 直播间，主播在直播间内过品，用户通过点击小黄车买货。
• 短视频，主播发一个短视频，下面会有一个购买链接。
• 泛货架，类似于一个店铺页，这个地方没有主播，也就是没有售货员，这类场景统称为货架场景。
• 大促，大促场景是在618和双十一期间上线的大促独立页面，上面会有大促会场和二级页等新的成交场。
• 站外场，不在快手上，例如通过口令分享到微信和朋友圈或者像一些微商分享到自己的万人大群，引流到快手进行成交。

最后是人的部分，通过快手内部的推荐团队，搜索团队，PUSH、SMS 等，将公域流量包括站外的人吸引到直播间进行转化。

2.业务阶段

2020年，快手电商数据团队初建。

从业务生命周期来看，电商业务已经过了初创期，进入高速成长期，用户规模百倍增长，交易规模也有对应的爆增，市场份额不断扩大。

与此同时，快手内部的团队，包括分析团队、产品团队以及运营团队等都在急速扩张，管理层到执行层，每个目标的制定以及落地动作的过程监控都需要数据进行支撑，在这个过程中我们遇到了需求爆炸问题。而当时数据准确性问题还没有解决，数据指标的一致性存在问题，也没有一套统一的指标维度矩阵，也就是说，当时的数据能力是落后于业务发展的。

3.面临的困难

在内部数据系统中，通过AB测试、看板、多维分析等对运营/DA/PM进行支持；同时数据也会以接口的形式在小店后台、生意通（类似于阿里的生意参谋）、跟播助手等实时场景对外部商家和主播进行支持。

具体的问题主要包括：

• 用户规模大：服务电商内部有数十个团队，全部门数据用户数千人，服务商家数千万人。
• 产品形态多：支撑各种形态多样的产品，比如小店后台、跟播助手、生意通、分销产品、快递物流等几十条产品线。
• 业务系统多：支持B端、C端、O端、经营决策等数十个系统。

02解决方案

1. 解决方案 打基础-统一基础数据建设

想要解决问题首先要找到问题产生的原因。

从上图左下角看，当时的开发形式是，从原始的DB和日志接入数据之后，直接开发APP的中间层，缺少对指标的管理，也缺少统一的一致性事实，如右下图所示，对DWD+DWS（一致性事实）层的构建和DIM（一致性维度）层的构建。

• 缺少一致性维度层，当时大家使用的买家维表和商家维表有几十张，这些维表大部分是相同的，但是会有一些微小的差异。
• 缺少一致性事实层，DWS层的核心是对粒度和一致性指标的管理。没有这一层就没有办法统一开发，也没有办法统一OLAP的指标。

2. 解决方案 具体流程

下面分享如何构建上节提到的解决方案。

• 业务梳理。当时业务已经有数据资产的沉淀了，因此需要独立的人力资源进行业务的梳理，包括对业务流程、业务系统、实体关系和业务角色等的详细梳理。
• 需求梳理。需求梳理完成后，会完成指标梳理和粒度确定，指标和粒度是构建指标体系和OLAP应用的核心，也是后续提效的关键，因为提效首先需要复用，而复用的就是指标和粒度的组合。
• 模型设计。基于上面的梳理结果构建中间层，也就是核心数仓，包括DIM、DWD和DWS这三层。这里需要用到一些表设计的基本规范，比如公共逻辑下沉、数据可回滚、成本性能平衡、命名清晰等。
• 开发上线。

业务过程的梳理需要将每个过程的所有环节，包括状态机都梳理清楚。以快手的领券举例，开始需要画一个泳道图，每一个图都标识清楚业务是什么样的，业务的实体关系也需要理清楚，这是做模型设计的关键指导。

指标会梳理成一个整体的指标维度矩阵，也就是所有的指标在哪些维度下是可用的，打好对应的标识。这是我们核心的资产沉淀，也是指导我们构建DWD和DWS的关键信息。

3. 解决方案 打基础-统一场景数据建设

在构建了上面的基础之后，接下来要围绕以下场景重点进行建设。

• 围绕核心的分析场景，如经营决策、流量转化、服务体验等，这也是在20年的时候最核心的需要建设的点。
• 围绕核心的业务实体，我们的业务实体当时主要是用户，之后是商家，现在扩展到用户、商家、商品等。

4. 解决方案 提效率-统一数据服务建设

数据建设完成后需要与OLAP指标中台进行联系。

首先建好核心的DWD+DWS层和DIM 层，这两层数据存储在Hive中；后续会将部分DWS基础指标和DIM同步到ClickHouse中，包括对应的中间层和维表；然后通过统一的OLAP管理系统将业务应用上的指标和维度进行拆解，并生成 SQL在下层的系统中进行查询。通过统一的应用解决个性化定制开发的问题。

回顾一下最初的问题：通过纯APP层的Hive表进行开发，堆ETL，堆人力，边际成本持续增加，而成本的增加却不能带来边际效益的提升。人越多越难管，出问题的场景和内耗也越多，难以为继。

现在是基于DWS+DIM进行多维分析建设，一处生产、多处调用。不管是研发看板还是基于指标维度的多维分析以及后端的相关产品，都可以通过这套平台统一对外提供服务。平台可以基于统一的语义生成查询接口，包括对外商家的查询API、数据API，对内OLAP的应用等，都是基于同一套数据底层的。

目前所有的取数查询都收敛至OLAP标准数据集。每月人为发起的查询次数从0增长到30W次。看板OLAP数据集依赖从0提升到上百张表，占业务整体的50%，并下线数千张APP层表，释放几十个相关DA工作，降低了用数成本。

5.解决方案 提效率-数据运营

下面分享一下数据运营的做法。

内部团队是有组织保障的，在构建好平台之后，如果大家不使用这个平台去实现指标落地管理和复用，可以简单粗暴地设置好对应的流程机制，必须按照流程执行。

外部团队，比如庞大的运营、产品和DA这些团队，是无组织保障的，要以价值优先，先解决用户的痛点，痛点解决后，自然而然就能使用我们的产品。具体做法有：

• 第一是建立对应的Oncall群，大家所有的问题都在 Oncall 群中进行解答，例如一个对应的大群，其中业务大概有几百人，每天会提几十个问题，这些问题都会得到及时的反馈；
• 第二是分不同的人群进行运营，例如DA团队重点关注的是指标的业务含义，运营团队更多关注自己的目标以及跟踪目标的进展，需要针对不同的人产出对应的指标说明，给出合理性的使用案例。

6. 解决方案 整体数据架构

介绍一下支撑整体数据指标中台的数据架构。

最下层是数据的接入，中间是一致性事实和一致性维度层，上层是围绕分析场景和核心实体构建的数据资产，最上层是有多维分析、看板、APP分析等数据应用。这些应用的基础都是通过统一的指标中台进行管理，保障指标的一致性。

03

建设成果

1. 建设成果-多维分析

我们构建了数据指标和对应的数据资产，用户在平台上看到上图这样一个多维分析的产品。其定位是多维分析、模板取数、SQL 取数、自助取数等，支持用户自助组合多维度多指标进行查询，主要面向的是产品、运营和DA 等团队。

鼠标放到指标上后，可以自动显示出该指标的详细定义，所见即所得。用户打开页面后，首先可以知道业务有多少个指标以及每个指标的含义是什么，同时如果有权限的话，可以查到对应的数据，并且数据可以以表格或者图表等多种形式进行展示。

当前针对电商业务场景，已经建立了涵盖商家、商品、营销、订单、流量、服务、分销等相关数据。

2. 建设成果-多维分析-案例

针对商家，各主营类目对 GMV 的贡献到底是怎样的，要得到这个结果，需要如下步骤：

• 首先勾选指标"支付订单金额【GMV】"、维度"商品主营类目"；
• 然后点击"+日期对比"，选择对比日期的开始时间；
• 第三选择想要展示的图表类型，可以是折线图或者饼图等；
• 最后点击"发起查询"，即可获得想要的查询结果。

3.建设成果-MBR经分数据产品

我们构建的指标中台支持了多个产品矩阵，第二个产品矩阵是不能自助查询的，是一个定制化的产品，叫经分数据产品。在公司每周的业绩回顾会上，供老板或者CEO等使用。每周MBR会议的第一部分是做业绩的展示，这个产品与前面介绍的产品是基于同一套底层，只是有更好的展示形式，通过数据中台产品提供的接口能力进行支持，面向宏观的老板视角。

4.建设成果-实时作战大屏

实时作战大屏是给主播的团队在开播期间使用的，主播在开播期间会使用这个大屏，可以看到实时的观看人数，实时的成交金额、成交订单数、退款金额以及直播间进入人数、离开人数等各种数据。同时右下角会有商品的实时点击量、曝光点击率、销售量等，这些也都是通过个统一的指标平台来进行管理的。

5.工作业绩-建设成果

下面介绍一下落地过程中整体的成果和衡量指标。整个平台是边建边运营的，构建一部分数据之后，立即就会进行推广和运营。

从多维分析使用趋势来看，自2021年1月到2021年的10月，平台使用次数从1000+次左右涨到了7.5万次，现在已经达到了几十万次；使用人数从20多个人增长到了900+人，基本上完成了对所有核心人员的覆盖。

从运营效率看，与其他数据团队比我们的运营效率是遥遥领先的。运营效率提升的要点是我们可以贴身服务业务，让业务知道我们有什么，同时他的问题也可以及时得到解决。

• 下面介绍一下落地过程中整体的成果和衡量指标。整个平台是边建边运营的，构建一部分数据之后，立即就会进行推广和运营。
• 从多维分析使用趋势来看，自2021年1月到2021年的10月，平台使用次数从1000+次左右涨到了7.5万次，现在已经达到了几十万次；使用人数从20多个人增长到了900+人，基本上完成了对所有核心人员的覆盖。
• 从运营效率看，与其他数据团队比我们的运营效率是遥遥领先的。运营效率提升的要点是我们可以贴身服务业务，让业务知道我们有什么，同时他的问题也可以及时得到解决。

下面介绍一下落地过程中整体的成果和衡量指标。整个平台是边建边运营的，构建一部分数据之后，立即就会进行推广和运营。

从多维分析使用趋势来看，自2021年1月到2021年的10月，平台使用次数从1000+次左右涨到了7.5万次，现在已经达到了几十万次；使用人数从20多个人增长到了900+人，基本上完成了对所有核心人员的覆盖。

从运营效率看，与其他数据团队比我们的运营效率是遥遥领先的。运营效率提升的要点是我们可以贴身服务业务，让业务知道我们有什么，同时他的问题也可以及时得到解决。

04未来规划和展望

上图展示了快手的大模型。第一个问题是有一个订单表，字段有订单ID、商品ID、下单时间、支付时间等，希望算一下每个商品的总支付金额，可以看到这段 SQL 跟我们的表结构是完全一致的，可以生成一个对应的结果SQL去计算数据。

另外一个问题是快手一天的DAU是多少？大模型会给我们一个提示， DAU是xxx亿，这个数字大家可以从财报上看到，同时大模型也给出了对业务的理解，这个数字反映了什么，这个信息是通过我们对语义层的标准化定义之后才能使用的。

我们未来的指标OLAP 系统的发展方向大致如上图所示。

当前指标OLAP 系统建设完成后如左边所示，作为数据的中间件去支持看板、自助查询、 AB 等各个不同方向的产品，是用户和数据系统以及数据平台之间的交互界面。

未来希望交互界面变成右边的样子，每个用户都会有一个 AI 助手，我们可以提问问题，比如如下的场景：

今天电商的 GMV 是多少？主要是什么原因带来的增长？用户不需要通过所有的看板逐个去找自己需要的数据，找到之后，如果发现 GMV 涨了，又要通过归因平台继续找增长的归因，到底是哪个维度细分下的变量变了之后而产生的增长。

618期间，哪些主播带来大牌大补的商品？这些商品主要的卖点是什么？这些我们在元数据里边已经录入了，但是每次查询都是用户先去找到 DA 同学，DA同学去写SQL或者说通过前面OLAP平台找到这些数据，找的过程包括查询的过程是非常耗时的。因为确实有一些用户需要有辅助服务，他们自己学会使用看板和自助查询以及一些SQL是比较困难的。如果可以通过人工语义去解决这些问题，则可以提升整体的数据使用效率。

大模型可以使用数据的关键是OLAP 系统的指标维度的语义一定要定义清楚，下面的数据也要搞清楚。未来的场景大致是这样，数仓搞清楚DIM、DWD、 DWS 这三层，OLAP系统管理好中间的指标维度，然后这套东西的元数据作为输入放到大模型中，大模型可以针对每个人每个场景产生对应的AI 助手。这就是我们对未来的展望。

最后，快手电商期待各位的加入，简历可以投递到以下邮箱：yushuai@kuaishou.com。

05Q&A

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索引的方式去提升性能。

今天的分享就到这里，谢谢大家。