百度智能小程序巡检调度方案演进之路
导读：百度智能小程序依托以百度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 顶层架构
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 < 100的页面，即低PV页面抽样1%，最终将高PV页面与抽样后的低PV页面union后输出，保证送检qps小于页面抓取qps限制。
筛选出的页面还需要经过一系列产品策略的限制：
部分小程序为免审小程序，将这些小程序的页面过滤出去；
误伤池是机审被召回，但人审复核无问题的页面，过滤误伤池可以大幅提升检测准确性；
大量的页面抓取会对小程序造成服务端压力，每个小程序有抓取配额限制。
页面过滤时采用left join操作，将实时流与离线维度表关联，离线维度数据也在不断地更新，需要保证维度数据的名称不变，数据内容不断更新，保证实时流在每一个窗口都可以拿到最新的维度数据。
最终产出的数据输出到Elasticsearch中，若全部数据都写在同一个索引下面，增删改都在这同一个索引下，索引下的数据量与日俱增，查询与插入效率降低，并且删除历史数据不方便，delete_by_query本身性能差，且非物理删除，不能起到释放空间和提高性能的目的。这里采用索引别名与按时间索引切分的方式，好处是删除历史数据可以按历史索引删除，方便操作，可以有效释放空间，提高性能。ES索引切分需要依次创建索引别名，创建索引模板，创建包含日期的索引，制定并配置rollover规则，创建切分索引与删除旧索引的定时任务。
PUT /%3Conline-realtime-risk-page-index-%7Bnow%2FH%7BYYYY.MM.dd%7C%2B08%3A00%7D%7D-1%3E/{ "aliases": { "online-realtime-risk-page-index": { "is_write_index" : true } }}
POST /online-realtime-risk-page-index/_rollover{ "conditions": { "max_age": "1d", //按天切分索引 "max_docs": 10000000, "max_size": "2gb" }}2.2.3.3 页面调度策略
经过前面两部分介绍的离线和实时页面发现策略，分别得到了待检的离线页面数据集和实时页面数据集。下面将基于这两个待检集合来详细介绍最终的页面调度策略。
1、数据划分，周期调度
对于离线数据集，使用【批次】来划分多批数据集；对于实时数据集，使用【窗口】来划分多批数据集。使用【定时任务】来周期性处理这些被划分的数据集。将一天划分为 bn 个批次，假设【定时任务】当前运行的时间所在当天的分钟数为 currentMinutes，那么，现在要处理的【离线数据】的【批次】 batch = currentMinutes * bn / (24 * 60)。对应地，现在要处理的【实时数据】的【窗口起点】 windowStart = batch * (24 * 60) / bn。考虑到实时数据处理的水印设置和定时任务的调度周期，currentMinutes并不是严格取当前的时间，而是由当前时间-30分钟后得到。
2、实时优先，离线补充
再次围绕系统资源的限制、对单个小程序抓取造成的压力、离线和实时页面集合间的补充等设计原则，在页面调度单个周期内，如果没有达到限额，会全部调度实时页面进行检测；如若实时页面此时仍未能达到限额，那么会使用离线页面进行补充，以保证系统时刻满负荷运行，充分均匀有效利用到资源。同时，这种调度方式也能保证实时和离线策略互备，当单个策略出现问题的时候，系统仍然可以通过另一个策略发现页面并送检，不至于空转。此外，离线数据集中页面会根据PV进行到倒排，使得点击较多的离线页面被检测更优先检。
3、页面去重
基于线上页面的PV分布规律，为尽可能提高巡检的PV覆盖率，页面调度策略中还增加了高 pv 页面当天去重与中低PV页面指定周期内去重的逻辑。存储数据库选型Redis，数据结构及页面url对应的分片计算设计如下：
数据结构
集合，集合中存储已经检测页面的URL转换为16位md5，单个集合存储一天的数据量太大，因此将一天的数据分成多个分片，每一个分片是一个集合。如果将一天分位100个分片，那么一天就有100个集合。
url对应的分片计算
1、小程序url中字母转int后相加得到数字x
2、x mod 分片数量得到 key
数据结构示意图：
2.2.4 收益回顾
智能小程序巡检平台在不断演进、优化的过程中，平台能力得到极大的提升：
每日巡检的页面数量已支持数千万量，页面覆盖率得到极大提升；
加入了基于实时数据的实时巡检通路，将问题页面的线上暴露时长大幅减小，问题发现达分钟级，整理干预链路由天级降低至小时级；
离线数据补充实时数据的调度策略，充分地利用了页面抓取与页面检测资源，利用更少的资源，检测更多的页面；
最终建立起小程序质量保障体系，帮助更好地发现并处理线上问题，控制线上风险，降低线上低质占比，保障小程序的生态健康。
三、思考与展望
本文我们围绕巡检的业务目标和背景，重点介绍了小程序巡检调度策略的演化历程，足以见对线上质量的巡检工作是需要不断建设和磨练的。随着业务的不断发展，线上资源会更丰富，内容更加多样性，页面资源量还会保持持续增长，我们势必会面对更大的挑战。如何从海量页面资源中高效、准确地召回线上风险问题，始终是巡检调度策略的思考目标。我们会不断地进行探索、优化，坚定不移地为不断增长的智能小程序业务保驾护航。