ClickHouse 列存原理与写入路径与复制机制

• 列存：每列独立文件存储
• 查询只读取所需列（列裁剪）
• 压缩（LZ4/ZSTD）与向量化执行

ClickHouse 采用列式存储，数据按列独立文件存储，每列的数据在磁盘上连续存放。查询时只读取查询涉及的列（列裁剪），避免读无关列，大幅减少 IO。列数据连续性好，天然适合压缩：LZ4 压缩快、ZSTD 压缩率高，配合列内数据相似性获得高压缩比。同时列式数据适合 SIMD 向量化执行，一次处理一批数据，减少指令开销，实现高吞吐分析。

列存的核心优势是「只读需要的列 + 高压缩 + 向量化」。分析查询通常只访问少量列、扫描大量行，列存能把 IO 与技术开销降到最低。压缩比列存高，因为同列数据类型相同、值相近。向量化逐批处理列数据，利用现代 CPU。三者叠加使 ClickHouse 在分析场景吞吐远超行存。

• INSERT 生成 part 目录
• 后台 merge 合并小 part
• 逐行写入导致 part 过多、性能差

ClickHouse 的 INSERT 会把一批数据作为一个 block 写入，生成一个新的 part 目录（不可变数据段）。后台会把多个小 part 合并成大 part。单次插入的行数越多，part 越少、越大；若逐行（或小批量）插入，会产生大量小 part，合并压力激增、查询时需扫描多个 part，性能下降。因此建议单次 INSERT 至少 1000 行（通常更大），减少 part 数量。

ClickHouse 的分区/part 模型决定了「写入越批量越好」。一个小 part 的元数据与索引开销是固定的，part 过多会拖慢查询与合并。批量写入（如 1000 行以上）能把行数摊薄到固定开销上，显著提升写入与查询性能。配合 async_insert 或 Buffer 引擎可缓冲小写入。避免逐行提交是 ClickHouse 写入的最佳实践。

• ReplicatedMergeTree 通过 ZooKeeper/Keeper 协调
• part 日志与 mutation 同步
• 多副本最终一致

ReplicatedMergeTree 通过 ZooKeeper（或 ClickHouse Keeper）维护副本间的协调：每个新写入的 part 会登记到 ZooKeeper 的日志中，其他副本检测到后从源副本拉取该 part 并应用，实现数据同步。mutation（如 UPDATE/DELETE）也通过协调机制在各副本间执行。多副本写入时，各副本插入的 part 通过协调去重与同步，最终所有副本达到一致的 part 集合，实现最终一致。

复制机制的核心是「ZooKeeper 协调 + part 日志 + 异步拉取」。写入先落到一个副本，再通过日志广播给其他副本，因此是异步的，存在短暂延迟，但最终一致。ZooKeeper/Keeper 的可用性决定复制可用性。副本间通过 part 去重（相同 part 不重复应用）保证不重不丢。生产常用 ClickHouse Keeper 降低运维成本。

• INSERT 写入临时 part
• 后台 merge 合并到最终分区
• part 生命周期

MergeTree 写入路径：INSERT 的数据先排序并构建成一个临时 part（位于临时目录或目标分区），随后通过后台任务把该 part 落到目标分区。多个小 part 由后台 merge 任务合并成更大的 part，最终形成稳定的分区数据。part 是不可变的，合并生成新 part 后旧 part 被删除。整个流程是异步的，保证了高吞吐写入。

写入路径的关键是「先落小 part，再后台合并」。这样写入无需等待磁盘整理，吞吐高。临时 part 到最终分区的过渡由后台完成。merge 是不可变数据段的重组，减少 part 数量、优化查询。理解 part 生命周期（写入→合并→清理）是理解 MergeTree 存储模型的基础。

• PARTITION BY 分区与分区裁剪
• DETACH/ATTACH PARTITION
• DROP PARTITION 删除数据

PARTITION BY 把数据按表达式划分为逻辑分区，每个分区对应一组 part。查询带分区键等值或范围条件时进行分区裁剪，跳过不相关分区，提升效率。part 生命周期管理：可用 ALTER TABLE ... DETACH PARTITION 把分区从表分离（数据保留但不可见），ATTACH PARTITION 重新挂载；DROP PARTITION 物理删除整个分区数据，适合按时间清理历史数据。

分区既是查询优化手段（分区裁剪），也是数据管理单元（按分区删除/分离）。DROP PARTITION 高效清理大范围数据，DETACH 用于备份或修复。生命周期管理需配合 TTL 与存储策略。分区粒度要权衡裁剪效率与 part 数量。

