データウェアハウス（DWH） をはじめとするデータ基盤は、広い意味では「分析のための大規模なデータベース」と捉えられます。
ただし実際の分析基盤は、単なるデータベースそのものではなく、データを蓄積し、整備し、利用可能な形で提供するまでの仕組み全体として設計されます。
そしてこの10〜20年で、扱うデータの量と多様性（ログ、半構造化データ、画像・音声など）が拡大し、コスト構造や運用形態も変わったことで、分析基盤の設計思想や構成の前提は大きく変化してきました。
本記事では、オンプレミス時代の統合型DWHを起点に、クラウド化を経て現在に至るまでの流れを、変化の背景とあわせて整理します。
◆ 全体像
| 項目 | オンプレミス時代 (1990s-2000s) | クラウド移行期 (2010s) | 現代 (2020s-) |
|---|---|---|---|
| 代表例（概念） | 統合型DWH（専用機・統合製品群） 例：Teradata, Oracle Exadata |
クラウドDWH（マネージド化） 例：Amazon Redshift, BigQuery |
クラウドDWHの成熟＋レイクハウス 例：Snowflake, Databricks |
| 拡張性 | 物理増設が前提（計画的な増強） | コンピュート/ストレージの一体拡張、需要に応じたスケールが可能 | 分離型、ワークロード単位で拡張しやすい |
| データ形式 | 構造化データ（RDB）中心 | 非構造化データも収集開始 | 構造化〜非構造化を含む統合活用が進展 |
| 処理手法 | ETL（TransformしてからLoad） | ELT（LoadしてからTransform） | 分散処理・サーバーレス |
| コスト | 高額な初期投資（CAPEX） | 従量課金（OPEX） | 設計次第でコスト差が出やすい |
1. オンプレミス時代：統合型アーキテクチャ
オンプレミス時代のDWHは、ストレージ、計算資源、データ管理、性能最適化の仕組みが、ひとつの製品（または強く統合された製品群）として提供されるのが一般的でした。
オンプレDWHの典型的な特徴
- ストレージと計算（CPU）がセット：増強する場合は機器やノード単位での増設が前提
- データは基本“DWH内に入れてから”分析：外部ストレージに置いたまま分析する前提は薄い
- ETLが強い：DWHに入れるために前処理・整形が必須
- 性能最適化が重要：インデックス、パーティション、集計、チューニングの比重が大きい
なぜ「統合型」が合理的だったのか
当時は
- ストレージが高い
- ネットワーク転送も高い/遅い
- 分散処理が一般的ではない
- 管理を単一製品に寄せた方が運用しやすい
という制約が強く、機能を単一基盤に集約し、限られたリソースを前提に最適化することが、現実的な選択でした。
2. 変化の起点：データ量・多様性の拡大
2000年代後半〜2010年代にかけて、分析対象のデータが大きく変化します。
- ログ、クリック、IoTなどで データ量が爆発
- 構造化だけでなく 半構造化（JSON）/非構造（画像・音声） が増える
- 「とりあえず貯めて後で使う」ニーズが増える
この結果、「高価なDWHにすべてを格納する」アプローチはコスト面・運用面で限界が見え始め、安価に大量保存できるストレージを前提とした設計が求められるようになります。
3. クラウド移行期：マネージド化の進展
2010年代に入ると、DWHはオンプレミスの専用機／サーバー構築を前提とした形から、クラウド上で提供されるマネージドサービスへと重心が移っていきました。
これにより、導入・運用の負担を抑えながら、必要な規模から段階的に利用を拡大できるようになります。
クラウドDWHがもたらした変化
-
初期投資（CAPEX）の縮小
従来は、事前にハードウェアを見積もって導入し、数年単位で償却しながら運用するのが一般的でした。クラウドでは、必要な規模から始めて、利用状況に応じて増減できるため、導入ハードルが大きく下がりました。 -
マネージド化による運用負荷の軽減
パッチ適用、バックアップ、冗長化、障害対応などの多くがサービス側に吸収され、利用者はインフラ運用よりも、データ設計・活用に集中しやすくなります。
計算とストレージの分離：拡張の自由度が上がった
クラウドでは、データの保存先（ストレージ）と、クエリ実行に必要な計算リソース（コンピュート）を、より独立して扱えるようになりました。
これにより、データは長期に保持しつつ、必要なタイミングで処理能力を確保するといった運用が現実的になります。
4. 定着：ELTへのシフト
これまではDWHの容量が貴重だったため、入れる前に綺麗に掃除する「ETL」が必須でした。しかし、クラウドでは「とりあえず安価なストレージ（データレイク）に全部放り込み、必要な時にDWHのパワーで変換する」という**ELT（Extract, Load, Transform）**が主流になりました。
5. 現代：レイクハウスによる統合
2020年代に入り、DWHとデータレイクを明確に分けるだけでなく、両者を統合的に扱う方向性が強まっています。これがデータレイクハウスと呼ばれる概念です。
なぜ“統合”が求められたのか
従来の「DWHとレイクの使い分け」は分かりやすい一方で、次の課題が出やすくなります。
- 管理が二重化する（権限、カタログ、品質、運用手順）
- データ連携が増えるほど、鮮度や整合性の確保が難しくなる
現代の解決アプローチ
- レイク上のデータに対して、SQLで扱いやすくする仕組みが成熟
- レイク上でも“テーブルとしての管理”を成立させる技術（例：テーブルフォーマット）が普及し、更新・履歴管理・整合性確保を行いやすくなった
これにより、「安価に大量保存する柔軟性」と「分析基盤としての信頼性」を、より一体で扱えるようになってきています。
6. 具体的な進化の形：BigQueryとSnowflake
ここでは、現代のクラウドDWHを象徴する例として、設計思想の違いが分かりやすい2つの方向性を簡単に触れます。
- BigQuery：インフラ意識を減らすサーバーレス志向
BigQueryは、利用者がサーバー管理や構成を強く意識せずに分析を進められる、サーバーレス志向の代表例です。
オンプレミス時代のように「インデックス設計やリソース確保」を前提にするより、大規模並列処理を前提にスキャンして集計するアプローチを取りやすい点が特徴です（実務ではパーティションやクラスタリング等の最適化も重要です）。
- Snowflake：ワークロード分離で“競合”を避ける設計
Snowflakeは、ワークロードごとに計算資源を分けやすい設計により、処理の競合を抑えやすい点が特徴です。
オンプレミスで起きがちな「バッチ実行中は分析が遅い」といった問題に対し、用途別に計算リソースを分離して並行稼働させるというアプローチで対処しやすくなっています。
7. まとめ
DWHは一貫して「分析のための基盤」ですが、時代とともに前提条件が変わり、それに合わせて最適な構成も変化してきました。
- オンプレミス時代は、限られた高価な資源を前提に 統合型で最適化するのが合理的だった
- データ量・種類の増大により、「すべてをDWHに格納する」前提が揺らぎ、安価な蓄積が重要になった
- クラウド化により、導入・運用のハードルが下がり、マネージド前提の設計が一般化した
- その結果、ETLからELTへと処理スタイルが移行し、さらに近年は DWHとレイクを統合的に扱う方向性（レイクハウス）が強まっている
進化の流れを振り返ると、データの特性とコスト構造の変化に合わせて“現実的に運用できる形”へ最適化されてきたことが分かりました。