データウェアハウスの構築に失敗しないための完全ガイド

データウェアハウスの構築は、アナリティクスの中でも最も厄介な仕事の一つです。しかし、適切なツールと適切な計画を立てれば、すべてのデータを簡単に1つの場所にまとめることができます。このブログでは、その方法についてご紹介します。

なぜデータウェアハウスを構築するのか？

データウェアハウスとは、複数のシステムから統合されたデータを保存する集中型リポジトリのことです。

一般的なビジネスでは、複数のミッションクリティカルなシステムが存在します。CRM、ERP、Eコマースシステム、マーケティングオートメーションプラットフォームなどが挙げられます。これらのシステムはすべて、重要なデータを保持するリレーショナルデータベース上で動作しています。

ETLを利用したデータパイプラインを設定することで、これらの情報をすべて統合することができます。このパイプラインは、重要なシステムからデータを抽出し、統合とクレンジングを行い、1つの大きなリレーショナル・データベースであるデータウェアハウスにすべて保存します。

データウェアハウスの実装は、データが特定のボリュームに達したときだけ考える必要があるものだと誤解されています。中小企業がこのステップを開発の後半まで後回しにしているのは、集中型リポジトリの価値がわからないからです。

ほとんどの企業は最初からデータリポジトリを必要としていますが、その理由は分析です。データウェアハウスは、複数のシステムからデータを統合する最も迅速で信頼性の高い方法の1つであり、分析チームに顧客と業務の360°ビューを提供します。

システム統合や災害復旧のための安全なバックアップなど、集中型リポジトリを検討する理由は他にもあります。また、適切なデータウェアハウスの導入計画があれば、始めるのは簡単です。

データウェアハウス構築のための８つのステップ

データウェアハウスの必要性を確認したら、プランニングに着手しましょう。データウェアハウスを構築するには、以下の手順に従ってください。

1) 関係者から要件を収集する

このような全社的なデータプロジェクトでは、複数の利害関係者が関与することになります。あなたは以下のような人と話をする必要があります。

意思決定者：リーダーや戦略担当者、さらには社内のCレベルにまで話を聞く必要があります。彼らは、あなたが会社の戦略的目標に沿って行動できるように支援してくれます。
ITチーム： ITチームは、データ・パイプラインへのソースの接続など、データ・プロジェクトにおいて実践的な役割を果たします。また、エラーが発生した場合にも対応し、オンプレミス・ソリューションを使用する場合には、ウェアハウスをサポートしなければならないこともあります。
アナリティクスチーム：データチームは、プロジェクトのスコープアウトを支援します。プロジェクトの成果を定義し、必要なデータソースを特定するのを支援します。
セキュリティとコンプライアンスチーム：データウェアハウスは、機密情報の取り扱いを伴うことがあります。ルールに違反していないか、追加のリスクを生じさせていないかを確認する必要があります。

全員の同意が得られれば、データウェアハウスの導入を開始する準備が整います。

2) ウェアハウス環境を作成する

この段階では、次のようなウェアハウス環境のためのいくつかのオプションがあります。

オンプレミス：ローカルハードウェア上のホスト
パブリッククラウド：AWSやAzureなどのホスト型クラウドソリューションを利用する
プライベートクラウド：自社のハードウェアでクラウドをホストするか、信頼できるサードパーティに依頼するか
ハイブリッドクラウド：オンプレミスとクラウドストレージを混在させるか、オンプレミスでデータを保存し、処理や分析にクラウド機能を利用するかのどちらか

パブリッククラウドは、ホストがハードワークのほとんどを代行してくれるため、最も安価で簡単なオプションであることが多いでしょう。しかし、レイテンシーやセキュリティの問題があるため、オンプレミスやハイブリッドのオプションを検討する必要があるかもしれません。

どちらを選択するにしても、3つの異なる環境を作成する必要があります。