• LowCardinality：低基数（重复值多）
• Delta：单调递增/规律数据
• DoubleDelta：二阶差分稳定

各编码针对不同数据分布：LowCardinality 适合低基数（重复值多）的列，用字典编码大幅压缩；Delta 编码存储相邻值的差值，适合单调递增或规律变化的数据；DoubleDelta 存储二阶差分，适合变化率稳定的时序数据；Gorilla 针对时序浮点数据，结合 XOR 与前缀压缩，压缩率高。这些编码先压缩列内数据，再配合 LZ4/ZSTD 做块级压缩，双重压缩提升压缩比。

编码选择取决于数据分布。LowCardinality 对枚举/重复值效果显著；Delta/DoubleDelta 对时间序列有序数据有效；Gorilla 对高精度浮点时序最优。编码与 LZ4/ZSTD 是不同层级的压缩：编码处理列内相关性，块压缩处理整体冗余。正确选择编码可显著降低存储与 IO。

• async_insert 异步批量写入
• Buffer 引擎缓冲后批量落盘
• 可见性延迟与丢数据风险

async_insert 把多个小 INSERT 异步合并成较大的批量，再一次性写入生成大 part，从而减少 part 数量、提升写入吞吐。Buffer 引擎在内存中缓冲插入数据，按时间或行数阈值把缓冲批量写入目标表，同样减少小 part。代价是可见性延迟：异步/缓冲的数据在落盘前可能不可见；且若节点崩溃，缓冲中未落盘的数据可能丢失，存在丢数据风险。

缓冲是「吞吐 vs 实时性/持久性」的权衡。async_insert 与 Buffer 用内存缓冲换取更少 part 与更高吞吐，但引入数据可见延迟与崩溃丢失风险。对实时性要求高或数据不可丢的场景需谨慎，或配置可靠的 flush 策略。生产上按数据量与实时性需求选择缓冲策略。

• 稀疏主键索引：每 8192 行一个 mark
• 跳数索引：minmax/set/bloom_filter
• 二者协同过滤

稀疏主键索引按 index_granularity（默认 8192 行）生成一个 mark，记录每个 granule 的主键范围，用于按主键条件裁剪数据范围。跳数索引（minmax/set/bloom_filter）针对非主键列建立，minmax 记录列值的 min/max，set 记录去重值集合，bloom_filter 用布隆过滤器判断是否存在，用于过滤数据块。主键索引负责主键条件裁剪，跳数索引负责非主键列裁剪，两者协同多级过滤，减少读取数据量。

稀疏主键索引只能高效处理主键前缀条件，跳数索引补充了非主键列的过滤能力。二者是「不同粒度、不同列」的过滤：主键索引定位 granule 范围，跳数索引在 granule 内进一步过滤。协同使用能最大化裁剪，减少扫描。跳数索引有构建与存储开销，需选择性建立。

• Kafka 引擎表消费 + 物化视图写入
• 实时摄入架构
• 延迟特征

实时摄入架构：建 Kafka 引擎表作为消费通道，通过物化视图把 Kafka 数据写入目标 MergeTree 表。Kafka 引擎表持续消费消息，物化视图在每次消费到 block 时触发写入目标表。延迟特征：消息从 Kafka 到可查询的目标表存在一定延迟，取决于消费批次大小、物化视图写入速度与目标表合并；通常为秒级到亚秒级，非毫秒级实时。

该架构是 ClickHouse 实时数据摄入的标准模式。延迟主要由消费粒度与写入链路决定：Kafka 消费按 block 批量，物化视图同步写入。目标表可用 ReplacingMergeTree 等做去重。相比手动定时导入，该架构实现近乎实时。需监控消费延迟与目标表写入压力。

• Projection：表内物理预聚合，透明加速
• 物化视图：独立目标表，需显式查询
• 性能与维护差异

Projection 是表内定义的物理预聚合结构，ClickHouse 在写入时自动维护，查询时优化器自动选择使用投影，对用户透明，无需改查询。物化视图是独立的目标表，由源表 INSERT 触发写入，查询需显式指向目标表（或通过视图）。Projection 维护简单、透明，但增加写入与存储开销；物化视图更灵活但需显式管理。

Projection 适合「对既有查询透明加速」的场景，优化器自动路由；物化视图适合「需要独立聚合表、可被多查询复用」的场景。Projection 的预聚合随写入自动维护，但冗余存储与写入开销需权衡。物化视图目标表可独立优化（如 TTL、分区）。两者按查询透明性与灵活性需求选择。

