YData Profiling 中的 PII 识别与敏感数据管理：从本地脱敏配置到 Fabric Data Catalog 的自动化分类

PII（个人身份信息）识别与管理是企业数据治理、隐私合规和数据安全实践的基石。本篇技术指南以 YData 生态中 data-profiling 的 PII 识别与管理工作为核心，系统讲解 PII 的定义与风险、自动化识别的必要性，以及 YData Fabric Data Catalog 如何借助 NER 命名实体识别模型与传统规则模式相结合，实现规模化、自动化的 PII 检测；同时结合本仓库的配置与源码，说明开源侧 data-profiling 提供的本地敏感数据处理方案（sensitive 配置组、样本脱敏、值遮蔽等）。读完本文，你将掌握在 data-profiling 中配置敏感数据报告、理解 redact 遮蔽机制、并了解企业级 PII 分类平台的能力边界与定位。

什么是 PII，为什么它如此关键

个人身份信息（Personally Identifiable Information, PII） 指任何能够用于识别某个具体个人的信息，包括但不限于：

• 姓名（names）
• 地址（addresses）
• 电话号码（phone numbers）
• 社会安全号码 / 身份证号（social security numbers）
• 电子邮件地址（email addresses）
• 财务信息（financial information）

在当今数字时代，数据被大规模地收集、存储和处理，PII 因此成为数据生命周期中需要重点保护的对象。YData Profiling 文档明确将 PII 管理视为数据治理与隐私合规的核心环节：一旦 PII 被误用或未经授权访问，可能引发身份盗窃（identity theft）、金融欺诈（financial fraud）和隐私泄露（breaches of privacy）等严重后果。

为什么要自动化 PII 识别

自动化 PII 识别的价值源于两个现实压力：

1. 合规驱动：全球许多国家和地区都出台了严格的数据保护法规（如欧盟 GDPR、美国 CCPA、HIPAA），要求组织负责任地处理 PII。正确的 PII 分类是满足法规要求、避免处罚的前提。
2. 规模驱动：随着数据量持续增长，人工识别 PII 变得不切实际且极易出错。手工检查成千上万个字段、追踪跨系统分布的敏感信息，既无法保证覆盖率，也无法保证一致性。

正是基于这两点，一个稳健的 PII 管理解决方案对于组织建立并维护安全的敏感信息处理方式、赢得信任并遵守法律要求至关重要。

YData Fabric Data Catalog：基于 NER + 规则模式的 PII 检测

在 YData 生态中，PII 自动化识别的核心能力由 YData Fabric Data Catalog 承载。根据仓库文档 pii_identification_management.md，Fabric Data Catalog 是 data-profiling 的一个可扩展、可交互的云端版本，它将数据画像（data profiling）体验与先进的机器学习解决方案集成在一起：

• 基于 NER（Named Entity Recognition，命名实体识别）模型的深度学习方法；
• 结合传统基于规则的模式识别（如正则表达式匹配邮箱、电话号码、证件号等固定模式）。

这种「深度学习 + 规则引擎」的双通道设计，使得系统既能识别结构化字段中的固定模式，又能理解非结构化的文本上下文，从而高效地检测 PII。例如，规则模式可以稳定命中「邮箱地址」「手机号」这类格式明确的字段，而 NER 模型则可以识别出「人名」「地名」这类依赖语义的实体。

需要明确的是，该能力属于 YData 企业级功能（Enterprise feature），仅在 YData Fabric 平台内提供，并非开源 data-profiling 库内置能力——开源侧对应的是本地敏感数据保护配置（见下文）。Data Catalog 还通过元数据管理自动记录数据集的 PII 存在情况，如 collaborative_data_profiling.md 所述：Data Catalog 会自动捕获并存储数据集元数据，包括数据类型、来源、最近更新时间、表间关系，以及潜在 PII 的存在情况，并支持从多种数据源自动摄取元数据，使目录始终保持最新。

为什么选择 Fabric 来管理数据集的 PII 识别

除了自动化的 PII 识别，Fabric Data Catalog 还通过自动化数据画像与元数据管理，在数据治理、隐私合规和整体数据管理方面带来以下关键收益：

满足隐私法规合规（Compliance with Privacy Regulations）

GDPR、CCPA、HIPAA 等法规要求组织负责任地处理 PII。一个专门的平台能够确保 PII 被正确分类，帮助组织满足法律要求并避免潜在罚款。合规不是一次性动作，而是需要持续、可审计的分类能力，这正是平台化方案的优势。

以数据画像保障识别准确性（Data Profiling for Accuracy）

数据画像（data profiling）是对数据结构与内容的分析和理解。将数据画像能力融入平台，组织可以确保 PII 识别与分类的准确性，维护数据完整性，降低误分类风险——例如避免把「用户名」这类非 PII 字段误判为敏感字段，或漏掉隐藏在备注文本中的个人信息。

高效管理大规模 PII（Efficient Management of PII）

随着数据规模增长，手工管理和编辑 PII 分类变得不现实。平台化方案精简了管理流程、减少出错概率，并允许组织跨多个数据集和系统持续追踪 PII 的分布情况。

促进数据治理（Facilitating Data Governance）

数据治理要求建立策略与流程来保证数据质量、安全与合规。PII 管理解决方案通过提供集中式枢纽来监管 PII 分类、元数据和相关策略，从而增强组织的数据治理能力。

开源侧的配套能力：本地敏感数据处理

虽然自动化的 NER + 规则 PII 识别属于 Fabric 企业级能力，但本仓库的开源 data-profiling 同样提供了一套完整的本地敏感数据处理方案，可在不联网、数据不外发的前提下保护隐私。相关细节记录在 sensitive_data.md，并有示例代码与源码实现佐证。

