一、前言

知乎业务中，随着各业务线业务的发展，逐渐对用户画像和实时数据这

两部分的诉求越来越多。对用户画像方面，期望有更快、更准、更方便

的人群筛选工具和方便的用户群体分析能力。对于实时数据方面，期望

拥有可以实时响应的用户行为流，同时在算法特征、指标统计、业务外

显等业务场景有愈来愈多的数据实时化的诉求。在 2021 年 8 月，知

乎 平台 团队成立数据赋能组。针对历史实时数据需求无承接方的现象，

已有用户画像系统无法满足多样的人群定向的现状，及业务方进一步人

群分析的业务诉求。故提出基础设施层选用百度智能云的 Palo 作为实

时数据仓库，业务工具层建设实时数据集成、实时数据调度、实时数据

质量中心等系统，应用层建设实时数据应用和用户画像应用的方案。该

方案针对性地解决了业务痛点，满足了业务诉求。拆分当前业务主要在

实时数据和用户画像两大部分有难点，共包含如下的三个方向目标： 实

时业务 数据

1 、通过提供实时的业务指标，解决业务对热点、潜力的把控，助力

生产、消费，提升优质创作量及内容消费能力。

2 、提供实时的复杂计算的外显指标，加强用户体验，解决业务侧通

过后端脚本计算的高维护成本和复杂性，节约成本，提升人效。

实时算法特征

1 、以实时数据为基础，提供多样的实时算法特征，与算法团队共同

提升 DAU 、留存、用户付费等核心指标。用户画像

1 、用户筛选，做到多维、多类型的定向筛选，并接入营销、广告、

运营平台等系统，提高业务效率，降低人员成本。

1 、用户分析，做到多角度用户分析，定向用户分析报告 0 成本，助

力业务部门快速把握核心客户市场。

本文就知乎平台的数据赋能团队，基于以上三个方向的目标，就这四个

问题，来逐一介绍这方面的技术实践经验和心得体会：

1 、如何通过实时数据驱动业务发展？

2 、如何从 0 -> 1 搭建实时数据中心？

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

题？

4 、如何快速高效的开发业务功能和保证业务质量？

1.1 名词解释

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

二、面临的挑战和痛点

针对当前业务目标，主要有以下几个具体要求。 1 ）有价值

1 、如何通过实效性发现业务价值？

1.1 、搭建热点、潜力等紧随时间的指标和 相关 的 排 行 榜 ， 直 接 支

持 业务发展。

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

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

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

2 ）数据实效性

1 、 推荐页首屏浏览 6 条 内容，如何在 第 二 刷 的时 候 就立 即感 知到 最

新 的用户行为？

1.1 、通过 UBS 建设提升实效性 （ 下面介绍 ） 。

2 、在 推荐 算法中， 非常 实时的特征 推荐 算法效 果 要 比天级别 更 新 特

征的算法效 果好很 多，如何保证 10 分 钟 内算法 受 到特征 变 更？

2.1 、通过实时数据系统与 Palo 配合 共同建设，提升到 10 分 钟 内

更 新（ 下面介绍 ） 。

3 ）接口实时性

1 、热点运营场景，期望用户画像 服 务能在 秒级别 快速筛选出大量人

群，用户后 续 的 推送 等运营场景，如何解决？

1.1 、通过用户画像系统与 Palo 配合 共同建设，提升人群筛选的

速度 （ 下面介绍 ） 。

4 ）复杂性

1 、实时数据几乎 没 有 count 、 sum 需求。几乎 都是 复杂 去重 和多数

据 联合 计算的 情况 。

1.1 、以 播放 量为 例 。在 启播 、 暂停 、 完播 、心 跳 等多个 条件 下，

会同时有多个点，要进行 去重 。同时基于 视频回答 、 视频 的 关 系和 双 作

者联合 创作的 关 系，需要 叠 加，同时保证在 父子 内容 异常 状 态 的 情况 下

过 滤其 中部分 播放 行为。

2 、人群分析业务，期望多角度、各维度进行人群 关联 计算，同时基

于 全 部用户特征针对当前人群和对 比 人群进行 TGI 计算，筛选出显 著

特征，如何解决？

2.1 、通过用户画像系统与 Palo 配合 共同建设，解决复杂的人群

