データウェアハウスの種類：アーキテクチャとユースケースの完全ガイド

データウェアハウスは、組織全体の構造化データを収集、整理、保存する中央リポジトリであり、アナリストやデータサイエンティストが複雑なクエリを実行し、レポートを生成し、ビジネスインテリジェンス（BI）ワークロードをサポートできるようにします。トランザクション処理用に設計された運用データベースとは異なり、データウェアハウスは分析ワークロード向けに構築されています。複数のソースからのデータを結合し、長年にわたる履歴データを保存し、戦略的な意思決定に必要なガバナンスの効いた基盤を提供します。

プラットフォームの選定や移行を行う前に、さまざまなデータウェアハウスの種類を理解しておくことが不可欠です。それぞれの種類は、スケール、レイテンシ、コスト、対象範囲の間における、アーキテクチャ上の明確なトレードオフを反映しています。このガイドでは、従来のエンタープライズデータウェアハウスから最新のレイクハウスアーキテクチャまで、データウェアハウスの主要な種類をすべて網羅し、それぞれがどのような場合に最適な選択肢となるかについて明確な指針を提供します。

データウェアハウスの3つの主な種類

この分野では、現代のデータアーキテクチャの基盤となる3つの主要なデータウェアハウスの種類が認識されています。それは、エンタープライズデータウェアハウス（EDW）、データマート、およびオペレーショナルデータストア（ODS）です。これらに加えて、組織はワークロードの要件、データ量、ガバナンスの複雑さに応じて、クラウド型データウェアハウス、仮想データウェアハウス、ハイブリッドデータウェアハウス、レイクハウスプラットフォームなども導入しています。

それぞれの種類は、データの保存方法、所有者、サポートするレイテンシ、得意とする分析クエリにおいて異なります。適切な選択は、データソース、チーム体制、データ品質の要件、およびサポートする必要がある分析のユースケースによって決まります。

エンタープライズデータウェアハウス（EDW）

エンタープライズデータウェアハウス（EDW）は、最も包括的な種類のデータウェアハウスであり、組織全体の信頼できる唯一の情報源（Single Source of Truth）として機能するように設計されています。EDWは、営業、財務、運用、人事、顧客関係管理（CRM）システム、在庫管理システムなど、すべての主要な部門からのデータを、一貫したデータ品質基準とアクセス制御によって管理された単一の中央データウェアハウスに統合します。

アーキテクチャとスコープ

エンタープライズデータウェアハウスの決定的な特徴は、組織横断的なスコープにあります。複数のソースからのデータは、Extract, Transform, Load（ETL）プロセスを経てウェアハウスに格納され、そこでビジネスルール、データのクレンジング、検証によってチーム間の一貫性が確保されます。その結果、どの部門のアナリストであっても、同じバージョンのビジネスデータに対してクエリを実行できる、ガバナンスの効いたリポジトリが実現します。

EDWは通常、3層アーキテクチャを採用しています。最下層（ボトムティア）は、データソースと、運用システムから生データをインジェスト（取り込み）して変換するETLプロセスを処理します。中間層（ミドルティア）は、多次元分析のためにデータへのアクセスを可能にするOLAPサーバーをホストします。最上層（トップティア）は、ビジネスユーザーがデータを分析するためのフロントエンドツール（ダッシュボードやBIアプリケーション）を提供します。この階層型設計により、インジェストの複雑さと分析パフォーマンスが分離され、各層を独立して最適化できます。

EDWを選択すべきケース

組織全体での分析、規制コンプライアンスに関するレポート、または現在データサイロ化している部門間での信頼できる唯一の情報源が必要な場合、EDWは最適な基盤となります。規制報告を管理する金融サービス企業、患者データを管理する医療機関、サプライチェーンと生産データを統合する大手製造企業など、複雑なデータガバナンス要件を持つ組織は、EDWが提供する一元化されたガバナンスから最大の恩恵を受けられます。

従来のデータウェアハウスにおける主な課題は、スケーラビリティです。データ量が増加するにつれて、独自のテーブルフォーマットや固定されたハードウェア構成により、オンプレミスのEDW導入は拡張コストが高くなります。この制約に直面している多くの組織は、EDWのガバナンスモデルを維持しつつ、インフラの限界を排除したクラウドベースまたはレイクハウスアーキテクチャへの移行を進めています。

