2026-08-12 20:12:49 分类：科技
今天不聊概念，直接拆一件让人又爱又恨的东西——事实表。先说个故事：前两年我在一家电商公司做数仓重构，线上遇到一个诡异的问题：一个统计销售金额的报表，每天凌晨跑一次，每次全量扫订单表。当时明明已经建了索引，可查询还是慢得让人崩溃。后来我查了一下执行计划，发现那个事实表居然是行存的。
你可能觉得“这有什么好稀奇的”，但在你写下那句“CREATE TABLE”的时候，你就已经在给后面埋地雷了。事实表从来不是一个“数据容器”，它更像是查询引擎的燃料。燃料的物理形态不同，燃烧效率天差地别。
事实表的物理存储：从行存到列存，一次IO革命
传统行存储，把一行所有字段堆在一个物理块里。如果你想查所有订单的金额总和，数据库就必须把整行整行拖到内存里，哪怕你只需要一列。假设订单表有40个字段，一亿行，每行平均200字节，那全表扫描就是20GB的IO。实际上，你只需要那个金额列，也就两三GB。行存白白浪费了80%的IO。
列存呢？把同一列的索引号放在一起，压缩比高，而且查询时只读取相关的列。我们用ClickHouse和MySQL做了一次对比：同样一张订单事实表，1亿行，查询“统计每日销售额”，MySQL（行存）全表扫描耗时22.3秒，ClickHouse（列存）只用了0.8秒。差距不是几倍，是28倍。而且ClickHouse的配置文件几乎没有调优，标准的MergeTree引擎。
为什么能快这么多？第一，列存的物理布局让CPU缓存命中率飙升。第二，数据压缩减少了磁盘到内存的传输量。一个金额字段用delta压缩后，体积只有原始1/10。在SSD上，等量数据，绕过的IO少一个数量级，时间自然就下来了。
数据仓库事实表列式存储与行式存储结构对比图
聚合查询的数学本质：逆天的预聚合是怎么练成的
事实表里躺着的是最细粒度的原始记录。每条记录是一个不可再分的“事件”。但业务方从来不直接看明细，他们要看的是“这个月每个品类的退货率”。所以查询引擎必须在事实表上做group by和sum的操作。这时候，一个最笨的办法就是实时扫全表。另一个稍微聪明点的办法，是把事实表的所有度量值预先按维度组合算好，把“结果”存下来。这就是预聚合。
预聚合的本质是，用空间换时间。还是那张1亿行订单事实表，如果我们按日期+品类+渠道三个维度预聚合，行数会降到10万左右。你猜查询速度快了多少？原始查询需要2秒，预聚合后只需要30毫秒。这里面的数学原理很简单：聚合是个归约操作，它满足结合律，所以可以提前算好中间状态，比如sum和count，后面再merge。
听起来很完美，对吧？但这里面有一个陷阱：如果你把每个维度组合都预聚合一遍，那就是一个巨大的立方体。7个维度就能产生2的7次方=128个cuboid，每种组合的存储量都不一样。你不加筛选地做全组合，存储膨胀会直接击爆你的磁盘。我们曾经在测试环境中干过这事，一张200MB的事实表，全量预聚合后变成7.2GB，膨胀了36倍。查询是快了，可运维崩溃了。
所以预聚合必须有策略，比如只建“关键维度组合”，即（日期, 品类）等等。这块我们后面会详细说。
数据仓库事实表预聚合Rollup多维数据立方体示意图
三个致命陷阱：事实表落地最容易翻车的地方
三个致命陷阱：事实表落地最容易翻车的地方
别以为建完事实表就万事大吉了。根据我的经验，以下三个坑，几乎每一个数据团队都踩过。
陷阱一：粒度不声明
事实表里每一行代表什么？这是先决条件。如果两张表都叫“订单事实表”，一张细到订单明细项，另一张直接是当日汇总，那么分析师做起报表来一定会怀疑人生。更严重的是，如果你允许在同一张表里既存明细又存预聚合结果，查询结果就会忽大忽小。解决方案也很简单：建表时必须定义粒度，并且用一个唯一键去校验。比如“订单事实表”粒度是“订单项”，那就用(order_id, line_item_id)做唯一键，写入时检查重复率。一旦发现重复行，宁可拒绝写入也不能放过。
陷阱二：维度字段的过度冗余
很多新人喜欢把维度字段直接塞进事实表。比如把客户性别、地区、手机型号全都冗余到订单事实表里。这样查询倒是方便了，但带来两个问题：一是存储膨胀，二是维度更新时需要同步事实表。如果维度属性变了，你要么改历史事实，要么眼睁睁看着历史数据错。比较好用的折中方案是：低基数的维度字段（比如性别、地区）可以直接冗余，但高基数或经常变化的维度必须拆出去。我们在实际项目中给事实表加了“性别”和“年龄层”两个冗余字段，结果查询性能大幅提升，而维度表更新依然通过id关联。
陷阱三：Hive风格的分区陷阱
如果你还停留在用where + group by做全表扫描，那很快就会被事实表惩罚。事实表最常见的天性就是日期分区，但分区数量过多，元数据压力就大。另一个问题是，你做了分区裁剪但没用上，比如你在where条件里写了date >= ‘2024-01-01’，但表没有按date分区，引擎只能扫全部分区。我们在生产环境发现，有一个团队把事实表按月份分区，但查询时总是同时访问“本月初至今”以及“去年同期”，导致本来能删掉80%分区的查询，结果把全分区都扫了。解决方案是：按周分区，加上一个“月度范围“的桶，并且在查询时显式指定分区列表。这个经验听起来简单，但做到的人太少。
当然，事实表的世界还有很多细节，比如迟到数据、拉链表、位图索引……但上面这三个点，如果你能躲开，你的数仓至少不会翻车。
话说回来，事实表本身并不复杂，复杂的是我们对它的轻视。每一次慢查询、每一场数据口径争论，背后都可能藏着一个没有设计好的事实表。下次建表之前，多想一想它的存储形态、聚合策略和粒度声明，你可能会少失眠几个夜晚。
免责声明：市场有风险，选择需谨慎！此文仅供参考，不作买卖依据。如有侵权请联系删除。
文章名称：事实表底层拆解：从存储模型到聚合算法，为什么它才是数仓的动力引擎？
文章链接：https://www.lfdjt.com/info_23_8432.html
