亿级搜索系统的基石，如何保障实时数据质量？

2021-09-21 08:03:01

阿里文娱有专门的搜索引擎算法团队做相关的探索。可你知道吗？在算法业务背后，面对数亿的视频数据，还有一支技艺高超的测试团队，在保障庞大数据系统的数据质量。

阿里文娱测试开发专家熙闫将通过本文讲述阿里文娱是如何构建实时数据质量保障体系，进而提升搜索引擎数据全面、快速、准确效果的，希望对大家有启发。

一、背景

优酷视频搜索是文娱分发场的最核心入口之一，数据源多、业务逻辑复杂，尤其是实时系统的质量保障是一个巨大挑战。如何保障数据质量，如何衡量数据变化对业务的影响？本文会做详细解答。

二、现状分析

搜索数据流程如下图所示，从内容生产到生成索引经历了复杂的数据处理流程，中间表多达千余张，实时数据消费即消失，难以追踪和复现。

从上图可以看出，整个系统以实时流模式为数据流通主体，业务层面按实体类型打平，入口统一分层解耦，极大的增加了业务的实时性和稳定性。但是另一方面，这种庞大的流式计算和数据业务系统给质量保障带来了巨大的挑战，从0到1建设实时数据的质量保障体系，同时保证数据对搜索引擎业务的平滑过渡是我们面临的考验。

三、实时数据质量保障体系方案

质量保障需要透过现象看本质。通过对架构和业务的分析，可以发现整个流式计算的业务系统有几个关键点：流式计算、数据服务、全链路、数据业务（包括搜索引擎的索引和摘要）。整体的质量诉求可以归类为：

基础数据内容质量的保障
流式链路的数据正确性和及时性保障
数据变化对业务效果的非负向的保障

结合线上、线下、全链路闭环的理论体系去设计我们的整体质量保障方案，如下图所示：

四、线下质量

1．实时dump

数据测试包含链路节点比对、时效性、正确性、一致性、可用性等方面，依托于阿里技术资源设计实时dump的方案如图：

2．数据一致性

一致性主要是指每个链路节点消费的一致性，重点在于整体链路的各个节点的数据处理消费情况保持一致，通过对数据消费的分时分频率的比对完成一致性验证。方案如下图：

我们采取不同的数据流频率输送给实时链路进行消费，利用各层的dump机制进行数据dump，然后取不同的抽样间隔对dump数据计算分析，分为三种不同的数据频率模式：

natural-flow：自然消费的数据流，是源于线上真实的数据消息通道，即自然频率的数据消费，以该模式进行测试更贴合实际业务情景
high-frequency：高频数据流，采用超出真实峰值或者其他设定值的数据频次输送给实时消费链路，在压测或者检测链路稳定性中是一个常用的测试策略；
low-frequency：低频数据流，采用明显低于真实值或者特定的低频次数据输送给实时消费链路。如果数据链路中有基于数据量的批量处理策略会暴露的比较明显，比如批量处理的阈值是100，那么在业务低峰时很有可能达不到策略阈值，这批数据就会迟迟不更新，这个批量处理策略可能不是合理。同时低频次的消费对于实时链路处理的一些资源、链接的最低可用度这些层面的检查也是有意义的。

3．数据正确性

数据正确性是对于数据内容的具体值的检查，总体原则是：

首先，高优保障影响用户体验的数据；
其次，保障业务层直接使用的核心业务相关的数据内容；
再次，中间层的核心业务相关数据由于不对外露出，会转换成业务引擎需要的最终层的业务数据。所以中间层我们采用通用的规则和业务规则来做基础数据质量保障，同时对上下游数据内容变化进行diff对比，保障整个流程处理的准确性。

4．数据可用性

数据可用性指的是数据链路生产的最终数据是能够安全合理使用的，包括存储、查询的读写效率、数据安全读写、对不同的使用方提供的数据使用保持一致性等。

可用性保障主要关注数据的存储、查询、数据协议（数据结构）三个大的维度，衡量的标准重点关注三个方面：

易读写：数据的结构化存储和写入必须是高效合理的；
服务一致：数据在结构化存储后，对外提供的服务有很多种，比如PB协议、API、SDK等，需要根据业务去考量。比如SDK、PB等对外提供使用的方式会涉及协议版本，不同的版本可能数据结构不一致导致对外使用的数据不一致性；
安全可靠：重点关注存储稳定、可靠、高效，兼顾效率和稳定性，同时更要关注安全性，防范随意改写数据、恶意dump等严重影响线上数据使用安全的风险。

