摘要

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

关键词：数据仓库，Palo，Apache Doris，用户画像，实时数据

一、前言

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

在 2021 年 8 月，知乎平台团队成立数据赋能组。针对历史实时数据需求无承接方的现象，已有用户画像系统无法满足多样的人群定向的现状，及业务方进一步人群分析的业务诉求。综合考虑了查询时效、运维简易等方面因素，数据赋能组提出基础设施层选用百度智能云的 Palo 作为实时数据仓库，业务工具层建设实时数据集成、实时数据调度、实时数据质量中心等系统，应用层建设实时数据应用和用户画像应用的方案。该方案针对性地解决了业务痛点，满足了业务诉求。

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

• 实时业务数据

1. 通过提供实时的业务指标，解决业务对热点、潜力的把控，助力生产、消费，提 升优质创作量及内容消费能力。
2. 提供实时的复杂计算的外显指标，加强用户体验，解决业务侧通过后端脚本计算的高维护成本和复杂性，节约成本，提升人效。

• 实时算法特征

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

• 用户画像

1. 用户筛选，做到多维、多类型的定向筛选，并接入营销、广告、 运营平台等系统，提高业务效率，降低人员成本。
2. 用户分析，做到多角度用户分析，定向用户分析报告 0 成本，助力业务部门快速把握核心客户市场。

本文就知乎平台的数据赋能团队，基于上述三个方向的目标，将围绕四个思考方向来介绍相关方面的技术实践经验和心得体会：

• 如何通过实时数据驱动业务发展？
• 如何从 0 -> 1 搭建实时数据中心？
• 如何搭建一套高效快速的用户画像系统来解决历史系统的多种问题？
• 如何快速高效的开发业务功能和保证业务质量？

1.1 名词解释

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

二、面临的挑战和痛点

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

1）有价值

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

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

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

1. 要全面覆盖多维度用户筛选的多种需求。
2. 多角度、多方式覆盖用户分析。

   2）数据实效性

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

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

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

1. 通过实时数据系统与 Palo 配合共同建设，提升到 10 分钟内更新（下面介绍）。

   3）接口实时性

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

1. 通过用户画像系统与 Palo 配合共同建设，提升人群筛选的速度（下面介绍）。

   4）复杂性

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

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

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

1. 通过用户画像系统与 Palo 配合共同建设，解决复杂的人群分析（下面介绍）。

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

1. 实时数据集成系统与 Palo 配合共同建设，解决增 / 删 / 改逻辑（下面介绍）。

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

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

   三、实践及经验分享

   3.1 整体业务架构

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

• 应用层：负责当前我们的业务应用，直接为业务提供工具或提供业务的某些模块，与业务共担目标，为业务赋能。
• 业务模型层：支持应用层建设和一定的实时分析能力，同时也作为业务某一个流程的功能模块接入使用，为外部业务和自身应用层建设，与业务共担目标，为业务赋能。
• 业务工具层：支持应用层和业务模型层的开发，提供通用的工具，面向降低应用层和业务模型层的建设成本，提升整体建设的工程效能，保证业务稳定和数据质量准确。
• 基础设施：技术中台提供的基础设施和云服务，提供稳定可用的基础功能，保证上层建筑的稳定性。
  

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

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

## 3.3 应用层建设经验分享

3.3.2 实时数据系统

业务场景

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

• 实时业务数据。

1. 通过提供实时的业务指标，解决业务对热点、潜力的把控，助力生产、消费，提 升优质创作量及内容消费能力。
2. 提供实时的复杂计算的外显指标，加强用户体验，解决业务侧通过后端脚本计算的高维护成本和复杂性，节约成本，提升人效。

• 实时算法特征。-

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

   面临的困难

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

1. 行为有多条，需要针对行为进行去重。
2. 过滤和加和规则很多，需要依赖多个数据源的不同数据结果进行计算。
   
   

• 时间敏感性高

1. 以算法特征为例，用户浏览某内容后，针对后续关联的一系列计算后，需要在一定时间内产出计算结果（10min 未产出后续推荐效果会有波动，26min 该特征的效果会降为 0）

• 调度过程中协调成本高

1. 需要调度系统中，同时能识别 kafka 流消费的进度和任务完成情况。
2. 需要严格拉齐多个依赖的消费进度，当达到统一进度后，集中进行后续任务计算。

   解决方案

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

