1. 课程导入与全景认知
在数据平台规模较小时，表与表之间的关系往往靠人脑记忆和口头交接就能维持。但当数仓、湖仓、实时链路、BI 报表、特征平台同时存在，一张核心表可能被几十个下游任务引用，一次字段变更就可能引发连锁故障。此时，真正决定数据团队效率的，不再是“能不能算出数据”，而是“能不能说清楚数据从哪来、到哪去、谁在改、改了会影响谁”。这正是元数据血缘与 Data Catalog 要解决的核心问题。
一、三个概念：元数据、血缘、Data Catalog
元数据（Metadata）是描述数据的数据。在生产环境中，它通常分为三类：技术元数据（表结构、字段类型、分区键、存储格式、任务调度信息）、业务元数据（指标口径、业务定义、负责人、主题域）和操作元数据（任务运行状态、数据量、更新频率、血缘关系）。技术元数据回答“这张表长什么样”，业务元数据回答“这个字段代表什么业务含义”，操作元数据回答“它现在是否正常、被谁使用”。
元数据血缘（Data Lineage）描述数据在系统间的流转路径与依赖关系。它至少包含两个方向：上游血缘（这张表的数据来自哪些表、任务、文件或消息流）和下游血缘（这张表被哪些任务、报表、模型或接口消费）。血缘的粒度可以是表级、字段级，甚至行级。表级血缘用于影响面分析，字段级血缘用于精确的变更影响判断，行级血缘通常只在合规审计等特定场景使用。
Data Catalog（数据目录）是元数据的统一组织与检索入口。它不只是“元数据数据库”，而是把技术元数据、业务元数据、血缘关系、数据质量信息、权限信息、使用热度整合在一起，形成可搜索、可浏览、可协作的数据资产地图。可以这样理解：元数据是原料，血缘是关系网络，Data Catalog 是面向使用者的产品化界面。
二、边界：它做什么，不做什么
明确边界能避免项目范围失控。元数据血缘与 Data Catalog 的职责是采集、存储、关联、展示和检索元数据与血缘关系，它不负责实际的数据计算、不替代调度系统、不直接修改数据、也不承担数据质量规则的全部执行。它更像数据平台的“地图与导航系统”：告诉你有什么、在哪里、怎么连、变了会怎样，但不会替你开车。
一个常见的误区是把 Data Catalog 当成“文档库”。如果元数据靠人工填写、血缘靠手工维护，它很快就会过期，最终失去信任。生产级方案必须优先保证自动化采集和血缘自动解析，人工只补充业务语义和负责人等无法自动获取的信息。
三、核心价值与生产挑战
血缘与 Catalog 的价值可以归纳为四条主线：影响面分析（改字段前知道会波及哪些下游）、故障定位（报表异常时快速回溯上游链路）、资产发现与复用（避免重复建表、重复开发）、合规与治理（数据来源可追溯、敏感字段可审计）。
但在生产环境中，落地难点同样突出。第一是采集覆盖不全：离线 SQL 任务、实时 Flink 作业、Python 脚本、存储过程、外部接口各自为政，血缘断点多。第二是解析准确性：动态 SQL、临时表、UDF、多层嵌套视图会让静态解析出现漏边或错边。第三是规模与性能：当元数据达到百万级节点、千万级边时，血缘查询、影响面展开、图遍历会明显变慢，甚至拖垮存储。第四是时效性：任务每天新增和变更，血缘如果不能准实时更新，就会给出过时结论。第五是信任问题：一旦用户发现血缘不准，就会退回人工排查，系统形同虚设。
因此，本课程不会只讲“怎么建一张元数据表”，而会围绕采集链路、血缘解析、存储模型、查询性能、增量更新、质量校验和产品化逐步展开，最终目标是让你能设计并优化一套在生产规模下可用的血缘与 Catalog 系统。
四、课程学习路径与实战目标
本课程共 30 章，整体按“认知 → 采集 → 解析 → 存储 → 查询 → 优化 → 落地”推进。前几章建立概念与全景，随后进入元数据采集的工程实现，包括 JDBC 采集、日志解析、调度系统对接；再深入 SQL 血缘解析，覆盖 SELECT、JOIN、子查询、UNION、CTE 等常见结构，并讨论动态 SQL 的降级策略；之后进入存储模型设计，比较图数据库与关系型存储在血缘场景下的取舍；最后聚焦性能优化，包括深链查询剪枝、热点缓存、增量血缘更新、批量写入与索引设计。
实战目标有三个层次。第一层是能建：能独立完成一套最小可用的元数据采集与血缘解析链路，把 Hive 表、Spark 任务和调度信息接入 Catalog。第二层是能用：能实现表级与字段级血缘查询，支持“给定一张表，展开 N 层下游”和“给定一个字段，找出所有受影响报表”两类核心操作。第三层是能优化：在百万级节点规模下，把典型血缘查询从秒级降到百毫秒级，并保证血缘更新延迟在可接受范围内。
接下来，我们会从元数据的分类与采集对象开始，逐步拆开这条链路。你不需要一开始就追求大而全，但需要清楚每个环节的输入、输出、判断标准和常见坑点，这样才能在生产环境中真正把血缘与 Catalog 用起来。