宽表经常是 BI 系统的标配，很多 BI 项目在建设之初首先就会准备宽表。宽表是将有一定关联关系的多个表连接成一个表，结果集不符合范式要求，会存在大量数据冗余。同时宽表由于需要事先建立，在使用时灵活性也比较差。

宽表有这么多缺点，为什么大家还乐此不疲地使用呢？

很大程度是为了快！

从一个宽表查询数据往往要比基于多个表进行实时关联的性能更高，建宽表主要是为了避免关联。我们知道关联计算一直是 SQL 的老大难，不仅难写，计算性能也很低。关于 SQL 关联的详细分析可以参考： 连接运算

不过，宽表虽然避免了关联，但由于数据冗余的存在，计算时可能会多读很多数据，这又会增加 IO 时间。比如订单表中每个订单平均对应 5 条订单明细（表），将两个表拉成宽表订单明细的数据就会冗余 5 倍，而订单表还有客户、雇员等维表，客户还有地区等维表，……，这些都变成宽表数据容量整体会放大很多倍。基于这个宽表进行查询，如要根据客户地区汇总订单金额，就要多读很多数据，IO 开销很高。

按照如此分析，宽表应该更慢才对。但实际情况为什么却是宽表更快呢？这主要是因为关系数据库做关联实在是太慢了，即使宽表 IO 成本增加几倍，仍然要比实时关联更快。

那么如果能优化关联性能，让关联跑得更快，是不是就能避免使用宽表带来的冗余、出错（违背范式的结果）、不灵活等诸多问题的同时，还能满足性能要求呢？

的确是这样。不过很遗憾，SQL 做不到。

前面关于 SQL 关联分析的参考已经做了详细分析，我们不再赘述，只引用结论：笛卡尔积再过滤这种 JOIN 定义，确实非常简单，而简单的内涵将得到更大的外延，可以把各种 JOIN 情况都包含进来。但过于宽泛的定义会导致无法对不同的关联计算进行针对性优化，最终只能在工程上想些治标的办法，并不能从根本上解决问题。

另外的事实是，数据库诞生至今，用于 BI 的这种简单 SQL 已经被各家厂商几乎优化到极致，但仍然需要宽表来解决性能问题，由此可见关联计算的性能问题并不好解决，甚至可以说解决不了。

那么怎么办？

用 SPL 可以搞定。

SPL（Structured Process Language）是一个开源结构化数据计算引擎，本身提供了不依赖数据库的强大计算能力。通过 SPL 进行关联运算的性能不仅远高于 SQL 关联，也比宽表快很多，可以从根本上解决关联运算慢的难题，又可以避免使用宽表带来的诸多问题。

SPL 针对 BI 业务中常见的等值 JOIN 区分为外键关联和主键关联两大类，分别采用了不同的性能优化方案，这在前面 连接运算 帖子的后半部分也有阐述。特别是针对 BI 业务中常见的外键关联可以采用维表预加载以及序号化的方法，对于主键关联可以使用有序归并的方法，都能大幅度降低关联计算的复杂度。

将关联运算提速后，就可以不再使用宽表了，从而大量减少了数据读取量。这样，用 SPL 做 BI 运算的性能就会有巨大提升。

这是理论上的分析，SPL 的实测表现怎么样呢？

为此，我们做了对比测试。测试选取了多维分析中常见的事实表和多个及多层维表的关联后按维度的汇总统计，以及宽表按维度的统计。

测试数据基于 TPCH 100G 数据集，设计大事实表和多个维表关联的运算：

1. 一个事实表和一个维表关联，共两表关联运算

2. 主子事实表和四个维表关联，其中一个维表被使用两次，共七表关联运算

3. 将 2 中的七表关联拼成宽表，基于宽表的统计运算。

对比产品选择了业界两个以 BI 运算性能高而著称的专用 OLAP 数据库，Starrocks 和 Clickhouse。对比结果如下：

时间单位：秒

详细测试报告： SPL 计算性能系列测试：关联表及宽表

从测试结果可以看到，在关联较多时，SQL 的宽表比关联更快，这验证了前面的分析。SPL 的宽表性能其实赶不上 Clickhouse ，但是实时关联计算性能很高，不仅比其他两个 SQL 数据库关联快（3-9 倍），甚至比数据库的宽表方案也有很大幅度的优势。如果再考虑到宽表的那些缺点（数据冗余、数据错误、灵活性差），使用 SPL 进行实时关联计算的优势会更加明显，不仅可以避免宽表的缺点，性能还能提升到 N 倍。

宽表并不一定比实时关联更快！有了 SPL 以后，BI 系统中为了高性能而花巨大代价建立的宽表就没什么意义了。