BigQuery リソースの整理

他の Google Cloud サービスと同様に、BigQuery のリソースは階層構造になっています。この階層を使用して、権限、割り当て、スロットの予約、課金など、BigQuery のワークロードを管理できます。

リソース階層

BigQuery は Google Cloud のリソース階層を継承し、BigQuery に固有のデータセットというグループ化メカニズムを使用します。このセクションでは、この階層要素について説明します。

データセット

データセットは、BigQuery リソースへのアクセスを整理して制御するために使用される論理コンテナです。データセットは他のデータベース システムのスキーマと似ています。

テーブル、ビュー、関数、プロシージャなど、作成する BigQuery リソースの大半はデータセット内に作成されます。接続とジョブは例外で、これらはデータセットではなくプロジェクトに関連付けられます。

データセットにはロケーションが設定されています。テーブルを作成すると、テーブルデータがデータセットのロケーションに保存されます。本番環境のデータにテーブルを作成する前に、ロケーションの要件を考慮してください。データセットの作成後にロケーションを変更することはできません。

プロジェクト

すべてのデータセットはプロジェクトに関連付けられています。Google Cloud を使用するには、少なくとも 1 つのプロジェクトを作成する必要があります。プロジェクトは、すべての Google Cloud サービスの作成、有効化、使用の基礎となります。詳細については、リソース階層をご覧ください。1 つのプロジェクトに複数のデータセットを保持できます。また、同じプロジェクトに異なるロケーションのデータセットが存在する場合もあります。

BigQuery データに対して、クエリの実行やテーブルへのデータの取り込みなどの処理を行う場合、ジョブを作成します。ジョブは常にプロジェクトに関連付けられていますが、データを含むプロジェクト内で実行する必要はありません。実際、1 つのジョブで複数のプロジェクトのデータセットのテーブルを参照することもあります。クエリジョブ、読み込みジョブ、エクスポート ジョブは常に、参照するテーブルと同じロケーションで実行されます。

各プロジェクトには Cloud 請求先アカウントが関連付けられます。プロジェクトで発生した費用は、そのアカウントに請求されます。オンデマンド料金を使用する場合、クエリを実行するプロジェクトに料金が請求されます。容量ベースの料金を選択している場合、スロットの予約は、スロット購入に使用した管理プロジェクトに課金されます。ストレージは、データセットが存在するプロジェクトに課金されます。

フォルダ

フォルダは、プロジェクトの上位にある追加のグループ化メカニズムです。1 つのフォルダ内のプロジェクトとフォルダは、親フォルダのアクセス ポリシーを自動的に継承します。フォルダは、異なる法人、部門、社内チームのモデル化に使用できます。

組織

組織リソースは、組織（会社など）を表し、Google Cloud リソース階層のルートノードです。

BigQuery の使用を開始するときに組織リソースは必要ありませんが、組織リソースを作成することをおすすめします。組織リソースを使用すると、個々のユーザーが作成するリソースではなく、BigQuery のリソースを一元管理できます。

次の図は、リソース階層の例を示しています。この例では、組織のフォルダ内にプロジェクトが存在します。プロジェクトは請求先アカウントに関連付けられており、3 つのデータセットが含まれています。

考慮事項

BigQuery リソースの整理方法を選択する際は、次の点を考慮してください。

• 割り当て。BigQuery の割り当ての多くはプロジェクト レベルで適用されます。データセット レベルで適用される場合もあります。クエリや読み込みジョブなどのコンピューティング リソースを対象とするプロジェクト レベルの割り当ては、ストレージ プロジェクトではなく、ジョブを作成するプロジェクトに対してカウントされます。
• 課金。組織内のさまざまな部門で別々の Cloud 請求先アカウントを使用する場合は、チームごとに異なるプロジェクトを作成します。組織レベルで Cloud 請求先アカウントを作成し、アカウントをプロジェクトに関連付けます。
• スロットの予約。予約済みスロットのスコープは組織リソースに限定されます。予約したスロット容量を購入すると、スロットのプールを組織内のプロジェクトまたはフォルダに割り当てるか、組織リソース全体に割り当てることができます。プロジェクトは親フォルダまたは組織からスロット予約を継承します。予約済みスロットは、スロットの管理に使用される管理プロジェクトに関連付けられます。詳細については、Reservations を使用したワークロード管理をご覧ください。

• 権限。データにアクセスする組織内のユーザーに権限階層がどのように影響するのかを検討してください。たとえば、チーム全体に特定のデータへのアクセス権を付与する場合は、そのデータを 1 つのプロジェクトに保管することでアクセス管理を簡素化できます。

  テーブルなどのエンティティは親データセットの権限を継承します。データセットは、リソース階層（プロジェクト、フォルダ、組織）内の親エンティティから権限を継承します。リソースに対する処理を実行するには、リソースに関連する権限と BigQuery ジョブの作成権限の両方が必要です。ジョブの作成権限は、そのジョブで使用されるプロジェクトに関連付けられています。

