一只努力的微服务

原创 Aibrix Preble 算法

摘要：UCSD团队在ICLR 2025发表的论文提出E2调度算法（Exploitation + Exploration），解决分布式LLM推理中长Prompt重复共享与负载均衡的矛盾。核心创新是通过动态权衡缓存复用与GPU负载，当匹配前缀大于剩余token时复用缓存，否则选择最优GPU。配套机制包括负载再平衡、Prefill/Decode混合调度及优先级队列。实验显示Preble在平均延迟和尾延迟上显著优于SGLang，尤其在Tool Use等高共享场景。AIBrix的工程实现简化了部分设计，如未考虑驱逐代

原创 vLLM vs SGLang 深度技术对比

摘要 vLLM与SGLang是当前两大主流LLM推理框架，分别针对不同场景优化。vLLM基于PagedAttention技术，通过分页管理KV Cache解决显存碎片问题，适合通用高吞吐场景。SGLang则采用RadixAttention实现跨请求KV Cache复用，配合零开销重叠调度，专为结构化/多步骤工作流设计。两者核心差异在于：vLLM优化单次请求内的显存利用率，SGLang侧重共享前缀请求的重复计算消除。性能表现上，vLLM在独立短请求场景占优，SGLang在提示词复用场景可提速6倍以上。

原创 【Calcite 系列】深入理解 Calcite 的 AggregateRemoveRule

本文分析了AggregateRemoveRule的工作原理，该规则用于删除不必要的Aggregate操作。当输入数据在分组键上已唯一且聚合函数可简化为单行表达式或常量时，该规则将移除聚合操作。文章详细阐述了规则的触发条件、单例聚合与静态聚合的区别、对SUM0的特殊处理、删除后的投影补偿机制，以及规则对元数据的依赖性。通过测试案例展示了规则在各种场景下的适用性，其核心在于证明删除操作不会改变语义。

原创 【Calcite 系列】深入理解 Calcite 的 AggregateStarTableRule

本文分析了Calcite中的AggregateStarTableRule规则，该规则用于优化星型模型查询，通过物化汇总表替代原始扫描与聚合操作。文章详细阐述了规则的工作机制：首先检查materializations开关，然后通过RelOptLattice查找可用汇总表，区分精确命中和需要roll-up的情况，并强调measure映射的重要性。该规则的价值在于直接复用预计算结果，大幅提升查询性能。其适用条件包括启用materialization、使用StarTableScan且存在满足查询需求的汇总表。文章还

原创 【Calcite 系列】深入理解 Calcite 的 AggregateJoinTransposeRule

摘要：AggregateJoinTransposeRule是Calcite中处理聚合优化的核心规则，通过将聚合操作下推到Join两侧，先在左右表进行局部聚合，再合并结果来提升性能。规则要求Join必须是等值连接，聚合函数可拆分（如SUM/COUNT），并检查连接键唯一性以优化执行计划。它区分DEFAULT（仅分组下推）和EXTENDED（支持聚合函数下推）两种配置，但不支持DISTINCT和FILTER聚合。该规则通过四步转换实现优化，并在测试中覆盖了多种连接和聚合场景。

原创 【Calcite 系列】深入理解 Calcite 的 AggregateMinMaxToLimitRule

摘要：AggregateMinMaxToLimitRule是一条聚焦优化MIN/MAX聚合查询的规则，将无GROUP BY的MIN/MAX改写为带ORDER BY和LIMIT 1的标量子查询。规则触发条件严格，要求无分组且仅含MIN/MAX聚合。改写时每个聚合生成独立子查询，显式过滤NULL值并检查表达式确定性以保证语义正确。这种改写使执行器能利用索引和排序优化，提升查询效率。规则虽应用场景有限，但能有效优化特定聚合查询的执行性能。

原创 【Calcite 系列】深入理解 Calcite 的 AggregateUnionAggregateRule

