データ ウェアハウスのデータ マートとは何ですか? 種類と例

⚡ スマートサマリー

データマート設計では、データウェアハウスの情報の中から特定の部門に特化したサブセットを提供し、3種類のデータマート、設計から管理までの5つのフェーズ、そして迅速、安全、かつ費用対効果の高い配信を実現するためのベストプラクティスについて解説します。

  • 🎯 定義: データマートとは、データウェアハウスの主題指向型サブセットであり、営業、マーケティング、人事、財務などの特定の部門向けに構築される。
  • 🧩 市場の種類: 依存型マートは中央倉庫から仕入れ、独立型マートは運用システムから直接仕入れ、ハイブリッド型マートは両方を組み合わせたものである。
  • ⚙️ 実装フェーズ: データマートの構築は、設計、構築、データ投入、アクセス、管理という段階を経て進められます。
  • 🔌 ETLとRDBMS: RDBMS はマートを保存し、ETL ツールはマッピングします。tractsは、ソースデータとメタデータを変換、クレンジング、ロードします。
  • 📊 次元設計: スター型スキーマに基づいてデータをモデリングすることで、クエリの速度が向上し、ビジネスユーザー向けのレポート作成が簡素化されます。
  • 💡 ビジネスへの影響: 規模が小さいということは、フルサイズの倉庫に比べて、クエリの速度が速く、コストが安く、アクセス制御が厳格で、配送が迅速になることを意味します。
  • 🧭 ベストプラクティス: 納品サイクルを数週間以内に抑え、ハードウェアとネットワークの予算を確保し、すべての関係者を早期に巻き込む。

データウェアハウス内のデータマート(依存型、独立型、ハイブリッド型データマートを示す)

データマートは、 データウェアハウス 単一のチームに特化することで、部門は企業全体のワークロードを待つことなく、自らのデータを迅速に分析できます。以下のセクションでは、データマートとは何か、組織がデータマートを使用する理由、利用可能な3つのタイプ、およびデータマートの実装と管理方法について説明します。

データマートとは?

データマートは組織の単一の機能領域に焦点を当てており、組織に格納されているデータのサブセットを含んでいます。 データウェアハウスこれはデータウェアハウスの簡略版であり、マーケティング、営業、人事、財務など、特定の部門、ユニット、またはユーザーグループによる使用を目的として設計されています。

データマートは単一の機能しか持たないため、通常は組織内の単一の部門によって管理されます。このように焦点を絞ることで、その範囲は限定され、所有権も明確になります。

データマートは、多数のデータソースを統合するデータウェアハウスとは異なり、少数のデータソースからのみデータを取得します。そのため、データマートは規模が小さく、フル機能のデータウェアハウスよりもはるかに柔軟性に優れています。

なぜデータマートが必要なのでしょうか?

組織がデータマートを利用する理由はいくつかある。

  • データマートは、ユーザーが照会するデータ量を削減することで、ユーザーの応答時間を改善します。
  • 頻繁に要求されるデータに簡単にアクセスできます。
  • データマートは、企業データウェアハウスよりも実装が簡単で費用も安価です。
  • 俊敏性に優れており、モデルが変更された場合でも、より小規模なデータマートを迅速に再構築できます。
  • データマートは単一の専門家によって定義されるのに対し、データウェアハウスは学際的なチームによって定義されるため、データマートの方が変更に対して柔軟である。
  • データはパーティション化されており、非常にきめ細かなアクセス制御権限が可能となっている。
  • データは分割して、異なるハードウェアまたはソフトウェアプラットフォームに保存することができる。

つまり、データマートはより小さく明確に定義されたデータを扱うため、エンタープライズデータウェアハウスよりも構築が迅速で、運用コストが安く、セキュリティも容易である。

ただし、データマートはすべて同じように構築されているわけではありません。マートがデータを取得するソースによって、扱う3つのタイプのうちどれになるかが決まります。

データマートの種類

データマートには、データの取得元によって大きく分けて3つの種類があります。

  1. 依存: 依存型データマートは、運用ソース、外部ソース、またはその両方から直接データを取得します。
  2. 独立した: 中央データウェアハウスなしで、独立したデータマートが構築されます。
  3. ハイブリッド: ハイブリッドデータマートは、データウェアハウスまたは運用システムからデータを取り込むことができます。

依存型データマート

依存型データマートは、組織のデータを単一のデータウェアハウスから取得するため、一元管理のメリットが得られます。1つ以上の物理データマートを構築する必要がある場合は、それらを依存型データマートとして構成します。

依存型データマートは、2つの方法で構築できます。1つは、ユーザーが必要に応じてデータマートとデータウェアハウスの両方にアクセスする方法、もう1つは、アクセスをデータマートのみに限定する方法です。後者の方法は最適ではありません。なぜなら、共通のソースから始まったものの、その後破棄され、ほとんど使用されなくなったデータ、いわゆる「データジャンクヤード」が発生する可能性があるからです。

単一のデータウェアハウスからデータを取得する依存データマート
依存型データマート

独立したデータマート

独立したデータマートは、中央データウェアハウスなしで構築されます。この種のデータマートは、組織内の小規模グループにとって理想的な選択肢です。

