エンタープライズデータウェアハウス (EDW) は、組織全体のシステムから抽出された構造化された分析対応データの中央リポジトリです。2035 年までに 530 億ドルを超えると予測されており、成長を続ける EDW 市場は今後も定着するでしょう。しかし、EDW の価値は、それに供給されるデータによって決まります。クラウドインフラストラクチャー、モデリングツール、ビジネスインテリジェンス (BI) ダッシュボードに多額の投資をしたとしても、基盤となるデータが古かったり不完全だったりすると、ダウンストリームのすべての決定にその欠陥が引き継がれます。EDW の周囲に構築するアーキテクチャ、ガバナンス管理、データ移動レイヤーによって、ビジネスにとってのその価値が決まります。

以下では、エンタープライズデータウェアハウスとは何か、適切に構築されたデータウェアハウスを構成する要素、およびデータ移動を主要な関心事として捉える方法について説明します。

主なポイント

• 最新の EDW は、構造化された分析対応データの単一の管理されたリポジトリから、ビジネスインテリジェンス、財務レポート、機械学習のワークロードにサービスを提供します。

• ロールベースのアクセス、列レベルのマスキング、監査ログ、データリネージなどのガバナンス管理によって、チームがウェアハウスを信頼して使用するかが決まります。

• データ移動レイヤーは多くの EDW プロジェクトが失敗する原因となりますが、ネイティブのソースコネクターにより、継続的なメンテナンスの負担なしにパイプラインを稼働させることができます。

エンタープライズデータウェアハウスとは

エンタープライズデータウェアハウス (EDW) は、ビジネスインテリジェンス、財務レポート、そしてますます増加する機械学習モデルの背後にある機能ストアやトレーニングデータセットを支える一元化されたデータリポジトリです。

当初、EDW はレポート作成のために構築されていました。現在では、人工知能 (AI) システムが依存する管理された基盤となっており、データの品質、一貫性、鮮度に対する基準が高まっています。

エンタープライズデータウェアハウスの仕組み

大まかに言えば、EDW はビジネス全体からデータを取り込み、標準化して、使用できるようにします。このプロセスは通常、3 つの段階に分かれています。

これがエンタープライズデータウェアハウスの仕組みです。

取り込み

決済プラットフォーム、顧客関係管理 (CRM) システム、企業資源計画 (ERP) システム、プロダクトデータベースなどのソースシステムから単一のレイヤーにデータが流れます。この時点ではまだ生の状態であり、スキーマは異なり、タイムスタンプは競合する可能性があり、欠損値に一貫性がありません。

モデル

ここで生データが有用になります。チームは変換ツール (一般的には dbt) を使用して、生データをクリーンアップ、結合、再形成し、信頼性の高いデータセットにします。

一般的な 2 つのモデリングアプローチは以下のとおりです。

• スタースキーマ: ディメンションテーブル (顧客、製品、日付など) に接続された中心的なファクトテーブル (注文など)。シンプルでクエリが高速であり、レポート作成に広く使用されています。

• スノーフレークスキーマ: スタースキーマをさらに正規化したもので、ディメンションがより小さな関連テーブルに分割されています。冗長性は減りますが、クエリが複雑になる可能性があります。

提供

クリーンアップされ、モデル化されたデータは、ダウンストリームのユーザーが利用できるようになります。アナリストは構造化クエリ言語 (SQL) を使用してデータをクエリし、ダッシュボードは自動的に更新され、ビジネスチームは一貫した指標を信頼します。

最新のエンタープライズデータウェアハウスはどのようなアーキテクチャで稼働していますか

最新の EDW のほとんどはクラウドベースであり、コンピューティングとストレージの分離という中心的な原則に基づいて構築されています。これにより、チームはデータ量とは無関係に処理能力を拡張できます。

もう 1 つの大きな変化は、抽出、変換、ロード (ETL) から抽出、ロード、変換 (ELT) への移行です。ELT では、データをロードする前に変換するのではなく、まず生データをウェアハウスにロードし、そこで SQL を使用して変換します。これにより、ビジネスニーズの変化に合わせてパイプラインを容易に適応させることができます。

適切に設計された EDW には、いくつかの共通点もあります。

• 並行処理のための分離されたコンピューティング: 財務レポートからデータサイエンスまで、さまざまなワークロードがリソースを競合することなく同時に実行されます。

• 階層化されたデータアーキテクチャ: 生データ、中間変換、本番環境対応モデルが明確に分離されているため、トレーサビリティが確保され、デバッグが容易になります。

