传统SQL和现代数据实践结合:SQL是不是没有那么酷了呢? - tselai


在年轻的数据从业者中,越来越多的人认为SQL不是“很酷”,不够好甚至更糟,认为“ SQL不够专业,真正的数据科学家应该编写代码”。然而,自己的经验却使我对此反感。无论是在数据收集和清理等管道的最初阶段,还是功能工程和报告生成的后期阶段,我都开始欣赏SQL的强大功能和多功能性以及RDBMS的有效性。
实际上,不仅吸引我的是SQL和RDBMS的工具性质,而且吸引和涵盖了它们的整个“ SQL传统”。自从Codd在70年代引入关系模型以来,实用主义的水平就建立并推动了数据管理。
在本文中,我收集了有关SQL主题及其如何适合现代数据实践的一些想法。上周我在一次演讲中遇到了一波难以置信的动机,当时我声称现代数据项目可以通过尽早采用SQL并坚持使用SQL来极大地受益:“从SQLite开始,以Postgres扩展”的理念。

再使规范化规范
现代NoSQL系统的无规范结构本质实际上消除了对具有深思熟虑的数据模型设计的需求。您可以将数据转储到灵活的“文档”“集合”中,而不是更严格的“行”“表”中,然后使用功能强大的查询语言来提取所需的内容。为什么要这样做?因为您可能无法预料以后需求将如何变化,所以在RDBMS中更改架构可能会很棘手。听起来很公平。理论上肯定是这样。
但是,我与现有NoSQL部署的合作越多,我越相信它们的无结构本质已成为借口和不愿事先停留在项目数据模型上的借口。
我看到太多的应用程序从零时开始就依赖MongoDB作为其主数据库来处理“普通的”事务数据。然后逐渐地,他们最终不得不“转换特定集合的字段”,“创建充当锚点的中间集合”,或者更糟糕的是通过cronjob进行转换而提供“其NoSQL数据库之上的表格层”的调试项目。
将数据以表格格式导入关系数据库,甚至引入“每个人都应该使用的Python库,以便以表格格式获取数据,因为这就是Scikit-Learn所期望的”。
如今,大多数主要的RDBMS确实提供了某种无结构的支持,通常使用具有丰富查询语义的JSON数据类型。
这种方法的好处是,可以在不牺牲ACID一致性的情况下为它们的结构化和非结构化数据提供一个数据库。既可以在引用级别(即外键)确保数据完整性,又可以通过约束,索引和触发器来严格管理数据质量。

使ETL更接近数据
ETL是现代数据驱动型工作的资金消耗机器,并且是每个数据科学家日常生活中必不可少的恶魔。然而,这可能是数据管道中不那么周全的想法。无数机器学习工程师带着使用随机森林和支持向量的希望开始了他们的模型选择工作,直到后来才意识到没有足够的干净数据可用,他们不得不使用简单的回归。
我认为,如果将更多的数据清理过程推到数据库级别,则数据管道将更加平滑和整洁。
让我们关注关系数据库的另一个典型特征:触发器和存储过程。它们都可以成为数据清理和转换工具箱中的重要工具。
由于必须在固有的声明性环境中编写过程代码,因此数据库服务器编程以前很难适应。但是今天,情况有了很大的改善:语法变得更加甜美,甚至可以使用过程语言来编写其触发器和存储过程函数。使用Postgres,甚至可以在数据库中编写Python和Perl代码!

SQL功能强大
我的经验表明,我在查询级别创建的功能越多,在尝试使用不同的功能向量时就具有更大的灵活性,并且模型选择和评估越快。编写查询时,数据库将成为画布,您可以在其上绘制漂亮的模型。无需在磁盘和内存之间跳来跳去,也不需要在数据库和熊猫之间跳来跳去。您可以自由组合来自不同表的数据,在各个列之间执行简单或复杂的操作,并让查询优化器为确定为您创建数据集的最佳方式进行繁重的工作!
SQL和关系数据库已经走了很长一段路,如今,它提供了数据科学家可以要求的几乎所有功能。Postgres(甚至包括SQLite和其他主要的关系数据库)提供了一些文本处理功能和自由文本搜索功能,这些功能足以满足大多数应用程序的需求。这是否消除了对NLTK或ElasticSearch的需求?绝对不。
但是,在利用SQL方面有一些警告。首先,由于其声明性,SQL几乎总是会为您提供结果,但它们可能并不是您所要的。SQL要求细致和谨慎,因为调试非常困难。您无法打印“我在”以检查是否存在错误的循环条件,等等。实际上,您只能进行的调试是检查执行计划并对其进行反向工程。
在另一个“文化”方面,我注意到的一件事是,诸如“干净代码”和“可维护性”之类的最佳实践和概念在SQL世界中并不那么普遍。我可以将其归因于许多方面,但我只是强调一个事实,即太多“商人”使用SQL。他们将其视为“获取数据的临时工具”,这种方法是正确且务实的,但是我们应该尝试引导他们将SQL用作代码库,该代码库将被其他人使用,并应被用作实现以下目的的工具:与数据库和其他程序员进行通信。

关系数据库具有成本效益
关系数据库通常在财务上也更有意义。像MongoDB和ElasticSearch这样的分布式系统非常耗钱,可能会浪费您的技术和人力资源预算;除非您绝对确定并已经计算了数字,并认为它们确实对您的情况有意义。

以上只是挑选摘录,详细点击标题见原文。