📚 课程目录第1章 Databricks平台与AI数据工程全景

1. Databricks平台与AI数据工程全景

在开始学习数据建模与分析工程之前，需要先建立一张“平台地图”：Databricks 并不是单一工具，而是一套围绕 Lakehouse 架构组织起来的数据与 AI 工程平台。理解各组件之间的分工与协作关系，才能明确数据建模与分析工程在整个体系中的位置——它既不是孤立的数据转换环节，也不是只服务于报表的末端步骤，而是连接原始数据、业务语义与 AI 应用的中枢层。

Lakehouse：统一数据底座

传统数据架构中，数据仓库擅长结构化查询与治理，数据湖擅长低成本存储多样数据，但两者长期割裂，导致数据重复搬运、口径不一致。Lakehouse 的核心思路是把二者合并：底层使用云对象存储（如 S3、ADLS、GCS）保存开放格式文件，中间通过 Delta Lake 提供事务、Schema 约束与时间旅行能力，上层再通过统一的计算引擎同时支撑 SQL 分析、机器学习与流处理。对数据建模与分析工程而言，这意味着同一份数据可以被 BI、特征工程和模型训练共同使用，而不必为每种用途单独复制一份。

Delta Lake：可靠性与可演进性的基础

Delta Lake 是 Lakehouse 的存储层协议，它在 Parquet 文件之上维护一份事务日志（_delta_log），记录每次写入、更新、删除和 Schema 变更。数据建模中常见的“缓慢变化维”“增量合并”“回滚重算”等需求，都依赖 Delta 的 ACID 事务与 MERGE、UPDATE、DELETE 能力。例如，当上游订单表发生迟到数据时，可以用 MERGE 按主键更新目标表，而不是整表重写；当模型口径调整需要回溯时，可以用时间旅行读取历史版本进行对比验证。Delta 还支持 Schema 演进与约束，使建模过程中新增字段、修改类型有据可依，而不是靠人工约定。

Unity Catalog：治理与语义的入口

Unity Catalog 提供跨工作区的统一元数据、权限与血缘管理。它把数据对象组织为“目录—模式—表/视图/函数/模型”的层级，并对表、列、行级权限进行集中控制。对数据建模来说，Unity Catalog 的价值不只是权限，更在于它让“表、视图、指标、特征、模型”都成为可发现、可追溯的资产。建模时定义的维度表、事实表、聚合视图，都可以在 Catalog 中被检索、授权和审计，血缘信息还能帮助分析某个指标变化究竟来自哪张源表或哪次作业。

MLflow、Workflows 与 AI 运行时

MLflow 负责实验跟踪、模型注册与部署，它记录每次训练的参数、指标和产物，使模型从实验到上线的过程可复现。Workflows 负责任务编排，把数据抽取、清洗、建模、训练、评估等步骤组织成有依赖关系的作业链，并支持定时、事件触发与重试。AI 运行时则提供面向大模型与生成式 AI 的推理、向量检索与 Agent 能力。三者与 Lakehouse、Delta、Unity Catalog 共同构成一条从数据到智能的完整链路。

数据建模与分析工程在平台中的位置

如果把平台比作一条生产线，数据建模与分析工程位于“原料”与“成品”之间：上游是原始数据接入与存储，下游是 BI 分析、特征服务与 AI 应用。它的主要职责包括：定义业务实体与关系，设计维度模型或宽表，编写可维护的转换逻辑，管理数据质量与口径一致性，并让模型和特征能够被复用。换句话说，数据建模与分析工程决定了“数据以什么结构被理解”，而 Lakehouse、Delta、Unity Catalog、MLflow、Workflows 与 AI 运行时则分别提供存储、可靠性、治理、实验管理、编排与智能运行能力。

从图中可以看到，数据建模与分析工程处于承上启下的位置：向下依赖 Lakehouse 与 Delta Lake 提供可靠存储与事务能力，向上通过 Unity Catalog 实现治理与共享，再向 BI、MLflow 和 AI 运行时输出结构化、可复用的数据资产。Workflows 则贯穿其中，负责把建模、训练、评估等步骤编排为可调度、可重试的作业链。

一个可执行的建模示例

假设我们要为零售业务构建一张订单事实表。源数据是原始订单表 raw_orders，包含订单号、客户号、商品号、数量、单价和下单时间。建模目标是在 Delta 表中生成 fact_orders，并关联维度表 dim_customer 与 dim_product。关键实现如下：

-- 在 Unity Catalog 中创建建模模式
CREATE SCHEMA IF NOT EXISTS retail_modeling;

-- 创建 Delta 事实表，按订单日期分区
CREATE TABLE IF NOT EXISTS retail_modeling.fact_orders (
  order_id      STRING,
  customer_id   STRING,
  product_id    STRING,
  quantity      INT,
  unit_price    DECIMAL(10,2),
  order_amount  DECIMAL(12,2),
  order_date    DATE
)
USING DELTA
PARTITIONED BY (order_date);

-- 使用 MERGE 增量写入，按 order_id 去重更新
MERGE INTO retail_modeling.fact_orders AS t
USING (
  SELECT order_id, customer_id, product_id,
         quantity, unit_price,
         quantity * unit_price AS order_amount,
         CAST(order_time AS DATE) AS order_date
  FROM raw_orders
  WHERE order_time >= current_date() - INTERVAL 1 DAY
) AS s
ON t.order_id = s.order_id
WHEN MATCHED THEN UPDATE SET *
WHEN NOT MATCHED THEN INSERT *;

执行后，可以通过以下方式判断结果是否符合预期：查询当日新增行数与源表当日订单数是否一致；检查 order_amount 是否等于 quantity * unit_price；确认分区 order_date 下没有重复 order_id。如果发现重复，通常说明 MERGE 的匹配键不唯一，需要回到源表检查主键定义。这些检查正是数据建模与分析工程中“口径一致性”和“数据质量”的具体落点。

建模时优先在 Unity Catalog 中定义表与视图，而不是在个人目录下临时建表。这样血缘、权限和资产发现才能自动生效，后续 BI 与模型训练也能直接引用同一份定义。

总结来看，Databricks 平台提供的是“存储—治理—编排—智能”的完整能力，而数据建模与分析工程负责在其中定义数据的结构与语义。掌握这张全景图，后续学习 Delta 表设计、维度建模、指标口径管理和特征工程时，就能清楚每一步在平台中的位置与依赖关系。