以下是对《滴滴数据血缘建设实践》一文的详细总结，基于知乎专栏文章（发布于2025年8月21日）的内容整理而成：
📌 一、建设背景
随着滴滴数据体系的复杂化（涵盖Spark、Flink、ClickHouse等计算引擎，以及数据梦工厂、数易平台等工具），用户需清晰掌握数据从采集、加工到应用的全链路。核心需求包括：
- 数据溯源：追踪数据来源、加工过程及最终应用场景（如报表、BI工具）。
- 治理需求：精准识别下游依赖以支持成本治理、安全治理和链路优化。
- 演进目标：分阶段实现血缘能力从“能用”（基础查看）→“敢用”（高覆盖、高准确率）→“好用”（智能化工具支持）。
🛠 二、建设总览
血缘系统架构分为三层：
- 来源系统：覆盖数据梦工厂、数易平台、标签平台等核心产品。
- 处理层：
- 采集：引擎运行日志（Spark/Flink审计日志）、任务配置、API服务化配置、用户上报数据。
- 解析：通过SQL语法解析器、Spark逻辑计划解析器、文件路径解析器实现多场景覆盖。
- 存储：采用JanusGraph图数据库（基于HBase+ES）存储关系，并引入JGraphT内存图优化查询效率（如下游统计耗时从6小时降至6分钟）。
- 应用场景：支持数据地图、开发治理、安全审计等业务。
现状：字段血缘覆盖率达97%，核心链路20+，日均解析血缘结果千万级，服务调用量百万级。
⚙️ 三、设计与实践
1.血缘解析技术
- SQL语法解析器：通用性强，适用于CK/Presto等引擎，通过抽象语法树（AST）解析表/字段血缘。
- Spark逻辑计划解析器：
- 优势：精准获取运行时字段映射（如字段ID转换）、JOIN/GROUP BY分析。
- 挑战：解析效率低（需逐条处理），通过输出逻辑计划JSON至日志并批量解析优化。
- 文件路径解析器：覆盖无SQL场景（如DataFrame API），通过HDFS路径匹配Hive元数据。
2.血缘存储优化
- 图数据库选型：JanusGraph支持分布式扩展，但存在导入/查询性能瓶颈。
- 解决方案：
- 数据过滤精简导入内容。
- 三图维护（每日全量导入+原子替换）加速更新。
- JGraphT内存图缓存加速下游统计、血缘关系检测。
3.血缘实时化
- 问题：离线解析（T+1）导致新任务血缘延迟。
- 方案：与数据梦工厂联动，通过消息队列实时推送任务变更事件，动态更新内存图。
🚀 四、血缘应用场景
1.数据地图
- 图形化展示：上下游节点、层级、核心下游统计（如93天访问记录）。
- 关系检测：快速验证两节点间是否存在血缘路径。
- 变更通知：字段变更时自动通知下游负责人（邮件/内部消息）。
2.数据开发
- 权限管控：SQL执行前校验字段访问权限。
- 依赖分析：可视化任务输入/输出表，辅助调度配置。
3.治理场景
- 安全审计：敏感字段扩散检测（如跨业务线数据使用）。
- 层级治理：
- 最长路径计算：识别加工链路过长的表（如层级0表被层级3表依赖）。
- 扩散点治理：标记跨多业务线依赖的表（如table6），推动优化。
- 重复模型识别：通过上游字段相似度（>80%）提示存储冗余风险。
4.字段血缘应用
- 热度分析：基于SQL访问频率标记字段热度。
- 安全等级继承：下游字段自动继承上游最高等级（如C4→C4）。
- 精准通知：字段变更仅通知相关下游表。
🔮 五、未来规划
- 生态完善：补全CK/SR等存储的字段血缘，构建生产到使用的全链路血缘。
- 实时能力升级：扩展实时血缘覆盖范围（如非任务场景）。
- 智能化探索：结合大模型提升血缘分析能力，推动行级/算子级血缘产品化。
❓ 六、Q&A精选
- DDL变更处理：通过虚拟表暂存历史表结构，确保下游解析一致性。
- 历史分区血缘：采用生命周期管理，过期未使用的血缘关系自动失效。
- SQL解析准确率：以字段上游覆盖率（100%字段可追溯）为优化目标，依赖运行时逻辑计划提升精度。
思考
Q:多版本的数据模型，对血缘的影响如何分析？
A：多版本的数据模型与多版本的数据服务可通过，字段级别唯一的id进行血缘梳理，血缘的分析应该基于某个版本比如v1.1的血缘，与V1.2 进行字段增删改导致的影响分析。
总结：滴滴通过多源解析、图存储优化和实时化能力，构建了高覆盖（97%字段）、高可靠（99.99%准确率）的数据血缘系统，支撑数据治理、安全合规与开发效率提升，并计划向全链路实时化与智能化演进。
