万字详解:知乎用户画像与实时数仓的架构与实践

本文详细介绍知乎如何利用ApacheDoris构建高响应实时数据架构,实现用户画像、实时业务分析和算法特征,提升业务响应速度与成本效益,以及应对挑战和实践案例。

用户画像与实时数据分析是互联网企业的数据核心。知乎数据赋能团队以 Apache Doris 为基础,基于云服务构建高响应、低成本、兼顾稳定性与灵活性的实时数据架构,同时支持实时业务分析、实时算法特征、用户画像三项核心业务流,显著提升对于时效性热点与潜力的感知力度与响应速度,大幅缩减运营、营销等业务场景中的人群定向成本,并对实时算法的准确率及业务核心指标带来明显增益。

关键词:数据仓库,Apache Doris,用户画像,实时数据

一、前言

知乎业务中,随着各业务线业务的发展,逐渐对用户画像和实时数据这两部分的诉求越来越多。对用户画像方面,期望有更快、更准、更方便的人群筛选工具和方便的用户群体分析能力。对于实时数据方面,期望拥有可以实时响应的用户行为流,同时在算法特征、指标统计、业务外显等业务场景有愈来愈多的数据实时化的诉求。

在 2021 年 8 月,知乎平台团队成立数据赋能团队。针对历史实时数据需求无承接方的现象,已有用户画像系统无法满足多样的人群定向的现状,及业务方进一步人群分析的业务诉求,提出基础设施层选用Apache Doris作为实时数据仓库技术选型,业务工具层建设实时数据集成、实时数据调度、实时数据质量中心等系统,应用层建设实时数据应用和用户画像应用的方案。该方案针对性地解决了业务痛点,满足了业务诉求。

拆分当前业务主要在实时数据和用户画像两大部分有难点,共包含如下的三个方向目标:

1)实时业务数据

  • 通过提供实时的业务指标,解决业务对热点、潜力的把控,助力生产、消费,提升优质创作量及内容消费能力。

  • 提供实时的复杂计算的外显指标,加强用户体验,解决业务侧通过后端脚本计算的高维护成本和复杂性,节约成本,提升人效。

2)实时算法特征

  • 以实时数据为基础,提供多样的实时算法特征,与算法团队共同提升 DAU、留存、用户付费等核心指标。

3)用户画像

  • 用户筛选,做到多维、多类型的定向筛选,并接入营销、广告、 运营平台等系统,提高业务效率,降低人员成本。

  • 用户分析,做到多角度用户分析,定向用户分析报告 0 成本,助力业务部门快速把握核心客户市场。

本文就知乎平台的数据赋能团队,基于以上三个方向的目标,就这四个问题,来逐一介绍这方面的技术实践经验和心得体会:

  • 如何通过实时数据驱动业务发展?

  • 如何从 0 -> 1 搭建实时数据中心?

  • 如何搭建一套高效快速的用户画像系统来解决历史系统的多种问题?

  • 如何快速高效的开发业务功能和保证业务质量?

1、名词解释

2、实时数据与用户画像与各业务的结合

二、面临的挑战和痛点

针对当前业务目标,主要有以下几个具体要求。

1、有价值

1)如何通过实效性发现业务价值?

  • 搭建热点、潜力等紧随时间的指标和相关的排行榜,直接支持业务发展。

2)如何让用户画像的筛选和分析能力最大化?

  • 要全面覆盖多维度用户筛选的多种需求。

  • 多角度、多方式覆盖用户分析。

2、数据时效性

1)推荐页首屏浏览 6 条内容,如何在第二刷的时候就立即感知到最新的用户行为?

  • 通过 UBS 建设提升实效性(下面介绍)

2)在推荐算法中,非常实时的特征推荐算法效果要比天级别更新特征的算法效果好很多,如何保证 10 分钟内算法受到特征变更?

  • 通过实时数据系统与 Apache Doris配合共同建设,提升到 10 分钟内更新(下面介绍)

3、接口实时性

热点运营场景,期望用户画像服务能在秒级别快速筛选出大量人群,用户后续的推送等运营场景,如何解决?

  • 通过用户画像系统与 Apache Doris 配合共同建设,提升人群筛选的速度(下面介绍)

4、复杂性

1)实时数据几乎没有 count、sum 需求。几乎都是复杂去重和多数据联合计算的情况。

  • 以播放量为例。在启播、暂停、完播、心跳等多个条件下,会同时有多个点,要进行去重。同时基于视频回答、视频的关系和双作者联合创作的关系,需要叠加,同时保证在父子内容异常状态的情况下过滤其中部分播放行为。

2)人群分析业务,期望多角度、各维度进行人群关联计算,同时基于全部用户特征针对当前人群和对比人群进行 TGI 计算,筛选出显著特征,如何解决?

  • 通过用户画像系统与 Apache Doris 配合共同建设,解决复杂的人群分析(下面介绍)

3)业务数据中有增 / 删 / 改逻辑,如何实时同步?

  • 实时数据集成系统与 Apache Doris 配合共同建设,解决增 / 删 / 改逻辑(下面介绍)

4)明细数据异常发现滞后,异常发现后,需要针对性修正构建方式,及回溯数据修复,如何解决?

  • 通过选择 Lambda 架构作为数据架构解决(下面介绍)

三、实践及经验分享

1、整体业务架构

基于当前的业务,从顶层至底层进行了拆分。主要分为应用层、业务模型层、业务工具层、基础设施层。基于我们当前的业务形态,自上而下。

  • 应用层: 负责当前我们的业务应用,直接为业务提供工具或提供业务的某些模块,与业务共担目标,为业务赋能。

  • 业务模型层: 支持应用层建设和一定的实时分析能力,同时也作为业务某一个流程的功能模块接入使用,为外部业务和自身应用层建设,与业务共担目标,为业务赋能。

  • 业务工具层: 支持应用层和业务模型层的开发,提供通用的工具,面向降低应用层和业务模型层的建设成本,提升整体建设的工程效能,保证业务稳定和数据质量准确。

  • 基础设施: 技术中台提供的基础设施和云服务,提供稳定可用的基础功能,保证上层建筑的稳定性。

2、实时数据的数据架构选型

解决当前问题的数据架构,一般有 Lambda 架构和 Kappa 架构。针对当前业务特点,计算复杂、偶发的异常问题需要大数据量回溯等特性。当前实时数据的数据架构采用的是 Lambda 架构。由 Doris 承载分钟级的批处理,Flink 来承载秒级别简单逻辑的流处理。具体如下:

3、应用层建设经验分享

1)实时数据系统

①业务场景

实时数据系统主要有两个大方向:实时业务数据和实时算法特征。

  • 实时业务数据

  • 通过提供实时的业务指标,解决业务对热点、潜力的把控,助力生产、消费,提 升优质创作量及内容消费能力。

  • 提供实时的复杂计算的外显指标,加强用户体验,解决业务侧通过后端脚本计算的高维护成本和复杂性,节约成本,提升人效。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值