用SQL思考VS用Python思考

多年来，我已经使用过各种语言和工具来分析数据，当我回想起我使用每一个工具的时候，我逐渐意识到为了解决分析问题，每一个工具鼓励使用不同的思路框架。意识到这些框架对性能的提升和掌握一门新的语言或工具的技术特征同样重要。

我第一次接触到数据分析大约十年前作为一名大学生（尽管我的时间都花在了研究棒球票的背面）在学校里，以及后来作为一个经济学研究员，我曾几乎只用两个工具，Excel和R就能良好运行来自政府数据门户或学术来源下载的CSV或Excel文件。

但我开始专注于商业分析的新工作时，我被扔到一个全新的世界。我需要的绝大多数数据存储在数据库中。SQL成了一个必要的接入点。

首先，采用了新的工具，是具有挑战性的。不仅有一个学习曲线要与之抗衡，也觉得SQL有限制。我习惯了R的简便统计测试，可访问的绘图库和灵活的数据结构。在SQL中，即便是画一个柱状图这样简单的事，也需要一个完整的博客帖子来学习。

有一段时间，我通过修补工具保持这种灵活，并把查询结果导入RStudio。

从我SQL客户端跳转到R客户端，使得所有工作整合到一起变得困难。下载查询结果，并将其重新导入到R的痛苦使我的工作变成线性的-从SQL转换为R, 并且不会再转化回来。如果我想添加一个分析，我第一想法通常是，“也许我能找到一种方法处理而且仅仅依赖我已经有的数据。”知道这是从前在R中我的感受，我会在一个查询中加入很多我一开始不需要的数据。我找到答案很慢，而且往往留下未发掘的有问题的行。

随着时间的推移，当我对SQL越熟练  ，我开始体会到它的好处。它的严格有力推动一致性，这对标准化的业务指标是有价值的。计数和简单的聚合，是SQL所擅长的，影响商业决策往往是足够了。最后，我发现自己在我的工作流程中放弃了R。考虑到SQL到-R的工作流程是如何支离破碎的，R的灵活性是抵消不了SQL到R的转换代价。而当我真的错过了一些东西在R，我经常会找到一个繁琐的解决方法，通常能使任务完成。

当模式团队开始工作整合Python Notebooks和我们的SQL编辑器时，我被拉回使用脚本语言来分析。不过这一次，切换工具的痛苦得到减轻—操作情况是把SQL结果传递给Python没有任何导入或输出。突然感觉就像另一个世界再次打开。

但随之而来的，仍然是另一种思考方法和一种新的思维框架要学习。而这个新的工作流程的好处是，这在很大程度上为我SQL至R工作流程转换提供了没有代价的好处，使这种转换显然是值得的，还有我以前知道的一些事会变得容易得多。

不用知道SQL所有的知识是可以的

SQL是一个相当有限的语言。查询几乎只使用一些组合联接，聚合函数，子查询和窗口功能。

这就像建造的东西需要一组基本的积木块。我可以创造惊人的，复杂的，和原创的东西，但我很少发现有些积木块, 我有, 但是我我从来不知道。

Python，相比之下，就像是一个专门的积木块组的集合。每个库都有自己定制的块为建设某事非常专门化：Seaborn负责视觉效果，pandas进行分析，scikit-learn用于机器学习，等等。

这些库添加了非常多的功能。几十行的SQL（或者一点都不能），现在只需要一个Python的方法。但是，这个方法做了什么我就不完全清楚了。通过SQL，如果我沿某种路径操作失灵，我可能发现一个更好的方式来重新安排我正在做的。在Python，相比于修改我调用的方法, 我更可能是去寻找一个新的方法.

去谷歌上查询

“ Python社区 ”，是一个庞大而蓬勃发展的群体, 这个群体产生了这些专门的块。而“ SQL社区”是......微软和甲骨文的SEO素材。造成这种情况的原因尚有争议，但效果是明显的，在网上找到真正支持Python的资源相对更容易。