データマート

データマートは、特定の部門、ビジネス機能、または分析ドメインにスコープを絞った、データウェアハウスの特定のテーマに特化したサブセットです。EDWが組織全体にサービスを提供するのに対し、データマートはマーケティングチーム、財務部門、地域の営業部門など、特定の対象者にサービスを提供します。データマートは、特定のチームが実行する特定のクエリやレポート用に最適化された形式でデータを保存し、通常は結合の複雑さを最小限に抑える非正規化されたスタースキーマやスノーフレークスキーマ設計を使用します。

従属型データマートと独立型データマート

データマートには2つのアーキテクチャパターンがあります。従属型データマートは、既存のEDWからデータを取得し、中央リポジトリのガバナンスとデータ品質基準を継承します。これは、部門間での指標定義の不一致を防ぐことができるため、すでにEDWが存在する場合に推奨されるアプローチです。

独立型データマートは、EDWを経由せずにソースシステムから直接データを取り込みます。独立型マートは迅速に構築できますが、リスクも伴います。各マートが異なるビジネスルールを適用する可能性があり、部門間で一貫性のないレポート作成につながる恐れがあります。これはまさに、データウェアハウスアーキテクチャが排除しようとしているデータサイロそのものです。

データマートを構築すべきケース

特定のチームに、完全なEDWの導入を待つ時間がない分析要件がある場合、データサブセットに対するクエリパフォーマンスを個別に最適化する必要がある場合、またはデータの部門所有がガバナンス要件である場合に、データマートを構築します。データマートは、売上データの分析、マーケティングのアトリビューション、財務報告など、データドメインが明確に定義され、利用者が限定されているユースケースに特に適しています。

オペレーショナルデータストア（ODS）

オペレーショナルデータストア（ODS）は、ほぼリアルタイムのレポート作成や運用の意思決定向けに設計されたデータウェアハウスの一種であり、トランザクションデータベースと分析用のEDWの間に位置します。EDWが長年にわたって蓄積された履歴データを保存するのに対し、ODSは現在および最近の運用データを保持し（通常、数分から数時間の間隔で更新されます）、長期的なトレンドではなくビジネスの現在の状態を反映するクエリに最適化されています。

データアーキテクチャにおけるODSの役割

CRMプラットフォーム、在庫管理システム、注文処理プラットフォームなどの運用システムは、トランザクションデータを継続的に生成しますが、分析クエリ向けには設計されていません。本番環境のトランザクションデータベースに対して複雑なレポートを実行すると、それがサポートする業務の速度が低下します。ODSは、運用データを別の環境に複製することでこれを解決し、アナリストがソースシステムに影響を与えることなくクエリを実行できるようにします。

ODSは、複数の運用ソースからのデータを統合し、フォーマットを標準化するために軽い変換を適用し、統合された運用データをレポート作成に利用できるようにします。これはEDWに代わるものではありません。履歴トレンド分析や戦略的計画のクエリは、依然としてデータウェアハウスの役割です。ODSは、現在の在庫レベル、当日の売上実績、アクティブなカスタマーサポート案件など、時間に敏感な運用の質問を処理します。

仮想データウェアハウス

仮想データウェアハウス（フェデレーテッドデータウェアハウスとも呼ばれます）は、データを単一のストレージ場所に物理的に統合しません。代わりに、論理的な抽象化レイヤーを作成し、複数のソースシステムにまたがってその場でデータをクエリし、それらの異なるシステムを統合された分析環境として提示します。

仮想ウェアハウスは、クエリフェデレーション技術を利用してクエリをソースシステムにプッシュダウンし、プレゼンテーション層で結果を集計します。このアプローチにより、物理的な統合に伴うストレージやETLインフラのコストが不要になり、運用データベースにすでに存在するデータを移動させることなく分析する際の価値実現までの時間（Time-to-Value）を短縮できます。主な制限はクエリのパフォーマンスです。複数のシステムにまたがる大規模なデータセットの結合を必要とする複雑なクエリは、各クエリが分析ワークロード向けに設計されていないシステムからデータを取得する必要があるため、大きなレイテンシが発生します。