针对依赖数据众多、计算规则复杂、质量难以保证等问题。通过建设工具降低解决问题的成本。

• 通过建设实时数据集成和实时数据调度的能力，保障数据接入和数据模型建设的速度，降低接入时间，提升业务接入效率（具体见下方）
• 通过建设实时数据质量中心，保障数据质量，降低发现数据质量问题的时间，提升发现效率，保证业务交付结果（具体见下方）
  时间敏感性高，加强监控、与 Palo 集群共同提升吞吐效率和计算效率。
• 搭建写入延迟、计算延迟等监控，快速发现问题。
• Palo 集群进行参数变更，调整批量写入的数据量、时间和频率等进行优化。

1. 当前我们的 Load 主要有 Broker Load 和 Routine Load。其中时效性要求高的是 Routine Load。我们针对性的进行了参数调整。

• Palo 增加了 Runtime Filter，通过 BloomFilter 提升 Join 性能。

1. Palo 集群在 0.14 版本中加入了 Runtime Filter 的过滤，针对 Join 大量 key 被过滤的情况有明显提升；
2. 该变更针对我们当前的几个业务调度性能，有明显提升。时间从 40+s 提升至 10s 左右；

   3.3.3 用户画像系统 DMP

   业务场景

用户画像系统主要有两大功能：用户检索和用户分析。

• 用户检索。重点在于快速完成人群包圈选同时在圈选条件变更过程中，需要快速计算出预计能圈的用户有哪些？
• 用户分析。重点在于多人群包的各个维度对比分析，通过分析结论找到最明显的用户特征（通过 TGI 值判断）

  面临的困难

1. 数据规模大。我们当前是 200+ 个标签，每个标签均有不同的枚举值，总计有 300+ 万的 tag。tag 对用户的打标量级在 900+ 亿条记录。由于标签每日更新导入量级十分大。
2. 筛选响应时间要求高。针对简单的筛选，要求在秒级别出结果，针对复杂的人群筛选，筛选后人群量大的情况，要求在 20s 内完成人群包生成。
3. 人群包除了 long 类型的用户 id 外，还需要有多种不同的设备 id 和设备 id md5 作为筛选结果。
4. 用户分析场景下，针对 300+ 万 tag 的多人群交叉 TGI 计算，需要在 10min 内完成。

解决方案

DMP 业务架构

DMP 业务流程

性能问题针对性解决
数据规模大，提升导入性能，分而治之。

• 数据模型变更，拆分文件。

1. Palo 的存储是按照 Tablet 分散在集群上的。通过调整数据模型，确保分布均匀及每个文件尽可能的小。

• 导入变更，拆分导入。

1. 由于每个 Broker Load 导入都是有性能瓶颈的，将 900+ 亿行数据，拆分为 1000+ 个 Broker Load 的导入任务，确保每个导入总量都足够小。

提升人群筛选和人群分析的计算速度，分而治之。

• 业务逻辑变更，拆分用户。

1. 将用户每 0 ～ 100 万拆分为一组。
2. 针对全部用户的交并差，等价于对所有组用户交并差后的并集。
3. 针对全部用户的交并差的总数，等价于对分组用户交并差后的总数进行 sum。

• 数据模型变更，拆分文件。

1. 设置 bitmap 的分组参数，将分组设置为 colocate group。确保每个分组的交并差计算均在自己所在 BE 完成，无需 shuffle。
2. 将 bitmap 表的分桶拆分更多，通过更多文件同时计算加速结果。

• 计算参数变更，提升并发。

1. 由于计算过程通过分治的手段，拆分为多个小任务。通过提升并行度 parallel_fragment_exec_instance_num 再进一步优化计算速度。

效果

上线后，接入了知乎多个主要场景的业务，支持多业务方的人群定向和分析能力。为业务带来曝光量、转化率等直接指标的提升。

同时在工具性能上，有如下表现：

• 导入速度。当前每日 900+ 亿行数据，在 3 小时内完成导入。
• 人群预估。人群预估基本可在 1s 内完成，P95 985ms。
• 人群圈选。人群圈选过程在 5s 内完成，整体圈人在 2min 左右。（待提升中介绍）
• 人群分析。人群分析过程在 5min 内完成。

待提升

功能扩展

