【CarbonData】CarbonData 的索引是如何构建和维护的？是在数据加载时还是查询时？
CarbonData 索引构建与维护机制全解析：从数据加载到查询加速
问题引入
用户问题原文：CarbonData 的索引是如何构建和维护的？是在数据加载时还是查询时？
在供应链库存优化系统中，我们曾遭遇一个棘手的查询延迟问题：一条用于实时监控“高价值商品在特定仓库的库存水位”的查询SELECT sku_id, SUM(stock_on_hand) FROM supply_chain_inventory WHERE warehouse_id = 'WH-001' AND product_tier = 'premium' GROUP BY sku_id，在数据量增长后，响应时间从 200ms 暴涨至 3.5 秒。深入排查发现，根本原因在于我们错误地认为 CarbonData 的索引是“按需构建”的，而实际上其核心索引（如 Min-Max、Bloom Filter）是在数据加载时就已固化到文件中的。由于建表时未正确配置索引策略，导致查询时无法有效裁剪数据。
本文将系统性地拆解 Apache CarbonData 2.3.x 的索引体系，明确区分不同索引类型的构建时机（加载时 vs 查询时）、维护方式以及它们在查询执行中的协同工作机制。我们将从源码层面剖析索引的生成逻辑，并结合供应链场景，展示如何通过正确的建模和配置，在数据写入阶段就为未来的查询埋下性能的种子。