分析 （ 下面介绍 ） 。

3 、业务数据中有 增 / 删 / 改逻辑 ，如何实时同步？

3.1 、实时数据集成系统与 Palo 配合 共同建设，解决 增 / 删 / 改逻

辑（ 下面介绍 ） 。

4 、 明细 数据 异常 发现 滞 后， 异常 发现后，需要针对性 修正构 建方 式 ，

及 回溯 数据 修 复，如何解决？

4.1 、通过选 择 Lambda 架构 作为数据 架构 解决 （ 下面介绍 ） 。

三、实践及经验分 享

3.1 整体业务架构

基于当前的业务，从 顶 层 至底 层进行了拆分。主要分为 应用层、业务模

型层、业务工具层、基础设施层 。基于 我们 当前的业务 形态 ， 自 上 而 下

应用层 ： 负责 当前 我们 的业务应用， 直 接为业务提供工具 或 提供业务的

某些模块 ，与业务共 担 目标，为业务赋能。

业务模型层 ： 支持 应用层建设和一定的实时分析能力，同时 也 作为业务

某 一个流 程 的功能 模块 接入 使 用，为外部业务和 自身 应用层建设，与业

务共 担 目标，为业务赋能。

业务工具层 ： 支持 应用层和业务 模 型层的开发，提供通用的工具，面向

降低应用层和业务 模 型层的建设成本，提升 整 体建设的工 程 效能，保证

业务 稳 定和数据质量准 确 。

基础设施 ：技术中台提供的基础设施和云 服 务，提供 稳 定可用的基础功

能，保证上层建 筑 的 稳 定性。

3.2 实时数据的数据架构选型

解决当前问题的数据 架构 ，一 般 有 Lambda 架构 和 Kappa 架构 。针对

当前业务特点，计算复杂、 偶 发的 异常 问题需要大数据量 回溯 等特性。

当前实时数据的数据架构采用的是 Lambda 架构 。 由 Palo 承 载 分 钟

级 的 批处理 ， Flink 来承 载秒级别简单逻辑 的流 处理 。具体如下：

3.3 应用层建设经验分享

3.3.1 实时数据系统

业务场景

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

实时业务数据。

1 、通过提供实时的业务指标，解决业务对热点、潜力的把控，助力

生产、消费，提 升优质创作量及内容消费能力。

2 、提供实时的复杂计算的外显指标，加强用户体验，解决业务侧通

过后端脚本计算的高维护成本和复杂性，节约成本，提升人效。

实时算法特征。

1 、以实时数据为基础，提供多样的实时算法特征，与 推荐 算法团队

共同提升 DAU 、留存、用户付费等核心指标。

面临的困难

1 、 依赖 数据 源 多，计算 规则 复杂。以 我们 的 播放 量计算为 例 ：

1.1 、行为有多 条 ，需要针对行为进行 去重 。

1.2 、过 滤 和加和 规则很 多，需要 依赖 多个数据 源 的 不 同数据 结果

进行计算。

2 、时间 敏感 性高

2.1 、以算法特征为 例 ，用户 浏览某 内容后，针对后 续关联 的一系

列 计算后，需要在一定时间内产出计算 结果（ 10min 未 产出后 续推荐

效 果 会有 波 动， 26min 该特征的效 果 会降为 0 ）

3 、调度过 程 中 协 调成本高

3.1 、需要调度系统中，同时能 识别 kafka 流消费的进度和 任 务 完

成 情况 。

3.2 、需要 严格拉齐 多个 依赖 的消费进度，当 达 到统一进度后，集

中进行后 续任 务计算。

解决方案

搭建实时数据基 座 ，建设 相 应的数据 模 型，降低建设成本。

针对 依赖 数据 众 多、计算 规则 复杂、质量难以保证等问题。通过建设工

具降低解决问题的成本。

1 、通过建设实时数据集成和实时数据调度的能力，保 障 数据接入和

数据 模 型建设的速度，降低接入时间，提升业务接入效率 （ 具体 见 下

方 ）

2 、通过建设实时数据质量中心，保 障 数据质量，降低发现数据质量

问题的时间，提升发现效率，保证业务 交 付 结果（ 具体 见 下方 ）