Lakehouse：迈向低成本、无限扩展、无厂商锁定的可观测性架构？

本文字数：11526；估计阅读时间：29 分钟

作者：Melvyn Peignon & Dale McDiarmid

本文在公众号【ClickHouseInc】首发

TL;DR

借助 Apache Iceberg 和 Delta Lake 等开放表格式，Lakehouse 架构正在成为可观测性场景的可行选择。这类架构结合了 Parquet 的列式压缩与过滤能力，以及 schema 演进、快照机制和目录管理等关键特性。

不过，在大规模遥测（telemetry）数据处理中仍存在诸多挑战：如何在分区设计中平衡查询与写入、元数据快速膨胀、并发写入冲突、Parquet 在处理半结构化数据与点查询方面的限制、以及对象存储带来的延迟问题。值得庆幸的是，诸如 Liquid Clustering、Parquet 的新型 VARIANT 数据类型，以及新兴格式如 Lance 等技术，正逐步弥合这些差距。

ClickHouse 已具备对 Iceberg 和 Delta 表的查询与写入能力。用户开始探索在“热路径”上使用 ClickHouse，以实现高速写入与低延迟读取，同时将 Iceberg、Delta 等开放格式作为经济实用的长期存储方案。

Lakehouse 架构在可观测性场景的应用潜力

过去五年，企业在数据管理与分析方面经历了一场深刻变革。Apache Iceberg 和 Delta Lake 等开放表格式，为传统数据湖在分析与数仓场景下带来了结构化能力。这类格式推动了 Lakehouse 架构的诞生，使对象存储具备了与数据库相媲美的语义能力，同时保留其可扩展性和低成本优势。

数据湖曾让用户在灵活性与结构化之间难以两全，而如今，开放格式在简单文件之上构建出类表结构的抽象，使数据集合表现得更像数据库系统。它们减少了数据重复，消除了对特定厂商的依赖，并为原本杂乱的非结构化数据带来了数据库级别的治理与一致性。更重要的是，开放格式实现了计算与存储的彻底解耦，使得任何查询引擎都可以基于同一存储层运行分析任务。这样，用户便可根据不同的工作负载灵活选择最佳工具，而无需被绑定至某一平台或引擎。

如果你像我们一样，将可观测性视作另一类典型的数据问题，那么自然会提出一个问题：Lakehouse 架构及其所依赖的开放表格式，是否适用于可观测性场景？

换言之，这些格式能否满足可观测性所需的关键特性：高性能查询、适配半结构化事件的灵活 schema、卓越的压缩率、低成本的长期存储能力，以及对高吞吐数据写入的支撑能力？

在这篇文章中，我们将系统探讨 Lakehouse 架构所采用的开放表格式及其底层技术的优势与不足，同时分享我们对这一技术在可观测性领域未来发展的看法 —— 其中已有诸多令人振奋的新进展，让我们相信开放格式将在可观测性工作负载中扮演越来越重要的角色。

Lakehouse 架构在可观测性场景中的适用性

如今，越来越多的团队已将日志、追踪（traces）和指标（metrics）数据直接写入对象存储，以实现低成本的长期保留。而借助开放表格式，这些原始数据可以具备数据库般的语义，进而被 ClickHouse 等多种分析引擎直接查询 —— 无需厂商绑定、也无需将数据迁移至专用的可观测性系统中进行复制与重处理。理论上，这种方式不仅能降低计算资源成本，减少数据冗余，还能显著降低数据传输带来的网络开销，同时又保留了对象存储带来的成本优势。在本文接下来的部分，我们将从底层文件格式 Parquet 开始，逐步分析适用于可观测性负载的开放表格式所具备的关键技术特性。

Parquet：构建高效可观测性查询的列式基础

Apache Parquet 是为大规模数据分析任务设计的高效列式存储格式。它不同于传统数据库以行为单位存储数据，而是按列组织数据，使得查询任务只需读取所需字段 —— 这对于需要聚合与可视化的可观测性工作负载尤其合适。得益于其列式布局，Parquet 支持极高效的数据压缩。当数据有序或重复性高时，压缩效率尤为明显。每列内部，Parquet 还引入了多种数据感知型编码方式，如运行长度编码、字典编码、增量编码等，用以降低冗余并优化存储空间。