• 複数のユースケースのサポート: 1 つのプラットフォームで、BI、分析、機械学習、ビジネスの各ユースケースに重複なく対応できます。

エンタープライズデータウェアハウスの信頼性を高める要素

EDW は信頼されて初めて価値を持ちます。ガバナンスとセキュリティの管理により、指標をめぐる論争を防ぎ、コンプライアンスリスクを軽減し、機密データが悪用されるのを防ぐことができます。

ガバナンスとセキュリティの管理によってエンタープライズデータウェアハウスを企業向けにする方法は以下のとおりです。

• ロールベースのアクセス制御 (RBAC): 権限は役割ごとに割り当てられるため、ユーザーは必要なデータのみを見ることができます。

• 列レベルのマスキング: 納税者番号、給与額、機密の顧客データなどの機密フィールドは、ユーザーのアクセス権限に基づいて非表示になるか、トークン化されます。

• 監査ログ: すべてのクエリを追跡できます。これは、(データタイプに応じた Service Organization Control 2 や PCI DSS などの) コンプライアンスにおいて重要です。指標に疑問が生じた場合、監査ログを使用して、レポートの作成に使用されたデータの正確なバージョンを追跡できます。

• データリネージ: 用語から任意の指標をそのソースまでさかのぼることができるため、デバッグがはるかに効率的になります。

• 一貫した指標の定義: 共有のセマンティックレイヤーにより、異なるチームが同じ指標を異なる方法で計算するのを防ぎます。

モダナイゼーションの前にエンタープライズデータウェアハウスの準備状況を監査する方法

多くの EDW モダナイゼーションプロジェクトは、現状を把握しないまま性急に進められるために失敗に終わります。構造化された監査を行うことで、このような事態を回避できます。

注目すべきポイントは以下の通りです。

• データソースと所有者の棚卸し: 現在のウェアハウスや手動レポートにデータを供給しているすべてのシステム、その所有者、信頼性を特定します。

• 現在の障害の特定: 手作業によるワークロード、脆弱なパイプライン、繰り返し発生する障害を確認します。

• データの品質とリネージの評価: 重複レコード、欠落している外部キー (他のテーブルの列にリンクされているデータベース列)、形式に一貫性のないフィールド、文書化されていない SQL スクリプト内にのみ存在する変換や、システム内ではなく担当者の頭の中だけにある変換がないかを確認します。

• プラットフォーム要件の確認: 必要なクエリの同時実行数、予想されるデータ量、リアルタイムまたはほぼリアルタイムの更新が必要かどうかを明確にします。

• 影響の大きい出発点の優先順位付け: ビジネス価値が最も高く、ソースデータが最もクリーンなレポート作成ワークフローを特定し、そこから優先的に構築します。

データ移動がエンタープライズデータウェアハウスの成否を分ける理由

データ移動は多くの場合、エンタープライズデータウェアハウスの成功を決定づけます。カスタムの ETL コネクターの構築は、予想以上に複雑で壊れやすいものです。データ移動レイヤーによって、EDW が実際に使用可能かどうかが決まります。

一般的な障害の原因は以下のとおりです。

• 事前の警告なしに連携を損なう API の変更

• 認証情報の期限切れと認証の更新

• ピーク時の予期しないレート制限

• 誰にも警告せずに失敗するパイプライン

これらの問題により、ダッシュボードに古いデータや不正確なデータが入力され、ビジネス全体の信頼が損なわれる可能性があります。

決済などの価値の高いデータソースであれば、その影響はさらに大きくなります。データに一貫性がないと、財務、業務、プロダクトの各チームに同時に影響を及ぼす可能性があります。

決済、サブスクリプション、返金、不審請求の申請、入金に Stripe を使用する組織にとって、Stripe は大量かつ高価値のデータソースとなることがよくあります。Stripe Data Pipeline は、ノーコードのコネクターとしてこれを直接処理します。

具体的な方法は以下の通りです。

• サポートされる送信先: Snowflake、Amazon Redshift、Databricks など。

• セキュリティ体制: Stripe Data Pipeline ではサードパーティの ETL サービスが不要なため、金融取引や顧客情報を含むデータが外部に公開されるリスクが軽減されます。

• メンテナンスの負担: 構築やメンテナンスが必要なカスタムコネクターはありません。Stripe の API が変更された場合、パイプラインの調整は Stripe 側で行われます。