百度智能小程序巡检调度方案演进之路

徽金儒土

导读：百度智能小程序依托以百度APP为代表的全域流量，精准连接用户。如今，百度智能小程序线上体量近百万，包含的内容资源量更有上百亿之多；海量的页面下，如何更高效、快速的发现有问题的页面，从而保障线上内容安全与用户体验，将是一个不小的挑战。本文内容会围绕小程序线上内容的安全巡查机制，并重点介绍小程序的巡检调度方案的演进过程。全文6178字，预计阅读时间16分钟。一、业务简介1.1?巡检业务介绍百度智能小程序依托百度的生态和场景，通过百度APP“搜索+推荐”的方式为开发者获取流量提供了便捷的通道，极大的降低了开发者获客成本。随着小程序开发者入驻量增长，线上小程序的内容质量参差不齐，低质的内容（色情、低俗等）如果在线上展现，会极大地影响用户体验；且部分严重违规内容（政治敏感、赌博等）甚至会造成严重法务风险，同时威胁到小程序的生态安全。因此，针对线上小程序，需要建设质量评估能力、巡检及线上干预机制，通过对小程序内容实现7*24小时的线上巡查，对于不符合标准的小程序，及时进行限时整改或强制下线等处理，从而最终保障小程序线上生态质量和用户体验。1.2 巡检调度策略的目标和核心限制因素?目前百度智能小程序天级去重后的页面访问量达数亿，小程序线上的全部页面资源量更是高达上百亿。理想情况下，为了全面把控风险，应该对所有页面实现“应检尽检”，快速高准地召回线上风险。但实际执行中，需要考虑到以下因素或限制：不同小程序（或主体）下的内容安全指数不同。如，政务等特殊类目小程序发布本身需要经过较严格的审查，出现违规的可能性不大；相反，其他某些特殊类目下的小程序存在违规的风险指数就比较高。而当某些主体下的部分小程序历史上违规次数比较多，该主体下的其他小程序发生违规作弊的可能性就也比较大，等等，导致对不同小程序（或主体）下的页面需要区别对待；小程序被抓取的配额限制。每次针对小程序页面的抓取，最终都等同于对该页面的访问，会转换为小程序服务端的压力，不能因为巡检本身影响到开发者服务的稳定性。在小程序开发平台中，开发者可以表达自身小程序允许被抓取的配额；针对没有显示表达配额的小程序，我们也会根据小程序的流量（PV、UV等）设置合理的抓取阈值；资源限制。对页面的内容安全评估，首先依赖对页面进行spider抓取、渲染、解析其中包含的文本和图片内容、针对文本和图片的安全检测；而抓取、渲染、检测等过程均需要耗费大量的机器资源；其他相关因素和限制还包括：页面流量对应的风险指数（流量高的页面和只有一次点击的页面发生风险时对应的影响面不同）、不同流量入口的区分等。因此，我们需要综合考虑以上各项，设计巡检调度策略，并根据对线上准召case的评估，不断地优化调整策略，优化资源利用率，以更高效、更准确地发现线上潜在的风险问题，降低风险在线上的暴露时长，最终保证智能小程序的生态健康。二、巡检调度方案的演进过程2.1 V1.0版巡检调度方案2.1.1 顶层架构巡检V1.0的顶层设计如下图所示，其中包含的关键组件（或流程）如下：数据源：线上用户在使用百度智能小程序的过程中，端sdk会不断采集相关的埋点日志（包括小程序访问日志、性能日志、异常日志等），随后上报到百度日志中台，并落盘存储。这些日志数据将是巡检页面发现策略很重要的数据源。（备注：基于百度安全准则，我们不会采集或通过登录态等获取或存储密保的手机号等用户隐私信息）页面发现策略：小程序每天有点击（或访问）的去重页面量高达数亿之多，受限于抓取、渲染、检测等各环节的资源限制，如何从这些页面中高效挖掘出潜在的风险页面，是巡检策略的目标。巡检平台：平台本身包含巡检任务生成、页面送抓取、各种能力检测（对应风控类/体验类、红线类/非红线类等各类低质问题）等多个子服务模块，模块间多经过Kafka进行异步交互。低质审核及信号下发：由于部分机审能力侧重高召回，运营同学会对机审召回的风险内容进行人工审核，经过人工确认的低质信号会被下发应用至下游。线上低质干预（打压）：针对各类低质风险问题，结合小程序流量特点、问题的风险等级等，我们有一套完善的、精细化的线上干预流程，会对小程序实施从单页面屏蔽、流量关闭到小程序下线、甚至主体拉黑等不同程度的处罚措施。2.1.2 巡检调度策略实现V1.0版的巡检策略集中采用离线方式调度，结合小程序流量分布、行业类目特点、线上发布周期、违规历史等特征，我们从线上抽象出多种不同的策略，分别做从小时级到周级等不同周期的调度。为平衡业务诉求和资源需要，巡检调度方案还考虑了如下因素：同策略内及不同策略间的页面URL精确去重不同渠道来源的相同页面识别及去重小程序的页面由不同渠道分发，如Feed、搜索、动态转发等，不同分发渠道下的相同页面URL上会有一定区别，而页面内容本身是一样的，我们因此建设了专门的策略来识别不同流量渠道下的相同页面。以上页面去重，目的均是提高资源的有效利用率。2.1.3 业务挑战然而，随着入驻百度智能小程序的开发者量和小程序量的迅速增长，小程序的页面量更是从数十亿激增到上百亿；同时对于服务类业务的引入，对风险控制时效性的要求从天级提升到小时级。当前的架构已不再能满足业务增长对于线上风控的业务要求。2.2 V2.0版巡检调度方案2.2.1 设计目标（优化方向）V1.0架构检测数据以离线数据为主，具有T+1的时间延迟，前一天暴露的风控问题在第二天才能发现，为了更快地发现暴露在线上的风控问题，减少线上问题的暴露时间，V2.0架构设计的最终目标为线上风险页面暴露即发现。为了实现这一目标，送检页面以实时流数据为主，离线数据作为补充；另外，小程序页面检测需要抓取页面内容，会对小程序服务端造成压力，因此还要保证单一小程序页面送检的均匀性与单日限额的限制。具体的设计准则如下：原则：实时优先、离线补充红线：不超过小程序抓取额度限定、抓取均匀，不能集中抓取同一小程序产品需求：保证页面检测的高覆盖率限制：页面抓取资源限制2.2.2 顶层架构演进后的V2.0巡检策略顶层架构设计如下：相较V1.0，V2.0引入了实时数据流，并对小程序的抓取配额做出了5分钟一个窗口级别的更细粒度的控制。2.2.3 V2.0巡检调度策略拆解实现实时巡检整体实现方式如下图所示，可以拆分为三个部分：实时页面发现策略、离线页面发现策略与页面调度策略。实时页面发现策略是相较于巡检V1.0架构的新策略，直接接收实时流日志数据，根据一定策略筛选出用户点击的页面，能够实现分钟级的风控问题发现；离线页面发现策略与巡检V1.0架构类似，采用T-1的日志数据，作为实时数据的兜底，没有全部采用实时数据是由于小程序的使用qps有波峰与波谷，在小程序使用波谷，页面发现量会减少，导致页面抓取与检测能力没有充分利用，此时需要离线数据做为补充；页面调度策略将实时与离线策略聚合，实现了离线数据补充实时数据，页面实时去重的功能，将页面送抓取并送机审检测。2.2.3.1 离线页面发现策略离线页面发现策略，是利用前一日的用户浏览小程序页面的日志，统计出各页面的PV，并经过误伤池过滤、抓取配额限制等策略，将待巡检的页面与页面的PV存入Doris中，供巡检调度使用。数据流转如下图所示，数据依次经过ODS层（Hive表存储小程序原始日志）、DWD层（Hive表存储用户调起日志）、DWA层（Hive表存储各页面PV）、DM层（Doris表存储待检测页面信息），数仓各层间的计算通过Spark实现。2.2.3.2 实时页面发现策略实时页面发现策略的数据源为小程序实时配送服务，小程序实时配送服务是小程序实时数仓的基础，数据使用方在实时数据配送服务的管理端新增日志分流规则，就可以将符合条件的数据分流的指定的消息队列（百度BigPipe）中，利用Spark、Flink或程序接收消息进行计算即可。实时数据服务整体架构如下图所示，目前已实现秒极延迟。在小程序实时数据配送服务中配置筛选用户调起小程序的日志分流规则，利用Structured Streaming接收对应的消息队列Topic，首先提取日志中的关键信息，包括：小程序ID、页面url、事件时间等。小程序每日有点击的页面达数亿，检测全部覆盖所有页面不现实，因此筛选出PV较高的页面优先检测，实时数据PV的计算需要一个时间区间，与Structured Streaming micro-batch对应，取时间区间为5min，Structured Streaming 的 windowSize 设置为5分钟，滑动步长也设置为5分钟，窗口之间不重叠，计算5分钟内，每个页面的PV。对于延迟过久的数据，需要通过watermark（水印）将其抛弃，取水印时间为15分钟，即15分钟前的数据将被过滤。数据输出采用Append模式，每个窗口只输出一次，输出最终结果，避免单窗口内页面重复送检。具体窗口与水印的概念如下图所示（本图引用自Spark Structured Streaming官网，https://spark.apache.org/docs/latest/structured-streaming-kafka-integration.html）。由于页面内容抓取QPS有限，无法将全部页面抓取送检，对于窗口内PV较大的页面全部送抓取，对于低PV页面，由于页面数过多，采用抽检的方式，Structured Streaming不支持Limit语句，为了实现数据抽样，给PV = 1的页面一个0-9999的随机数rand，筛选出rand