5．时效性

由于实时链路的流式特性和多实体多次更新的特性，在测试时效性时核心问题有两点：

如何去跟踪确定一条唯一的消息在整个链路的消费情况；
如何低成本获取每个节点过程的数据链路时间。

我们抽象出一个trace+wraper的流式trace模型如下图：

获取链路过程的每个节点的时间，包括传输时间和处理时间。对于track-wraper需要约定统一的track规范和格式，并且保证这部分的信息对业务数据没有影响，没有增加大的性能开销。如下图，我们最终的信息中经过trace&track-wraper带出来的trak-info，采用json格式方便track-info的扩展性。

这样就很容易去获取到任意信息，计算每个节点的时间。

我们也可以通过抽样计算一些统计指标衡量时效：

对于时效性有明显异常的数据可以筛选出来，进行持续优化。

6．性能测试

实时数据链路本质是一套全链路数据计算服务，所以我们也需要测试它的性能情况。

第一步，我们先具体化全链路的待测系统服务。

包括两部分的性能，Bigku的反查服务，即HSF服务，再就是blink的计算链路节点。

第二步，准备数据和工具。

压测需要的业务数据就是消息。数据准备有两种方式，一种是尽可能模拟真实的消息数据，我们只要获取消息内容进行程序自动模拟即可；另外一种会采用更真实的业务数据dump引流，进行流量回放。

由于数据链路的特性，对压测链路施压就是转成发送消息数据，那么如何控制数据发送呢？有两种方式：

第一种我们开发一个发送消息的服务接口，转变成常规的接口服务压测，然后可以采用阿里的任何压测工具，整个测试就变成常规的性能测试；

第二种我们可以利用blink消息回追的机制，重复消费历史消息进行压测，不过这种方法有弊端，无法控制消息的频率。

7．压测和指标收集

根据业务情况来收集指标，指标包括服务本身的指标和资源指标，可以参考我们的部分性能测试报告示例（数据有截断）：

五、线上质量

1．服务稳定性保障

稳定性包括两个层面，一是实时计算任务链路的每个节点的稳定性，二是内置服务的稳定性。

2．实时计算

由于实时计算采用全blink的计算方式，我们可以利用blink系统本身的特性来做任务的监控。每个节点的任务都需要配置稳定性指标的监控，包括rps、delay、failover等。效果示例如下：

3．实体服务

实体服务是HSF服务，采用阿里统一的监控平台来完成整体服务能力的监控，示例如图：

整体指标包含以下内容：

4．数据消费保障

在数据消费层面，重点关注每个链路层级的消费能力和异常情况。基于积累的track-report能力进行数据统计，结合平台完备的基础能力来完成消费保障。分为两层：

核心层：消息出口的实体消息统计监控，包括整体数量和消息内容分类统计监控。如图示例：

中间层：包括每个实体消息处理的accept，处理逻辑层的success、fail、skip指标，便于我们实时知晓每个链路层收到的消息、成功处理、错误和合理异常等消费能力情况。如图示例：

5．数据内容保障

数据内容层，建设综合数据更新、数据内容检查、业务效果三位一体的精准数据检查，达到数据生产、消费、可用性的闭环检测，如图所示：

从图中可以看出，我们数据内容保障分为三部分：

sampler：抽样器，通过blink实时消费消息在链路中抽取待测数据，通常是只抽取数据ID；抽样策略分间隔和随机两种。间隔策略就是取固定时间间隔的特定数据进行检查；随机则根据一定的随机算法策略来抽样数据进行检查。
data-monitor：是做数据内容检查，包括更新时效性和数据特征属性检查。
effect-monitor：数据正常更新之后，对在线业务实时产生的效果影响进行检查，检查的核心点包括搜索的两大基本效果——召回和排序，以及用户体验相关的数据属性的检查。

部分数据实时效果示例图：

6．实时干预与自动修复

实时干预通道，如下图：

实时干预系统会根据不同的干预需求，对消息内容和干预机制进行消息组装和通道分发。

当主通道业务链路正常时，若需要强制更新一个ID维度的数据，只需要输入ID走正常主链路更新即可。
当需要强制干预某些具体的数据内容到指定的消息通道时，则可进行数据内容级别的更详细的精准干预。
急强制干预，是指当主链路中间层处理有较大延迟或者完全阻塞时，会造成下游业务层数据无法正常获取输入。通过主逻辑全copy的机制建立了一个VIP的消息通道，通过VIP通道去直接干预出口消息，保证业务数据正常能进行优先更新。