质量维度、对账与生命周期管理 - 面试题

#

★★★

1. 级联删除（Cascade Delete）的设计？

问题

级联删除（Cascade Delete）如何设计？它有哪些风险与最佳实践？

考察点

级联删除的概念与外键约束
级联删除的风险（误删、性能、锁）
设计替代方案（软删除、归档）

答案

级联删除通过外键约束的 ON DELETE CASCADE 实现，删除父表记录时自动删除子表所有关联记录，保证引用完整性。它简化了删除逻辑，但风险显著：一是误删放大，一次删除可能波及大量下游数据且难以恢复；二是性能与锁，级联删除涉及多表扫描与大量行锁，容易造成锁竞争与长事务；三是隐藏的依赖，业务未必知道级联范围。设计上建议：对关键数据优先用"软删除"（逻辑删除标志位）而非物理删除；确需级联时先评估子表规模与依赖，做完整性校验、分批删除并加事务保护；对审计表、历史表避免级联（防止历史被误清）。PostgreSQL 中删除父表时若子表存在引用会报错，需明确级联行为。

解析

级联删除是"用数据库保证一致"的便捷手段，但风险集中在"不可控的破坏范围"；工程上倾向软删除+手动可控的物理清理，必要时用级联但配严格评审与备份。

示例代码

-- 外键级联删除
CREATE TABLE orders (
  id BIGSERIAL PRIMARY KEY,
  user_id BIGINT REFERENCES users(id) ON DELETE CASCADE
);

-- 软删除：使用逻辑删除标志，避免物理删除
ALTER TABLE orders ADD COLUMN deleted_at TIMESTAMPTZ;

#

★★★

2. MDM 的实现模式，注册表（Registry）、聚合（Consolidation）、集中（Centralized）？

问题

主数据管理（MDM）的实现模式有哪些？注册表、聚合、集中三种模式的区别是什么？

考察点

MDM 三种实现模式的定义
各模式的适用场景与优缺点
模式选择考虑因素

答案

MDM 有三种主流实现模式。集中式（Centralized）：把主数据集中存储在一个权威库中，各系统消费该库，数据一致性最强、治理最彻底，但改造成本高、源系统需统一接入。注册表（Registry）：保留各系统原有数据，只建立"主数据索引"映射（如通过全局 ID 关联各系统的客户记录），不复制主数据，落地快、侵入小，但查询需跨系统、一致性弱。聚合（Consolidation）：把各来源的主数据合并到中央库，供分析使用，但通常不写回源系统，适合分析型场景。选择取决于一致性需求、改造预算与查询频率：实时强一致选集中式，快速落地选注册表，分析场景选聚合。

解析

三种模式本质是"集中程度"与"侵入度"的权衡：集中式一致性最好但改造大，注册表灵活但一致性弱，聚合居中且偏向分析；模式可组合演进。

#

★★★

3. 数据对账（Data Reconciliation）的实现，账实核对？

问题

数据对账（Data Reconciliation）如何实现？如何做账实核对？

考察点

数据对账的概念与目的
对账的实现方式（总额、明细、抽样）
对账在资金与大数据场景的应用

答案

数据对账是核对两个系统/两条数据链路结果是否一致的机制，核心是"账实核对"。实现分几层：总额对账，比较两边的总金额、总笔数是否一致，成本低、能快速发现整体差异；明细对账，逐笔比对记录（按主键/唯一键 join），定位具体差异行；抽样对账，在大数据量下按比例抽样核验，兼顾成本与置信度。对账还常用"双写校验"（进入两个系统时比对）、"流水对账"（按时间窗比对增量）与"差异补偿"（对账后修正差异并幂等）。在支付场景，T+1 将业务流水与银行流水对账，核对金额、笔数、状态，确保资金安全；在大数据场景，对比源系统与数仓的计数、求和与去重。对账需定义差异阈值、告警与补偿流程。

解析

对账的本质是"建立可验证的一致性"，从总额到明细逐层收敛差异；关键在幂等补齐与差异定位，保证最终一致且可审计。

示例代码

-- 总额对账：比较两系统的总金额与笔数
SELECT
  (SELECT COUNT(*) FROM txn_system_a) AS cnt_a,
  (SELECT COUNT(*) FROM txn_system_b) AS cnt_b,
  (SELECT COALESCE(SUM(amount),0) FROM txn_system_a) AS sum_a,
  (SELECT COALESCE(SUM(amount),0) FROM txn_system_b) AS sum_b;

