データウェアハウス（DWH）とは

データウェアハウスは、多くの場合、分析用にデータを変換するために設計された3層アーキテクチャーを採用しています。

• 最下層
• 中間層
• 最上層

複数のソース・システムからのデータはデータウェアハウス・サーバーに流れ込み、そこで保存されます。従来、このデータはETL（抽出、変換、ロード）データ統合プロセスを通じて移動し、オートメーションによってデータがクレンジングされ整理された後にウェアハウスにロードされます。

データウェアハウスは主に構造化データを保存するため、データの変換はロードの前に行われます。一部の最新のウェアハウスでは、代わりにELT（抽出、ロード、変換）プロセスが使用されています。この方式では、変換を行う前にデータをウェアハウスにロードします。この手法は、標準化された形式を必要とせず、非構造化データや半構造化データを保存できるデータレイクで一般的に使用されています。

この層には分析エンジンが含まれており、多くの場合オンライン分析処理（OLAP）システムによって強化されています。従来型のリレーショナル・データベース（多くのデータウェアハウスを含む）は、多次元データ（例えば、売上データには地域、時間、製品といった複数の次元がある）を保存できますが、多次元クエリーに最適化されているわけではありません。

OLAPシステムは、大量のデータに対して高速で複雑なクエリーや多次元分析を行うために設計されています。これらは「キューブ」（配列ベースの多次元データ構造）を使用し、複数の次元にわたる柔軟で迅速な分析を可能にします。一般的なユースケースには、データ・マイニング、財務分析、予算編成、需要予測などがあります。

OLAPとOLTPの違い：オンライン・トランザクション処理（OLTP）システムは、多数のユーザーからのリアルタイムのトランザクションを大量に取り込み、更新します。一方、OLAPシステムはすでに取り込まれたデータを分析します。

データウェアハウスで利用されるOLAPには3種類があります。

• 多次元OLAP（MOLAP）：多次元OLAPキューブを直接扱い、通常は最も高速かつ実用的な多次元データ分析の方式です。
  
  
• リレーショナルOLAP（ROLAP）：データをキューブに再構成せず、リレーショナル・テーブル内のデータを直接利用して多次元データ分析を行います。
  
  
• ハイブリッドOLAP（HOLAP）: 単一のOLAPアーキテクチャー内で、リレーショナル・データベースと多次元データベースの最適な役割分担を実現します。

データウェアハウスの最終層は、ビジネスデータのレポート、ダッシュボード、アドホック分析を行うためのフロントエンド・ユーザーインターフェースを提供します。これらのセルフサービス型BIツールにより、ユーザーは技術的なデータ・エンジニアリングの専門知識がなくても、過去のデータに基づいたレポートを作成し、トレンドを可視化し、ワークフローのボトルネックを特定できます。

データウェアハウスは大きく進化しており、オンプレミス専用のシステムから、柔軟なクラウドやハイブリッドモデルへと移行しています。

歴史的に、データウェアハウスは汎用ハードウェアを使用してオンプレミスでホストされていました。これらのシステムは、大規模並列処理（MPP）または対称型マルチプロセッシング（SMP）アーキテクチャーで構成され、スタンドアロン・アプライアンスとして提供されることもありました。こうしたデプロイメントには多大な投資が必要ですが、厳格なコンプライアンス、データ・セキュリティーやデータ・プライバシーの基準が求められる業界にとっては、有力な選択肢となる場合があります。

現在、多くのデータウェアハウスはクラウド上で稼働するように構築されています。これにより、ペタバイト規模のデータ・ストレージ、高い拡張性を持つコンピュートおよびストレージ、従量課金制の価格体系といったクラウド・コンピューティングのメリットを享受できます。クラウドベースのデータウェアハウスは、一般的にフルマネージドのSoftware-as-a-Service （SaaS）として提供されるため、ハードウェアやソフトウェアへの初期投資が不要です。また、このサービス提供モデルはインフラストラクチャー管理に必要なリソースを削減し、組織が分析や洞察に集中できるようにします。

