1. 课程导入与Databricks湖仓全景
欢迎进入《Databricks企业数据湖仓建模与开发》。在动手写第一行 PySpark 之前，我们需要先建立一张"全局地图"：企业数据平台到底要解决什么问题，Lakehouse 为什么会出现，Databricks 平台由哪些组件构成，以及本课程将用一个什么样的实战项目把 30 章内容串起来。这一章不涉及复杂代码，但它决定了你后续每一章"为什么这么做"的判断依据。
一、从数据湖与数据仓库的割裂说起
传统企业数据架构长期存在两条并行链路。一条是数据湖：以 HDFS、S3、ADLS 等对象存储为底座，存放原始日志、JSON、Parquet、图片等半结构化与非结构化数据，成本低、格式自由，但缺乏事务、缺乏 Schema 约束、缺乏高效点查与更新能力，容易退化成"数据沼泽"。另一条是数据仓库：以 Teradata、Oracle、Snowflake、Redshift 为代表，提供强 Schema、ACID 事务、SQL 优化器和成熟的 BI 生态，但存储与计算耦合、扩展成本高，且难以直接处理原始文件和机器学习特征。
结果是同一份业务数据被反复搬运：湖里存一份原始数据，ETL 到仓里再存一份清洗结果，特征工程又在第三处再存一份。数据冗余、口径不一致、链路延迟、治理困难，成为企业数据团队最典型的痛点。Lakehouse（湖仓一体）的核心价值，就是用一套存储、一套元数据、一套权限，同时提供数据湖的低成本开放格式与数据仓库的事务、性能与治理能力。
二、Lakehouse 的四个关键能力
理解 Lakehouse，抓住四个关键词即可：
- 开放格式：底层数据以 Parquet 等开放列式格式落地在对象存储上，不被厂商锁定，Spark、Trino、Flink、Pandas 都能直接读。
- 事务与元数据层：通过 Delta Lake 这样的表格式，在 Parquet 之上维护事务日志（_delta_log），实现 ACID、时间旅行、Schema 演进与 MERGE/UPSERT。
- 统一治理：Unity Catalog 提供跨工作区、跨云的表、视图、函数、模型、卷的统一权限与血缘。
- 多负载融合：BI 报表、流式处理、数据科学、机器学习、GenAI 在同一份数据上工作，不再需要为每种负载复制一份。
需要强调的是，Lakehouse 不是"把仓库搬到湖上"这么简单。它要求我们重新思考分层建模：Bronze（原始接入）、Silver（清洗整合）、Gold（主题聚合）三层如何在 Delta 表上落地，增量如何处理，维度与事实如何组织，这些正是本课程后续章节的主线。
三、Databricks 平台组件地图
Databricks 是 Lakehouse 的典型工程实现。它的组件可以按"控制面—计算面—数据面—治理面"来理解：控制面是账户控制台与工作区 UI，负责用户、集群策略、作业调度；计算面包括 All-Purpose Cluster、Job Cluster、SQL Warehouse、Serverless 计算；数据面是 Delta 表与对象存储；治理面是 Unity Catalog。围绕这些底座，平台提供 Notebook、Delta Live Tables（DLT）、Workflows、Databricks SQL、MLflow、Feature Store、Model Serving 等能力。
下面这张图把本节的核心对象——存储格式、表格式、计算引擎、治理与上层负载——组织成一张平台全景图，帮助你建立"数据从哪来、经过什么、被谁消费"的空间感。
四、企业数据湖仓的典型场景
在真实企业里，Lakehouse 通常从四类场景切入。第一类是统一数据接入与增量同步：用 Auto Loader 或 Kafka 把业务库 CDC 与日志持续写入 Bronze，再用 MERGE 做幂等更新。第二类是数仓迁移与替换：把原有 ODS/DWD/DWS/ADS 分层映射到 Bronze/Silver/Gold，用 Delta 表承接原仓库的维度和事实。第三类是实时与准实时分析：流式写入 Silver，SQL Warehouse 直接查询，支撑分钟级看板。第四类是机器学习与特征工程：在 Gold 之上构建特征表，用 MLflow 跟踪实验、注册模型并上线服务。
这四类场景共享同一套存储与治理，这正是 Lakehouse 相对"湖 + 仓"双栈方案最直接的收益：链路更短、口径更统一、成本更可控。
五、课程实战项目：零售订单湖仓
为了让 30 章内容有统一的落点，本课程设计了一个贯穿始终的实战项目——零售订单湖仓。项目背景设定为一家中型零售企业，数据源包括：订单系统 MySQL 的 CDC 增量、门店 POS 日志、商品主数据 CSV、以及用户行为埋点 JSON。目标是在 Databricks 上构建 Bronze/Silver/Gold 三层 Delta 表，最终产出"每日门店销售汇总""商品维度宽表""用户复购指标"三张 Gold 表，并支持 BI 查询与一个简单的销量预测模型。
项目会用到以下示例参数（均为教学假设值，非真实生产数据）：订单表约 2000 万行、日增量约 30 万行；POS 日志每日约 500 万条；商品主数据约 8 万行；集群采用 2 个 Driver + 4 个 Worker（每 Worker 8 核 32GB）的 Job Cluster；Delta 表按 dt 分区，Z-Order 按 store_id 与 sku_id 优化。这些参数会在后续章节中反复出现，用于演示分区裁剪、文件合并、广播 Join 等优化手段的实际效果。