• 缺乏定制的人群扩散能力。多业务场景对已有人群进行扩散有复杂且多样的需求。
• 缺乏用户人群染色，无法再多个环节完成用户效果的回收和进行后续的分析。

性能提升

• 当前 Palo 的行列转换功能在建设中。在用户画像业务中，将用户 id 更换为设备 id，人群缩减（将具体人群包缩减为一个比较小的人群包用于后续运营动作）过程是通过业务代码实现的，降低了性能。

1. 后续结果由行列转换后，用户画像结果处理流程中会将设备 id 获取方式通过 join 维度表来实现，人群缩减通过 order by rand limit 来实现，会有比较明显的性能提升。

• 当前 Palo 的读取 bitmap 功能在建设中。业务代码无法读取到 bitmap，只能先通过 bitmap_to_string 方法读取到转换为文本的 bitmap，加大了传输量，降低了圈选性能。

1. 后续可以直接读取 bitmap 后，业务逻辑中会替换为直接获取 bitmap，会极大程度的减少数据传输量，同时业务逻辑可以针对性缓存，。

• 针对人群预估逻辑，当前是通过例如 bitmap_count(bitmap_and) 两个函数完成的，后续 Palo 会提供 bitmap_and_count 合并为一个函数，替换后可提升计算效率。

3.4 工具层建设经验分享

3.4.1 数据集成

业务场景

“巧妇难为无米之炊”，没有数据也就没有后面的一切，数据采集作为基础至关重要。Palo 数据仓库自带的多种数据导入方式对于数据入仓非常便利，但是在我们的使用过程中也遇到了一些挑战，比如：

• 在从离线数仓进行 broker load 的时候数据依赖丢失，上游数据错误无法评估受影响的范围。
• 需要编写冗长的 etl 处理逻辑代码，小的操作变更流程很长，需要全流程（至少 30 分钟）的上线操作；此外每次部署操作还有可能遇到各种初始化 MQ 消费者的问题
• 缺少运行状态监控，出现异常问题无法在分钟甚至小时级别的时间发现；
• 在线导入仅支持 kafka json，上游的 pulsar、protobuf 数据仍需要代码开发进行转发，导致每次接入数据都需要转换函数的开发以及同样全流程的上线操作；
• 业务逻辑中，期望业务是什么样，Palo 中的数据就是什么样，让业务无感知。这种全增量同步期望被包住，而不是做很多配置或开发很多代码来实现。

  解决方案

针对上述问题，知乎数据赋能组启动建设实时数据模型，在百度智能云Palo团队的协同配合下，将对众多业务数据的依赖，以及对数据逐层建设的数据模型搭建出实时数据集成系统和实时调度系统，并下沉到工具层。

• 实时数据集成。建设快速且自定义的配置，针对不同的数据源建设导入能力。
• 与 Palo 的 Broker Load 和 Routine Load 进行配合，在此基础上搭建针对业务的全增量同步。
• 封装集成能力对内部暴露的接口，业务层无需理解中间过程，只选择同步的数据库和数据表即可进行实时同步。
  

效果

同步配置

同步任务

上线前

• 早期使用 Palo 开发实时数据业务过程中，由于需要某个数据全/增量同步，同时进行数据转换。需要建 Palo 数据模型，完成全量数据导入，建设增量数据 ETL 和 Routine Load 等开发，需要 1 名工程师 1 天才能将一张表接入到 Palo 中并进行全增量实时同步。
• 中间链路多，缺乏报警，针对重要的链路，建设打点和报警成本高，需要 0.5 天左右。

1. 全量：原始数据库 TiDB -> 中间部分（DataX）-> Palo
2. 增量：原始数据库 TiDB -> TiCDC -> Canal Binlog Kafka -> ETL（填充数据）-> Kafka -> Routine Load -> Palo
   上线后

• 仅需要 10min 的配置，数据集成包含模型，数据导入及中间 ETL 的转化和额外数据补充以及 Routine Load 全部建好。业务层无需感知数据中间链路，仅需要描述我期望那个表被同步。
• 上线后无需业务关心，完成第一步配置后，后续的监控和报警以及一致性，集成全面解决。

3.4.2 数据调度

业务场景

我们在初期通过 Palo 建设实时数据的过程中，是通过 Routine Load 后的数据，再定时任务执行后续计算逻辑，后再将计算结果导出到承载存储，如 Redis、Zetta（知乎自研 HBase 协议） 中完成外部压力承载。在这个过程中遇到了如下问题：