仮想データウェアハウスは、探索的分析、小規模なレポート作成、または規制上の制約によりデータの移動が禁止されている状況に最適です。大量の分析クエリや、大規模なデータ処理を必要とするAIワークロードには、適切なアーキテクチャとなることはほとんどありません。

クラウド型データウェアハウス

クラウド型データウェアハウスは、AWS、Microsoft Azure、Google Cloudなどのクラウドプラットフォーム上でホストされ、データウェアハウス機能をフルマネージドサービスとして提供します。クラウド型データウェアハウスを運用する組織は、物理的なハードウェアのプロビジョニングや保守を行う必要がありません。クラウドプロバイダーがインフラを管理し、組織はデータのインジェスト、モデリング、分析に集中できます。

クラウド導入のメリット

クラウド型データウェアハウスの最も重要なメリットは、弾力性のあるスケーラビリティです。従来のオンプレミスのデータウェアハウスでは、ピーク時の負荷に合わせてハードウェアのサイズを決定する必要があり、通常の運用時には過剰なプロビジョニングが発生していました。クラウドウェアハウスは、従量課金制モデルに基づいて需要に応じてコンピューティングリソースとストレージリソースを自動的に拡張するため、組織は使用した分だけ支払うことになります。また、クラウド導入は価値実現までの時間も短縮します。オンプレミスの導入では調達から本番稼働まで数か月かかる場合がありますが、クラウドデータウェアハウスは数時間以内にプロビジョニングしてデータをロードできます。

エグレスコストと移行への対応

クラウドベースのデータウェアハウスには、組織が評価すべきトレードオフが存在します。クラウドプロバイダーのネットワーク外にデータを移動する際の手数料であるデータエグレス料金（データ転送量課金）は、規模が大きくなると高額になる可能性があります。複数のクラウドプロバイダーを利用する組織は、異なるプラットフォーム間でのデータ統合、セキュリティポリシー、ガバナンスフレームワークの管理において、さらなる複雑さに直面することになります。

クラウドデータウェアハウスに移行する前に、プラットフォームから流出するデータ量を評価し、ベンダーロックインを軽減するオープンデータフォーマットを検討し、移行先プラットフォームのガバナンスおよびセキュリティ機能がコンプライアンス要件を満たしているか確認してください。

ハイブリッドおよびモダンデータウェアハウス

ハイブリッドデータウェアハウスは、オンプレミスとクラウドのデータストレージ機能を組み合わせたものです。これにより、組織は機密データや規制対象データを自社のデータセンターに保持しつつ、需要の変動に応じた分析処理のためにクラウドのスケーラビリティを活用できます。

モダンデータウェアハウスの特徴

モダンデータウェアハウスは、いくつかの重要な方法で従来のウェアハウスモデルを拡張しています。事前定義されたスキーマを持つ構造化データだけでなく、半構造化データや非構造化データもサポートします。また、コンピュートとストレージを分離することで、それぞれを独立してスケーリングできるようにし、大規模なデータ処理のコストを削減します。さらに、ストリーミングデータパイプラインと統合してレイテンシを短縮し、オープンデータフォーマットをサポートしてベンダーロックインを回避し、従来の BI やレポート作成に加えて、機械学習や AI のワークロード向けのネイティブなフックを提供します。

また、モダンデータウェアハウスは強力なデータリネージ機能を備えており、ソースシステムから各変換ステップを経て最終的な利用ポイントに至るまでデータを追跡します。このリネージは、データガバナンスとデータ品質保証に不可欠です。アナリストがレポートの数値を疑問視した場合、リネージのドキュメントを参照することで、データチームはその数値がどのように計算されたかを正確に追跡できます。

データレイクとレイクハウスのアーキテクチャ

データレイクは、事前定義されたスキーマなしで生データを元のフォーマットのまま保存し、あらゆるソースからの構造化、半構造化、非構造化データを受け入れます。データを保存してクエリを実行する前に、ETL プロセスを通過させて定義されたスキーマに適合させる必要があるデータウェアハウスとは異なり、データレイクはスキーマオンリードを採用しています。つまり、スキーマはインジェスト（取り込み）時ではなく、クエリ実行時に適用されます。この柔軟性により、データレイクは機械学習やデータサイエンスの探索用として、大量の生データを保存するのに適しています。