開発環境：開発：開発チームはこの環境で新機能や新しい統合をテストします。この環境にはテストデータが保存され、機密情報は難読化されています。
テスト環境：開発環境と同じですが、このウェアハウスはテストとQAのためのものです。
本番環境：これはライブデータウェアハウスで、ユーザーとアナリティクスチームがアクセスします。他の環境で変更をテストしない限り、ここに変更を加えることはできません。

必要に応じて、3つ以上の環境を作成することができます。例えば、テスト用とQA用に別々のウェアハウスが必要になるかもしれません。しかし、開発チームは本番データで新機能を試すことができないため、少なくとも3つは必要になるでしょう。

3) データモデルを選択する

データモデリングは、おそらくデータウェアハウスの実装で最も難しい部分です。すべてのソースデータベースは独自のスキーマを持っています。ウェアハウスは単一のスキーマを持つことになり、すべての入力データはこのスキーマに適合しなければなりません。そのため、既存のすべてのデータに適合し、将来に向けてスケールアップできるモデルが必要です。

スキーマの主な種類には以下のようなものがあります。

スタースキーマ：リンクされた次元テーブルを持つファクトテーブル。
スノーフレークスキーマ：次元テーブルの追加レベルを追加することで、スタースキーマを強化します。
Galaxyスキーマ：共通の次元テーブルで接続された複数のファクトテーブル
Constellationスキーマ：次元テーブルの追加階層を持つGalaxyスキーマ

ゼロからスキーマを設計するのは、一般的にデータサイエンティストの仕事です。多くのクラウドや商用のオンプレミスシステムでは、ニーズに合わせてスキーマモデルを採用するのを支援してくれます。

4) データソースに接続する

接続は2つのステップで行われます。まず、ターゲットソースからデータを抽出し、データウェアハウスにアップロードします。

データ抽出は、次のようないくつかの方法で行うことができます。

APIコール：最も一般的な方法で、これはセキュアなインターフェイスによって処理されるトランザクションです。
ファイル転送：レガシーシステムでは、データをファイル（通常はCSV）としてエクスポートすることができます。
SQLクエリ：いくつかのインスタンスでは、SQLクエリを使用してデータベースの結果を取得することができます。

データを取得したら、データウェアハウスにロードする必要があります。

このタスクが複雑なため、ほとんどの人は自動化されたETL(Extract, Transform, Load)に頼ることでデータプロセス全体を処理しています。Integrate.ioには、ターゲットから自動的に抽出し、デスティネーションにロードするための統合ライブラリが備わっています。

このようにデータを移動するための自動化されたプロセスがある場合、それはデータパイプラインとして知られています。

5) データの変換

ETLには、抽出とロードの間に重要なステップがあります。変換は、ETLプロセスがデータを元のスキーマから変換先のスキーマに変換する中間段階です。変換を行わなければ、データを変換先のテーブルに入れることはできません。

変換には、以下のような他のステップも含まれます。

バリデーション：日付が有効であることや、郵便番号が住所と一致していることなど、すべてのデータが論理的な制約の範囲内に収まっていることを確認します。
クレンジング：破損したデータや重複したデータを削除します。あるいは、データをそのままにしておきますが、潜在的な問題を指摘します。
ハーモナイゼーション：気温を華氏に変換したり、すべての日付フォーマットをMM/DDに変更するなど、すべてのデータを単一のフォーマットに統一します。
エンリッチメント：データの品質を向上させるために、他のソースからのデータとレコードを結合します。

Integrate.ioのようなツールを使えば、コーディングなしでスキーママッピングを作成することができます。また、バリデーション、クレンジング、およびその他のデータハイジーンタスクのためのルールを設定することもできます。

6) データマートを作成する

データウェアハウスはすべてを保存しますが、ほとんどの人はすべてにアクセスする必要はありません。営業チームは営業数値を、オペレーションチームはオペレーションデータを必要としています。

この解決策は？データマートです。マートはウェアハウス内の論理的な領域であり、関連する結果のみを表示する限定されたビューです。

