1. Lakehouse架构与企业数据平台演进
企业数据平台在过去二十年经历了三次明显的架构跃迁：以关系型数据库为核心的数据仓库、以低成本对象存储为核心的数据湖，以及把两者能力统一到同一份数据上的Lakehouse（湖仓一体）。理解这三者的驱动力、能力边界与代价，是判断“什么时候该用哪种架构、Databricks 在其中的定位是什么”的前提。
一、三代架构的驱动力与代价
数据仓库的核心价值是强 Schema、事务一致性与高性能 SQL。它把数据先清洗、建模（如星型模型、雪花模型）再入库，因此 BI 报表口径稳定、查询快。代价是：存储与计算强耦合，扩容成本高；只能处理结构化数据；对半结构化日志、图像、文本、IoT 时序等数据支持差；Schema 变更需要停机式 ETL 改造。
数据湖的出现正是为了解决“存得下、存得便宜、什么格式都能存”。它把原始数据以开放格式（Parquet、ORC、JSON、Avro）落到对象存储（S3、ADLS、GCS、OSS），计算与存储解耦，成本大幅下降。但代价随之而来：缺少事务与并发控制，容易出现读到写一半的文件；缺少 Schema 约束，容易退化成“数据沼泽”；小文件多、元数据管理弱，查询性能不稳定；ACID、时间旅行、行级更新等能力缺失。
于是企业普遍形成“两套系统”的现实：数据湖存原始数据，数据仓库做分析。数据在两者之间反复搬运，产生冗余副本、口径不一致、时效延迟和治理割裂。Lakehouse 的驱动力就是用一套开放存储 + 一层事务化表格式 + 统一计算引擎，同时提供数据湖的低成本与数据仓库的可靠性。
二、Lakehouse 的核心特征
Lakehouse 不是“数据湖加一个查询引擎”，其关键差异在于在对象存储之上引入开放表格式（Delta Lake、Apache Iceberg、Apache Hudi）。以 Delta Lake 为例，它在 Parquet 数据文件旁维护一份事务日志 _delta_log，记录每次提交的元数据与文件增删，从而带来：
- ACID 事务：并发写入通过乐观并发控制与冲突检测保证一致性，读者不会看到半成品数据。
- Schema 演进与约束：支持加列、改类型（受控），并可对关键列施加 NOT NULL、CHECK 约束。
- 时间旅行：按版本号或时间戳查询历史快照，便于审计、回溯与复现实验。
- 批流一体：同一张表既可作为流式写入目标（含 MERGE、UPSERT），也可被批查询读取。
- 开放格式：底层仍是 Parquet，可被 Spark、Presto/Trino、Flink 等多引擎读取，避免厂商锁定。
这些能力使 Lakehouse 能同时承载 BI 报表、机器学习特征、实时分析与数据科学探索，而不必为每种负载复制一份数据。
三、Databricks 平台的定位
Databricks 是 Lakehouse 架构的典型实现平台，其定位可以概括为：以 Delta Lake 为存储层、以 Spark 与 Photon 为计算层、以 Unity Catalog 为治理层、以 Lakehouse 上的多工作负载为价值层。它把数据工程、SQL 分析、机器学习、实时流处理统一在同一份数据上，并通过 Unity Catalog 提供跨工作区的统一权限、血缘与审计。
从选型角度看，若企业已有大量结构化报表且数据量不大，传统数仓仍可胜任；若数据种类多、增长快、需要 ML 与实时能力，且希望避免湖仓双份存储，Lakehouse 更合适。Databricks 的适用场景通常包括：多源异构数据入湖、增量 ETL/ELT、特征工程与模型训练、实时风控与推荐、以及需要统一治理的跨部门数据共享。
四、一个可对照的示例：从双系统到 Lakehouse
假设某零售企业每天产生约 2 亿条订单与行为日志，原有架构是：日志经 Kafka 落到 S3 数据湖（Parquet），再用 Spark 每日批处理写入数仓做报表。痛点是：报表 T+1、无法做实时推荐、特征与报表口径不一致、湖中数据无人治理。
迁移到 Lakehouse 后，典型做法是：Kafka 通过 Structured Streaming 直接写入 Delta 表 fact_orders，使用 MERGE INTO 做 UPSERT；同一张表既供 SQL Warehouse 出报表，也供特征工程读取。示例参数（合理假设）：
-- 建表：启用 Schema 约束与变更追踪
CREATE TABLE IF NOT EXISTS lakehouse.fact_orders (
order_id STRING NOT NULL,
user_id STRING,
amount DECIMAL(12,2),
status STRING,
event_time TIMESTAMP
)
USING DELTA
TBLPROPERTIES ('delta.enableChangeDataFeed' = 'true');
-- 流式 UPSERT
MERGE INTO lakehouse.fact_orders AS t
USING staging_orders AS s
ON t.order_id = s.order_id
WHEN MATCHED THEN UPDATE SET *
WHEN NOT MATCHED THEN INSERT *;判断迁移是否达成目标，可观察几个可验证信号：报表时效从 T+1 缩短到分钟级；同一 order_id 在报表与特征表中的金额一致；通过 DESCRIBE HISTORY lakehouse.fact_orders 能看到每次写入版本，必要时用 VERSION AS OF 回溯到出问题前的快照；Unity Catalog 中能看到该表的上下游血缘。若这些信号成立，说明 Lakehouse 的核心收益已经落地，而不仅是换了一个存储格式。