分析GitHub：最流行的許可證是什麼？
Python部落(python.freelycode.com)組織翻譯，禁止轉載，歡迎轉發。
介紹
在這個kernel中,我將演示如何使用 Sohier 的 BigQuery 輔助模塊來安全查詢我們在 Kaggle 中獲得的最大 BigQuery 數據集.數據大小總共3TB,通過掃描大量大表格,你可以看到對於我來說快速耗盡5TB/30天 的配額實在是太容易了.
bq_helper模塊簡化了我們在 Kaggle 中通過 BigQuery Python 客戶端庫要做的日常只讀任務,讓資源管理變得很輕鬆.由於我們做了身份驗證工作,這個輔助類只能在 Kernels 中運行.這意味著你不必擔心諸如管理證書或輸入信用卡信息才能學習如何使用 BigQuery 數據集等事項.
你會學到以下內容:
1. 創建一個 BigQueryHelper 對象
2. 了解數據集中的表格
3. 在執行前預估查詢量大小
4. 安全查詢,轉化為 pandas.dataframe 並可視化結果集
在 kernel 的最後,你不僅能學習如何安全查詢 BigQuery 數據集,還能得出 GitHub 開源項目中使用的最流行的許可證. 現在讓我們開始吧!
創建一個 BigQueryHelper 對象
首先, 我們利用 bq_helper 來創建一個 BigQueryHelper 對象.這需要傳遞兩個參數:工程名稱和數據集名稱.點擊 kernel 的 "Data" 選項卡,就可以找到工程名稱和數據集名稱.選擇任一表格,可以找到被 . 分隔的地址的前兩部分內容(在藍色 BigQuery 表格框中),分別對應工程名稱和數據集名稱:
bigquery-public-data
github_repos
讓我們為 GitHub 數據集創建一個 BigQueryHelper 對象:
如果你使用的是你自己的 kernel, 點擊編輯器面板底部控制台中的 "Environment Variables" 選項卡,你就會看到在你的環境中已經創建了一個 BigQueryHelper 對象
通過只讀函數來了解你的數據
既然我們已經有了 GitHub 數據集的 BigQueryHelper 對象,現在就可以通過一些超級簡單的只讀函數來了解數據的更多信息,包含:
表格列表
獲取表格概要
檢查表格行信息
接下來,我們來運行一個最簡單的只讀任務來列出數據集中的所有表格.當然你也可以通過查看 "Data" 選項卡來預覽這些表格.
運行正常.我們能夠確認看到的9個表格和 "Data" 選項卡中展示的是相同的.
GitHub BigQuery 的數據集並不包含任何錶的列級別描述(否則你在 "Data" 選項卡的文件預覽中也能看到它們).在包含列級別描述的情況,可以通過調用 bq_helper 查看錶格概要來展示它們:
最後,除了可以通過 "Data" 選項卡來預覽表格的前100行,還有另外一種查看前幾行的方式是調用 bq_helper .
由於 SELECT * 會掃描你指定列的所有行(這會潛在的消耗很多配額),所以在僅僅瀏覽數據的情況下,最好避免使用它.這裡你可以參照 Sohier notes 中使用 list_rows 這個高效方法一樣,通過使用 head 來查看前幾行.讓我們在 licenses 這個表中試一下:
目前, bq_helper 提供了一些可用的輔助函數,讓你在編寫查詢語句之前能安全的了解你的數據.如果你希望看到更多的功能,可以隨時開啟問題或者提交 PR 到 GitHub repo 來通知我們.
預估查詢大小
最精彩的部分開始了.我們渴望馬上開始分析 GitHub BigQuery 數據集以便深入分析開源軟體的發展,但考慮到在查詢中需要掃描的數據量,還是應該謹慎一些.畢竟我們只有5TB的量!
幸運的是, bq_helper 模塊早已經為我們提供了工具,我們可以很容易的估計出查詢量大小.只需要依據 BigQuery 的 SQL 規範簡單的寫一個查詢語句,然後調用 estimate_query_size 函數就可以得到以 GB 為單位的查詢大小.現在我們試一下.
在 kernel 中,我寫了一個查詢,從 commits 表中 SELECTS 了2000條短的提交消息.讓我們使用 estimate_query_size 看一下會掃描的數據量.
運行完畢後,剛才的查詢消耗大概會接近18GB. 現在你能體會到在不需要實際消耗配額的情況下就能知道數據量大小實在是太有用了! 請注意查詢並不會返回一個17.6GB 的對象--它僅僅返回了2000條非常短的提交消息.
現在我們把返回結果擴大一倍,再來估計一下查詢大小:
哈哈,怎麼返回了完全相同的估計值? 這表明使用 LIMIT 來減少查詢返回的數據量實際上並沒有改變查詢掃描的數據量.對於你的配額來說,這是一個不利的消息.
讓我們再做一個實驗,是有關我包含的 WHERE 子句的,我們去掉 WHERE 和 LIMIT之後,看看是否會增加查詢掃描的數據量:
我們再次掃描了同樣的 17.6GB 的數據,現在我們已經清楚的知道這是信息欄位的總大小.我希望你能得到的經驗是你掃描的數據與你期望作為查詢結果返回的數據並不相等.我建議你查看 BigQuery 的最佳實踐文檔來獲取更多信息.
不要泄氣,還是有一些好消息的! 當你運行了一個查詢請求,結果將會默認緩存一段時間.所以只要你在同一個 notebook 互動式會話中,你就可以多次運行 cell/query 而不用消耗額外的配額.這是特別有用的,因為當你點擊"New Snapshot"來保存作業時,你的 kernel 會從上到下重新執行.
安全查詢
既然我們滿意與手頭上的大批數據,並且有把握估計到查詢量大小,讓我們實際取一些數據!
query_to_pandas_safe 是另外一個 bq_helper 函數,用來執行查詢.相比基本的BigQuery Python 客戶端庫,它有兩個優點:
默認不會運行超過1GB預估大小的查詢
它返回了一個方便的pandas dataframe
嘗試使用 query_to_pandas_safe 來執行一條查詢.因為它要掃描 17.6GB 的數據,在正常情況下,查詢將會運行失敗.
由於 query_to_pandas_safe, 我們並沒有真正執行大於1GB 的查詢.如果想讓查詢量大一些,可以添加一個參數 max_gb_scanned. 例如如果想成功執行這個查詢,我需要設置 max_gb_scanned=18
合併為四步
通過以上學習,我們已經知道如何處理 BigQuery 大數據集了.現在嘗試將以下操作結合在一起:創建合理大小查詢,獲取pandas dataframe返回值,可視化結果集.
回到 kernel 剛開始的問題,得到在 GitHub 工程中最經常使用的許可證.寫完查詢語句後,我將:
預估查詢量大小,確保不要太大
使用 query_to_pandas_safe 執行查詢並返回 pandas dataframe 結果集
探查結果集
可視化結果集
步驟1.預估上面語句的查詢量
執行此次查詢將僅消耗我0.02GB的配額.而令我滿意的是,我的配額是30天5TB.
步驟2.使用 query_to_pandas_safe獲取 pandas dataframe 返回值
執行正常,由於我的查詢量小於1GB,沒有異常退出.
步驟3.探查結果集
現在結果已經在 pandas dataframe 中,操作數據會變得超簡單.我們先來確認 dataframe 的大小並與我們剛剛掃描過的數據大小(0.02GB)做個比較:
小很多! 再次重申一下你所掃描的數據與查詢後作為結果集返回的數據是完全不一樣的.這是因為 BigQuery 掃描了 licenses 表格中 license 欄位的所有內容.
我們看一下返回的前幾行的內容:
很明顯, MIT 是 GitHub BigQuery 開源項目數據集中最流行的許可證.另外我們返回了多少個許可證呢?
我們已經得到了數據集中使用的15個許可證中每一個的數目.
步驟4.可視化結果集
將查詢得到的結果集可視化後會變得更加真實.我會使用 matplotlib 結合 seaborn 創建一個條形圖來展示 GitHub 工程中所使用的許可證數目.
乾的漂亮!目前,我們已經知道 MIT 是最流行的許可證了,但通過條形圖我們可以很直白對比出次流行的許可證分別是: Apache 2.0, GPL 2.0 和 GPL 3.0. 順便說一下, 我的這個 kernel 是 Apache 2.0的許可證:)
結尾
我希望你能喜歡這個 kernel,並且至少學到了一些新東西.在知道 bq_helper 中的函數可以防止我意外超過我的配額後, 我對探索這個龐大的3TB數據集有了信心.以下是 Kaggle Kernels 中使用 BigQuery 數據集的一些資源:
SQL 新手?註冊2月15日開始為期5天的 SQL Scavenger Hunt 來學習這種實用的語言
Kaggle 中 BigQuery 資源匯總
來這裡了解更多 BigQuery Python 客戶端庫
探索 Kaggle 中所有可用的 BigQuery 數據集--每個都有各自的"starter kernel"讓你來 fork
英文原文：https://www.kaggle.com/mrisdal/safely-analyzing-github-projects-popular-licenses/notebook
譯者：郭明
TAG:Python部落 |