エージェント型企業を強化する Think基調講演を視聴する

データ・ウェアハウスとは。

データ・ウェアハウスとは。

データウェアハウスは、さまざまなソースからデータを集約し、クエリーや分析に最適化された中央のデータ・ストアに統合します。通常、抽出、変換、ロード(ETL)または抽出、ロード、変換(ELT)プロセスを使用してデータをクレンジングし、ビジネス・インテリジェンス(BI)やその他のデータ分析ユースケースに向けて準備・整理します。
 

データウェアハウス・システムは、運用データベース、トランザクション・システム顧客関係管理(CRM)プラットフォームなど、幅広いソース・システムから大量のデータを統合することができます。セルフサービス分析ツールによって、ビジネス・ユーザーはこのデータを探索・分析し、価値ある洞察を得ることができます。

データウェアハウスの概念は1980年代に登場し、異種のデータを一貫した形式に統合して分析できるようにすることを目的としていました。World Wide Web、ソーシャルメディア、モノのインターネット(IoT)といった新しいデータ・ソースが急増するにつれて、より大容量のストレージと高速な分析の需要が高まりました。

データウェアハウスはニアリアルタイム分析向けに構成および最適化されているため、大量の生の非構造化ビッグデータを保存するには通常適していません。ウェアハウス内のデータ量が増えるにつれて、ストレージのコストと複雑さも増大します。さらに、レイテンシーやパフォーマンスの問題が発生する可能性もあります。

このようなニーズに応えるために、クラウドネイティブのデータウェアハウスやデータレイクハウスなど、より柔軟な代替手段が進化してきました。詳細については、「データウェアハウスとデータレイクハウスの比較」をご覧ください。

データウェアハウジングの仕組み

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

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

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

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

中間層

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

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

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つのスキーマとは

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

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

これらのスキーマには、次のように定義されるファクト・テーブルと次元テーブルが含まれます。

  • ファクト・テーブル:売上製品や収益額などの定量データを格納します

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

スター・スキーマ

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

スタースキーマを描いたグラフィック スター・スキーマの例

スノーフレーク・スキーマ

スノーフレーク・スキーマは、中央のファクト・テーブルをコアに配置し、多数の正規化された次元テーブルが外側に放射状に展開され、それらの次元がさらに多対1の関係を通じて他の次元テーブルにさらに拡張されます。この複雑で分岐したパターンは雪の結晶のように見えることがあります。スノーフレーク・スキーマはデータの冗長性が低い一方で、クエリー性能が低下するというトレードオフがあります。

スノーフレーク・スキーマの例 スノーフレーク・スキーマの例

ギャラクシー・スキーマ

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

Galxyスキーマの例 Galxyスキーマの例

データウェアハウス・アーキテクチャーのコンポーネント

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

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

ETL/ELTツール

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

API層

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

データ層(または中央データベース)

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

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

サンドボックス

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

アクセスツール

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

AI Academy

生成AIの成功の鍵はデータ管理

生成AIの使用を成功させるために、高品質のデータが不可欠である理由をご覧ください。

データウェアハウスのタイプ

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

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

エンタープライズ・データ・ウェアハウス(EDW)

エンタープライズ・データウェアハウス(EDW)は、企業全体にサービスを提供するデータウェアハウスです。全チームや全テーマ領域の履歴データを集約した中央の情報リポジトリーとして機能します。エンタープライズ・データウェアハウス環境には、運用データストア(ODS)や部門固有のデータ・マートが含まれることもあります。

オペレーショナル・データ・ストア(ODS)

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

データ・マート

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

データウェアハウスと他の種類のデータ・ストレージの違い

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

データウェアハウスとデータベースの違い

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

データウェアハウスとデータレイクの違い

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

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

データレイクハウスとデータウェアハウスの比較

データレイクハウスは、データウェアハウスとデータレイクの長所を組み合わせたもので、ウェアハウスの高いパフォーマンスとともに、レイクの低コストな柔軟性を提供します。レイクとウェアハウスの主要機能を一つのデータ・プラットフォームに統合することで、レイクハウスは大量の構造化・非構造化リアルタイムデータの処理を加速できます。

また、機械学習データサイエンス人工知能(AI)のワークロードをより効率的にサポートします。さらにデータレイクハウスには、共有メタデータや分散型SQL(構造化問合せ言語)エンジンなどの機能が追加される場合もあります。

