BigQuery導入の裏話と苦労話

はじめに

この記事では、私たちのチームがBigQueryを導入し、本格運用するまでに経験した苦労や裏話を中心にまとめました。
BigQueryのレビュー記事をFindy Toolsにて執筆しました。

レビュー記事では触れられなかった、「初期のスコープが広がった際の対応」や、「環境分離を実現するためのTerraform導入のプロセス」について詳しく紹介します。

アーキテクチャ

主要なデータはS3にデータの集約を既に行っていたため、BigQuery Data Transfer Serviceを利用してBigQueryに連携しました。
データパイプラインの開発はTerraformを用い、バージョン管理やリソースの一覧化を行った。

BigQuery導入の背景

当時の課題

社内には既にさまざまなデータが蓄積されていましたが、それらを整理・統合して簡単に分析できる「データマート」が存在していませんでした。そのため、各部署やチームが都度データを整形し、分析レポートを作成する非効率な状況が続いていました。

目指した状態

データマートを導入し、誰もが「使いやすく」「再利用可能」な形でデータを活用できる仕組みを構築することを目標にしました。

• Before: 各チームが都度データを準備して分析
• After: 整形済みのデータマートを参照して分析可能

ツール選定と導入の決め手

比較したツール

• Amazon Athena
• dbt

決め手

1. コスト
   • 小規模から利用できる従量課金制であるBigQuery + Dataformを採用しました。特にDataformは無料で利用可能で、dbtの月額固定費（2023年当時は月50ドル）と比較すると、試験導入には最適でした
2. 使いやすさ
   • BigQueryとDataformの親和性が高く、Google Workspaceとの連携が容易でした

苦労したポイント

導入当初は「お試し利用」からスタートしましたが、本格運用へと移行する際に多くの課題に直面しました。以下では、それらの課題と対策について詳しく解説します。

---

スコープの広がり

当初の目的は「データマートを提供すること」だけでしたが、運用を進める中で開発環境の整備、安全性の確保といった新たな要件が次々と浮上しました。これにより、スコープが大幅に広がり、以下の対応が必要になりました。

環境分離の必要性

• 課題: 開発環境と本番環境を同一環境で運用していたため、その結果、テストや変更が本番に影響を及ぼすリスクがありました
• 解決策: 本番環境と物理的に分離された開発環境を構築することで、影響を最小限に抑え、安全に開発・テストを行えるようにしました

IaC（Infrastructure as Code）の導入

• 課題: 開発環境を本番環境のクローンとして構築するためには、手動でリソースを作成する手間がかかり、人的ミスも発生しやすい状態でした
• 解決策: Terraformを導入し、リソースをコードで管理する体制を整備しました

Terraform導入のメリット

1. リソース管理と一覧化

   • データセットやテーブル、データパイプラインなどのリソースをコードで一元管理することで、全体の見通しが良くなり、設定ミスが大幅に減少しました
   • 容易にロールバックができるようになり、予期しないトラブルが発生しても迅速に復旧できる体制が整いました

2. 環境分離の実現

   • Terraformで管理されたコードをもとに、開発環境と本番環境を完全に分離。これにより、本番環境への影響を心配することなく新機能の開発や検証を行えるようになりました

実際の運用での変化

Terraform導入後、以下のような改善が見られました：

• データパイプラインやデータセットの作成が完全に自動化され、開発速度が向上しました
• 開発環境と本番環境を分離することで、テスト中の障害やエラーによる影響範囲が限定的になり、安心して開発を進められるようになりました

新しい環境導入の課題

環境整備を進める中で、次のような議論や課題も発生しました。

インフラの抽象化

• 課題: データパイプラインやデータセットの命名規則、システムのスコープなどをどこまで細かく管理するかの方針が定まらず、議論が紛糾しました
• 解決策: チーム内で開発ガイドラインはみんなで保守改善していきたい、という認識をすり合わせつつ、最低限のルールを明文化しました

最低限のルールの具体例

開発ガイドラインの作成:

• データマートの構築・テスト・運用の一連の流れをドキュメント化し、新メンバーでも迷わないようにしました
• 後述するスコープアウトした項目をドキュメントに記載し、管理しました

本番環境に絞った権限の整備

• 本番環境のインフラ、データマートの編集者権限を整備しました
• スコープアウトしたもの
  • 開発環境の権限整備: IaCによって最悪即時で作り直せるようになったので、開発環境はスクラップ&ビルドを前提に、ゆるい権限としました
    ディレクトリ管理
• インフラ層を新規で定義し、責務を明示しました

.
├── definitions: Dataform（SQLXワークフロー）を管理
├── infrastructures: Terraformの設定ファイルを管理
│   ├── live: 環境ごとの設定ファイルを管理.モジュール化したリソースを組み合わせて構成.
│   └── modules: データレイクを構成するモジュールを管理
│       ├── bigquery-pipeline: BigQueryのパイプラインを管理
│       ├── datasets: BigQueryのデータセットを管理
│       ├── external-table: 外部テーブルを管理
│       └── scheduler: Cloud Schedulerを管理
└── transfer-scripts: terraform外のデータ転送を管理

データマートの命名規則
- データセット名は、下記表のような規則を設けました
- スコープアウトしたもの
- テーブルの命名規則
- 既存データマートの再整備

ディレクトリ	役割	ユーザーへの公開
Sources	データソースの宣言。データ転送からきたデータセットのデータクレンジングを行う。（データ型の変更, 欠損の補完など）	×
Staging	ソースデータの変換	×
Reporting	変換されたソースデータからの出力テーブルの定義	〇

振り返り

BigQueryの導入は単なるツール選定では終わらず、環境分離やIaCの導入といった「開発体制の変革」までスコープが広がりました。その過程で、コードによる管理や開発ルール合意の重要性を実感しました。

また、初期段階で「スコープの拡張可能性」を見据えた計画ができていれば、もっとスムーズに進められたと感じています。

この記事が、これからデータ基盤を構築しようとする皆さんの参考になれば幸いです！