为什么 SQL 需要软件库

尽管他们尝试，SQL（结构化查询语言）的批评者从未真正能够削弱其受欢迎程度。在创建几十年后，世界上大多数数据库仍然在SQL上运行，大多数数据分析仍然通过SQL查询进行。说数字世界在SQL上运行并不算太夸张。

然而，尽管它很受欢迎，但SQL确实有一些缺点限制了它的实用性 - 即使对于高级用户也是如此。在对Fivetran联合创始人兼首席执行官George Fraser的采访中，我们讨论了其中之一：SQL没有一个开源软件库生态系统来处理某些常见用例，并且可以在流行的SQL系统中工作。因此，在一个 SQL 数据库上学到的技能可能不会转移到另一个 SQL 数据库，并且正在编写太多复杂的查询。

由于SQL生态系统的运作方式，这是一个棘手的问题，但这样做可能会催化数据分析创新的全新时代。弗雷泽认为一个可能的解决方案就在我们的眼皮底下。

未来：所以每个人都能跟上，你能简单解释一下SQL是什么吗？

GEORGE FRASER：SQL是一种编程语言，仅用于与数据库交互。它无处不在，几乎存在于每个软件应用程序的掩护之下。如果你加载你的Facebook提要，所有关于谁评论了什么，你叔叔刚刚发布的数据，都存储在一堆SQL数据库中。当你加载页面时，一大堆SQL查询就会触发并获取所有这些数据。

例如，如果您正在修理汽车，那么情况确实如此 - 有关对汽车所做的工作的数据可能存储在某个地方的SQL数据库中。我们现在正在进行的这个Zoom调用，我敢肯定SQL数据库中有一堆条目表示此调用。真的，世界运行在SQL上。

结构化信息 - 在社交媒体帖子的情况下，可能是“名称”，“帖子内容”，“发布时间”，是否包含图像之类的内容 - 通常存储在SQL数据库中。还有其他类型的数据库，但与SQL数据库相比，它们的使用量很小。

然而，人们总是抱怨SQL做不到的事情，或者SQL不能做。为什么？

我忘了原来的说法是什么，但它是这样的，'有两种技术：人们抱怨的技术，以及无关紧要的技术。因此，数据库管理系统和SQL（99%的时间用于与它们交互的语言）是计算机的首批应用程序之一。当人们发明计算机时，他们做的第一件事就是发明数据库，因为你可以用计算机做的最有用的事情之一就是存储一堆数据，更新它，检索它，并总结它。所以，它可以追溯到很久以前。

SQL本身是在70年代创建的，它有很多伟大的特征。它非常成功，并被广泛采用。这有点像我们呼吸的空气。在这一点上，对于技术人员来说，这就像向一条鱼询问水一样。

人们抱怨它，因为它并不完美。什么都不是。但是由于一系列原因，很难改变。它的一些缺陷确实已经存在了很长时间。

软件库
执行特定和明确定义的操作的代码，通常是在应用程序或语言的本机功能之外或之上执行的。流行的库的例子包括用于Python数据分析的pandas，用于使用Apache Spark进行机器学习的MLlib，以及用于在SQL中处理地理数据的PostGIS。

其中一个缺陷，你已经写过，是SQL不是一种库语言 - 你不能轻易地使用它的软件库。为什么这是值得解决的问题？

如果我倒退一步，SQL会有很多问题。其中一些是小问题，可能不值得解决。人们喜欢指出 - 这是一种程序员内部棒球 - 子句的顺序可以说是错误的，如果它有不同的顺序会更好。但在这一点上，这不是一个大问题，改变还为时已晚。我认为这是一个小问题。这是有原因的，为什么这没有被证明是SQL的致命缺陷。还有其他类似的事情是小问题。

但我认为SQL有一个非常大的问题，那就是它不是一种库语言。开源软件革命改变了我们构建其他所有类型软件的方式，但它并没有来到SQL。