トレードオフとなるのは信頼性です。ETL プロセスが提供するデータ品質の強制力がないため、データレイクには不整合、重複、またはドキュメント化が不十分なデータが蓄積される可能性があり、アナリストが統制された BI レポート作成のために信頼することができなくなります。

統合ソリューションとしてのレイクハウス

データレイクハウスは、データレイクの柔軟性とコスト効率、およびデータウェアハウスのデータ管理機能を組み合わせたものです。レイクハウスはクラウドオブジェクトストレージ上にオープンフォーマットでデータを保存し、ACID トランザクション、スキーマエボリューション（スキーマ進化）、データ品質制約、およびタイムトラベル（過去の任意の時点に存在していたデータをクエリする機能）を強制するトランザクションメタデータおよびガバナンスレイヤーを追加します。

その結果、データエンジニアが ETL パイプラインを実行し、データアナリストが統制されたテーブルに対して SQL クエリを実行し、データサイエンティストがモデルトレーニングのために生データや特徴量エンジニアリングされたデータにアクセスできる、単一のプラットフォームが実現します。これらはすべて、システム間でデータを移動することなく行えます。レイクハウスの導入で一般的なメダリオンアーキテクチャでは、データをブロンズ（生データ）、シルバー（検証および統合済み）、ゴールド（精選され、すぐに利用可能）のレイヤーに整理し、各段階でデータ品質を段階的に向上させます。ゴールドレイヤーは、従来のウェアハウスがすでに運用しているデータマートや EDW サービングレイヤーに直接マッピングされるため、アーキテクチャの移行がスムーズに行えます。

データウェアハウスのアーキテクチャとストレージ

導入モデルに関係なく、データウェアハウスのアーキテクチャは同じ基本原則を反映しています。それは、データを生成元のアプリケーションから分離し、統制されたプロセスを通じてクレンジングおよび統合し、トランザクションの書き込みではなく分析クエリに最適化されたフォーマットで保存する必要があるということです。

ストレージとスキーマ設計

モダンデータウェアハウスはコンピュートとストレージを分離しているため、それぞれの次元を独立してスケーリングできます。ストレージシステムはデータを列指向（カラムナー）フォーマットで保持し、分析クエリ中にスキャンされるデータを最小限に抑えます。たとえば、50列のうち3列だけにアクセスするクエリは、すべての行を完全にスキャンするのではなく、3列分のデータのみを読み取ります。

スキーマ設計はクエリのパフォーマンスに大きく影響します。スタースキーマは、売上トランザクションやウェブセッションなどの測定可能なイベントを含む中央のファクトテーブルを中心に、関連するエンティティ（顧客、製品、期間）を説明するディメンションテーブルで周囲を構成します。スタースキーマでの結合（ジョイン）はシンプルで高速です。スノーフレークスキーマはディメンションテーブルをさらに正規化し、結合の複雑さが増す代わりにストレージの冗長性を削減します。ギャラクシースキーマは、複数のファクトテーブル間でディメンションテーブルを共有し、異なるビジネスプロセスにまたがる分析クエリをサポートします。

スタースキーマは、読み取りパフォーマンスを優先するため、データマートやレイクハウスのゴールドレイヤーで最も一般的な選択肢です。適切なスキーマは、データ量、更新パターン、およびスキーマがサポートする必要のある分析クエリの複雑さによって異なります。

ウェアハウス内のデータの種類

データウェアハウスは歴史的に、リレーショナルデータベース、CRM プラットフォーム、財務システム、在庫管理システムなどをソースとする、事前定義されたデータ型とスキーマを持つ行と列 of 構造化データを保存してきました。構造化データは、標準的な SQL を使用して簡単にクエリを実行でき、ETL パイプラインにスムーズに統合できます。

構造化、半構造化、非構造化データ

半構造化データは、厳密なリレーショナルスキーマには準拠していませんが、パース（解析）を可能にする組織的なマーカーを含んでいます。JSON ドキュメント、XML ファイル、ログレコード、クリックストリームデータはすべてこのカテゴリに分類されます。多くのモダンデータウェアハウスプラットフォームは、ネイティブな半構造化データ型をサポートしており、データを事前にフラット化することなく、SQL クエリでネストされた構造をナビゲートできます。

