データ基盤のスケーリング戦略――10GB・10TB・1PBで変わる設計判断

データ基盤の設計判断は、データ量のオーダーで根本的に変わります。10GB級の組織と1PB級の組織では、使うツールも、チーム構成も、チューニングの観点もまるで異なります。本記事では、10GB・10TB・1PBの3段階でスケーリング戦略を整理し、各段階の設計判断と落とし穴を解説します。

データ量で設計は根本的に変わる

「データが増えたら同じ構成を拡張すればいい」という発想は、一定規模を超えると通用しなくなります。10GBの世界ではシンプルさが正義、10TBではチューニングの世界、1PBではアーキテクチャの根本見直しが必要です。どの段階にいるかを正しく認識し、次の段階の構成を見据えて設計することが重要です。

ここで述べる「GB / TB / PB」は単に保存サイズではなく、クエリ対象となるアクティブデータの目安です。コールドデータを含めるとさらに桁が大きくなる場合があります。

10GBスケール――シンプルさが正義

10GBクラスでは、何を選んでも動きます。BigQueryでもSnowflakeでもPostgreSQLでも、快適に動作します。この段階で重要なのは「シンプルさ」と「次のフェーズへの移行しやすさ」の両立です。

典型的な構成はBigQuery無料枠 + Airbyte OSS + dbt Core + Metabaseで、月額数千円〜数万円の範囲に収まります。パーティショニングやクラスタリングを意識する必要はほとんどなく、テストを書いて日次バッチを回せば十分です。むしろ、この段階でアーキテクチャを複雑にしすぎないよう気を付けてください。

10GB級でよく見る失敗は「将来のために過剰設計する」ことです。スキーマレスに全てを溜めたり、ストリーム処理基盤を先行導入したりしても、データ量が少ないうちは使い切れずに運用負荷だけが残ります。

10TBスケール――パフォーマンスチューニングの世界

10TBに入ると、クエリが遅くなり始め、月額費用も目に見えて上昇します。パーティショニング、クラスタリング、インクリメンタルモデル、マテリアライズドビューといったチューニング技法が効いてくる領域です。

BigQueryならパーティショニング＋クラスタリングでスキャン量を大幅に削減できます。以下は典型的な設定例です。

CREATE TABLE marts.fct_orders
PARTITION BY DATE(order_date)
CLUSTER BY customer_id, region
OPTIONS(
  partition_expiration_days = 365,
  require_partition_filter = TRUE
) AS
SELECT * FROM {{ ref('int_orders_enriched') }};

dbtでは`materialized=’incremental’`を使い、日次で差分だけを再計算するのが定石です。全件再計算はコストと時間の両面で現実的でなくなります。

この段階では、データ品質の問題も目立ち始めます。Elementary / Monte CarloなどのオブザーバビリティツールとdbtテストでSLAを守る運用を確立しましょう。チーム構成も専任のデータエンジニア2〜3名 + アナリティクスエンジニアが必要になってきます。

1PBスケール――アーキテクチャの根本見直し

1PBに達すると、「DWHにすべて突っ込む」方針は破綻します。ホット / コールドの分離、オブジェクトストレージ + オープンテーブルフォーマットの採用、Spark / Trinoによる分散処理、専用ストリーム処理基盤など、アーキテクチャそのものを見直す必要があります。

この段階ではDatabricks(Delta Lake + Spark)やSnowflake + Icebergといったレイクハウスアーキテクチャが主流です。BigQueryもPBスケールに対応していますが、コスト管理と権限設計の複雑さが桁違いに増します。

組織面では、データプラットフォームチームが部門として確立されることが多くなります。SRE的な視点を持つエンジニア、データモデラー、アナリティクスエンジニア、ガバナンス担当が専門分業し、データメッシュ的な分散所有に移行するケースも見られます。

スケール別推奨構成

各スケールの推奨構成を1つの表で俯瞰します。

観点	10GB	10TB	1PB
DWH	BigQuery無料枠	Snowflake / BigQuery	Databricks / Snowflake + Iceberg
Ingestion	Airbyte OSS	Fivetran	Fivetran + 自作CDC
Transform	dbt Core	dbt Cloud	dbt Cloud + SQLMesh / Spark
BI	Metabase	Looker / Tableau	Looker + BIセマンティック層
品質監視	dbt tests	dbt tests + Elementary	Monte Carlo / Soda
チーム規模	1〜2名	3〜8名	15名以上
月額コスト目安	1〜15万円	100〜500万円	5,000万円以上

各スケールの構成を図で示します。

【スケール別構成図】

10GB:
[Sources] -> [Airbyte] -> [BigQuery] -> [dbt Core] -> [Metabase]

10TB:
[Sources] -> [Fivetran] -> [Snowflake] -> [dbt Cloud] -> [Looker]
                              |                 |
                              +-> [DataHub]     +-> [Elementary]

1PB:
[Sources] -> [Fivetran + CDC] -> [Object Storage (S3/GCS)]
                                     |
                                     v
                       [Delta / Iceberg Table Format]
                                     |
                   +-----------------+-----------------+
                   v                 v                 v
               [Databricks]      [Trino/Presto]    [Spark Jobs]
                   |                 |                 |
                   v                 v                 v
           [dbt Cloud / SQLMesh] [BI Semantic Layer] [Looker/Tableau]

スケーリングの落とし穴

スケーリング時によく陥る落とし穴を表に整理しました。先回りして手を打つことで、痛みを最小化できます。

落とし穴	症状	対策
パーティショニング未設定	フルスキャンで費用急増	DATE / タイムスタンプ列で分割
全件再計算の放置	dbt runが数時間	incrementalモデル採用
コールドデータ未分離	ストレージ費増大	アーカイブ / BI Engineから除外
権限管理の属人化	退職で止まる	TerraformでRBAC管理
モノリシックなモデル	変更不能	ドメイン分割 / データメッシュ
テストカバレッジ不足	障害多発	dbt tests + Elementary自動化

まとめ

データ基盤は量のオーダーで別物になります。10GBではシンプルさ、10TBではチューニング、1PBではアーキテクチャ再設計――それぞれのフェーズで正しい手を打ち続けることが、持続可能な基盤の条件です。先のフェーズを見据えつつ、今のフェーズに合った構成を保ち続けてください。

よくある質問

データ量が増えたら何から見直すべきですか?

まずパーティショニングとクラスタリングの最適化から始めましょう。これだけでクエリ性能が数倍改善するケースが多いです。次にインクリメンタルモデル化、最後にコールドデータ分離の順が費用対効果の高いアプローチです。

PBスケールにはどのDWHが適していますか?

Databricks（Spark + Delta Lake）またはSnowflakeが実績豊富です。BigQueryもPBスケールに対応していますが、コスト管理がより重要になります。選定時には既存のデータエコシステムとの親和性も考慮してください。

スケーリングでコストを抑えるコツは?

ホットデータ / コールドデータの分離、不要データの定期削除、クエリパターンに合わせたパーティショニングの3つが基本です。BI Engineやマテリアライズドビューを使い、よく使われるクエリをキャッシュすることも効果的です。