以网页分析数据为例

一个 Parquet 文件中，每列被分割为列块（column chunks），进一步划分为数据页面（pages），每个页面大小通常为几 MB，是数据读取的基本 I/O 单位。每个页面在写入时会使用如 ZSTD 或 Snappy 等算法进行块级压缩，从而显著降低存储占用与读取开销。

这些列块又被组织为行组（row groups），每个行组代表数据集的一部分横向切片。对于查询引擎而言，行组是并行处理的核心单元：多个线程或节点可并行读取多个行组。随着新一代引擎（如 ClickHouse 的 v2 读取器）的出现，Parquet 还支持跨列、跨文件的进一步并行化，尤其在宽表场景下可大幅提升性能。

Parquet 同时包含丰富的元数据与统计信息，使得引擎在读取前便可筛选出相关数据块，从而提升查询效率。例如，文件尾部保存了 schema、编码方式及列级 min/max 统计；列块中可能包含字典编码以加速筛选；数据页面中也可能包含 min/max 值以支持更细粒度的数据裁剪；此外，还支持在行组层级使用 Bloom Filter 来高效判断某值是否存在。

正是由于其列式结构、丰富元数据与现代压缩算法的组合，Parquet 具备了高压缩比、快速筛选与强大的并行处理能力。这些优势使其成为可观测性场景中海量数据扫描与聚合查询的理想存储格式。

开放表格式：以高效文件存储为基石构建的可观测性体系

Parquet 提供了大多数 lakehouse 系统的数据存储基础，但它本质上只是一个文件格式 —— 仅负责数据布局，并不具备对数据变更的管理能力，也无法协调并发写入。开放表格式如 Apache Iceberg 和 Delta Lake 构建在 Parquet 之上，引入了数据库级的关键表语义，包括快照（snapshot）、模式演进（schema evolution）、时间旅行（time travel）和原子提交（atomic commit）等。此外，这些格式还配套引入了目录服务（catalog），如 Unity、AWS Glue 和 Nessie，用于集中管理表的位置、版本以及 schema 历史。它们将原本松散分布的 Parquet 文件集合转化为结构一致、具备演化能力的表，从而形成真正可被查询引擎统一访问的数据集。

在本节讨论中，我们聚焦于可观测性场景中最相关的功能特点。在这类场景下，事务性保障并不是核心需求，且数据大多为不可变状态。虽然不同的表格式在技术实现上有所差异，但它们的设计目标是一致的。因此，为便于说明，我们主要以 Apache Iceberg 为例进行探讨。

Iceberg 表格式与目录机制

支持 schema（模式）演进

在可观测性数据中，遥测事件的结构变化频繁 —— 新字段、标签和嵌套属性不断被引入。表格式最重要的价值之一就是提供了对 schema 的灵活管理与演进能力。借助这一能力，数据结构可以随着时间自然演化，无需重写历史文件或通过自建元数据系统维护 schema 差异。如果没有表格式支持，查询引擎或开发者必须手动处理 schema 差异，动态适配查询逻辑。而采用 Iceberg 等表格式时，schema 版本信息被完整记录在元数据中，即便结构不断变化，历史数据依然可被一致查询。这大大简化了查询逻辑，提升了可观测性系统的健壮性与开发效率，远优于直接处理一堆独立的 Parquet 文件。

灵活的分区机制

表可以按时间、服务名称、地域等多种维度进行分区，从而在查询时快速定位目标数据。结合文件级和列级的统计信息，Iceberg 等表格式支持基于元数据的裁剪机制：查询引擎在实际读取 Parquet 文件之前，就能跳过无关的分区与文件，有效减少 I/O 开销与查询延迟。这种裁剪能力特别适用于面向时序数据和高维标签的可观测性场景，使得查询既快速又成本可控。

排序与合并

