データウェアハウスとは何ですか？ データウェアハウスは、複数のソースシステムからの現在のデータと履歴データを保存する一元化されたシステムです。トランザクションワークロードの処理ではなく、クエリ、分析、レポート作成向けに最適化されています。さまざまなソースからの構造化データと履歴データを集約および統合し、ビジネスインテリジェンスと意思決定をサポートします。
データウェアハウスは通常、クレンジング、変換され、一貫したデータモデルに整理された構造化データおよび半構造化データを保存します。これにより、整理された高品質なデータを提供することで効率的なデータ分析が可能になり、ビジネスユーザー、データアナリスト、データサイエンティストがデータを分析し、傾向を特定して意思決定をサポートすることが容易になります。
オペレーショナルデータベースは、業務システム（注文処理など、日々の業務活動をサポートするアプリケーションやサービス）によって生成されたデータを保存・管理し、大量のデータに対するパフォーマンス、アグリゲーション、複雑な分析クエリに合わせて最適化されています。
データウェアハウスの簡単な歴史
データウェアハウスの概念は、オペレーションシステムと分析ニーズの間で拡大する乖離に対処するために登場しました。
1980年代から1990年代初頭にかけて、組織はレポートを作成するために運用データベースに大きく依存していました。データ量の増加に伴い、分析クエリによってトランザクションシステムの処理速度が低下し、メトリクスの不整合が生じるようになりました。この隔たりを埋めるため、初期のアーキテクチャでは、レポート作成を日常業務から分離するステージング環境レイヤーと運用データストアが導入されました。
現代のデータウェアハウスは、1990年代初頭にビル・インモンの研究によって形作られました。彼はデータウェアハウスを、意思決定支援のために設計された集中型で主題指向のシステムと定義しました。同じ頃、ラルフ・キンボールは、分析クエリとビジネスインテリジェンス向けにデータ構造を最適化するディメンショナルモデリングを普及させました。
2000年代には、エンタープライズデータウェアハウスやデータマート（データウェアハウスの小規模でドメイン固有のサブセット）が一般的になりましたが、通常はオンプレミスにデプロイされ、多額の初期投資が必要でした。 2000年代後半におけるビッグデータの台頭によりデータレイクが登場し、ストレージの柔軟性が向上したものの、データウェアハウスに取って代わることはありませんでした。
2010年代におけるクラウドインフラストラクチャへの移行は、ストレージとコンピュートを分離することでデータウェアハウジングを変革し、柔軟な拡張とマネージドサービスを可能にしました。現在、データウェアハウスはより広範なデータエコシステムの一部として機能し、トランザクションデータベース、データレイク、アナリティクスプラットフォームと連携して、パフォーマンス、柔軟性、ガバナンスのバランスを取っています。
データウェアハウスはどのような課題を解決しますか？
組織が成長するにつれて、データは運用システム間で断片化します。レポート作成ロジックが重複することが多く、メトリクスに不整合が生じ、分析クエリによってアプリケーションのパフォーマンスが低下する可能性があります。
データウェアハウスは、次のようにしてこれらの課題を解決するのに役立ちます。
複数のソースからのデータを単一のリポジトリに一元化
チーム間での定義とメトリクスの標準化
アナリティクスワークロードのクエリパフォーマンスの向上
トランザクションシステムから分析処理を分離
大規模なビジネスインテリジェンスとレポート作成のサポート
組織が部門や環境を横断してデータを効率的に管理できるように支援
データウェアハウスにおけるガバナンス管理は、機密レコードを一元管理し、データの出所と使用状況に関する監査証跡を提供することで、規制へのコンプライアンスを簡素化します。
その結果、アナリティクスの信頼性が向上し、ビジネスパフォーマンスをより明確に把握できるようになります。
データウェアハウス、データベース、データレイクの比較
データウェアハウス、データベース、データレイクは、最新のデータアーキテクチャにおいてそれぞれ異なる役割を果たします。
データベース は、運用ワークロードとアプリケーションロジックをサポートし、トランザクション処理用に最適化された、構造化された（多くの場合正規化された）形式でデータを保存するように設計されています。
データウェアハウス は、アナリティクス、レポート作成、BIをサポートし、高速なクエリと分析のために最適化されたディメンショナルモデルにデータを保存します。
データレイク は大量の未加工データを元の形式で保存し、組織が構造化形式と非構造化形式の両方でデータを保存して柔軟に分析できるようにします。
これらのシステムは、分離して使用されるのではなく、多くの場合組み合わせて使用されます。多くの組織は、柔軟性、パフォーマンス、ガバナンスのバランスを取るために、トランザクションデータベース、データレイク、データウェアハウスを組み合わせています。
より詳細な比較については、データレイクとデータウェアハウスに関するガイド
OLTP と OLAP の比較 - 違いを理解する
データウェアハウスがいつ必要になるかを理解するには、OLTP システムと OLAP システムを区別することが役立ちます。
OLTP（オンライントランザクション処理） システムは、運用ワークロードをサポートするように設計されています。これらのシステムは、ユーザーのサインアップ、購入、アップデート、アプリケーションのやり取りなど、頻繁に発生する小規模なトランザクションを取り扱います。
OLAP（オンライン分析処理） システムは、分析を目的として設計されています。数か月または数年にわたる過去のデータに及ぶことも多い大規模なデータセット全体で、複雑なクエリをサポートします。OLAPシステムは、多次元データを取り扱うために特別に構築されており、時間、ロケーション、製品などの複数のディメンションにまたがる高速で複雑なクエリを可能にします。さらに、OLAPシステムはビジネスインテリジェンスおよびデータ分析のための高度な分析機能を提供し、組織が洞察を導き出し、データ主導の意思決定を行えるようにします。
OLTP と OLAP の比較
注：トランザクションデータベースとデータウェアハウスは競合する技術ではありません。これらは、異なるワークロード向けに設計された補完的なシステムです。適切に設計されたアーキテクチャでは、OLTP システムと OLAP システムが連携して、運用効率と分析の洞察の両方をサポートします。
データウェアハウスはどのような場合に必要になりますか？
次のような場合は、データウェアハウスが必要になる可能性があります。
複数の運用システムからのデータを分析する
ビジネスユーザーが一貫した信頼できるメトリクスを必要とする
レポート作成クエリがアプリケーションのパフォーマンスに影響を与えている
現在の状態だけでなく、過去のトレンドを分析する必要がある
アプリケーションデータベースにおけるアナリティクスロジックの管理が困難になっている データガバナンスとアクセス制御の重要性が高まっている
主なワークロードにリアルタイムトランザクションやアプリケーションのデータアクセスが含まれる場合は、通常、OLTP データベースが最適な選択肢となります。アナリティクスやレポート作成がビジネスの中核を担うようになると、データウェアハウスの価値が高まります。
データウェアハウスのアーキテクチャとレイヤー
データウェアハウスは通常、レイヤー化されたアーキテクチャとして設計され、各レイヤーが特定のレンジのデータ処理を担当します。この分離により、チームは関心を分離し、パフォーマンスを向上させ、システムの一部を個別に進化させることができます。実装は組織によって異なりますが、ほとんどのデータウェアハウスシステムはレイヤー化されたアプローチを採用しており、アナリティクスやパフォーマンスのために利用可能にする前に、運用ソースから変換およびストレージレイヤーを経由してデータを移動させます。
ソースシステム
ソースシステムには、運用データベース、SaaSアプリケーション、ログファイル、外部データソースが含まれます。これらのシステムは、ウェアハウスに流れ込む生データを生成し、通常、日常業務における信頼できる情報源として機能します。
ステージングと取り込み
データはステージング環境に取り込まれ、そこで検証、クレンジング、変換の準備が行われます。このレイヤーは、ソースシステムとウェアハウスの間のバッファとして機能し、本番システムに影響を与えることなく、必要に応じてデータの検査、整理、再処理を行うことができます。
変換とモデリング
このレイヤーでは、データを一貫した形式に変換し、分析データモデルとして整理します。ここでは、ビジネスロジック、アグリゲーション、標準定義が適用されます。
ストレージ階層
データは多くの場合、アクセスパターンに基づいて複数の階層に保存されます。頻繁にアクセスされるデータはより高速なストレージに配置される一方で、古い履歴データはよりコスト効率の高い方法で保存される場合があります。さらに、レポート作成や意思決定を容易にするために、詳細なトランザクションデータから導き出された集計情報であるサマリーデータが、データウェアハウス内で未加工データとともに保存されることがよくあります。
アナリティクスと BI ツール
ビジネスインテリジェンスツール、アナリティクスプラットフォーム、機械学習ワークフローは、データウェアハウスに対してクエリを実行し、洞察、ダッシュボード、レポートを生成します。これらのツールは、データウェアハウスの分析機能を活用して、ビジネスインテリジェンスと高度な分析をサポートします。
データウェアハウスのユースケース
データウェアハウスは、汎用的なデータシステムではありません。分析ワークロード向けに意図的に最適化されており、その最適化にはトレードオフが伴うため、トランザクションのユースケースには適していません。
データウェアハウスは、多次元にわたる大量の履歴データをサポートするように設計されています。データは通常、取り込まれ、変換され、読み取りパフォーマンス、アグリゲーション、高速かつ効率的な分析クエリを重視した分析モデルに整理されます。ただし、データは常にアップデートされるわけではなく、高頻度の書き込みや低レイテンシのトランザクション向けに最適化されているわけでもありません。
一方、トランザクションシステムは、大量の小規模なリアルタイム操作を処理するように設計されています。これらは、アプリケーションワークフローにおいて、即時の整合性、高速な挿入とアップデート、予測可能な応答時間を優先します。
最適なユースケース
ビジネスインテリジェンスとレポート作成
エグゼクティブダッシュボードと主要業績評価指標（KPI）
トレンド分析と予測
過去のパフォーマンス分析
データマイニングとアナリティクスのワークロード トランザクション分析およびレポート作成のための POS システムからのデータ統合
これらの目的で使用される場合、データウェアハウスは重要な意思決定支援システムとなります。
不向きなユースケース
データウェアハウスは、即時の整合性、低レイテンシのレスポンス、またはアプリケーション開発に伴う頻繁なスキーマ変更を必要とするワークロードには適していません。
不向きなユースケースには以下が含まれます：
大量のトランザクションワークロード
低レイテンシのアプリケーションクエリ
リアルタイムの運用アップデート 計画的なモデリングを行わずに急速に変化するスキーマ
データウェアハウスは、本質的に高額でも複雑でもありません。 トランザクションシステムのように動作することを求められると、不要なレイテンシ、運用リスク、アーキテクチャの複雑さを招き、コストが高くなります。
データウェアハウスの限界
データウェアハウスには以下のような特性があります。
高コスト： 大量の履歴データの保存、計算負荷の高い分析クエリの実行、取り込み・変換・ガバナンスのためのパイプラインの維持が必要になることがよくあります。データと使用量の増加に伴い、継続的なインフラストラクチャおよび運用のニーズによってコストが増大します。
複雑： データウェアハウスの構築と運用には、データモデリング、取り込み、変換、アクセスマネジメントなど、複数のレイヤーのマネージメントが伴います。チームは一貫したメトリクスを定義し、スキーマの変更を管理し、データ品質を維持しますが、これには通常、専門的なスキルと多大な連携が必要となります。
時間がかかる： データのロードと変換のプロセスは、特に大量のデータを扱う場合に時間がかかることがあります。
柔軟性の低さ： データウェアハウスの構造は通常固定されているため、変化するビジネス要件に適応することが困難になる場合があります。
制限： データウェアハウスはレポート作成や分析に最適化されているため、他の種類のデータ処理タスクにおける有用性が制限される可能性があります。
データウェアハウスがMongoDBと連携する仕組み
データウェアハウスは、トランザクションデータベースを置き換えるのではなく、一般的にこれと組み合わせて使用されます。
一般的なアーキテクチャでは、MongoDB などの OLTP データベースが、アプリケーションで使用される運用データを保存します。その後、そのデータはデータウェアハウスに複製またはストリーミング配信され、アプリケーションのパフォーマンスに影響を与えることなく変換および分析できます。
このアプローチにより、各システムはそれぞれの得意分野に集中することができます。
トランザクションデータベースは高速で信頼性の高い操作をサポート
データウェアハウスはアナリティクスとビジネスインテリジェンスをサポート
最新のアーキテクチャでは、レイクハウスやコネクタベースのアプローチが採用されるケースが増えており、システム同士を結合することなく、運用データをアナリティクスプラットフォームに移動、同期、公開するための構造化された手法を提供します。これらのパスワードなしでは、コネクタが運用データベースからアナリティクス環境にデータをストリーミング配信または複製する一方で、レイクハウスプラットフォームはウェアハウススタイルのアナリティクスとデータレイクストレージを組み合わせます。
たとえば、MongoDB と Databricks などのプラットフォームとの連携により、OLTP パフォーマンスを維持しながら、OLAP システムを使用して運用データを分析することが可能になります。
2つのシステムがどのように連携して動作するか
一般的なアーキテクチャは次のパターンに従います。
アプリケーションは運用データを MongoDB に書き込みます
データはデータウェアハウスに複製、ストリーミング配信、またはバッチロードされます
データウェアハウスはアナリティクス用にデータを変換およびモデリング
BI ツールやアナリストはアプリケーションデータベースとは別のシステムであるウェアハウスに対してクエリを実行
このアーキテクチャでは、アプリケーションは運用データベースとのみやり取りし、分析ワークロードはすべてデータウェアハウスに対して実行されます。この分離により、分析クエリがトランザクションワークロードと競合することがなくなり、各システムが独立して効率的に動作できるようになります。MongoDB は高速で信頼性の高いトランザクションをサポートし、データウェアハウスは大規模なデータセットに対する複雑な分析クエリをサポートします。
このアプローチが重要な理由
MongoDB とデータウェアハウスを併用することで、組織は次のことが可能になります。
運用データベースで負荷の高い分析クエリを実行することを回避
アナリティクスの利用が増加してもアプリケーションのパフォーマンスを維持
チーム間で一貫したメトリクスを維持 アプリケーションスキーマを複雑にすることなく過去の傾向を分析
MongoDB は運用ワークロードに最適化されています。大量のトランザクション、柔軟なスキーマ、そして稼働中のアプリケーションをサポートする低レイテンシの読み取りと書き込みの処理に優れています。これに対してデータウェアハウスは、分析ワークロードに最適化されています。多数のディメンションにわたる大量の履歴データをスキャンして集計するように設計されており、多くの場合、オペレーショナルデータベースでは非効率で悪影響を及ぼすような計算負荷の高いクエリが使用されます。
これらの関心を分離することで、組織は運用データに対する負荷の高い分析クエリの実行を回避し、アナリティクスの利用が増加してもアプリケーションのパフォーマンスを維持し、チーム間でコンシステントで共有されたメトリクスを維持することができます。
このアーキテクチャでは、MongoDB が現在の運用データに対するプライマリレコードシステムとして機能する一方、データウェアハウスはレポート作成、傾向分析、長期的な洞察に特化して構築された派生分析システムとして機能します。
最新の統合パターン
多くの組織がコネクタやレイクハウススタイルのアーキテクチャを使用して、運用データと分析データを統合しています。たとえば、MongoDB と Databricks などのプラットフォームの統合により、組織はトランザクションワークロードを分離したまま、OLAP システムを使用して運用データを分析できます。
これらのパターンは、単一のシステムに互換性のないワークロードを処理させることなく、アナリティクス、機械学習、レポート作成のユースケースをサポートします。
データウェアハウスを導入するタイミング
需要が低い場合、MongoDB は運用ワークロードと並行して基本的なアナリティクスをサポートできます。シンプルなレポート作成やアプリケーションレベルの洞察に適したアグリゲーション機能と柔軟なスキーマを提供します。
しかし、レポート作成が複雑化し、データ量が増加し、あるいは履歴分析が不可欠になるにつれて、こうしたアクセスパターンは運用データベースに対して競合する要求をもたらすようになります。MongoDB が運用データの記録系システムとして機能し続ける一方で、分析ワークロードを独立してスケールできるようにすることが、現実的な次のステップとなります。
データウェアハウスの制限とトレードオフ
データウェアハウスは強力ですが、限界もあります。
具体的には以下のようなものがあります。
高価
適切なデータモデリングを行わないと設計が複雑になります
入力と保守に時間がかかる 柔軟性が低い
データウェアハウスが適切なソリューションであるかどうかを判断する際には、これらのトレードオフを理解することが不可欠です。
データウェアハウス階層とは？
データウェアハウスは多くの場合、データの処理、保存、アクセスの方法に基づいて階層に編成されます。これらの階層は、関心を分離し、パフォーマンスを向上させ、コストを抑制するのに役立ちます。
一般的なデータウェアハウスの階層
最下位階層：データの取り込みとストレージ
この階層には、ソースシステム、取り込みパイプライン、未加工ストレージが含まれます。データは業務システム、アプリケーション、外部ソースから収集され、ウェアハウス環境にロードされます。未加工のデータや軽度に処理されたデータは、再処理や監査のために保持される場合があります。
中間階層：変換とモデリング
中間階層では、アナリティクス向けにデータがクレンジング、変換、モデル化されます。ビジネスルールが適用され、データ品質チェックが実施され、分析スキーマが作成されます。この階層は、一貫した信頼できるメトリクスを生成するために不可欠です。
最上位階層：アナリティクスと消費
最上位階層には、BI ツール、ダッシュボード、アナリティクス プラットフォーム、機械学習ワークフローが含まれます。ビジネスユーザー、アナリスト、データサイエンティストはこのレイヤーでデータを操作し、トレンドの探索、レポートの作成、意思決定のサポートを行います。
これらの階層を分離することで、組織は運用システムを保護し、ストレージとコンピュートのコストを管理しながら、アナリティクスを増やすことができます。
一般的なデータウェアハウスのバリエーションにはどのようなものがありますか？
すべてのデータウェアハウスが同じように構築されているわけではありません。従来のオンプレミスデータウェアハウスは、ガバナンスやセキュリティの向上、データ主権、レイテンシの低減といったメリットを提供するハードウェアベースのストレージソリューションですが、管理が複雑になる場合があります。最新のデータウェアハウジングは、これらのオンプレミスシステムを超えて進化し、クラウドネイティブやハイブリッドのアーキテクチャをサポートしています。
2025年までに、多くの最新のデータウェアハウスはレイクハウスとしても機能するようになり、AIや機械学習のワークロード向けに、ガバナンスと構造をデータレイクの柔軟なストレージと融合させます。
一般的なデータウェアハウスのバリエーション
エンタープライズデータウェアハウス（EDW）
エンタープライズデータウェアハウスは、組織全体の一元化されたアナリティクスプラットフォームとして機能します。部門横断でデータを統合し、レポート作成やビジネスインテリジェンスのための信頼できる唯一の情報源を提供します。
データマート
データマートは、データウェアハウスのより小規模で、特定の主題に特化したサブセットです。これらは多くの場合、財務、マーケティング、営業アナリティクスなど、特定のチームやユースケース向けに設計されています。
従来のデータウェアハウス
従来のデータウェアハウスは通常、オンプレミスにデプロイされ、多額の初期インフラ投資を必要とします。 これらは固定スキーマと長い開発サイクルに依存しています。
クラウドデータウェアハウス
クラウドデータウェアハウスは、ストレージとコンピュートを分離するフルマネージドサービスです。弾力的な拡張、より迅速な設定、従量課金制の価格設定を提供し、多くの現代の組織にとってデフォルトの選択肢となっています。
モダンデータウェアハウス
最新のデータウェアハウスは、柔軟性、データレイクとの統合、高度なアナリティクスおよび機械学習ワークロードのサポートを重視しています。これらは、運用データベースを置き換えるのではなく、連携して動作するように設計されています。
適切なバリエーションの選択は、データ量、レイテンシ要件、ガバナンスのニーズ、組織の成熟度によって異なります。
データウェアハウスは他のデータシステムとどのように比較されますか？
データウェアハウスと他のデータシステムの違いを理解することは、それが適切なソリューションである場合とそうでない場合を明確にするのに役立ちます。
データウェアハウスとデータレイクの比較
データウェアハウスとデータマートの比較
データウェアハウスが適しているケース
データウェアハウスは、アナリティクス、レポート作成、意思決定向けに設計された専用システムです。複数のソースからのデータを一元化し、一貫したビジネスロジックを応用して、大規模な複雑な分析クエリをサポートします。データウェアハウスは分析アクセスパターン向けに最適化されており、効果的な AI および機械学習アプリケーションに不可欠です。さまざまな AI および機械学習ワークフローをサポートできるクリーンで信頼性の高いデータを提供し、ビジネスインテリジェンスや高度なアナリティクスに必要な分析機能を強化します。
これはトランザクションデータベースの代替ではありません。最も効果的なデータアーキテクチャは、OLTP システムと OLAP システムを組み合わせることで、それぞれが本来の目的を果たせるようにします。
正しく使えば、データウェアハウスはビジネスインテリジェンスとデータアナリティクスの信頼できる基盤となります。誤って使用すると、不要なコストと複雑さをもたらします。