用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有更多的塊，從它工作的數據來看，它傾向于更抽象。人們可以輕松地共享庫和腳本塊。有人分享了如何創建一個箱線圖例子并可以提供的代碼，并說：“在這里傳入你的數據?！蔽铱梢杂蔑w行數據集，應用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腳本慢十倍，我已經理解的方式，感覺更容易做到這一點。學習是比打字困難。

但是堅持你知道什么是小事精明，大事糊涂。學習一門新的語言，不僅提供了新的工具，同時也開辟了在精神上來思考數據和分析模型新穎的方式。這可能會導致你提出和回答你從來沒有考慮過的問題。