BigQueryの概念実証（Proof-of-Concept）
Googleの新しいBigQueryサービスは、高価なソフトウェアや新しいインフラストラクチャを必要とせずに、顧客にビッグデータ分析能力を提供できるでしょうか？ ThoughtworksとAutoTraderは、大規模なデータセットを使用して、1週間の概念実証テストを実施しました。テストでは、7億5000万行のデータセットに対して、7〜10秒の範囲で一貫したクエリパフォーマンスが示されました。REST APIとJava、JavaScript、Google Chartsを使用して、クエリ結果をインタラクティブに視覚化するWebフロントエンドを作成しました。この演習全体は、3人で5日間で行われました。評決：BigQueryは優れたパフォーマンスを発揮し、ビッグデータと小規模な予算を持つ組織、特にデータウェアハウスを持たない組織や、データウェアハウスの使用が制限されている組織にメリットをもたらす可能性があります。
2012年9月4日
Ianは、Thoughtworksのプリンシパルコンサルタント兼アーキテクトです。彼はThoughtworksに10年間在籍し、コードの作成からCTOの戦略支援まで、あらゆることを行ってきました。彼は現在、GPUとマルチコアがソフトウェア設計に及ぼす変化と、オンラインで競争するために必要な組織変更に焦点を当てています。
Googleは最近、Google App Engineの改良版と新しいツールを導入し、エンタープライズ向けサービスをアップグレードしました。Google BigQueryは、最大数十億行の膨大なデータに対して、高速でインタラクティブなクエリを実行するための新しいオンラインサービスです。大量のデータを迅速に分析するのに適していますが、変更するのには適していません。データ分析の観点から見ると、BigQueryはOLAP（オンライン分析処理）システムであり、組織がビッグデータを扱うのを支援することを目的としています。
私たちは、このテクノロジーをテストすることに非常に興味を持っていたので、「ビッグ」というラベルにふさわしいデータセットを持つパートナーを探しました。英国のクライアントの1つであるAutoTraderは、ビッグデータと、BigQueryが解決できることを期待していたビジネス上の課題の両方を持っていました。
AutoTraderは、英国で新車と中古車を購入および販売するためのトップランクのオンラインサイトであり、毎週のクラシファイド広告雑誌も発行しています。中古車が販売店に入荷したときにディーラーが知りたい2つの質問は、いくらでオファーするか、そして販売にどれくらいの時間がかかるかです。その答えは、AutoTraderの履歴データの中にあります。
私たちは、AutoTraderから過去5年間にWebサイトに掲載されたすべての広告のデータ（広告が表示されていた期間と、サイトから削除された時点の車両価格（車両の販売価格と想定される）を含む）を借りました。テストデータセットには7億5000万行を超えるデータが含まれており、AmazonのEC2にアップロードされていました。
BigQueryへのデータの取り込み
ビッグデータを扱う場合、ファイルサイズ制限が問題になります。Unixコマンドラインの「split」を使用してデータファイルを適切なサイズのチャンクに分割し、レコードの途中ではなく行の境界でファイルを分割するように注意しました。これを行う際には、Google Cloud Storage（GCS）の制限とBigQueryのインポート制限の両方を考慮する必要があります。
GoogleのGCSコマンドラインツールgsutilが正常にインストールされるとすぐに、それを使用してAmazonからGCSにデータを移動しました。これは、プロセス全体の中で最も遅い部分であることが判明しました。GCSへの転送には、合計で約12時間かかりました。gsutilの並列アップロード機能を使用しようとしましたが、これはEC2インスタンスがI/Oバウンドになるだけでした。後から考えると、Amazonのリージョン、ファイルサイズ、並列アップロードを試して、このプロセスを高速化するために、もっと時間をかけることができたはずです。
GCSにデータが格納されたら、次にスキーマを表す非常に単純なテキストファイルを作成し、それをBig Queryコマンドラインツール（bq）で使用して、BigQueryにテーブルを設定しました。最初にデータの小さなサブセットでチェックアウトし、BigQueryのWebコンソールからいくつかのクエリを実行して、データセット全体を読み込む前にすべてが適切であることを確認しました。
次の段階は、GCSから新しく定義されたBigQueryデータベースへの転送を完了することでした。AmazonのソースからGCSへの並列アップロードで発生した問題のため、BigQueryへの読み込みに並列機能を使用しようとはしませんでした。後で、これを行うことができれば、8時間の転送時間を約15分に短縮できたことがわかりました。
すべてのデータがアップロードされたら、いくつかのクエリを試しました。最初は、BigQuery内でいくつかの内部配布が行われていなかったためか、これらは非常に遅かったです。当初、これらのクエリには数分かかりましたが、翌朝には約7〜10秒かかり、これは演習の残りの部分でかなり一貫していました。
BigQueryとGoogle Chartsを使用したビッグデータWeb分析の作成
私たちは、Google App Engineを使用して、クエリのシンプルなWebフロントエンドを作成し、出力をインタラクティブに視覚化するためにGoogle Chartsを埋め込むことにしました。
私たちのWebページは、アプリにRESTfulコールを行い、アプリはJava Big Query API（Pythonもオプションです）を使用してRESTfulコールを行い、データに対してクエリを呼び出しました。結果は、Google Chartsライブラリを使用してクライアント側でレンダリングされました。インタラクティブなチャートに加えて、BigQueryの結果が「ジョブID」を介してアクセスできる一時テーブルに保存されるという事実を利用して、シンプルなエクスポートメカニズムを追加することができました。これにより、クエリの結果をGCSに、ひいては他のGoogleツールに、またはCSVファイルとしてエクスポートするための非常にシンプルで迅速な方法が実現します。これはすべてOAUTHによって保護されており、アプリを使用してクエリを表示、アクセス、および呼び出すことができるユーザーをきめ細かく制御できます。
BigQueryを呼び出すために非同期メカニズムを使用するようにWebアプリを変更することを検討し始めましたが、時間が足りませんでした。とはいえ、jobIDを使用して中間結果をクエリするのは非常に簡単そうでした。もう一度チャンスがあれば、最初から非同期アプローチを採用するでしょう。
結論と利点
全体的に、BigQuery、API、ユーティリティを使用して短時間で達成できたことに感銘を受けました。時間と費用を比較的少なく抑え、高価なインフラストラクチャを必要とせずに、非常に大量のデータを視覚化およびクエリするさまざまな方法を試すことができました。
非常に大きなデータセットから洞察を得たいと考えている組織にとって、BigQueryは、特別なソフトウェアの購入や追加のインフラストラクチャを必要としない実行可能なオプションとなる可能性があります。既にエンタープライズデータウェアハウスを持っている組織でさえ、BigQueryは理論をテストしたり、データウェアハウスの管理者が使用を制限している他のインスタンスに使用したりするためのオプションです。
課題と教訓
概念実証中に、他のユーザーが学ぶことができる問題が発生しました。
Googleユーティリティのインストール
問題を回避するために、適切なバージョンのPythonがインストールされていて、パスに複数のバージョンがないことを確認してください。古いバージョンのpythonでeasy_installを使用しようとした初期の試みでは多くの問題が発生したため、ダウンロード可能なバージョンのツールを使用するのが最善であることがわかりました。
Googleコードベースの例
App Engine内から使用されるBigQueryの実際の動作Javaの例、特にOAUTHメカニズムに関する例を見つけるのは非常に困難であることがわかりました。しかし、作業を処理するためのクラスをいくつか作成したら、4段階のリダイレクト（ThoughtworksはGoogleアプリで独自の企業OAUTHメカニズムを使用しているため）でも、それ以上の問題は発生しませんでした。これらのメカニズムをwebdriverや自動受け入れテストのようなものと連携させるには、もう少し検討が必要になります。
ChartsとBigQueryのJSON形式が若干異なる
もう1つの問題は、BigQueryから返されるJSON形式が、Chartsが予期する形式とわずかに異なることです。これには正当な理由がありますが、ChartsがJSONの一部を直接使用できれば、作成する必要のあるコードの量が削減されたはずです。
タイムスタンプが問題だった
私たちのデータには、（Googleツールの観点からは）非標準形式のタイムスタンプが含まれていました。このため、期間別に選択するクエリの構築が困難になりました。これを回避することはできましたが、データで実行したいと思っていたことが制限されました。私たちはこれをBigQueryチームに伝えました。将来的には、日付/時刻形式に関してより柔軟に対応できるようになると期待しています。
Webコンソールを使用する
実験中に、BigQuery Webコンソールは、コードにクエリを追加する前に試してみるのに非常に役立つことがわかりました。
gsutilとbqの並列読み込みを試す
AmazonからGSCにロードする際にI/Oの問題が発生しましたが、後で、GCSからBigQuery自体に並列ロードを使用することで、多くの時間を節約できたことがわかりました。gsutilとbqで使用可能なさまざまなオプションをテストして、環境に最適なパフォーマンスを提供するオプションを確認することをお勧めします。
クエリを実行し、小規模なデータセットで開発する際には、データ使用量に注意する
完全なデータセットのテストをたくさん行うと、数テラバイト以上のデータ使用量になる可能性があり、高額な料金が発生する可能性があります。クエリは非常に高速に返されるため、リターンセットが数ギガバイトになる可能性があることを忘れてしまいます。そして、それらはすぐに加算されます。
テクノロジー
BigQuery：コマンドライン、Webコンソール、API
Google Cloud Storage：コマンドライン
Google App Engine：Java、RESTful API、OAUTH
Webフロントエンド：JavaScript、Google Charts
謝辞
AutoTraderのJames RobertsとThoughtworksのVyv Coddがコードでペアを組みました。AutoTraderのPete Hanlonがデータを提供し、ThoughtworksのNick HinesとStuart Hoggとともにチームをサポートしました。
主な改訂
2012年9月4日：martinfowler.comで最初に公開