BigQuery に関する12の誤解の真相を明らかにする

Yuta Hono
google-cloud-jp
Published in
18 min readMar 20, 2018

--

この記事は Busting 12 myths about BigQuery の著者の許可を得た上で @yutah_3 が日本語訳、補足したものです。個人的に気になった話等を含めて “訳者注” を入れながら翻訳します。

割と最近、 Forrester Research のレポート The Forrester Wave™: Insight Platforms-As-A-Service, Q3 2017 では Google Cloud は Leader のポジションとして位置付けられました。 BigQuery がこの中で果たした功績は間違いなく大きいでしょう。

私達は日々、スタートアップから大企業のお客様に至るまで、多様な Google BigQuery をお使いのお客様と、お客様の分析やデータウェアハウスに関する課題を解決するために一緒に取り組んでいます。多くの場合、私達のお客様は BigQuery の柔軟性、機能性を気に入っていただけます。しかしながら、いくつかの BigQuery に関する誤解を聞くこともあります。それらの誤解は昔の BigQuery を利用したときの経験に基づくものであったり、 BigQuery のアーキテクチャに対する誤解から生ずるものであったりします。このブログポストでは、 BigQuery に対するよくある誤解を解くための12の真実について説明します。

このブログポストで紹介するトピックは、すべてのユースケースに広く当てはまりますが、いくつかの疑問は大企業のお客様よりいただいたご質問を含んでいます。例えば、クエリの優先順位付け、複雑なプロジェクトのトポロジー、プロジェクト管理の自動化、きめ細かいアクセス制御などは大企業に必須ですが、プロダクトのドキュメントにわかりやすくかかれていないこともあるかもしれません。

真実 その1: BigQuery を使うと、ニアリアルタイムでの分析が可能になる

世間ではバッチ処理の結果としてのデータウェアハウスだと考えることが一般的で、そして予め決められたバッチスケジュールに則ってり過去のイベントの古いスナップショットだと思うでしょう。 GCP の ストリーミング分析ソリューション を用いることで、このケースには当てはまりません。

