想象你是一家大型公司的档案管理员，公司所有员工都在往同一个共享库房里塞文件——销售记录、用户日志、订单明细，堆积如山。一开始大家随意堆放，很快问题出现了：小李上午存的文件被小张下午覆盖了，有人改了旧数据导致报表对不上账，整个库房陷入混乱。这时，Delta Lake 出现了，它就像一位经验丰富的首席档案官，给这个混乱的库房带来了秩序、安全与历史记忆。 Delta Lake 是一个开源存储层，它给数据湖添加了“数据库式的保障”。它让数据湖不再只是一个“大仓库”，而变成一个可靠、高效、可回溯的数据管理平台。你可以把它理解为：给原本“无规则”的数据湖，装上了一套完整的“档案管理制度”——每个操作都有记录、有备份、有规则，还能随时回到过去查看任何时刻的档案。

岗位关联

掌握 Delta Lake 的核心特性，意味着你不仅能搭建数据湖，还能让湖中的数据像数据库一样可靠、可追溯、高性能。这是数据平台工程师从“能用”走向“好用”的关键技能。

目录
  1. 可视化演示
  2. 数据湖的困境
  3. ACID事务保障
  4. 时间旅行回溯
  5. Schema演进
  6. 高效数据操作
  7. 对比与流批一体
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

展示Delta Lake的ACID事务日志、时间旅行版本管理与三大数据湖表格式对比，理解数据湖事务可靠性的核心机制。

本节配有交互动效（进入视口后自动加载，约 3KB）。

Delta Lake ACID事务机制 事务日志(_delta_log)记录每次提交，保证原子性 乐观并发控制+冲突解决，支持多写并发 ACID = Atomic + Consistent + Isolated + Durable 数据湖上实现可靠事务

数据湖的困境

档案管理员老张最近焦头烂额。公司所有部门都往同一个共享库房里塞文件，销售记录、用户日志、订单明细，堆积如山。但这还不是最可怕的——最可怕的是库房里的混乱状态：小李上午存的文件被小张下午覆盖了，有人改了旧数据导致报表对不上账，整个库房陷入了数据混乱的泥潭。

这个场景正是数据湖技术早期面临的真实困境。数据湖（Data Lake）以低成本存储海量原始数据著称，支持结构化、半结构化、非结构化数据的统一存放。然而，传统数据湖有几个致命痛点：文件系统无法保证多个读写操作之间的原子性；数据文件一旦写入就很难高效地更新或删除，通常只能“全量重写”；历史数据被覆盖后无法找回。这些问题让“数据湖”沦为“数据沼泽”。

Delta Lake 的解决方案是在数据湖之上添加一层“事务日志”（Transaction Log）。这就像在共享库房里建立了一套完整的档案登记制度：每次存取操作都必须先写操作日志，再改实际文件；所有操作要么完整成功，要么完全不发生；每个操作都有时间戳和编号，形成一条不可篡改的历史记录。这套机制将数据湖从“无规则的仓库”升级为“制度化的档案馆”。

ACID事务保障

档案库的新制度规定：任何人往库房里放文件或修改文件，必须按照“申请-执行-确认”流程完成，不能直接动手。这个流程被称作“事务”（Transaction）。

ACID 是数据库事务的四大核心属性，Delta Lake 将其引入数据湖：

  • 原子性（Atomicity）：一个事务中的所有操作要么全部成功，要么全部回滚。就像档案管理员整理一份文件时，如果中途出错，整个文件恢复到操作前的状态，不会出现“改了一半”的情况。
  • 一致性（Consistency）：事务完成后，数据必须满足所有预设规则。例如，账户余额不允许出现负数，事务执行后绝不会破坏这类约束。
  • 隔离性（Isolation）：多个事务并发执行时，互不干扰。就像两个档案管理员同时整理不同文件，彼此看不到对方未提交的中间状态。
  • 持久性（Durability）：事务一旦提交，数据就不会丢失，即使系统崩溃也能恢复。

在 Delta Lake 的实现中，ACID 的核心机制是 Write-Ahead Log（预写日志）：数据修改操作不直接作用于数据文件，而是先顺序写入一个日志文件，记录这次操作的详细信息。当日志成功写入后，操作才真正生效。这个机制可以比作档案管理员“先登记、后执行”——所有操作在动手前先写在册子上。

