Databricks Certified Data Engineer Associate (DEA)

**把 Delta Lake 当普通 Parquet 用** — Delta Lake 是 Parquet 文件 + transaction log（_delta_log 文件夹），这个 log 才是 ACID 的核心。常见错误：以为"写 Parquet 就行"、忽略 OPTIMIZE 和 VACUUM 命令（OPTIMIZE 做小文件合并、Z-ORDER 做数据 clustering、VACUUM 清理过期快照文件），结果查询性能越用越差、存储成本失控。考试会考"执行 OPTIMIZE 后 Time Travel 还能不能查历史版本"（能，VACUUM 才会真正删除旧文件）。

**Structured Streaming 的 watermark 理解错** — Watermark 是告诉引擎"多晚到的数据我不再等了"，用来平衡 late data 容忍度和状态存储大小。常见错误：以为 watermark 是"数据处理速度上限"或"触发间隔"。考题会给你一段代码 `.withWatermark("event_time", "10 minutes").groupBy(window(...))`，问"一条 event_time 比当前 watermark 早 15 分钟到达的数据会发生什么"（被丢弃，不会更新聚合结果）。

**Unity Catalog 和老 Hive Metastore 混淆** — 老的 Hive Metastore 是两层命名（database.table），权限粒度粗、没有 catalog 层、不跨 workspace。Unity Catalog 是三层（catalog.schema.table）、支持 row/column 级安全、一个 Unity Catalog Metastore 可以服务多个 workspace、数据血缘自动追踪。考题会问"从 hive_metastore 的表迁移到 Unity Catalog，权限模型会如何变化"。别把 USE CATALOG 和 USE SCHEMA 混用。

**分区（Partitioning）策略用错导致严重 skew** — Delta Lake 分区跟 Hive 一样按文件夹分，但 Databricks 强烈不推荐对高基数字段（user_id、timestamp 到秒）分区。正确做法：按日期（低基数、查询常用）分区 + 用 Z-ORDER 对 user_id 做二级 clustering。考题常给场景："一张表按 timestamp 到秒分区，产生 300 万个小文件" — 让你选改进方案（答案是改成按 date 分区 + Z-ORDER BY timestamp）。

**Auto Loader 的 schema evolution 模式搞错** — 有 5 种模式：addNewColumns（默认，新列自动加 + 流失败重启）、rescue（所有 schema 变更存到 _rescued_data 列）、failOnNewColumns（严格模式）、none（忽略新列）。生产场景最常用的是 addNewColumns，但考题会问"希望不中断流处理、所有未知字段保留但不修改 schema"（答案是 rescue）。

**MERGE INTO 语法细节** — WHEN MATCHED / WHEN NOT MATCHED / WHEN NOT MATCHED BY SOURCE 三种子句的区别要分清。NOT MATCHED BY SOURCE 是 Databricks 扩展，用于删除目标表中源表不再有的行（SCD Type 1 硬删除场景）。考题会给一段 MERGE 代码问执行后的结果行数。

**Databricks Workflows 的 retry 和 dependency** — Workflows（Jobs）的 task 之间可以设置依赖（DAG）和 retry 策略。考题常问"一个 task 失败后，依赖它的下游 task 会发生什么"（默认不会运行，除非配置了 Run if: At least one failed 这种条件）。Job Cluster 和 All-purpose Cluster 的区别也是考点：Job Cluster 任务结束后自动销毁、便宜；All-purpose 常驻、贵但快启动、适合交互开发。