不使用 SQL 的数据仓库

本是古典何须时尚 2024-02-18 09:17 4阅读 0赞

目前绝大多数数据仓库都采用SQL来处理数据。经过几十年的发展，SQL已经成为数据库世界的标准语言，并积累了大量的用户群体，数据仓库支持SQL已经是常态。然而，在当代大数据的背景下，随着业务复杂度的不断增加，在以计算为主要任务的数据仓库场景中，SQL的能力似乎越来越显得不足。一个典型的表现就是一些数据仓库开始集成Python等非SQL语言。且不说这两种风格截然不同的语言能否很好地融合和互补，单从这个趋势来看，显然业界对SQL的能力表示怀疑。

在本文中，我们将介绍一个非基于SQL的数据仓库“esProc”。由于集算器不使用SQL作为查询语言（而是使用SPL），所以我们可以暂时将其视为一种新型的数据仓库。

集算器为什么不使用SQL？

要回答这个问题，我们需要弄清楚为什么在SQL已经有了的情况下，数据仓库仍然引入Python，它想解决什么问题？

我们知道SQL对于过程计算并没有提供很好的支持。即使使用CTE语法，用SQL描述复杂的计算仍然非常复杂，往往需要嵌套多层代码并反复关联。另外，SQL的数据集是无序的，SQL非常不擅长有序计算。在处理与订单相关的操作时，使用 SQL 进行编码通常很麻烦，甚至无法实现。SQL本身的语言特性决定了它不擅长实现某些复杂的计算，但此类计算在数据仓库的数据分析场景中却很常见。例如，在对电商进行漏斗分析（计算页面浏览、加入购物车、下单、支付等每个步骤的用户流失率）时，用SQL编写代码是很困难的。相比之下，对于涉及多个连续步骤和重复使用结果的场景，使用支持逐步有序计算的语言（如Python）更容易实现。

换句话说，SQL缺乏足够的能力。

但引入Python等第三方语言来弥补能力的不足，会使技术栈变得复杂。即使我们不考虑Python是否能够弥补不足，也不考虑两种语言是否能够很好的融合，单单是多种不同风格的技术所带来的系统复杂度的上升，也必然导致高发展和运维成本。

除了能力不足之外，基于SQL的关系数据库还存在封闭性的问题。

由于数据库的主要功能是事务处理（TP），因此需要很多约束来保证数据的一致性等。例如，只有符合条件的数据才能加载到数据库中；只能处理数据库内部的数据，这就是我们所说的封闭性。数据仓库是在数据库的基础上发展起来的，继承了数据库的封闭性。

紧密度对于TP业务来说非常重要，但是对于以分析计算为主的AP业务来说，紧密度就没有意义，甚至非常不利。封闭性要求数据只有加载到数据库后才能使用，这将导致多个数据库的数据无法随意组合和计算，从而极大地限制了数据仓库的应用场景。

此外，现代数据应用的数据来源多种多样。除了不同的数据库之外，我们还经常面临多种数据源和数据类型。由于封闭式SQL数据库无法计算数据库外的数据，因此必须先导入数据再计算，从而增加了ETL动作。这样不仅增加了程序员的工作量和数据库的负担，而且损失了数据的实时性。通常，数据库外部的数据格式不规则，不容易加载到约束性强的数据库中，即使进行ETL动作，也首先需要将原始数据加载到数据库中，才能利用数据库的计算能力。于是，ETL改为ELT，增加了数据库的负担。

而且，封闭性使得用户不方便自由地利用以空间换时间的方式。我们知道，存储资源比计算资源便宜得多。如果我们针对不同的计算目标以多种方式冗余存储数据，我们可能会获得更好的查询体验。然而，SQL需要将数据存储到表中。创建过多的表会使元数据变得更大，导致运维成本大幅增加，同时过多的表还会给数据仓库带来容量和性能问题，面临扩展压力。许多大型组织在其中央数据仓库中存储数千个中间表。这些表已经积累了多年，但又不得不谨慎保留，对数据库的容量、性能、运维造成了巨大的负担。

SQL在性能方面也表现不佳

众所周知，SQL的执行效率取决于数据库优化引擎的优化程度，好的数据库会根据SQL的计算目标（而不是其字面表达的逻辑）来选择更高效的执行路径。然而，这种自动优化机制仅