-- 明细对账：找出仅在 A 侧存在的记录
SELECT t.a_id FROM txn_system_a t
LEFT JOIN txn_system_b b ON b.txn_id = t.txn_id
WHERE b.txn_id IS NULL;

#

★★★

4. 数据质量监控，Deequ、Great Expectations？

问题

数据质量监控如何实现？Deequ 与 Great Expectations 分别是什么？

考察点

数据质量监控的核心维度
Deequ 与 Great Expectations 的特点
数据质量规则与告警

答案

数据质量监控通过持续运行质量规则发现数据问题。常见质量维度：完整性（非空率）、唯一性（重复率）、有效性（取值域/格式）、一致性（多字段/跨表逻辑）、准确性（与权威来源比对）、及时性（数据按时到达）。Deequ（亚马逊开源）是基于 Spark 的库，用"验证器"（Verifiers）定义质量约束（如 hasSize、isComplete、isUnique、isContainedIn），在 Spark 任务中批量计算质量指标并生成质量报告，适合大数据批处理。Great Expectations 是 Python 数据质量框架，用"Expectation"（如 expect_column_values_to_not_be_null）声明式定义抽查，支持数据源对接、生成文档与数据验证，适合数据管道与 Notebook 场景。两者都把质量规则"代码化、可测试、可版本化"，并接入告警（如失败即阻塞下游或发送通知）。

解析

数据质量监控的核心是"把质量规则变成可自动执行的断言"，Deequ 面向 Spark 批处理、Great Expectations 面向通用 Python 栈；规则应随数据契约管理并触发告警。

#

★★★

5. 数据保留策略（Retention Policy），合规要求、业务需求？

问题

数据保留策略（Retention Policy）如何设计？如何处理合规要求与业务需求的平衡？

考察点

数据保留策略的概念与目的
合规要求（法规、审计）与业务需求的驱动
保留下沉、归档与销毁的实现

答案

数据保留策略规定数据保存的时间与销毁方式，是合规与成本管理的核心。设计时需同时满足两类驱动：合规要求，如 GDPR/个保法规定部分数据可请求删除、审计要求保留交易流水 N 年、行业法规（金融 5 年、医疗 7 年）要求保留期限；业务需求，如数据分析、历史报表、风控回溯需要保留一定数据。策略落地上：按数据分级与类型设定保留期（如交易明细 7 年、日志 90 天、临时数据 30 天），到期后自动归档到冷存储或销毁；把保留期写入元数据与生命周期策略，由定时任务执行分区删除/归档。需注意保留期与删除权的冲突，以及"最小化原则"（只保留必要数据）。

解析

保留策略是"合规底线+业务上限+成本平衡"的产物，关键在于把保留期"配置化"并落地为自动执行的生命周期任务，避免数据无限堆积或违规提前删除。

#

★★★

6. 数据归档（Archival）的策略，冷热分离、分区表、外部存储？

问题

数据归档（Archival）的策略如何设计？冷热分离、分区表、外部存储如何配合？

考察点

数据归档的概念与目标
冷热分离、分区表、外部存储的实现
归档与查询的平衡

答案

数据归档是把低频访问的历史数据从热存储迁移到低成本存储，以控制成本、提升在线库性能。策略核心是冷热分离：近期高频数据留在热库（SSD/主库），久远数据归档到冷存储（对象存储、低成本存储）。实现手段：分区表是最常见的归档基础，按时间分区（如按月），归档时直接 drop/迁移过期分区，改造成本低、查询友好；外部存储（如 MySQL 的 ARCHIVE 引擎、PostgreSQL 的冷存储表、HDFS/S3）放置归档数据，配合元数据记录归档位置。查询时可通过"分区裁剪+冷热路由"（如查旧数据走归档库）兼顾。归档需保留约束与索引，并定义归档策略（何时、按什么条件、迁移到哪、如何恢复）。

解析

归档的本质是"按访问频率分层存储（Tiering）"，分区表让归档可批量、可裁剪，外部存储降低持有成本；设计要点是归档条件、恢复路径与查询路由的闭环。

示例代码

-- 按时间分区表，便于按分区归档
CREATE TABLE orders (
  id BIGINT,
  order_date DATE
) PARTITION BY RANGE (order_date);

-- 归档：DETACH 过期分区（先备份或迁移到归档表/存储）
ALTER TABLE orders DETACH PARTITION orders_2020;

#

★★

7. 数据销毁（Data Destruction），逻辑删除 vs 物理销毁？

问题

什么是数据销毁？逻辑删除与物理销毁有什么区别，如何选择？

考察点

逻辑删除与物理销毁的定义
两者在安全性与可恢复性上的差异
选择依据与合规要求

