【数据蒋堂】第18期：SQL用作大数据计算语法好吗？

当前的大数据平台在处理结构化数据时大都仍然以提供SQL语法为主流。兼容SQL的好处是很明显的，SQL的应用非常广泛，会SQL的程序员很多，如果继续采用SQL则可以避免许多学习成本。支持SQL的前端软件也很多，使用SQL的大数据平台很容易融入这个现成的生态圈中。大数据平台打算替代的传统数据库也是SQL语法的，这样兼容性会很好，移植成本相对较低。

但继续使用SQL也有缺点，最大的问题就是难以获得大数据计算最需要的高性能。

我们在前面的文章中提到过，SQL中缺乏一些必要的数据类型和运算定义，这使得某些高性能算法无法描述，只能寄希望于计算引擎在工程上的优化。传统商业数据库经过几十年的发展，优化经验已经相当丰富，但即使这样仍有许多场景难以被优化，理论层面的问题确实很难在工程层面解决。而新兴的大数据平台在优化方面的经验还远远不如传统数据库，算法上不占优，就只能靠集群更多的机器获得性能提升。另外，SQL还是一种描述性语言，不擅长指定执行路径，而想获得高性能常常需要专门优化的执行路径，这又需要增加许多特殊的修饰符来人为干预，那还不如直接用过程性语法更为直接，这也会妨碍用SQL写出高性能的代码。

SQL发明之初的计算机硬件能力还比较差，要保证实用性，SQL的设计必须适应当时的硬件条件，这就导致了SQL很难充分利用当代计算机的硬件能力，具体来说就是大内存、多线程和集群。SQL中的JOIN是按键值对应的，而大内存情况下其实可以直接用地址对应，不需要计算HASH值和比对，性能可以提高很多；SQL的数据表无序，单表计算时还容易做到分段并行，多表关联运算时一般就只能事先做好固定分段，很难做到同步动态分段，这就无法根据机器的负载临时决定并行的线程数量；对于集群运算也是这样，SQL在理论上不区分维表和事实表，JOIN运算简单地定义为笛卡尔积后过滤，要实现大表JOIN就会不可避免地产生占用大量网络资源的HASH Shuffle动作，在集群节点数太多时，网络传输造成的延迟会超过节点多带来的好处。

如果我们设计新的代数体系和运算模型，就可能克服SQL的这些缺点，一方面更好地描述高性能算法，另一方面能充分利用当前的硬件资源，从而获得更高的性能。

不过，这样一来，对外的接口也就不再是SQL语法了，不能再兼容以往的代码了。

顺便提一句，新的运算模型并不是指当前业内的NoSQL，NoSQL并不是为高性能计算设计的，事实上它以牺牲计算能力为代价而换取了可横向扩展的能力，对于复杂大数据计算的需求而言是个倒退。

有没可能让高性能和兼容性共存呢？比如采用新的内核模型，然后基于它去解释SQL语法，或者能将SQL代码自动移植到新体系下。

理论上是可能的，解释或移植SQL是有不少工作量，但并不是非常困难。不过，这样做只能获得语法的兼容性，并不能得到高性能。高效的代码要针对运算模型的特征去编写，而SQL语法中并没有体现这些信息，一定要把SQL移植过来，仍然会面临前述的工程层面优化问题，没办法做得最优效果。事实上，两种均采用SQL的数据库，要让其特有的语法能够互相解释和移植，在不影响性能的前提下都是很难做到的。新兴的大数据厂商都愿意提供这种可移植的技术以降低老数据库的移植成本，但并没有多少成功者。

那么，结论是什么呢？

对于中短期目标的产品，那么继续采用SQL是合理的，这将有利于产品的快速应用，性能主要依靠硬件能力或更大规模的集群来提升。而面向长期目标的产品，那就有必要采用取代关系代数体系的运算型，为获得高性能，不能也不必再提供兼容SQL的方案了，需要忍受漫长的健全生态圈过程。