摘要：AggregateUnionAggregateRule优化了SQL查询中重复的去重操作。该规则针对UNION ALL结构，当上下两层Aggregate都仅用于去重（无聚合计算）时，将底部的去重操作提到顶部统一执行。规则要求：1）必须是UNION ALL；2）Aggregate只能包含去重；3）通过补Project保持行类型对齐。这种优化减少了冗余的去重步骤，使查询更高效。规则仅处理两个输入的简单场景，确保实现简洁可靠。

原创 【Calcite 系列】深入理解 Calcite 的 AggregateUnionTransposeRule

本文分析了AggregateUnionTransposeRule的实现原理与限制条件。该规则将聚合操作下推到UNION ALL的每个输入分支，再在顶部合并局部结果。其核心机制包括：仅支持UNION ALL以避免语义冲突；限制聚合函数类型为可分解的MIN/MAX/COUNT/SUM等；处理输入列空值性差异导致的类型匹配问题；将顶层COUNT转为SUM0以正确累加局部计数。测试用例验证了基础场景、类型转换和唯一性边界条件，展示了该规则"先分支压缩再全局合并"的优化思路。

原创 【Calcite 系列】深入理解 Calcite 的 AggregateValuesRule

本文分析了AggregateValuesRule优化规则的工作原理。该规则专门处理Aggregate操作作用于Values节点的两类特殊情况：一是空输入时的全局聚合，直接构造常量结果；二是纯去重场景，直接对Values去重而无需执行聚合操作。规则通过严格条件判断确保只在语义明确的情况下生效，如空输入时COUNT返回0而MIN返回NULL，以及仅当输入输出行类型相同时才进行去重优化。这种优化虽针对小规模场景，但对查询性能提升具有重要意义，能避免后续处理不必要的聚合操作。

原创 【Calcite 系列】深入理解 Calcite 的 AggregateJoinJoinRemoveRule

本文分析了AggregateJoinJoinRemoveRule这一SQL优化规则，它专门处理两层左连接加聚合的场景。规则的核心是判断底层左连接是否冗余可删，需满足三个条件：1)聚合结果未使用底层右表列；2)所有聚合调用必须为DISTINCT风格；3)上下两层连接的左侧键必须一致。该规则通过严格检查确保语义不变后，会重构连接结构并调整字段映射。测试案例验证了规则在各种场景下的正确性，展现了其保守但精准的优化特点。

原创 【Calcite 系列】深入理解 Calcite 的 AggregateFilterTransposeRule

本文分析了AggregateFilterTransposeRule规则的工作原理和应用场景。该规则将Aggregate(Filter(input))重写为Filter(Aggregate(input))，主要目的是优化计划形态而非直接提升性能。规则支持两种处理路径：当过滤条件列已在原聚合输出中时直接转置；否则拆分为上下两层聚合，并确保聚合函数具备rollup能力。文章详细阐述了规则匹配条件、唯一性检查机制、对GROUPING SETS的处理方式，以及明确拒绝DISTINCT聚合的原因。该规则主要用于物化视图

原创 【Calcite 系列】深入理解 Calcite 的 AggregateFilterToFilteredAggregateRule

本文分析了AggregateFilterToFilteredAggregateRule规则，它专用于将Aggregate(Filter(input))结构转换为带FILTER子句的聚合形式。该规则主要针对无分组键的全局聚合(grand total)，通过将WHERE条件吸收到聚合调用中，使查询计划更适合物化视图改写和后续优化。文章详细阐述了规则的适用条件、实现逻辑（包括处理已有FILTER条件的方式）以及测试覆盖点，强调其作为规范化规则的价值在于减少计划树结构差异，而非通用查询优化。

原创 【Calcite 系列】深入理解 Calcite 的 AggregateFilterToCaseRule

本文分析了AggregateFilterToCaseRule规则的作用机制，该规则将FILTER聚合转换为CASE WHEN形式。文章指出这种转换并非单纯追求性能优化，而是为了兼容性、标准化需求以及与反向规则AggregateCaseToFilterRule形成可逆转换。重点阐述了规则的具体匹配条件、转换流程、特殊处理COUNT聚合的逻辑，以及为保持可逆性而对DISTINCT聚合的谨慎处理。最后强调了该规则体现了Calcite设计中对转换安全性和可逆性的重视，是一种规范形态转换规则。