• 依赖未就绪后续任务就执行。如最近 24 小时的曝光，在 15:05 运行昨日 15:00 - 今日 15:00 的查询。此时如果 Routine Load 仅导入到 14:50 的数据，这次执行结果异常；
• Palo 资源有限，但很多任务都是某些整点整分钟的，一次性大量的计算任务造成集群崩溃；
• 任务是否执行成功，任务是否延迟，是否影响到业务，无报警无反馈；
• 导出存储过程通用，重复代码开发，每次都需要 0.5 - 1 人天的时间开发写入和业务接口。

  解决方案

  基于上述问题，我们与百度智能云Palo团队合作，梳理出重要的数据流与监控项，并建立起知乎实时数据的数据调度与监控架构。
  架构图
  

流程图

效果

同步任务

收益

• 建立任务依赖机制，通过 kafka 的 offset 和前置表是否完成计算，判断当前计算任务能否执行。后续再也没有出现过数据还未导入就先开始进行数据计算的情况。
• 通过退让策略，监控当前 Palo 指标，在高负载情况下避免提交 SQL。避峰趋谷，完成资源最大利用。后续通过这种方案，一定程度的避免了瞬时跑高整体集群的问题。
• 全链路监控任务执行情况，和延迟情况，一旦延迟报警，及时沟通解决和恢复业务。一旦任务延迟，监控可非常快速的发现相关问题，多数情况能在业务可接受范围内完成恢复。
• 上线后，原先需要 1 天的工程能力开发时间降低至 0。只需要在 Palo 中有一个可查询的 SQL，经过简单配置即可完成一定时间交付给业务相关数据、排行榜的需求。

3.4.3 数据质量

业务场景

数据，已经成为互联网企业非常依赖的重要资产。数据质量的好坏直接关系到信息的精准度，也影响到企业的生存和竞争力。Michael Hammer（《Reengineering the Corporation》一书的作者）曾说过，看起来不起眼的数据质量问题，实际上是拆散业务流程的重要标志。 数据质量管理是测度、提高和验证质量，以及整合组织数据的方法等一套处理准则，而体量大、速度快和多样性的特点，决定了大数据质量所需的处理，有别于传统信息治理计划的质量管理方式。
具体到针对知乎的各个业务：
AI平台、增长团队、内容平台等已经将部分或全部业务渐渐迁移到实时计算平台，在接入数据更实时，更迅速的接入带来的所享受的收益外，数据质量更加变得重要。

• 完整性: 数据完整性问题包括：模型设计不完整，例如：唯一性约束不完整、参照不完整；数据条目不完整，例如：数据记录丢失或不可用；数据属性不完整，例如：数据属性空值。不完整的数据所能借鉴的价值就会大大降低，也是数据质量问题最为基础和常见的一类问题；
• 一致性: 多源数据的数据模型不一致，例如：命名不一致、数据结构不一致、约束规则不一致。数据实体不一致，例如：数据编码不一致、命名及含义不一致、分类层次不一致、生命周期不一致……相同的数据有多个副本的情况下的数据不一致、数据内容冲突的问题；
• 准确性: 准确性也叫可靠性，是用于分析和识别哪些是不准确的或无效的数据，不可靠的数据可能会导致严重的问题，会造成有缺陷的方法和糟糕的决策；
• 唯一性: 用于识别和度量重复数据、冗余数据。重复数据是导致业务无法协同、流程无法追溯的重要因素，也是数据治理需要解决的最基本的数据问题；
• 关联性: 数据关联性问题是指存在数据关联的数据关系缺失或错误，例如：函数关系、相关系数、主外键关系、索引关系等。存在数据关联性问题，会直接影响数据分析的结果，进而影响管理决策；
• 真实性: 数据必须真实准确的反映客观的实体存在或真实的业务，真实可靠的原始统计数据是企业统计工作的灵魂，是一切管理工作的基础，是经营者进行正确经营决策必不可少的第一手资料；
• 及时性: 数据的及时性是指能否在需要的时候获到数据，数据的及时性与企业的数据处理速度及效率有直接的关系，是影响业务处理和管理效率的关键指标。

  解决方案

  全流程的数据链路和各级质量保证方法
  