BigQuery に(訳者注: ログやイベントが)到着すると、無料のデータロードジョブにはクオータポリシーによる制限がありますが、BigQuery へのストリーミングを行う事ができます。デフォルトでは、クオータポリシーはストリーミング挿入にもクオータポリシーが適用されますが、必要なら、クオータの増加を行うことが可能です。もし Google Cloud の担当者と一緒にプロジェクトを推進しているなら、どのように増加申請を行うか問い合わせてください。 (訳者注:サポートへの連絡でクオータの増加が可能です

更には、データが Cloud Bigtable, Cloud Storage, Google Drive にあるのなら、 BigQuery へデータをロードせずに分析を行うことが可能です。詳細は 真実 その3 でご紹介します。

真実 その2:BigQuery は SQL 以外もサポートしている

BigQuery が ANSI 標準 SQL 2011 をサポートしていますが、同時に ユーザー定義関数 (User Defined Functions, UDF) もサポートしています。 UDF はSQLやSQL以外のプログラミング言語(例:JavaScript)を用いて関数を定義することができます。これらの関数は列を入力として受け付け、アクションを実行し、それたのアクションの結果を値として結果を返します。

訳者注:もっと複雑な処理を書きたい場合や、 BigQuery からデータを取り出し、書き込む、その逆の場合には Cloud Dataflow を使うのもおすすめです。 @yuu.ishikawaさんは Export BigQuery to Google Datastore with Apache Beam/Google Dataflow という記事で BigQuery から Cloud Datastore へのデータ書き出しを解説されています。

真実 その3:BigQuery は 外部ストレージに格納されたデータも分析できる

BigQuery のカラム指向ストレージにデータが存在することでクエリが高速に返るという真実はありますが、 BigQuery は SQL クエリを Cloud Storageにあるログファイルや、Cloud Bigtable のトランザクショナルなレコード、など、その他多くの外部データソースに対して実行することも可能です。

この記事では、上で言及した外部データソースへのクエリ機能はデータアナリストやデータエンジニアへの「銀」レベルのデータを生成するために利用しています。「銀」レベルと比べると「金」レベルは、 BigQuery の中に保管されたデータを指します。データウェアハウスの外のデータが相対的に高い速度、多様性、品質、インタラクティビティを犠牲にしています。「銀」レベルのデータはデータウェアハウスにまだ入れていないデータを関連付けて調査を行うデータアナリストに非常に適したデータです。また、データエンジニアは ETL ジョブを設計する際に、データウェアハウスの中にあるデータの種類を拡張するために、この種類のデータをよく用います。

真実 その4:BigQuery を利用しても、 ある時間のスナップショットを取得出来る

7日間分のテーブルの完全な変更履歴を保持することで、 BigQuery はあなたのデータへのある時間へのスナップショットへのアクセスを提供しています。これを用いることで、バックアップからのリカバリを依頼することなく、変更を元に戻すことが出来ます。

ただし、テーブルが完全に削除された場合、履歴は2日後にはフラッシュされてしまいます。

訳者注:バックアップがない、という話をたまに聞くのですが、この機能を用いることでユーザバックアップの取得が可能です。また、明示的に永続化しなくとも、タイムスタンプ機能は自動で適用されているため、何らかのミスオペなどの際にはここから戻すことも可能です。お客様オペミス以外への DR 用途として、 BigQuery そのものに格納されたデータはシステム的には複数リージョンでバックアップをされています。

真実 その5:BigQuery は クエリの優先度設定をサポートしている

BigQuery をオンデマンド料金で利用している場合、プロジェクトのクエリ全体で分散する形で 最大 2000 スロットを利用することが出来ます。この場合、利用できるのは interactive タイプのクエリか、 batch タイプのクエリのみです。デフォルトでは、 Bigquery はクエリを interactive モードで実行します。 interactive クエリが発行されるとすぐに、オンデマンド料金の他のプロジェクトで並列に実行されているすべてのクエリと競合します。 batch クエリはキューイングされ、アイドル状態のリソースが利用可能になるとすぐに実行されます。 interactiveのクエリはクエリのクオータにカウントされますが、 batch クエリはカウントされません。BigQuery が動作する規模を考えれば、オンデマンド料金で完全に事足りるかもしれません、しかし、それ以外にも選択肢はあります。

月額固定の請求のほうがよい、もしくはクエリのレイテンシーセンシティブなワークロードがあるため、オンデマンド料金では満たせない性能の要件や予測できる請求というのもあるかもしれません。このような状況においては、定額料金を利用することが出来ます。このモデルでは、特定の数のスロットがプロジェクトが利用する複数または一つのプロジェクト専用に割り当てられます、プロジェクトに対し階層を作った優先度をつけたモデルを設計することができます。定額料金は、さまざまな優先度と予算を持つ複数の組織とワークロードのある大企業のお客様に特に適しています。例えば、下図に示された設定の中で、 Dashboarding プロジェクトから発行されたクエリは他の2つのプロジェクトから発行されたクエリよりも優先度が高く処理されます。しかしこの優先順位付けによって、スロットが無駄になることはありません。もし Dashboarding プロジェクトが全く割り当てられたスロットを使わないのであれば、それらのスロットは残ったプロジェクトに分配されます。 Data Science プロジェクトにあるデータであっても、 Dashboarding プロジェクトから高い優先度でクエリを実行することが出来ます。この場合の優先度は Data Scienceプロジェクトからクエリをかけるよりも高くなります。

真実 その6:BigQuery プロジェクトのトポロジーは組織構造に合わせて設定できる

Google Cloud Identity & Access Management (IAM) は組織モデルにあわせて、ユーザーとユーザーのリソースへのアクセスを整理することができる柔軟なビルディングブロックです。最近のリリースで、 BigQuery は IAM カスタムロールをサポートし、さらに柔軟になりました。

以下の図は IAM の内包する階層を示したものです。データセット、プロジェクト、フォルダ、組織のすべてのレベルに対しパーミッションを設定することができます。パーミッションは階層の上から下へ継承されます。このブログポストでは、 Google Cloud Platform (GCP) のリソース階層をどのように組織とマップできるかの詳細を示しています。

もし非常に大規模な数のユーザーがプロジェクトに参加したり、離脱したりを管理する必要がある場合には、ロールをユーザーレベルに割り当てるべきではないでしょう。代わりに、ネストしたユーザーグループの利点を利用するべきです。これらのグループは組織の中の異なるエンティティを表現します、例えば部署、ワークフロー、キャンペーン、調査、等やもしくはプロジェクト名で命名するのもよいでしょう。グループのよくある命名規則は以下のようなものです。 gcp-{team}-{role}gcp-{project}-{role} などが考えられます。

いくつもの GCP プロジェクトや、ユーザーグループ、それぞれのプロジェクトにおけるいくつかのアクセスレベルなどは組織の中の多くの要素に依存します。すべてのとりうるトポロジをレイアウトすることは現実的ではありませんが、このセクションの残りの部分では、現場でそのまま、もしくは組織に合ったものを構築するための最初の形として使用できるよくあるアプローチを紹介します。

下記の整理がデータライフサイクルにおいて発生します:

  • データエンジニアグループのユーザーは ETL のパイプラインをテストしながら構築する PRE_PROD のプロジェクトでのみ作業する(訳者注:商用環境の前の環境という意味
  • PROD 環境では、サービスアカウントだけが ETL 処理を行い、データアナリストがデータの可視化を公開するための “clean” なデータを提供し、派生したデータセット様々な用途やデータサイエンティストが新しい機械学習のモデルのトレーニングをするために用いる
  • マーケティングやプロダクトマネジメントのようなユーザーは、データアナリストによって提供された可視化データと派生したデータセットを用いる

下のトポロジーでは、データの置き場所とそのデータの利用場所は異なるプロジェクトになっています。この整理方法はデータウェアハウスから他のGCPリソースを分離するため、もしくはクエリの優先度とチーム予算の分離などが要件としてあり、その要件を満たすためによく利用されます。

この整理方法では、データエンジニアグループのユーザーが一つの環境ごとに一つのプロジェクトを管理し、そこにすべてのデータを格納します。データ分析官もしくはデータサイエンティストのグループのユーザーはレポートの生成や機械学習モデルをデータレイクとはことなるプロジェクトで使います。

厳しいデータセキュリティの要件のある組織では、ユーザーはすべてのデータにアクセス権を持ちませんが、そのデータのうち、異なるセキュリティドメインに属するデータにはアクセス権を持ちます。データセットを用いて、センシティブなデータを皆が使えるデータから隔離することが可能で、データセットレベルできめ細かいアクセス制限を行うことが出来ます。データ分析官とデータサイエンティストは CommonSales のデータセットにアクセスできますが、データサイエンティストだけが Employee データにアクセス出来ます。

最小権限の原則に基づき、 ETL 処理そのものを別のプロジェクトに分割することも出来ます。この分割は、データパイプラインとデータストレージの管理責任のあるチームを分割する必要が出てくるかもしれません。課金データはプロジェクトごとに集計することができるため、懸念事項の分離は費用の追跡を容易にします。

真実 その7:BigQuery のプロジェクト設定は自動化出来る

BigQuery のサーバーレスアーキテクチャは非常に大量の管理作業を減らしてくれるとはいえ、データセットの設定、 IAM の設定といったプロジェクト単位での設定は必要です。 Google Cloud Console はそれらのタスクを簡単にしてくれますが、複雑な組織モデル、たとえば前の章で紹介したものなどをおこなうのは人力となってしまいます。Infrastructure as a Code に依存している大きな組織は、コードレビューの関門とともにデプロイプロセスを確立しています — クラウド環境においてもこの原則は適用されます。たとえ管理するインフラはなくとも、プロジェクトを手動で管理したくはないでしょう。Cloud Deployment Manager を利用することで、これらの作業をコードで実現できます。ここにサンプルテンプレートがありますので、ぜひ試してみてください。

訳者注:3月5日に DDL がサポートされ、さらに便利になりました。

真実 その8:BigQuery は正規化したスキーマと JOIN をサポートしている

BigQuery はどんなリレーショナルなデータモデルも扱うことができ、多くの場合、既存のデータウェアハウスかのら移行においてスキーマ変更を必要としません。しかしもし最高の結果を得たいのであれば、いくつか考慮するべき事項があります。

下に図示した通り、 多くの正規化されたデータ構造は、BigQuery の中でネストされ繰り返しされた行としてマップされます。これは JSON と Avro ファイルからのロードを容易にします。直感的なドットを用いた表記法を利用し、フィールドにアクセス可能です。例えば、 cityLived[0].name のような形となります。

2つのテーブル間の関係がネストおよび繰り返し行で表現できない場合には、伝統的な正規化されたスキーマがあなたが考えているよりも多くの場合で良いパフォーマンスを発揮します。正規化は 1 TB 以下の関係をもつテーブルか、頻繁に UPDATE DELETE に悩まされるテーブルで一般的にはうまく動作します。詳細なスキーマデザインの TIPS に関しては、こちらのソリューションを御覧ください。

真実 その9:BigQuery はきめ細かいアクセス制御を 行・列 のレベルまでサポートしている

BigQuery の IAM による制御の最小粒度がデータセット単位であるという真実は、よくテーブル単位での制御や行、列レベルでのアクセスコントロールができないという誤解を招きます。しかしながら、承認済みビューを利用することで、より細かいアクセス制御を実現できます。承認済みビューによって、ビューの裏にあるテーブルをユーザーに read させず、クエリを実行させることが可能になります。 SESSION_USER() 機能をりようして、ユーザーに見せてよい行を動的にコントロール可能です。例えば、 private.access_control という名前のマッピングテーブルに対し、承認済みビューを設定する SQL クエリは以下のとおりです。

#standardSQL
SELECT c.customer, c.id
FROM `private.customers` c
INNER JOIN (
SELECT group
FROM `private.access_control`
WHERE SESSION_USER() = user_name) g
ON c.allowed_group = g.group

真実 その10:BigQuery は幅広く GCP およびサードパーティーの製品両方とインテグレーションされている

Data Studio, Cloud Datalab, Cloud Dataproc, Cloud Dataflow, Cloud Machine Learning Engine のような GCP プロダクトに加えて、 BigQuery と一緒に利用できる豊富なパートナー製ツールの一覧があります。

BigQuery にカスタムアプリケーションを接続するには、多くの一般的なプログラミング言語をカバーしているクライアントライブラリ、もしくは BigQuery REST API を直接利用できます。

また、伝統的なアプリケーションや簡単に修正できないアプリケーションからの接続のためには、 BigQuery の JDBC および ODBC ドライバーを利用することが出来ます。

真実 その11:暗号化キーを制御できる

BigQuery の中に保管されたデータはデフォルトで暗号化されます。 BigQuery の最近のリリースで、 Beta ではありますが、ユーザ管理の暗号鍵による暗号化がサポートされました。こちらのドキュメントでデータの暗号化をしなければならない際にどのような選択肢があるか確認することができます。

真実 その12:BigQuery の利用を監視、監査できる

Stackdriver を用いて BigQuery を監視し、また BigQuery のメトリクスにアラートを設定したり、様々なグラフを設定したりできます。例えば、 Query Time メトリクスを用いてシステムのスループットを監視したり、 Slots Allocated メトリクスを用いてクエリの需要のトレンドを可視化することができます。システムの状態にプロアクティブに気づけるようにするには、アラートをしきい値に対して設定することができます。Stackdriver はセルフサービスの Web ベースのポータルを提供していますので、 Stackdriver アカウントを通していつでも確認することが可能です。

Bigquery はユーザーの行動を自動的に監査ログに残します。監査ログは 利用しているものと異なる BigQueryのデータセットにストリーミングまたはバッチでエクスポートすることができ、ログを好きなツールで可視化することができます。詳細については、 BigQuery を使用して監査ログを分析する のページを御覧ください。 この記事の「Analyzing BigQuery Usage」章では、 BigQuery の監査ログを可視化し、どの様に請求に関する質問を対応をするかということが書かれています。このテクニックは、他の洞察を監査ログから導く際ももちろん利用可能です。

次のステップ

この記事が BigQuery に関するいくつかの誤解を正す手助けにてくれたら幸いです。もしもう少し詳細をお知りになりたい場合には、 最近アップデートされた データ ウェアハウス使用者向け BigQuery のドキュメントや、 Teradata のデータ ウェアハウジングから GCP のビッグデータへの移行 をご確認ください。

--

--

Yuta Hono
google-cloud-jp

Solutions Eng at @Google, @GoogleCloud. Opinions are my own, NOT the views of my employer. All posts here are my personal opinion.