文件上的数据怎样获得可靠的表能力？
从 Files + Metadata / Table Layer 出发，把 Schema Evolution、Atomic Commit、Snapshot、Version 和 Time Travel 连成一个问题链。
一批手机银行事件已经写进 Lake
文件上的数据怎样获得可靠的表能力？
文件可以被 SQL 引擎读取，但今天的读者还要知道当前 Schema、正式版本和失败写入是否可见。一次加工准备写 10 个文件，第 6 个文件失败时，半份新数据不能悄悄出现在结果里。
文件负责承载字节，谁负责说明这一组文件现在代表哪张表？
核心概念
Table Layer：把文件组织成可管理的表
文件是物理承载，Table Layer 通过 Metadata 说明 Schema、文件集合和表状态，帮助读者看到完整提交并定位历史版本。
“能读”还回答不了五个问题
手机银行事件的 v1 有 event_id、customer_id、event_type 和 event_time。下一批事件需要增加 channel。把新文件放进目录很容易，但读取方仍然要猜当前 Schema，确认哪些文件属于正式结果，并判断写入是否完整。
如果加工任务在第 6 个文件失败，普通文件目录可能同时留下前 5 个新文件。读者看到的内容就不再对应一个清楚的表状态；发生误加工后，也没有天然的旧状态可供回看。
- Schema Evolution 让字段变化成为一次明确的表变化。
- Atomic Commit 让整批更新整体可见或完全不可见。
- Snapshot / Version History 让表的不同状态可以被命名和定位。
10-3 · Snapshot Experiment
让一次 Commit 产生可回看的表状态
先模拟第 6 个文件失败，确认上一版仍然可见；再 Commit v2，观察 channel 如何进入 Schema、Snapshot 如何形成 Version History，并选择 v1 进行 Time Travel。
正在加载交互实验…
四个词描述的是一条因果链
Schema Evolution 说明表结构发生了变化。Atomic Commit 规定这次变化和新文件如何一起发布：第 6 个文件失败时，读者仍然看到旧 Table State。Commit 成功后，系统产生一个新的 Snapshot。
多个 Snapshot 排成 Version History，Time Travel 就有了明确的读取目标。“今天发现加工结果有问题，看看修改之前是什么状态”因此成为一次有依据的查询，不是依赖文件名猜测。