<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>时间旅行 on PlumePHP</title><link>https://plumephp.com/tags/%E6%97%B6%E9%97%B4%E6%97%85%E8%A1%8C/</link><description>Recent content in 时间旅行 on PlumePHP</description><generator>Hugo</generator><language>zh-CN</language><lastBuildDate>Wed, 30 Sep 2026 09:00:00 +0800</lastBuildDate><atom:link href="https://plumephp.com/tags/%E6%97%B6%E9%97%B4%E6%97%85%E8%A1%8C/index.xml" rel="self" type="application/rss+xml"/><item><title>Apache Iceberg 深度剖析：元数据层、ACID 与表优化</title><link>https://plumephp.com/data-lakehouse-iceberg/</link><pubDate>Wed, 30 Sep 2026 09:00:00 +0800</pubDate><guid>https://plumephp.com/data-lakehouse-iceberg/</guid><description>&lt;h2 id="引言"&gt;引言&lt;/h2&gt;
&lt;p&gt;大多数团队用上 Iceberg，是因为它的 SQL 接口足够友好：&lt;code&gt;MERGE INTO&lt;/code&gt;、&lt;code&gt;VERSION AS OF&lt;/code&gt;、&lt;code&gt;CALL rewrite_data_files&lt;/code&gt;。但 Iceberg 之所以能在廉价对象存储上重建数仓的可靠性，靠的不是 SQL 语法，而是一套&lt;strong&gt;严谨的元数据模型&lt;/strong&gt;。理解这层模型，你才能解释三个常被忽略的问题：为什么并发写不会互相污染？为什么小文件总会拖慢查询？为什么优化任务要做了一次又一次？&lt;/p&gt;</description></item></channel></rss>