System Design 101：街景图像中车牌与人脸自动模糊系统的三段式架构详解

当你打开 Google 或 Apple 地图的街景视图时，道路两旁的汽车车牌与行人的面孔往往都被打上了模糊的马赛克——这是由一套端到端的图像处理流水线自动完成的。本篇文章以 system-design-101 仓库中 《How Google/Apple Maps Blur License Plates and Faces on Street View》 为核心骨架，深入剖析一套可用于面试场景的可行方案：它由数据管道（Data Pipeline）、模糊管道（Blurring Pipeline）与服务管道（Serving Pipeline）三段组成，共 11 个关键步骤。读完本文，你将掌握从训练数据准备、两阶段目标检测网络、敏感目标模糊，到对象存储与用户检索的完整设计链路。

需要特别说明的是，该文档呈现的是一个"可能成立"的高层架构方案，而非 Google/Apple 的真实内部实现细节，这一点在面试中同样适用：面试官看重的是你能把整条链路拆分清楚，并解释每个环节存在的理由。

问题背景与设计目标

街景服务会派出采集车辆拍摄海量街景照片，这些原始图像直接对外发布会带来严重的隐私风险：车牌号、人脸等个人可识别信息（PII）必须被模糊处理后方可上线。核心难点在于：

• 数量巨大：街景图像以亿计，人工打码不可行，必须全自动处理；
• 目标多样：车牌、人脸、门牌号等敏感目标形状、角度、光照各异，检测难度大；
• 实时性要求：采集到发布的链路需要在一定延迟内完成处理，同时保证误检、漏检在可接受范围内。

因此，一个可行的方案需要把"训练一个会认目标的模型"与"大规模跑检测和模糊"两条链路分开设计，这正是原文档三段式架构的由来。

总体架构：Data / Blurring / Serving 三段流水线

原文档给出的高层面架构图将系统拆成三个阶段，总共 11 步，可以先用一张表总览：

阶段	步骤	职责
Data Pipeline	Step 1	获取带边界框（bounding box）标注的训练数据集
Data Pipeline	Step 2-4	数据集预处理与数据增强，完成归一化与缩放
Data Pipeline	Step 5-6	用标注数据训练两阶段（2-stage）机器学习网络
Blurring Pipeline	Step 7-10	街景图像预处理 → 目标边界检测 → 模糊敏感目标 → 写入对象存储
Serving Pipeline	Step 11	用户端检索已模糊的街景图像

三段链路的分工逻辑非常清晰：数据管道解决"模型从哪来"，模糊管道解决"图像怎么被处理"，服务管道解决"结果怎么给用户"。这与仓库中 《数据管道概览》 介绍的 Collect → Ingest → Store → Compute → Consume 五大阶段的思想一脉相承：离线准备好数据与模型，在线完成计算，最终把产物提供给消费方。

Data Pipeline：准备训练数据（Step 1-6）

Step 1：获取边界框标注数据集

训练的起点是一批人工（或半自动）标注的街景图像。标注的核心产物是边界框（bounding box）：每张图中每个敏感目标（车牌、人脸）都会被一个矩形框标出，并附上类别标签。这个标注集就是监督学习的"标准答案"（ground truth），后续模型的检测精度上限由标注质量直接决定。

Step 2-4：预处理与数据增强

原始街景图像不能直接喂给网络，需经过预处理与数据增强：

• 预处理（Preprocessing）：裁剪无效区域、去噪、统一图像尺寸，消除采集设备差异带来的干扰；
• 归一化（Normalization）：把像素值缩放到统一范围（如 0～1 或 -1～1），使各通道数值尺度一致，帮助梯度稳定、加速收敛；
• 缩放（Scaling）：统一输入分辨率，保证网络输入张量形状固定；
• 数据增强（Augmentation）：对图像施加随机翻转、旋转、亮度/对比度扰动、裁剪等变换，在不增加标注成本的前提下扩大有效样本分布，让模型对角度、光照变化更鲁棒——这对街景中千奇百怪的拍摄角度尤为重要。

Step 5-6：训练两阶段检测网络

原文档明确指出训练目标是一个两阶段（2-stage）网络。两阶段检测是目标检测领域的一种经典范式，其核心思想是"先粗后精"：

1. 第一阶段——区域提议（Region Proposal）：网络先生成一批可能包含目标的候选区域（region of interest），剔除大量无意义的背景区域；
2. 第二阶段——分类与回归：对候选区域逐一进行精细分类（是车牌、是人脸，还是背景）并回归出更精确的边界框位置。