最终，当老张需要处理一批数据变更时，他会先在登记册上按顺序写清楚每一步操作，确认无误后再动手改文件。即使中途有人闯入打断，登记册上也会有完整记录，不会出现不可追溯的改变。这就是 ACID 给数据湖带来的“安全感”。

Delta Transaction=Write-Ahead Log+Parquet Data Files\text{Delta Transaction} = \text{Write-Ahead Log} + \text{Parquet Data Files}
这个公式说明了 Delta Lake 事务的核心组成：每个事务先把操作记录在日志中，再实际修改数据文件。预写日志是事务可靠性的基石。
  1. 事务（Transaction）一次完整的数据操作单元。例如“将用户表 A 的 100 条记录更新”，这就是一个事务。
    Transaction={Begin,Operations,Commit}\text{Transaction} = \{\text{Begin}, \text{Operations}, \text{Commit}\}
  2. Write-Ahead Log（预写日志）在修改数据之前，先把操作信息写入日志。日志是顺序追加的，速度极快，并且记录了操作的完整信息。
    Log=Append-Only Sequence of Operations\text{Log} = \text{Append-Only Sequence of Operations}
  3. Parquet 数据文件实际存储数据的列式文件格式，Delta Lake 用它来存储表中的真实数据。
    Data Files=Parquet Format with Columnar Storage\text{Data Files} = \text{Parquet Format with Columnar Storage}

时间旅行回溯

有了登记制度后，老张发现一个新需求：有些时候需要查看某个文件在“上周”是什么样子。以前数据被覆盖就永远找不回来了，但现在，因为每次修改都有日志记录，他可以随时“穿越”回任意历史版本。

这就是 Delta Lake 的“时间旅行”（Time Travel）特性。由于事务日志按版本号依次记录每一次操作，每一条数据表的版本都对应一个特定的快照（Snapshot）。用户可以通过版本号或时间戳查询历史上任意时刻的数据状态。

时间旅行的实现原理基于“版本控制”：每次事务提交后，事务日志都会生成一个新的日志条目，指向当前最新的数据文件列表。查询历史版本时，Delta Lake 会读取指定版本号之前的日志，重建当时的数据文件列表，然后从这些文件读取数据。这就像一个仓库管理员要查看旧档案时，从登记册的某一条记录开始，把当时存放的文件一一找出来。

使用时间旅行的方法很简单，只需在读取时指定版本号或时间戳：

时间旅行让数据恢复也变得极其简单。当数据被错误修改时（比如误删了某张表的数据），只需回到误操作之前的版本即可恢复。在金融审计、法规合规、历史数据分析等场景中，这个特性价值连城。老张再也不用担心档案被改得面目全非——他随时可以坐上“时光机”，回到任意一天看原来的样子。

Snapshot(V)=Data Files Referenced by Log≤V\text{Snapshot}(V) = \text{Data Files Referenced by Log} \leq V
这表示：要获取 V 版本的数据快照，只需找出日志中所有版本号 ≤ V 的提交所引用的数据文件集合。
  1. 版本号 V事务日志从 0 开始，每提交一次事务，版本号加 1。它就像档案的“编号”。
    Version=Transaction Log Sequence Number\text{Version} = \text{Transaction Log Sequence Number}
  2. 快照 Snapshot(V)在 V 版本时，数据表的完整状态。它是所有 ≤ V 版本日志引用的数据文件的集合。
    Snapshot=⋃v≤V{Data Files in Commit v}\text{Snapshot} = \bigcup_{v \leq V} \{\text{Data Files in Commit } v\}
  3. 引用文件列表每个版本的日志条目记录了该版本包含的所有数据文件路径。
    Commit(v)→{file1,file2,… }\text{Commit}(v) \rightarrow \{\text{file}_1, \text{file}_2, \dots\}
text3 行
Version 0: [file1.parquet, file2.parquet] -- 初始数据Version 1: [file1.parquet, file3.parquet] -- 新增 file3Version 2: [file1.parquet, file4.parquet] -- 删除 file3，新增 file4

Schema演进

