为什么谷歌把SQL当代码对待？你也应该这样做！

过去 2 年中，作为一名谷歌的供应商，我观察到谷歌的数据工程师（Data Engineers）对待 SQL 的方式与软件工程师（Software Engineers）对待代码的方式相同。这种好的心态可以整合到所有公司（不分大小）的数据战略中。

在本文， 我将介绍谷歌从将SQL视为代码中获益的方法，并讨论一些具体方式，让所有公司都可以从这些原则中受益。如果你想了解更多数据分析相关内容，可以阅读以下这些文章：
数据分析新工具MindsDB–用SQL预测用户流失
DS数据科学家和DA数据分析师：要学习什么不同内容？
Pandas和SQL，数据科学家应该用哪个？
这六个SQL小技巧，让你的分析效率突飞猛进！

SQL 明明是一种查询语言，那为什么谷歌会将其视为代码？

就像面向对象的编程一样，SQL 写起来也很费时间，调试起来很费劲，不太好理解，还可能会导致版本控制出现问题，又必须保持可维护性。从我观察到的这个谷歌部门来看，SQL 还被用来创建数据管道。当数据管道发生故障时，SQL必须要方便使用，可以轻松修复漏洞，才能顺利修复数据管道。很明显，考虑到所有这些因素，代码的集中化必须是数据战略的核心组成部分。

借助代码管理工具有另一个好处：可以很容易了解谁在更改、或谁在维护 SQL 脚本，并跟踪该作者对其他相关查询的更改。可以快速轻松地找到存在问题的代码提交，并恢复更改或进行相关的修复。

提交 SQL 代码后，代码会立即部署到开发环境中。然后执行开发管道，并立即识别并修复故障。每天晚上，都会发布一次 UAT，并优化代码，确保代码通过了生产版本。每周都会发布一周内提交的所有SQL的产品版本，在这个阶段，几乎没有失败版本。

小公司能做些什么呢？

观察你公司的软件工程文化；由于谷歌公司的文化可能更加成熟，因此，你需要了解并使用他们会用的工具，如 Git、IDE 等，并开把将所有代码都放到索引的位置。然后花时间将脚本从本地位置迁移到全局位置，消除视图、物化视图和存储过程。

谷歌如何使用工具管理 SQL 代码

Google 在一个集中单一的代码存储库中，管理着基本上所有的代码。如果需要对 SQL 作出更改，或者创建一个新脚本时，谷歌就会创建一个更改列表；本质上类似于拉取请求。然后，这些通道必须经过测试后，由另一名工程师批准。审阅者签字批准后，作者就可以把代码更改提交到存储库中。

尽管变更控制在许多公司都很常见，但我在谷歌观察到的一个关键区别是代码格式化的重要性。虽然我以前对代码格式不太重视，但格式良好的代码大大减少了理解、调试和修改其他作者的代码所需的时间。谷歌非常重视代码的格式，因此有了自动拒绝不符合编程标准的更改的机制。

小公司能做些什么呢？

选择一个代码存储库，并坚持使用这个库。理想情况下，代码存储库应该与工程部门共享，如果做不到，至少应该把所有 SQL 代码集中在一个存储库中，其中包含所有数据功能，例如数据工程、分析、商业智能，同时采用代码格式的标准化。

现在，开源代码格式化工具非常多，这些工具用起来很方便，并且极大地提高了代码的可读性和可维护性。花必要的时间（或编写必要的工具）通过格式化工具运行之前的代码，并要求之后的代码要符合格式化标准。在短短几天或几周内，所有数据工程师都要采用该标准，让 SQL 变得更易于阅读、编写和理解。

为什么版本控制和环境可节省每个人时间

如果公司经常做出更改，在没有版本控制的情况下，很容易出现无法弥补的回归。但有了版本控制，如果提交的代码破坏了管道、出现了预料之外的值或无法执行时，可能很难识别出所做的精确更改。这一原则与谷歌的代码集成方法相吻合。当在结构良好的环境中批准不需要的更改（这种情况一直都存在）时，业务不会受到干扰。SQL 更改在提交时会直接影响开发环境，从而可以及早发现故障。

在开发中，虽然代码更改成功（不会立即出现故障），但极少数情况下，很有可能会导致生产失败。这可能是由多种因素造成的。在本例中，UAT就作为一种预生产环境被引入。

谷歌使用可以注入表格名的变量来管理以上情况，看起来像这样：domain.table.environment.name${environment}

小公司能做些什么？

至少要实现一个开发环境。在组织数据基础架构的更大范围内测试代码，可以确保将故障概率降至最低。免费的开源工具（例如 DBT）添加了一个抽象层，让这个操作更加简单。所有表都可以存在两次；一次作为开发表，再次作为生产表。在每日、每周或每月发布计划中，自先前发布计划以来提交的所有代码都可以升级至生产环境。

广泛访问代码

谷歌最出名地就是利用单一的代码存储库存储所有代码。有时，可能很难弄清楚一个产品的所有消费者都有谁。例如，软件工程师可能正在更新生产应用程序，如果没有广泛访问的集中代码库，他们可能不知道这些更改的下游后果。通过集中化处理，他们可以轻松搜索可能依赖于其应用程序生产的脚本、查询和其他应用程序，并通知相应的工程师，或协作进行同步更改。代码保密是脱节开发的秘诀。

虽然，一些用于高度敏感项目的代码存储库可能不会被广泛可见，但这种代码储存库很少，并且仅适用于一些最极端的情况。虽然谷歌的代码库规模很大，但代码架构始终是建立在信任的基础上；你的代码库也应该做到这样。

小公司能做些什么？

更加信任你的代码库和存储库，增加沟通。你的项目不需要像你想象的那么神秘；从工程的师地角度来看，你不要雇用你不信任的工程师查看你的整个代码库。同时，鼓励软件工程和数据工程之间的更多协作，并且在代码投入生产之前，解决下游后果的内置流程和程序。

希望通过分享我对谷歌SQL的观察，能让你有所启发。感谢你的阅读！

原文作者：Galen B
翻译作者：Lia
美工编辑：过儿
校对审稿：Jiawei Tong
原文链接：https://blog.devgenius.io/why-google-treats-sql-like-code-and-you-should-too-53f97925037e