答案

数据销毁是让数据不可再访问的机制，合规（如 GDPR 删除权、数据最小化）要求某些数据到期必须销毁。逻辑删除：通过标记（如 deleted_at、is_deleted）软删除，数据仍物理存在，可恢复、可审计，但若未真正清除，敏感数据仍留在存储介质上，不完全满足"销毁"的合规定义。物理销毁：真正从存储介质清除数据，包括数据库行删除、文件覆盖、存储介质消磁/粉碎，满足"不可恢复"要求，但不可逆、成本高。选择上：业务可恢复且需审计的场景用逻辑删除；合规要求"彻底清除"的敏感数据（如 GDPR 删除权、换介质）用物理销毁。落地时逻辑删除数据需定期由后台任务真正清除（物理删除），并保证物理删除在备份、副本、日志中同步清除，避免残留。

解析

逻辑删除管"业务可见性"，物理销毁管"合规彻底性"，两者是"先软后硬"的关系；难点在于物理销毁要覆盖所有副本与备份，否则数据残留违背合规。

#

★★

8. GDPR 删除请求（Right to Erasure）的工程实现？

问题

GDPR 删除请求（Right to Erasure）的工程实现是什么？

考察点

GDPR 删除权的内涵
删除请求的工程实现（定位、级联、确认）
删除与日志、备份的边界

答案

GDPR 删除权（Right to Erasure）允许个人要求删除其个人数据。工程实现需打通全链路：定位数据，通过主键（如用户 ID）在各业务表、数仓、日志中定位该用户全部数据；删除数据，按业务删除不同类型数据（硬删除、假名化、匿名化），并处理级联（订单、收货地址等关联数据）与孤儿数据；确认删除，执行后向用户确认并留存删除记录。难点在于：删除要覆盖所有副本（缓存、CDC、备份、离线分析），备份中的个人数据常采用"超额保留期后删除"或"备份隔离+覆盖"策略；日志类数据难以逐条删除，常用权限隔离+最短保留期。删除需在 SLA 内完成（GDPR 通常 1 个月）。工程上常建"删除请求队列+工作流+可观测性"，保证删除可追溯、可验证。

解析

GDPR 删除权工程落地关键是"全链路定位+逐类删除+副本覆盖+确认回执"，本质是建立可审计的删除工作流；真正的难点在备份与日志中的残留。

#

★★

9. 删除请求的下游同步，CDC、消息队列、ETL？

问题

删除请求如何同步到下游？CDC、消息队列、ETL 在删除同步中的作用是什么？

考察点

删除请求传播到下游的机制
CDC 与消息队列、ETL 在删除同步中的作用
删除的一致性与幂等

答案

删除请求不仅要在源系统删除，还要传播到下游（数仓、搜索、缓存、Kafka），否则下游仍残留个人数据。三种机制：CDC（Change Data Capture，如 Debezium）捕获源库的删除操作（delete 事件），将删除传送到下游消费系统，实时且可追溯；消息队列（如 Kafka）作为删除事件的传输通道，通过 topic 分发删除事件，消费者收到后执行对应删除；ETL（批处理）在每日/定时任务中根据源库增量同步删除（如根据 deleted_at 或删除日志），适合延迟容忍的场景。设计上需保证删除事件的幂等（重复消费不产生副作用）、顺序（删除与新增的先后）与最终一致（下游最终也删除）。删除事件通常携带主键，下游按主键删除匹配数据。

解析

删除同步的本质是"删除事件的传播"，CDC 实时、消息队列负责传输、ETL 兜底批量；三者的核心是保证下游最终一致且幂等，避免个人数据残留。

#

★★

10. Apache Atlas 的数据血缘与分类？

问题

Apache Atlas 如何实现数据血缘与分类？

考察点

Atlas 的血缘采集与展示
Atlas 的分类（Tag）机制
Atlas 在 Hadoop 生态中的定位

答案

Apache Atlas 是 Apache 开源的数据治理框架，深度对接 Hadoop 生态（Hive、HBase、Kafka、Sqoop、Falcon 等）。血缘方面，Atlas 通过 Hook 自动采集各组件操作（如 Hive 的 DDL/ETL 查询）生成血缘关系，展示表/字段之间的上游与下游依赖，支持影响分析与溯源。分类方面，Atlas 提供基于 Tag 的资产分类机制，可给数据实体打标签（如"PII""敏感"），标签可随血缘传播，并可与 Ranger 集成实现基于标签的访问控制（Tag-based Policy）。Atlas 的核心是类型系统（Type System）与实体之间的关系（Relationship），也可支持自定义类型与元数据属性。它适合以 Hadoop 为核心的数据湖治理场景。