要实现高效查询，Lakehouse 系统依赖两项关键能力：数据的有序写入与小文件的有效合并。排序可确保相似值在物理上相邻存储，既提升压缩率，也增强列级统计信息的过滤效果。而过多的小文件则会带来明显的性能负担 —— 每个文件都需单独处理其元数据与读取逻辑，导致延迟上升与扫描效率下降。一旦排序不一致且缺乏合并策略，数据将逐渐碎片化，查询引擎不得不扫描大量冗余数据。

尽管在写入阶段实现数据排序理论上较为简单，实际操作常需额外系统支持。新数据需要在写入前完成批处理与排序，确保每个 Parquet 文件按分区键（如时间戳、服务名）对齐。这一过程往往借助 Kafka、Flink 或 Spark 等数据流引擎来缓冲并整理数据。

即使初始数据是有序写入的，随着新数据流入或迟到事件摄入，排序仍可能退化。为此，系统需定期执行合并操作（Compaction），将零散或无序的小文件重组为更大、排序良好的文件。这不仅有助于维持数据的物理聚集性与压缩效率，也优化查询性能。通常，合并由外部执行引擎（如 Spark、Athena）处理，或在托管平台如 Databricks 中以后台任务自动运行。

在配置层面，用户可设定目标文件数量、大小上下限，以及每次合并的总字节数，从而在性能与成本之间取得平衡。

ClickHouse 提供原生的批处理与自动合并能力。来自边缘设备或遥测采集器的写入请求会被自动聚合、排序后写入存储，确保数据按键聚集，从而实现高压缩率与高效筛选。系统内置的后台任务将持续将小文件合并为大文件，整个过程无需用户干预。

快照

表格式中的快照（snapshot）和时间旅行（time travel）功能，对构建可观测性管道尤为重要。快照记录数据集在某一时刻的完整状态，为分布式写入提供一致性视图。在处理失败、任务中断或需回溯分析时，快照机制可支持稳定的回滚与再处理。

表格式和对象存储

Lakehouse 架构之所以具备无限扩展能力，离不开云对象存储的支持。尽管表数据理论上可存于本地 SSD，但在实际部署中，它们几乎总托管在 Amazon S3、Azure Blob Storage 或 Google Cloud Storage 等对象存储服务中。对象存储提供了低成本、可长期保留的容量，完美契合大规模遥测与日志数据的需求。现代查询引擎（包括 ClickHouse）能够直接从对象存储中读取 Parquet 文件及其对应的表格式元数据。这种能力使得开放文件格式与云原生基础设施之间的结合，具备极强的灵活性与成本优势。

不过，尽管开放格式与对象存储天然兼容，这一架构在实践中仍存在一些现实限制 —— 我们将在下一节中进一步分析。

可观测性场景下使用开放表格式的现实挑战

分区策略的选择至关重要

在采用开放表格式时，分区方案直接决定了数据的物理布局与查询效率。合理分区能使引擎聚焦于所需数据子集，提升读取速度。ClickHouse 不仅支持分区，还支持设置主键，能够在更细粒度上进行排序与过滤。然而，如果分区粒度过细，会导致海量小文件产生，增加 I/O 与元数据负担；而分区过粗则导致全 表扫描负担沉重。用户常需借助外部工具手动处理这类问题，或依赖 Databricks、AWS S3 表等托管平台。尤其当迟到数据写入已有分区时，容易造成碎片化与性能下降，后续还需通过合并操作（compaction）恢复效率。相比之下，大多数分析型数据库内置了自动合并机制，可透明解决这些问题。

元数据规模增长带来的开销

随着写入量增大、schema 频繁变更，以及合并任务的进行，像 Iceberg 这样的表格式会持续生成新的元数据文件，包括 manifest、快照与文件列表。对于可观测性这类高写入场景而言，元数据结构极易膨胀至百万级条目，带来查询规划延迟、内存消耗上升与插入性能下降等一系列问题。控制元数据增长通常依赖定期合并 manifest 文件、快照过期与垃圾回收操作，这些过程不仅需要额外的计算资源，也增加了系统的运维复杂度。尽管行业对这些维护任务已有成熟实践，但其操作成本不容忽视，尤其在大规模部署场景下更是关键挑战。