原创 【Calcite 系列】深入理解 Calcite 的 AggregateExtractProjectRule

本文分析了AggregateExtractProjectRule规则的核心作用与实现原理。该规则通过在Aggregate下方显式插入精简的Project，提取聚合真正需要的输入列，从而优化查询性能。文章详细解读了规则如何计算字段使用情况（包括分组列、聚合参数和过滤条件）、构造字段映射关系，以及避免循环触发的机制。虽然规则本身不改变聚合语义，但它通过列裁剪为后续优化创造了更干净的输入环境，是查询优化的重要基础性规则。

原创 【Calcite 系列】深入理解 Calcite 的 AggregateExpandWithinDistinctRule

本文分析了Calcite中AggregateExpandWithinDistinctRule规则的工作原理。该规则将WITHIN DISTINCT聚合表达式（如SUM(x) WITHIN DISTINCT(y)）展开为两层聚合结构：内层通过GROUPING SETS按不同粒度去重并提取代表值，外层根据GROUPING()标识过滤并汇总结果。规则统一处理DISTINCT和WITHIN DISTINCT表达式，支持FILTER条件，并提供严格（抛异常）和宽松两种非唯一值处理策略。测试案例验证了其对各种场景的支持

原创 【Calcite 系列】深入理解 Calcite 的 AggregateExpandDistinctAggregatesRule

AggregateExpandDistinctAggregatesRule 是 Calcite 中处理 DISTINCT 聚合的核心规则，它将复杂的 DISTINCT 聚合表达式展开为更基础的 Aggregate、Project 和 Join 操作组合。该规则主要处理四种情况：当所有 DISTINCT 聚合参数相同时采用简单路径；支持 GROUPING SETS 的复杂场景；单 DISTINCT 聚合情况；以及通用多参数 DISTINCT 聚合的展开。规则通过分析聚合参数、过滤条件等特征，选择最优的展开方式

原创 【Calcite 系列】深入理解 Calcite 的 AggregateCaseToFilterRule

本文分析了 Calcite 中的 AggregateCaseToFilterRule 规则，该规则将条件聚合表达式（如 SUM(CASE WHEN...THEN...END)）改写为带 FILTER 的聚合形式（如 SUM(...) FILTER(WHERE...)）。文章详细介绍了规则的匹配模式、核心转换逻辑，并分类说明了其支持的 5 种改写场景，包括普通聚合、DISTINCT 聚合以及特殊模式转换等。同时指出该规则在 NULL 语义和自定义聚合函数场景下采取保守策略的原因，确保改写后的语义等价性。

原创 【Calcite 系列】深入理解 Calcite 的 SetOpToFilterRule

本文介绍了Calcite优化器中的SetOpToFilterRule规则，该规则将来自同一数据源且仅谓词不同的集合操作（UNION/INTERSECT/MINUS）改写为单个数据源加复合过滤条件的形式。通过分析源码实现，阐述了规则的工作原理：识别可合并的同源分支，根据不同集合操作类型（OR/AND/AND NOT）合并谓词条件，消除重复表扫描并增强谓词下推能力。特别说明了规则触发条件、安全性检查机制以及保证语义正确性的关键设计，包括对确定性表达式、子查询等特殊情况的处理策略。

原创 【Calcite 系列】深入理解 Calcite 的 IntersectToSemiJoinRule

的本质，是把这个特殊的集合操作改写成优化器更熟悉的SEMI JOINn 路INTERSECT变成 n-1 层嵌套SEMI JOIN连接条件使用正确处理NULL各分支列 Cast 到公共类型保证类型安全最终加DISTINCT恢复去重语义把优化器不擅长的INTERSECT转化为它擅长的JOIN正确保持了NULL等值语义（这是很多实现容易忽略的细节）支持任意路数的INTERSECT，覆盖面广已作为CoreRules的一部分提供，便于直接启用。