解析

Atlas 的定位是"Hadoop 生态的治理底座"，血缘靠 Hook 自动采集、分类靠 Tag 并联动 Ranger 权限，价值在于"治理与权限打通"。

#

★★

11. DataHub（LinkedIn）的元数据模型？

问题

DataHub（LinkedIn 开源）的元数据模型是怎样的？

考察点

DataHub 的架构与元数据模型
Aspect 与实体、版本化的机制
DataHub 的现代特性

答案

DataHub 是 LinkedIn 开源的现代化数据目录/元数据平台。其元数据模型以"实体（Entity）+ Aspect（属性片段）"为核心：一个实体（如 Dataset、Dashboard、Pipeline）由多个 Aspect 组成，每个 Aspect 是数据的一个可独立更新的属性块（如 schemaMetadata、ownership、tags、dataQuality）；Aspect 支持版本化，保留历史版本，支持时间旅行（查询某时刻的元数据）。写入采用 first-write-wins、后续 update 走 merge 的合并语义，保证并发更新的一致性。元数据通过 Kafka 异步流式摄取（Kappa 架构），存储于 Elasticsearch/MySQL。DataHub 支持血缘、术语（Glossary）、数据质量、Schema 版本、搜索与权限，并可通过自定义 Aspect 扩展。模型灵活，适合现代数据栈。

解析

DataHub 模型的精髓是"实体-Aspect 化+版本化"，让元数据可独立更新、可追溯、可扩展；流式摄取使其近实时。

#

★★

12. 元数据平台（Metadata Platform）的核心能力？

问题

元数据平台（Metadata Platform）的核心能力有哪些？

考察点

元数据平台的核心能力清单
各能力的价值
元数据平台与数据治理的关系

答案

元数据平台是集中管理数据资产元数据的系统，核心能力包括：元数据采集（自动接入数据库、数据湖、ETL、BI 等，抓取表结构、字段、分区、血缘）、血缘（展示数据来源与去向，支持影响分析与溯源）、数据目录（搜索、浏览、标签、收藏，帮助用户找到数据）、业务术语（Glossary 统一口径，沟通业务与技术）、数据质量（对接质量评分与规则）、数据分类与权限（标签、敏感度、访问控制）、数据契约与变更管理（Schema 版本、SLA）、以及审计与协作（评论、收藏、数据所有者）。这些能力共同支撑"找到、理解、信任、治理数据"的闭环。元数据平台是数据驱动组织的核心基础设施，与数据治理、数据质量、数据血缘深度协同。

解析

元数据平台核心是把"元数据全生命周期"集中管理，形成"采集→存储→检索→治理→协作"的闭环；能力越全，数据资产越可被高效使用与治理。

#

★★

13. 主数据匹配（Matching）与合并（Merging）算法？

问题

主数据匹配（Matching）与合并（Merging）算法如何实现？

考察点

主数据匹配的相似度算法
匹配的判定与阈值
合并的去重与冲突解决

答案

主数据匹配（Matching）用于判断两条记录是否指向同一实体（如同一客户），合并（Merging）用于把匹配的记录合并为一条权威记录。匹配算法：精确匹配（主键、身份证号等唯一键直接相等）、模糊匹配（姓名、电话、地址用编辑距离、Jaro-Winkler、Soundex、Jaccard 等相似度算法）、加权评分（多个字段加权打分，超过阈值判定为同一实体）、机器学习匹配（训练模型判断匹配概率）。匹配需先做标准化（清洗、归一化地址、统一姓名格式）再打分。合并处理：选定"黄金记录"（来自权威源或得分最高），合并各字段、保留冲突的解决策略（取最新、取权威源、人工裁决），并维护"合并记录"关系（survivorship）与历史。常用两阶段：blocking 减少候选对，再细粒度打分。

解析

匹配的核心是"相似度+阈值"，标准化是前提；合并的核心是"冲突解决+幸存记录"，并保存合并关系以保证可审计；常用 blocking 降低计算量。

#

★★

14. 主数据管理（MDM, Master Data Management）的核心概念？

问题

主数据管理（MDM）的核心概念是什么？

考察点

主数据与交易数据的区别
MDM 的目标与价值
MDM 的落地要素

答案

