- データマートは、特定の部門のためのもので、通常は企業全体のデータウェアハウスの1つのサブセットです。
- データマートは、より小規模で、より特化したデータセットによりクエリの速度を向上させます。
- データウェアハウスは企業全体の戦略的な意思決定を支援し、データマートは部門レベルの戦術的な意思決定を行うためのものです。
- データウェアハウスには多くのデータセットが含まれており、更新には時間がかかります。
- データウェアハウスの実装には何年もかかりますが、データマートは範囲が狭く、数ヶ月で実装することができます。
データマートとデータウェアハウスの違いとは?
また、データマートは今日のクラウドファーストの世界においても妥当だと言えるでしょうか?
データマートとデータウェアハウスの定義、両者のユースケース、そして今日のクラウドエコシステムにおけるデータマートの役割について解説します。
Table of Contents
データマートについて
データマートは、ビジネスの特定の領域で使用するために用意されたデータウェアハウスの1セグメントです。データセット全体を、財務やマーケティング部門に関連するデータなど、管理しやすい関連性の高いチャンクに分割します。
現代のビジネスでは、膨大な量の構造化されたデータと非構造化データを毎日取得しています。データ量を考えると、データセット全体に対してクエリを実行するには時間がかかってしまいます。エンドユーザーは、通常、分析する前に関連データを取得するためだけに複雑なクエリを書かなければなりません。データをビジネスの役割ごとに分解することで、データマートは関連する情報に素早くアクセスできるようになります。また、データインサイトを取得するプロセスを迅速化します。
別の言い方をすれば 営業はチーズが欲しい、マーケティングは七面鳥が欲しい、法務はパンが欲しいと思っているなら、サンドイッチを1つずつ分解してもらいたくないですよね。データマートを使えば、それぞれに必要なものを与えることができます。
データウェアハウスについて
データウェアハウスは、ビジネスのデータセット全てを持つ中央のデータリポジトリです。データウェアハウス内のデータへのアクセスを制御することは、データプライバシー法に準拠するために重要です。さらに、前述したように、データウェアハウス全体に対してクエリを実行することは、エンドユーザーにとって複雑な作業になります。
データマートでは、エンドユーザーがデータを照会しやすくするために、ビジネス機能に応じてデータを分離して管理します。データの分離は、既存のデータウェアハウスから作成される場合もありますし、様々な業務部門や組織が独自にデータマートを作成することも可能です。これらのデータマートは、データウェアハウスにマージすることも可能です。
データマートvs. データウェアハウス
データマート対データウェアハウスの基本的な性質を見てみましょう。
データマート
- サイズ:100GB未満
- テーマ:単一テーマ
- ソース:ビジネス部門に特化したBIツール
- スコープ:単一のビジネスラインまたは多機能部門
- 意思決定:単一部門の目標とトラッキングを活用した戦術的な意思決定をサポートし、より大きな全体像を構築します。
- コスト: $10,000 - $100,000 データマート、統合、ETLの範囲によって異なります。
- 統合:特定のビジネス部門に必要な統合
データウェアハウス
- サイズ:100GB以上
- テーマ:複数の対象
- ソース:企業のデータを構成する社内外のリソース
- スコープ:複数のビジネス部門
- 意思決定:事業全体に影響を与える戦略的な意思決定をサポート
- コスト:社内のデータウェアハウスでは10万ドル以上かかるが、クラウドソリューションを活用すればコストは大幅に下がる
- 統合:企業全体の統合
データマートの種類について
データウェアハウスには、一般的な企業において使用される3つの主要なタイプのデータマートがあります。
- 従属型データマート:従属型データマートを使えば、中央のデータウェアハウスからすべてのデータを引き出すことができます。この方法は間違いなくいくつかの利点があります(すなわち、データの集中化です)。データウェアハウスにおいてデータマートを開発する主な目的は、クエリパフォーマンスを向上させ(クエリはデータマートレベルで実行されます)、KPIトラッキング機能を提供することです - なぜなら各データマートのKPIトラッカーを開発することができるため。
- 独立型データマート:独立型データマートでは、あなたのデータマートはデータウェアハウスには一切接続されていません。これは、データウェアハウスの目的(複数のデータストリームを活用して情報に基づいた意思決定を行うこと)と矛盾しているように見えるかもしれませんが、短期的な目標や迅速な導入に役立ちます。多くの場合、独立したデータマートは、より複雑な従属型データマートを構築する過程で構築されます。(多くの場合、このステップを完全にスキップすることを選択しますが )
- ハイブリッドデータマート:ハイブリッドデータマートは、データウェアハウスデータと別のシステム(技術スタックなど)からのデータの両方を組み合わせています。通常、これらはアドホックな統合や、異なるソースからのデータをすぐに利用する必要がある場合に利用されます。理想的には、これらの異なるソースをウェアハウスに統合し、ハイブリッドシステムの必要性を排除したいと考えています。
データマートのメリット
データマートを使用する理由はいくつかあります。
- ユーザーは、情報に基づいた意思決定を行うために必要となる正確なデータにアクセスすることが可能
- リスクを軽減し、データの使用状況を監視してセグメント化することができます。
- 各データマートのKPIトラッカーを構築することが可能
- BIツールとの統合が容易
- 特定のビジネス部門ごとのデータをより明確に把握することが可能
- データマートレベルでクエリを実行できるので、パフォーマンスが向上
- データウェアハウスよりも安価に構築することが可能
- ビジネス部門のアクセシビリティを向上させるためにデータを構成することが可能
- 部門は自身のデータ関連タスクをコントロールすることが可能
- データマートは、より堅牢なデータウェアハウスを構築するためのブロックとして機能することが可能
データマートの構造とデータモデリング
データマートは、データウェアハウスの設計において重要な役割を果たしています。使用するデータモデリング手法(またはスキーマ)によって、データマートの構築方法や活用方法は大きく異なり、データウェアハウスソリューションの全体的な構築に影響を与えます。
ビジネスに使えるデータモデリングの方法論はたくさんありますが、ここでは、Bill Inmonの「トップダウン」とRalph Kimballの「ボトムアップ」という2つの主要なモデルを取り上げます。
Bill Inmonのトップダウンアプローチ
Bill Inmon は、データマート構築のためのトップダウンアプローチを定義しました。このモデルでは、データウェアハウスが最初に構築され、すべてのビジネスデータのメインの保存場所となります。そして、データマートは、特定のビジネスニーズを満たすためにアドホックに構築されます。つまり、データウェアハウスはデータマートを前提として構築されているわけではないので、特定のビジネスラインが必要になったときに応じて後から追加していくことになります。
トップダウンのアプローチは、このモデルに従います - データウェアハウス > ETL > データマート > OLAPキューブ > インターフェース
Inmonモデルにはいくつかの重要なメリットがあります。
- データウェアハウスがすべてのビジネスデータの中央リポジトリとして機能するため、データは一貫性を保ちます。
- 「データウェアハウス第一主義」のため、データの信頼性に非常に優れています。
Ralph Kimballのボトムアップアプローチ
Ralph Kimballは、データモデリングのために逆の方法論を取っています。ここでは、ボトムアップのアプローチが採用され、ほとんどの場合、「スタースキーマ」または(少しだけ改修された)「スノーフレークスキーマ」として定義されます。Kimballのアプローチでは、データマートが最初に構築され、データウェアハウスは "すべてのデータマートの集合体 "として定義されます。
ボトムアップアプローチは、次のモデルに従います - データマート > ETL > データウェアハウス > OLAPキューブ > インターフェース
Kimballモデルのメリットはたくさんあります。
- データマートはデータウェアハウスと別々に管理されていないため、構築が容易で、多くの主要なBIツールとの自然に統合することが可能です。
- アナリティクスは、最初にデータウェアハウスを経由せずに、データマート内のデータに直接アクセスすることができます。
- Kimballのモデルは、構築コストが安く、すぐにスケールすることができます(つまり、小規模で安く始められ、ビジネスのニーズに合わせてゆっくりとスケールアップが可能)。
データマートとETL
ETLツールはデータウェアハウスを動かす燃料であるため、ETLとデータマートの役割を理解することは非常に重要です。データマートはデータウェアハウスのスライスであることを忘れないでください。Kimballのボトムアップ・モデリングを使用してウェアハウスを構築する場合、データマートに対して直接 ETL ロードを実行することになります。そこで、データマートからデータウェアハウスにデータパイプラインを構築します。
Inmonのトップダウンアプローチを使えば、データウェアハウスにデータマートへデータを投入するためのETLを実行します。つまり、ETLの負荷はデータウェアハウスやデータレイクに対して直接実行されます。
理想的には、これらのワークフローの両方をサポートできるETLツールを選択する必要があります。Integrate.ioはパイプラインのセットアップが簡単で、すべての主要なBIツールとの迅速な統合が可能です。さらに、ETLのデータマートとデータウェアハウスの両方のレベルにおいて完全に動作します。
データマートの構造: トップダウン?それともボトムアップアプローチ?
すべてに言えることですが、それはあなたのニーズに依存します。どちらのアプローチにも長所と短所があります。ボトムアップのアプローチは、迅速な実装に最適です。ニーズの進化に合わせてスケールアップすることができます。トップダウンのアプローチは、今後構築していくための強固な基盤を与えてくれます。しかし、オンプレミスのデータウェアハウスを構築するにはコストがかかります。
この議論にクラウドが入ってくることで、トップダウンのアプローチに軍配が傾きます。最新のクラウドベースのデータウェアハウスソリューション(RedshiftやBigQueryなど)を利用することで、企業はオンプレミスのウェアハウスのような莫大なコストをかけずに、集約されたデータリポジトリを持つことができます。そのほとんどが従量制の価格設定になっており、簡単に拡張できるようになっています。そして、これらのデータウェアハウスソリューションの多くは、上述の2つのアプローチとは大きく異なる複雑なデータモデリングを持っています。 例えば、RedshiftやSnowflakeは、独自の非常に複雑なデータモデリングを持っており、分析用データを整理するのに非常に効率的です。
クラウドの登場により、独立型データマートのトレンドは衰退傾向にあります。その代わりに、企業は従属型データマートやハイブリッドデータマートを選択するケースが増えています。ストレージと計算能力が大規模に利用できるようになったことで、一時的もしくは長期間有効なデータクラスタの作成も容易になりました。
Integrate.ioでデータ統合が簡単に
データマートは、パフォーマンスを向上させるために、データウェアハウスを非常に利用しやすいブロックにセグメント化するのに役立ちます。クラウドを利用してデータウェアハウスを構築・維持する場合、データ統合は良好なデータマネジメントのための重要な鍵です。Integrate.ioの自動ETLプラットフォームは、データをデータマートに取り込むためのローコードソリューションを提供しています。クラウドベースのプラットフォームは、視覚的なインターフェースを持ち、一般的に人気のあるデータベースやウェアハウスのほとんどと統合されています。 Integrate.ioがあなたのビッグデータ管理をより効率的にするためにどのように役立つかを理解するのに、ぜひオンライン相談をお申し込みください。