原创 【Calcite 系列】深入理解 Calcite 的 AggregateGroupingSetsToUnionRule

本文分析了Calcite中AggregateGroupingSetsToUnionRule规则的实现原理，该规则将包含GROUPING SETS的聚合查询转换为多个简单聚合的UNION ALL操作。

原创 【Calcite 系列】深入理解 Calcite 的 SortRemoveDuplicateKeysRule

本文分析了 Calcite 的 SortRemoveDuplicateKeysRule 优化规则，该规则通过函数依赖分析识别并消除 ORDER BY 子句中的冗余排序键。当多个排序键指向相同底层列或存在函数依赖关系时，保留其中一个键即可确保排序结果正确，从而减少不必要的比较开销。该规则实现简洁，与 Calcite 元数据框架深度集成，能有效处理自动生成 SQL 中的冗余排序问题，同时保持查询语义不变。文章详细介绍了规则的工作原理、适用场景、优势与局限，并提供了典型示例说明其优化效果。

原创 【Calcite 系列】深入理解 Calcite 的 JoinExpandOrToUnionRule

本文介绍了 Calcite 中 JoinExpandOrToUnionRule 的实现原理，该规则通过将带有 OR 条件的 Join 转换为多个互斥 Join 分支并用 UNION ALL 组合，解决 OR Join 难以优化的问题。规则会判断 OR 分支是否满足等值连接条件，确保改写后语义等价，并针对不同 Join 类型（INNER/ANTI/LEFT 等）采用不同展开策略。关键点包括：1) 只拆分合法的等值条件；2) 通过 NOT 排除前序条件保证结果不重复；3) 对 ANTI JOIN 采用链式处理保

原创 【Calcite 系列】深入解析 Apache Calcite 的函数依赖实现 RelMdFunctionalDependency

本文围绕 `core/src/main/java/org/apache/calcite/rel/metadata/RelMdFunctionalDependency.java` 这份实现，系统介绍 Calcite 是如何在关系代数树上推导函数依赖（Functional Dependency, FD）

原创 【Calcite 系列】ProjectAggregateMergeRule 丢失 Project 字段名问题修复

摘要：本文分析了Apache Calcite中ProjectAggregateMergeRule规则的问题，该规则在合并Project和Aggregate节点时会丢失原始字段名，导致输出列变为默认的$f0等形式。修复方案是在构建新Project算子时显式传递原始字段名参数。修改后测试显示成功保留了EXPR$0和SS0等列名，确保了元数据一致性。该修复对依赖列名的SQL引擎（如Flink、Beam等）具有重要意义，保障了查询优化过程中的语义保真性。

原创 【Calcite 系列】将 INTERSECT 转换为 EXISTS

本文介绍了将SQL中的INTERSECT操作转换为EXISTS子查询的优化方案。传统INTERSECT实现通常使用Hash Join或Sort+Unique方式，而转换为EXISTS后可以利用短路优化、谓词下推和索引扫描等优势。该优化通过IntersectToExistsRule规则实现，仅适用于INTERSECT DISTINCT场景，要求列数和类型匹配。核心实现通过递归将右侧输入包装成EXISTS子查询并与左侧关联，最终生成更高效的执行计划。测试验证了基础两路交集、多路交集、NULL语义处理等场景的正确

原创 【Calcite 系列】ProjectRemoveRule无法正确保留顶层Project字段名

Apache Calcite查询优化器中ProjectRemoveRule规则存在字段名保留问题。该规则用于合并冗余投影操作，但原始实现中project.getInput()获取的是包装类型而非实际Project节点，导致无法执行字段重命名逻辑。修复方案包括：1)修改规则匹配模式，明确匹配两层RelNode；2)改用call.rel(1)直接获取底层算子。测试表明修复后能正确保留顶层Project的字段别名。该问题虽隐蔽但影响查询语义正确性，修复已包含在1.39.0版本中。