これを適切なメタデータで管理することができます。例えば、いくつかのレコードに「売上」とタグを付け、他のレコードに「財務」とタグを付けることができます。マートは、一致するタグごとにレコードを表示することができます。売上請求書のように、両方のチームに関連するレコードは、両方のタグを持つことができます。そうすると、両方のデータマートに表示されます。

マートは、ターゲットを絞った結果を提供する優れた方法です。また、関連データの閲覧を制限することができるため、データセキュリティを向上させるための優れた方法でもあります。

7) BI と Analyticsを構築する

ほとんどの市販のビジネスインテリジェンス（BI）および分析ツールは、データウェアハウスとのシンプルな統合を提供しています。また、これらのツールをETLプラットフォームに直接接続することで、より高速なインサイトとビジュアライゼーションを提供することができます。

BIおよび分析ツールは、データウェアハウスに依存しています。

ボリューム：データ量が多いほど、アナリティクスのインサイトがより詳細になります。
速度：リアルタイムのダッシュボードには、高速のデータストリームが必要です。
信頼性：データは高品質で、現在の状態を正確に把握できるものでなければなりません。

もしデータウェアハウスの実装計画に従っていれば、分析チームが必要とするデータを提供できるはずです。

8) 監視とレビュー

データウェアハウスが運用可能になり、分析チームが必要なものを手に入れたら、データ品質を確保するための対策を講じ始めることができます。

これには、自動化されたデータ品質テストツールを使用して、ウェアハウスのコンテンツの品質を測定することが含まれます。また、元データとストアされたデータの間に明らかな不一致がないか確認するために、センスチェックを行うこともできます。

データウェアハウス構築の落とし穴

データウェアハウスの構築は大きなプロジェクトであり、うまくいかないこともあります。計画に従っていれば、何の問題もないはずです。しかし、注意すべき点がいくつかあります。

課題: セキュリティリスクの特定

解決策：セキュリティは継続的なプロセスです。フィールドを変換して機密データを削除、暗号化、またはマスクすることは、データ損失を防ぐための最初のステップです。コンプライアンスとセキュリティ慣習に注意を払うだけでなく、クラウド側で新たな脅威に対処するクラウドパートナーの選択にも注意を払う必要があります。

課題: 個人情報に起因するコンプライアンス違反

解決策：ETLは、機密データがウェアハウスに届けられる前にデータを難読化するのに役立ちます。コンプライアンスの問題を解決する必要があります。

課題: Analyticsを実施する際のデータ品質問題

解決策：まず、ソースをチェックして、データがソースの時点でクリーンであることを確認してください。もしそうであれば、問題はETLプロセスのどこかに起因する可能性が高いでしょう。

統合での設定に関する問題
トランスフォームが正しいフィールドをマッピングしていない
ウェアハウススキーマへのアップロードに問題がある

最後の問題は、ウェアハウスの構造を見直す必要があるかもしれません。

課題: Analyticsがアクションにつながるインサイトを生み出せない

解決策：こうした問題は通常、選択したデータソースが間違っていることを意味します。アナリティクスチームと話し合い、入ってくるデータを見直してみてください。場合によっては、さらに遡って新しいデータを取得する方法について検討する必要があるかもしれません。

データウェアハウスを次のレベルへ

多くの点で、データウェアハウスは通常のウェアハウスと似ていますが、どちらもプロセスに関係しています。

データウェアハウスは、最終的には単なる大きなリレーショナル・データベースです。それをエキサイティングなものにしているのは、それを維持するプロセスです。データをどのようにインジェストするか、どのようにデータを統合するか、そしてそのデータをどのようにBIや分析ツールに送り出すかです。

Integrate.ioは整合性のあるウェアハウスを構築するための完璧なプラットフォームです。今すぐオンラインデモを予約して、ノーコードETLがあなたのためにどう役立つかを確認してみてください。

データウェアハウス

データウェアハウスの構築に失敗しないための完全ガイド

なぜデータウェアハウスを構築するのか？