宽表是快还是慢？

看起来您只提供了来源链接，而没有贴出需要翻译的正文内容。请把要翻译的文本（文章正文）粘贴在这里，我就可以按照要求保留链接并将其余部分翻译成简体中文。

Introduction

宽表是商业智能（BI）系统的常见组件。它们通常在项目早期通过将多个相关表连接成一个去规范化的单表来创建。这会产生一个不符合范式的数据集，并包含大量冗余数据。由于宽表必须预先创建，它们的使用灵活性也较低。

为什么宽表被认为是快速的

• 查询宽表可以避免实时多表连接的开销。
• 在 SQL 中，连接操作历来难以编写，且可能表现出较差的性能。
• 有关 SQL 连接的详细分析请参阅 HERE。

宽表的缺点

• 数据冗余： 在计算过程中会读取额外的数据，增加 I/O 时间。
  示例： 一个 Orders 表与 OrderDetails（每个订单 5 行）进行连接时，会将订单数据重复五次。再加入维度表（如 Customer、Employee、Region）会进一步膨胀数据集。
• I/O 开销： 对宽表进行聚合查询（例如按客户地区汇总订单金额）时，必须扫描更大体量的数据。
• 违反规范化： 结果集不符合范式，可能导致数据错误。
• 灵活性差： 宽表“僵硬”——任何模式更改都需要重新构建表。

尽管存在这些问题，宽表在实际使用中往往看起来更快，因为关系数据库的连接操作可能显著更慢，即使宽表带来了更高的 I/O 成本。

连接可以优化吗？

是的，但传统的 SQL 缺乏针对不同连接模式进行有针对性优化的机制。基于笛卡尔积的通用连接定义使得应用专门的优化变得困难。各厂商已经将 SQL 优化推向极限，然而许多 BI 工作负载仍然依赖宽表来实现可接受的性能。

SPL 作为解决方案

SPL（结构化过程语言） 是一个开源计算引擎，专为结构化数据处理而设计，独立于任何特定数据库。SPL 提供：

• 更高的连接性能： SPL 的连接处理性能优于传统 SQL 连接和宽表连接。
• 针对性优化： SPL 区分两种常见的 BI 连接类型：
  • 外键连接 – 通过 维度表预加载 和 数字化 方法进行优化。
  • 主键连接 – 通过 基于顺序的合并 方法进行优化。

通过加速连接，SPL 消除了对宽表的需求，降低了数据量并提升整体 BI 性能。

SPL 连接优化技术

外键连接

• 维度表预加载: 将维度表一次性加载到内存中，避免重复查找。
• 数值化: 将连接键转换为紧凑的数值表示，以加快匹配速度。

主键连接

• 基于顺序的合并: 利用已排序的主键以线性时间合并表格，降低复杂度。

性能比较

使用 TPC‑H 100 GB 数据集进行基准测试，聚焦于典型的 BI 场景：

1. 两表连接： Fact table ↔ one dimension table。
2. 宽表聚合： 在预构建的宽表上执行相同的分析。

结果（时间以秒为单位）已在详细测试报告 HERE 中汇总。

关键发现

• SQL 宽表 vs. SQL 连接： 宽表更快，验证了之前的分析。
• SPL 实时连接 vs. SQL： SPL 的连接速度比两个 SQL 数据库的连接快 3–9×。
• SPL vs. ClickHouse 宽表： 虽然 ClickHouse 的宽表性能更高，SPL 的实时连接仍以很大优势超越它。

考虑到宽表的缺点（冗余、错误、缺乏灵活性），SPL 的实时连接提供了明显优势：它避免了宽表的缺陷，同时交付更卓越的性能。

Conclusion

宽表可以因为规避昂贵的 SQL 连接而快速出现，但它们会引入显著的冗余和刚性。SPL 通过提供高性能、实时的连接，并针对常见 BI 模式进行专门优化，提供了一个强大的替代方案。因此，对昂贵宽表的依赖会减少，进而实现更简洁的数据模型和更快的分析。

SPL 是开源的；源代码可在 GitHub 获取。