BigQuery 概念驗證
Google 的新服務 BigQuery 能否讓客戶在不需要昂貴軟體或新基礎設施的情況下，擁有大數據分析能力？Thoughtworks 和 AutoTrader 使用海量資料集進行了一週的概念驗證測試。測試結果顯示，在 7 億 5 千萬列的資料集上，查詢效能穩定，範圍在 7 到 10 秒之間。我們使用 REST API 搭配 Java、JavaScript 和 Google Charts，建立一個網路前端，提供查詢結果的互動式視覺化。整個練習在 5 天內由 3 人完成。結論：BigQuery 表現良好，可以讓擁有大數據和小預算的組織受益，尤其是沒有資料倉儲，或資料倉儲使用受限的組織。
2012 年 9 月 4 日
Ian 是 Thoughtworks 的首席顧問兼架構師。他在 Thoughtworks 任職 10 年，從撰寫程式碼到協助技術長制定策略，無所不包。他目前關注的重點包括 GPU 和多核心如何改變軟體設計，以及在網路上競爭所需的組織變革。
Google 最近升級了其企業服務，提供了升級版的 Google App Engine 和一些新工具。Google BigQuery 是新的線上服務，可以高速執行大量資料（高達數十億列）的互動式查詢。它適合快速分析大量資料，但不適合修改資料。在資料分析方面，BigQuery 是 OLAP（線上分析處理）系統，旨在協助組織處理大數據。
我們非常有興趣將這項技術付諸測試，因此我們尋找了一個擁有堪稱「龐大」標籤資料集的合作夥伴。我們在英國的客戶之一 AutoTrader 既有龐大資料，也有他們希望透過 BigQuery 來協助解決的業務問題。
AutoTrader 是英國排名第一的線上網站，用於買賣新車和二手車，而且還發行一份每週分類廣告雜誌。當二手車進入停車場時，經銷商想要知道答案的兩個問題是：出價多少；以及可能需要多長時間才能賣出。答案就在 AutoTrader 的歷史資料中。
我們從 AutoTrader 借用了資料，涵蓋過去五年來他們網站上放置的所有廣告，包括廣告顯示的時間長度以及從網站移除時車輛的價格（假設那是車輛的售價）。測試資料集包含超過 7.5 億列，而且已上傳到 Amazon 的 EC2。
將資料匯入 BigQuery
處理龐大資料時，檔案大小限制是一個問題。我們使用 Unix 命令列「分割」將資料檔案分割成適當大小的區塊，並小心地沿著列界線分割檔案，而不是在記錄中間分割。執行此操作時，必須考量 Google Cloud Storage (GCS) 限制和 BigQuery 匯入限制。
Google 的 GCS 命令列工具 gsutil 順利安裝後，我們使用它將資料從 Amazon 移到 GCS，結果證明這是整個過程中速度最慢的部分。總列數花費大約 12 小時傳輸到 GCS。我們嘗試使用 gsutil 中的平行上傳功能，但這只會導致我們的 EC2 執行個體變成 I/O 受限。事後回想，我們可以花更多時間來實驗 Amazon 區域、檔案大小和平行上傳，以加快這個程序。
資料在 GCS 中後，我們接著建立一個非常簡單的文字檔案來表示架構，並搭配 Big Query 命令列工具 (bq) 使用它在 BigQuery 中設定表格。我們先使用一小部分資料檢查它，從 BigQuery 網路主控台 執行一些查詢，以確保在載入整個資料集之前一切都合適。
下一個階段是完成從 GCS 傳輸到新定義的 BigQuery 資料庫。由於我們在從 Amazon 上的來源上傳到 GCS 時遇到平行上傳的問題，我們沒有嘗試使用平行工具來載入 BigQuery。後來我們發現我們可以這麼做，而且可能會將我們的 8 小時傳輸時間縮短到大約 15 分鐘。
當我們上傳所有資料後，我們嘗試了一些查詢。一開始，這些查詢非常慢，這可能是因為 BigQuery 內部的一些分佈尚未發生。最初這些查詢需要幾分鐘，但隔天早上大約需要 7 到 10 秒，而且在練習的剩餘時間裡，這個時間保持相當一致。
使用 BigQuery 和 Google Charts 建立大數據網路分析
我們決定使用 Google App Engine 為我們的查詢建立一個簡單的網路前端，並嵌入 Google Charts 以互動式視覺化輸出。
我們的網頁對我們的應用程式進行 RESTful 呼叫，而應用程式進而使用 Java Big Query API（Python 也是一個選項）對資料進行查詢的 RESTful 呼叫。然後使用 Google Charts 函式庫在用戶端呈現結果。除了互動式圖表外，我們還能夠新增一個簡單的匯出機制，利用 BigQuery 結果儲存在臨時表格中，並可透過「工作 ID」存取這一事實。這提供了一個非常簡單且快速的方法，可以將查詢結果匯出到 GCS，進而匯出到其他 Google 工具或作為 CSV 檔案。所有這些都透過 OAUTH 保護，讓我們可以精細地控制誰可以使用應用程式查看、存取和呼叫查詢。
我們開始研究將我們的網路應用程式變更為使用非同步機制來呼叫 BigQuery，但時間不夠了。話雖如此，這看起來相當簡單，使用 jobID 來查詢中間結果。如果再給我們一次機會，我們會從一開始就採用非同步方法。
結論與優點
總體而言，我們對在短時間內使用 BigQuery、API 和公用程式所取得的成就印象深刻。我們能夠以相對較低的投資時間，且不需要昂貴的基礎架構，來試驗不同的方式來視覺化和查詢大量資料。
對於渴望深入瞭解非常大型資料集的組織而言，BigQuery 可能是可行的選項，不需要購買專用軟體或額外的基礎架構。即使對於已經擁有企業資料倉儲的組織而言，BigQuery 也是一個測試理論的選項，或是在資料倉儲管理員限制使用的其他情況下。
問題與教訓
我們在概念驗證期間遇到了一些問題，其他人可以從中學習。
安裝 Google 公用程式
確保安裝正確版本的 Python，且路徑中沒有多個版本，以避免問題。我們發現最好使用可下載版本的工具，因為我們早期的嘗試，試圖在舊版本的 python 中使用 easy_install，導致許多問題。
Google 程式碼範例
實際上證明很難找到一些從 App Engine 內部使用的 BigQuery 的 Java 範例，特別是在 OAUTH 機制方面。但是，一旦我們建立了一些類別來處理這項工作，我們就沒有遇到進一步的問題，即使在四階段重新導向（因為 Thoughtworks 使用自己的公司 OAUTH 機制與 Google 應用程式）的情況下也是如此。需要更多思考才能讓這些機制與 webdriver 和自動驗收測試等一起運作。
圖表和 BigQuery 的 JSON 格式略有不同
另一個問題是 BigQuery 回傳的 JSON 格式與 Charts 預期的略有不同。雖然有很好的理由造成這種情況，但如果 Charts 能直接使用部分 JSON，將可減少我們必須建立的程式碼量。
時間戳記是個問題
我們的資料包含非標準格式的時間戳記（從 Google 工具的角度來看）。這使得難以建構依時間範圍選取的查詢。雖然我們能夠解決這個問題，但確實限制了我們希望使用資料執行的部分功能。我們已將此問題轉達給 BigQuery 團隊，並預期他們未來將在日期/時間格式方面提供更大的彈性。
使用網路主控台
在實驗過程中，我們發現 BigQuery 網路主控台對於在將查詢新增至程式碼前進行嘗試非常有價值。
嘗試使用 gsutil 和 bq 平行載入
雖然我們在從 Amazon 載入至 GSC 時遇到 I/O 問題，但我們後來發現，如果使用平行載入從 GCS 至 BigQuery 本身，我們可以節省許多時間。值得測試 gsutil 和 bq 提供的各種選項，以找出在您的環境中提供最佳效能的選項。
執行查詢時注意資料用量，並使用小型資料集進行開發
如果您對完整資料集進行大量測試，您可能會使用數 TB 的資料，這可能會產生高額費用。查詢回傳得非常快，您會忘記回傳組可以是數 GB，而且它們會快速累積。
技術
BigQuery：命令列、網路主控台、API
Google Cloud Storage：命令列
Google App Engine：Java、RESTful API、OAUTH
網路前端：JavaScript、Google Charts
致謝
AutoTrader 的 James Roberts 和 Thoughtworks 的 Vyv Codd 與我共同撰寫程式碼。AutoTrader 的 Pete Hanlon 提供資料，並與 Thoughtworks 的 Nick Hines 和 Stuart Hogg 一起支援團隊。
重大修訂
2012 年 9 月 4 日：首次發布於 martinfowler.com