クラウドベースのデータウェアハウスは、拡張性を活用しつつ、オンプレミスのデータセンターの設置面積やレガシー・インフラへの支出を削減したい組織の間で人気が高まっています。

一部の組織は、オンプレミスとクラウドのデータウェアハウス双方の利点を兼ね備えたハイブリッド・モデルを採用する場合もあります。このアプローチにより、クラウドの拡張性と柔軟性を活用しながら、オンプレミスに残す必要がある機密性の高いワークロードを制御することが可能になります。

データウェアハウスにおいては、スキーマがデータの構造を定義します。代表的なスキーマ構造には、スター・スキーマ、スノーフレーク・スキーマ、ギャラクシー・スキーマ（ファクト・コンステレーション・スキーマとも呼ばれる）の3種類があります。

これらのスキーマはすべて、OLAPシステムにおけるデータ検索速度を最適化するために設計された次元データモデルです。次元モデルは冗長性を高めることで、レポートや検索のための情報を見つけやすくし、クエリーのパフォーマンスを改善します。

これらのスキーマには、以下のように定義されるファクト・テーブルとディメンション・テーブルが含まれます。

• ファクト・テーブル：売上製品や収益額などの定量データを格納します
  
  
• ディメンション・テーブル：販売日や製品カテゴリなど、ファクトに関連するコンテキスト情報や記述情報を格納します

スター・スキーマは、中央に1つのファクト・テーブルがあり、その周囲をディメンション・テーブルが囲む構造です。図では、ファクト・テーブルが星形の中央に配置されます。スター・スキーマは最もシンプルで一般的なスキーマであり、高速なクエリー実行をユーザーに提供します。

スノーフレーク・スキーマは、中央のファクト・テーブルが多数の正規化されたディメンション・テーブルと接続され、それらのディメンション・テーブルがさらに多対1の関係を通じて他のディメンション・テーブルに接続される構造です。この複雑で分岐したパターンは雪の結晶のように見えることがあります。スノーフレーク・スキーマはデータの冗長性が低い一方で、クエリーパフォーマンスが低下するというトレードオフがあります。

銀河に多数の星が含まれているのと同じように、ギャラクシー・スキーマには多数のスター・スキーマが含まれ、それらは冗長性を回避するために正規化されたディメンション・テーブルを共有します。ギャラクシー・スキーマは非常に複雑なデータウェアハウスに最適ですが、ユーザーはパフォーマンスが低下する可能性があります。

典型的なデータウェアハウスのアーキテクチャーには、データを保存、管理、処理し、分析用に提供するために連携して機能する複数のコンポーネントが含まれます。

• ETL/ELTツール
• API層
• データ層（または中央データベース）
• メタデータ 
• サンドボックス
• アクセスツール

ETLツールはソース・システムからデータを抽出し、ステージング層で変換した後、データウェアハウスにロードします。ELTでは、データはウェアハウスにロードされた後に変換されます。Apache Sparkのようなデータ処理フレームワーク・ツールは、データ変換の管理に役立ちます。

アプリケーション・プログラミング・インターフェース（API）用の接続層は、データウェアハウスが運用システムからデータを取得して統合するのに役立ちます。APIはまた、可視化ツールや高度な分析ツールへのアクセスも提供します。

データ層（または中央データベース）は、データウェアハウスの中心です。ここでシステムは、ビジネス・アプリケーション、メールリスト、Webサイト、その他のデータベースなど、さまざまなソースからデータを統合・保存します。この層はETLまたはELTのデータ・パイプラインによって支えられており、リレーショナル・データベース管理システム（RDBMS）やクラウド・データウェアハウス・プラットフォームを使用します。組み込みのデータ・ガバナンスとセキュリティー機能によってデータを分割し、ユーザーは必要なものだけにアクセスできます。

メタデータは「データに関するデータ」であり、システムに保存されているデータを記述して検索や分析利用を可能にします。これには、テーブル構造やデータ型といった技術的メタデータや、作成者、作成日、ファイルサイズといった記述的メタデータが含まれます。メタデータは効果的なデータ・ガバナンスやデータ管理の鍵となります。