データウェアハウスのメリット

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

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

データ品質の向上

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

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

AIと機械学習のサポート

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

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

意思決定サポートの強化

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

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

データウェアハウスの業界別ユースケース

データウェアハウスは、業界固有の用途にも利用できます。

官公庁・自治体

データ・ウェアハウスの分析機能により、官公庁・自治体は犯罪や人口動態の傾向、交通パターンなどの複雑な現象をより深く理解することができます。

ヘルスケア

請求や診断コード、患者の人口統計、投薬、検査結果など、異なるデータを集中管理・分析できるため、医療提供者はより深い洞察を得ることができます。これらのインサイトは、患者の治療成果の理解や業務効率の向上などに役立ちます。

旅行とホスピタリティー

旅行や宿泊の選択に関する履歴データを活用して、顧客により正確に広告や販促をターゲティングできます。

製造業

大量のデータを生成する大規模製造企業は、各部門のニーズに合わせたデータ・マートを構築するためにデータウェアハウス・ソリューションを利用できます。

データウェアハウスに関するよくある質問

データウェアハウスは必要ですか?

データウェアハウスは、ビジネス・アプリケーション(BI)、Webサイト、その他のデータベースなど、複数の業務システムから大量のデータを集約している組織にとって、賢い選択となり得ます。BIツールやダッシュボードを使用して複雑な履歴分析を実行する予定の場合に特に役立ちます。

データウェアハウスのコストを最適化するにはどうすればよいですか?

コストを最適化するには、データとコンピューティング・リソースを分離し、個別に拡張できるアーキテクチャーを検討してください。また、コスト効率の良いクラウド・オブジェクト・ストレージやAI搭載のワークロード管理を活用して、自動化されたリソース分配を行うこともできます。オープン・データ形式により、ウェアハウスやレイクハウス間でデータ共有が容易になり、ストレージコストと複雑さが削減されます。

データウェアハウスでのデータ品質問題をどう扱うべきでしょうか?

データ・クレンジングと標準化のための強力なETL/ELTプロセス、堅牢なデータガバナンスポリシー、そして問題が発生した際にそれを検知するためのデータ可観測性は、データ品質の問題に対処するのに役立ちます。「シフト・レフト」アプローチは、データ品質の問題を下流ではなく、根本原因の近くで検出し、解決するのにも役立ちます。

データウェアハウスはデータベースとどう違うのですか?

データベースは主に高速トランザクション処理のために構築され、通常は特定のアプリケーションのデータ・ストレージとして機能します。データウェアハウスは、さまざまなソースから大量のデータを集約し、ビジネスインテリジェンス、分析クエリー、その他の高度なデータ分析のためにデータをクリーンアップして準備します。

データウェアハウスは誰が所有すべきでしょうか?

データ・エンジニアがインフラストラクチャーの構築と保守を行い、最高データ責任者が、データ戦略を立てデータ管理機能を監督します。ビジネスインテリジェンスチームがセマンティックレイヤーとダッシュボードを管理し、部門横断的なデータガバナンスチームがデータ品質セキュリティーの確保を支援します。

共同執筆者

Alexandra Jonker

Staff Editor

IBM Think

Jim Holdsworth

Staff Writer

IBM Think

Matthew Kosinski

Staff Editor

IBM Think

関連ソリューション
IBM watsonx.data

watsonx.dataを使用すると、オープンでハイブリッド、かつ管理されたデータ・ストアを通じて、データがどこに保存されていても、すべてのデータを使用して分析とAIを拡張できます。

watsonx.dataの詳細はこちら
データレイク・ソリューション

オープンなデータレイクハウスに含まれるあらゆるデータを使用して、アプリケーション、分析、AIを強化します。

データレイク・ソリューションの確認
データおよびAIコンサルティング・サービス

適切な戦略、データ、セキュリティ、ガバナンスを整え、AIを効果的に拡張します。

データおよびAIコンサルティング・サービスはこちら
次のステップ

IBM watsonx.dataで、AIおよび分析のためにすべてのデータを統合を統合します。AIと分析のためのハイブリッドでオープンなデータレイクハウスで、データの所在に関わらず、あらゆるデータを活用しましょう。

  1. watsonx.dataの詳細はこちら
  2. AI向けデータソリューションの探索