主数据（Master Data）是描述业务核心实体的、跨系统共享的基础数据，如客户、产品、供应商、组织、物料，区别于高频变化的交易数据。主数据管理（MDM）是治理主数据的策略、流程与技术的集合，目标是保证主数据在多个系统间一致、准确、唯一且权威。MDM 的核心概念包括：单一事实来源（Single Source of Truth，SSOT）、黄金记录（Golden Record，合并后的权威记录）、数据匹配与合并（去重）、数据所有权与认责（数据所有者管理）、数据生命周期（创建、变更、归档）。MDM 通过统一主数据模型、主数据服务中心与治理流程，解决"同一客户在不同系统信息不一致"、"多套数据口径"等痛点，是数据治理的基础。

解析

MDM 的本质是"为跨系统共享的实体数据建立权威治理"，解决一致性与去重问题；核心是黄金记录、SSOT、匹配合并与所有权。

#

★★

15. GDPR 的删除权与归档保留的冲突？

问题

GDPR 的删除权与归档保留之间存在什么冲突？如何解决？

考察点

删除权与归档保留的冲突本质
合规保留（legal hold）与删除权
冲突的解决方案

答案

冲突在于：GDPR 删除权要求个人数据可被删除，而归档保留（如审计、监管、法律保存）要求数据保留一定期限，两者对"同一份数据"提出了相反要求。解决思路：区分"数据用途"与"保留理由"。若保留是基于法定/监管义务（如审计、税务、诉讼），则不适用删除权，可保留至法定期限，但需向用户说明保留理由；若保留只是一般业务需求，则需满足删除权。工程上：对归档数据做"最小化"处理（仅保留必要字段）、对个人标识做匿名化/假名化（抹去可直接识别个人的信息，使删除权不再适用）、设定"保留期限+删除执行"（到期后自动匿名或删除）、对法律诉讼保留做"legal hold"（冻结删除但记录原因）。核心是建立"保留理由登记"，让删除权与保留义务可审计地共存。

解析

冲突的解法是"以保留理由为判据"：凡有法定义务的保留可豁免删除权，否则必须删除；匿名化/最小化是化解冲突的关键手段。

#

★

16. OpenMetadata 的开放标准？

问题

OpenMetadata 的开放标准是什么？它如何实现开放与互操作？

考察点

OpenMetadata 的开放标准理念
开放 API 与 Schema
与开源生态的集成

答案

OpenMetadata 是开源的数据治理平台，强调"开放标准"：其元数据模型、API 与接口全部开放，采用 JSON Schema 定义元数据实体，提供 REST API 与 SDK 供第三方接入，支持与主流数据源（数据库、数据湖、Kafka、BI、数据管道）通过连接器自动采集元数据。开放标准意味着：元数据可被任何工具读取与写入、可扩展自定义实体与属性、可与其他系统（如 Airflow、dbt、Tableau）互操作。OpenMetadata 还内置了数据血缘、术语、质量、数据画像与协作能力，并遵循"开放采集（Ingestion）+开放 API"，让治理栈不绑定厂商。它支持 Agent 连接器架构，便于社区贡献新连接器。

解析

OpenMetadata 的"开放标准"体现在 JSON Schema 化的元数据模型、开放的 REST API 与 SDK、以及可扩展的连接器生态，核心是"元数据可移植、可互操作、可扩展"。

#

★

17. 主数据管理（MDM）与数据治理的协同，主数据标准如何落地为数据质量规则，治理流程如何支撑 MDM 的认责与变更？

问题

主数据管理（MDM）与数据治理如何协同？主数据标准如何落地为数据质量规则，治理流程如何支撑 MDM 的认责与变更？

考察点

MDM 与数据治理的关系
主数据标准落地为质量规则
治理流程支撑认责与变更

答案

MDM 与数据治理强协同：MDM 是主数据领域的治理落地，数据治理提供制度、流程与工具的支撑。协同体现在三方面：一是主数据标准落地为数据质量规则——把主数据的定义（如客户编码规范、性别枚举、地址格式、唯一性要求）转化为可执行的质量校验规则（如非空、唯一、取值域、格式），在主数据接入与维护时自动校验，保证主数据质量。二是治理流程支撑认责——通过数据治理明确每个主数据域的数据所有者（Owner）、数据管家（Steward）与职责，MDM 的创建、修改、合并都需认责与审批。三是治理流程支撑变更——主数据变更（如字段调整、合并冲突裁决）走治理化的变更管理（评审、审批、影响分析、通知下游），保证主数据变更可控。治理把 MDM 从"技术工具"提升为"制度+流程+技术"的体系。

解析

MDM 与治理协同的本质是"标准→规则→流程→工具"的贯通：主数据标准落地为质量规则，治理流程支撑认责与变更，让 MDM 有制度保障。