不使用SQL的数据仓库
Source: Dev.to
目前绝大多数数据仓库都使用 SQL 来处理数据。经过数十年的发展，SQL 已经成为数据库领域的标准语言，并拥有庞大的用户群体，因此为数据仓库提供 SQL 支持是很自然的事。然而，在当代大数据背景下，业务复杂度不断提升，SQL 在计算为主的数据仓库场景中的能力显得日益不足。一个典型的表现是，一些数据仓库开始引入非 SQL 语言，如 Python。业界对 SQL 能力的质疑已相当明显。
本文介绍一种基于非 SQL 的数据仓库 esProc。由于 esProc 并不使用 SQL 作为查询语言（它使用 SPL），我们可以把它视为一种新型的数据仓库。
为什么 esProc 不使用 SQL？
缺乏过程化和有序计算
SQL 对过程化计算的支持很差。即使使用 CTE 语法，在 SQL 中描述复杂计算也很繁琐，往往需要深度嵌套查询。此外，SQL 将数据集视为无序的，这使得有序计算变得困难甚至不可能。
典型的数据分析任务——例如电商公司的漏斗分析（计算用户在每一步的流失：页面浏览 → 加入购物车 → 下单 → 支付）——在支持逐步、有序计算的语言（如 Python 或 SPL）中实现要容易得多。
关系数据库的封闭性
关系数据库主要面向事务处理（TP）而设计。它们强制严格的约束：只能加载满足条件的数据，且只能处理数据库内部的数据。这种“封闭性”对 TP 有价值，但对分析处理（AP）却是劣势：
- 跨源计算 – 来自多个数据库的数据无法自由组合，限制了仓库的使用场景。
- ETL 开销 – 现代应用会摄取多种数据源（文件、流、NoSQL 存储）。由于数据库无法计算存储之外的数据，必须先将数据导入，增加 ETL 步骤，提升程序员工作量，并导致实时性下降。
- 空间换时间的权衡 – 存储冗余的中间表可以提升查询性能，但 SQL 强制数据必须落在表中。维护成千上万的中间表会膨胀元数据，提升运维成本，并带来容量和扩展性挑战。
性能限制
SQL 的性能高度依赖数据库的优化器。对于简单查询，优化器可以选取高效的执行计划，但一旦计算变得中等复杂，优化器往往退回到字面执行，导致性能急剧下降。漏斗分析等示例常常运行得太慢而无法实际使用，批处理作业甚至可能需要数小时才能完成。
给基于 SQL 的仓库加 Python 的问题
引入第三方语言（如 Python）会使技术栈更加复杂：
- 更高的开发和运维成本 – 管理多种语言及其不同范式会增加复杂度。
- 大数据支持不足 – Python 缺乏原生机制（如游标）来处理超出内存容量的数据，使得大规模计算变得笨拙。
- 并行性低效 – Python 的全局解释器锁（GIL）阻止了真正的多线程 CPU 并行；并行执行往往是串行的，甚至比串行更慢。
- I/O 开销 – Python 必须从封闭的数据库中读取数据，产生额外的 I/O 成本，进一步削弱性能。
- 无法介入存储层 – 高性能算法（如有序合并）需要直接控制数据布局，而当数据位于封闭的关系存储中时，这几乎是不可能的。
结论
基于 SQL 的数据仓库存在三大核心问题：
- 过程化和有序计算能力不足
- 封闭性阻碍灵活的数据集成并增加 ETL/ELT 负担
- 对中等复杂度分析工作负载的性能衰减
在 SQL 上再加 Python 并不能解决这些问题，反而会带来额外的复杂性和性能限制。esProc 通过抛弃 SQL、采用 SPL，提供了一个更灵活、开放且高性能的现代数据仓库分析环境。