More Related Content
Similar to BigQuery ハンズオン
Similar to BigQuery ハンズオン (20)
BigQuery ハンズオン
- 4. BigQueryの仕組み
■The 12 Components of Google BigQuery
https://medium.com/google-cloud/the-12-
components-of-google-bigquery-
c2b49829a7c7
■重要なコンポーネント
・Dremel（クエリエンジン）
・Colossus（ストレージエンジン）
・Jupiter（ネットワーク）
・Borg（大規模コンテナ・クラスタ管理）
Editor's Notes
- まずは自己紹介をさせていただきます。
名前はなかむらと申します。
元々は某小売系のインフラとシステム運用のエンジニアをしておりました。
そこでBigQueryと出会って、どっぷりやっていたら、Google Developers Expertsというエバンジェリストのような活動をさせて頂いております。
あとはGCPUGやbq_sushiというようなユーザーコミュニティでイベントの企画や登壇なども行っております。
- 今日のアジェンダについてですが、まずはBigQueryの裏側を少しお話しさせていただきます。
これは知らなければ使えないということではありません。逆に知らなくても十分使えます。
ただし、知っておいた方がよりBigQueryの長所をうまく使うことが出来るかもしれません。
その後にハンズオンを行います。
- まずはBigQueryの仕組みについて、この後お話します。
お話しする内容については、ほぼこのURLに記載があるものとなります。
12のコンポーネントということですが、先程のアジェンダにも記載しましたが、今回は重要と思われる6つのみを抜粋してお話します。
これは読んでいただくと様々な単語に様々なリンクが貼られており、より深い内容に飛ぶことが出来、どんどん技術の沼にハマっていきます。
もしお時間があればご一読いただければと思います。
また、BigQueryを構成するGoogleの技術で重要なものが4つあります。
覚えていただく必要はありませんが、今後GCP系の違うサービスを使うことがある場合でもDremelを除いてよく出てくる単語です。
つまり、DremelはBigQueryのみで利用していますが、その他の技術は他のサービスでも共通して利用されています。後ほど説明します。
- サーバレス・サービスモデルについて。
そもそもBigQueryはサーバということを気にする必要はありません。ハードウェアや機能アップデートの管理はすべてGoogleで行われています。
よくあるのが、他の同様なビッグデータを扱うサービス（よく比較されるのがRedShiftなど）はVMやCPU、メモリ、ディスクサイズ、レプリケーション、シャーディングの設計などなど色んなことを考える必要があります。
しかし、BigQueryはそれは必要としません。利用者はデータを入れることと、抽出することだけを考えればいいのです。
また、クエリを実行した瞬間に数秒で数十万コアが勝手に利用されています。スケールアウトなども気にする必要はありません。
- 独自のストレージエンジン。
ColossusというGFSの後継のストレージエンジンを利用しています。
これはデータセンター規模で一つのファイルシステムとして認識しています。同じインフラの上にGmailやDocs、YoutubeなどGoogleのサービスで共通のものが使われています。
また、自動的に同じデータを3箇所のデータセンターにレプリケーションし、安全にデータが保管されます。
データのシャーディングや暗号化もこのColossusというシステムが行います。
CapacitorはBigQueryはカラムナーデータベースです。そのフォーマットを行い、データを最適化します。
また、テーブルパーティショニングなどもここで管理されます。
Poseidonは様々なファイルフォーマットへの対応や、クエリとインポート/エクスポートを分離します。
ここで重要なのはこれらの機能がすべて別々で動いているということです。
普通のコンピュータだとどうでしょうか？暗号化やシャーディング、カラムナーフォーマットへの変更、データのインポート/エクスポートはCPUやDiskI/Oなど様々なリソースが使われます。
そのリソースを利用している間は他の機能が遅延したりするものです。そういうことも気にしなくて良いですし、そこに課金は発生しません。
課金については後ほど説明します。
- Dremelは元々はGoogle社内で利用されていたクエリエンジンです。
2015年にアップデートされ、Standard-SQLやDMLにも対応しました。DMLについては制限があります。
主にシャッフルやクエリのオプティマイズ、データの抽出を行っています。
各ノードに対してDremelのコンテナが配られるのですが、これはBorgで管理されています。つまり、使うときだけ起動して、処理が終わればそのプロセスは終了します。
ちなみにBigQueryでは1ユーザあたり2000スロットというものが割り当てられています。このコンテナ上で動いているプロセス数の合計のことだと思われます。
詳細は公開されていません。上限があるのに公開されていないというのが難点ではありますが、実のところこのプロセスの性能は常に向上されているので、その時のスナップショットでお話してもすぐに陳腐化してしまうとのことです。
ストレージのところでは3箇所に保存されていると言いましたが、クエリ自体もその3箇所に対して実行されます。
そして、一番速く結果が返ってきたものを採用します。つまり、どこかのデータセンターでアクセスが急増してパフォーマンスが落ちたり（実際にはあまりそういうことは無いですが）、クエリ実行中にコンピュータノードが壊れて返事が返ってこなかったりしても、大丈夫なようになっています。
- そして、これらのストレージとクエリはGoogleが開発したネットワークで接続されています。
TCP/IPなどの一般的なネットワークのプロトコルではなく、独自のものらしいです。（なんとなくUDPに近いとは言っていましたが。。。。）
この高速なネットワークこそが、BigQueryの速さの秘訣の1つであるともいえます。
本当に謎技術なので、簡単ですが、これで。
- 課金についてですが、クエリ課金とストレージ課金の2つがあります。
クエリ課金はクエリで参照したデータ容量について課金が発生します。
後ほどハンズオンにて説明しますが、BigQueryのデータ抽出はクエリに書かれた列すべてをスキャンします。
つまり、一般的なRDBMSや他のデータソリューションのようにwhere句のところでIndexを効かせて範囲を狭めてから、データを取ってくるというようなことはしません。
必ずフルスキャンとなり、そのデータに課金が発生します。これを忘れないでください。
もし、そういうものを気にせずに使いたい場合はFlat-Rateと言って、月額固定料金でクエリ投げ放題のプランもあります。
ストレージ課金については、BigQueryに保持しているデータ容量によって課金されます。
そして、テーブルのデータが変わらない場合、つまりInsertやUpdate、Deleteを行わずにテーブルのデータが固定されて90日間を経過すると半額になります。
余談ですが、なぜ90日後に半額になるのかというところですが、どうやらそれまでに実行されたクエリやデータ操作などをみて常にデータの最適化がされているようです。
これが落ち着くのが90日ということらしいです。
- 最後にアクセス権のところです。
BigQuery全体に対してはCloud IAMの権限と連携することが出来ます。
そこからDataset（テーブル群をまとめる単位）単位での権限付けも可能です。
認証方式はO-Authとサービスアカウントの2種類があります。
そして、全ての操作をStackDriverの監査ログとして残すことができ、それをBigQueryに保存することも出来ます。
内部統制などの操作に対する証跡として利用することが出来ます。
- 最後にアクセス権のところです。
BigQuery全体に対してはCloud IAMの権限と連携することが出来ます。
そこからDataset（テーブル群をまとめる単位）単位での権限付けも可能です。
認証方式はO-Authとサービスアカウントの2種類があります。
そして、全ての操作をStackDriverの監査ログとして残すことができ、それをBigQueryに保存することも出来ます。
内部統制などの操作に対する証跡として利用することが出来ます。
- それではまずは基本的なハンズオンをやっていきたいと思います。
このリンクのURLをベースに行っていきます。