随着公司业务发展，档案库的表格模板也在不断调整。以前只需要记录“客户名称、电话号码”，现在还需要“邮箱、地址”；以前电话号码是数字，现在需要支持国际区号。在传统数据湖中，修改表结构意味着重写所有数据。但在 Delta Lake 中，改模板是一件轻松的事。

Schema 演进（Schema Evolution）是指数据表的列结构可以灵活地随时间调整。Delta Lake 支持添加新列、修改列类型、甚至重命名列。这些操作无需重写已有数据文件，只需要更新表结构的元数据。

具体机制是：每个表都有一个当前 Schema 定义，存在事务日志中。进行 Schema 变更时，只需在日志中追加一条"ALTER TABLE"记录，将 Schema 的版本从旧版本更新到新版本。读取数据时，Delta Lake 会将新 Schema 映射到旧数据文件上。如果匹配不上，则使用默认值填充。

Schema 演进的核心设计原则是“向后兼容”：旧数据文件应该能在新的 Schema 下被正确读取。这意味着添加列时必须有默认值或允许为空。Delta Lake 会自动完成类型转换和元数据映射，使用者不需要手动处理兼容逻辑。

对老张来说，Schema 演进就像给档案库升级了“文件夹标签体系”。以前标签只有名字和电话，现在可以添加“邮箱”标签，而且老档案不用重抄——读的时候，系统会自动给老文件补齐空的邮箱栏。数据表的结构变得越来越灵活，业务迭代不再被“改表就要重写数据”的魔咒束缚。

New Schema=Old Schema⊕ΔSchema\text{New Schema} = \text{Old Schema} \oplus \Delta\text{Schema}
公式表示：新 Schema 等于旧 Schema 加上一个 Schema 增量。增量的添加、删除、修改操作不会破坏已有数据文件。
  1. 旧 Schema当前表结构中已有的字段集合。例如 {id: INT, name: STRING}。
    Old={id: INT,name: STRING}\text{Old} = \{\text{id: INT}, \text{name: STRING}\}
  2. Schema 增量需要添加或修改的字段操作。例如 ADD COLUMN age: INT。
    Δ={ADD age: INT}\Delta = \{\text{ADD age: INT}\}
  3. 新 Schema合并后的字段集合。例如 {id: INT, name: STRING, age: INT}。
    New=Old⊕Δ={id, name, age}\text{New} = \text{Old} \oplus \Delta = \{\text{id, name, age}\}
text2 行
ALTER TABLE users ADD COLUMN email STRING;ALTER TABLE users ALTER COLUMN phone TYPE BIGINT;

高效数据操作

档案库的管理制度逐渐完善，但老张又遇到了新挑战：日常运营中，他需要经常“修改”和“删除”档案。例如客户换了电话号码，需要更新档案内容；有些客户注销了账户，需要把档案移除。在传统数据湖中，更新一条记录意味着重写整个表，这就像一个库房管理员为了改一页纸的内容，不得不把整栋楼的档案全部重新抄一遍。

Delta Lake 提供了一系列高效的数据操作原语，其中最重要的是 Merge、Update 和 Delete。

Merge（合并）是 Delta Lake 最强大的操作之一，它允许根据条件在一次操作中同时完成数据插入、更新和删除。这类似数据库的"UPSERT"语义（有则更新，无则插入）。它的语法类似于标准 SQL：

Update 操作允许按条件更新指定列，Delete 操作允许按条件删除指定行。这些操作的底层实现涉及“文件重写”策略：Delta Lake 不会修改原始 Parquet 文件（因为文件不可变），而是为需要更新的记录生成新版本的数据文件，并更新事务日志中引用的文件列表。未修改的数据文件保持不变，这避免了全表重写。

这套文件管理策略让 Delta Lake 在处理数据更新时，避免了对整个表的扫描和重写。另外，Delta Lake 还提供了 OPTIMIZE 操作来合并小文件——就像档案管理员定期把成堆的碎纸片整理成整齐的大文件册，提高查询性能；Z-ORDER 则是一种多维聚类技术，能显著加速特定过滤条件下的查询。