业务架构

业务流程

效果

某业务健康情况监控
以通过 DQC 监控的某一个业务的健康情况，该业务由多个导出任务和中间计算任务及部分数据源组成，当前情况是一切正常。期间如果出现某节点任意异常后，都可及时发现。

某任务中间逻辑监控

     该任务中间计算中其中部分规则未达标，导致该任务未通过。

收益
上线前

• 早期无类似 DQC 系统保证的前提下，我们很多问题都是天级别甚至上线后，才发现存在数据异常，出现过 3 次问题，造成的返工和交付不靠谱的情况，对业务影响巨大。
• 早期开发中，在开发过程需要不断针对各种细节规则进行比对，总会花费一定时间逐层校验，成本巨大。
  上线后
• 在上线 1 个月内，通过 DQC 系统规则，当前已发现了 14 个错异常，在 1 - 2h 左右发现，立即修复。对业务的影响降低到最小。

• 在系统上线后，在开发过程中，开发完相关数据，如有异常，就产生了异常报警，大幅节省了人工发现的成本，因为修复时间早，在后续开发启动前，就已经修复，极大程度降低开发过程中的返工成本。

  四、总结与展望

  4.1 收益总结

  4.1.1 业务发展方面

• 针对实时业务数据

1. 提供了基于时效性的热点、潜力的把控。加速业务在生产、消费方面的使用，进而提升优质创作量及用户对内容消费能力。
2. 同时提供了提供实时的复杂计算的外显指标，加强用户体验，下线了业务后端通过脚本计算指标的方法，降低了业务的复杂性，节约了成本，提升人效。

• 针对实时算法特征

1. 提供了基于创作者、内容、消费者的实时算法特征，与算法团队共同在多个项目中，针对 DAU、留存、用户付费等核心指标有了明显的提升。

• 针对用户画像

1. 完善和升级用户筛选，做到多维、多类型的定向筛选，并接入了运营平台、营销平台等系统，提高了业务效率，降低了业务人员进行人群定向的成本。
2. 搭建和完善用户分析，做到多角度用户分析，定向用户分析报告 0 成本，助力业务部门快速把握核心客户市场。

4.1.2 工具建设方面

• 完成了实时数据领域和用户领域的布局，建设了相关的开发和维护工具，解决了先前在此方面无基础设施，无业务工具，开发成本高的问题。

• 搭建了集成、调度、质量系统。通过工具的方式降低了业务发展和迭代的成本，让业务快速发展，同时也保证了交付质量提高了业务基线。

  4.1.3 人员组织方面

• 自上而下的拆分了实时数据和用户画像的能力，分为应用层、业务模型层、业务工具层和基础设施层。通过组织划分，明确了不同层次的边界和加速了业务目标的达成。

• 搭建并完善了多层次团队人员梯队。根据针对不同方向的同学，给予不同的 OKR 目标，做到跨层次方向隔离，同层次方向一致，同模块目标一致。共同为整体实时数据与用户画像服务建设而努力。

4.2 未来展望

从 2021 年 8 月成立至今，我们一直思考如何提供更好的实时数据服务？实时数据能建设什么方面的应用，为业务创造价值？如何将用户画像服务做好？用户画像服务的筛选、分析能力如何为业务创造更大价值？摸着石头过河的同时，我们也在不断摸索和建设相关的业务能力和基础建设。在明年的发展中，我们还会针对以下方面进一步发展：

• 基于实时数据

1. 强化基础能力工具层的建设，持续降低基于实时数据方面的建设、交付成本。
2. 提升数据质量工具覆盖能力，为业务模型提供质量保障，并提供基于实时数据的画像质量保障能力。
3. 基于当前业务诉求，部分场景针对 5 分钟级实时无法满足，进一步探索秒级别复杂情况实时能力，并提供能力支持。

• 基于用户画像

1. 加强并针对用户画像、用户理解、用户洞察 & 模型等进一步建设。通过与具体业务结合，建设贴合业务场景的用户理解成果和相应的分析能力，找到业务的留存点。
2. 进一步加强新的工具能力的建设，通过建设用户理解工具、用户分析工具，降低产生理解及对业务分析的成本，提升业务效率，快速发现业务价值。

作者简介
侯容。知乎数据赋能组 Leader，主要负责实时数据、用户理解方向。