当您尝试将 SQL 用于分析工作负荷时，这一点尤其重要。当你使用SQL时，不需要库，就像我在Facebook上的数据示例中使用的一样，或者关于你的汽车维修的数据，或者关于我们现在正在进行的这个电话的数据。您所要做的就是提取记录并一次更新一个记录。它不是图书馆语言，但谁在乎呢？

但是，由于世界上99%的重要数据存储在SQL数据库中，因此人们使用SQL不仅仅是检索数据的一种方式，而且是实际汇总和分析数据的方式。当分析师编写SQL时，他们编写大型SQL查询，这些查询具有很大的复杂性，并且会做一些花哨的事情，例如滚动平均值以及您能想象到的一切。在那里，没有开源SQL生态系统，它不是一个好的库语言，这是一个大问题。因为每个使用SQL分析数据的分析师都必须从零开始。

这就是我们仍然生活在SQL的世界，但我认为有一条出路。

分析数据库
分析数据库用于通过仪表板、报告和其他数据分析方法为业务决策提供信息。这与事务数据库相反，事务数据库通常读取，写入和获取应用程序数据以响应事件（例如某人在线进行汽车维修预约）。

为什么SQL没有软件库的生态系统？

我认为有两个原因。一个是SQL实际上不是一种语言。每个实现SQL的数据库管理系统（其中有很多）都实现了略有不同的SQL。如果我们专注于分析，我们谈论的可能是10个数据库。这只会让它变得更加困难，因为无论你做什么，你都必须做10次。

另一个原因是没有办法分发SQL。即使你为一个特定的数据库写了一个很棒的开源SQL库，你怎么能把它交给其他人呢？没有用于 SQL 的包管理器。Golang有一个内置的包管理器。Rust 有 Cargo。Java有Maven。每一种编程语言都有一些包管理器，这些包管理器要么是首先用编程语言创建的，要么是实现了社区采用或逃逸速度，它成为事实上的包管理器。这就是你共享代码的方式，直到最近，SQL还没有包管理器。

实际上有几个用于SQL的开源库。我最喜欢的例子是PostGIS，这是我所说的例外。它是Postgres处理地理数据的库，这是很多人想要做的事情。尽管有所有这些障碍，但它对一小部分人非常有用 - 这是你做新事情时真正需要的，你需要吸引很多人，而不是对每个人有吸引力 - 他们会按照网站的说明在他们的数据库上安装二进制文件。然后大型云供应商，因为PostGIS很受欢迎，只是将其与他们的数据库预先打包在一起。因此，通过英勇的努力，人们能够采用SQL库的一个示例，用于SQL Postgres的特定风格。

但是，如果你看看这个例外，你就会发现问题：很难获得开源SQL库的分发。

鉴于SQL生态系统的运作方式，您如何解决这个问题？

我认为解决方案是dbt，一个构建工具和SQL的包管理器。包管理器是程序员共享代码的一种方式。我可以编写一些代码，我可以将其发布到包存储库，然后您可以使用该代码。

构建工具有点难以解释。如果你是一个程序员，你写了一堆代码，你的工作就没有完成。总是必须做一些事情才能将代码变成实际执行某些操作的东西。您需要将该代码部署到数据库中，以 dbt 为例。或者你需要将代码编译成一个程序，或者上帝知道什么。总有某种构建步骤，你采用这个代码，它基本上是一个人写的一堆文本，你把它变成真正有用的东西。就 dbt 而言，它的作用是将该代码部署到数据库中，以便它实际上开始在现实世界中执行操作，而不仅仅是坐在屏幕上看着你。

现在，如果dbt成为实现这一目标的平台，它需要几乎无处不在，我认为这可能发生。SQL分析师从未真正拥有过好的开发人员工具。他们只有这些专有的东西，这些东西是由试图向他们出售数据库的公司制造的，或者不管它是什么。我经常开玩笑说，dbt是分析师的第一次良好关系，所以他们都非常忠于dbt。

