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

发布时间:2022-08-10 01:30:24 来源:乐鱼足球竞猜官网 作者:乐鱼竞猜官网首页

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  通过建设实时数据集成和实时数据调度的能力,保障数据接入和数据模型建设的速度,降低接入时间,提升业务接入效率(具体见下方)

  通过建设实时数据质量中心,保障数据质量,降低发现数据质量问题的时间,提升发现效率,保证业务交付结果(具体见下方)

  时间敏感性高,加强监控、与 Doris 集群共同提升吞吐效率和计算效率:

  Doris 集群进行参数变更,调整批量写入的数据量、时间和频率等进行优化。

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

  重点在于快速完成人群包圈选同时在圈选条件变更过程中,需要快速计算出预计能圈的用户有哪些?

  重点在于多人群包的各个维度对比分析,通过分析结论找到最明显的用户特征(通过 TGI 值判断)

  数据规模大。我们当前是 200+ 个标签,每个标签均有不同的枚举值,总计有 300+ 万的 tag。tag 对用户的打标量级在 900+ 亿条记录。由于标签每日更新导入量级十分大。

  筛选响应时间要求高。针对简单的筛选,要求在秒级别出结果,针对复杂的人群筛选,筛选后人群量大的情况,要求在 20s 内完成人群包生成。

  人群包除了 long 类型的用户 id 外,还需要有多种不同的设备 id 和设备 id md5 作为筛选结果。

  用户分析场景下,针对 300+ 万 tag 的多人叉 TGI 计算,需要在 10min 内完成。

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

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

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

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

  缺乏定制的人群扩散能力。多业务场景对已有人群进行扩散有复杂且多样的需求。

  当前 Doris 的行列转换功能在建设中。在用户画像业务中,将用户 id 更换为设备 id,人群缩减(将具体人群包缩减为一个比较小的人群包用于后续运营动作)过程是通过业务代码实现的,降低了性能。后续结果由行列转换后,用户画像结果处理流程中会将设备 id 获取方式通过 join 维度表来实现,人群缩减通过 order by rand limit 来实现,会有比较明显的性能提升。

  当前 Doris 的读取 bitmap 功能在建设中。业务代码无法读取到 bitmap,只能先通过 bitmap_to_string 方法读取到转换为文本的 bitmap,加大了传输量,降低了圈选性能。后续可以直接读取 bitmap 后,业务逻辑中会替换为直接获取 bitmap,会极大程度的减少数据传输量,同时业务逻辑可以针对性缓存。

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

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

  在从离线数仓进行 broker load 的时候数据依赖丢失,上游数据错误无法评估受影响的范围;

  需要编写冗长的 etl 处理逻辑代码,小的操作变更流程很长,需要全流程(至少 30 分钟)的上线操作;

  在线导入仅支持 kafka json,上游的 pulsar、protobuf 数据仍需要代码开发进行转发,导致每次接入数据都需要转换函数的开发以及同样全流程的上线操作;

  业务逻辑中,期望业务是什么样,Doris 中的数据就是什么样,让业务无感知。这种全增量同步期望被包住,而不是做很多配置或开发很多代码来实现。

  在建设实时数据模型的过程中。需要依赖众多业务的数据,同时需要针对数据逐层建设数据模型。摸索并搭建了实时数据集成系统和实时调度系统,并下沉到工具层。

  早期使用 Doris 开发实时数据业务过程中,由于需要某个数据全/增量同步,同时进行数据转换。需要建 Doris 数据模型,完成全量数据导入,建设增量数据 ETL 和 Routine Load 等开发,需要 1 名工程师 1 天才能将一张表接入到 Doris 中并进行全增量实时同步。

  中间链路多,缺乏报警,针对重要的链路,建设打点和报警成本高,需要 0.5 天左右。

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

  依赖未就绪后续任务就执行。如最近 24 小时的曝光,在 15:05 运行昨日 15:00至今日 15:00 的查询。此时如果 Routine Load 仅导入到 14:50 的数据,这次执行结果异常;

  Doris 资源有限,但很多任务都是某些整点整分钟的,一次性大量的计算任务造成集群崩溃;

  导出存储过程通用,重复代码开发,每次都需要 0.5 - 1 天的时间开发写入和业务接口。

  建立任务依赖机制,通过 kafka 的 offset 和前置表是否完成计算,判断当前计算任务能否执行。后续再也没有出现过数据还未导入就先开始进行数据计算的情况。

  通过退让策略,监控当前 Doris 指标,在高负载情况下避免提交 SQL。避峰趋谷,完成资源最大利用。后续通过这种方案,一定程度的避免了瞬时跑高整体集群的问题。

  全链路监控任务执行情况,和延迟情况,一旦延迟报警,及时沟通解决和恢复业务。一旦任务延迟,监控可非常快速的发现相关问题,多数情况能在业务可接受范围内完成恢复。

  上线 天的工程能力开发时间降低至 0。只需要在 Doris 中有一个可查询的 SQL,经过简单配置即可完成一定时间交付给业务相关数据、排行榜的需求。

  数据,已经成为互联网企业非常依赖的重要资产。数据质量的好坏直接关系到信息的精准度,也影响到企业的生存和竞争力。Michael Hammer(《Reengineering the Corporation》一书的作者)曾说过,看起来不起眼的数据质量问题,实际上是拆散业务流程的重要标志。数据质量管理是测度、提高和验证质量,以及整合组织数据的方法等一套处理准则,而体量大、速度快和多样性的特点,决定了大数据质量所需的处理,有别于传统信息治理计划的质量管理方式。

  AI平台、增长团队、内容平台等已经将部分或全部业务渐渐迁移到实时计算平台,在接入数据更实时,更迅速的接入带来的所享受的收益外,数据质量更加变得重要。

  早期无类似 DQC 系统保证的前提下,我们很多问题都是天级别甚至上线后,才发现存在数据异常,出现过 3 次问题,造成的返工和交付不靠谱的情况,对业务影响巨大。

  早期开发中,在开发过程需要不断针对各种细节规则进行比对,总会花费一定时间逐层校验,成本巨大。

  上线 个月内,通过 DQC 系统规则,当前已发现了 14 个错异常,在 1 - 2h 左右发现,立即修复。对业务的影响降低到最小。

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

  提供了基于时效性的热点、潜力的把控。加速业务在生产、消费方面的使用,进而提升优质创作量及用户对内容消费能力。

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

  完善和升级用户筛选,做到多维、多类型的定向筛选,并接入了运营平台、营销平台等系统,提高了业务效率,降低了业务人员进行人群定向的成本。

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

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

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

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

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

  基于当前业务诉求,部分场景针对 5 分钟级实时无法满足,进一步探索秒级别复杂情况实时能力,并提供能力支持。

  加强并针对用户画像、用户理解、用户洞察 & 模型等进一步建设。通过与具体业务结合,建设贴合业务场景的用户理解成果和相应的分析能力,找到业务的留存点。

  进一步加强新的工具能力的建设,通过建设用户理解工具、用户分析工具,降低产生理解及对业务分析的成本,提升业务效率,快速发现业务价值。

  是围绕Database、BigData、AIOps的企业级专业社群。资深大咖、技术干货,每天精品原创文章推送,每周线上技术分享,每月线下技术沙龙,每季度Gdevops&DAMS行业大会。

上一篇:权威解读:创新管理机制推动数据资源体系开放共享
下一篇:天融信深度参与电信网和互联网数据安全管控平台行业标准编制