非構造化データ（画像、動画、自由形式のテキストドキュメント、音声録音など）は、SQL で直接クエリを実行することはできませんが、組織が AI や機械学習の機能を構築するにつれて、その重要性はますます高まっています。レイクハウスアーキテクチャはこの境界線を曖昧にし、非構造化データを同じプラットフォーム内で構造化データと並行して保存および管理できるようにします。

スキーマオンライト（従来のデータウェアハウスのようにインジェスト時に構造を強制する）とスキーマオンリード（データレイクのようにクエリ実行時まで構造化を遅らせる）の選択は、データ品質の一貫性とインジェストの柔軟性の間の根本的なトレードオフを反映しています。成熟したデータプラットフォームの多くは、統制された分析テーブルにはスキーマオンライトを使用し、探索用および生データのゾーンにはスキーマオンリードを使用します。

外部データソースと統合

データウェアハウスが単一のソースからのみデータを取得することはほとんどありません。一般的なエンタープライズ環境の導入では、運用データベース、CRM システム、ERP プラットフォーム、マーケティングオートメーションツール、財務元帳、サードパーティのデータプロバイダー、外部 API からのデータを統合します。これらの多様な外部データソース（それぞれ独自のスキーマ、更新頻度、データ品質特性を持つ）を管理することは、データウェアハウスアーキテクチャの主要な課題の1つです。

外部データがウェアハウスに入る前に、期待されるスキーマやデータ品質ルールに照らし合わせて検証する必要があります。検証を行うことで、必須フィールドの欠落、想定範囲外の数値、参照整合性の違反といった一般的な問題を早期に発見できます。インジェスト時にこれらの問題を検出することは、データがレポートやダッシュボードに反映された後に発見するよりも、はるかにコストが抑えられます。データエンリッチメント（取り込んだデータに参照テーブルや外部データセットからのコンテキストを追加すること）は、生のソースデータをアナリストが必要とするビジネスに即したデータセットへと変換します。

ETL と ELT、およびパイプラインモニタリング

データ統合プロセスは、データがソースシステムからウェアハウスにどのように移動し、どのように変換されるかを決定します。ETL（Extract, Transform, Load）は従来のアプローチであり、データはソースから抽出され、別の処理環境で変換された後、最終的な構造化された形式でロードされます。ELT（Extract, Load, Transform）はその順序を逆にし、まず生データをロードしてから、ウェアハウス自体の処理能力を使用してウェアハウス内で変換を行います。モダンなクラウドデータウェアハウスでは、変換ステップでウェアハウスの並列処理機能を活用でき、全体的なコストを抑えられるため、ELT が好まれることがよくあります。アーキテクチャへの影響について詳しく知りたい場合は、ELT と ETL の比較で主要なトレードオフを解説しています。

データパイプラインのモニタリングは、インジェストジョブがスケジュール通りに完了し、データ量が想定と一致し、データが本番環境にプロモートされる前に品質チェックに合格することを確認します。サイレントエラー（エラーなしで完了するものの、誤った結果を生成するパイプラインの失敗）は、データウェアハウスの運用において最も危険な障害モードの1つです。

データセキュリティとガバナンス

データガバナンスとデータセキュリティは、あらゆるデータウェアハウスの基本要件であり、特に規制コンプライアンスの対象となる機密データを扱う組織にとっては極めて重要です。誰が、いつ、何の目的でどのデータにアクセスしたかを証明できないウェアハウスは、監査人を満足させることも、データを預けている顧客の信頼を維持することもできません。

アクセス制御、暗号化、および監査ログ

効果的なデータセキュリティは、ロールベースのアクセス制御（RBAC）から始まります。これは、個人ではなくロールにデータアクセス権限を割り当てることで、大規模な組織全体でアクセス管理をスケーラブルにするものです。アクセス制御は、カタログレベル、テーブルレベル、列レベル（個人を特定できる情報（PII）のマスキングに不可欠）、および行レベル（組織への所属やデータの所有権に基づく）の複数のレベルで機能する必要があります。

