当前的大数据平台在处理结构化数据时大都仍然以提供 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 并不是为高性能计算设计的，事实上它以牺牲计算能力为代价而换取了可横扩以及方便写的能力，对于复杂大数据计算的需求而言是个倒退（当然这也不是大部分 NoSQL 的目标）。

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

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

那么，结论是什么呢？

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