スティルハウスの書庫の書庫

はてなダイアリーで書いてた「スティルハウスの書庫」を移転してきました。

BigQueryってなんぞ？

#io2010 GAE

Google I/O 2010では、Google Storageと合わせて利用する新機能「BigQuery」が発表されました（これもApp Engineとは個別のプロダクトです）。ひとことで言えば「何100億件のデータも数秒〜数10秒で集計できる、大規模並列クエリサービス」です。既存のOLAPやデータウェアハウスに相当するもので、更新処理には使えません。

MapReduceとはどう違う？

大規模なデータセットに対して多数のサーバで並列処理するという点ではMapReduceに似ていますが、処理結果がすぐに得られる点、そしてSQLっぽいクエリ言語で表現できる集計処理しか実行できない（mapperやreducerを定義してデータを任意の方法で加工したりできない）点がMRとは異なります。MRよりさらに高水準の分散処理サービスです（MR＋Hiveに近いかもしれません）。

リンク集

特徴

以下、公開されているドキュメントとGoogle I/O 2010のセッションをもとにまとめてみました（カッコ内は筆者の感想です）。

  • BigQueryとは
    • 大規模データセット（数TB、数兆件規模）に対して短時間（数秒〜数10秒）で対話型の集計処理が可能なサービス
  • Google社内でも様々に利用している
    • インタラクティブツール
    • スパム検出
    • トレンド解析
    • Webダッシュボード
    • ネットワーク最適化
    • MapReduceもあるが、複雑で時間もかかる（訳注：ad hocなクエリには向かない）
  • 使い方
    • データをGoogle Storageにインポートする
    • データをBigQueryのスキーマにインポートする（インデックス等の指定は不要）
    • クエリを実行
  • 制限
    • OLTP用途には使えない
    • 複数テーブルのjoinはできない
    • ピボット分析はサポートしない
    • インポート作業はいまのところGooglerに依頼して手作業で実施（いずれ自動化予定）
  • ネットワークモニタリング分析のデモ
    • M-Labではインターネットトラフィックの統計データを一般公開している（約600億件）
    • このデータをBigQueryにインポートした
    • クエリのデモ：SELECT COUNT (*) FROM [bigquery/tables/mlab/v1]
      • （10秒もかからずに全件カウントが返って来た！すごす！）

BigQueryのAPI

BigQueryのクエリ構文

  • SQLのサブセットを記述する
    • - SELECT ... FROM ... WHERE ... GROUP BY ... ORDER BY ... LIMIT ...
  • M-Labデータに対する「ユーザー数のカウント」の例：
SELECT COUNT(DISTINCT web100_log_entry.connection_spec.remote_ip) AS num_clients
FROM [bigquery/samples/mlab]
WHERE IS_EXPLICITLY_DEFINED(web100_log_entry.connection_spec.remote_ip) AND
      IS_EXPLICITLY_DEFINED(log_time) AND
      log_time > 1262304000 AND
      log_time < 1262476800;

num_clients

    

  • 

      

    • 

        

      • 

          

        • 

            

          • 

              

            • 

                

              • 

                  

                • 

                    

                  • 

                      

                    • -
                      • 

                    • 

                  • 

                • 

              • 

            • 

          • 

        • 

      • 

    • 

      20217

BigQueryのデータモデルとアーキテクチャ

BigQueryでは、以下のようなJSONっぽい（追記：しかしよく見るとかなりJSONと違う！）データモデルを取り扱います。

record {
  f1: X
  m1 {
    f2: a
    f2: b
    f2: c
  }
  r1 {
    m2 {
      f3: 1
      f3: 2
    }
    m2 {
      f3: 3
      f3: 4
      f3: 5
    }
  }
}
record {
  f1: Y
...

こうしたデータに対して、以下のようなかたちでクエリを実行できます。

SELECT f1, COUNT(r1.m2.f3) WITHIN RECORD AS cnt FROM [Table];

このクエリは、「Tableテーブルについて、個々のrecord内のr1.m2.f3の数をカウントしてf1ごとに返す」という意味になります。結果は以下の通り。

      +----+-------+
      | f1 |  cnt  |
      +----+-------+
      | X  |   5   |
      | Y  |   7   |
      | Z  |   2   |
      +----+-------+

これらのドキュメントから判断するに、BigQueryのデータモデルはリレーショナルモデルではありません。joinもできません。非正規化されたツリー構造データ（XMLに似ている？）に対して問い合わせする独自データモデル＋言語と捉えてよいでしょう。


そして肝心のポイント――どうやってそんなに速くクエリできるの？――ですが、MLで聞いてみたところ、

Kaz,

Thank you for the interest in BigQuery.

We don't comment on the backend details  of BigQuery. What I can say is that
we are running BigQuery on thousands of machines.

The 60 B records were imported as part of a sample dataset. We don't have
numbers to share at this point regarding the time taken to import the
dataset.

thanks
Amit

という回答。つまり詳細なアルゴリズム（例えば事前に集約処理しているか等）は教えてくれませんでしたが、数1000台規模の並列クエリ処理であることは間違いないようです（クラウド破産しそうw）。またインポート時間についても上述のとおりノーコメントでした。

@ashigeru さんのコメントまとめ

BigQueryについて@ashigeruさんにいろいろコメントをいただいたまとめです：


という感じで、BigQuery面白いですねぇ。。600億件の集計を数秒でこなすデモを見たときはぞくっとしました。どんなズルしてるのだろう〜と勘ぐりましたが、意外に力業な大規模並列クエリを実行しているようです。価格設定の発表に期待です。これまで超高額な製品群（Hyperionとか？）が席巻していたOLAPやDWH、Business Intelligence市場においてもクラウドの価格破壊を起こせるか興味深いところです。