4

面向行为分析的数据治理和应用

 1 year ago
source link: https://www.6aiq.com/article/1688027641683
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

导读 本文将分享奇富科技-数据生态团队如何对面向行为分析的数据进行治理和应用。

全文目录:

  1. 常见的数据分析场景

  2. 数仓建模方法

  3. 数仓建模方法的优劣势

  4. 面向行为分析的分析方法-概念

  5. 面向行为分析的分析方法-整体架构

  6. 面向行为分析的分析方法-分析举例


分享嘉宾|贾毅宁 360数科 数据生态总监

编辑整理|王鹏 滴滴出行

出品社区|DataFun


01/常见的数据分析场景

常见的数据分析就是对业务数据或者行为数据进行分析和管理。

image-e42183beecca4e948a6f197eb56cc2bb.png-imageStyle

业务数据主要是指用户行为发生之后,实际产生的结果,我们使用数仓建模来给业务提供指标,从而指导业务进行一些正向的操作或者修改之前的一些操作。行为数据主要是指用户使用产品上的各种行为,我们可以对面向行为分析的数据进行加工和分析,从用户的行为中推导出来到底是哪些环节没有做好,从而调整和优化这些环节。

02 /数仓建模方法

在引入行为分析方法之前,先介绍一下数仓建模的方法。

image-f8fd0d1f3e1f413c9b5036a967015db3.png-imageStyle

数仓建模方法主要流程如下:

  • 用户空间:以音乐播放为例,用户在APP上的操作会产生行为日志,比如广告请求、曝光、点击,APP打开、用户注册和播放、下载歌曲等操作日志。
  • 数仓建模:我们将用户的行为日志采集过来,形成ODS、DWD层的表,再往后是各个主题表。不同业务团队会创建自己的业务宽表,从用户空间中抽取感兴趣的事件放到各自的主题业务宽表中。
  • 主题应用:再往下是这些主题宽表所支撑的业务,比如报表建设、特征挖掘、机器学习、OneID系统建设等等,最终为增长团队、经营团队和产品团队等提供支持。

03/数仓建模方法的优劣势

1. 优势

  • 方法论成熟 : 已经在无数的公司中被验证过,更有像《阿里巴巴大数据实践》《Building The Data Warehouse》 等优秀的指导书籍。
  • 技术栈成熟: 无论是从消息中间件、数据ETL管路,数据湖、数据仓库、数据集市的各种选型等,工业界已经诞生了无数优秀的框架和数据库。
  • l技术供应商支持完善:Google,Amazon,Microsoft,阿里云,腾讯云等供应都提供几乎一站式的服务。
  • 技术人才供给: 各个互联网公司都有数据仓库建模的需求,人才供应充分,培养体系完备。
  • 公司推动阻力小: 数仓的重要性经历了充分的市场教育,推动起来会比较顺畅,投入产出比也比较好阐述。
  • 应用场景:适合指标类的多维分析数据运算。

2. 劣势

  • 建设链条长: 数据采集->ODS->DWD->DWT->数据报表和应用。
  • 数据一致性保证有挑战:不同数据主题之间会有指标和字段的重合,在工程和业务之间,不同的工程团队之间都可能造成理解的偏差。
  • 扩展字段流程复杂:表结构需要预先定义, 扩展新字段往往需要较长的开发周期和回溯数据周期。
  • 工程实现很难统一: 架构评估往往取决于承接的工程团队的过往经验和喜好,同样需求的实现差异较大。
  • 不适合时序行为数据分析:因为需要按照用户维度shuffle和开窗,用户行为分析往往比较耗资源。
  • 预聚合不够灵活:当维度不能命中预聚合的维度时,查询会退化成全表聚合。

04/面向行为分析的分析方法-概念

image-36faa73eb5184bffaa4a4dd075526e60.png-imageStyle