New Files=Old Files−Removed+Added\text{New Files} = \text{Old Files} - \text{Removed} + \text{Added}
公式描述了一次更新/删除操作后的文件变化：新文件集合 = 旧文件集合减去被替换的文件，加上新生成的文件。
  1. 旧文件集合操作前数据表包含的所有 Parquet 文件。
    Old Files={f1,f2,f3,f4}\text{Old Files} = \{f_1, f_2, f_3, f_4\}
  2. 移除的文件包含被修改或删除记录的文件。Delta Lake 会将这些文件标记为无效。
    Removed={f2,f3}\text{Removed} = \{f_2, f_3\}
  3. 新增的文件写入新数据的文件。例如操作后生成一个新文件。
    Added={f5}\text{Added} = \{f_5\}
  4. 新文件集合操作后数据表的有效文件列表。读取时，系统只读取这个列表中的文件。
    New Files={f1,f4,f5}\text{New Files} = \{f_1, f_4, f_5\}
sql5 行
MERGE INTO target_table AS tUSING source_table AS sON t.id = s.idWHEN MATCHED THEN UPDATE SET t.value = s.valueWHEN NOT MATCHED THEN INSERT (id, value) VALUES (s.id, s.value)

对比与流批一体

老张的档案馆运作得越来越好，他开始和同行交流——听说有的档案馆用“更先进的系统”，比如 Iceberg 和 Hudi。他需要了解这些方案的异同，并最终构建一个既能处理每日批量档案，又能实时记录新档案的统一系统。

Delta Lake、Apache Iceberg 和 Apache Hudi 是当前三大开源数据湖表格式，都被称为"Lakehouse"（湖仓一体）的基石。它们的目标相似，但在设计理念上各有侧重：

  • Delta Lake 由 Databricks 主导，深度集成 Spark。它的核心优势是事务日志作为唯一事实来源、简洁的表结构定义，以及与 Spark 生态的无缝融合。适合以 Spark 为主要计算引擎的企业，是流批一体的首选。
  • Apache Iceberg 由 Netflix 发起，追求中立的表格式规范。它支持多种计算引擎（Spark、Flink、Trino），在 SQL 兼容性和跨引擎支持方面做得更好，适合需要多引擎共存的公司。
  • Apache Hudi 起源于 Uber，核心优势是高效的文件级索引和增量处理能力，尤其擅长大规模 UPSERT（更新插入）场景，也支持 MOR（读时合并）等丰富的表服务。

在流批一体（Streaming and Batch Unified）方面，Delta Lake 提供了一个优雅的统一架构：无论你是通过批处理还是流处理写入数据，都写在同一张表上，读到的都是同一个版本的数据。这意味着批处理任务和流处理任务可以共享同一份数据，不再需要维护两套数据管道（批处理一套、流处理一套）。

老张最终恍然大悟：数据湖的建设不一定要在某一种方案上“押注”，而是要根据企业的计算引擎、场景特点来选型。但无论选哪种方案，核心方向是一样的——让数据湖拥有数据库的可靠性，同时保留数据湖的开放格式和低成本扩展能力。Delta Lake 用它的事务、时间旅行、Schema 演进和批流统一能力，把数据湖从一潭死水变成了活水之源，开启了湖仓一体的新范式。

Unified Table=Batch Jobs∪Streaming Jobs→Single Version of Truth\text{Unified Table} = \text{Batch Jobs} \cup \text{Streaming Jobs} \rightarrow \text{Single Version of Truth}
流批一体的核心思想：批处理作业和流处理作业都读写同一张 Delta 表，实时数据和离线数据不再分裂，形成统一的数据视图。
  1. 批处理作业周期性运行的大数据任务，比如每天凌晨算一遍全量报表。
    Batch=Scheduled Jobs with Large Volumes\text{Batch} = \text{Scheduled Jobs with Large Volumes}
  2. 流处理作业持续不断地读取并处理实时数据，比如实时统计用户点击。
    Stream=Continuous Processing of Events\text{Stream} = \text{Continuous Processing of Events}
  3. 单一事实版本批处理和流处理看到的是同一份数据状态，不存在“两边数据对不上”的困惑。
    Single Version=⋂(Batch View,Stream View)\text{Single Version} = \bigcap (\text{Batch View}, \text{Stream View})

AI 应用场景

实时数仓的增量计算

阶段：数据接入与预处理阶段

