データ基盤とデータパイプライン — データが「流れる」仕組みを設計する

導入

「分析したいのに、データが販売システムや在庫DBや配送ログにバラバラに散らばっていて使えない」——そんな経験はないでしょうか。データを一か所に集め、自動的に整えて届ける「データ基盤」と「データパイプライン」の仕組みを確認していきます。

くわしく知ろう

データ基盤は3層で構成されています。ソース層には業務システムが生成した生データがあり、蓄積層ではデータレイクとDWHが役割を分担します。データレイクは構造化・非構造化を問わず生データを全量蓄積するストレージで、加工前の原石を保管する倉庫のようなものです。一方DWHは分析目的に合わせて整形されたデータを格納し、集計クエリを高速に実行できます。活用層にはデータマートやBIツールが位置し、経営層や現場担当者が直接参照します。

データをソースから蓄積層へ運ぶ仕組みがデータパイプラインです。従来の方式はETL（Extract-Transform-Load）と呼ばれ、ソースからデータを抽出し、中間サーバーで変換・整形した後にDWHへロードします。近年のクラウドDWH環境ではELT（Extract-Load-Transform）が主流になっています。ELTは先にDWHへ生データをロードし、DWH上の処理能力を活かして後から変換を行う方式で、クラウドの高い演算性能を柔軟に活用できる点が利点です。

データパイプラインの実行スケジュールを管理する仕組みをデータオーケストレーションといいます。Apache Airflowはその代表的なOSSで、タスク間の依存関係や実行順序をDAG（有向非巡回グラフ）として定義し、処理を自動的に調整します。

データの流し方にはストリーミング処理とバッチ処理の2種類があります。ストリーミング処理はデータが発生した瞬間にリアルタイムで処理する方式で、在庫の即時反映や不正検知に適しています。バッチ処理は一定期間のデータをまとめて定期的に処理する方式で、夜間の売上集計や月次レポート生成に適しています。代表的なクラウドデータ基盤としてBigQuery（Google）、Redshift（AWS）、Synapse Analytics（Azure）があります。

具体例

EC事業を例に挙げると、受注データ（Salesforce）・在庫DB（PostgreSQL）・配送ログ（S3）をELTでBigQueryにロードし、パイプラインでリアルタイム変換を行い、データマートの在庫分析テーブルをBIダッシュボードへ連携します。在庫残量のアラートにはストリーミング処理を、日次の売上集計にはバッチ処理を使い分けることで、現場の意思決定スピードを高めています。

まとめ・試験ポイント

• データ基盤3層＝ソース層（生データ）→蓄積層（データレイク・DWH）→活用層（データマート・BI）
• データレイク＝生データを全量蓄積する原石倉庫、DWH＝分析用に整形済みのデータベース
• ETL＝変換してからロード、ELT＝先にロードしてDWH上で変換（クラウドDWHに適する）
• ストリーミング処理＝リアルタイム処理（在庫反映・不正検知）、バッチ処理＝定期まとめ処理（夜間集計）
• クラウドデータ基盤の代表例＝BigQuery（Google）・Redshift（AWS）・Synapse Analytics（Azure）
• データオーケストレーション＝パイプラインのスケジュール・依存関係管理（Apache Airflow等）

※本コンテンツは2026年3月公表の改定案 Ver.1.0 に基づく暫定版です