• 副本通过 ZooKeeper 同步 part
• 冲突解决（part 去重）
• 最终一致

ReplicatedMergeTree 各副本通过 ZooKeeper 协调同步 part：新 part 写入后登记到 ZooKeeper 日志，其他副本拉取并应用。冲突解决主要通过 part 去重：多个副本可能同时写入同一数据，通过 part 的块校验和（checksum）与日志去重，避免重复应用同一 part。不同副本对同一 part 的写入通过协调保证只应用一次，最终各副本 part 集合一致（最终一致）。

副本同步的核心是「日志 + 拉取 + 去重」。冲突主要来自并发写入同一 part 或数据重复，ZooKeeper 协调 + 校验和去重保证不重不丢。副本间出现落后的副本会从健康副本追赶。理解同步与去重机制是保障副本一致性的关键。

• 向量化执行：SIMD 批量处理
• 列裁剪：只读所需列
• 分区裁剪：跳过无关分区

三者协同减少查询开销：分区裁剪在分区层面跳过无关分区，减少扫描范围；列裁剪只读取查询涉及的列，减少列 IO；向量化执行对读取的列数据用 SIMD 批量处理，减少指令与解释开销。协同顺序为：分区裁剪定范围 → 列裁剪定列 → 向量化执行计算。三者叠加使查询在分析场景高效。

协同的关键是「层层减少数据量、批量化处理」。分区裁剪与列裁剪解决 IO 问题，向量化解决计算问题。分析查询扫描大量行、少量列，正好契合这三者的优势。相比行存，列存 + 向量化 + 裁剪是 ClickHouse 高吞吐的核心。

• 每个 part 含 primary.idx 主键索引
• 跳数索引辅助过滤
• merge 合并 part 并重建索引

每个 part 目录包含 primary.idx（主键稀疏索引）、标记文件（marks）与列数据文件。primary.idx 记录每个 granule 的主键值用于裁剪。跳数索引（skip index）作为辅助索引，在 part 内进一步过滤非主键列。merge 操作把多个 part 合并，生成新 part 并重建其 primary.idx 与跳数索引，合并后索引更紧凑。索引在 part 层面维护，随 part 更新。

索引是 part 的一部分，随 part 的创建与合并而重建。primary.idx 提供主键裁剪，跳数索引补充非主键过滤。merge 把分散的 part 合并，减少 part 数量、压缩索引、提升查询效率。理解 part 与索引的关系是理解查询裁剪与存储布局的基础。

• 块校验和 (checksum) 去重
• 幂等写入原理
• 防止重复插入

ClickHouse 在插入时对每个数据块计算校验和（checksum），并登记到 ZooKeeper。当再次插入相同数据块时，通过校验和匹配可识别为重复，从而去重，实现幂等写入。这在 ReplicatedMergeTree 中尤为重要：同一块数据在多个副本间或重试时不会重复应用。幂等写入防止因网络重试或副本协调导致的重复数据。

块校验和去重是 ClickHouse 幂等写入的基础。通过记录块 ID 与校验和，系统能识别并跳过重复插入。这保证了重试过程中的数据正确性。但幂等只对「完全相同的数据块」有效，若业务层生成不同块 ID 则需自行去重。理解幂等机制对构建可靠写入链路很重要。

• 轻量删除：标记行（_row_exists 掩码列），查询时过滤，后台 merge 物理清理
• 普通 mutation：重写整个 part
• 删除量级与实时可见性取舍

轻量级删除（23.3+）通过内部 _row_exists 掩码列标记被删除的行，查询时过滤这些行，物理删除由后台 merge 完成，无需重写整个 part，删除开销小、速度快，适合大量小规模删除。ALTER TABLE ... DELETE（普通 mutation）会重写整个 part，把符合条件的行物理删除，删除量大但修改后立即生效、实时可见。取舍上：轻量删除适合海量小删除、但删除行在 merge 前仍占用空间且查询需过滤；普通 mutation 删除实时可见但重写 part 成本高，适合大批量删除。

两者本质是「延迟物理清理 vs 立即物理清理」。轻量删除用掩码标记，把物理清理推迟到 merge，降低删除的即时成本，但牺牲了空间释放与部分可见性。普通 mutation 立即重写，实时可见但 I/O 高。按删除量级与实时性需求选择：海量小删除用轻量删除，大批量一次性删除用 mutation。