データは、保存時と転送時の両方で暗号化される必要があります。保存時の暗号化はストレージメディアへの不正アクセスを防ぎ、転送時の暗号化はネットワーク上での傍受を防ぎます。監査ログは、誰がいつテーブルにクエリを実行し、どのようなデータが返されたかなど、すべてのアクセスおよび変更イベントを記録し、セキュリティ調査や規制コンプライアンスの証明をサポートします。データのソースからすべての変換を経て消費ポイントまでデータを追跡するデータリネージの追跡は、ガバナンスとデータ品質保証の両方をサポートします。

ウェアハウスのタイプ別データ分析ユースケース

データウェアハウスのタイプによって対応する分析ワークロードは異なります。このマッピングを理解することで、特定のワークロードタイプに最適化されたアーキテクチャを導入しながら、すべてのユースケースで同様のパフォーマンスを期待してしまうといった失敗を避けることができます。

ワークロードへのアーキテクチャのマッチング

エンタープライズデータウェアハウスは、前年比トレンド分析、部門横断的なレポート、エグゼクティブダッシュボード、複数のビジネスドメインにわたるデータの結合を必要とするコンプライアンスレポートなどの戦略的分析をサポートします。データマートは、売上パフォーマンス、マーケティングアトリビューション、決算レポート、顧客セグメンテーションなどの部門別の分析をサポートし、データ範囲が限定されているためセルフサービスを迅速化できます。オペレーショナルデータストアは、小売、物流、金融サービス環境における現在のビジネス状況の監視やリアルタイムイベントへの対応など、運用分析をサポートします。

クラウドおよびレイクハウスアーキテクチャは、大規模な機械学習モデルのトレーニング、自然言語処理パイプライン、レコメンデーションシステムなどの高度な分析とAIをサポートします。これらのワークロードには、管理された構造化データだけでなく、より柔軟なストレージアーキテクチャのみが対応できる生データや半構造化データも必要となります。

BI、レポート、高度な分析

BIツールはデータウェアハウスに接続し、SQLを書かないビジネスユーザーでもアクセスできるダッシュボードやレポートを作成します。機械学習の統合では、データサイエンティストが特徴量エンジニアリング用の管理されたクリーンなデータと、モデルトレーニング用の生の履歴データの両方にアクセスする必要があります。レイクハウスアーキテクチャは、これら両方のユースケースを単一のプラットフォームでサポートするため、BIワークロードとMLワークロード用に個別のデータコピーを維持するというデータエンジニアリングのオーバーヘッドを排除できます。

データウェアハウスソリューションの選択と移行

適切なデータウェアハウスソリューションを選択するには、ベンダー管理型とセルフホスト型のオプションの評価、コスト構造の理解、およびプラットフォームが特定の分析ワークロードを大規模にサポートできるかどうかの検証が必要です。ベンダー管理型サービスは、インフラストラクチャの管理、スケーリング、パッチ適用、高可用性を処理しますが、運用管理の一部が制限されます。セルフホスト型オプションは、厳格なデータ所在地要件や複雑なセキュリティポリシーに対して組織に高い柔軟性を提供しますが、チームがクラスターを管理し、アップグレードを調整し、容量計画を処理する必要があります。

ベンダーとコスト要因の評価

データウェアハウスのコストは、ストレージコスト、コンピュートコスト、データ移動コストの3つのカテゴリに分類されます。最新のクラウドデータウェアハウスでは、ストレージとコンピュートの価格が個別に設定されているため、それぞれを独立してスケーリングできます。重要な本番ワークロード用のプラットフォームを決定する前に、実際のデータとクエリパターンを使用して概念実証（PoC）を実行してください。合成ベンチマークが、実際に運用するデータ量における実世界のパフォーマンスを反映することはほとんどありません。

段階的な移行とコストの最適化

レガシーデータウェアハウスから最新のプラットフォームへの移行は、ビジネスドメインごとに整理された段階的なアプローチを採用すると効果的です。まずは、データ要件が明確に定義され、意欲的なビジネスオーナーが存在するドメインから始めましょう。次のドメインに進む前に、本番環境のベンチマークに対して移行を検証します。