一部のデータウェアハウスはサンドボックスを提供します。これは、本番データのコピーと関連する分析ツールを含む隔離されたテスト環境です。データ・アナリストやデータサイエンティストは、サンドボックス内で新しい分析手法を試せるため、他のユーザーによるデータウェアハウスの運用に影響を与えることはありません。

アクセスツールはデータウェアハウスに接続し、ビジネスユーザーに使いやすいフロントエンドを提供します。ビジネス・ユーザーやデータ・アナリストは、ダッシュボード、アプリケーション、データ可視化ツールを使ってデータと対話し、洞察を引き出すことができます。これらのツールの例には、Tableau、Looker、Qlikなどがあります。

データ・ウェアハウスには主に次の3つのタイプがあります。

• エンタープライズ・データウェアハウス（EDW）
• オペレーショナル・データ・ストア（ODS）
• データ・マート

データ・ウェアハウスの種類は主に以下の３つがあります。

• クラウド・データ・ウェアハウス
• オンプレミスまたはライセンス形式のデータ・ウェアハウス
• データウェアハウス・アプライアンス

クラウドベースのデータウェアハウスは、クラウド上で動作するように構築されています。多くの場合、クラウド・データウェアハウスは、データウェアハウスのインフラストラクチャーがクラウド会社によって管理されているマネージド・データ・ストレージ・サービスとして組織に提供されます。組織は、ハードウェアやソフトウェアに先行投資する必要も、独自のシステムを管理する必要もありません。また、クラウド・サービスでは柔軟な料金体系が提供される場合がよくあります。

クラウド・コンピューティング・サービスを使用し、オンプレミスのデータセンターのフットプリントを削減しようとする組織が増えるにつれて、クラウドベースのデータウェアハウスの人気が高まっています。

運用データストア（ODS）は、運用データの最新スナップショットを保持します。ODSは頻繁に更新されるため、ほぼリアルタイムのデータに迅速にアクセスできます。組織は日々の運用上の意思決定やリアルタイム分析にODSを活用することが多いほか、EDWや他のデータシステムのデータソースとして利用する場合もあります。

データ・マートは、既存のデータウェアハウス（またはその他のデータ・ソース）のサブセットであり、企業全体ではなく特定の事業部門や部署に合わせてデータが調整されています。例えば、企業がマーケティング部門向けにデータ・マートを構築することで、そのユーザーは顧客セグメンテーションやキャンペーン成果に関する、より特化した洞察にアクセスでき、企業全体の広範なデータセットを参照する必要がなくなります。

データウェアハウス、データベース、データレイク、データレイクハウスという用語は同じ意味で使われることもありますが、重大な違いがあります。

データベースは主に自動化されたデータ取り込みと高速トランザクション処理のために構築されたファイリング・キャビネットのようなものです。通常は特定のアプリケーション専用のデータストアとして機能します。一方、データウェアハウスは、組織内のあらゆるアプリケーションからデータを保存し、予測分析やその他の高度な分析に最適化されています。

データレイクは、大量の生データを低コストで保存できるソリューションであり、あらかじめ定義されたスキーマを使用するのではなく、スキーマ・オン・リードのアプローチを採用します。データレイクには、構造化データ、非構造化データ、半構造化データ（ドキュメント、動画、IoTログ、SNSの投稿など）を保存できます。

データレイクは、ビッグデータプラットフォーム（Apache Hadoopなど）や、Amazon Simple Storage Service（Amazon S3）のようなクラウド・オブジェクト・ストレージ・サービス上に構築できます。データウェアハウスのように分析用にデータをクレンジング、検証、正規化することは通常ありません。

データレイクハウスは、データウェアハウスとデータレイクの側面を融合したものであり、レイクの低コストで柔軟な特性と、ウェアハウスの高性能を兼ね備えています。レイクとウェアハウスの主要な特長を1つのデータソリューションに統合することで、レイクハウスは大量の構造化データ、非構造化データ、リアルタイム・データ・ストリームの処理を加速し、機械学習、データサイエンス、人工知能（AI）ワークロードをサポートできます。