与单阶段检测器（如 YOLO、SSD 等"一步到位"范式）相比，两阶段方案通常精度更高、召回更稳，代价是推理更慢、计算成本更高。在街景模糊场景中，漏掉一个车牌或人脸会直接造成隐私泄露，因此"宁可慢一点、也要准一点"的两阶段方案是合理取舍。需要说明的是，原文档只给出了"两阶段网络"这一高层描述，并未指定具体模型；面试中能讲清两阶段 vs 单阶段的权衡即可。

这一环节也可以对照仓库中 《数据管道概览》 的 Compute 阶段理解：模型训练本质上是对已整理数据的一次大规模离线计算。

Blurring Pipeline：检测并模糊敏感目标（Step 7-10）

模型就绪后，进入对生产街景图像的实际处理环节，共 4 步。

Step 7-8：图像预处理与目标边界检测

新采集的原始街景图像首先经过与训练时一致的预处理（归一化、缩放等），保证与模型训练时的输入分布一致，否则检测精度会明显退化。随后进入目标边界检测：模型对图像进行前向推理，输出所有敏感目标的类别与边界框坐标——这一步是整条链路的"火眼金睛"。

Step 9：模糊敏感目标

拿到边界框后，系统对框内区域施加模糊处理。常见手段包括：

• 高斯模糊（Gaussian Blur）：对像素做加权平滑，细节被抹平但整体轮廓尚可辨认；
• 马赛克/像素化（Pixelation / Mosaic）：把区域降采样再放大，形成肉眼可见的色块，是街景服务中最常见的效果；
• 遮盖（遮挡块）：直接覆盖纯色块，信息抹除最彻底。

之所以"只模糊边界框内区域"而不是整图模糊，是为了最大限度保留地图的可用信息——用户依然能看到街道、建筑、路况，只是无法辨认车牌与人脸。

Step 10：写入对象存储

处理完成的模糊图像需要被持久化保存。原文档明确使用了对象存储（object store）。这与仓库中 《存储系统概览》 的介绍相呼应：对象存储以"对象（object）"为单位保存数据，通过 HTTP 接口即可读写，天然适合存放海量、不可变、以读取为主的图片文件，并且具备极强的横向扩展能力——这正是亿级街景图片的理想归宿。一张街景图对应一个对象，配合合理的目录/键命名（如按地理区域、采集批次分桶），后续检索和维护都非常方便。

Serving Pipeline：向用户提供模糊图像（Step 11）

Step 11 是整个链路的终点：用户从客户端发起请求，系统返回已模糊的街景图像。这里可以借鉴仓库中 《设计 Google Maps》 的成熟做法：静态图片类内容适合通过 CDN + 云存储（如 S3） 的方式分发——街景瓦片（tile）是低频变化的静态资源，预先以不同缩放级别渲染好、就近从 CDN 加载，既能大幅降低源站压力，又能保证用户端加载速度。也就是说，模糊图像一旦写入对象存储，其对外服务路径就可以完全复用地图系统成熟的 CDN 分发基础设施。

各阶段的权衡与面试要点

总结这套方案，面试官通常关注以下几个权衡点：

权衡点	说明
两阶段 vs 单阶段检测	两阶段精度更高但更慢，适合"漏检不可接受"的隐私场景；单阶段更快但可能漏检
模糊粒度	只模糊检测框内区域可保留地图信息，但若边界框回归不准会留下隐私残留，需要设置一定的外扩余量（margin）
计算成本	全量街景图逐张推理成本极高，可考虑先粗筛（低置信度区域跳过）或仅对新采集数据执行模糊，旧数据一次性批处理
存储与分发	对象存储负责持久化，CDN 负责读放大场景下的分发，二者解耦便于独立扩展
误检与漏检	人脸误检会破坏地图观感，车牌漏检则造成隐私事故；生产环境通常会叠加人工抽检或二次复核机制

这套架构同时也呼应了仓库 README 中"用可视化和简单术语解释复杂系统、为系统设计面试做准备"的项目定位——它给出的是一个可讨论、可扩展的答题框架，而不是唯一的正确答案。

总结

从 原文档 出发，我们完整还原了一套街景图像敏感信息模糊系统的三段式架构：**数据管道（Step 1-6）**负责用边界框标注数据训练两阶段检测网络；**模糊管道（Step 7-10）**负责对生产图像做预处理、目标边界检测、敏感目标模糊并写入对象存储；**服务管道（Step 11）**则通过 CDN 等基础设施把模糊图像高效地分发给用户。整条链路中，机器学习模型解决"如何认出敏感目标"，对象存储解决"海量结果如何存放"，CDN 解决"如何低延迟地送达用户"——三者各司其职，这也是面试中值得记住的模块化解题思路。