并发写入瓶颈与协调成本

当前主流表格式通过乐观并发控制机制支持多客户端并行写入。每个写入者基于当前快照执行变更操作，最终由 catalog 系统进行原子提交。若存在冲突，写入者将重新尝试提交。这种机制为对象存储带来了接近数据库的隔离性，但在可观测性常见的高吞吐写入压力下，表的元数据指针成为性能瓶颈，频繁重试与提交失败成为常态。为缓解此问题，用户需采用批量写入、按分区并发写入以及定期合并小文件等方式。然而，即使有这些优化措施，想要扩展写入能力仍需更多手动调度与参数调优，远不如传统数据库由存储引擎自动完成那般高效。

Parquet 格式的天然局限

除了表格式本身的架构挑战，Parquet 作为底层存储格式在可观测性场景中也存在一些结构性限制。

支持半结构化数据

原本设计为静态列式文件格式的 Parquet，并不适合处理动态变更的数据类型。尽管在结构化分析中表现出色，但其紧耦合的类型系统与物理布局限制了类型演进能力，也使其在数据类型支持多样性上逊于现代数据库系统。

尤其在处理半结构化数据（如日志、事件）时问题尤为突出。Parquet 中嵌套结构（如 struct、LIST）通过定义层级与重复层级表示，必须顺序解码才能重建原始嵌套结构。为访问某个深层字段，往往需读取并解压整个页面 —— 这在查询 JSON 风格数据时极其低效。更麻烦的是，使用嵌套结构还要求用户提前定义 schema 且字段类型一致。一旦遇到新字段，还需更新表 schema，触发高开销的元数据操作。虽然 JSON 也可作为 byte array 存储，但这需要逐条解析内容，查询效率更低且扩展性差。

值得关注的是，Parquet 近期引入了 VARIANT 类型，未来有望缓解这些结构性瓶颈 —— 详见下节内容。

ClickHouse 与 Parquet 的差异

ClickHouse 在处理 JSON 数据方面拥有明显优势：在插入时，可将 JSON 字段自动拆解为类型明确的列，用户无需解析整个对象即可直接查询其中任意字段 —— 同时仍保留列式存储的压缩、索引与过滤性能。这为高效处理半结构化数据提供了关键能力。

擅长大规模扫描，但不适合点查

Parquet 从底层架构上是为高吞吐、顺序扫描而优化的，而非低延迟、随机访问。其数据通常以行组为单位进行压缩存储，每个页面    ·大小可达数十甚至数百 MB。即使查询仅需返回一条记录，查询引擎仍需定位对应行组、加载所涉列块，并解压整个页面（含字典）才能获取目标字段。相比之下，ClickHouse 内建内存索引，可精准定位目标块，实现快速点查。

这种差异对可观测性负载尤为关键。在日志或 trace 分析中，基于 trace_id、span_id 等唯一标识符进行高选择性点查十分常见。而 Parquet 的结构并不适配这一模式。

可用的优化方案诸如使用外部索引（如 Elasticsearch）、基于高基数字段分区、应用 Bloom Filter 等，但它们都存在明显的成本与权衡，如增加基础设施复杂度、生成小文件或压缩效率下降。

元数据体积膨胀

随着数据规模增长，Parquet 的元数据也可能迅速膨胀。每个文件尾部包含每列与每个行组的 schema、编码方式、统计信息等，尤其在宽表结构或使用较小行组时，单个 footer 可达几十 MB。

在对象存储上读取这些大尺寸元数据将显著影响查询启动延迟，且在并发读取多个文件时负担更甚。小行组虽有助于并行化与裁剪，但会放大 footer 成本；大行组则牺牲了并行与裁剪能力。

这种参数调优复杂且耗时，远超多数可观测性团队的精力投入范畴。

对象存储适配性差异

Parquet 在本地或分布式文件系统中表现良好，但在对象存储如 S3 中使用时，其架构劣势暴露无遗。读取一个 Parquet 文件通常需执行多轮请求：读取文件尾（footer）以获取 schema 与行组，再解析页面、列与字典元数据，最后才读取数据本身。