解决的问题：在传统数据湖架构中，每次新增数据都需要全量重算统计指标，计算成本高、实时性差。AI 模型的训练特征往往需要最新数据支撑，旧架构无法满足实时特征更新的需求。

具体案例：某电商推荐系统团队需要每天更新用户行为特征表。他们使用 Delta Lake 的 MERGE 操作将实时点击流数据和历史用户画像进行 UPSERT 合并，只更新变化的记录，再通过 Delta 的时间旅行功能快速回溯到任意版本的特征表进行模型对比实验。特征更新延迟从原来的 T+1 缩短到分钟级。

数据湖表结构治理

阶段：特征工程与数据治理阶段

解决的问题：AI 建模过程中，特征表的结构频繁调整（新增特征、修改字段类型），传统方式需要重写全表，效率低下。Schema 演进和数据治理成为 AI 开发瓶颈。

具体案例：某金融风控团队在构建反欺诈模型时，需要频繁向特征表添加新特征。借助 Delta Lake 的 Schema 演进能力，他们直接在原始表上增量添加特征列，无需重写历史数据，即使模型回测需要用到旧版特征组合，也能通过时间旅行获取。整个特征平台的数据治理效率提升了 3 倍。

流批一体的 AI 特征平台

阶段：模型训练与在线推理阶段

解决的问题：传统架构下，离线训练数据和在线推理数据分为两套系统（如 HDFS + Kafka），存在训练/推理数据不一致的问题。AI 模型的可靠性受到影响。

具体案例：某短视频推荐团队使用 Delta Lake 构建了流批一体的特征平台。Flink 流任务实时写入用户行为特征到 Delta 表，Spark 定时批任务同时对该表执行大规模离线特征计算。在线推理使用 Delta 表的 CDC（变更数据捕获）输出增量特征，离线训练则直接读取同一张 Delta 表的历史快照。训练和推理的特征分布完全一致，模型线上效果显著提升。

Python 演示

python50 行
from pyspark.sql import SparkSessionfrom pyspark.sql.functions import col, current_timestamp spark = SparkSession.builder \    .appName("DeltaLakeDemo") \    .config("spark.sql.extensions", "io.delta.sql.DeltaSparkSessionExtension") \    .config("spark.sql.catalog.spark_catalog",            "org.apache.spark.sql.delta.catalog.DeltaCatalog") \    .getOrCreate() data = [("Alice", 25), ("Bob", 30), ("Cathy", 28)]df = spark.createDataFrame(data, ["name", "age"]) # 创建 Delta 表df.write.format("delta").mode("overwrite").save("/tmp/delta_demo") # 读取 Delta 表read_df = spark.read.format("delta").load("/tmp/delta_demo")print("初始数据:")read_df.show() # 追加新数据new_data = [("David", 35)]new_df = spark.createDataFrame(new_data, ["name", "age"])new_df.write.format("delta").mode("append").save("/tmp/delta_demo") # 时间旅行：读取版本 0v0_df = spark.read.format("delta") \    .option("versionAsOf", "0") \    .load("/tmp/delta_demo")print("版本0的数据:")v0_df.show() # 删除操作from delta.tables import DeltaTabledelta_table = DeltaTable.forPath(spark, "/tmp/delta_demo")delta_table.delete(col("name") == "Bob")print("删除 Bob 后的数据:")spark.read.format("delta").load("/tmp/delta_demo").show() # Merge UPSERT 操作updates = [("Alice", 26), ("Eve", 22)]update_df = spark.createDataFrame(updates, ["name", "age"])delta_table.alias("t") \    .merge(update_df.alias("s"), "t.name = s.name") \    .whenMatchedUpdate(set={"age": "s.age"}) \    .whenNotMatchedInsertAll() \    .execute()print("Merge 后的数据:")spark.read.format("delta").load("/tmp/delta_demo").show()
目的：演示使用 PySpark 和 Delta Lake API 完成创建表、追加数据、时间旅行、条件删除和 UPSERT 操作。
  1. spark = SparkSession.builder...getOrCreate()创建 Spark 会话，并通过配置启用 Delta Lake 扩展。
  2. df.write.format("delta").mode("overwrite").save(...)以 Delta 格式将 DataFrame 写入指定路径，若表已存在则覆盖。
  3. .option("versionAsOf", "0")时间旅行关键参数，指定读取版本 0 的历史快照。
  4. DeltaTable.forPath(spark, "/tmp/delta_demo")通过表路径加载 Delta 表的句柄，用于后续操作。
  5. delta_table.delete(col("name") == "Bob")按条件删除数据行，底层通过事务日志和文件重写实现。
  6. .merge(update_df.alias("s"), "t.name = s.name")将更新表与目标表按关联键合并：匹配则更新，不匹配则插入。