コンピュートとストレージの分離は、最新のデータウェアハウスにおける最も重要なコスト最適化手段の1つです。従来のアーキテクチャでは、コンピュートとストレージは一緒にスケーリングされます。最新のクラウドアーキテクチャはこれらの要素を分離するため、組織は追加のコンピュートをプロビジョニングすることなくストレージを追加でき、ストレージコストを恒久的に増やすことなくピーク時のクエリ期間に合わせてコンピュートをスケールアップできます。オートスケーリングにより、ピーク時のプロビジョニング不足とアイドル時の過剰なプロビジョニングの両方を防ぐことができます。

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

よくある質問

主なデータウェアハウスのタイプは何ですか？

主要な3つのデータウェアハウスタイプは、エンタープライズデータウェアハウス（EDW）、データマート、およびオペレーショナルデータストア（ODS）です。これらのコアタイプに加えて、組織はクラウドベースのデータウェアハウス、仮想データウェアハウス、オンプレミスとクラウドストレージを組み合わせたハイブリッドデータウェアハウス、およびウェアハウスのガバナンスとデータレイクの柔軟性を統合したレイクハウスアーキテクチャも導入しています。各タイプは、データの範囲、レイテンシ要件、および分析ワークロードに基づいて、異なるユースケースに対応します。

データウェアハウスとデータレイクの違いは何ですか？

データウェアハウスは、事前に定義されたスキーマに構造化データを保存し、データがロードされる前にETLプロセスを通じてデータ品質を強制します。データレイクは、取り込み時に事前に定義されたスキーマを必要とせず、構造化、半構造化、または非構造化といった元のフォーマットのまま生データを保存します。データウェアハウスは複雑な分析SQLクエリやBIレポート用に最適化されており、データレイクは柔軟性や大規模なデータサイエンスおよび機械学習ワークロード用に最適化されています。レイクハウスはこれら両方を組み合わせたもので、データレイクの柔軟性を備えたオープンフォーマットでデータを保存し、データウェアハウスの信頼性を備えたガバナンスおよびトランザクションレイヤーを追加します。

組織がEDWではなくデータマートを使用すべきなのはどのような場合ですか？

データマートは、特定の部門が完全なEDWの導入よりも迅速に分析機能を必要とする場合、限定されたデータドメインに対するクエリパフォーマンスを個別に最適化する必要がある場合、または部門ごとのデータ所有権がガバナンス要件である場合に適した選択肢です。データマートは、ソースシステムから直接取り込むのではなく、中央リポジトリからデータを取得する、既存のEDWの上に構築された依存型ストアとして最も効果的です。中央のEDWなしで独立したデータマートを構築すると、一貫性のない指標定義やチーム間でのデータサイロが発生するリスクがあります。

オペレーショナルデータストアとは何ですか？また、データウェアハウスとどのように異なりますか？

オペレーショナルデータストア（ODS）は、数分から数時間の間隔で更新される現在およびそれに近い運用データを保持し、運用レポートや意思決定向けに設計されています。データウェアハウスは、長年にわたる履歴データを蓄積し、トレンド分析、戦略的レポート、および複雑な多次元クエリ用に最適化されています。ODSは、運用トランザクションシステムと、1日に1回しか更新されないこともあるウェアハウスとの間のレイテンシのギャップを埋めます。多くの場合、両方のシステムが一緒に導入されます。ODSが当日の運用の可視化をサポートし、ウェアハウスが長期的な戦略分析をサポートします。

クラウドデータウェアハウスはオンプレミスのデータウェアハウスとどのように異なりますか？

クラウドデータウェアハウスはクラウドプラットフォーム上でホストされ、オンプレミスの導入と比較して、弾力的なスケーラビリティ、従量課金制の料金設定、およびインフラストラクチャ管理オーバーヘッドの削減を実現します。従来のオンプレミスデータウェアハウスはピーク時の容量に合わせてサイズを決定する必要があり、通常の運用時には大幅な過剰プロビジョニングが発生することがよくあります。クラウドウェアハウスは自動的にスケーリングし、数時間でプロビジョニングできます。トレードオフとしては、大容量時のデータエグレス（送信）コスト、クラウドプロバイダーの可用性への依存、および複数のクラウドプラットフォームにわたって運用する組織におけるガバナンスの複雑さなどが挙げられます。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事