为什么需要 Data Lineage Tracking?
上周四,某金融公司的风控 agent 突然开始拒绝大量正常的贷款申请。排查后发现,agent 使用的信用评分模型输入了一个错误的数据源——本该使用"过去 12 个月的还款记录",却误用了"过去 12 个月的查询记录"。更糟糕的是,这个错误已经存在了 3 周,影响了 2,400 多个客户的贷款审批。
问题是:如何快速找到受影响的客户?如何确定错误的起始时间?如何验证修复后的模型不再使用错误的数据源?
如果没有 Data Lineage Tracking(数据血缘追踪),这些问题几乎无法回答。你需要手动检查:
- 模型的代码,找出它读取了哪些数据表。
- 数据表的 ETL Pipeline,找出数据来源。
- 历史部署记录,找出什么时候引入了这个 bug。
- 过去的决策日志,找出哪些客户受到了影响。
这个过程可能需要几天甚至几周时间。而有了完整的数据血缘系统,你可以在几分钟内重建完整的数据流转路径,精准定位问题并评估影响范围。
为什么需要 Data Lineage?
1. 问题排查(Troubleshooting)
当 agent 输出错误结果时,data lineage 可以帮助:
- 溯源:找出错误数据的来源(是哪个数据表、哪个 API、哪个用户输入)。
- 定位:确定错误引入的时间点(是哪次代码变更、哪次数据迁移、哪次配置更新)。
- 影响分析:找出所有使用了错误数据的下游系统、模型和决策。
2. 影响分析(Impact Analysis)
当需要修改数据源或数据处理逻辑时,data lineage 可以帮助:
- 依赖分析:找出所有依赖该数据源的下游系统。
- 风险评估:评估修改可能带来的风险和影响范围。
- 回归测试:确定需要进行回归测试的系统列表。
3. 合规审计(Compliance Audit)
许多法规要求追踪数据的完整流转路径:
- GDPR Article 30:记录个人数据的处理活动,包括数据来源、处理目的、数据接收者。
- HIPAA §164.312(b):记录对患者健康信息的所有访问和处理。
- BCBS 239(银行业):要求银行能够追踪风险数据的完整血缘。
- SOX(上市公司):要求追踪财务数据的来源和处理过程。
没有完整的数据血缘,无法满足这些合规要求。
记录模型设计
核心概念
Data Lineage 通常使用图(Graph)模型来表示:
- Node(节点):代表数据实体(如数据库表、API、文件、模型、agent)。
- Edge(边):代表数据流动关系(如 "reads from"、"writes to"、"transforms into")。
- Attribute(属性):节点的元数据(如 schema、owner、classification)。
- Timestamp(时间戳):记录数据流动的时间。
Node 类型定义
enum NodeType {
DATABASE_TABLE = "database_table",
API_ENDPOINT = "api_endpoint",
FILE = "file",
MODEL = "model",
AGENT = "agent",
USER_INPUT = "user_input",
EXTERNAL_SERVICE = "external_service",
CACHE = "cache",
QUEUE = "queue",
}
interface DataNode {
node_id: string; // 唯一标识(UUID)
node_type: NodeType;
name: string; // 节点名称(如 "users table"、"OpenAI API")
qualified_name: string; // 限定名称(如 "prod_db.public.users")
// 元数据
owner?: string; // 责任人
description?: string; // 描述
schema?: Record<string, any>; // 数据结构(如列名、类型)
classification?: "public" | "internal" | "confidential" | "pii";
// 技术信息
location?: string; // 物理位置(如 S3 bucket path、database connection string)
format?: string; // 数据格式(如 JSON、CSV、Parquet)
// 时间信息
created_at: string;
updated_at: string;
// 自定义元数据
metadata?: Record<string, any>;
}
Edge 类型定义
enum EdgeType {
READS_FROM = "reads_from",
WRITES_TO = "writes_to",
TRANSFORMS_INTO = "transforms_into",
DERIVED_FROM = "derived_from",
DEPENDS_ON = "depends_on",
TRIGGERS = "triggers",
}
interface DataEdge {
edge_id: string; // 唯一标识(UUID)
source_node_id: string; // 源节点 ID
target_node_id: string; // 目标节点 ID
edge_type: EdgeType;
// 流动详情
columns?: string[]; // 涉及的列(如 ["user_id", "email"])
transformation?: string; // 转换逻辑描述(如 "JOIN users ON user_id")
filter_condition?: string; // 过滤条件(如 "WHERE status = 'active'")
// 执行信息
executed_at: string; // 执行时间
duration_ms?: number; // 执行耗时
rows_affected?: number; // 影响的行数
// 关联信息
job_id?: string; // 关联的 ETL job ID
request_id?: string; // 关联的请求 ID
session_id?: string; // 关联的会话 ID
// 自定义元数据
metadata?: Record<string, any>;
}
示例:Agent 决策的数据血缘
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ User Input │────▶│ Agent │────▶│ OpenAI API │
│ (query) │ │ (orchestrator)│ │ (GPT-4) │
└──────────────┘ └──────────────┘ └──────────────┘
│ │
│ ▼
│ ┌──────────────┐
│ │ Embedding │
│ │ Model │
│ └──────────────┘
│ │
▼ ▼
┌──────────────┐ ┌──────────────┐
│ Vector DB │◀────│ Query │
│ (retrieval) │ │ Results │
└──────────────┘ └──────────────┘
│
▼
┌──────────────┐
│ Final │
│ Response │
└──────────────┘
对应的血缘记录:
{
"nodes": [
{
"node_id": "node_user_input_001",
"node_type": "user_input",
"name": "Customer Query",
"qualified_name": "session:sess_abc123:user_input",
"classification": "pii",
"schema": {
"query": "string",
"user_id": "string",
"timestamp": "datetime"
}
},
{
"node_id": "node_agent_001",
"node_type": "agent",
"name": "Customer Support Agent",
"qualified_name": "agent:customer-support-bot:v2.3.1",
"owner": "team:ai-platform"
},
{
"node_id": "node_openai_001",
"node_type": "api_endpoint",
"name": "OpenAI Chat Completions",
"qualified_name": "api:openai.com/v1/chat/completions",
"location": "https://api.openai.com/v1/chat/completions"
},
{
"node_id": "node_vector_db_001",
"node_type": "database_table",
"name": "Knowledge Base Embeddings",
"qualified_name": "prod_db.public.kb_embeddings",
"classification": "internal",
"schema": {
"document_id": "uuid",
"embedding": "vector(1536)",
"metadata": "jsonb"
}
},
{
"node_id": "node_response_001",
"node_type": "file",
"name": "Agent Response",
"qualified_name": "session:sess_abc123:response",
"format": "json"
}
],
"edges": [
{
"edge_id": "edge_001",
"source_node_id": "node_user_input_001",
"target_node_id": "node_agent_001",
"edge_type": "reads_from",
"executed_at": "2026-06-15T14:23:45Z",
"request_id": "req_xyz789"
},
{
"edge_id": "edge_002",
"source_node_id": "node_agent_001",
"target_node_id": "node_openai_001",
"edge_type": "triggers",
"executed_at": "2026-06-15T14:23:46Z",
"duration_ms": 1234,
"request_id": "req_xyz789"
},
{
"edge_id": "edge_003",
"source_node_id": "node_agent_001",
"target_node_id": "node_vector_db_001",
"edge_type": "reads_from",
"columns": ["document_id", "embedding", "metadata"],
"filter_condition": "WHERE metadata->>'category' = 'support'",
"executed_at": "2026-06-15T14:23:45Z",
"rows_affected": 5,
"request_id": "req_xyz789"
},
{
"edge_id": "edge_004",
"source_node_id": "node_openai_001",
"target_node_id": "node_response_001",
"edge_type": "writes_to",
"executed_at": "2026-06-15T14:23:47Z",
"request_id": "req_xyz789"
}
]
}
存储方案选型
方案一:Graph Database(图数据库)
推荐:Neo4j、Amazon Neptune、Azure Cosmos DB(Gremlin API)
优势:
- 原生支持图查询:轻松遍历上下游节点,查询性能高。
- 灵活的模式:可以轻松添加新的节点类型和边类型。
- 可视化友好:大多数图数据库都提供内置的可视化工具。
劣势:
- 学习曲线:需要学习图查询语言(如 Cypher、Gremlin)。
- 运维复杂:图数据库的集群管理和备份恢复相对复杂。
查询示例(Cypher):
// 查询某个节点的所有上游依赖(向上追溯 3 层)
MATCH (target:DataNode {node_id: "node_response_001"})<-[:READS_FROM|DERIVED_FROM*1..3]-(source:DataNode)
RETURN source.node_id, source.name, source.node_type
ORDER BY source.created_at DESC;
// 查询某个数据表被哪些下游系统使用
MATCH (table:DataNode {qualified_name: "prod_db.public.users"})-[:READS_FROM]->(downstream:DataNode)
RETURN downstream.node_id, downstream.name, downstream.node_type;
// 查询包含 PII 数据的完整流转路径
MATCH path = (source:DataNode {classification: "pii"})-[*1..5]->(target:DataNode)
RETURN path
LIMIT 10;
方案二:Relational Database(关系数据库)
推荐:PostgreSQL、MySQL
优势:
- 熟悉度高:团队通常已经熟悉 SQL,学习成本低。
- 生态丰富:有丰富的 ORM、迁移工具、监控工具。
- 成本低:开源数据库免费,云服务价格也相对较低。
劣势:
- 递归查询性能差:需要使用递归 CTE 查询血缘关系,性能不如图数据库。
- 模式僵化:添加新的节点类型或边类型需要修改 schema。
查询示例(SQL with Recursive CTE):
-- 查询某个节点的所有上游依赖(向上追溯 3 层)
WITH RECURSIVE upstream AS (
-- 基础情况:直接上游
SELECT
e.source_node_id,
n.node_id,
n.name,
n.node_type,
1 AS depth
FROM data_edges e
JOIN data_nodes n ON e.source_node_id = n.node_id
WHERE e.target_node_id = 'node_response_001'
AND e.edge_type IN ('reads_from', 'derived_from')
UNION ALL
-- 递归情况:继续向上追溯
SELECT
e2.source_node_id,
n2.node_id,
n2.name,
n2.node_type,
u.depth + 1
FROM upstream u
JOIN data_edges e2 ON u.source_node_id = e2.target_node_id
JOIN data_nodes n2 ON e2.source_node_id = n2.node_id
WHERE u.depth < 3
AND e2.edge_type IN ('reads_from', 'derived_from')
)
SELECT DISTINCT node_id, name, node_type, depth
FROM upstream
ORDER BY depth ASC;
方案三:Lineage-specific Store(专用血缘存储)
推荐:Apache Atlas、DataHub、Amundsen
优势:
- 开箱即用:专门用于数据血缘管理,提供完整的 UI 和 API。
- 集成丰富:预置了与 Hive、Spark、Airflow、dbt 等工具的集成。
- 元数据管理:除了血缘,还提供数据目录、数据质量、数据治理等功能。
劣势:
- 重量级:需要部署和维护复杂的系统。
- 定制困难:如果需要特殊的血缘模型,定制成本高。
适用场景:大型企业,已有成熟的数据平台团队,需要统一的数据治理解决方案。
采集机制
方式一:Instrumentation(代码埋点)
在应用程序代码中显式记录数据血缘。
示例:
import { DataLineageTracker } from "@company/data-lineage-sdk";
const tracker = new DataLineageTracker({
apiEndpoint: "https://lineage-api.example.com",
apiKey: process.env.LINEAGE_API_KEY,
});
async function processUserQuery(userId: string, query: string): Promise<string> {
const sessionId = generateSessionId();
// 记录用户输入节点
await tracker.recordNode({
node_id: `user_input:${sessionId}`,
node_type: "user_input",
name: "User Query",
qualified_name: `session:${sessionId}:user_input`,
classification: "pii",
metadata: { user_id: userId },
});
// 记录从向量数据库读取数据
const embeddings = await vectorDB.search(query);
await tracker.recordEdge({
source_node_id: "node_vector_db_001",
target_node_id: `agent_run:${sessionId}`,
edge_type: "reads_from",
columns: ["document_id", "embedding", "metadata"],
rows_affected: embeddings.length,
metadata: { session_id: sessionId },
});
// 记录调用 OpenAI API
const response = await openai.chat.completions.create({
model: "gpt-4",
messages: [{ role: "user", content: query }],
});
await tracker.recordEdge({
source_node_id: `agent_run:${sessionId}`,
target_node_id: "node_openai_001",
edge_type: "triggers",
duration_ms: response.usage.total_tokens * 10, // 估算耗时
metadata: {
session_id: sessionId,
tokens_used: response.usage.total_tokens,
},
});
// 记录最终响应
await tracker.recordNode({
node_id: `response:${sessionId}`,
node_type: "file",
name: "Agent Response",
qualified_name: `session:${sessionId}:response`,
metadata: { session_id: sessionId },
});
await tracker.recordEdge({
source_node_id: "node_openai_001",
target_node_id: `response:${sessionId}`,
edge_type: "writes_to",
metadata: { session_id: sessionId },
});
return response.choices[0].message.content;
}
优点:
- 精确:可以记录详细的上下文信息(如查询参数、返回结果、耗时)。
- 灵活:可以根据业务需求自定义记录逻辑。
缺点:
- 侵入性强:需要修改应用程序代码。
- 维护成本高:每次代码变更都需要同步更新血缘记录逻辑。
方式二:Proxy(代理拦截)
在数据访问层部署 Proxy,自动拦截并记录所有数据操作。
示例架构:
┌─────────────┐ ┌──────────────┐ ┌─────────────┐
│ AI Agents │────▶│ Data Proxy │────▶│ Database / │
│ │ │ (Records │ │ API │
└─────────────┘ │ Lineage) │ └─────────────┘
└──────────────┘
│
▼
┌──────────────┐
│ Lineage │
│ Storage │
└──────────────┘
实现方式:
- Database Proxy:使用 ProxySQL、PgBouncer 等数据库代理,记录所有 SQL 查询。
- API Gateway:使用 Kong、Apigee 等 API Gateway,记录所有 API 调用。
- Service Mesh:使用 Istio、Linkerd 等服务网格,记录微服务间的通信。
优点:
- 无侵入:无需修改应用程序代码。
- 全面:可以捕获所有数据操作,不会遗漏。
缺点:
- 性能开销:Proxy 会增加延迟,需要优化。
- 上下文缺失:Proxy 只能看到网络层面的信息,缺少业务上下文(如用户 ID、会话 ID)。
方式三:Sidecar(边车容器)
在 Kubernetes 环境中,为每个 Pod 部署一个 Sidecar 容器,负责记录血缘。
示例配置:
apiVersion: apps/v1
kind: Deployment
metadata:
name: customer-support-agent
spec:
template:
spec:
containers:
- name: agent
image: my-agent:latest
- name: lineage-sidecar
image: company/lineage-sidecar:latest
env:
- name: LINEAGE_API_ENDPOINT
value: "https://lineage-api.example.com"
- name: LINEAGE_API_KEY
valueFrom:
secretKeyRef:
name: lineage-secret
key: api-key
volumeMounts:
- name: shared-volume
mountPath: /var/run/lineage
volumes:
- name: shared-volume
emptyDir: {}
工作原理:
- Agent 将血缘事件写入共享卷(如
/var/run/lineage/events.jsonl)。 - Sidecar 监听共享卷,读取新事件并发送到 Lineage API。
- Sidecar 负责重试、缓冲、批量发送等可靠性保障。
优点:
- 解耦:Agent 只需写入文件,无需关心网络通信。
- 可靠:Sidecar 可以处理重试、缓冲、离线缓存等。
缺点:
- 资源占用:每个 Pod 都需要额外的 Sidecar 容器。
- 复杂性:需要管理共享卷的生命周期和清理。
查询与分析
上下游追溯
向上追溯(Upstream):找出数据的来源。
async function getUpstreamLineage(nodeId: string, maxDepth: number = 5): Promise<DataNode[]> {
const query = `
MATCH path = (target:DataNode {node_id: $nodeId})<-[:READS_FROM|DERIVED_FROM*1..${maxDepth}]-(source:DataNode)
RETURN DISTINCT source
ORDER BY source.created_at DESC
`;
const result = await graphDb.run(query, { nodeId });
return result.records.map(record => record.get("source").properties);
}
// 使用
const upstreamNodes = await getUpstreamLineage("node_response_001", 3);
console.log("Upstream nodes:", upstreamNodes.map(n => n.name));
// Output: ["Customer Query", "Vector DB", "OpenAI API", ...]
向下追溯(Downstream):找出数据的使用者。
async function getDownstreamLineage(nodeId: string, maxDepth: number = 5): Promise<DataNode[]> {
const query = `
MATCH path = (source:DataNode {node_id: $nodeId})-[:READS_FROM|WRITES_TO*1..${maxDepth}]->(target:DataNode)
RETURN DISTINCT target
ORDER BY target.created_at DESC
`;
const result = await graphDb.run(query, { nodeId });
return result.records.map(record => record.get("target").properties);
}
// 使用
const downstreamNodes = await getDownstreamLineage("prod_db.public.users", 3);
console.log("Downstream nodes:", downstreamNodes.map(n => n.name));
// Output: ["Customer Support Agent", "Analytics Dashboard", "ML Model", ...]
影响范围分析
当需要修改某个数据源时,评估影响范围:
async function assessImpact(nodeId: string): Promise<ImpactAnalysis> {
// 获取所有下游节点
const downstreamNodes = await getDownstreamLineage(nodeId, 10);
// 分类统计
const impactByType: Record<string, number> = {};
for (const node of downstreamNodes) {
impactByType[node.node_type] = (impactByType[node.node_type] || 0) + 1;
}
// 识别关键系统(生产环境的 agent、对外 API 等)
const criticalSystems = downstreamNodes.filter(node =>
node.metadata?.environment === "production" &&
(node.node_type === "agent" || node.node_type === "api_endpoint")
);
// 估算受影响的用户数
const affectedUsers = await estimateAffectedUsers(downstreamNodes);
return {
total_downstream_nodes: downstreamNodes.length,
impact_by_type: impactByType,
critical_systems: criticalSystems.map(n => ({
node_id: n.node_id,
name: n.name,
owner: n.owner,
})),
estimated_affected_users: affectedUsers,
recommended_actions: [
`Notify owners of ${criticalSystems.length} critical systems`,
`Schedule regression testing for affected agents and models`,
`Prepare rollback plan in case of issues`,
],
};
}
// 使用
const impact = await assessImpact("prod_db.public.users");
console.log("Impact analysis:", impact);
血缘可视化
使用 D3.js、Cytoscape.js 或 Graphviz 构建交互式血缘图:
import cytoscape from "cytoscape";
async function renderLineageGraph(nodeId: string) {
// 获取血缘数据
const upstream = await getUpstreamLineage(nodeId, 3);
const downstream = await getDownstreamLineage(nodeId, 3);
const edges = await getEdgesBetweenNodes([nodeId, ...upstream.map(n => n.node_id), ...downstream.map(n => n.node_id)]);
// 构建 Cytoscape 元素
const elements = [
...upstream.map(node => ({
data: { id: node.node_id, label: node.name, type: node.node_type },
classes: "upstream",
})),
{
data: { id: nodeId, label: "Current Node", type: "current" },
classes: "current",
},
...downstream.map(node => ({
data: { id: node.node_id, label: node.name, type: node.node_type },
classes: "downstream",
})),
...edges.map(edge => ({
data: {
source: edge.source_node_id,
target: edge.target_node_id,
label: edge.edge_type,
},
})),
];
// 渲染图形
const cy = cytoscape({
container: document.getElementById("lineage-graph"),
elements: elements,
style: [
{
selector: ".upstream",
style: {
"background-color": "#3498db",
"label": "data(label)",
},
},
{
selector: ".current",
style: {
"background-color": "#e74c3c",
"label": "data(label)",
"width": 40,
"height": 40,
},
},
{
selector: ".downstream",
style: {
"background-color": "#2ecc71",
"label": "data(label)",
},
},
{
selector: "edge",
style: {
"width": 2,
"line-color": "#95a5a6",
"target-arrow-color": "#95a5a6",
"target-arrow-shape": "triangle",
"label": "data(label)",
"font-size": 10,
},
},
],
layout: {
name: "dagre",
rankDir: "LR",
},
});
// 添加交互
cy.on("tap", "node", (evt) => {
const node = evt.target;
showNodeDetails(node.data("id"));
});
}
实战案例
案例一:数据污染溯源
问题:Agent 输出的建议中包含过时的产品信息,导致客户投诉。
排查步骤:
- 定位问题节点:找到生成错误响应的 agent 运行实例(
node_response_001)。 - 向上追溯:查询该响应的上游数据源,发现使用了
prod_db.public.products表。 - 检查数据 freshness:发现该表的最后更新时间是 30 天前,而产品价格昨天已更新。
- 找出根因:ETL Pipeline 失败,导致产品表未同步最新数据。
- 影响评估:查询过去 30 天所有使用了该产品表的 agent 运行,发现有 1,200 个响应可能包含过时信息。
- 修复:重启 ETL Pipeline,重新训练受影响的产品推荐模型。
- 预防:增加数据 freshness 监控,当数据超过 24 小时未更新时自动告警。
案例二:GDPR 删除验证
问题:用户行使"被遗忘权",要求删除所有个人数据。需要验证删除是否彻底。
验证步骤:
- 识别 PII 节点:找到所有包含该用户 PII 的数据节点(如
users表、orders表、logs表)。 - 向下追溯:查询这些 PII 节点的所有下游使用者,找出可能复制了 PII 的系统。
- 验证删除:在每个下游系统中检查该用户的 PII 是否已被删除或匿名化。
- 生成报告:生成 GDPR 删除验证报告,列出所有检查过的系统和验证结果。
- 审计日志:将验证过程和结果记录到审计日志中,作为合规证据。
案例三:模型调试
问题:新部署的推荐模型准确率下降 15%。
调试步骤:
- 对比血缘:对比新旧模型的血缘图,发现新模型多了一个上游数据源
prod_db.public.user_behavior_v2。 - 检查数据质量:发现
user_behavior_v2表中 30% 的记录缺少关键字段session_duration。 - 回溯变更:查询该表的变更记录,发现上周进行了 schema 迁移,但未迁移历史数据。
- 修复:回填历史数据的
session_duration字段,或修改模型以处理缺失值。 - 验证:重新训练模型,验证准确率恢复到正常水平。
- 预防:在 ETL Pipeline 中增加数据质量检查,当缺失率超过阈值时阻止数据流入。
FAQ
Q1: Data Lineage 和普通日志有什么区别?
A:
- 粒度不同:日志记录事件(如 "API called"),血缘记录数据实体之间的关系(如 "Table A feeds into Model B")。
- 目的不同:日志用于调试和监控,血缘用于追溯数据来源和影响分析。
- 结构不同:日志是线性的时间序列,血缘是图结构(节点和边)。
- 保留期限不同:日志通常保留 30-90 天,血缘需要长期保留(至少 1-7 年)。
Q2: 如何记录中间产物的血缘关系?
A:
- 为每个中间产物创建节点:如缓存、临时表、模型中间层。
- 记录转换逻辑:在边上记录 transformation 字段,说明数据如何从一个节点转换到另一个节点。
- 关联请求 ID:使用
request_id或session_id关联同一流程中的所有节点和边。 - 版本控制:为模型、代码等节点添加版本号,便于追溯历史变更。
Q3: 血缘数据量太大会影响性能吗?
A: 会的。优化建议:
- 采样策略:对于高频操作(如每秒数千次的 API 调用),可以采样记录血缘(如每 100 次记录 1 次)。
- 聚合存储:将细粒度的血缘聚合成粗粒度(如按小时聚合,而不是每条请求都记录)。
- 分层存储:热数据(最近 7 天)存储在图数据库中,冷数据(7 天前)归档到对象存储。
- 索引优化:在常用查询字段(如
node_type、classification、owner)上建立索引。
Q4: 如何实现跨系统的血缘追踪?
A:
- 统一标识符:使用全局唯一的
node_id(如 UUID),确保跨系统的节点可以正确关联。 - 标准化协议:定义统一的血缘数据模型和 API,各系统遵循同一标准。
- 分布式追踪:使用 OpenTelemetry、Jaeger 等分布式追踪系统,跨系统传递
trace_id。 - 中央存储:将所有系统的血缘数据集中存储在一个中央图库中。
Q5: 如何验证血缘数据的准确性?
A:
- 自动化测试:定期运行血缘验证脚本,检查是否有断裂的血缘链、孤立的节点。
- 人工抽检:随机抽取一些血缘记录,人工验证其准确性。
- 对比实际数据流:将血缘图与实际的数据流进行对比,发现不一致的地方。
- 用户反馈:允许数据工程师和分析师报告错误的血缘关系。
- 版本控制:对血缘数据进行版本控制,便于回溯和审计。
Q6: GDPR 删除请求如何通过血缘追踪?
A:
- 识别 PII 节点:找到所有包含该用户 PII 的节点。
- 向下追溯:找出所有使用了这些 PII 的下游节点。
- 执行删除:在每个节点上执行删除或匿名化操作。
- 验证删除:再次查询血缘图,确认所有 PII 已被删除。
- 记录证据:将删除过程和验证结果记录到审计日志中。
注意:某些系统可能无法完全删除数据(如备份、审计日志),需要在隐私政策中说明,并获得用户的同意。
Q7: 如何选择 Graph DB 方案?
A: 考虑以下因素:
- 规模:预计的节点数和边数,是否需要水平扩展。
- 查询性能:递归查询的性能要求。
- 易用性:查询语言的学习曲线、可视化工具的支持。
- 成本:许可证费用、运维成本、云服务费