• Distributed 表按 sharding_key 分发 INSERT 到本地表
• 缓冲机制（async）
• 故障重试与不重不丢

Distributed 表把 INSERT 数据按 sharding_key 分发到各分片的本地表。写入可配置为异步缓冲（async_insert / 异步分发），数据先在本节点缓冲，再批量发送到目标分片。节点故障或重试时，通过分布式表内部的任务队列与重试机制，把未成功写入的数据重新发送；配合块去重（校验和）避免重复，保证不重不丢。但若节点永久故障且缓冲未持久化，可能丢失未发送数据。

Distributed 表的不重不丢依赖「任务队列 + 重试 + 去重」。异步分发把数据缓冲，故障时重试；去重校验和防止重复。但缓冲在内存时，节点崩溃可能丢失。因此关键数据需配置持久化缓冲或接受容量风险。理解分发与缓冲机制是保障分布式写入可靠性的关键。

• 读副本时避免未同步 part
• replica 延迟影响
• load_balancing 配置

ReplicatedMergeTree 读副本时，通过 ZooKeeper 已知各副本的 part 集合，查询会优先选择数据完整的副本，避免读到未同步的旧 part。若某副本 parts 延迟，可通过 load_balancing 配置（如 nearest_hostname、in_order、random）选择读取的副本，避免把查询路由到数据滞后的副本。replica 延迟越大，读取到不一致数据的风险越高，因此需保证副本同步并及时处理延迟副本。

读一致性依赖「副本选择 + 同步状态」。查询应选择 parts 集合最新的健康副本，避免读旧数据。load_balancing 控制副本选择策略，可偏向最健康副本。若副本长期滞后，读一致性受影响。生产上需监控副本延迟并触发追赶或修复。

• part 不可变，mutation 重写 part
• Mutation 异步执行队列
• 对写入吞吐与查询一致性的影响

ClickHouse 的 part 是不可变的数据段，因此 UPDATE/DELETE（mutation）不能原地修改，而是创建新的 part 并重写符合条件的数据，旧 part 在替换后删除。Mutation 是异步的，加入执行队列，由后台任务逐个处理，因此执行期间查询可能看到部分数据已更新、部分未更新（不一致）。由于重写 part 消耗大量 IO，Mutation 会占用后台资源，影响正常写入吞吐，且 Mutation 执行期间可能阻塞 merge。

不可变 part 是 ClickHouse 存储模型的基石，mutation 通过重写实现更新，代价是开销大。异步性导致执行期间数据不一致（新旧混合）。Mutation 大且多会占用后台资源、拖慢写入。因此生产上应避免频繁 mutation，优先用重写表、ReplacingMergeTree 或轻量删除。理解 Mutation 的异步重写特性是正确使用更新/删除的关键。

• 分布式 JOIN 的数据重分布
• 大表 JOIN 的风险
• 优化手段（字典、预连接、GLOBAL）

分布式 JOIN 时，如果 join 表是分布式表，数据可能需要在节点间重分布，产生大量网络传输与内存开销，性能风险大。子查询在分布式下也可能被重复执行或需全局合并。优化手段包括：用 GLOBAL JOIN 让子查询在单节点执行后广播；用字典代替小维表 JOIN；用本地表连接避免重分布；预聚合或物化连接结果；对小表用分布式表的 Replicated 或本地副本。

分布式 JOIN 的核心风险是「数据重分布」与「不必要的网络传输」。优化目标是减少重分布与重复执行。GLOBAL JOIN 避免每节点重复执行子查询；字典替代小表 JOIN 提升性能；利用数据本地性减少跨节点。理解分布式 JOIN 的执行模型是优化性能的关键。

• 查询缓存缓存查询结果
• 结果复用条件（SQL 相同、数据未变）
• 失效与适用场景

ClickHouse 的查询缓存（Query Cache）会缓存查询结果，当相同 SQL 再次执行且底层数据未变化时，直接复用缓存结果，避免重复计算。缓存命中需满足条件：SQL 文本相同、涉及的表未发生 mutation/merge 变更、查询参数一致。缓存适用于确定性的、重复执行的查询（如报表、仪表盘），可显著降低延迟。但缓存有内存开销，且数据更新后需失效。

查询缓存通过「结果复用」减少重复计算，适合高频重复查询。但要求查询确定性、数据不变，否则结果过期。缓存失效依赖数据变更检测。适用场景是固定报表、重复聚合；不适合实时变化数据。需权衡缓存命中率与内存占用。