在 S3 这类高延迟环境中，这一系列操作会引发大量串行 HTTP 请求，形成严重的“请求放大效应”。同时，丰富的元数据虽然提升了裁剪能力，却也意味着在查询准备阶段必须下载和解析大量非数据字节。ClickHouse 通过异步 I/O、预读取与元数据缓存等机制在一定程度上缓解这些问题，但在可观测性这类需快速响应的场景下，Parquet 在对象存储中的访问瓶颈仍不可忽视。

新技术正逐步缓解 Lakehouse 在可观测性中的难题

尽管前文提到的诸多挑战复杂且具工程难度，但整个数据基础设施生态正在快速发展，推动诸多创新逐步落地。

表格式领域的关键创新

最令人期待的进展之一来自于对合并（compaction）与聚类（clustering）机制的持续优化。许多现代数据引擎开始将这些操作自动化，减少以往需依赖 Spark 等批处理框架手动执行的复杂操作。Databricks 提出的“液态聚类”（Liquid Clustering）就是其中的代表性技术，当前也正逐步影响更广泛的生态建设。与传统的全表重写不同，液态聚类通过后台增量聚类的方式，逐步优化数据排序，同时避免写入放大效应。这种方式既维持了数据的良好组织，也保持了高压缩率与高查询性能，关键在于其无需用户手动介入 —— 新写入数据也能快速响应查询请求。

另一方面，Iceberg 设计上并未支持稀疏主键或倒排索引，这类结构正是 ClickHouse 在实现精细过滤与跳过无效数据方面的关键机制。一些商业实现尝试通过引入外部或辅助索引来补齐这一短板，但这些方案多为闭源，缺乏通用标准。不过，近年来已有若干开源项目致力于补全这一生态空白，未来值得期待。

Parquet 文件格式的升级与替代探索

在文件格式层面，Parquet 也正在朝向支持更灵活数据模型演进。其中最大亮点是引入了 VARIANT 类型 —— 支持在单列中存储嵌套结构如对象（object）、数组（array）与标量（scalar）等灵活类型。这对可观测性中常见的 JSON 数据尤为关键。该类型支持结构元数据与字段值分离编码：字段名称采用字典编码存储在元数据列中，字段值则使用标准值列编码。这种机制不仅提高了对字段名称复用场景的压缩效率，也使得查询引擎可以跳过不相关字段，快速定位所需信息。更进一步，VARIANT 类型还引入了“shredding”机制 —— 将嵌套字段展开为独立列进行存储，从而显著提升列式扫描与过滤性能。这种方式本质上与 ClickHouse 在其 JSON 类型上所实现的列访问模式非常相似。尽管 VARIANT 功能仍处于早期阶段，尚未被广泛引擎支持，但它为 Parquet 处理稀疏、变化频繁的半结构化数据带来了极大希望。特别是在避免冗余页面读取、提升点查效率方面，有潜力突破当前 Parquet 查询瓶颈。

Variant 类型采用两级字典编码机制：字段名称以字典形式编码为元数据，从而优化了具有相同字段名的对象在存储上的效率。原始图示鸣谢：Andrew Lamb - https://andrew.nerdnetworks.org/speaking/

然而，这些改进并不能完全掩盖 Parquet 的设计局限。其原生为本地大文件扫描优化，并不适合对象存储环境中高延迟、小查询的场景。它缺乏数据库级的 I/O 减少策略，也无法像 ClickHouse 的 wide parts 机制那样支持独立列存储与极致压缩。

因此，对于既包含实时点查，又需大范围分析扫描的典型可观测性负载，Parquet 的行组与元数据架构很可能成为性能瓶颈。

新一代格式正在兴起，针对这些结构性不足，业界正开始构建新一代文件格式 —— 在保留 Parquet 优势的同时，重新设计压缩、存储与访问模型。例如 Vortex、FastLanes、BtrBlocks 与 Lance 均为代表性尝试，其中 Lance 正展现出快速的生态增长趋势，成为备受关注的后起之秀。

