最新のデータウェアハウスを設計するためのアナリストガイド

そのため、会社のデータウェアハウスを構築するように求められます。 効率的でスケーラブルで信頼性の高いデータウェアハウス。 あなたの会社が真剣にあなたのビジネスのための重要な戦略的資産としてデータレポートを実装することに着手している場合は、データウェアハウスを構築することは、最終的に会話の中に出てくるでしょう。しかし、データウェアハウスを構築することは容易でも些細なことでもありません。 データウェアハウスプロジェクトの50％以上が受け入れが制限されているか、完全に失敗します。

データウェアハウスの設計と構築をどのように開始する必要がありますか？ 落とし穴は何であり、どのようにそれを最適化する必要がありますか？ 最も重要なのは、私はどこから始めるべきですか？この記事では、いくつかの一般的な落とし穴を避けるためにデータウェアハウスを設定する方法についての高レベルのガイドを提供します。

データウェアハウスとは何ですか？現代のビジネスでは、通常、データは別の場所（データソース）に格納されています。 これは、次のデータにすることができます。

• アプリケーションデータベース：スタートアップにとって、これはおそらく彼らのコア製品アプリケーションです。 他のビジネスのために、それは販売アプリケーションの彼らのポイントすることができます、
• Webアプリケーション：これは、ビジネスを拡張したり、ビジネ 例としては、Mailchimpのような電子メールマーケティングソフトウェア、Google AnalyticsやMixpanelのようなweb分析アプリケーション、XeroやQuickbooksのような会計ソフトウェアなどがあります。
• スプレッドシート：これは、デスクトップスプレッドシート（Excel、CSV）またはGoogleスプレッドシートなどのオンラインスプレッドシートの形にすることができます。 これらのデータは、誰かによって手動で更新されたり、Zapierアクティビティによって更新されたりすることがあります。

データウェアハウスは、すべてのデータレポートのニーズのための単一の場所に異なるソースからのデータを同期します。

信頼できるデータを提供し、社内のすべての従業員からのクエリワークロードを処理できます。

データウェアハウスの設計

また読む：いつデータウェアハウスを取得する必要がありますか？

典型的なデータウェアハウスの設定は次のようになります。

レポート要件に基づいてデータウェアハウスを設計および構築します。 必要なデータを特定したら、データウェアハウスに情報を流すようにデータを設計します。

各データソースのスキーマを作成する

データベースに同期する各データソースのデータベーススキーマを作成します。 この

1. は、各テーブルの由来となるデータソースをすばやく識別するのに役立ち、データソースの数が増えるにつれて役立ちます。 また、将来のデータアナリストや企業に入社するビジネスチームメンバーは、各データソースの内容をすばやく知ることができます。
2. データソースごとに特定のアクセス許可(読み取り/書き込み)を割り当てることができます。 たとえば、データエンジニアは、ジュニアアナリストが読み取りのみを許可し、特定のスキーマには書き込みを許可したくない場合があります。これは、時間の経過とともにデータソースの数が増加する場合に特に役立ちます。 データが含まれている可能性のあるソースの数を見てください。

   たとえば、mailchimpxerofbadsというスキーマを設定して、これらのアプリケーションから倉庫にインポートしたい電子メールマーケティング、財務、広告データをそれぞれ設定できます。

   Mailchimpからデータベースにcontactsテーブルをインポートすると、
   次のようにクエリできます:

   SELECT name, email FROM mailchimp.contacts

   スキーマを作成する方法

   スキーマを作成するのは簡単です。 新しいスキーマを作成するには、行を入力するだけです。 実際、Postgresでは3つの単語しかありません。

   CREATE SCHEMA 

   例:

   CREATE SCHEMA mailchimp

   注1:新しいアナリストは、データベーススキーマの間で混乱する可能性があります。 スキーマ定義は2つあります。 スキーマは、データベース内のテーブルとフィールドがどのように相互に関連しているかを記述するために使用することができます。

