Webアプリを作ってきたインフラエンジニアがデータ基盤に挑戦するときの道しるべ
最近クラウドインフラエンジニアとしてナウキャストに入社し、Webインフラ経験を土台にデータ基盤を学び始めました。
Webアプリのインフラは継続して扱ってきましたが、データ基盤の設計は選択肢が多く、学習初期に迷いやすい領域でした。
本記事は、インフラエンジニアの視点で、AIと一緒に学びながら整理したデータ基盤構築のナレッジです。
「EC2やRDS、ALBなど触れてきましたが、データ基盤には触れていなかったので、データエンジニアリングってどうやるの？」という疑問から始まった学習記録を、共有できる形にしました。
想定読者:
- Webアプリのインフラは分かるけど、データ基盤は初めて
- RDSとRedshiftって何が違うの？OLTP vs OLAPって何？
- データレイクとデータウェアハウスってどう使い分けるの？
1. 概要
データ基盤とは何か
データ基盤（Data Platform）とは、企業が持つ様々なデータを収集・保存・変換・分析・活用するための統合的なインフラストラクチャです。インフラエンジニアがこれまで扱ってきたWebアプリケーションのインフラ（EC2, ALB, RDS）とは異なり、データ基盤は「大量のデータを効率的に処理し、ビジネス価値を生み出すための分析環境」を提供します。
なぜデータ基盤が必要なのか
従来のWebアプリケーション用のデータベース（RDS, Aurora）は、トランザクション処理に最適化されています。しかし、以下のような分析ニーズには適していないです：
- 数年分の売上データを集計して傾向を分析したい
- 複数のシステムからデータを統合して全社的なレポートを作成したい
- 機械学習モデルを使って予測分析を行いたい
こうしたニーズに応えるために、分析専用のデータ基盤が必要になります。
本記事で学べること
- データ基盤の全体像: OLTP vs OLAP、データレイク vs データウェアハウス
- インフラ構成パターン: 小規模（Lambda + S3 + Athena）、AWS完結型（Glue + Redshift + dbt）、SaaS型（Kinesis + Databricks/Snowflake）
- データベース選定: RDS、Aurora、Athena、Redshift の特徴と使い分け
- 行指向vs列指向ストレージ: データ量とクエリパターンに応じた選択基準
2. 前提知識
この記事は、EC2やRDSなどWebアプリケーションのインフラは触ってきたけど、データ基盤は初めて、というインフラエンジニアを対象としています。以下のような知識があれば読み進められます：
AWS基本サービス
- EC2 : 仮想サーバーの起動・管理
- S3 : オブジェクトストレージの基本操作
- VPC : ネットワーク構成の基礎
- IAM : ロールとポリシーによる権限管理
SQL基礎
- 基本クエリ:
SELECT,WHERE,ORDER BY,GROUP BY - テーブル結合:
JOIN(INNER, LEFT, RIGHT) - 集計関数:
COUNT,SUM,AVG,MAX,MIN
3. 実際に作るとなるとどんなインフラ構成になるか
「データ基盤を構築してください」と言われても、データ量やコストによって構成は大きく変わります。ここでは、AWSを使った代表的な3パターン（小・中・大規模）を整理しました。自分のプロジェクトがどのパターンに当てはまるかを考えながら読んでみてください。
パターンA: 小規模構成 (小規模、月次レポート程度)
対象
- 学習目的、PoC（概念実証）
- スタートアップや小規模プロジェクト
- 初期コストを抑えたい場合
構成図
特徴
-
サーバーレス中心
- サーバー管理不要、運用負荷が低い
- Lambda: データ収集、軽量な変換処理
- Glue Data Catalog: テーブル定義の管理
- Athena: S3上のデータに対してSQLクエリを実行
-
従量課金
- 初期コスト不要、使った分だけ課金
- スモールスタートに最適
-
制約
- 複雑な変換処理には不向き
- Lambda: メモリ10GB、実行時間15分まで
- Athena: クエリのたびにS3をスキャン
- データ量に応じてコスト増）
コスト
| サービス | 何に課金されるか | どうやってコスト抑えるか |
|---|---|---|
| S3 | 保存してるデータ量 | 古いデータはGlacierに自動移行。ライフサイクルポリシー設定すると便利 |
| Glue Data Catalog | メタデータオブジェクト数 | 100万オブジェクトまで無料。普通は課金されない |
| Athena | SQLでスキャンしたデータ量 | パーティション切らないと大量にスキャンされてコストが急増する。必ず設定すべき |
| Lambda | 実行時間とメモリ | メモリは必要最小限に。バッチ処理でまとめて実行するとコスト減る |
| QuickSight | ユーザー数 | Readerライセンスを使うと安い |
ポイント:
- Lambda + S3 + Glue Data Catalog + Athena でサーバーレスなパイプラインが作れます
- Glue Data Catalogはテーブル定義を管理
- dt=YYYY-MM-DD みたいに日付で切るといったパーティション設計が大事です
- Terraformでインフラをコード管理するのが定石です
参考リンク
パターンB: AWS完結型DWH構成 (Redshift中心)
対象
- AWSエコシステムで完結させたいデータ分析基盤
- 既にAWSを活用している、またはAWSに統一したい組織
- Aurora/RDSを主要データソースとしており、Redshiftへ継続同期したい
- データ量：中〜大規模
- 日次バッチ処理、定期的なBIレポート作成
構成図
注: Glue は「データレイクへの投入と整形」、dbt は「DWH内での変換」を担当
特徴
-
Redshift: データウェアハウス
- 列指向ストレージ: 集計クエリが高速
- MPP (Massively Parallel Processing): 並列処理で大量データを処理
- 中〜大規模データの集計に適している
-
Redshift Zero-ETL integration
- Aurora/RDSからRedshiftへ継続的にレプリケーション可能
- ソースDB側の変更をほぼリアルタイムで分析基盤へ反映しやすい
- AWS内で完結しつつ、データ連携の運用負荷を下げられる
-
AWS Glue: マネージドETL
- Sparkベース: 複雑なデータ変換が可能
- Data Catalog: メタデータ管理（テーブル定義、スキーマ）
- サーバーレス: インフラ管理不要
-
dbt (data build tool): SQLベースの変換
- モダンデータスタックの標準ツール
- バージョン管理、テスト、ドキュメント生成が可能
- SQLが書ければ使える（学習コスト低）
-
データレイヤー分け
- Raw層（Bronze）: ソースから取り込んだ生データをそのまま保持する層（変更不可、監査証跡）
- Staging/Warehouse層（Silver）: Bronzeデータに対してマッチング・マージ・フィルタリング・クレンジングを行い、主要なビジネスエンティティを分析しやすい形に再構成する中間層
- Mart層（Gold）: KPI定義や集計ロジックを適用し、レポート・ダッシュボード・部門利用向けに提供する層
参考:
メダリオンアーキテクチャ (Medallion Architecture)
データ分析基盤の3層構造（Datalake / DWH / Datamart）について
コスト
| サービス | 何に課金されるか | どうやってコスト抑えるか |
|---|---|---|
| Redshift | ノード数 × サイズ × 稼働時間 | リザーブドインスタンス買うと最大75%オフ。使わない時間は一時停止するとコストが削減できる |
| AWS Glue | Sparkの実行時間 | 増分処理にして全データ処理しない。ワーカー数も必要最小限に |
| S3 | データ量 | 初期数日間だけ参照され、その後は保管だけされるデータはS3 Glacierに移行するなどライフサイクルポリシー設定を行う |
ポイント:
- Glue ETLでPySparkを書きます
- Redshift の DISTKEY と SORTKEY がパフォーマンスに直結します
- Aurora/RDS連携は、要件によってZero-ETLを有力な選択肢として検討できます
- dbt は SQLでデータ変換を書けるから、アナリストも参加しやすい
- Raw → Staging → Mart という段階的なデータ変換が定石
参考リンク
パターンC: SaaS型DWH構成 (Snowflake/Databricks中心)
対象
- 複数クラウドサービスや多数SaaSに跨るデータを統合したい組織
- 非エンジニアも含めて、セルフサービスで分析しやすい仕組みが必要
- リアルタイム処理や高度な機械学習ワークロードを扱いたい
- マルチクラウド戦略やベンダーロックイン回避を重視している
構成図
特徴
-
S3からの自動取り込み
- Snowpipe（Snowflake）: S3にファイルが置かれたら自動で取り込み（イベント駆動）
- Auto Loader（Databricks）: 新しいファイルを自動検知・取り込み
- GlueやEMRなしで、S3から直接データを取り込める
-
運用負荷の極端な削減
- サーバー管理、パッチ適用、VACUUM、ANALYZEなどの運用作業が不要
- DISTKEYやSORTKEYのような手動チューニングが不要（自動最適化）
- 自動スケーリング、自動バックアップ
-
コンピュートとストレージの完全分離
- 複数のウェアハウス（コンピュートクラスタ）で同じデータに同時アクセス可能
- ETL用、BI用、ML用など、用途別にウェアハウスを分離できる
- ストレージとコンピュートを独立してスケール可能
-
高度な機能とエコシステム
- Snowflake: タイムトラベル、ゼロコピークローン、データシェアリング
- Databricks: Delta Lake（ACID対応）、Spark + ML統合、Notebook環境、MLflow
コスト
| サービス | 何に課金されるか | どうやってコスト抑えるか |
|---|---|---|
| S3 | データ量 | ライフサイクルポリシーで古いデータをGlacierに移行 |
| Snowflake | ウェアハウス稼働時間 + データ量 | 自動停止必ず設定する。アイドル時間設定しないと継続的に課金される |
| Databricks | DBU × 稼働時間 + EC2コスト | 自動終了設定必須。スポットインスタンス使うと最大90%オフ |
ポイント:
- S3にデータを置けば、Snowflake/Databricksが自動で取り込んでくれる
- 運用負荷が低い
- コンピュートとストレージが完全分離しているので、柔軟にスケール可能
- Snowflake: SQLファーストで使いやすい、BIツール連携が強い
- Databricks: Spark + ML統合、Delta Lake、Notebookで試行錯誤しやすい
Snowflake/Databricksに関して詳しくはPart2でまとめたいと思います
参考リンク
- Snowflake公式ドキュメント
- Snowpipe
- Databricks公式ドキュメント
- Auto Loader
- Delta Lakeとは何か
- Databricks のチュートリアルを始める
- Snowflakeで始めるData Lake - Apache Icebergの基本と活用法 -
4. データベースの選定
データ基盤を構築する際、最も重要な判断の一つが「どのデータベースを使うか」です。
前のセクションでインフラ構成パターンを見てきましたが、ここではデータベース選定の基準について深掘りします。
まず理解すべきなのは、Webアプリで使ってきたRDSと、データ分析で使うRedshiftは、
同じ「データベース」という名前でも、設計思想が根本的に異なるという点です。
この違いを理解するために、OLTP（トランザクション処理）とOLAP（分析処理）の概念から見ていきます。
OLTP と OLAP の違い
一般的には、Webアプリで使うRDS (PostgreSQL, MySQL) はOLTP寄り、分析基盤で使うRedshiftやAthenaはOLAP寄りです。ただし実際はプロジェクト要件次第で、1つのシステム内にOLTP/OLAPの性質が混在することもあります。
ここでは理解しやすさのために典型パターンを比較します。
OLTPシステムの特徴
OLTPシステムは、大量のトランザクションデータを処理するよう最適化されたリレーショナルデータベースにデータを保存します。
主な特徴：
- 正規化されたスキーマ: データの重複を排除し、整合性を保つ（第3正規形など）
- ACID トランザクション: Atomicity（原子性）、Consistency（一貫性）、Isolation（独立性）、Durability（永続性）を保証
- 高速な書き込み: INSERT、UPDATE、DELETE が頻繁に発生
- 単一レコード操作: 顧客の注文、商品の在庫更新など、1件ずつ処理
OLAPシステムの特徴
OLAPの多次元スキーマは、複数のデータセット（履歴データ、最新データ、外部データなど）からデータを取得する複雑なクエリに適しています。
主な特徴：
- 非正規化されたスキーマ: スタースキーマやスノーフレークスキーマで、JOINを最小化
- 読み取り中心: SELECT クエリが大半、更新は定期的なバッチ処理
- 集計に最適化: SUM、AVG、COUNT などの集計関数が高速
- 多次元分析: 時間軸、地域軸、商品軸など、複数の軸でデータを切り出し、分析できる
詳細比較
| 項目 | OLTP (トランザクション処理) | OLAP (分析処理) |
|---|---|---|
| 目的 | トランザクション処理 | 分析・集計処理 |
| データモデル | 正規化 | 非正規化、多次元スキーマ |
| ストレージ形式 | 行指向 | 列指向 |
| クエリパターン | 単純なSELECT、INSERT、UPDATE | 集計・分析クエリ（GROUP BY、SUM、COUNT） |
| 応答時間 | ミリ秒単位（即座にレスポンス） | 秒〜分単位（大量データ処理のため） |
| 更新頻度 | 秒単位でリアルタイム更新 | バッチ処理（日次、時間単位） |
| 同時実行 | 数千〜数万の同時トランザクション | 数十〜数百の同時クエリ |
| データソース | 単一アプリケーションからの最新データ | 複数システムからの履歴データ + 最新データ |
| 代表的なDB | RDS, Aurora | Redshift |
| 例 | ECサイトの注文処理、在庫管理 | 過去1年の売上分析、顧客行動分析 |
行指向と列指向の違い
OLTPとOLAPの違いを理解する上で重要なのが、データの保存形式です。行指向（OLTP向き）と列指向（OLAP向き）では、同じデータでも保存方法が大きく異なります。
例えば、SELECT SUM(Amount) FROM sales WHERE City = 'Tokyo' という集計クエリを実行する場合:
- 行指向: すべてのカラムを読み込む必要がある → 遅い
- 列指向:
CityとAmountのカラムだけ読み込む → 速い
例として以下に具体的なデータの保存形式を示します。
【行指向ストレージ (OLTP)】
Row 1: [ID=1, Name=Alice, Age=30, City=Tokyo, Amount=5000]
Row 2: [ID=2, Name=Bob, Age=25, City=Osaka, Amount=3000]
Row 3: [ID=3, Name=Carol, Age=35, City=Tokyo, Amount=7000]
→ 1レコード全体を読み書きするのに最適
【列指向ストレージ (OLAP)】
ID: [1, 2, 3]
Name: [Alice, Bob, Carol]
Age: [30, 25, 35]
City: [Tokyo, Osaka, Tokyo]
Amount: [5000, 3000, 7000]
→ 特定のカラムだけを読み込む集計に最適
→ 同じ型のデータが連続するため圧縮効率が高い
AWS データベース比較
RDS
特徴:
- AWSマネージドなOLTPデータベース
- 行指向ストレージ
- ACID トランザクション保証
用途:
- Webアプリケーション
- 業務システム
- トランザクション処理が中心
スケーラビリティ:
- 垂直スケール: インスタンスサイズ変更（例: t3.medium → r5.2xlarge）
- 水平スケール: リードレプリカ（読み取り専用コピー、最大15台）
コスト:
- インスタンス課金
- ストレージ課金
- リザーブドインスタンスで割引可能
Aurora
特徴:
- AWS独自開発の高性能OLTP DB
- PostgreSQLまたはMySQLと互換
- ストレージが自動スケール
- 高可用性
用途:
- 高性能が必要なトランザクション処理
- 高可用性が求められるシステム
- RDSからの移行
スケーラビリティ:
- 垂直スケール: 1プライマリインスタンス変更（例: t3.medium → r5.2xlarge）
- 水平スケール: リードレプリカ（読み取り専用コピー、最大15台、自動フェイルオーバー）
- Aurora Serverless: 自動スケール（最小〜最大ACUを設定）
コスト:
- RDSより高いが、パフォーマンスが良い
- I/O課金が発生する場合がある
S3 + Athena
特徴:
- サーバーレスクエリエンジン
- S3上のデータに対してSQLを実行
- 読み込み時にスキーマを適用するスキーマオンリード
用途:
- データレイク上でのアドホッククエリ
- 探索的分析
- 月次レポートなどの軽量な分析
スケーラビリティ:
- 自動スケール
- データ量は無制限（ただし、コストと性能は設計に依存）
コスト:
- スキャンしたデータ量で課金（$5 / TB）
- パーティショニングで必要なデータのみスキャン
Athena使うときの注意:
- パーティション切らないと全データスキャンされてコストが爆発してしまう
-
WHERE dt = '2026-02-01'みたいにパーティションキーで絞り込む必要あり
Redshift
特徴:
- AWSマネージドなデータウェアハウス
- 列指向ストレージ
- MPP (Massively Parallel Processing) アーキテクチャ
用途:
- データウェアハウス
- 大量データの集計
- 定期的なBIレポート
スケーラビリティ:
- 水平スケール: ノードを追加（例: 2ノード → 4ノード → 8ノード）
- 垂直スケール: ノードタイプの変更（例: dc2 (SSD), ra3 (マネージドストレージ)）
コスト:
- ノード数 × ノードタイプ × 稼働時間
- リザーブドインスタンスで最大75%割引
- 使わない時間帯は停止しコストを抑える
Redshift使うときの注意:
- DISTKEY と SORTKEY の設定がパフォーマンスに直結します
- JOINで使うカラムをDISTKEYに、WHEREで絞り込むカラムをSORTKEYに設定する
- Aurora/RDS由来データの継続同期は Zero-ETL integration も検討する
RDSからRedshiftへのデータロード:
要件に応じて、主に以下の方法があります。
- 一括ロード: S3に出力してRedshiftのCOPYコマンドで取り込む
- 複雑な変換が必要な場合: AWS Glueで加工してS3に出力し、COPYで取り込む
- 継続同期（Aurora/RDS → RedshiftをAWS内でシンプルに連携）: Zero-ETL integrationを検討する
- 継続レプリケーション（CDC）の細かな制御、異種DB間移行、S3中継など柔軟な連携が必要な場合: AWS DMSを利用する
- 直接JDBC接続: 小規模・一時的な用途で利用する
- AWS Data Pipeline: 既存環境で見かけることはあるが、新規構築ではGlue + Step Functions / EventBridge なども選択肢になる
データベースの選定
データベースを選定する際は、データ量だけでなく、コスト、運用負荷、クラウド戦略、既存インフラとの統合性など、複数の観点から総合的に判断する必要があります。以下の比較表を参考にしてください。
データベース比較表
| 観点 | RDS | Aurora | S3 + Athena | Redshift |
|---|---|---|---|---|
| カテゴリ | トランザクションDB | トランザクションDB | クエリエンジン | データウェアハウス |
| 用途 | OLTP（トランザクション処理） | OLTP（トランザクション処理） | OLAP（アドホック分析） | OLAP（データウェアハウス） |
| クエリ頻度 | 高頻度（秒単位） | 高頻度（秒単位） | 低〜中頻度（月次・週次レポート） | 中〜高頻度（日次バッチ、BIツール） |
| コスト | 中（インスタンス課金） | 中〜高（インスタンス + I/O課金） | 低（スキャン量に応じた従量課金） | 高（ノード課金、リザーブドで割引可） |
| 運用負荷 | 中（パッチ適用、バックアップ自動化） | 低（自動フェイルオーバー、ストレージ自動スケール） | 扱うデータの量、形式によって変動(シンプルな構成、PoC向け) | 中〜高（ノード管理、DISTKEY/SORTKEY設計） |
| パフォーマンス要件 | 低レイテンシ（ミリ秒単位） | 低レイテンシ（ミリ秒単位）、高可用性 | 中〜高レイテンシ（秒単位、パーティション設計に依存） | 中レイテンシ（秒単位）、大量データ集計に最適 |
| スケーラビリティ | 垂直スケール + リードレプリカ | 垂直 + 水平スケール、Aurora Serverless | 自動スケール | 水平スケール（ノード追加） |
| AWSエコシステム統合 | ネイティブ統合 | ネイティブ統合 | ネイティブ統合（S3、Glue、IAM） | ネイティブ統合（S3、Glue、Lambda、IAM） |
| 適用ユースケース | Webアプリケーション、業務システム | 高性能が必要なWebアプリ、高可用性システム | 探索的分析、月次レポート、ログ分析 | AWSで完結するDWH、日次レポート、BI分析 |
選定フロー
データベースの選定は、以下の観点で判断します：
上記フローチャートに加えて、以下の観点も判断材料になります:
コスト優先の場合:
- 初期コストを抑えたい → S3 + Athena（従量課金）
- 安定したコストにしたい → Redshift（リザーブドインスタンス活用）
運用負荷を最小化したい場合:
- サーバーレスが良い → S3 + Athena
- マネージドで運用したい → Aurora、Redshift
チームのスキルセット:
- AWSに精通している → Redshift
- SQLで分析したい → Snowflake
- Spark + 機械学習を活用したい → Databricks
データレイク vs データウェアハウス vs データマート の詳細比較
データ基盤を設計する際、これら3つの概念を正しく理解し、使い分けることが重要です！
詳細比較表
| 項目 | データレイク | データウェアハウス | データマート |
|---|---|---|---|
| データ形式 | 生データ、非構造化データも可 | 構造化データ、スキーマ定義済み | 要約されたリレーショナルデータ |
| スキーマ | 読み込み時に定義 | 書き込み時に定義 | 事前定義済み |
| 目的 | 多様なデータを蓄積し再利用可能にする | 共通定義に基づく組織横断分析を可能にする | 特定部門・業務の分析要件に最適化する |
| 提供範囲 | 全社横断の原本保管領域（多用途で再利用） | 全社共通定義で統合された分析基盤 | 部門・ドメイン単位で提供する分析領域 |
| ユーザー | データエンジニア、データサイエンティスト | ビジネスアナリスト | 特定チーム |
| 分析用途 | 機械学習、探索的分析 | BIレポート、ダッシュボード | 要約分析、部門レポート |
| 処理方式 | ELT | ETL | ウェアハウスからフィルタリング |
| データ品質 | 品質チェック不十分の可能性 | 高品質保証 | 高品質 |
| 代表例 | Amazon S3 | Redshift | 部門別Redshiftスキーマ |
| コスト | 低 | 中〜高 | 低〜中 |
データレイクの詳細
特徴:
- あらゆる形式のデータを保存できる：CSV, JSON, Parquet, Avro, ログファイル、画像、動画など
- スキーマを後で定義できる柔軟性がある
- 低コストで大量データを保存可能
AWS実装例:
- S3: オブジェクトストレージ
- AWS Glue Data Catalog: メタデータ管理
- Athena: アドホッククエリ
データウェアハウスの詳細
特徴:
- 構造化されたデータのみ
- 分析用に最適化されたスキーマ（例: スタースキーマ）
- 高速なクエリパフォーマンス
AWS実装例:
- Redshift: データウェアハウス
データマートの詳細
特徴:
- データウェアハウスのサブセット
- 特定の部門やプロジェクトに特化
- 小規模で管理しやすい
AWS実装例:
- Redshiftのスキーマ分離
参考リンク
- RDS vs Aurora どっち使う？
- データベース基礎：行ベース（行指向）と列ベース（列指向 / カラム型）の違いを整理する
- Amazon Athenaの使い方まとめ
- OLAP vs OLTP の違い
- データウェアハウス vs データレイク vs データマート
- S3+Athena構成の弊社データ基盤の限界が近い
5. 学習してみて感じたこと
DBの違い
今回データ基盤について学習してみて感じたのは、データの使い方が根本的に違うということです。そして、その違いを技術的に実現しているのが「行指向ストレージ」と「列指向ストレージ」の違いでした。
Webアプリケーションのインフラ（OLTP）:
- RDSを使って1レコード全体を更新・挿入することがメイン
- リアルタイム性が求められる（ミリ秒単位）
- 「行全体を高速に読み書きする」という設計思想
- 行指向ストレージ（RDS, Aurora）: 1レコード全体を読み書きするのに最適
データ基盤（OLAP）:
- 属性ごとに統計を取って分析することがメイン
- バッチ処理が中心
- 「列ごとにデータを集計する」という発想
- 列指向ストレージ（Redshift など）: 特定のカラムだけを集計するのに最適
これまでだと「1レコード全体の更新や挿入」がメインだったので、列ごとに最適化するという発想がありませんでした。しかし、データ分析では「全顧客の購入金額の合計」のように、特定の列だけを大量に読み込むクエリが中心になります。
# 例
Webアプリ: SELECT * FROM users WHERE id = 1;
→ 1人のユーザー情報を取得
データ分析: SELECT region, SUM(amount) FROM sales GROUP BY region;
→ 全レコードの region と amount だけを読み込んで集計
同じDBでも、使われ方が違うと大きく構成が変わるというのが最大の発見でした。この設計思想の違いが理解できたことで、データ基盤の全体像が腹落ちしました。
苦労したポイントと気づき
bronze/silver/goldの境界が曖昧だが、本質は「段階的な加工」
データレイクのレイヤー分け（bronze/silver/gold）について学習しましたが、最初は「どこまでがbronze、どこからがsilver」という明確な基準がないことに戸惑いました。
- bronze: ここは比較的明確
- silver: 型変換だけで十分なのか？どこまで業務的に整えるべきか？
- gold: "ビジネスロジックを適用"とあるけど具体的には？
しかし、勉強していく中で気づいたのは、大事なのは「3層に分ける」ことではなく、「段階的にデータを加工する」という考え方だということです。
実際、プロジェクトによっては：
- シンプルに
raw/processedの2層構成 - 細かく
raw/cleaned/enriched/martの4層構成
など、レイヤー数も定義も変わります。重要なのは以下の点：
- 生データを保持する（監査・検証のため変更不可で保存）
- 段階的に加工する（エラー時のデバッグや再利用がしやすい）
- 最終的に分析用データを作る（BIツールやMLモデルで使える形）
補足ですが、4層以上の設計は「3層では足りない」というより、ある層を事細かく分けているだけ、と捉えると理解しやすいと教わりました。
bronze/silver/goldという3層の役割分担で考えると整理しやすく、途中で変換処理を1つ挟んだからといって、必ずしも別の新しい層が増えるわけではありません。
レイヤー数の多寡よりも、各層の責務が明確かどうかが重要だと感じました。
レイヤー分けに唯一の正解はありませんが、bronze/silver/gold の責務分離を軸に設計すると整理しやすいと感じました。そのうえで、要件に応じて各層を詳細化していけば、自分のプロジェクトにも適用できると考えています。
ETLが複数箇所で必要という意外性
ETL処理について調べていく中で、ETLがデータパイプラインの複数箇所で必要になることに驚きました。
- データソース → データレイク（bronze）: 各種データソースからS3にデータを投入する際のETL
- bronze → silver → gold: データレイク内での段階的な変換のためのETL
特に大規模プロジェクトでは、一度S3を介してデータを保存し、さらに別のDBにロードするという"DB2個でやっていくイメージ"が意外でした。Webアプリでは RDS1つで完結することが多いため、この多段階構成は新鮮でした。
これから取り組む際に気をつけたいこと
1. まずは概念の理解から始めたい
データ基盤を学習する中で、最初に躓きやすいと感じたのが「概念の理解」でした。
- OLTP vs OLAP: トランザクション処理と分析処理の違い
- データレイク vs データウェアハウス: 生データと構造化データの違い
これまでやってこなかったリソースが多いので、改めて勉強が必要だと感じました。Webアプリのインフラ経験があっても、データ基盤は別領域として学び直す必要がありそうです。
しかし、これらの基本概念を理解しておくと、各ツール（Athena、Redshift など）をどう使っていけば良いのか理解しやすくなりました。
2. コスト監視は最初から設定したい
データ基盤は、Webアプリのインフラとはコスト構造が異なります。
- Webアプリ: インスタンスの稼働時間で課金
- データ基盤: データのスキャン量、DPU時間、ノード数で課金
特にAthenaは、パーティションを切らずに全データスキャンすると想定外のコストが発生します。ケアレスミスでコストが爆増しないためにも最初からAWS Cost Explorerでアラートを設定しておくのが大事だと感じました。
3. 実際に手を動かして試したい
データ基盤は、やってみないと理解が難しいと感じました。
- ドキュメントを読むだけでは分からないことが多い
- 実際にAthenaでクエリを投げてみる、Glue ETLジョブを動かしてみる、という経験が重要
- PoC（概念実証）や小規模な検証環境で試してから本番構成を決めるのが良さそう
簡単に実践した方が理解が深まります。AWSの無料枠を使って試すのも良いと思います。
自分もやってみます！
4. 選択肢の多さに惑わされないようにしたい
データ基盤には多くのツールがあり、最初は「どれを選べばいいのか」迷います。
- AWSのツールのみで完結もできる（例: Lambda + S3 + Athena + Redshift + Glue）
- 構成の多くをカバーしてくれるSnowflake/Databricksなどの専用ツールもある
一度概念を理解していれば、どのツールを使っても基本は同じです。自分のプロジェクトの要件（データ量、リアルタイム性、予算、社内のスキルセット）に合わせて選ぶのがポイントですね。
5. ネット上の情報を積極的に活用したい
データエンジニアリングは近年注目されている分野なので、大量の記事があります。
- AWS公式ドキュメント
- Snowflake/Databricksの公式チュートリアル
- Qiita、Zenn、個人ブログ
同じような悩みを持った人の記事を探すと、解決策が見つかることが多いです。実際に今回の学習でも、多くの先人の記事に助けられました。
6. まとめ
この記事では、インフラエンジニアがデータ基盤を構築する際の基礎知識を学びました。
本記事で学んだこと
- データ基盤の全体像: OLTP と OLAP、データレイク と データウェアハウス
- インフラ構成パターン: 小規模（Lambda + S3 + Athena）、AWS完結型（Glue + Redshift + dbt）、SaaS型（Kinesis + Databricks/Snowflake）
- データベース選定: RDS、Aurora、Athena、Redshift の特徴と使い分け
- 行指向vs列指向ストレージ: データ量とクエリパターンに応じた選択基準
次回:【設計・ツール選定編】
次回は、データモデリングの詳細とツール選定を解説します：
- データモデリング詳説: スタースキーマ、ファクトテーブル、ディメンションテーブル
- ETL/ELT実装: AWS Glue、Lambda、Step Functions、dbt
- Snowflake と Databricks: アーキテクチャ比較と選定基準
Discussion