Lance 在数据布局与访问模型上采取了完全不同的设计理念：它不再依赖固定大小的行组（row group），而是将数据以独立 flush 的片段（fragment）方式写入。这种架构既支持高效的顺序扫描，也支持细粒度的随机读取，实质上打破了传统 Parquet 中行组的逻辑。

每个列可独立刷新页面，意味着对于写入频率高、字段动态变化大的列，不再需要与整个数据集保持对齐。同时，Lance 允许将页面大小根据底层对象存储（如 S3）的读取特性进行对齐优化，从而提升 range 请求效率。这种结构天然适配并发查询：依靠流水线式并行（pipeline parallelism）而非统一块处理，使查询引擎可以按需读取小型数据片段，无需解压大块连续数据，也避免了用户需要调优行组大小、元数据布局等复杂低层参数的问题。

鸣谢：本文中关于 LanceDB 优势的图片均来自 https://blog.lancedb.com/lance-v2

Lance 还摒弃了 Parquet 封闭僵化的编码机制，转而采用插件化架构。编码策略与统计信息作为扩展模块存在，底层数据以原始字节形式存储，具体的（编/解码）逻辑由插件决定。这种机制允许开发者轻松接入新的压缩算法或索引策略，而无需修改文件格式本身或阅读器逻辑。例如，字段字典、跳跃表（skip table）等元数据可以在列级或页面级灵活存放，其中列级存储更适用于高选择性、点查类查询。

鸣谢：本文中关于 LanceDB 优势的图片均来自 https://blog.lancedb.com/lance-v2

虽然 Lance 目前仍处于早期发展阶段，其是否会成为可观测性领域的主流格式尚不可知，但它提出的诸多理念令人眼前一亮。它与其他新兴文件格式一样，正尝试从根本上解决传统列式文件在面向云原生、半结构化、高并发读写场景中的短板。这些新格式尚未经历大规模生产可观测性系统的全面考验，真正的关键将是查询引擎能否保持开放、去格式绑定（format-agnostic）的架构特性 —— 这样才能释放存储格式的创新活力，让技术更优者自然胜出。

ClickHouse 与开放表格式

开放表格式正日益成为可观测性系统中不可或缺的一环 —— 它们为海量遥测数据提供了低成本、可长期保留的开放式存储能力。ClickHouse 在这场架构变革中具备天然优势。作为一款已在大规模可观测性场景中成熟应用的分析型数据库，ClickHouse 集成了快速写入、高效压缩与亚秒级查询性能，是与开放表格式融合的理想平台。

ClickHouse 多年来已支持直接查询 Parquet 文件，并持续优化其读取器性能。最新版读取器支持在行组内部实现列级并行 —— 同一行组中多个列可同时读取，极大提高了宽表查询吞吐量。此外，该读取器还能智能合并 I/O 请求，将多个小范围的读取操作整合为更大范围请求，尤其在 S3 等高延迟对象存储场景下表现出色。ClickHouse 可提前声明所需读取范围，减少请求次数，提升数据拉取效率。

在独立的 ClickBench 基准测试中，ClickHouse 展现了其在 Parquet 数据读取场景下的出色性能。

更进一步，ClickHouse 正积极扩展对表目录与开放格式的支持：不仅可通过 AWS Glue、Unity Catalog、LakeKeeper 和 Nessie 等目录服务查询数据，还能将其中的 Iceberg 和 Delta Lake 表直接作为 ClickHouse 数据库中的常规表使用。

CREATE DATABASE unity
ENGINE = DataLakeCatalog('https://.cloud.databricks.com/api/2.1/unity-catalog/iceberg')
SETTINGS catalog_type = 'rest', catalog_credential = ':', warehouse = 'workspace',
oauth_server_uri = 'https://.cloud.databricks.com/oidc/v1/token', auth_scope = 'all-apis,sql'

这意味着现有的可观测性工具链 —— 例如 ClickStack —— 可无需修改即可直接与这些表交互。

