データ基盤・分析（大規模・リアルタイム）｜2026年版

先に要点

大量データ・リアルタイム・データ組織の段階では、ストリーミング + レイクハウス + オーケストレーション + ガバナンスで束ねます。
具体的には、流入は Kafka / Kinesis / Pub-Sub、基盤は BigQuery / Snowflake / Databricks(レイクハウス)、変換は dbt、実行管理は Airflow / Dagster。
中規模([データ基盤・中規模](/playbook/data-platform-midsize))のバッチELTに、リアルタイム処理と、組織での再利用・統制を足す段階です。
注意は 複雑さとコスト。本当に必要なリアルタイム性と規模だけを、体制とセットで取りにいきます。

「データが膨大」「リアルタイムに近い分析が要る」「複数チームがデータを使う」── ここまで来ると、バッチ中心のデータ基盤・中規模から一段上がり、ストリーミングと、組織で支えるデータ基盤になります。

対象と前提

データ量が大きく、バッチ同期では鮮度・規模が足りない
リアルタイム/準リアルタイムの集計やイベント処理が要る
複数チームがデータを共有・再利用する(データ組織がある)
データの品質・権限・系譜(リネージ)の統制が必要

全体構成（リファレンスアーキテクチャ）

結論: 「流す(ストリーミング) → ためる(レイクハウス) → 整える/回す(dbt + オーケストレーション)」を、ガバナンスで包みます。

読み込み中...

各層の具体的な候補は次のとおりです。

層	役割	具体的な候補(2026年)
流入(ストリーミング)	イベントをリアルタイムに流す	Kafka / Amazon Kinesis / Pub-Sub
基盤(レイクハウス)	大量データの保管と分析を統合	BigQuery / Snowflake / Databricks
変換・実行管理	モデリングとパイプラインの自動実行	dbt + Airflow / Dagster
ガバナンス	品質・権限・系譜(リネージ)	データカタログ + 権限管理 + 監視

レイクハウスは、安価なオブジェクトストレージ上のデータレイクと、DWHの分析能力を統合した考え方です。生データから段階的に整えるメダリオン(bronze→silver→gold)のような層構成で、再利用と品質を両立します。

なぜこれを選ぶか

リアルタイムに対応 ── ストリーミングで、イベントを溜めずに流して処理できる
大量データを束ねる ── レイクハウスで、構造化・非構造化データを一元的に扱える
組織で再利用できる ── 整えたデータとガバナンスで、複数チームが安全に使える

コスト感

2026-06時点の目安(公式で要確認)

規模が大きいぶん費用も大きく、ストリーミング基盤・レイクハウスの計算/保管・オーケストレーションが主な項目です。とくに計算リソースとクエリが効きます。コスト最適化(ストレージ階層・クエリ最適化・不要パイプラインの停止)と監視を仕組みに組み込みます。製品ごとに課金が大きく異なるため、必ず公式と実測で見積もります。

落とし穴

過剰な複雑さ ── リアルタイムが本当に要るか見極める。多くはバッチで足りる。要らないストリーミングは負債
組織・体制 ── 大規模データ基盤は技術より運用体制が要。担い手がいないと破綻する
コスト管理 ── 計算・保管・転送が積み上がる。最適化と上限を継続的に見る
ガバナンス後回し ── 権限・品質・系譜を後付けすると、信頼できないデータ基盤になる

スケール時の移行余地

ここまで来ると、次はML/AIの活用(特徴量ストア、推論基盤)や、組織のデータメッシュ化といった発展になります。いずれも複雑さが大きいので、課題が具体化してから段階的に進めます。

よくある質問

Q. リアルタイム処理は本当に必要ですか？

A. 多くの分析はバッチ(定期同期)で十分です。リアルタイムが要るのは、不正検知・在庫・運用監視・即時パーソナライズなど「数分の遅れが意味を持つ」用途に限られます。要らないのにストリーミング基盤を作ると、複雑さとコストだけが増えます。まず鮮度要件を具体的に確認してから決めます。

Q. データレイクとデータウェアハウス、レイクハウスの違いは？

A. データレイクは安価なストレージに生データを大量にためる場所、DWHは整った分析用のデータベースです。レイクハウスは、データレイクの安さ・柔軟さと、DWHの分析能力を統合しようという考え方で、近年の主流になりつつあります。大規模では、生データはレイクに、整えたデータは分析しやすい形に、と段階的に持ちます。

Q. 中規模との一番の違いは何ですか？

A. リアルタイム性と、組織での運用です。中規模はバッチのELTで「集めて分析」できれば十分ですが、大規模はストリーミングでの即時処理、複数チームでの再利用、品質・権限・系譜のガバナンスが要ります。技術以上に、データ基盤を支える体制(データエンジニアリングの担い手)が成否を分けます。

Q. Kubernetesは要りますか？

A. 必須ではありません。マネージドのストリーミング・DWH・オーケストレーションを使えば、多くはKubernetesなしで構成できます。自前で大規模な処理基盤を運用する場合に選択肢に入りますが、まずはマネージドサービスの組み合わせで始め、本当に必要になってから検討するのが無理がありません。

データ基盤・分析（大規模・リアルタイム）の推奨構成｜2026年版