原创 【Doris 系列】Doris Stream Load 导入 csv 测试

Stream Load 支持通过 HTTP 协议将本地文件或数据流导入到 Doris 中。Stream Load 是一个同步导入方式，执行导入后返回导入结果，可以通过请求的返回判断导入是否成功。一般来说，可以使用 Stream Load 导入 10GB 以下的文件，如果文件过大，建议将文件进行切分后使用 Stream Load 进行导入。Stream Load 可以保证一批导入任务的原子性，要么全部导入成功，要么全部导入失败。

原创 【Doris 系列】Doris IP 变更修复

查看 fe.out 会有以下报错，此时 fe 进程是无法启动的，操作前注意备份所有 fe 的元数据并停止上游读写动作！

原创 ByConity ELT 小测

总体测试体验还是不错的，bsp 确实能在资源有限的情况下一定程度的解决大查询或复杂查询的问题，但是在想构造一个 OOM 且 bsp 还能运行的参数确实有点难，尝试了好多次，建议可以在查询失败时给出建议，甚至能够自适应开启 bsp 并设置并行度，让用户收到 OOM 时就知道这个 SQL 确实是不能跑了。

原创 Gluten 优化器优化规则集

原创 Spark 优化规则集

原创 Doris 优化规则集

原创 【Doris 系列】Doris 各类 Distribute 介绍

所有节点默认的分布，即没有分布。

原创 CentOS 7 搭建 Impala 4.1.2 + Kudu 1.15.0 测试环境

通过 Web 页面看一下 Kudu，地址为：http://127.0.0.1:8051。打开：http://127.0.0.1:25000/backends。打开：http://127.0.0.1:25020/catalog。打开：http://127.0.0.1:25010/metrics。下载 java 安装包，需要登录 oracle，请自行下载。这部分不过于详细介绍，如果有现成环境也可以直接拿来使用。编译完成后，自行打的 RPM 包进行安装。至此，所有的安装验证就完成了。

原创 Milvus 介绍

代理本身是无状态的，可以借助负载均衡组件（Nginx、Kubernetes的Ingress、NodePort、LVS）向外界提供统一的访问地址和服务。为了在写入数据时充分利用集群的并行计算能力，Milvus 中的集合必须将数据写入操作分散到不同的节点。在 Milvus 中，所有数据都是按照集合（collection）、分片（shard）、分区（partition）、段（segment）和实体（entity）来组织的。相比之下，分片更多的是在写入数据时的扩展能力，而分区更多的是在读取数据时增强系统性能。

原创 使用 docker-compose 搭建 Doris 和 Hudi 测试环境

本机环境是 MacOS M1，系统版本为 12.5.1。

原创 【ClickHouse系列】ClickHouse 支持 ANN 向量索引

最近邻域搜索（ANN）是指在 n 维空间中找到与给定点距离最小的点的问题。如果数据要逐条对比，性能和内存都有很大的消耗，所以添加了 annoy_index 索引，利用 ann 索引来加速计算。

原创 ClickHouse UNDROP TABLE 功能

不论是使用 ClickHouse 还是其他数据库，如果手抖删掉了一个表，想要恢复是相当困难。但是现在 ClickHouse 支持了能力，如果因为手抖误删了一个表，那在短时间内可以快速恢复。目前还是个实验性功能，如果想要体验可以使用最新分支。下面来体验一下整个功能。

原创 ClickHouse 如何编写测试用例

想对 ClickHouse 进行开发，不能只懂得如何编写代码，更要懂得如何做好测试，这样才能保证自己开发的功能是可用的。所以如何编写测试用例是非常重要的，本文介绍一下 ClickHouse 如何编写测试用例。ClickHouse 的测试分很多种，这里主要介绍两种最常用的测试，即 stateless 测试和 integration 测试。

原创 【ClickHouse系列】如何解决 Too Many Parts 问题

如何解决 Too Many Parts 问题