我们知道，数据库的数据处理能力是封闭的。所谓封闭性，这里是指要被数据库计算和处理的数据，必须事先装入数据库之内，数据在数据库内部还是外部是很明确的。

数据库一般有 OLTP 和 OLAP 两个用途。对于 OLTP 业务来讲，因为要保证数据的一致性，而一致性只有在一个确定的范围内谈论才有意义，这样就自然就会带来封闭性：数据库系统将保证也只负责数据库内部的数据的一致性。

如果不关注 OLTP 业务，只关心 OLAP 业务时，数据库在逻辑上可以被理解成为数据仓库，而这样的数据仓库也顺便继承了这个封闭性。

数据库的名字中有个“库”字，即使不考虑 OLTP 业务，也会让人觉得它是个以存储为主要目的的产品。其实不然，在实际应用中，特别是在大数据场景下，数据库有相当多的作用是计算，对于 OLAP 业务几乎可以说是全部，其存储经常也是为了计算服务的。因为数据库的计算能力还不错，远远超过大多数其它软件产品，所以人们经常会为了计算目标而部署数据库。

但是，一个以计算为主要任务的产品，没必要绑定封闭性这样的特点。

计算能力的封闭性有什么坏处呢？

一个典型的现象就是 ETL 经常被做成 ELT 甚至 LET。ETL 中的 E 和 T 这两步事实上也是某种计算，如果计算能力被封闭到数据库之内的话，我们就只能先把数据装入库中才能计算了，因为无法计算库外的数据。然而 ETL 过程中的原始数据常常并不在库内，或者至少不在这个用于计算的数据库中，也可能存在于多个数据库。总之，都需要先做个同库动作之后才能再计算。

有点多此一举！

数据库的封闭性，相当于城市有个城墙，数据要进出也必须通过数据库的城门，过程中还要进行一些检查。对于 OLTP 业务，为了保证一致性，这些检查是有必要的，但也会损失数据库的 IO 效率，而这对于 ETL 这类业务几乎没有意义，只是浪费时间而已。

当代应用中多样性的数据源越来越普遍，经常有来自外部服务的数据。如果为了计算这些数据而先把它们转入数据库中，也是非常累赘的。临时转入的效率很低（因为数据库的 IO 成本高），很可能跟不上访问需求，而定时批量转入又很难获得最新的数据，同样影响计算结果的实时性。

那么，我们把计算能力从数据库中剥离出来，作为独立的计算引擎提供，让数据（仓）库只负责存储，是不是就可以了？

不依赖于数据库的计算能力确实很必要，这样是可以解决上述的 ELT/LET 和多数据源问题，但这还不够。

数据库风格的计算常常是数据密集型的，其性能和存储机制密切相关。把计算能力剥离，只能是让计算可以进行，但并不能保证足够快。在关注计算性能的场景下，特定的存储方案仍然是必要的。

还是要回到计算封闭的老路？

不必。

要获得高性能，是要关注数据存储，但只要设定专门的存储格式即可，并不需要做个“库”把数据装起来。一个开放的计算引擎，可以计算任何来源的数据。如果数据能够以约定的方式存储，那么可以获得更高性能的计算效率，仅此而已。计算时并不需要关心数据是不是属于某个“库”，“数据仓库”（如果还用这个名词的话）可以发展成没有库、只有数据的组织形式。

现代城市不必再有城墙！