データウェアハウス

データウェアハウスとは、組織の運用システムから収集したデータを、トランザクション処理ではなく分析を目的とした構造に統合する中央リポジトリです。データはソースシステムから抽出され、一貫性のある形式と定義に変換された後、ウェアハウスにロードされます。ウェアハウスでは、データを生成したシステムに影響を与えることなく、ソースを横断してクエリを実行できます。

このソリューションが解決しようとしている問題は、情報の断片化です。組織の情報は通常、コマースプラットフォーム、顧客関係管理システム、財務パッケージ、マーケティングツール、サポートソフトウェア、そして複数のスプレッドシートに分散しており、それぞれに独自の定義、識別子、履歴が存在します。これらのうち複数にまたがる質問には、手動での照合なしには答えることができません。そのため、数分で済むはずの分析に数日かかったり、同じ指標に対して異なる部門が異なる数値を算出したりするのです。

分析ワークロードと運用ワークロードを分離することが2つ目の理由であり、これは好みというよりは実務上の必要性です。本番データベースに対して複雑な分析クエリを実行すると、顧客や従業員が依存するシステムのパフォーマンスが低下します。また、運用スキーマはトランザクションの記録に最適化されており、トランザクションを集計することには適していません。データウェアハウスを使用することで、運用リスクを負うことなく、制約のない分析が可能になります。

データレイクとの違いは、構造とタイミングにあります。データウェアハウスは、ロード前にスキーマと変換を適用することで、一貫性がありクエリ可能なデータを生成しますが、事前の設計作業が必要となり、柔軟性が低下します。一方、データレイクは生データを元の形式で保存し、読み取り時に構造を適用します。これにより、柔軟性と詳細さが維持されますが、解釈の負担はすべての利用者に課せられます。最新のアーキテクチャでは、生データを保存し、その上にモデル化されたレイヤーを構築するなど、両者を組み合わせるケースが増えています。

モデリングこそが​​、価値の大部分と難しさの大部分を占める部分です。ビジネスエンティティの定義方法、メジャーの計算方法、緩やかに変化する属性の処理方法、そしてソースの調整方法を決定することで、組織自身の自己認識が明確になります。こうした作業を行わずにソースシステムの構造を複製したデータウェアハウスは、断片化を単に別の場所に移動させるだけであり、クエリ実行時に調整の問題が再び発生します。

定義のガバナンスは、技術よりも重要です。収益計算方法が3つ、あるいはアクティブ顧客の定義が2つも存在するデータウェアハウスは、以前のシステムよりも効率的に意見の相違を生み出します。定義を合意し、文書化し、それぞれを一度だけ実装し、レポートが合意されたバージョンを使用するようにすることで、単一の情報源を理想ではなく現実のものにすることができます。

更新頻度は、デフォルト設定で決定され、後々後悔することが多い設計上の決定事項です。データの継続的な読み込みは技術的には可能ですが、ほとんどのビジネス上の意思決定は日単位または週単位で行われるため、必要となることは稀です。また、ほぼリアルタイムでの処理には多大なコストがかかります。更新頻度を、理論上の最新性ではなく、実際のデータ利用状況に合わせることで、誰も活用しない最新データに無駄なコストをかけることを避けることができます。

クラウドプラットフォームの登場により、コストは消滅したのではなく、その形態が変化した。ストレージは安価になり、コンピューティングは使用量に応じて課金されるため、多額の初期投資は不要となり、クエリ量に応じて変動するコスト体系が導入された。しかし、不適切なクエリ、不必要な更新頻度、ビューごとに大規模な集計を再計算するダッシュボードなどは、クラウドの経済性が一律に安価になると考えていた組織にとって、予想外の高額請求につながる可能性がある。

この作業はエンジニアリング、モデリング、定義に関する組織的合意にまたがるため、技術面よりも最後の部分で失敗することが多い。実際には、モデリングと定義のガバナンスは データ分析パイプラインとインフラストラクチャ 製品開発 または IT部門そして、その範囲は通常、すべてを統合しようという野心ではなく、組織が実際に下さなければならない決定によって設定されるのが最善である。