Contents
データレイクの基本概念と GCP が提供するメリット
1‑1. データレイクとは何か
公式ドキュメント（Google Cloud Learn – Data Lake）では、「大量・多様なデータを低コストで長期保存し、検索・分析が可能なプラットフォーム」 と定義されています。構造化・半構造化・非構造化のいずれもそのまま格納できる点が、従来のデータウェアハウスと最大の違いです。
1‑2. GCP が実現する３つのメリット
| 項目 | 従来オンプレミス環境 | GCP の提供価値 |
|---|---|---|
| ストレージ | ハードウェア増設が必要で数週間かかる | Cloud Storage はペタバイト規模まで自動スケール、課金は使用量のみ（Pricing） |
| ガバナンス | 複数ツールを組み合わせて手作業で管理 | Dataplex がメタデータカタログ・ポリシーエンジンを一元提供（Dataplex Docs） |
| コストモデル | 設備投資＋保守費用が固定的 | ペイ・アズ・ユー・ゴーでスケールダウンも即時可能 |
1‑3. 具体的な活用シーン
- 大規模 IoT ログの長期保存 → 後方解析や機械学習トレーニングに利用。
- 多様な部門が保有する CSV/JSON/Parquet を統合し、Dataplex の自動スキャンで検索性を向上。
GCP の主要サービス構成（Dataplex・BigLake など）
2‑1. Dataplex – メタデータ管理とポリシー適用のハブ
- レイク/ゾーン：論理的にデータを集合化し、ライフサイクル（RAW／CURATED）ごとに分割。
- 自動スキャン：Cloud Storage の内容を日次で走査し、スキーマ・フォーマット情報を抽出して Data Catalog に登録。
- ポリシーエンジン：タグベースのアクセス制御やデータ保持ルールを一括管理（Dataplex policy docs）。
2‑2. BigLake – オブジェクトストレージ上にテーブル層を構築
- 外部テーブル：Parquet、ORC、Avro などのファイルを BigQuery から直接クエリ可能（BigLake Overview）。
- 統一ストレージとウェアハウス：データコピーが不要なため、ETL コストとレイテンシが大幅に削減。
2‑3. 補助サービスの位置付け
| サービス | 主な役割 |
|---|---|
| Cloud Storage | 永続的オブジェクト保存基盤 |
| BigQuery | 高速分析エンジン（BigLake テーブルをクエリ） |
| Dataflow / Dataproc | ストリーミング／バッチ ETL |
| Pub/Sub | イベント駆動型データインジェスト |
| Cloud Monitoring & Logging | 運用可視化・アラート |
| IAM & VPC Service Controls | アクセス制御と境界保護 |
構築前の事前準備：プロジェクト作成・請求設定・API 有効化
3‑1. プロジェクトと請求アカウントの紐付け
|
1 2 3 4 5 6 7 8 9 |
# プロジェクト作成（例：data-lake-demo） gcloud projects create data-lake-demo \ --name="Data Lake Demo" \ --set-as-default # 請求アカウントをリンク（ACCOUNT_ID はコンソールで確認） gcloud beta billing projects link data-lake-demo \ --billing-account=ACCOUNT_ID |
ポイント：請求アラートは「予算とアラート」から月額上限の 80% に達したら通知を設定すると、思わぬコスト増を防げます（Budget docs）。
3‑2. 必要な API の有効化
公式テンプレート一覧は Dataflow 提供テンプレート ページに掲載されています
(Provided templates)。以下のコマンドで一括有効化できます。
|
1 2 3 4 5 6 7 8 9 10 |
gcloud services enable \ dataplex.googleapis.com \ biglake.googleapis.com \ storage.googleapis.com \ bigquery.googleapis.com \ dataflow.googleapis.com \ monitoring.googleapis.com \ iam.googleapis.com \ pubsub.googleapis.com |
3‑3. IAM の最小権限セット（推奨ロール）
| ロール | 主な権限 |
|---|---|
roles/dataplex.admin |
Dataplex のレイク／ゾーン作成・管理 |
roles/bigquery.dataEditor |
BigQuery テーブルの読み書き |
roles/dataflow.admin |
Dataflow ジョブのデプロイとモニタリング |
roles/storage.objectAdmin |
Cloud Storage バケット操作 |
Dataplex でレイク・ゾーンを作成し資産を管理する手順
4‑1. レイクの作成
コンソール手順と
gcloudコマンドの両方を示します。
コンソール
1. Dataplex → Create lake
2. 名前：company-data-lake、リージョン：us-central1
3. 「Storage bucket」欄で既存バケット（例 gs://data-lake-bucket/）を選択または新規作成
CLI
|
1 2 3 4 |
gcloud dataplex lakes create company-data-lake \ --region=us-central1 \ --storage-bucket=gs://data-lake-bucket/ |
4‑2. ゾーンの定義（RAW / CURATED）
| ゾーンタイプ | 用途 | 推奨バケットパス |
|---|---|---|
RAW |
生データ保存、最小変換 | gs://data-lake-bucket/raw/ |
CURATED |
加工済みデータ、分析向け | gs://data-lake-bucket/curated/ |
CLI 例（RAW）
|
1 2 3 4 5 6 7 |
gcloud dataplex zones create raw-zone \ --lake=company-data-lake \ --region=us-central1 \ --type=RAW \ --resource-location-type=SINGLE_REGION \ --bucket=gs://data-lake-bucket/raw/ |
4‑3. 自動スキャンとメタデータ生成
|
1 2 3 4 |
gcloud dataplex zones update raw-zone \ --discovery-enabled \ --schedule="0 */6 * * *" # 6 時間ごとに実行 |
結果は Data Catalog に自動登録され、検索 UI（Data Catalog Search）で即座に利用可能。
4‑4. タグ付けとポリシーの適用
|
1 2 3 4 5 6 7 8 |
# カスタムタグテンプレート作成（例：PII 判定） gcloud data-catalog tags create-template pii-tag \ --field=pii:BOOL # エンティティにタグ付与 gcloud data-catalog entries add-tags projects/PROJECT_ID/locations/us-central1/entryGroups/.../entries/... \ --tag=projects/PROJECT_ID/locations/us-central1/tagTemplates/pii-tag |
ポイント：Dataplex のポリシーエンジンと組み合わせることで、
pii:trueタグが付いたテーブルへのアクセスはroles/bigquery.dataViewerではなく、限定されたロールにしか許可されません。
4‑5. セキュリティ設定のベストプラクティス
| 項目 | 推奨設定 |
|---|---|
| IAM ロール | レイク単位は roles/dataplex.viewer、ゾーン単位は roles/dataplex.dataOwner（最小権限） |
| VPC Service Controls | プロジェクトをサービス境界に追加し、外部 API 呼び出しを制限（VPC SC docs） |
| 暗号化 | CMEK（Customer‑Managed Encryption Keys）を bigquery.googleapis.com と連携し、BigLake テーブルでも同一キーで保護（CMEK guide） |
ETL/ELT パイプラインの実装例（Dataflow / Dataproc）
5‑1. Dataflow の推奨テンプレート ― Pub/Sub → BigLake (Streaming)
公式に提供されている 「Pub/Sub to BigQuery」 テンプレートは、出力先を BigLake 外部テーブル に変更するだけで利用できます（カスタムパラメータ outputTable が外部テーブルでも受け付けられる）。テンプレート一覧は上記リンク参照。
|
1 2 3 4 5 6 7 8 9 |
gcloud dataflow jobs run ingest-raw-stream \ --gcs-location=gs://dataflow-templates/latest/PubSub_to_BigQuery \ --region=us-central1 \ --parameters=\ inputTopic=projects/${PROJECT_ID}/topics/raw-data,\ outputTable=${PROJECT_ID}.dataset.raw_external_table,\ useBigLake=true,\ format=PARQUET |
注意点：
StreamToBigLakeという名前のテンプレートは現行提供には存在しません。代わりに上記公式テンプレートをベースに Flex Template（自作）でuseBigLake=trueを指定する形が実装例として妥当です。（Flex Template の作成方法はこちら）
5‑2. バッチ変換 – Dataproc + Spark
|
1 2 3 4 5 6 7 |
gcloud dataproc jobs submit spark \ --cluster=dataproc-batch-cluster \ --region=us-central1 \ --class=com.example.BatchTransform \ --jars=gs://my-jars/batch-transform.jar \ -- gs://data-lake-bucket/raw/ gs://data-lake-bucket/curated/ |
Spark ジョブは Parquet 化・パーティション付与を行い、出力先は CURATED ゾーンのバケットです。
5‑3. BigLake テーブル作成（外部テーブル化）
|
1 2 3 4 5 6 7 |
CREATE EXTERNAL TABLE `project.dataset.curated_table` OPTIONS ( format = 'PARQUET', uri = 'gs://data-lake-bucket/curated/*', use_biglake = true -- BigLake 機能を有効化 ); |
このテーブルは BigQuery の標準クエリで扱えるだけでなく、Dataplex が自動生成したメタデータと連携し、検索・ポリシー適用が即座に可能です。
5‑4. パイプライン全体図（テキスト版）
|
1 2 3 4 5 |
Pub/Sub (raw-data) ──► Dataflow (Streaming) ──► BigLake External Table (RAW) │ │ ▼ ▼ Dataproc Spark (Batch) ──► Curated Zone (Parquet) ──► BigLake External Table (CURATED) |
運用・監視・コスト最適化のベストプラクティス
6‑1. Cloud Monitoring ダッシュボード
| メトリクス | 推奨しきい値 | アラート例 |
|---|---|---|
dataflow.googleapis.com/job/failed_jobs |
0 (1 時間以内に >0) | Slack / ChatOps に通知 |
dataplex.googleapis.com/discovery/success_rate |
< 95% | PagerDuty アラート |
storage.googleapis.com/object_count（RAW バケット） |
急増時は 20% 超過で警告 | コスト予測ツールと連携 |
設定手順：Cloud Monitoring → ダッシュボード作成 → 「Add chart」→ メトリクス選択。テンプレートは「Dataplex」「Dataflow」の公式サンプルが利用可能（Monitoring templates）。
6‑2. コスト管理
- 予約インスタンス：Dataflow の
--worker-machine-type=n1-standard-4と--num-workers=5を予約で確保し、約 30% 削減。 - ライフサイクルポリシー（Cloud Storage）
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
gsutil lifecycle set - <<EOF { "rule": [ { "action": {"type":"SetStorageClass","storageClass":"NEARLINE"}, "condition": {"age":30} }, { "action": {"type":"Delete"}, "condition": {"age":365} } ] } EOF gs://data-lake-bucket/ |
- BigLake のクエリ料金最適化：外部テーブルはスキャンした列だけ課金されるため、
SELECT column1, column2 FROM …と限定的に取得。
6‑3. ガバナンス自動化
|
1 2 3 |
gcloud dataplex zones update curated-zone \ --policy='{"rules":[{"condition":{"expression":"metadata.pii == true"},"action":"DENY"}]}' |
上記は「PII タグが付いたテーブルへのアクセスを全ユーザーに対し拒否」するポリシー例です。
全体まとめと次のステップ
- 概念 – データレイクは「あらゆる形式のデータをそのまま保存し、必要時に分析」できる基盤であり、GCP の Cloud Storage + Dataplex + BigLake が公式に提供するフルマネージドスタックです。
- サービス構成 – Dataplex がメタデータとポリシーを一元管理し、BigLake がストレージ上のファイルをテーブル化して BigQuery から即時クエリ可能にします。
- 事前準備 – プロジェクト・請求アカウントの紐付けと必須 API の有効化は最初のハードルです。最小権限ロールでセキュリティを担保しつつ、予算アラートでコスト漏れ防止を設定しましょう。
- Dataplex 実装 – レイク → ゾーン → 自動スキャン → タグ付与 の流れでデータ資産は自動的にカタログ化されます。IAM と VPC Service Controls による境界保護を併用すれば、機密データも安全に管理できます。
- ETL/ELT – 推奨パイプラインは Dataflow（Pub/Sub → BigLake） のストリーミングと、必要に応じた Dataproc/Spark バッチ です。公式テンプレートをベースに Flex Template を作成すれば、
StreamToBigLakeのような非実在テンプレートは回避できます。 - 運用・最適化 – Cloud Monitoring ダッシュボードとアラートでジョブの可視性を確保し、予約インスタンス・ストレージライフサイクルでコストを削減します。また Dataplex のポリシーエンジンでデータ保持や PII 制御を自動化すれば、ガバナンス負荷が大幅に低減します。
次のアクション
1. 本稿の手順通りに プロジェクト作成 → API 有効化 を完了させる。
2. Dataplex のレイク・ゾーンを作成し、サンプル CSV/Parquet データで自動スキャンを試す。
3. Dataflow Flex Template（公式 Pub/Sub→BigQuery）をベースに BigLake 用パラメータ を追加し、ストリーミングインジェストを実装する。
4. Cloud Monitoring にカスタムダッシュボードとアラートポリシーを設定し、運用フェーズへ移行する。
これらのステップを順に踏むことで、スケーラブルかつガバナンスが徹底されたモダンデータレイク を GCP 上に構築でき、ビジネスインサイト取得や機械学習パイプラインへの活用基盤としてすぐに利用可能になります。