我们已经开始在某种程度上看到这种情况发生，尽管这不是我们正在谈论的完美例子。但是，例如，Fivetran创建了一个库，可以在我们的数十个dbt模型中重复使用，因此用户不需要重新安装并重新学习他们想要使用的每个模型的相同内容。碎片问题（每个数据库管理系统实现的SQL略有不同）应该在数据库级别上是可管理的，因为如果您针对的是使用SQL进行数据分析的分析师，那么您基本上只针对Snowflake，Databricks，BigQuery，Redshift和SQL Server。也许其他人会突破，然后还会有一个，但这是一个合理的数字，它不是一千个。

“开源软件革命改变了我们构建其他所有类型软件的方式，但还没有来到SQL。

SQL数据库已经存在了很长时间，那么在过去几年中发生了什么，我们现在需要更多的库和更好的整体开发人员体验？

我认为这是SQL数据库在分析工作负载方面的性能。几年前，除了非常昂贵的SQL数据库之外，还没有足够快的SQL数据库来应对复杂的分析工作负载。因此，当您想要对大量数据执行复杂的分析工作负荷时，您需要将数据从数据库中取出，并将其放入专用工具中，通常是一个经过优化的 OLAP 多维数据集，可以非常快速地执行非常具体的查询。这些 OLAP 多维数据集都有自己的语言、工具、GUI 等。它在很大程度上是一个商业生态系统，而不是像SQL那样以单一语言为中心。

然而，在过去的10年中，SQL数据库在分析工作负载方面变得如此快速和便宜，以至于其中很多数据库都已向下移动到数据库中。您将连接到的许多这些特殊用途的数据分析工具都消失了。数据库本身就足够快，在某些方面更好，因为它更灵活，所以人们开始在数据库上进行大量分析。这导致了更多的SQL代码和更复杂的代码，这就需要一种更好的方法来组织和构建它。

以前，每个人都只是使用临时SQL构建过程。它可以像将一些代码从一个地方复制和粘贴到另一个地方一样简单，然后按下按钮来运行它。如果你的代码不是那么复杂，并且整个公司中只有两个人在处理这部分代码，那么这将工作正常。但是，当人们开始在数据库中进行从汤到坚果的分析时，他们需要像dbt这样的东西。

假设你的理论取得了成果，你认为什么会为有用或流行的SQL库带来什么？

时间序列分析可能就是这样。在SQL中使用内置功能（如窗口函数）进行滚动平均值之类的事情是非常尴尬的。

另一个真正有用的开源库，我希望看到它是近似聚合。这是存在于所有这些不同数据库中的东西，但它通常不是很用户友好，所以他们几乎不使用它。或者它只是对于不同的系统不同，所以没有人会费心去学习;他们只是学习常规平均值。而且，男孩，如果有一种统一的方式来做近似的聚合案例，那就太好了。如果有人能围绕流行系统的内置近似聚合功能编写一个友好的包装器，然后作为用户，你可以使用它，那就太好了。

“开源代码是软件开发的绝对革命，所以对于SQL开发人员来说，同样的事情也可能发生 - 它可能是催化剂。

如果这个想法流行起来并变得非常受欢迎，对SQL生态系统的净影响是什么？

好吧，开源代码是软件开发的绝对革命，所以SQL开发人员也可能发生同样的事情 - 它可能是催化剂。你可以看到这些广泛使用的库的出现，每个人都在学习并列出他们每天在工作中使用的LinkedIn配置文件和使用情况。它使分析师的工作效率更高：一位分析师，完成的工作是他们的两倍，因为他们正在利用他们已经使用多年的开源代码。

这也可能导致更少的错误，因为你写的每一行代码都是犯错误的机会。你越能利用经过广泛测试的东西，你犯的错误就越少。这些都是在Java和C++和其他语言中发生过的事情，它只是在等待在SQL中发生。

你提到了LinkedIn。一套标准的工具和技能对于换工作的员工和试图招聘的公司来说似乎也很有价值。

这是巨大的。每个人都想从技术维度的角度来考虑这些事情，但开源代码最重要的元素之一是你可以随身携带它。你一次学会了如何使用这个库，如果它足够受欢迎，你的下一份工作也很有可能也会使用它。因此，它为个人学习这些东西创造了更多的动力，因为他们不必担心如果他们换工作，这些知识将在几年内变得毫无用处