Python 可以完成某項任務(wù)，并不意味著這個任務(wù)就應(yīng)該使用 Python 來做。

作為一名 Web 開發(fā)人員，我第一次與數(shù)據(jù)庫和 SQL 產(chǎn)生交集是使用對象關(guān)系映射(ORM)。我使用的是 Django 查詢集 API，這個界面用戶體驗很好。之后，我轉(zhuǎn)向數(shù)據(jù)工程方向，更多地利用數(shù)據(jù)集來構(gòu)建 AI。我的職責(zé)是從用戶應(yīng)用程序中獲取數(shù)據(jù)，并將其轉(zhuǎn)換為數(shù)據(jù)科學(xué)家可利用的內(nèi)容，這一過程通常稱為 ETL (extract, transform and load)。

隨著產(chǎn)業(yè)發(fā)展，生產(chǎn)系統(tǒng)中的數(shù)據(jù)非�；靵y，需要進行大量轉(zhuǎn)換才能用于構(gòu)建 AI。有些 JSON 列每行模式都不相同，有些列包含混合數(shù)據(jù)類型，有些行有錯誤值。此外，還需要計算「用戶成為訪問者的時間」以及「他們在兩次訪問間的等待時間」等特征。當(dāng)我著手清理、聚合和管理數(shù)據(jù)特征時，我想確定哪種語言最適合該任務(wù)。在之前的工作中我每天都使用 Python，我知道它可以完成工作。但是，這次經(jīng)歷使我了解到，Python 可以完成一項任務(wù)并不意味著這個任務(wù)就應(yīng)該使用 Python 來做。

我對 SQL 的第一個誤解是：SQL 無法進行復(fù)雜的轉(zhuǎn)換

我們正在處理一個時間序列數(shù)據(jù)集，我們希望能夠跟蹤特定用戶。隱私法規(guī)不允許獲取用戶訪問的具體日期，因此我們決定將記錄日期歸一化為用戶首次訪問的日期(如首次訪問后 5 天等)。對于我們的分析，重要的是要知道離上次訪問過去了多久以及離首次訪問過去了多久。A 有兩個樣本數(shù)據(jù)集，一個有大約 750 萬行，大小為 6.5 GB，另一個有 55 萬行，大小為 900MB。

我使用下面的 Python 和 SQL 代碼先在較小的數(shù)據(jù)集上測試轉(zhuǎn)換。Python 和 SQL 分別花費 591 秒和 40.9 秒完成了任務(wù)。這意味著 SQL 的速度是 Python 的大約 14.5 倍!

 

 

SQL 轉(zhuǎn)換不僅速度更快，而且代碼也更易讀，更易于維護。在這里，我使用 lag 和 first_value 函數(shù)來查找用戶歷史記錄中的特定記錄(即分區(qū))。然后使用 age 函數(shù)來確定兩次訪問間的時間差。

更有趣的是，當(dāng)這些轉(zhuǎn)換腳本應(yīng)用于 6.5 GB 的數(shù)據(jù)集時，Python 完全失敗。在 3 次嘗試中，Python 崩潰了 2 次，第三次我的計算機完全崩潰...... 而 SQL 只耗時 226 秒。

更多信息參見：

https://www.postgresql.org/docs/9.5/functions-window.html

http://www.postgresqltutorial.com/postgresql-window-function/

我對 SQL 的第一個誤解是：SQL 無法扁平化不規(guī)則的 json

對我來說，另一個改變是我意識到 Postgres 可以很好地處理 json。我最初認(rèn)為用 Postgres 扁平化或解析 json 是不可能的...... 我不敢相信自己竟然如此愚蠢。如果你想關(guān)聯(lián) json 并且它的模式在行間是一致的，那么最好的選擇可能就是使用 Postgres 內(nèi)置功能來解析 json。

 

 

另一方面，我的樣本數(shù)據(jù)集中一半 json 不是有效的，因此存儲為文本。在這種情況下，我要么重新編碼數(shù)據(jù)使其有效，或者刪除無效的行。為此，我創(chuàng)建了一個名為 is_json 的新 SQL 函數(shù)，然后使用該函數(shù)來驗證 WHERE 子句中的 json 是否有效。

 

 

不幸的是，我發(fā)現(xiàn) user_json 具有不同的模式，具體取決于用戶所使用的 app 版本。雖然從應(yīng)用程序開發(fā)的角度來看這是有道理的，但是有條件地解析每行的每種可能性代價是很高昂的。難道我的最終歸宿還是 Python?不不不!我在 Stack Overflow 上找到了一個由 Postgres 大神編寫的 klin 函數(shù)(https://stackoverflow.com/users/1995738/klin)。

 

 

這個函數(shù)能夠成功地扁平化 json，輕松解決我的噩夢。

結(jié)語

有一種說法叫「Python 是做任何事情的第二好語言」。我相信這是真的，并且在某些情況下 Python 和「最好」語言之間的性能差異可以忽略不計。但是在本文介紹的情況下，Python 無法與 SQL 比肩。這些發(fā)現(xiàn)完全改變了我做 ETL 的方法。我現(xiàn)在的工作模式是「不要將數(shù)據(jù)移動到代碼中，而是將代碼移動到數(shù)據(jù)中」。Python 將數(shù)據(jù)移動到代碼中，而 SQL 執(zhí)行后者。更重要的是，我知道我只是觸及了 SQL 和 postgres 的皮毛。我期待能發(fā)掘出更多出色的功能，使用分析庫實現(xiàn)加速。

原文鏈接：https://towardsdatascience.com/python-vs-sql-comparison-for-data-pipelines-8ca727b34032

標(biāo)簽： [db:TAGG]

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請與原作者聯(lián)系。