或许更重要的是，Python中的结构适合在该SQL斗争方式发现答案。因为Python有更多的块，从它工作的数据来看，它倾向于更抽象。人们可以轻松地共享库和脚本块。有人分享了如何创建一个箱线图例子并可以提供的代码，并说：“在这里传入你的数据。”我可以用飞行数据集，应用pandas.boxplot()方法去学习如何创建箱线图，然后转身使用.boxplot()为其他应用程序的用户数据画箱线图。

SQL查询，在另一方面，紧密与数据联系在一起。我必须知道表和列名称对查询可以产生任何意义。这往往会使共享例子更难。向一个人展示如何做一个箱线图用SQL需要共享数据才会有意义，这有可能使人们更不愿意分享自己的工作。

包容黑盒子

给我足够的时间，我可以理解一个SQL查询在做什么。因为所有的块通常是熟悉的，因为查询是自包含的实体不能把工作外包给外部库，我可以把全范围查询最终拼凑在一起和“获取”它。

创建或查看一个Python notebook的时候，有时我必须承认，我永远也不会完全知道发生了什么。要了解一个SciPy的功能，例如，我必须仔细查阅一大堆文件或多层源代码。实际上，我根本不会这样做。相反，我更经常发现操作像试一试，插入，看看他们返回结果是否符合我的要求。

不足之处是有如此大量的社区资源和库。对Python没有什么必然不妥的（并且它不像任何人，真正的，充分理解地球上分组依据什么），但对Python，我常常发现自己更倾向于相信结果是对的，尤其是在技术文档比代码本身更难理解的情况下。

创建分析网

在SQL工作时，查询常常呈线性发展。我主要使用SQL从大型数据集进行数据的聚合和联接设置这样一个流程：

1.把一堆表格联接一起。

2.把数据聚合成更小。

3.加入更多的表。

4.再次聚合。

5.依此类推，直到我能得到一个产生12行数据的巨型查询。

虽然这些查询可能会很长，他们往往在心里并不难模仿—数据通过子查询线性移动。数据就像一个雪球往下坡滚，随着它的运行，它运行收集和压缩更多的表，它一直滚动，直到它转变成成一个完美的雪球（或产生灾难性的雪崩）。

Python进展更加流畅。我经常采用一个初始数据集，并将其分解成许多较小的数据集，并且每个成为分析的线程。我可以把这些线程结合一起，并且以不同的方式将它们拆开。

这要求我在心里模仿我的分析像一个分析网一样，这是很难的事情。我不能再想，“我最左边表格是什么？我该怎么联接它？“相反，我不得不思考，”什么是分割成许多视图的最好表？我怎样才能把这些视图融合到有用的某事中？“与Python的“块”的例子相对应，“网”的思考方式提供比SQL更宽松的框架，它可能让习惯了严格思维的人感到一点不适。

急速改变

SQL的线性性质意味着，如果我想将一些透视图添加到我的分析，最好在一开始引进，不然我不得不备份我的查询，然后总是放弃传递的结果。这是麻烦的，即使它是通过几层子查询来添加列一样简单。

在其他情况下，从一个基础的查询出发计算多个目标时, 需要创建一个多个目标的核心查询。这些独立的查询以后会变得难以合并，这使得一些通用的修改我必须尽早进行，否则后期我就要在每一个查询中都修改一遍。

Python的Web-based的工作流的好处是，我可以更轻松地快速改变，迭代更快。东西在不同点可以添加和删除，当它们出现在相同的工作流程，能让我去探究问题。由于每个分析探索可以指向相同的核心，它更自然地在不同的分析点之间移动。

此外，通常情况下，它只是运算速度更快。没有什么事比只写一个长时间运行的SQL查询仅仅为了找到我想要把一个附加列添加到最外面的查询更令人沮丧了。Python允许我直接把这个改变应用到最后一步，而不必通过每次重新运行整个操作。

欢迎改变

最终，我在此过渡期间面临的最大障碍是惯性。SQL是我的安全默认值。即使SQL查询比同等的Python脚本慢十倍，我已经理解的方式，感觉更容易做到这一点。学习是比打字困难。

但是坚持你知道什么是小事精明，大事糊涂。学习一门新的语言，不仅提供了新的工具，同时也开辟了在精神上来思考数据和分析模型新颖的方式。这可能会导致你提出和回答你从来没有考虑过的问题。