数据工程面试：如何评估并迁移到 Delta Lake Liquid Clustering？
题目与场景
你负责一张按 tenantid、orderdate 分区并长期使用 Z-Ordering 的 Delta Lake 订单事实表。租户数量增长后，小租户查询仍扫描大量文件；团队想改用 Liquid Clustering。请说明如何评估、迁移、验证和回滚，并给出你会观察的指标。
面试官考察点
- 能否从真实过滤条件和文件布局诊断问题，而不是把新特性当作银弹。
- 能否区分分区、Z-Ordering 与 Liquid Clustering 的兼容边界。
- 能否设计小范围迁移、增量维护、全量重写和回滚护栏。
- 能否用扫描字节数、文件数、p95 延迟和成本证明收益。
先问清楚的澄清问题
- 主要查询是否稳定过滤
tenantid、时间范围或customerid，谓词选择性如何？ - 当前表的 Delta Lake、Spark/Databricks 运行时、读写客户端版本是否支持 Liquid Clustering？
- 现有分区和 Z-Ordering 的维护频率、单文件大小、近两周扫描字节数与 p95 延迟是多少？
- 是否允许后台
OPTIMIZE带来的额外计算，是否有低峰窗口和回滚副本？
30 秒回答示范
我会先用查询日志确认最常用且选择性高的过滤列，再用一张影子表做两周对照。Liquid Clustering 可以在不重写已有数据的情况下改变后续布局，但它与传统分区和 Z-Ordering 不能同时作为布局方案，所以要先确认版本、协议和下游客户端。迁移后按批执行增量 OPTIMIZE，必要时用 OPTIMIZE FULL 覆盖历史数据；比较同口径查询的扫描字节数、文件数、p95、失败率和成本。只有收益稳定且写入、并发、回滚都通过，才逐步扩大范围。
深入拆解
1. 先建立工作负载画像
把最近两周查询按模板聚合，记录过滤列组合、时间范围、扫描文件数、扫描字节数、返回行数、p50/p95 延迟和执行成本。若查询常带 tenant_id，但租户大小差异很大，单纯按日期分区可能让小租户仍命中许多文件。若谓词高度漂移，固定聚类列的收益可能不稳定，应先保留现状并补充观测。
2. 选择聚类列并控制列数
优先选择高频、选择性高、能被数据跳过机制利用的过滤列；把低频或高基数但几乎不出现在谓词中的列放入候选而非直接上线。Liquid Clustering 最多支持四个聚类列，列越多不代表越快，还会增加布局维护成本。用离线回放比较两到三个候选组合，避免只看单条“最佳”查询。
3. 设计迁移边界和兼容性检查
官方文档说明 Liquid Clustering 需要受支持的 Delta Lake 版本；现有表启用路径也随版本变化。启用前检查读写引擎、协议升级影响、流式写入、增量读取、备份工具和旧客户端。Liquid Clustering 不与传统分区或 Z-Ordering 组合使用，因此迁移计划要明确停止旧维护任务，并在影子表验证旧消费者。
4. 先增量维护，再决定是否全量重写
改变聚类列不会自动重写已有数据；新写入和后续优化才会按新布局整理。先在影子表或低风险表上启用并运行增量 OPTIMIZE，观察新增数据的文件跳过效果。历史数据仍是主要扫描来源时，再安排 OPTIMIZE FULL，并把计算成本、锁竞争和低峰窗口纳入变更评审。
CREATE TABLE fact_orders (
tenant_id STRING,
order_date DATE,
customer_id STRING,
amount DECIMAL(18, 2)
) USING DELTA
CLUSTER BY (tenant_id, order_date);
OPTIMIZE fact_orders;
ALTER TABLE fact_orders CLUSTER BY (tenant_id, customer_id);
OPTIMIZE fact_orders FULL;5. 用可复现基线验证收益
固定同一批查询、数据快照、并发度和缓存条件，比较迁移前后扫描文件数、扫描字节数、p50/p95 延迟、失败率、写入吞吐和每次查询成本。示例验收门槛可以是扫描字节数下降 30%、p95 下降 20%，且写入成本增加不超过 10%；这些是项目示例，必须根据基线调整。还要验证时间范围查询、跨租户查询、回填和并发优化，避免只优化一种路径。
6. 设置回滚、治理和持续监控
保留原表快照或影子表，先用小流量读切换，再逐步扩大。记录聚类列、版本、优化批次和指标，给旧客户端设置兼容检查。若 p95、写入延迟或成本连续越过阈值，暂停扩大范围，恢复读路由并停止新布局维护；回滚后重新分析谓词和数据倾斜，而不是立即换另一组列。
一份更完整的强回答
我会从查询日志建立基线，确认 tenant_id 和时间过滤是否真的主导扫描，再用两到三个聚类列组合做影子表回放。上线前核对 Delta/Spark 版本、协议、流式读写和旧客户端，因为 Liquid Clustering 与分区、Z-Ordering 是替代关系，且最多四列。迁移先覆盖新数据并增量 OPTIMIZE；若历史文件仍造成扫描，再在低峰执行 OPTIMIZE FULL。验收同时看扫描字节数、文件数、p95、成本、写入吞吐和失败率，并保留快照、暂停开关和读路由回退。连续两个观测窗口达标后再扩大范围，任何指标越界都触发暂停和复盘。
常见失分点
- 只背诵“Liquid Clustering 更快”，没有查询基线和对照组。
- 忽略它与分区、Z-Ordering 的不兼容，继续运行旧维护任务。
- 以为修改聚类列会立即重写全部历史数据，没有安排增量或全量优化。
- 只报平均延迟，不看扫描字节数、p95、写入成本和数据倾斜。
- 没有版本、协议、旧客户端和回滚检查，就直接在生产表执行。
追问与延伸
追问一：为什么不把四个常用列全部放进去？
列数上限不是目标。过多列会增加布局维护成本，且不同查询组合可能互相稀释收益；应按谓词频率、选择性和回放结果选最小有效集合。
追问二：启用后旧数据多久会变好？
不能直接承诺时间。已有数据不会因改列自动全部重写；要看增量 OPTIMIZE 覆盖速度，历史占比高时再评估 OPTIMIZE FULL 的窗口和成本。
追问三：如何处理租户极度倾斜？
按租户分层回放，分别观察大租户、小租户和跨租户查询。必要时调整列组合或查询路由，并把最差分位而非总体平均作为门槛。
追问四：什么信号说明应该停止迁移？
若扫描字节数没有稳定下降、p95 或写入成本持续恶化、旧客户端不兼容，或回滚演练失败，就暂停扩大范围，恢复原布局维护并重新做工作负载分析。