3. データベーステーブルのフ: mySQLデータベースはスキーマをサポートしていないため、mailchimp_contactsなどのように、インポートするテーブルに名前を付けるために命名規則を使用することができます。 これが、お客様にレポートデータベースにPostgreSQLを使用することをお勧めする理由の一つです。
   

   ソースデータをデータウェアハウスに移動する

   次のステップは、ソースデータをデータウェアハウスに同期することです。 エンジニアはこれをETLスクリプトとして知っているかもしれません。

   次の考慮事項を使用してインポートスクリプトを設計します。

   1. 明らかに不要な列を削除します。 あなたがそれらを必要とすることを認識した場合、後でそれらを追加することはそれほど難しいことではありません。
   2. 列名の名前を変更して、よりわかりやすくしたり、データベースをわかりやすくしたりします（小文字やキャメルケースを使用するなど）。
   3. 明らかに不要なレコードを除外します。 これは、運用システム上の内部ユーザーテストを記録することができます（ユーザーが次のようなデータを追加することがあります[email protected] または最初の名前をtestsとして設定する）
   4. レコード値をマップして読みやすくします。 これにより、後でCASE-IFsを使用してレポート中にアナリストの名前を変更する手間が省けます）。 たとえば、一部のレコードには、数値キー（1,2,3、99など）や、組織の残りの部分には知られていない可能性のある省略名が格納されている場合があります。 そのような場合は、インポート処理中にこれらのキーを実際の値にマップすることができます。
   5. インポートが完了した後、データベースインデックスを宛先テーブルに適用します。 注以前の記事では、データベースインデックスについて書いています。
   6. エラー処理：セットアップメール//ジョブが失敗したときに詳細なエラーログと関連する利害関係者（特にデータアナリスト）に送信されるSlackアラートメッセージ。 この場合の誤検知の数を減らすために、特定の期間内に自動再試行（または自動復旧プロセス）を設定することができます。

   ソース（生）データを変換する必要がありますか？よく聞かれる質問の1つは、データを倉庫に移動する前にデータ変換を適用する方法です。私たちの一般的なアドバイスはそれを行うことではありません。

   少なくとも最初はそうではありません。 特にこれが最初のデータウェアハウスプロジェクトの場合。 これにはいくつかの理由があります。

   a. データ変換のニーズに明確な要件がある可能性は低いです

   “明確な要件”が与えられていても、この要件はプロジェクトの過程で変更されるか、古くな

   異なる利害関係者が異なる時点で何を望んでいるかに基づいてETLスクリプトを改訂する時間を費やすことは望ましくありません。

   (変換されていない)ソースデータを移動すると、ETLスクリプトの依存関係を”ビジネス要件”から分離するのに役立ちます。

   b. 他のケースではソースデータが必要になる可能性があります

   ソースデータを、異なる次元に沿って集計するか、他のソースのテーブルと結合することで、複数の派生テーブルに派生させることができる相互作用のベースとして考えてください。

   売り手のコンバージョンの有効性を追跡する方法については、以下の例を参照してください。

   データを変換すると、将来のレポートのユースケースに必要となる可能性のあるソースデータの詳細が失われます。

   たとえば、期間別に売上高を集計すると、別のユーザーが他のレポートと関連付ける必要がある特定のトランザクションレコードの詳細が失われます。

   変換されていないソースデータを移動すると、他のデータソースと柔軟に組み合わせることができます。

   さまざまな質問に答えるために再利用可能なデータモデルの構築を検討し始めると、ソースデータの必要性がより重要になります。 コホートレポートは、変換後の一連のデータを使用して構築されている上で、以下の例を参照してください。 あなたが持っていない場合、これはより困難になります

   c. ソースシステムの負荷を減らす

   ソースシステムでデータ変換を実行すると、特に世界中の顧客にサービスを提供するデータベースがある場合、かなりのリソー

   移動する前に、長時間実行されるデータ変換ジョブでオーバーロードする必要はありません。

   データを移動する前にデータを変換することは理にかなっているケースがいくつかありますが、これらのケースは通常、信頼性の高いデータウェアハウスを既に設定しており、それをさらに改善しようとしている企業向けのものです。

   特定の問題を解決するためにデータを変換する

   データを変換する方法について考えることは複雑になる可能性があります。 チェックを外したままにすると、ビジネスに価値を提供しないデータの最適化に多くの時間を費やすことになる可能性があります。

   明確な結果なしにデータ変換を計画、設計、実装することは、問題を探す解決策です。経験則の1つは、終わりを念頭に置いて開始することです。

   データ変換は、レポートの実用的なユースケースまたは問題に対処するためにのみ作成する必要があります。

   これらの実用的なユースケースを見つける（そして優先順位を付ける）良い方法は、インポートしたデータを使用してレポートとダッシュボードの構築を開始す

   ユーザーがクエリのパフォーマンスの問題を発生させ始めたら、データの変換を調べることができます。これは、
   (a)にネストされたサブクエリまたはカスタムテーブル式(Cte)

   (b)が含まれているか、複数のテーブルに複数の(高価な)結合があるレポートが原因で

   ここでは、SQLベースのレポートの柔軟性が、データ変換が対処できる問題を特定するのに役立ちます。

   どのアナリストも、実行時間の長いクエリでレポートの根本原因を迅速に特定し、パフォーマンスを最適化するために開始するのは簡単です。

   これは主に、データを自動的に事前に集計することによって行われます。 これはマテリアライズドビューで行うことができ、次のいずれかのデータ変換ジョブを作成できます。

   1. 大きなトランザクションテーブルを集計してクエ
   2. 異なるデータソースからの列を持つ派生テーブルを作成します
   3. 選択したユーザーグループの機密データを置換/マスクします。別の推奨事項は、変換された（または後処理された）テーブルを格納するために、データウェアハウスに新しいデータベーススキーマを作成することです。

      各データソースをスキーマで分離する以前のアプローチと同様に、特定のスキーマを作成すると、派生/変換されたデータテーブルのリストを識別するのに役立ち これは、データの成熟度が高まるにつれて、一連のデータインポート、データ変換ジョブを順番に文字列化し始めるときに後で役立ちます。

      内部データドキュメントを作成する

      特に、データウェアハウスを少数のエンジニアしか使用方法を理解していないブラックボックスにしたくない場合は、これが重要です。 あなたのユーザーがそれを理解していない場合、彼らはそれを照会する自信がありません。

      ソースデータ内の

      • テーブルと列、およびそれらの解釈方法を説明する共有ドキュメント（Google Doc）を作成することから始めることができます
      • データダイアグラムがある場合は、データダイアグラムが含まれています。
      • レポート内の列（ダッシュボード、メトリック）とその背後にある基礎となる前提を読み取る方法

      レポートが作成（または更新）されるたびに、このドキこの内部データドキュメントを作成および構造化する方法の詳細については、別の投稿で共有するので、このスペースに注意してください！

      これで終わりです！

      このガイドが参考になったことを願っています！ 信頼性の高いデータウェアハウスを構築するために、お客様の旅をどのように支援できるかをお知らせください。