用户画像与实时数据分析是互联网企业的数据核心。知乎数据赋能团队以 Apache Doris 为基础，基于云服务构建高响应、低成本、兼顾稳定性与灵活性的实时数据架构，同时支持实时业务分析、实时算法特征、用户画像三项核心业务流，显著提升对于时效性热点与潜力的感知力度与响应速度，大幅缩减运营、营销等业务场景中的人群定向成本，并对实时算法的准确率及业务核心指标带来明显增益。
1. 前言
知乎业务中，随着各业务线业务的发展，逐渐对用户画像和实时数据这两部分的诉求越来越多。对用户画像方面，期望有更快、更准、更方便的人群筛选工具和方便的用户群体分析能力。对于实时数据方面，期望拥有可以实时响应的用户行为流，同时在算法特征、指标统计、业务外显等业务场景有愈来愈多的数据实时化的诉求。
在 2021 年 8 月，知乎平台团队成立数据赋能团队。针对历史实时数据需求无承接方的现象，已有用户画像系统无法满足多样的人群定向的现状，及业务方进一步人群分析的业务诉求，提出基础设施层选用 Apache Doris 作为实时数据仓库技术选型，业务工具层建设实时数据集成、实时数据调度、实时数据质量中心等系统，应用层建设实时数据应用和用户画像应用的方案。该方案针对性地解决了业务痛点，满足了业务诉求。
拆分当前业务主要在实时数据和用户画像两大部分有难点，共包含如下的三个方向目标：
实时算法特征 用户画像
本文就知乎平台的数据赋能团队，基于以上三个方向的目标，就这四个问题，来逐一介绍这方面的技术实践经验和心得体会：
1.1 名词解释
1.2 实时数据与用户画像与各业务的结合
2. 面临的挑战和痛点
针对当前业务目标，主要有以下几个具体要求。
数据实效性 在推荐算法中，非常实时的特征推荐算法效果要比天级别更新特征的算法效果好很多，如何保证 10 分钟内算法受到特征变更？ 接口实时性 复杂性 人群分析业务，期望多角度、各维度进行人群关联计算，同时基于全部用户特征针对当前人群和对比人群进行 TGI 计算，筛选出显著特征，如何解决？ 业务数据中有增 / 删 / 改逻辑，如何实时同步？ 明细数据异常发现滞后，异常发现后，需要针对性修正构建方式，及回溯数据修复，如何解决？ 3. 实践及经验分享 3.1 整体业务架构
基于当前的业务，从顶层至底层进行了拆分。主要分为应用层、业务模型层、业务工具层、基础设施层。基于我们当前的业务形态，自上而下
3.2 实时数据的数据架构选型
解决当前问题的数据架构，一般有 Lambda 架构和 Kappa 架构。针对当前业务特点，计算复杂、偶发的异常问题需要大数据量回溯等特性。当前实时数据的数据架构采用的是 Lambda 架构。由 Doris 承载分钟级的批处理，Flink 来承载秒级别简单逻辑的流处理。具体如下：
3.3 应用层建设经验分享 3.3.1 实时数据系统 3.3.1.1 业务场景
实时数据系统主要有两个大方向：实时业务数据和实时算法特征。
实时算法特征。 3.3.1.2 面临的困难
调度过程中协调成本高 3.3.1.3 解决方案
时间敏感性高，加强监控、与 Doris 集群共同提升吞吐效率和计算效率： Doris 增加了 Runtime Filter，通过 BloomFilter 提升 Join 性能。 3.3.2 用户画像系统 DMP 3.3.2.1 业务场景
用户画像系统主要有两大功能：用户检索和用户分析。
用户分析。 3.3.2.2 面临的困难 筛选响应时间要求高。 人群包除了 long 类型的用户 id 外，还需要有多种不同的设备 id 和设备 id md5 作为筛选结果。用户分析场景下，针对 300+ 万 tag 的多人群交叉 TGI 计算，需要在 10min 内完成。 3.3.2.3 解决方案
导入变更，拆分导入。 提升人群筛选和人群分析的计算速度，分而治之。 数据模型变更，拆分文件。 计算参数变更，提升并发。 3.3.2.4 效果
上线后，接入了知乎多个主要场景的业务，支持多业务方的人群定向和分析能力。为业务带来曝光量、转化率等直接指标的提升。同时在工具性能上，有如下表现：
3.3.2.5 待提升 性能提升 当前 Doris 的读取 bitmap 功能在建设中。业务代码无法读取到 bitmap，只能先通过 bitmap_to_string 方法读取到转换为文本的 bitmap，加大了传输量，降低了圈选性能。 针对人群预估逻辑，当前是通过例如 bitmap_count(bitmap_and) 两个函数完成的，后续 Doris 会提供 bitmap_and_count 合并为一个函数，替换后可提升计算效率。 3.4 工具层建设经验分享 3.4.1 数据集成 3.4.1.1 业务场景
“巧妇难为无米之炊”，没有数据也就没有后面的一切，数据采集作为基础至关重要。Doris 数据仓库自带的多种数据导入方式 对于数据入仓非常便利，但是在我们的使用过程中也遇到了一些问题。比如：
3.4.1.2 解决方案
在建设实时数据模型的过程中。需要依赖众多业务的数据，同时需要针对数据逐层建设数据模型。摸索并搭建了实时数据集成系统和实时调度系统，并下沉到工具层。
3.4.1.3 效果
上线后 3.4.2 数据调度 3.4.2.1 业务场景
我们在初期通过 Doris 建设实时数据的过程中，是通过 Routine Load 后的数据，再定时任务执行后续计算逻辑，后再将计算结果导出到承载存储，如 Redis、Zetta（知乎自研 HBase 协议） 中完成外部压力承载。在这个过程中遇到了如下问题：
3.4.2.2 解决方案
3.4.2.3 效果
3.4.3 数据质量 3.4.3.1 业务场景
数据，已经成为互联网企业非常依赖的重要资产。数据质量的好坏直接关系到信息的精准度，也影响到企业的生存和竞争力。Michael Hammer（《Reengineering the Corporation》一书的作者）曾说过，看起来不起眼的数据质量问题，实际上是拆散业务流程的重要标志。数据质量管理是测度、提高和验证质量，以及整合组织数据的方法等一套处理准则，而体量大、速度快和多样性的特点，决定了大数据质量所需的处理，有别于传统信息治理计划的质量管理方式。具体到针对知乎的各个业务：
AI平台、增长团队、内容平台等已经将部分或全部业务渐渐迁移到实时计算平台，在接入数据更实时，更迅速的接入带来的所享受的收益外，数据质量更加变得重要。
一致性:
多源数据的数据模型不一致，例如：命名不一致、数据结构不一致、约束规则不一致。数据实体不一致，例如：数据编码不一致、命名及含义不一致、分类层次不一致、生命周期不一致……相同的数据有多个副本的情况下的数据不一致、数据内容冲突的问题；准确性: 唯一性: 关联性: 真实性: 及时性: 3.4.3.2 解决方案
3.4.3.3 效果
3.4.3.3 收益 上线后 4. 总结与展望 4.1 收益总结 4.1.1 业务发展方面 针对实时算法特征 针对用户画像 4.1.2 工具建设方面
完成了实时数据领域和用户领域的布局，建设了相关的开发和维护工具，解决了先前在此方面无基础设施，无业务工具，开发成本高的问题。
搭建了集成、调度、质量系统。通过工具的方式降低了业务发展和迭代的成本，让业务快速发展，同时也保证了交付质量提高了业务基线。
4.1.3 人员组织方面
自上而下的拆分了实时数据和用户画像的能力，分为应用层、业务模型层、业务工具层和基础设施层。通过组织划分，明确了不同层次的边界和加速了业务目标的达成。
搭建并完善了多层次团队人员梯队。根据针对不同方向的同学，给予不同的 OKR 目标，做到跨层次方向隔离，同层次方向一致，同模块目标一致。共同为整体实时数据与用户画像服务建设而努力。
4.2 未来展望
从 2021 年 8 月成立至今，我们一直思考如何提供更好的实时数据服务？实时数据能建设什么方面的应用，为业务创造价值？如何将用户画像服务做好？用户画像服务的筛选、分析能力如何为业务创造更大价值？摸着石头过河的同时，我们也在不断摸索和建设相关的业务能力和基础建设。在明年的发展中，我们还会针对以下方面进一步发展：
基于用户画像