常见误区

误区许多初学者认为只要数据文件写入是原子的（不会产生半截文件），数据湖就具备事务能力了。他们看到 HDFS 的 rename 操作是原子的，就以为 Hadoop 生态写文件不会出错。

正解原子性只是 ACID 中的一个属性。完整的事务还需要保证：多个文件操作要么全部成功要么全部回滚（原子性）、事务完成后数据必须满足约束（一致性）、并发事务互不干扰（隔离性）、提交后数据持久保存（持久性）。Delta Lake 的独到之处在于它通过事务日志统一协调所有文件操作，确保上述四个属性同时成立。单独的原子文件写入远没有达到事务级别。

为何常见：因为大多数编程语言中对单个文件的读写是原子的感觉根深蒂固，人们容易把文件系统层面的单个操作语义误当成数据库事务语义。

误区很多使用者认为时间旅行意味着数据湖中的所有历史版本都永久保留，可以无限回溯到任意早期版本。

正解Delta Lake 默认只保留最近 30 天（可通过配置调整）的事务日志和版本信息。超出保留期之后，旧版本的数据文件可能被清理（VACUUM），时间旅行到这些版本将不再可行。时间旅行需要同时保留日志和对应的数据文件，而过多的历史版本会占用大量存储，因此必须通过保留策略在“灵活回退”和“存储成本”之间取得平衡。

为何常见：因为 Git 的版本管理可以永久保留历史提交记录，人们类比到 Delta Lake，误以为版本保留也是无期限的。

误区有的学习者听说过 Hudi 的 MOR（读时合并）和 Copy-on-Write（写时复制）概念，将它们与 Delta Lake 的文件重写策略混为一谈。

正解Copy-on-Write 是在写入时直接重写文件——真正的实时更新；MOR 是写入时先写增量日志，读取时合并——牺牲读性能换取写放大。Delta Lake 采用的是 Copy-on-Write 风格：UPDATE 时重新生成包含最新数据的 Parquet 文件，并更新事务日志。它会自动合并小文件以优化读写性能，但不会像 MOR 那样增加一层额外的逻辑读取。

为何常见：因为三种表格式的技术实现都有各自的变异和优化，初学者容易混淆术语在具体引擎中的实现差异。

面试题

Q1. Delta Lake 最核心的设计创新是什么？

单选题 · easy

  • A.使用 Parquet 列式存储格式
  • B.引入了事务日志机制← 正确答案
  • C.支持 SQL 查询
  • D.使用 Hadoop HDFS 存储

答案：B。Delta Lake 的最核心创新是在数据文件之上增加了一层事务日志（Transaction Log），通过这层日志实现了 ACID 事务、时间旅行、Schema 演进等能力。Parquet 格式并非 Delta Lake 的发明，SQL 查询也早已存在。答案选 B。

Q2. 关于 Delta Lake 的 ACID 特性，下列说法正确的是？

单选题 · easy

  • A.原子性表示事务部分成功也没关系
  • B.一致性要求数据始终满足预设规则← 正确答案
  • C.隔离性意味着事务不能并发执行
  • D.持久性指数据可以随时删除

答案：B。一致性（Consistency）指事务完成后，数据必须满足所有预设规则。原子性要求事务全部成功或全部回滚，存在排除 A；隔离性指并发事务互不干扰而非禁止并发，排除 C；持久性要求提交后数据不丢失，排除 D。

Q3. 在 Delta Lake 中使用时间旅行读取版本 1 的数据，正确的 Option 是？

单选题 · mid

  • A..option("versionAsOf", "1")← 正确答案
  • B..option("asOfVersion", "1")
  • C..option("timestampAsOf", "1")
  • D..option("versionOf", "1")

