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