📚 课程目录第1章课程导入与全景认知

1. 课程导入与全景认知

在真实的数据平台里，数据很少只以一种方式到达。业务库的订单通过 CDC 持续流入，日志文件按小时批量落盘，模型特征需要分钟级刷新，而训练任务又要求对历史全量数据做一致性快照。Databricks 的价值，正是把批处理、流处理、AI 训练与任务编排放在同一套 Lakehouse 体系里完成。本课程的目标，是让你能够独立设计、实现并运维这样一条端到端管道，而不是只会点几个按钮。

学完这门课，你应该能做到什么

课程围绕四个能力层次展开。第一层是建模与存储：理解 Delta Lake 的 ACID 事务、时间旅行和 Schema 演进，能设计 Bronze/Silver/Gold 分层表。第二层是批流统一处理：用 Spark Structured Streaming 处理增量数据，用 Auto Loader 做文件摄取，并理解流式表与批表如何共用同一份存储。第三层是AI 与特征工程：用 Feature Store 管理特征、保证训练与推理的一致性，用 MLflow 跟踪实验与模型版本。第四层是编排与运维：用 Databricks Workflows 组织多任务 DAG，配置依赖、重试、告警与参数传递，并借助 Unity Catalog 做权限与血缘治理。

这四层不是并列的知识点，而是同一条数据链路上的不同环节。下面这张全景图给出了本课程的核心对象与它们之间的数据流向，后续每一章都会落在图中的某个节点或某条边上。

核心概念：批、流、编排三者的关系

初学者最容易混淆的是“批”和“流”的边界。在 Databricks 里，二者并不是两套独立系统，而是同一张 Delta 表上的两种读取方式。流式写入把新数据不断追加为新的文件版本，批查询读取的是某个时刻的完整快照。这意味着你可以用流的方式写入 Bronze 表，再用批的方式对 Silver 表做全量重算，二者互不冲突。

第二个关键概念是编排不等于调度。调度只回答“什么时候跑”，编排还要回答“谁依赖谁、失败了怎么办、参数怎么传、跑完通知谁”。一个典型的 Workflows 任务 DAG 可能是：ingest_orders 成功后触发 build_silver_orders，后者与 build_silver_customers 都成功后触发 build_gold_sales，最后触发 train_forecast_model。每个任务可以指定不同的集群规格，重试次数和超时时间也各自独立。

第三个概念是特征一致性。训练时用历史特征、推理时用实时特征，如果两边的计算逻辑不一致，模型效果会明显下降。Feature Store 的作用就是把特征计算逻辑固化成一张带时间戳的表，训练和推理都从同一张表取数，从而消除这种偏差。

典型应用场景

本课程会反复引用三个场景，帮助你建立直觉。场景一是电商实时销售看板：订单 CDC 流入 Kafka，Auto Loader 每 30 秒摄取一次，Silver 层做去重与金额校验，Gold 层按分钟聚合销售额，BI 看板每 10 秒刷新。场景二是日志异常检测：应用日志按小时写入云存储，Auto Loader 增量读取，Silver 层解析出错误码与耗时，再用 MLflow 注册的模型做批推理，输出异常分数。场景三是推荐特征回填：当特征逻辑变更时，需要对过去 90 天的历史数据重新计算，这属于典型的批处理任务，由 Workflows 按天分片并行执行。

这三个场景覆盖了流式摄取、批式重算、AI 推理和任务编排四类操作。你在后续章节中遇到的每个技术点，都可以放回这三个场景里理解它的位置和作用。

技术栈全景与学习路径

从工具角度看，本课程涉及的技术栈可以分成四组。存储与表格式：Delta Lake、Unity Catalog。计算引擎：Spark SQL、Structured Streaming、Auto Loader。AI 工具链：Feature Store、MLflow、Model Serving。编排与运维：Databricks Workflows、Job Cluster、告警与运行历史。这四组工具不是孤立的，它们通过 Delta 表和 Unity Catalog 的命名空间连接在一起。

建议的学习顺序是：先掌握 Delta 表的读写与分层建模，再学习流式摄取与增量处理，然后进入特征工程与模型管理，最后用 Workflows 把前面所有任务串成一条可调度、可监控、可重跑的管道。每学完一个模块，都回到全景图里确认自己掌握了哪个节点。

一个可执行的最小示例

为了让你在课程开始就有一个可运行的对象，下面给出一个最小管道的骨架。它把原始 JSON 文件摄取到 Bronze 表，再清洗到 Silver 表。示例参数为教学假设，实际运行时请替换为你自己的路径和表名。

-- 1. Bronze：用 Auto Loader 增量摄取 JSON
CREATE OR REFRESH STREAMING TABLE bronze_orders
AS SELECT *,
       current_timestamp() AS _ingest_time,
       _metadata.file_path AS _source_file
FROM cloud_files(
  "s3://demo-lake/raw/orders/",
  "json",
  map("cloudFiles.inferColumnTypes", "true")
);

-- 2. Silver：去重、过滤非法金额、统一字段类型
CREATE OR REFRESH STREAMING TABLE silver_orders
AS SELECT
    order_id,
    CAST(customer_id AS BIGINT) AS customer_id,
    CAST(amount AS DECIMAL(12,2)) AS amount,
    CAST(order_time AS TIMESTAMP) AS order_time
FROM STREAM(bronze_orders)
WHERE order_id IS NOT NULL
  AND amount > 0;

-- 3. 验证：对比两表行数与金额区间
SELECT 'bronze' AS layer, COUNT(*) AS cnt FROM bronze_orders
UNION ALL
SELECT 'silver', COUNT(*) FROM silver_orders;

运行后你应该观察到：Bronze 行数大于等于 Silver 行数，差额来自被过滤掉的空 order_id 和非正金额记录。如果 Silver 行数为零，优先检查 JSON 字段名是否与 SELECT 中的列名一致，以及 amount 字段是否被推断成了字符串类型。这个“行数差 + 金额区间”的检查方式，会在后续章节中反复用到。

Auto Loader 会记录已处理文件的检查点。如果你在测试时反复修改源文件，建议更换检查点目录或使用新的表名，否则可能看不到预期的增量效果。

到这里，你已经看到了本课程的完整轮廓：从数据源到 Delta 分层，从流式摄取到 AI 特征，从单个任务到 Workflows 编排，最后用 Unity Catalog 统一治理。接下来的章节会逐个展开这些节点，并始终把它们放回这条端到端管道中理解。