SQL语言作为计算机历史上最早的数据库查询语言之一，其标准诞生于1986年，发展至今已有近四十年历史。原本人们期望经过数十年积淀，数据库厂商和实现者能够围绕统一规范凝聚成一套稳定、统一的SQL标准。然而现实却恰恰相反——今天，SQL方言如雨后春笋般层出不穷，新的变种不断涌现，而各大数据库厂商则持续为其产品添加专属扩展功能，导致SQL语言生态堪比《巴别塔》，呈现出无法统一、相互难以兼容的局面。SQL方言之间存在着多方面的巨大差异。语法层面上，例如MySQL有时允许省略GROUP BY子句，而其他数据库则不允许。支持的操作符种类不一，像GROUPING SETS、ASOF、ROLLUP、PIVOT、QUALIFY、MATCH RECOGNIZE、LATERAL和UNNEST等高级功能的支持情况各数据库差异明显。
法律合法的语句集合也不相同，诸如MySQL允许在GROUP BY中引用SELECT中定义的别名，但其他数据库则不允许。此外，SQL查询的语义在不同方言中也会产生不同的执行结果，比如对于NULL值在ORDER BY中的排序规则就存在显著差异。类型系统亦非统一，例如PostgreSQL的DECIMAL数据类型拥有几乎无限的精度支持且能处理Infinity值，而其他数据库则不同。基本操作符的行为也不尽相同，SQLite中表达式“+x”不执行任何操作，而MySQL中则把x强制转换为整数。标量函数的实现各异，SUBSTR在MySQL、Oracle、谷歌大数据以及PostgreSQL中的行为大相径庭。以上差异仅限于查询语言层面，尚未涉及查询引擎及底层执行机制的复杂度。
作为系统设计者，如果想要打造一款新的数据库或查询引擎，首要面临的挑战是选择支持哪种SQL方言。由于方言的复杂和分散，决定将直接影响用户的采用成本与系统的后续发展。这一决策主要包含两条路径。一是全力支持已有具备广泛影响力的方言，如PostgreSQL、MySQL或Oracle的方言。这通常意味着有现成的文档、参考系统和开源组件可复用，降低开发成本和风险。对于用户而言，也更容易迁移和采用。
另一条路径是自创一套全新的方言体系，从无到有构建设计规范、语法解析器、优化器以及执行引擎。这种方法灵活度和创新性高，但代价巨大，风险明显，且会遭遇重重生态适应瓶颈。Feldera作为一家专注于新型数据库解决方案的公司，选择了基于Apache Calcite构建其编译器基础架构。Apache Calcite始于2016年，但其发展历史更长。Calcite的设计理念以标准SQL兼容性为基础，赋予系统高度灵活性，方便满足不断变化的市场需求。借助Calcite，Feldera能够支持来自Postgres、Sqlite、Databricks、Snowflake等不同数据库的SQL查询迁移，极大提升了用户的迁移便利度和兼容体验。
Calcite框架具有高度可配置的解析器，包含一套验证和类型检查工具、两个灵活的优化器、并拥有丰富的SQL代码生成模块，支持源到源的SQL转换，同时包含多种SQL方言的标量函数集合。这使得Calcite不仅能满足通用SQL程序的需求，还能满足多样化特定场景下的定制需求。Calcite提供了多个配置层级。解析器的行为通过SqlParser.Config配置，如是否区分大小写。SqlConformance配置用于模拟其他流行方言的粗粒度行为差异，比如GROUP BY中数字表示列号还是常量。SqlToRelConverter.Config和SqlValidator.Config分别控制查询从抽象语法树到关系表示的转换和验证过程中规范化行为。
Calcite包含了丰富的SqlDialect及其子类，如SqliteSqlDialect，用于代码生成阶段决定目标方言的SQL表示方式。Calcite更多用于源代码转换，而非限制程序的接收规则。同时，Calcite的类型系统以接口形式暴露，允许完全自定义。此外，其内建两套默认类型系统：RelDataTypeSystem面向泛型SQL，JavaTypeFactory则辅助生成基于JVM的可执行代码。测试过程中，Calcite通过将SQL编译成Java代码，再通过Janino Java编译器即时编译执行，实现静态类型检查。值得一提的是，Calcite支持动态类型方言，比如SQLite的加法操作结果类型取决于参数值。
优化器方面，Calcite采用模块化设计，所有优化规则实现统一接口，称为RelOptRule。任何人都能编写并贡献优化规则，构成基于Volcano风格启发式成本模型的优化引擎。开源生态使得用户可深入定制和扩展现有组件，极大增强系统适应性。然而高灵活度的设计也带来了复杂的学习曲线和较高的上手门槛。尽管如此，Feldera在基于Calcite的基础上成功扩展并贡献了多项用户需求的功能，包括ASOF连接、VARIANT支持、UUID、无符号数等，高效响应客户反馈。此外，当Calcite源码出现漏洞或错误时，Feldera团队能够快速修复并提交补丁，缩短发布周期，保证产品质量持续提升。
结合Calcite的架构，Feldera还实现了多种非标准特性，比如流式扩展和递归查询，虽然这些未直接回馈至Calcite主项目，但在自身开源库中彰显创新能力。作为一款增量计算引擎，Feldera注重与众多系统通过适配器连接，其SQL语法也借鉴多款数据库系统的设计理念，以便在SQL程序中直观表示连接器配置。考虑到测试复杂度及用户使用习惯，Feldera暂未将所有的Calcite配置选项开放给终端用户，从而保证行为一致性和稳定性。综上所述，SQL方言生态的复杂性与多样性是数据库行业长期面临的重要挑战。选择既有方言则可借助成熟的规范和生态，应对升级和兼容问题。而自定义方言虽具备创新潜力，却带来难以估量的市场风险与技术成本。
Feldera以Calcite为核心，积极拥抱多方言协同，通过开源和客户定制共同推动系统进化，实现了兼顾标准合规与业务扩展的良好平衡。未来，随着数据库技术不断演进，SQL作为核心查询语言必将继续面临多样扩展和融合调整的机遇与挑战。数据库系统设计者和应用开发者须紧紧抓住SQL的灵活性优势，同时警惕分歧与碎片化风险，持续探索最佳实践与创新路径。无论是选择现成方言，还是打造新方言，只有充分理解多样性根源和生态环境，才能在SQL的巴别塔中找到稳固基石，构筑能够满足新时代数据处理需求的高效平台。如果您希望让您的增量计算引擎拥有更丰富、更强大的SQL支持，不妨关注Feldera以及Apache Calcite的最新发展，探索定制化的解决方案。更多SQL方言与数据库技术的深入探讨，欢迎加入我们的社区，共同交流，携手迈向数据库创新的明天。
。
