第一章：元数据管道概述

大家好，我是你们这门课的老师。

正式开始之前，我想先聊聊一个挺有意思的问题：什么是元数据？

说白了，元数据就是“描述数据的数据”。听起来有点绕，对吧？我举个例子。你手机里有张照片，照片本身是数据。但照片的拍摄时间、地点、相机型号、分辨率、甚至是谁拍的——这些信息，就是元数据。它不直接是画面内容，但告诉你关于画面的“故事”。

在企业的数据仓库里，这种“故事”更复杂。customer_id 这个字段，它的数据类型是什么？从哪里来的？经过了哪些清洗规则？更新频率是多久？谁有权访问？……所有这些信息，都是元数据。

当年我在一家电商公司做数据平台时，就吃过亏。业务那边跑出一个报表，发现销售额突然暴涨300%。大家兴奋了半天，以为是爆款。结果一查，是某个上游数据管道出了问题，把一个订单重复计算了100次。那次的元数据管理一塌糊涂——根本没人知道那个字段的计算逻辑到底是什么。从那以后，我就发誓一定要把元数据管道这件事搞明白。

为什么需要元数据管道？

你想想看，如果你的数据只有几百条，手动管理元数据可能还行。但一旦数据增长到TB级别，涉及上百个数据源、几十套系统、几千个字段，没有自动化的元数据管道，团队就会陷入混乱。

元数据管道的作用，就是自动化地采集、清洗、存储、分发和展示元数据。它就像数据世界的“交通指挥中心”，让每个人都知道数据从哪里来、到哪里去、长什么样子。

元数据管道的核心构成

一个标准的元数据管道，一般包含这几个环节：

  • 采集器：从数据库、ETL工具、BI平台、消息队列等源头拉取元数据。
  • 解析器：把不同格式（JSON、XML、SQL DDL、YAML等）的元数据，转换成统一的内部模型。
  • 适配器：处理不同数据源之间的协议差异，比如Hive和MySQL的表结构表示方式完全不同。
  • 存储层：一般用图数据库（Neo4j）或文档数据库（MongoDB）来存储元数据之间的血缘关系。
  • API 网关：对外提供查询接口，供数据目录、数据治理平台调用。

我在项目中见过太多人，一上来就写代码采集元数据，结果写出来的东西只能跑通一种数据源。换个引擎，全废了。所以，设计管道时一定要考虑可扩展性。我会在后面的章节详细讲怎么用Python的抽象基类来实现它。

前置知识要求

别担心，这门课不需要你是什么专家。但有些基础总是好的：

领域 具体要求
Python基础 会写类、函数、异常处理。能用列表推导式和字典操作。
数据库基础 了解SQL，知道表、字段、索引的概念。会连MySQL或PostgreSQL。
命令行基础 能用cd、ls、pip install这些命令。
数据结构常识 稍微了解图（Graph）的概念。不深，懂节点和边就行。

我个人习惯，学任何新技术前，先把环境搭好。下面是我推荐的本课程配套环境：

# Python版本
python >= 3.10

# 必备库
pip install pydantic
pip install sqlalchemy
pip install psycopg2-binary  # 如果你用PostgreSQL
pip install neo4j            # 可选，图数据库驱动
pip install fastapi          # 用来搭API网关
pip install uvicorn          # ASGI服务器

小技巧：用 pyenv 管理多版本Python环境。别问为什么，相信我，当你在不同项目间切换时，这玩意儿能救命。

一个简单的元数据例子

为了让你对元数据管道有个直观感受，我们快速写个最小的示例。假设我们有一个PostgreSQL数据库，想采集所有表的字段信息。

import psycopg2
import json

# 连接数据库（请替换为你的实际连接信息）
conn = psycopg2.connect(
    host="localhost",
    port=5432,
    database="my_warehouse",
    user="admin",
    password="secret"
)

# 查询表的元数据
query = """
SELECT
    table_name,
    column_name,
    data_type,
    is_nullable
FROM information_schema.columns
WHERE table_schema = 'public'
ORDER BY table_name, ordinal_position;
"""

cur = conn.cursor()
cur.execute(query)
rows = cur.fetchall()

# 转成Python字典
metadata = {}
for table, column, dtype, nullable in rows:
    if table not in metadata:
        metadata[table] = []
    metadata[table].append({
        "column": column,
        "type": dtype,
        "nullable": nullable == "YES"
    })

# 输出为JSON，这就是最原始的元数据
print(json.dumps(metadata, indent=2))

cur.close()
conn.close()

你看，就这么几行代码，我们就完成了一个最简陋的元数据采集器。但它只能做一种数据库，输出一种格式。真正的管道要复杂得多。

本章知识结构图

下面这个SVG图，概括了元数据管道的整体架构和我们这章的要点。你可以先看个大概，后面每个环节我们都会逐层拆解。

元数据管道知识结构 元数据管道知识结构 元数据管道 元数据来源 RDBMS（MySQL, PG） ETL工具（Airflow） BI平台（Tableau） 管道核心环节 采集器（Extract） 解析器（Transform） 适配器（Connect） 存储 & API网关 课程目标：构建可扩展的Python管道 前置知识：Python3.10+ | SQL基础 | 命令行 | 图概念 环境：pydantic / sqlalchemy / fastapi / neo4j

一句话总结本章：元数据是数据的数据。元数据管道自动化地采集、处理、存储和暴露这些描述信息。我们会在本门课中用Python一步步搭建一个生产可用的管道。

曾经有人问我：“用现成的元数据管理平台（Atlas、Amundsen）不就行了？为什么还要自己写Python管道？”

我的回答是：现成工具适合80%的通用场景。但当你面对特殊的内部格式、定制的血缘解析逻辑、或者需要与已有的Python工具链深度集成时，自己写的管道才真正可控。而且，理解原理之后，你去用那些工具也会游刃有余。

嗯，这就是本章的内容。我们讲了元数据的定义、管道的作用、基本构成以及你需要的前置知识。这些概念会贯穿整个课程。接下来的章节，我们会从最底层的采集器开始，手写一个个组件，最后拼出一条完整的管道。

别着急，慢慢来。数据治理这件事，值得你投入时间。

← 上一章 📖 返回目录 下一章 →