此外，ClickHouse 近期也已原生支持向 Iceberg 与 Delta Lake 表写入数据，并持续增强其功能覆盖：包括基于分区与统计信息的高效查询裁剪、并发读取、时间版本回溯（time travel）与删除操作等。这让 ClickHouse 不仅可作为查询引擎，也能作为写入端接入开放格式，为可观测性系统引入数据库级别的完整读写能力。

在实践中，部分用户已采用“双写架构”来兼顾冷热数据需求：将遥测数据同时写入 ClickHouse 的 MergeTree 表以支撑实时分析，同时写入 Iceberg 或 Delta Lake 表以实现长期归档存储 —— 即热数据用于即时可视化与告警，冷数据则以开放格式高效存档，供未来回溯分析使用。

MergeTree 引擎兼顾了 lakehouse 灵活性与数据库性能的统一模型。ClickHouse 的 MergeTree 引擎融合了 lakehouse 架构与开放表格式的诸多优势，同时在可观测性场景中有效规避并简化了其运维难点。它将多项关键能力整合在一个系统中，包括：自动后台合并（compaction），保持数据局部性；稀疏索引（sparse indexing），加速高选择性查询； JSON 支持的 schema-on-write（写时结构定义）；生命周期管理（lifecycle management）。所有这一切都无需依赖外部协调器或手动优化。MergeTree 的列式结构天然具备出色压缩率，且原生支持 S3，使得低成本的长期存储成为现实。同时，其内建的写入与读取隔离机制，确保了在高并发写入场景下仍能提供稳定的查询响应。

相比之下，开放表格式提供了基于对象存储的持久性与经济性。因此，许多企业（如 Netflix）采用“双写架构”：遥测数据一份写入 ClickHouse 实时处理，一份写入开放格式供后续归档分析。然而这种模式也带来了重复写入与复杂数据管理等效率问题。（视频：https://www.youtube.com/watch?v=64TFG_Qt5r4&feature=youtu.be）

展望未来：统一表模型的愿景，ClickHouse 正在构建一个未来架构 —— 让开放表格式与数据库表在使用上实现完全融合。在这一模型中，用户操作一个 Iceberg 或 Delta 表时，其体验将与使用 MergeTree 表完全一致。包括物化视图、联合查询、时间旅行等数据库级能力都将开箱即用。

这意味着用户不再需要在开放性与性能之间二选一。底层数据以开放格式存储，而 ClickHouse 作为查询与写入引擎，为其注入数据库级的交互能力与性能优化。存储格式退居为实现细节，数据布局与访问路径由引擎透明调度。这一融合模型将为大规模可观测性系统带来真正的“两全其美” —— 既拥有开放格式的可移植性、生态兼容性与成本优势，又具备 ClickHouse 在 PB 级别实战中验证过的高吞吐、低延迟查询能力。

总结：

Lakehouse 格式正在重塑可观测性数据架构

开放表格式正在重构可观测性数据的存储与访问方式。它们开放、可扩展，并越来越多地成为查询引擎之间的互操作桥梁。尽管目前在性能、元数据治理、运维简化方面仍存在挑战，但围绕文件格式、表规范与查询引擎的创新进展迅速。随着生态系统逐渐成熟，ClickHouse 这类分析型数据库正处于理想位置 —— 在对象存储的海量可扩展性与可观测性所需的实时性能之间架起桥梁。数据库与开放表格式的融合将为用户带来极具吸引力的技术栈组合：湖存储的开放与成本效益，融合数据库引擎的速度、可靠性与易用性。

值得一提的是，Cloudflare 近期宣布，其 R2 对象存储已支持通过 SQL 查询访问数据，未来还将与 Logpush 深度集成，使用户能够在 Cloudflare 平台内原生完成日志的提取、转化与分析操作 —— 这标志着 lakehouse 在可观测性领域的实用性进一步落地。

征稿启示

面向社区长期正文，文章内容包括但不限于关于 ClickHouse 的技术研究、项目实践和创新做法等。建议行文风格干货输出&图文并茂。质量合格的文章将会发布在本公众号，优秀者也有机会推荐到 ClickHouse 官网。请将文章稿件的 WORD 版本发邮件至：Tracy.Wang@clickhouse.com