用户画像与实时数据分析是互联网公司的数据核心。知乎数据赋能团队基于ApacheDoris，构建基于云服务的高响应、低成本、稳定灵活的实时数据架构，支撑三大核心业务流程：实时业务分析、实时算法特征和用户画像，显着提升对时效性热点和潜力的感知和响应速度，大幅降低运营、营销等业务场景的人群定向成本，为实时算法和核心的精准度带来显着收益业务指标。一、前言在知乎业务中，随着各业务线的发展，对用户画像和实时数据的需求越来越大。在用户画像方面，有望拥有更快、更准、更便捷的人群筛选工具和便捷的用户群体分析能力。对于实时数据，期望有可以实时响应的用户行为流。同时，算法特征、指标统计、业务展示等业务场景对实时数据的需求也越来越多。2021年8月，知乎平台团队成立数据赋能团队。针对历史实时数据需求无承担者的现象，现有的用户画像系统无法满足多样化人群定位的现状，以及业务方进一步进行人群分析的业务需求，提出：基础设施层选择ApacheDoris作为实时数仓技术选型，业务工具层构建实时数据集成、实时数据调度、实时数据质量中心等系统，应用层构建解决方案用于实时数据应用和用户画像应用。该方案专门解决业务痛点，满足业务需求。目前业务的拆分主要难在实时数据和用户画像上。包括以下三个方向：1）实时业务数据，提供实时业务指标，解决业务热点和潜在控制，助力生产、消费，提升优质创作量和内容消费量。提供复杂计算的实时显式指标，提升用户体验，解决业务端维护成本高、后台脚本计算复杂的问题，节约成本，提高人效。2）实时算法特性基于实时数据，提供多种实时算法特性，与算法团队共同提升DAU、留存、用户付费等核心指标。3）用户画像用户筛选，实现多维度、多类型的针对性筛选，接入营销、广告、运营平台等系统，提高业务效率，降低人员成本。用户分析，多角度用户分析，定向用户分析报告0成本，帮助业务部门快速把握核心客户市场。本文来自知乎平台数据赋能团队。基于以上三个方向的目标，以及这四个问题，我们将一一介绍这方面的技术实践经验和体会：如何通过实时数据驱动业务发展？如何从0->1构建实时数据中心？如何构建高效快捷的用户画像系统，解决历史系统的各种问题？如何快速高效的开发业务功能，保证业务质量？1.术语解释2.实时数据和用户画像与各种业务的结合2.挑战和痛点目前的业务目标主要包括以下具体需求。1.有价值1）如何通过有效性发现商业价值？设置热点、潜力等时间指标及相关排名，直接支持业务发展。2）如何最大限度地发挥用户画像的筛选和分析能力？要全面覆盖多维度用户筛选的各种需求。多角度多方位覆盖用户分析。2.数据时效性1）如何在推荐页置顶浏览6条内容时第一时间感知到最新的用户行为？通过UBS构建提高有效性（下文介绍）2）在推荐算法中，非常实时的特征推荐算法的效果要比每日更新特征的算法好很多。如何保证算法在10分钟内发生特征变化？通过实时数据系统与ApacheDoris的共建，升级为10分钟内更新（详见下文）3、接口实时、热点运行场景。期望用户画像服务能够快速秒筛选出大量人群，以及用户后续推送等操作场景，如何解决？通过用户画像系统和ApacheDoris的联合建设，提高了人群筛选的速度（下面介绍）4.复杂性1）对实时数据几乎没有计数和求和的要求。几乎都是复杂的去重和多数据联合计算的情况。以播放音量为例。在广播开始、暂停、结束广播、心跳等多种情况下，会同时出现多个点，需要去重。同时，基于视频答案，视频之间的关系和两位作者联创的关系，需要进行叠加，同时保证在播放时过滤掉一些播放行为父子内容异常。2）针对人群分析业务，期望从多角度、多维度进行人群相关性计算，同时针对当前人群和对比人群进行基于所有用户特征的TGI计算，筛选出显着特征.如何解决这个问题呢？通过用户画像系统与ApacheDoris的联合构建，解决了复杂的人群分析（下文介绍）3）业务数据中存在增删改查逻辑，如何实时同步？与ApacheDoris联合构建实时数据集成系统，解决增删改查逻辑（后述）4）明细数据异常发现滞后。发现异常后，需要更正构造方法和回溯数据修复。如何解决？通过选择Lambda架构作为数据架构方案（下文介绍）三、实践与经验分享1、整体业务架构以当前业务为基础，自上而下拆分。主要分为应用层、业务模型层、业务工具层、基础设施层。基于我们目前的业务形式，自上而下。应用层：负责我们当前的业务应用，直接为业务提供工具或者提供业务的某些模块，与业务共享目标，为业务赋能。业务模型层：支持应用层构建和一定的实时分析能力，也作为一定业务流程的功能模块，构建对外业务和自身的应用层，与业务共享目标，为业务赋能。业务工具层：支持应用层和业务模型层的开发，提供通用工具，旨在降低应用层和业务模型层的建设成本，提高整体建设的工程效率，保证业务稳定和数据质量准确。基础设施：技术中心提供的基础设施和云服务，提供稳定可用的基础功能，保障上层建筑的稳定性。2.实时数据的数据架构选择目前解决问题的数据架构一般有Lambda架构和Kappa架构。根据目前的业务特点，复杂的计算和偶发的异常问题需要大数据量回溯等特性。目前实时数据的数据架构采用的是Lambda架构。Doris承载了分钟级的批处理，Flink承载了秒级简单逻辑的流处理。详情如下：3.应用层建设经验分享1）实时数据系统①业务场景实时数据系统主要有两个方向：实时业务数据和实时算法特征。通过提供实时业务指标，实时业务数据解决业务热点和潜控，助力生产和消费，提升优质创作和内容消费能力。提供复杂计算的实时显式指标，提升用户体验，解决业务端维护成本高、后台脚本计算复杂的问题，节约成本，提高人效。实时算法特性基于实时数据，提供多种实时算法特性，与推荐算法团队共同提升DAU、留存、用户付费等核心指标。②难点依赖数据源多，计算规则复杂。以我们的播放量计算为例：行为很多，需要对行为进行去重。过滤和求和规则很多，需要依赖多个数据源的不同数据结果进行计算。高时间敏感性以算法特征为例，用户浏览某个内容后，经过后续关联的一系列计算，计算结果需要在一定时间内产生（10分钟无输出，后续-up推荐效果会出现波动，26分钟这个feature会降为0）调度过程中的协调成本高，需要一个调度系统能够识别kafka流消费和任务完成的进度。需要严格对齐多个依赖的消费进度。统一进度后，集中进行后续任务计算。数据仓库：调度系统③解决方案构建实时数据库，构建相应的数据模型，降低建设成本。针对依赖数据量大、计算规则复杂、质量难以保证等问题。降低使用施工工具解决问题的成本。通过构建实时数据集成和实时数据调度能力，保证数据访问和数据模型构建的速度，减少访问时间，提高业务访问效率（详见下文）。通过构建实时数据质量中心，保证数据质量，减少发现数据质量问题的时间，提高发现效率，保证业务交付结果的高时间敏感性（详见下文），加强监控，提高吞吐效率和Doris集群计算效率：建立写入延迟、计算延迟等监控，快速发现问题。更改Doris集群的参数，调整批量写入的数据量、时间和频率等进行优化。目前我们的Load主要包括BrokerLoad和RoutineLoad。其中时效性要求高的是RoutineLoad。我们有针对性地调整了参数。Doris添加了RuntimeFilter以通过BloomFilter提高Join性能。Doris集群在0.14版本新增了RuntimeFilter，对Join中大量key的过滤有明显的提升；这一变化显着提高了我们当前几个业务调度的性能。时间从40+s增加到10s左右。2）用户画像系统DMP①业务场景用户画像系统主要有两大功能：用户检索和用户分析。用户检索。重点是快速完成人群的圈层选择。同时，在改变圈子选择条件的过程中，需要快速计算出预期被圈子的用户是谁？用户分析。重点是对多人群包的各个维度进行对比分析，通过分析结论可以找到最明显的用户特征（以TGI值判断）②面临的困难是数据规模庞大。我们目前有200+个标签，每个标签都有不同的枚举值，总共有300万+个标签。用户标签标注级别900亿+记录。由于标签每天更新，导入量非常大。筛选响应时间要求很高。对于简单的筛选，要求在几秒内出结果。对于复杂的人群筛查，在筛查后人数较多的情况下，要求在20秒内完成人群包的生成。除了long类型的userid，crowd包还需要有各种不同的deviceid和deviceidmd5作为过滤结果。在用户分析场景下，需要在10分钟内完成300万+标签的多人群交叉TGI计算。③解决方案DMP业务架构针对性解决DMP业务流程性能问题；大规模数据可以提高导入性能和分而治之。数据模型更改，拆分文件。Doris的存储按照Tablet分散在集群上。通过调整数据模型，保证分布均匀，每个文件尽可能小。要导入更改，请拆分导入。?由于每次BrokerLoad导入存在性能瓶颈，将900亿+行数据拆分为1000+BrokerLoad导入任务，保证每次导入总量足够小。提高人群筛选和人群分析的计算速度，分而治之。业务逻辑变化，用户分裂。每隔0到100万将用户分成一个组。所有用户的交差相当于所有组用户的交差后的并集。所有用户的交叉合并差异总数等于组用户的交叉合并差异总数的总和。数据模型更改，拆分文件。设置位图的分组参数，设置分组为colocategroup。保证每组的交差计算都在自己的BE中完成，没有shuffle。多拆分位图表的桶，通过更多的文件同时计算加速结果。更改计算参数以提高并发性。因为计算过程通过分而治之的方式被分成了多个小任务。通过增加并行度parallel_fragment_exec_instance_num进一步优化计算速度。④效果上线后，知乎接入了多个主要场景的业务，支持了多个业务方的人群导向和分析能力。为业务带来曝光率、转化率等直接指标。同时，在工具性能方面，还有以下表现：导入速度。目前每天导入900亿+行数据，3小时内完成导入。人群估计。人群估计基本可以在1s内完成，P95985ms。人群围成一圈。人群选择过程在5秒内完成，整体圈子选择大约需要2分钟。（更新中会介绍）人群分析。人口分析过程在5分钟内完成。⑤有待改进功能扩展缺乏定制化的人群扩散能力。多业务场景对现有人群的扩散需求复杂多样。缺乏对用户群体的着色，无法在多个环节完成用户效果的恢复和后续分析。性能改进目前Doris的行列转换功能正在建设中。在用户画像业务中，将userid替换为deviceid，通过业务代码实现减人群（将特定的人群包缩小为相对较小的人群包进行后续操作），降低了性能。后续结果经过ranks和columns转换后，在用户画像结果处理过程中通过join维度表实现deviceid的获取方式，通过randlimit实现order减少人群，具有更明显的性能提升。目前Doris的读取位图功能正在建设中。业务代码无法读取位图，只能读取通过bitmap_to_string方法转换为文本的位图，增加了传输量，降低了圈选性能。后面可以直接读取位图后，业务逻辑就换成直接获取位图，这样会大大减少数据传输量，同时可以有针对性地缓存业务逻辑。对于人群估计逻辑，目前是通过bitmap_count(bitmap_and)等两个函数完成的。后续Doris会提供bitmap_and_count合并为一个函数，替换后可以提高计算效率。4.工具层建设经验分享1）数据整合①业务场景“天下无米之炊”，没有数据就什么都没有，数据的收集作为基础至关重要。Doris数据仓库自带的各种数据导入方式，对于数据入库来说非常方便，但是我们在使用过程中也遇到了一些问题。例如：从离线数仓执行broker加载时数据依赖丢失，上游数据错误无法评估影响范围；冗长的etl处理逻辑代码需要编写，小操作变更过程很长，需要全程（至少30分钟）在线运行；此外，每次部署操作在初始化MQ消费者时可能会遇到各种问题；缺乏运行状态监控，无法在几分钟甚至几小时内发现异常问题；线上导入只支持kafkajson，上游的p??ulsar和protobuf数据还需要代码开发和转发，导致每次接入数据都需要开发转换函数和线上运行全流程相同；在业务逻辑中，期望的业务是什么，Doris中的数据是什么，让业务无感知。这种全增量同步有望在不做大量配置或开发大量代码的情况下被wrapped来实现。②解决方案在构建实时数据模型的过程中。它需要依赖很多业务的数据，同时需要为数据逐层构建数据模型。探索构建了实时数据集成系统和实时调度系统，并下沉到工具层。实时数据集成。构建快速和自定义的配置，并为不同的数据源构建导入功能。配合Doris的BrokerLoad和RoutineLoad，在此基础上构建业务的全增量同步。对内部暴露接口的封装和集成能力，业务层无需了解中间过程，只选择同步的数据库和数据表进行实时同步。③效果同步配置同步任务上线前，前期使用Doris开发实时数据业务，由于需要对某条数据进行全量/增量同步，同时进行数据转换。需要搭建Doris数据模型，完成全量数据导入，搭建增量数据ETL和RoutineLoad等开发。一张表接入Doris并进行全增量实时同步，需要1个工程师1天的时间。中间环节多，告警不足。对于重要环节，施工管理和报警成本高，需要0.5天左右。全卷：原库TiDB->中间部分（DataX）->Doris增量：原库TiDB->TiCDC->CanalBinlogKafka->ETL（填充数据）->Kafka->RoutineLoad->Doris只需要走在线10分钟配置，数据集成包括模型、数据导入、中间ETL转换、附加数据补充和RoutineLoad全部搭建完成。业务层不需要感知数据的中间环节，只需要描述我期望同步哪张表即可。上线后无需关心业务。第一步配置完成后，后续的监控、告警、一致性等都通过集成来全面解决。2）数据调度①业务场景在最初通过Doris构建实时数据的过程中，我们使用RoutineLoad后的数据，然后在调度任务中执行后续的计算逻辑，然后将计算结果导出到bearer存储，如Redis、Zetta（知乎自研HBase协议）完成外部承压。在这个过程中，遇到了如下问题：依赖的后续任务没有准备好执行。例如，对于过去24小时内的曝光，从昨天15:00到今天15:00的15:05运行查询。此时如果RoutineLoad只导入14:50的数据，则本次执行结果异常；Doris资源有限，但很多任务都是按小时分分钟执行的，一次大量的计算任务导致集群崩溃；任务是否执行成功，任务是否延迟，是否影响业务，无告警无反馈；存储过程的导出很常见，重复的代码开发，每次需要0.5-1天的时间来开发编写和业务接口。②解决方案架构图流程图③效果同步任务收益建立任务依赖机制，通过kafka的offset判断当前计算任务是否可以执行，pre-table计算是否完成。从来没有出现过在导入数据之前就开始计算数据的情况。通过退避策略监控当前的Doris指标，避免在高负载情况下提交SQL。避峰趋谷，最大限度地利用资源。后续采用该方案，在一定程度上避免了瞬间跑起来整个集群的问题。全链路监控任务执行状态和延时。一旦出现延误和告警，及时沟通解决并恢复业务。一旦任务延迟，监控可以快速发现相关问题，大多数情况下可以在业务可接受的范围内完成恢复。上线后，原本需要1天的工程能力开发时间减少为0，只需要在Doris中有一条可查询的SQL，通过简单的配置，就可以在1天内完成业务相关数据和排行榜的交付。一定时期。3）数据质量①业务场景数据已经成为互联网企业赖以生存的重要资产。数据的质量直接关系到信息的准确性，也影响着企业的生存和竞争力。MichaelHammer（《Reengineering the Corporation》一书的作者）曾说过，看似微不足道的数据质量问题，其实是拆解业务流程的重要标志。数据质量管理是一套衡量、改进和验证质量的处理指南，以及整合组织数据的方法。大数据量大、速度快、多样性的特点决定了大数据质量所需要的处理方式，有别于传统的信息治理方案的质量管理方式。具体到知乎的各个业务：AI平台、增长团队、内容平台等都逐渐将部分或全部业务迁移到实时计算平台上，享受数据更实时、访问速度更快带来的收益。此外，数据质量变得更加重要。完整性数据完整性问题包括：模型设计不完整，例如：唯一性约束不完整，引用不完整；数据条目不完整，例如：数据记录丢失或不可用；不完整的数据属性，例如：数据属性空值。不完整的数据可借鉴的价值会大大降低，也是最基本、最常见的一类数据质量问题；一致多源数据的数据模型不一致，如：命名不一致、数据结构不一致、约束规则不一致。数据实体不一致，例如：数据编码不一致、命名和含义不一致、分类级别不一致、生命周期不一致……在同一数据多副本的情况下，数据不一致、数据内容冲突；准确性准确性也称为可靠性，用于分析和识别不准确或无效的数据，不可靠的数据会导致严重的问题，会导致有缺陷的方法和糟糕的决策；唯一性用于识别和衡量重复数据，Redundantdata。重复数据是导致业务不协调、流程不可追溯的重要因素，也是数据治理需要解决的最基础的数据问题；关联数据的问题是指数据关联的数据关系缺失或错误，如：函数关系、相关系数、主外键关系、索引关系等。数据关联出现问题，会直接影响数据分析的结果，进而影响管理决策；真实性数据必须真实、准确地反映客观实体或真实业务的存在。真实可靠的原始统计数据是企业统计工作的灵魂，是一切管理工作的基础，是经营者做出正确经营决策必不可少的第一手资料；时效性数据的时效性是指在需要的时候能否获取到数据，数据的时效性和企业数据处理的速度与效率有着直接的关系，是影响业务处理和管理效率的关键指标。②解决方案全流程数据链路和各级质量保证手段业务架构业务流程③效果一个业务健康监控就是通过DQC来监控某个业务的健康状况。这个业务由多个导出任务和中间计算任务和一些数据源组成。目前的情况是一切正常。在此期间，如果某个节点出现异常，可以及时发现。任务中间逻辑监控的任务中间计算部分规则不符合标准，导致任务失败。④收益在上线前前期没有类似DQC系统保障的前提下，我们的很多问题都是在日级甚至上线后才发现的，存在数据异常。有3个问题，导致返工和交付不可靠。商业影响是巨大的。在开发初期，需要在开发过程中不断对比各种细则，层层验证总是需要一定的时间，成本巨大。上线后1个月内，通过DQC系统规则，发现错误14个，大约1-2小时发现，并立即修复。对业务的影响降到最低。系统上线后，在开发过程中，相关数据开发完成后，如果出现异常，会产生异常告警，大大节省了人工发现的成本，因为修复时间早，有在后续开发开始之前就已经修复了，这大大节省了开发过程中的返工成本。4.总结与展望1.收益总结1）业务拓展①为实时业务数据提供基于时间的热点和潜力控制。加速业务在生产和消费中的使用，从而提高优质创作量和用户对内容的消费能力。同时提供显式指标，提供实时复杂计算，提升用户体验，去除业务后台通过脚本计算指标的方式，降低业务复杂度，节约成本，提高人效。②针对实时算法特征，提供基于创作者、内容、消费者的实时算法特征。与多个项目的算法团队一起，DAU、留存、用户付费等核心指标得到显着提升。③完善升级基于用户画像的用户筛选，实现多维度、多类型的精准筛选，接入运营平台、营销平台等系统，提高业务效率，降低业务人员人群筛选成本。构建完善用户分析，实现多角度用户分析，零成本有针对性的用户分析报告，帮助业务部门快速把握核心客户市场。2）在工具建设方面，完成了实时数据领域和用户领域的布局，搭建了相关的开发和维护工具，解决了以往无基础设施、无业务工具、高成本的问题。这方面的开发成本。建立集成、调度和质量系统。通过工具降低业务开发和迭代的成本，让业务快速发展，同时保证交付质量，提升业务基线。3）人员组织方面，将实时数据和用户画像拆分能力从上到下分为应用层、业务模型层、业务工具层和基础设施层。通过组织分工，明确层级边界，加快业务目标的达成。建立和完善多层次团队成员梯队。根据不同方向的同学，给出不同的OKR目标，做到跨层级方向隔离，同层级方向，同模块目标。共同致力于整体实时数据和用户画像服务建设。2、未来展望自2021年8月成立以来，我们一直在思考如何提供更好的实时数据服务？实时数据可以构建什么样的应用，为企业创造价值？如何做好用户画像服务？用户画像服务的筛选和分析能力如何为业务创造更大的价值？我们在摸着石头过河的同时，也在不断探索和建设相关的业务能力和基础设施。在明年的发展中，我们将在以下几个方面进一步发展：1）加强基于实时数据的基础能力工具层建设，持续降低基于实时数据的建设和交付成本。提高数据质量工具覆盖率，为商业模式提供质量保障，提供基于实时数据的图像质量保障能力。基于目前的业务需求，部分场景无法做到5分钟级别的实时性。进一步探索秒级复杂态势实时能力，提供能力支撑。2）加强基于用户画像，进一步构建用户画像、用户理解、用户洞察&模型等，结合具体业务，构建贴合业务场景的用户理解结果和相应的分析能力，寻找业务留存点。进一步加强新型工具能力建设，通过用户理解工具和用户分析工具的建设，降低生成理解和业务分析的成本，提升业务效率，快速发现业务价值。