パターン

このセクションでは、BigQuery リソースを編成するための 2 つの一般的なパターンを紹介します。

• 中央データレイク、部門データマート。組織は、元データを保持する統合ストレージ プロジェクトを作成します。組織内の部門は、分析用に独自のデータマート プロジェクトを作成します。

• 部門のデータレイク、中央データ ウェアハウス。各部門は独自のストレージ プロジェクトを作成、管理し、その部門の元データを保持します。次に、分析に使用する中央データ ウェアハウス プロジェクトを作成します。

各アプローチには長所と短所があります。多くの組織では、両方のパターンの要素を統合しています。

中央データレイク、部門データマート

このパターンでは、組織の元データを保持する統合ストレージ プロジェクトを作成します。データの取り込みパイプラインは、このプロジェクトでも実行できます。統合ストレージ プロジェクトは組織のデータレイクとして機能します。

各部門には専用のプロジェクトがあり、このプロジェクトではデータのクエリ、クエリ結果の保存、ビューの作成が行われます。これらの部門レベルのプロジェクトはデータマートとして機能します。部門の請求先アカウントに関連付けられます。

この構造の利点は次のとおりです。

• 一元化されたデータ エンジニアリング チームが取り込みパイプラインを 1 か所で管理できます。
• 元データは、部門レベルのプロジェクトから分離されています。
• オンデマンド料金では、クエリの実行料金がクエリを実行した部門に課金されます。
• 容量ベースの料金では、予想されるコンピューティング要件に基づいて各部門にスロットを割り当てることができます。
• プロジェクト レベルの割り当ての点で、各部門は他の部門から分離されています。

この構造を使用する場合、一般的な権限は次のとおりです。

• 中央のデータ エンジニアリング チームには、ストレージ プロジェクトに対する BigQuery データ編集者と BigQuery ジョブユーザーのロールが付与されます。これにより、ストレージ プロジェクト内でのデータの取り込みと編集が可能になります。
• 部門のアナリストには、中央データレイク プロジェクト内の特定のデータセットに対する BigQuery データ閲覧者のロールが付与されます。データのクエリは可能ですが、元データの更新や削除はできません。
• また、部門アナリストには、部門のデータマート プロジェクトに対する BigQuery データ編集者のロールとジョブユーザーのロールも付与されます。これにより、部門内で使用するデータを変換または集計するために、プロジェクト内でテーブルを作成および更新し、クエリジョブを実行できます。

詳細については、Eventarc のロールと権限をご覧ください。

部門のデータレイク、中央データ ウェアハウス

このパターンでは、各部門が独自のストレージ プロジェクトを作成して管理します。このプロジェクトには、その部門の元データが格納されています。中央のデータ ウェアハウス プロジェクトに元データの集計または変換が保存されます。

アナリストは、データ ウェアハウス プロジェクトから集計されたデータをクエリして読み取ることができます。データ ウェアハウス プロジェクトには、ビジネス インテリジェンス（BI）ツール用のアクセスレイヤも用意されています。

この構造の利点は次のとおりです。

• 部門ごとに個別のプロジェクトを使用すると、部門レベルでデータアクセスを簡単に管理できます。
• 中央の分析チームには分析ジョブを実行する単一のプロジェクトがあるため、クエリのモニタリングが容易になります。
• ユーザーは元データから分離され、一元化された BI ツールからデータにアクセスできます。
• スロットをデータ ウェアハウス プロジェクトに割り当てて、アナリストや外部ツールからのすべてのクエリを処理できます。

この構造を使用する場合、一般的な権限は次のとおりです。

• データ エンジニアには、部門のデータマートで BigQuery データ編集者と BigQuery ジョブユーザーのロールが付与されます。これらのロールにより、データを取り込み、データマートに変換できます。
• アナリストには、データ ウェアハウス プロジェクトの BigQuery データ編集者と BigQuery ジョブユーザーのロールが付与されます。これらのロールにより、データ ウェアハウス内で集計ビューを作成し、クエリジョブを実行できます。
• BigQuery を BI ツールに接続するサービス アカウントには、特定のデータセットに対する BigQuery データ閲覧者ロールが付与されます。このロールでは、データレイクの元データまたはデータ ウェアハウス プロジェクトの変換済みデータを保持できます。

詳細については、Eventarc のロールと権限をご覧ください。

また、承認済みビューや承認済みユーザー定義関数（UDF）などのセキュリティ機能を使用すると、データマート プロジェクトの元データを表示する権限は付与しなくても、集計データを特定のユーザーが利用できます。

このプロジェクト構造により、データ ウェアハウス プロジェクトで多くのクエリが同時に発生する可能性があります。その結果、同時クエリの上限に達する場合があります。この構造を使用する場合は、プロジェクトの割り当て上限の引き上げを検討してください。また、クエリを実行するためのスロットプールを購入できるように、容量ベース課金の使用も検討してください。