核心前提：数据不出本地

data-profiling 不会向外部服务发送数据，因此适用于私有数据场景（如私人健康记录）。所有分析都在本地完成，这是进行敏感数据处理的基础信任前提。

sensitive 配置组：一键生成仅含聚合信息的报告

在需要共享报告、但又不能泄露样本数据的场景下（例如私人健康记录），可以使用 sensitive=True 快捷配置，让报告只提供聚合信息、不展示任何个体记录：

report = df.profile_report(sensitive=True)

从源码看，这个参数背后的实现位于 config.py 的 Config.arg_groups 定义中，sensitive 组会同时设置：

"sensitive": {
    "samples": None,          # 关闭样本展示（head/tail/random 均为 0）
    "duplicates": None,       # 关闭重复行展示
    "vars": {"cat": {"redact": True}, "text": {"redact": True}},
}

即：关闭样本区与重复区，并对分类（categorical）和文本（text）变量的取值进行遮蔽（redact）。该配置组的加载逻辑位于 profile_report.py：ProfileReport 构造时会遍历 (explorative, "explorative") 和 (sensitive, "sensitive") 等配置组，凡条件为真的组即合并进最终配置。

显式禁用样本与重复行

如果不使用 sensitive 组，也可以显式关闭报告中的样本和重复行，保证报告不直接泄露数据：

report = df.profile_report(duplicates=None, samples=None)

对应地，Config._shorthands（见 config.py）将 samples 简写为 {"head": 0, "tail": 0, "random": 0}、将 duplicates 简写为 {"head": 0}，从而把这两块区域的展示数量归零。

用模拟/合成数据替换真实样本

另一种更灵活的做法是：仍然展示样本，但使用模拟或合成数据填充样本区，并在说明中声明数据来源：

import pandas as pd

# 用模拟/合成数据生成器产生的样本替换真实数据
sample_custom_data = pd.DataFrame()
sample_description = "Disclaimer: the following sample consists of synthetic data following the format of the underlying dataset."

report = df.profile_report(
    sample={
        "name": "Mock data sample",
        "data": sample_custom_data,
        "caption": sample_description,
    }
)

其中 name 和 caption 键为可选。仓库中的完整实战示例可参考 mask_sensitive.py：该示例读取汽车数据集 auto2.dta，仅抽样 25% 生成报告，并将样本替换为「游戏中的汽车」模拟数据，同时启用 sensitive=True、关闭 interactions，最终输出名为 masked_report.html 的脱敏报告。

redact 遮蔽机制的源码级原理

redact（遮蔽）是敏感模式的关键一环。在 describe_categorical_pandas.py 中，描述逻辑会读取 config.vars.cat.redact，当遮蔽开启时跳过原始类目值的统计展示；Spark 后端的 describe_categorical_spark.py 与 describe_text_spark.py 也有相同处理。

更底层的遮蔽实现在 summarizer.py 的 _redact_column 函数中：它会对列的汇总描述进行递归脱敏，遮蔽 first_rows（首行样本值）等字段的值，并从描述字典中剔除可能暴露原始数据的键。这样生成的报告仅保留统计聚合，而不会携带任何原始取值。

读取敏感数据时的类型陷阱：电话号码被强转数值

文档特别提醒一个隐蔽的泄露渠道：使用 pandas.read_csv 读取含电话号码等敏感数据时，pandas 的类型推断默认会把 0612345678 这类电话号强转为数值型，导致报告中的聚合统计（min、max、分位数）间接泄露敏感信息。防止方法是保持字符串表示：

pd.read_csv("filename.csv", dtype={"phone": str})

文档同时指出，类型检测本身是公认的难题——这也是 visions（一个帮助开发者处理类型系统的库）被开发出来的原因。若用户自定义列类型，data-profiling 还支持通过 type_schema 参数在生成报告时指定各列类型（见 profile_report.py 与 type_schema.py 示例）。

开源能力与企业级能力的定位总结

为了帮助你快速对号入座，以下梳理两者的分工：

能力	开源 data-profiling（本仓库）	YData Fabric Data Catalog
本地/云端	本地运行，数据不外发	云端托管、可交互、可扩展
PII 自动化识别	不内置 NER 模型	NER 深度学习 + 规则模式双通道
敏感数据保护	sensitive=True、关闭样本/重复、redact 遮蔽、mock 样本	自动分类 + 元数据管理 + 访问控制
适用场景	单机分析、报告导出、隐私约束场景	企业级数据治理、规模化合规、跨系统 PII 追踪

在企业环境中，二者可以协同：开源侧用 sensitive=True 和脱敏样本保证「分享报告不泄露数据」，而 Fabric Data Catalog 则承担「规模化自动发现并持续管理 PII」的治理职责。无论选择哪条路径，识别 PII 只是起点，持续的分类管理、合规追踪与策略执行才是数据隐私保护的完整闭环——这也是 YData 将 PII 识别与管理作为独立功能模块提供给企业用户的原因所在。

延伸阅读

• 敏感数据处理完整指南：docs/features/sensitive_data.md
• Data Catalog 协作式数据画像：docs/features/collaborative_data_profiling.md
• 脱敏报告完整可运行示例：examples/features/mask_sensitive.py
• 配置组（sensitive / explorative）实现：src/data_profiling/config.py
• sensitive 参数处理流程：src/data_profiling/profile_report.py
• redact 遮蔽实现：src/data_profiling/model/summarizer.py