基于以上数仓建模的优缺点,我们需要对行为数据进行一些不一样的抽象,用一些不一样的查询方式来解决面向用户行为数据的问题。首先来介绍一些概念:

  • 用户空间:和数仓建模一样,这部分不变
  • 用户事件序列:和数仓建模方式不同,我们这里不将用户的行为日志抽象到ODS、DWD层,在这里将行为日志数据抽象成用户事件序列,比如对于播放歌曲事件会包含用户属性和事件属性,用户属性回答谁在什么样的设备上这个问题,事件属性回答这个人主要做了什么事, 这个事我怎么去描述它。对于所有事件,我们都可以用这两种类型的元数据来描述这个事件,在一个时间轴上串起来,就可以知道这件事是谁做的,以及做了这件事后发生了什么
  • 事件抽象:有了用户序列的抽象,我们可以聚焦一下,看某个人在某个具体事件序列上的抽象。比如图中会员升级的例子
  • 用户群计算:有了事件抽象之后,最重要的就是我们怎么使用这些数据,我们可以利用这些数据来获取新增用户群、活跃用户群以及满足X条件的用户群等等
image-263bfe75ac7e40fb825b58937b880a39.png-imageStyle

如上图所示,以7日Android用户的留存率为例,左边是传统数仓的解决方案,右边是行为分析的解决方案。

  • 传统数仓的解决方案:主要是写一个SQL来看7天前的新增用户在今天的活跃用户中是否有,如果有的话,7天的新增用户作为分母,今天的活跃用户作为分子,除出来一个比例计算留存率。但是可能在数仓里面,一条记录并不是用用户的ID来划分的,所以最终想要计算出用户ID的结果会有一个shuffle、关联、数据倾斜的过程,这都是在传统输出解决方案当中我们需要去考虑的一些点。
  • 行为分析的解决方案:这是另外一种简化的计算用户留存的方式,本质上是在图中的三个圈圈选的用户中做计算,三个圈的交集就是7天前的新增用户在今日活跃用户中的比例。我们将复杂留存SQL转成了三个用户群之间并集和交集的计算。

所以我们现在已经有了两层抽象,对于数据的抽象,是用时间线排进来的一个个的事件,对于计算的抽象,是把一个查询拆解成一个个用户群的计算,再根据计算的结果回答我们一个个关于用户群相关的问题。

05/面向行为分析的分析方法-整体架构

下面是面向行为数据分析的整体架构(该架构可供参考,但并非唯一解)。

image-7f6fc261e783487e86d5f916ca3027ba.png-imageStyle

从下往上看,最下面是数据的存储,采用列式存储,并在其中应用一些对用户群更友好的技术,从而减少数据的加载量和分发量。往上是文件元数据/列元数据。再上面是用户数据访问层,本质上就是计算层。IDMapping层主要解决不同ID对应同一用户的问题。查询缓存层、查询结果聚合层,以及最上面的查询接入层,都是为了提高查询效率。

下图是对于7日的Android用户留存率,在面向行为数据分析的架构中的实现过程抽象:

image-63054cc53df541b08e1a6141a48d6550.png-imageStyle

接下来是对于面向行为数据分析架构中关键节点的介绍。

1. 列存储

image-c66e0a4e3078412b911bfb40b0b7367e.png-imageStyle

首先介绍我们自定义的列存储。我们没有使用ORC、Parquet这些列存储格式,主要是因为ORC、Parquet格式不会对用户存储做一些自定义的优化,市面上的Druid、HBase也是为了加速数据访问引用了很多的组件。对于特定的场景,我们可以把更多的组件应用过来,比如说BloomFilter(布隆过滤器),目的是快速判断一个用户是否在当前文件中,因为我们所有的查询其实都是面向用户ID的。还有Delta encoding(差分编码),用来对时间格式进行存储,减少时间戳的存储体积。

2. 元数据

image-c4a0b56604a34cab805c3a291b738d59.png-imageStyle

列存储再往上一层就是元数据。首先是文件元数据。文件的第一级索引是按时间的,而时间是动态的,因为用户的活跃时间可能是在晚上或者中午的休息时间,凌晨可能用户并不活跃。这就导致我们文件中存储的用户数据在时间上不是平均分配的,比如想要查询凌晨1点到早上9点的数据,有可能需要访问多个文件。这个时候我们需要知道应该在动态时间切片文件中访问哪些文件。因此我们就需要一个元数据的管理,基于查询的起止时间,找出存储的位置,这样可以确保每个文件存储的大小是相近的,尽可能减少数据计算过程中的数据偏移。

