超全！实时用户画像实践经验
图源：《用户画像》
1、通过提供实时的业务指标，解决业务对热点、潜力的把控，助力生产、消费，提升优质创作量及内容消费能力。
本文就知乎平台的数据赋能团队，基于以上三个方向的目标，就这四个问题，来逐一介绍这方面的技术实践经验和心得体会：
1、如何通过实时数据驱动业务发展？
1.1 名词解释
1.2 实时数据与用户画像与各业务的结合
搭建热点、潜力等紧随时间的指标和相关的排行榜，直接支持业务发展。
2）如何让用户画像的筛选和分析能力最大化？
要全面覆盖多维度用户筛选的多种需求。
多角度、多方式覆盖用户分析。
1）推荐页首屏浏览 6 条内容，如何在第二刷的时候就立即感知到最新的用户行为？
2）在推荐算法中，非常实时的特征推荐算法效果要比天级别更新特征的算法效果好很多，如何保证 10 分钟内算法受到特征变更？
2）人群分析业务，期望多角度、各维度进行人群关联计算，同时基于全部用户特征针对当前人群和对比人群进行 TGI 计算，筛选出显著特征，如何解决？
4）明细数据异常发现滞后，异常发现后，需要针对性修正构建方式，及回溯数据修复，如何解决？
3.1 整体业务架构
应用层：负责当前我们的业务应用，直接为业务提供工具或提供业务的某些模块，与业务共担目标，为业务赋能。
业务模型层：支持应用层建设和一定的实时分析能力，同时也作为业务某一个流程的功能模块接入使用，为外部业务和自身应用层建设，与业务共担目标，为业务赋能。
业务工具层：支持应用层和业务模型层的开发，提供通用的工具，面向降低应用层和业务模型层的建设成本，提升整体建设的工程效能，保证业务稳定和数据质量准确。
基础设施：技术中台提供的基础设施和云服务，提供稳定可用的基础功能，保证上层建筑的稳定性。
3.2 实时数据的数据架构选型
3.3 应用层建设经验分享
3.3.1 实时数据系统
实时数据系统主要有两个大方向：实时业务数据和实时算法特征。
1、通过提供实时的业务指标，解决业务对热点、潜力的把控，助力生产、消费，提 升优质创作量及内容消费能力。
2、提供实时的复杂计算的外显指标，加强用户体验，解决业务侧通过后端脚本计算的高维护成本和复杂性，节约成本，提升人效。
1、依赖数据源多，计算规则复杂。以我们的播放量计算为例：
行为有多条，需要针对行为进行去重。
过滤和加和规则很多，需要依赖多个数据源的不同数据结果进行计算。
需要调度系统中，同时能识别 kafka 流消费的进度和任务完成情况。
需要严格拉齐多个依赖的消费进度，当达到统一进度后，集中进行后续任务计算。
解决方案
搭建实时数据基座，建设相应的数据模型，降低建设成本。
针对依赖数据众多、计算规则复杂、质量难以保证等问题。通过建设工具降低解决问题的成本。
通过建设实时数据集成和实时数据调度的能力，保障数据接入和数据模型建设的速度，降低接入时间，提升业务接入效率（具体见下方）
通过建设实时数据质量中心，保障数据质量，降低发现数据质量问题的时间，提升发现效率，保证业务交付结果（具体见下方）
1、搭建写入延迟、计算延迟等监控，快速发现问题。
2、Palo 集群进行参数变更，调整批量写入的数据量、时间和频率等进行优化。
当前我们的 Load 主要有 Broker Load 和 Routine Load。其中时效性要求高的是 Routine Load。我们针对性的进行了参数调整。
Palo 集群在 0.14 版本中加入了 Runtime Filter 的过滤，针对 Join 大量 key 被过滤的情况有明显提升；
该变更针对我们当前的几个业务调度性能，有明显提升。时间从 40+s 提升至 10s 左右；
3.3.2 用户画像系统 DMP
1、用户检索。重点在于快速完成人群包圈选同时在圈选条件变更过程中，需要快速计算出预计能圈的用户有哪些？
2、用户分析。重点在于多人群包的各个维度对比分析，通过分析结论找到最明显的用户特征（通过 TGI 值判断）
1、数据规模大。我们当前是 200+ 个标签，每个标签均有不同的枚举值，总计有 300+ 万的 tag。tag 对用户的打标量级在 900+ 亿条记录。由于标签每日更新导入量级十分大。
2、筛选响应时间要求高。针对简单的筛选，要求在秒级别出结果，针对复杂的人群筛选，筛选后人群量大的情况，要求在 20s 内完成人群包生成。
3、人群包除了 long 类型的用户 id 外，还需要有多种不同的设备 id 和设备 id md5 作为筛选结果。
4、用户分析场景下，针对 300+ 万 tag 的多人群交叉 TGI 计算，需要在 10min 内完成。
DMP 业务架构
数据规模大，提升导入性能，分而治之。
1、数据模型变更，拆分文件。
Palo 的存储是按照 Tablet 分散在集群上的。通过调整数据模型，确保分布均匀及每个文件尽可能的小。
2、导入变更，拆分导入。
由于每个 Broker Load 导入都是有性能瓶颈的，将 900+ 亿行数据，拆分为 1000+ 个 Broker Load 的导入任务，确保每个导入总量都足够小。
提升人群筛选和人群分析的计算速度，分而治之。
将用户每 0 ～ 100 万拆分为一组。
针对全部用户的交并差，等价于对所有组用户交并差后的并集。
针对全部用户的交并差的总数，等价于对分组用户交并差后的总数进行 sum。
设置 bitmap 的分组参数，将分组设置为 colocate group。确保每个分组的交并差计算均在自己所在 BE 完成，无需 shuffle。
将 bitmap 表的分桶拆分更多，通过更多文件同时计算加速结果。
3、计算参数变更，提升并发。
由于计算过程通过分治的手段，拆分为多个小任务。通过提升并行度 parallel_fragment_exec_instance_num 再进一步优化计算速度。
效果
上线后，接入了知乎多个主要场景的业务，支持多业务方的人群定向和分析能力。为业务带来曝光量、转化率等直接指标的提升。
同时在工具性能上，有如下表现：
导入速度。当前每日 900+ 亿行数据，在 3 小时内完成导入。
人群预估。人群预估基本可在 1s 内完成，P95 985ms。
人群圈选。人群圈选过程在 5s 内完成，整体圈人在 2min 左右。（待提升中介绍）
人群分析。人群分析过程在 5min 内完成。
待提升
功能扩展
缺乏定制的人群扩散能力。多业务场景对已有人群进行扩散有复杂且多样的需求。
缺乏用户人群染色，无法再多个环节完成用户效果的回收和进行后续的分析。
性能提升
1）当前 Palo 的行列转换功能在建设中。在用户画像业务中，将用户 id 更换为设备 id，人群缩减（将具体人群包缩减为一个比较小的人群包用于后续运营动作）过程是通过业务代码实现的，降低了性能。
后续结果由行列转换后，用户画像结果处理流程中会将设备 id 获取方式通过 join 维度表来实现，人群缩减通过 order by rand limit 来实现，会有比较明显的性能提升。
2）当前 Palo 的读取 bitmap 功能在建设中。业务代码无法读取到 bitmap，只能先通过 bitmap_to_string 方法读取到转换为文本的 bitmap，加大了传输量，降低了圈选性能。
后续可以直接读取 bitmap 后，业务逻辑中会替换为直接获取 bitmap，会极大程度的减少数据传输量，同时业务逻辑可以针对性缓存。
3）针对人群预估逻辑，当前是通过例如 bitmap_count(bitmap_and) 两个函数完成的，后续 Palo 会提供 bitmap_and_count 合并为一个函数，替换后可提升计算效率。
3.4 工具层建设经验分享
3.4.1 数据集成
2、需要编写冗长的 etl 处理逻辑代码，小的操作变更流程很长，需要全流程（至少 30 分钟）的上线操作；此外每次部署操作还有可能遇到各种初始化 MQ 消费者的问题
3、缺少运行状态监控，出现异常问题无法在分钟甚至小时级别的时间发现；
4、在线导入仅支持 kafka json，上游的 pulsar、protobuf 数据仍需要代码开发进行转发，导致每次接入数据都需要转换函数的开发以及同样全流程的上线操作；
5、业务逻辑中，期望业务是什么样，Palo 中的数据就是什么样，让业务无感知。这种全增量同步期望被包住，而不是做很多配置或开发很多代码来实现。
在建设实时数据模型的过程中。需要依赖众多业务的数据，同时需要针对数据逐层建设数据模型。摸索并搭建了实时数据集成系统和实时调度系统，并下沉到工具层。
1、实时数据集成。建设快速且自定义的配置，针对不同的数据源建设导入能力。
2、与 Palo 的 Broker Load 和 Routine Load 进行配合，在此基础上搭建针对业务的全增量同步。
3、封装集成能力对内部暴露的接口，业务层无需理解中间过程，只选择同步的数据库和数据表即可进行实时同步。
同步配置
2、中间链路多，缺乏报警，针对重要的链路，建设打点和报警成本高，需要 0.5 天左右。
全量：原始数据库 TiDB -> 中间部分（DataX）-> Palo
增量：原始数据库 TiDB -> TiCDC -> Canal Binlog Kafka -> ETL（填充数据）-> Kafka -> Routine Load -> Palo
上线后
1、仅需要 10min 的配置，数据集成包含模型，数据导入及中间 ETL 的转化和额外数据补充以及 Routine Load 全部建好。业务层无需感知数据中间链路，仅需要描述我期望那个表被同步。
2、上线后无需业务关心，完成第一步配置后，后续的监控和报警以及一致性，集成全面解决。
3.4.2 数据调度
2、Palo 资源有限，但很多任务都是某些整点整分钟的，一次性大量的计算任务造成集群崩溃；
3、任务是否执行成功，任务是否延迟，是否影响到业务，无报警无反馈；
4、导出存储过程通用，重复代码开发，每次都需要 0.5 - 1 人天的时间开发写入和业务接口。
解决方案
2、通过退让策略，监控当前 Palo 指标，在高负载情况下避免提交 SQL。避峰趋谷，完成资源最大利用。后续通过这种方案，一定程度的避免了瞬时跑高整体集群的问题。
3、全链路监控任务执行情况，和延迟情况，一旦延迟报警，及时沟通解决和恢复业务。一旦任务延迟，监控可非常快速的发现相关问题，多数情况能在业务可接受范围内完成恢复。
4、上线后，原先需要 1 天的工程能力开发时间降低至 0。只需要在 Palo 中有一个可查询的 SQL，经过简单配置即可完成一定时间交付给业务相关数据、排行榜的需求。
3.4.3 数据质量
AI平台、增长团队、内容平台等已经将部分或全部业务渐渐迁移到实时计算平台，在接入数据更实时，更迅速的接入带来的所享受的收益外，数据质量更加变得重要。
解决方案
全流程的数据链路和各级质量保证方法
某业务健康情况监控
以通过 DQC 监控的某一个业务的健康情况，该业务由多个导出任务和中间计算任务及部分数据源组成，当前情况是一切正常。期间如果出现某节点任意异常后，都可及时发现。
上线前
1、早期无类似 DQC 系统保证的前提下，我们很多问题都是天级别甚至上线后，才发现存在数据异常，出现过 3 次问题，造成的返工和交付不靠谱的情况，对业务影响巨大。
2、早期开发中，在开发过程需要不断针对各种细节规则进行比对，总会花费一定时间逐层校验，成本巨大。
上线后
1、在上线 1 个月内，通过 DQC 系统规则，当前已发现了 14 个错异常，在 1 - 2h 左右发现，立即修复。对业务的影响降低到最小。
2、在系统上线后，在开发过程中，开发完相关数据，如有异常，就产生了异常报警，大幅节省了人工发现的成本，因为修复时间早，在后续开发启动前，就已经修复，极大程度降低开发过程中的返工成本。
4.1 收益总结
4.1.1 业务发展方面
提供了基于时效性的热点、潜力的把控。加速业务在生产、消费方面的使用，进而提升优质创作量及用户对内容消费能力。
同时提供了提供实时的复杂计算的外显指标，加强用户体验，下线了业务后端通过脚本计算指标的方法，降低了业务的复杂性，节约了成本，提升人效。
完善和升级用户筛选，做到多维、多类型的定向筛选，并接入了运营平台、营销平台等系统，提高了业务效率，降低了业务人员进行人群定向的成本。
搭建和完善用户分析，做到多角度用户分析，定向用户分析报告 0 成本，助力业务部门快速把握核心客户市场。
4.1.2 工具建设方面
2、搭建了集成、调度、质量系统。通过工具的方式降低了业务发展和迭代的成本，让业务快速发展，同时也保证了交付质量提高了业务基线。
4.1.3 人员组织方面
搭建并完善了多层次团队人员梯队。根据针对不同方向的同学，给予不同的 OKR 目标，做到跨层次方向隔离，同层次方向一致，同模块目标一致。共同为整体实时数据与用户画像服务建设而努力。
4.2 未来展望
强化基础能力工具层的建设，持续降低基于实时数据方面的建设、交付成本。
提升数据质量工具覆盖能力，为业务模型提供质量保障，并提供基于实时数据的画像质量保障能力。
基于当前业务诉求，部分场景针对 5 分钟级实时无法满足，进一步探索秒级别复杂情况实时能力，并提供能力支持。
2、基于用户画像
加强并针对用户画像、用户理解、用户洞察 & 模型等进一步建设。通过与具体业务结合，建设贴合业务场景的用户理解成果和相应的分析能力，找到业务的留存点。
进一步加强新的工具能力的建设，通过建设用户理解工具、用户分析工具，降低产生理解及对业务分析的成本，提升业务效率，快速发现业务价值。
原文链接：
https://zhuanlan.zhihu.com/p/444879814?hmsr=joyk.com&utm_source=joyk.com&utm_medium=referral
长按或扫描下方二维码，后台回复：加群，即可申请入群。一定要备注：来源+研究方向+学校/公司，否则不拉入群中，见谅！
（长按三秒，进入后台）
推荐阅读