答案：A。Delta Lake 的时间旅行支持按版本号读取，使用参数 versionAsOf，注意按时间戳读取使用的是 timestampAsOf 而非 timestamp 相关选项。选项 B、C、D 都是不存在的参数名。

Q4. Delta Lake 的事务日志采用什么存储格式？

单选题 · mid

  • A.Parquet
  • B.JSON← 正确答案
  • C.Avro
  • D.CSV

答案：B。Delta Lake 的事务日志以 JSON 格式存储在 _delta_log 目录中，每个事务对应一个 JSON 文件。如果包含列统计信息等增量化数据时，可能会生成额外的 Parquet 侧文件（如统计文件），但核心事务日志格式为 JSON。

Q5. Delta Lake 支持哪些数据操作原语？

多选题 · mid

  • A.MERGE← 正确答案
  • B.UPDATE← 正确答案
  • C.DELETE← 正确答案
  • D.TRUNCATE

答案：ABC。Delta Lake 核心支持 MERGE（UPSERT）、UPDATE（更新已有记录）和 DELETE（按条件删除）。TRUNCATE（清除全表数据）虽然可以通过删除所有文件来实现，但它不是 Delta Lake 的核心操作原语，使用场景也完全不同。答案选 A、B、C。

Q6. 关于 Schema 演进，以下说法正确的是？

单选题 · hard

  • A.修改列类型不需要任何条件
  • B.添加列时需要有默认值或允许为空← 正确答案
  • C.Schema演进需要完全重写所有数据文件
  • D.Delta Lake 不支持重命名列

答案：B。Schema 演进添加新列时，考虑到旧数据文件的兼容性，需要设置默认值或允许为空。如果新列既没有默认值也不允许为空，旧数据无法自动填充，演进将失败。修改列类型要满足类型转换的规则，并非无条件修改。选项 C、D 也都是错误的。

Q7. Delta Lake 的 Merge 操作中，WHEN MATCHED THEN UPDATE 的含义是？

单选题 · hard

  • A.关联键匹配则删除目标行
  • B.关联键匹配则更新目标行的指定字段← 正确答案
  • C.关联键不匹配则插入新行
  • D.关联键匹配则跳过该记录

答案：B。Merge 操作包含三个语义：WHEN MATCHED THEN UPDATE 表示匹配时更新目标行的指定列；WHEN NOT MATCHED THEN INSERT 表示不匹配时插入新行；WHEN MATCHED THEN DELETE 表示匹配时删除目标行。答案选 B。

Q8. 以下哪些陈述准确描述了 Delta Lake 与 Apache Iceberg 的设计差异？

多选题 · hard

  • A.Delta Lake 深度集成 Spark 生态← 正确答案
  • B.Iceberg 更强调多引擎中立性← 正确答案
  • C.Delta Lake 不支持 Flink
  • D.Iceberg 不支持 ACID 事务

答案：AB。Delta Lake 与 Spark 有深度集成；Iceberg 的核心理念是支持 Spark、Flink、Trino 等多种引擎；Delta Lake 也通过连接器支持 Flink，排除 C；Iceberg 同样支持 ACID 事务，排除 D。选 A、B。

Q9. 在流批一体架构中，Delta Lake 如何实现统一？

单选题 · mid

  • A.流任务和批任务读写不同的数据表
  • B.流任务写入一张表，批任务读取另一张表
  • C.流任务和批任务共用同一张 Delta 表读写数据← 正确答案
  • D.将流转换回批处理执行

答案：C。流批一体的核心是流处理和批处理共用同一张 Delta 表，读写的是同一个版本的数据。这是对“两套数据管道，数据对不上”问题的根本解法。

Q10. 以下哪项是 Delta Lake 文件优化（OPTIMIZE）操作的主要目的？

单选题 · hard

  • A.增加表的副本数量
  • B.合并小文件以提升查询效率← 正确答案
  • C.减少数据表的列数
  • D.将文件转换为 CSV 格式

答案：B。OPTIMIZE 操作的任务是合并大量小文件为更大的文件，从而减少文件数量，降低查询扫描时的开销，提升查询效率。它不会改变表的数据和结构。答案选 B。