google bigqueryについて 紹介と推測
TRANSCRIPT
Google BigQueryについて 紹介と推測
2015/01/19 #osaka_impala_meetup01
玉川竜司
自己紹介• 玉川竜司
• FB: Ryuji Tamagawa
• Twitter: @tamagawa_ryuji
• 本業ソフト開発（Sky株式会社）
• 兼業翻訳者（ほぼオライリー）
Impalaのフリー電子書籍あります
http://www.oreilly.co.jp/books/9784873116723/
What’s Next • 著者の方が大変親切、かつBigQuery愛が感じられます
• 私：「ここ、動かないんだけど」Tigani：「あ、書いた時にはそれ実装される予定だったんだわ。結局ボツになって実装されなかったんで、削ってくれたらいいよ」私：「さいですか」
• たぶん3月発売!!
今日の内容
• BigQueryの概要
• BigQueryのいいところ
• BigQueryの気になるところ
• BigQueryの特徴的な機能から推測する実装
BigQueryの概要
BigQueryの概要• ビッグデータに対してSQLで分析を行うフルマネージドサービス
• OLTPのためのものではなく、OLAPよりのサービス
• 行を追記していくことはできるが、行の更新はできない
• 基本的には、RDBと同じデータモデル。テーブルにデータを保存していく。
• ただし、repeated fieldやrecord fieldといった拡張機能もある。この辺は、利便性とRDBとの互換性とのトレードオフ。
BigQueryの概要• WebのUIからインタラクティブにクエリを実行することも、APIを叩いてクエリを実行することもできる
• コマンドラインツールやPython、Javaなどのクライアントライブラリが用意されている
• データのインポートは、CSVもしくはJSONで。Google Cloud Storageを経由するか、直接APIでインポート。
• AdSenseなど、Googleの他のサービスからは直接データを渡してもらえることも
BigQueryの課金体系• 課金は、保存ストレージとクエリでスキャンしたデータ量に対してかかる
• ストレージ：$0.020（GB 単位/月）。 S3（$0.0300 /GB）より安い
• クエリ：$5（処理容量単位: TB）
• dry-runでクエリがスキャンするデータ量を事前に確認できる
• 特定のユーザーがデータセンターのリソースを食いつぶさないように、様々な負荷制限あり
BigQueryのいいところ
BigQueryのいいところ
• お手軽（RDB/SQLが分かっていれば、ほんとにすぐに使えます）
• 速い（50GB/Secは出るらしい。インタラクティブではないけど）
• 安い（バックエンドでは圧縮保存ですが）
• Googleの強力なインフラがあって初めて上記が成り立つ
BigQueryのいいところ（２）• 外部連携
• ODBCドライバあります
• http://www.simba.com/connectors/google-bigquery-odbc
• Google Spreadsheet、Excel、Tableauなども連携容易
• 裏方を少し知っておくと、パフォーマンスやコスト面でメリット大
BigQueryの気になるところ
• アクセスの手段がBigQuery SQLに限定される
• 1つのデータソースを多元的に活用したい場合はちょっと手間かも
• 時々機嫌が悪くなる
BigQueryの特徴的な機能からいろいろ推測※ あくまで私の個人的な推測ですので、なんの保障もありません
トピック
• クエリの実行から見るGoogleのインフラ
• クエリと匿名テーブル
• 列指向ストレージと圧縮
• ストレージのバックエンド更新とスナップショットデコレータ
クエリの実行の様子• 簡単に言えば、クエリの内容に応じてコンピュートノードのツリーを動的に構成し、そこに大量のディスクから一気にデータを流す
• テーブルのデータは必ずフルスキャン
• 単純に見えるものの、こうすることができるのは、超高速なネットワーク、強力なストレージレイヤー、大量のリソースをバースト的に突っ込んで動的に構成できるインフラがあるからこそ
• この辺のインフラの細かいところはGoogleさんの藪の中
コンピュート ノード
コンピュート ノード
コンピュート ノード
コンピュート ノード
コンピュート ノード
コンピュート ノード
ディスク
ディスク
ディスク
ディスクディスク
ディスク
ディスク
ディスク
ディスク
ディスク
ディスク
ディスクディスク
ディスク
ディスク
ディスクディスク
ディスク
ディスク
クエリの実行の様子（2）• GROUP BYやJOINの処理は、コンピュートノードのメモリ容量に制約を受ける
• コンピュートノードにデータが収まらなければResource Exceed Error
• データの量や分布によって、EACHオプションを使い、シャッフルを強制しなければならないケースもある。大きいテーブル同士のJOINなど
• データの量、分布をユーザーが意識しなければならないケースは（今のところ）なくなっていない
コンピュート ノード
コンピュート ノード
コンピュート ノード
コンピュート ノード
コンピュート ノード
コンピュート ノード
ディスク
ディスク
ディスク
ディスクディスク
ディスク
ディスク
ディスク
ディスク
ディスク
ディスク
ディスクディスク
ディスク
ディスク
ディスクディスク
ディスク
ディスク
コンピュート ノード
クエリの実行の様子（3）• デフォルトでは、クエリが最終的に返す結果は、それほど大きくならないことが想定されている
• 大きなデータを返す場合、最終出力を複数のコンピュートノードから行ってパフォーマンスを上げることもできる（allow_large_result）
• この場合、保存先のテーブルを明示的に指定する必要があり、保存先のストレージ容量に対する課金も生ずる（destination_table）
コンピュート ノード
コンピュート ノード
コンピュート ノード
コンピュート ノード
コンピュート ノード
コンピュート ノード
ディスク
ディスク
ディスク
ディスクディスク
ディスク
ディスク
ディスク
ディスク
ディスク
ディスク
ディスクディスク
ディスク
ディスク
ディスクディスク
ディスク
ディスク
コンピュート ノード
コンピュート ノード
ディスク
ディスク
ディスク
ディスク
ディスク
ディスク
ディスク
ディスク
ディスク
ディスク
クエリと匿名テーブル• クエリの実体は、テーブルからデータを読み取り、データを加工し、その結果を別のテーブルに出力するジョブ
• デフォルトでは、クエリの結果は匿名テーブルに出力されている。この匿名テーブルは7日間保存され、課金されない
• この匿名テーブルの名前は、クエリの文字列、クエリが読み取るテーブルの最終更新時刻から生成されている
tablename:foo lastupdate:2015-01-20
Query: SELECT …
tablename:f( foo, 2015-01-20, SELECT…)
クエリと匿名テーブル（２）• クエリの実行時には、そのクエリの結果が保存されている匿名テーブルがないかがまずチェックされる
• ダッシュボードなど、頻繁に同じクエリが実行されるようなアプリケーションでは、この機能をうまく使うと、コードを単純に保ったまま、高速かつ低コストにできる
tablename:foo lastupdate:2015-01-20
Query: SELECT …
tablename:xxxxxxxxxxx
if exists f(foo, 2015-01-20, SELECT…) ?
列指向ストレージと圧縮• BigQueryのデータはColumnIOという列指向のフォーマットで保存される
• データは列ごとに保存され、圧縮される。もちろん、1つの列も複数のディスクに分散配置されている
• データはバックグラウンドで再編成される。そのため、圧縮後のデータ容量はユーザーから見えないところで変化しうる
• そのため、課金は非圧縮状態の容量に対して行われるので、安い感じになる
001 Osaka Tamagawa 1234
002 Tokyo Shimauchi 4321
003 Tokyo Shimauchi 2323
003 Tokyo Kobayashi 0001
004 Sapporo Sato 5678
005 Sapporo Sato 7863
スナップショットデコレータ• スナップショットデコレータを使うと、ある時刻のテーブル（過去7日以内）にアクセスできる。範囲指定も可能。
• SELECT foo, bar from wikipedia@1386465812000
• SELECT foo, bar from wikipedia@1386465812000-1386465899999
• 行の挿入方法は2種類用意されている。バッチ処理とストリーミング。
• ここから想像するに、ユーザーの利便性、インフラに生ずる保存のコスト、クエリのコストを最適化するために…
Log Structured Merge Treeみたいなことをやっている？
2015/1/10 1:00時点
～2015/1/11 1:00
～2015/1/12 1:00
} 2015/1/12 1:00時点
～2015/1/13 1:00
まとめ• とてもお手軽に使い始めることができるビッグデータの分析サービス
• 裏方を少し学んでおくと、便利な仕掛けがたくさんあります
• Googleのインフラはすごいけど、ストレージデバイスやコンピュートノードは、やはりコモディティ製品っぽい。どうなってるのかいろいろ想像すると楽しいです