さらにデータレイクハウスには、共有メタデータや分散型SQL（構造化問合せ言語）エンジンなどの機能が追加される場合もあります。

データウェアハウスは、組織全体のユーザーに洞察と情報を提供し、以下のような多くのメリットをもたらします。

• データ品質の向上
• AIおよび機械学習のサポート
• 意思決定支援の強化

ELTまたはETLプロセスを通じて、データウェアハウスはデータを保存する前に受け入れデータを準備します。この準備には、データ品質を確保するためのデータ・クレンジング、標準化、重複排除などの手法が含まれます。堅牢なデータ・ガバナンスのポリシーと実践により、すべてのユーザーに対してデータの正確性と完全性を確保することもできます。

高品質なデータを単一のストアに統合することで、組織は包括的で信頼できる「唯一の情報源」を構築でき、データサイロを排除するのに役立ちます。この中央リポジトリーにより、ビジネス・ユーザーは組織全体の関連データに自信を持ってアクセスし、意思決定に活用できます。エンタープライズ・グレードのデータウェアハウスには、Apache Iceberg、Parquet、CSVなどのオープンソース形式のサポートも含まれる場合があり、企業全体でのさらなるデータアクセスと共有を可能にします。

最新のデータウェアハウスは、クリーンで信頼できるデータを提供することで、さまざまなAIや機械学習のワークフローをサポートできます。データサイエンティストは、クレンジングされ検証されたウェアハウス・データを使用して独自の生成AIモデルを構築したり、既存モデルをファインチューニングして独自のビジネスニーズにより適合させたりできます。

AI対応のデータウェアハウスは、データの収集、クレンジング、整理、構造化を行うとともに、AIや機械学習プラットフォームへのデータの流れを促進できる必要があります。ただし、すべての最新データウェアハウスがAIワークロードに最適化されているわけではありません。データレイクハウスはAIインフラストラクチャーのためのデータ・プラットフォームとしてますます選ばれるようになっています。

データウェアハウスは、さまざまなソースからデータを集中管理し、クレンジングすることで「唯一の情報源」を構築し、組織に包括的で信頼性の高いエンタープライズ・データの可視性を提供します。セルフサービス型のBIツールを利用することで、企業全体のユーザーがこの集約されたデータにアクセスし、分析クエリーを実行できます。

このように、データウェアハウスを利用することで、技術スキルのレベルに関係なくビジネスユーザーはテーマやトレンド、集計を発見しレポートできます。ビジネス・リーダーはこれらの洞察を活用し、ビジネスプロセスから財務管理、在庫管理に至るまで、事実に基づいたより適切な意思決定や予測を行うことができます。

データウェアハウスは、次のような業種固有の用途にも使用できます。

• 官公庁・自治体：データ・ウェアハウスの分析機能により、官公庁・自治体は犯罪や人口動態の傾向、交通パターンなどの複雑な現象をより深く理解することができます。
  
  
• 医療：請求書や診断コード、患者人口統計、投薬、検査結果など、異種のデータを一元化して分析する機能は、病院が患者の予後や業務の効率などについてのインサイトを得るのに役立ちます。
  
  
• ホスピタリティーと運輸：組織は、旅行や宿泊施設の選択に関する過去のデータを使用して、顧客に向けた広告やプロモーションをより正確にターゲットにすることができます。
  
  
• 製造：大手製造業は膨大な量のデータを生成します。組織はデータウェアハウスを使用して、各部門のニーズに合わせたデータ・マートを構築できるため、ユーザーが自分の役割に関連するデータに簡単にアクセスできるようになります。

データウェアハウス・ソリューションを実装する場合、組織は高いパフォーマンスを実現するために特定の課題に対応する必要があるかもしれません。これには次のものが含まれます。

• 大量のデータ
• データの品質と管理
• 複雑なクラウド・インフラストラクチャー
• The AI Ladderのサポート
• ストレージの柔軟性の欠如