【SQLite 内核】选型与阅读地图：SQLite vs PG vs DuckDB vs RocksDB
用部署形态、写并发、查询形态与持久化需求收束 SQLite / PostgreSQL·InnoDB / DuckDB / RocksDB 选型；给出站内阅读地图、全系列学术谱系与开放问题，标志 SQLite 内核系列完成。
duckdb 标签归档
共 16 篇文章 · 返回首页
【列存引擎内核】DuckDB 架构与嵌入式 OLAP
DuckDB 进程内嵌入式模型、Storage 的 Row Group 与 Column Segment、Catalog 与 checkpoint；与 ClickHouse Server 部署差异及 pg_duckdb 联邦场景边界。
【列存引擎内核】DuckDB 向量化与 Morsel-Driven Pipeline
DuckDB 向量批执行、morsel-driven 并行、Pipeline 调度与 spill；源码 execution/parallel 路径；对照 ClickHouse Processors 与 PG volcano 模型。
【列存引擎内核】ClickHouse 与 DuckDB 选型决策
从部署形态、规模、并发、联邦与运维成本五维对比 ClickHouse 与 DuckDB；给出决策树与组合架构，不排名不测虚构 benchmark。
【列存引擎内核】ClickHouse 与 DuckDB 源码级拆解
主选 ClickHouse 拆解 MergeTree 存储格式、向量化执行与分布式协调；DuckDB 作为嵌入式 OLAP 对照。覆盖列存文件布局、merge 机制、跳数索引与生产故障模式，面向数据平台工程师与从 PG/MySQL 转 OLAP 的 DBA。
【分布式 OLAP 查询引擎】OLAP 查询引擎全景：从单进程到 MPP
从 OLTP/OLAP/HTAP 边界、嵌入式 DuckDB 与分布式 Trino/Spark 分工、批式扫描与交互式查询延迟口径出发，闭合 lakehouse 与 stream-processing 之间的查询层缺口，并给出本系列 18 篇地图。
【分布式 OLAP 查询引擎】SQL 解析、分析与逻辑计划
从 Parser/AST、Analyzer 与 Catalog 元数据到 LogicalPlan 算子树；对照 PostgreSQL parse/rewrite/plan 边界，并用 DuckDB 1.5.4 实测 EXPLAIN 与 Trino 476+ 文档中的 logical plan 结构对读。
【分布式 OLAP 查询引擎】Join 重排与物理算子选择
Join order enumeration、Hash/Merge/Nested Loop 适用条件；Trino broadcast vs partitioned join 与 shuffle 网络代价；Dynamic partition pruning 与 runtime filter；DuckDB HASH_JOIN 实测与 Spark AQE 对照边界。
【分布式 OLAP 查询引擎】向量化批处理与 Morsel-Driven 并行
拆解列向量 batch、SelectionVector 与 flat/dictionary 编码；对照 columnar-engine/04 的 ClickHouse Block 直觉，说明 DuckDB morsel-driven 与 Trino Page 流在 MPP 上的落地，并给出本机 DuckDB 1.5.4 实测。
【分布式 OLAP 查询引擎】Hash Join 与 Hash Aggregation：Build/Probe 与 Spill
拆解 hash join build/probe 内存布局、outer join 标记，以及 partial/final 两阶段聚合在 MPP 上的语义；对照 Trino 476+ spill/revocable memory 与 DuckDB 本机 HASH_JOIN 实测。
【分布式 OLAP 查询引擎】DuckDB 与 DataFusion：嵌入式分析对照
从单进程向量化 pipeline 与 morsel-driven 并行出发，对照 DuckDB 1.5.4 与 Apache DataFusion 的 planner/executor 边界；说明何时选嵌入式读湖、何时必须上 Trino MPP；与 columnar-engine DuckDB 存储篇分工，并用本机实测 EXPLAIN 与 Parquet 投影下推数据锚定结论。
【分布式 OLAP 查询引擎】Iceberg 下推全链路：Planner 视角
与 lakehouse/18 分工：那边讲四层读湖漏斗是什么；本篇讲 Trino/Spark/DuckDB 在 SQL 优化链的哪一步把谓词变成 layout constraint、谁调用 Iceberg planning、split 如何携带残余谓词。引用官方文档与 lakehouse/18 本机 PyIceberg 实测，不伪造 Trino 计划输出。
【分布式 OLAP 查询引擎】引擎选型与数据平台阅读地图
用决策树收束 Trino/Spark/ClickHouse/DuckDB/DataFusion/PostgreSQL 的适用边界：交互式联邦、批 ETL、嵌入式分析、流批一体各走哪条路径；给出能力对照表（无吞吐排名）与 postgresql→columnar→lakehouse→stream→query-engine 全栈阅读顺序，闭合数据平台栈。
【分布式 OLAP 查询引擎】Trino · Spark · DuckDB · 优化与 MPP 执行
闭合数据平台栈最后一块：从 SQL 解析与 Calcite 式优化，到 Volcano/向量化执行、Trino Coordinator/Worker 与 shuffle，再到 Iceberg connector 下推与生产排查。承接 lakehouse 第 18 章读湖视角，补全「谁在做 planning」的引擎内核层。
【数据湖与开放表格式】查询引擎如何读湖
拆解查询引擎读 Iceberg/Delta 的下推链路：partition pruning（manifest）→ file pruning（manifest stats）→ row-group/page pruning（Parquet column index）→ 字典过滤。对照 Trino/Spark/DuckDB/DataFusion/ClickHouse 的能力差异，讲清 planning 在哪一层完成、stats 从哪来，并用本机 pyiceberg + DuckDB 实测裁剪效果。
持久化数据结构在数据库中的应用
MVCC 靠什么实现？持久化 B-tree、COW、append-only log。从 CouchDB 到 LMDB 到 DuckDB，三种不同的路径，同一个目标：读不阻塞写。