独立したデータマートは、エンタープライズデータウェアハウスや他のデータマートとは一切関係がありません。データは独立してロードされ、分析されます。このアプローチは、そもそもデータウェアハウスを構築する主な目的、つまり、さまざまな関心を持つ多くのユーザーが分析できる、一貫性のある一元化されたエンタープライズデータの保存場所という目的に反します。

中央データウェアハウスなしで作成された独立データマート

独立したデータマート

ハイブリッドデータマート

ハイブリッドデータマートは、データウェアハウス以外のソースからの入力を組み合わせます。これは、組織に新しいグループや製品が追加された後など、アドホックな統合が必要な場合に役立ちます。

ハイブリッドデータマートは、複数のデータベース環境に適しており、最小限のデータクレンジング作業で迅速な実装を実現します。また、大規模なストレージ構造にも対応し、小規模なデータ中心型アプリケーションにも適しています。

データウェアハウスと他のソースを組み合わせたハイブリッドデータマート

ハイブリッドデータマート

データマートの実装手順

データマートを実装するための5つのステップ

データマートの実装手順

データマートの実装は、やりがいのある作業ではありますが、非常に詳細なプロセスです。設計、構築、データ投入、アクセス、管理という5つの段階を経て進められ、それぞれの段階については以下で説明します。

設計

設計はデータマート実装の最初の段階です。データマートの最初の要求から要件収集、そして論理的および物理的なデータマート設計に至るまでのすべてのタスクが含まれます。

設計ステップには次のタスクが含まれます。

  • ビジネス要件と技術要件を収集し、データソースを特定する。
  • データの適切なサブセットを選択します。
  • データ マートの論理的および物理的構造を設計します。

データは、以下の基準に基づいて分割できます。

  • 日付
  • 事業部門または機能部門
  • 地理
  • 上記の任意の組み合わせ

データはアプリケーションレベルまたはDBMSレベルでパーティショニングできますが、ビジネス環境の変化に応じて毎年異なるデータモデルを使用できるため、アプリケーションレベルでのパーティショニングが推奨されます。ほとんどのデータマートは、 次元モデルクエリを高速に保つために、スター型スキーマなどを使用します。

どのような製品や技術が必要ですか?

この段階では、ペンと紙があれば十分です。UML図やエンティティ関係図を作成するのに役立つツールを使えば、論理設計図や物理設計図にメタデータを追加することもできます。

構築

構築は実装の第2段階です。物理データベースと論理構造の作成が含まれます。

このステップには、以下の作業が含まれます。

  • 前の段階で設計した物理データベースを実装する。例えば、テーブル、インデックス、ビューなどのスキーマオブジェクトを作成する。

どのような製品や技術が必要ですか?

データマートを構築するには、リレーショナルデータベース管理システム(RDBMS)が必要です。RDBMSは、データマートの成功に不可欠ないくつかの機能を提供します。

  • ストレージ管理: RDBMSはデータを保存および管理し、レコードの作成、追加、削除を可能にします。
  • 高速データアクセス: SQLクエリを使用すると、特定の条件やフィルターに基づいてデータを簡単に取得できます。
  • データの保護: RDBMSは、停電などのシステム障害から復旧でき、ディスク障害が発生した場合はバックアップからデータを復元できる。
  • マルチユーザーのサポート: 同時アクセスが可能なので、複数のユーザーが互いの変更を上書きすることなく、データの読み取りと変更を行うことができます。
  • セキュリティ: これは、どのユーザーがどのオブジェクトにアクセスできるか、またどの操作を実行できるかを規定するものです。

実装する

第3段階では、データがデータマートに格納されます。

入力手順には次のタスクが含まれます。

  • 地図ping ソースデータからターゲットデータへ。
  • Extracソースデータを取得する。
  • データのクリーニングと変換。
  • データマートにデータをロードしています。
  • メタデータの作成と保存。

どのような製品や技術が必要ですか?