其次是列元数据。我们查询的时候并不是要把所有的列都加载进来,计算的时候只加载文件中对应偏移量的列数据,这样可以减少网络传输的开销、磁盘IO和内存使用量。

3. OneID

image-5257684159ab40f49833bfa5fc1f1963.png-imageStyle

OneID的建设在每家公司是不一样的,但本质上都是用来追踪用户的设备变化,还原用户事件的最真实状态,进而提供IDMapping、ID Encoding的能力。

4. 缓存层

image-248b12186e3148339af3a6b473efb2d6.png-imageStyle

缓存层主要是对以前访问数据的缓存,加速访问。缓存key中有时间的版本号,数据可能会因为回填等原因引入新数据,通过时间版本号的方式可以自动刷新缓存。

5. 用户数据访问层

image-ad934fd6ada1430bbcc2be215f312fd9.png-imageStyle

用户数据访问层包括数据的聚合层、用户群算子层以及元数据管理和底层时序数据的加载。首先,用户请求会包含时间范围、过滤条件、用户群聚合条件等;第二步,根据用户请求,请求元数据,确定要访问的文件和列在哪里;第三步,知道了数据在哪后,加载数据到计算节点,并缓存到本地;第四步,用户分区计算,最大化并行查询效果;最后,进行聚合计算。

通过以上架构,我们希望在查询时,只去加载最低密度的数据,在不同节点之间通讯时只去通讯最必要的用户群的bit数组,最终也是通过bit运算的方式返回,再通过OneID将bit数组还原成所关心的用户群的一个详细的描述。

06/面向行为分析的分析方法-分析举例

下面是行为分析的几个例子。

首先是用户留存分析。

image-aae7c08b5805436da1747600f28e8cef.png-imageStyle

上图中包含了7月29日至8月8日(第5天到第10天)之间的留存率。对于行,只需要计算7月29日至8月8日之间每天的新增用户。对于列,只需要计算行时间+偏移量的活跃用户数。而整个表格的计算就是对两个用户群进行逻辑与。这样就把表格的计算拆成了一个个单元格的独立的计算,每一个独立的计算都可以通过预计算保存在缓存中,还可以通过一些好的用户交互方式,实现自助的留存率分析。

image-de033ec6a425472395cb228a35b48a01.png-imageStyle

第二个常用的分析是漏斗分析。比如分析做了播放的用户中,有多少进行了收藏,收藏的用户又有多少进行了购买,购买的用户中有多少下载了歌曲。漏斗分析又有时序严格和非严格之分。时序严格的转化漏斗,必须是发生在时序严格递增的场景下,同一个session内,一定是先播放,再收藏,再购买,最后下载。非时序严格的转化漏斗常用来进行趋势分析,有可能先购买再播放。对于非时序严格的转化漏斗,采用垂直切,我们只需要去分别计算每一个事件的用户群,再做与关系。时序严格的转化漏斗,要采用水平切,计算一个session内既播放,又收藏,购买并且下载了的用户群,再用搭积木的方式计算出来。

image-b1304c4d3e724538a8b663b104f8e0c6.png-imageStyle

第三个分析的例子是路径分析。常用于某个业务指标转化不好时进行分析。首先定义事件的入度和出度,也就是一个事件的前一个和后一个事件。计算采用深度遍历的方式。

07/回顾

  • 分析了行为分析和指标分析的主要差异
  • 阐述了数仓建模方式的优劣势,更适合用来做指标分析
  • 阐述了行为分析的主要概念和分析思路的不同
  • 阐述了行为分析系统建设的主要层次
  • 阐述了行为分析系统每个层次的主要应用的技术
  • 阐述了行为分析的主要支持的三个分析场景

以上就是本次分享的内容,谢谢大家。


▌2023数据智能创新与实践大会

数据架构/数据效能/智能应用/算法创新......

4大体系,专业解构数据智能

16个主题论坛,覆盖当下热点与趋势

70+演讲,兼具创新与最佳实践

1000+专业观众,内行人的技术盛会

点击下方链接了解详情:

https://www.bagevent.com/event/8416932?bag_track=zhihu


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK