【分布式 OLAP 查询引擎】Calcite 与规则/代价优化框架
RelNode、Convention、Trait 与 Rule-based 改写链；VolcanoPlanner/Cascades memo 搜索；Trino 476+ 自研 planner 与 Calcite 借鉴边界，对照 Spark Catalyst 优化阶段。
predicate-pushdown 标签归档
共 6 篇文章 · 返回首页
【分布式 OLAP 查询引擎】Scan、Filter 与 Project：Split 与下推边界
从 Trino TableScanOperator 与 ConnectorSplit 出发，讲 column pruning、谓词/limit 下推在 ConnectorMetadata 的落点，以及必须留在引擎内的 Filter/Project 边界；与 lakehouse/18 读湖漏斗衔接。
【分布式 OLAP 查询引擎】Iceberg 下推全链路：Planner 视角
与 lakehouse/18 分工：那边讲四层读湖漏斗是什么；本篇讲 Trino/Spark/DuckDB 在 SQL 优化链的哪一步把谓词变成 layout constraint、谁调用 Iceberg planning、split 如何携带残余谓词。引用官方文档与 lakehouse/18 本机 PyIceberg 实测，不伪造 Trino 计划输出。
【分布式 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 实测裁剪效果。
【存储工程】Parquet 文件格式深度解析
上一篇我们讨论了列式存储（Columnar Storage）的核心思想：把同一列的数据连续存放，让分析查询只读取需要的列，而不是扫描整行。这个思想落地到具体文件格式时，需要回答一系列工程问题：文件内部怎么组织数据才能同时支持并行读取和列裁剪？同一列的数据用什么编码方式才能最大化压缩率？如何在不读取全部数据的前提下跳过不…