有人意图取代 SQL，你同意吗？

SQL 作为一种关系型数据库广泛都在使用的标准处理语言，由于其优秀的表现已经获得世界范围内厂商和用户的普遍认可。如 MySQL、Oracle、SQL Server、Sybase、Informix 等。甚至在 IEEE Spectrum 2022 年顶级编程语言榜单中，SQL 在就业需求中位居第一。

偏偏就是这样一个“德高望重”的 SQL，就有人想取而代之。大家都很好奇，到底是谁有这么大的胆子？ 为什么它就敢取代 SQL？

友情提示：麦聪DaaS平台为您提供数据统一管理和统一服务平台，加速企业数字化转型进程，目前已获得全球近400家企业客户的使用，其中30多家为世界500强企业，欢迎大家到麦聪软件的官网下载免费试用版本。

认识这款要取代 SQL 的工具

要取代 SQL 的是一款开源工具 DBT（Data Build Tool）。有不少人诧异，DBT 究竟有什么的魔力。这里我们来稍作解读。

这是一款用 Python 语言编写的开源软件工具，帮助数据工程师编写选择语句来转换数据平台中的数据，通过 SQL 实现数据转换，将命令转化为表和视图。

因此，DBT 非常适合现代 BI 堆栈，与 Stitch、Fivetran、Redshift、Snowflake、BigQuery、Looker 和 Mode 等产品结合使用。

值得注意的是，DBT 主要聚焦于 ELT（提取、加载、转换）中的 T（转换数据）环节，它不提取或加载数据，但设计为在转换仓库内已经存在的数据时表现出色。DBT 结合了 SQL 的优势，将 DBT 项目变成了 SQL 的编程环境，并提供编程语言。例如在 SQL 中通常无法实现的写函数和控制结构。这意味着数据工程师无需再学新的语言或工具，可以自由地转换数据。

由于现代分析数据库的强大功能，ELT 已变得司空见惯。Redshift、Snowflake 和 BigQuery 等数据仓库具有极高的性能和可扩展性，因此此时大多数数据转换用例可以在数据库中而不是在某些外部处理层中更有效地处理。再加上计算和存储的分离，想要在其他地方执行数据转换作业的理由越来越少。

从这些表现来看，DBT 确实在 SQL 的基础上简化了 SQL 的使用门槛。

根据媒体报道，目前使用 DBT 的企业其实不在少数，全球已有超过 759 家公司，包括与 ASICS、Autodesk、DocuSign、Forever 21、WeWork 和 Urban Outfitters 等知名企业。除此之外，DBT 还支持数百个数据库的连接，如 IBM、Oracle、SAP 和 Snowflake 等。

大家为什么吐槽 DBT 取代 SQL？

任何事物都有其生命周期，SQL 也不能例外。所以，即便 SQL 有一天退出历史舞台也没什么可惊讶的。

既然 DBT 这么优秀的表现，大家听到 DBT 要取代 SQL 为什么还会纷纷吐槽，甚至反对呢？

这背后的导火索源自一位知名 Twitter 博主（Cogniti 首席技术官 Matthew Mullins）的一条推文，大意是：DBT 背后的商业团队推送一封邮件强迫用户转向 DBT，放弃 SQL。

一石激起千层浪，这个事情让大多数开发人员表示愤怒。

从使用成本角度来看，SQL 支持不需要任何额外的基础设施，但使用 DBT，用户只能创建表和视图，还需要支付额外的基础设施来运行 DBT，甚至支付培训费用。

从产品功能上来看，DBT 还有很多不足之处。诸如，DBT 仅涵盖 ELT 中 T 这部分，因此用户仍需其他工具来执行提取和加载部分以完成序列；有时候需要重写后端使用的宏，而覆盖 DBT 这种标准行为需要处理源代码的知识和专业知识；UI 确实帮助用户实现可视化数据转换，但对数据工程师更为重要的是需要保持其干净和易于理解。

最为重要担忧是，数据工程师并不希望 SQL 还要依赖任何第三方平台。原本 SQL 是一个行业标准语言，这无可厚非，但是 DBT 只是一个受欢迎的开发工具而已。

简单来说，开发者可以相信一个行业标准，但是如果去依赖某个开发商就显得挺危险的。

对于这样一款意图谋取 SQL 宝座的开源工具，你是怎么看待的呢？欢迎发表你的评论。