これらのタスクはETL(例:tracデータソースを調べ、ソースからターゲットへのマッピングを実行します。pingそして、tracts は、データを変換、クレンジングし、データマートにロードします。

その過程で、このツールはメタデータも生成します。メタデータとは、データの出所、データの最新性、行われた変更、適用された要約レベルなどの詳細情報です。

アクセスする

アクセスは4番目のステップであり、データの活用、つまりデータのクエリ、レポートやグラフの作成、そしてそれらの公開を行います。エンドユーザーはクエリを送信し、多くの場合、 OLAP ツール。

アクセス手順には、以下のタスクが含まれます。

  • データベースの構造やオブジェクト名をビジネス用語に変換するメタレイヤーを構築することで、技術的な知識のないユーザーでもデータマートに容易にアクセスできるようにする。
  • データベース構造の設定と維持管理。
  • 必要に応じてAPIとインターフェースを設定します。

どのような製品や技術が必要ですか?

データマートには、コマンドラインまたはGUIを使用してアクセスできます。GUIはグラフを簡単に生成でき、コマンドラインよりもユーザーフレンドリーであるため、通常はGUIが推奨されます。

管理する

管理は、データマート実装プロセスの最終段階です。チームは、GUIまたはコマンドラインを使用して、次のような継続的な管理タスクを処理します。

  • 継続的なユーザーアクセス管理。
  • パフォーマンス向上のためのシステム最適化と微調整。
  • データマートへの新規データの追加と管理。
  • システムに障害が発生した場合でもシステムが利用可能であり続けるよう、復旧シナリオを計画する。
  • ハードウェアおよびソフトウェアの障害からデータを保護しながら復旧する。

データマート実装のベストプラクティス

データマートの実装プロセス全体を通して、以下のベストプラクティスに従ってください。

  • データマートのソースを部門別に構造化する。
  • 導入サイクルは、月や年ではなく、週単位で計測する。
  • データマートの実装は複雑になる可能性があるため、計画および設計段階にはすべての関係者を参加させるようにしてください。
  • データマートのハードウェア、ソフトウェア、ネットワーク、および導入コストについて、正確な予算を立ててください。
  • データマートがハードウェアを共有している場合でも、ユーザーからのクエリを処理するには異なるソフトウェアが必要になる場合があります。高速な応答に必要な追加の処理能力とストレージを評価してください。
  • データマートがデータウェアハウスとは別の場所に設置されている場合は、必要なデータ量を移動するための十分なネットワーク容量を確保してください。
  • 変換処理の複雑さが増すにつれて、読み込み時間も長くなるため、その分の予算を確保しておいてください。

データマートの長所と短所

他のアーキテクチャの選択と同様に、データマートには明確な利点がある一方で、いくつかのトレードオフも存在する。

優位性

  • データマートは、組織全体のデータのうち、特定のユーザーグループにとって価値のあるサブセットを保持する。
  • これは、構築に費用がかかるデータウェアハウスに代わる、費用対効果の高い選択肢です。
  • データマートを利用することで、データへのアクセスが高速化されます。
  • 使いやすさが特長で、ユーザーの具体的なニーズに合わせて設計されているため、業務プロセスを加速させることができます。
  • データマートは、データウェアハウスよりも実装時間が短くて済みます。なぜなら、データの一部のみに焦点を当てるからです。
  • これには、アナリストが傾向を把握するのに役立つ過去のデータが含まれています。

デメリット

  • 企業は時として、互いに関連性のない、ばらばらのデータマートを過剰に作成してしまうことがあり、それらは維持管理が困難になる。
  • データマートはデータセットが限られているため、企業全体のデータ分析を提供することはできません。

よくあるご質問

A データウェアハウス データリポジトリは企業全体のあらゆる分野を網羅するリポジトリであるのに対し、データマートは特定の部門向けに、より小規模で分野別のデータセットを保持します。データマートは構築コストが安く、構築期間も短く、クエリ実行も迅速ですが、企業全体の分析を行うことはできません。

データマートは、特定の業務機能に合わせてモデル化された、構造化され処理済みのデータを格納する。データレイクは、構造化データ、半構造化データ、非構造化データなど、あらゆる種類の生データを大規模に格納する。データマートは迅速なレポート作成に役立ち、データレイクは探索的データサイエンスや機械学習をサポートする。

ほとんどのデータマートは 次元モデル一般的には、中心となるファクトテーブルとディメンションテーブルを結合したスター型スキーマが用いられます。スノーフレーク型スキーマは、これらのディメンションをさらに正規化します。どちらのスキーマも、クエリの高速化とビジネスユーザー向けのレポート作成の簡素化に貢献します。

営業データマートには、営業チーム向けの顧客取引、収益、パイプライン指標が格納されます。マーケティング、財務、人事のデータマートも同様に機能し、各部門は企業全体のデータウェアハウスにクエリを実行することなく、事前に集計されたデータにアクセスできます。

データマートは以下をサポートします OLAPOLTPではなく、トランザクションOLTPシステムが処理する高速な挿入や更新ではなく、レポートやダッシュボードのための履歴データの読み取り、集計、分析に最適化されています。

クラウドデータマートは、オンプレミスサーバーではなく、マネージド型のクラウドデータウェアハウスプラットフォーム上で稼働します。ハードウェア管理が不要になり、ストレージとコンピューティングリソースをオンデマンドで拡張でき、通常はクエリごとに課金されるため、コスト削減と導入スピードの向上につながります。

AIと機械学習ツールは、ソースデータのプロファイリング、スキーマとディメンションの推奨、ETLマップの生成などにより、データマートの作業を高速化します。pingデータ品質の問題を指摘するだけでなく、パーティショニングやインデックス作成の戦略も提案しています。ただし、エンジニアは本番環境に導入する前に、すべての推奨事項を精査する必要があります。

Yes. AI言語モデルを活用してコードのデバッグからデータの異常検出まで、 (NAIST) と GitHubコパイロット 短いプロンプトから、SQLクエリ、スター型スキーマのDDL、およびETLスクリプトのドラフトを作成します。 Rev生成されたコードにはビジネスルールが欠けている可能性があるため、実行する前に出力結果を確認し、テーブル名、結合、粒度が正しいことを確認してください。