51

ここで少し背景：

多かれ少なかれ、データウェアハウスが何であるかを知っています。データ ウェアハウジングに関するガイドを数十冊読み、SSAS で遊んでみました。スター スキーマとディメンション テーブルとファクト テーブルが何であるかを知っています。ETL とは何か、またその方法も知っています。 これは「方法」の質問でも、チュートリアルのリクエストでもありません。

私の問題は、私が読んだデータ ウェアハウスに関する資料のすべてが、データウェアハウスを構築する根拠を曖昧にしているように見えることです。それらはすべて比喩的に、または場合によっては文字通り「だからあなたはデータウェアハウスを構築することに決めました...」というフレーズで始まりますが、私はまだその決定を下していません。

だから私は、SO のメンバーが、ある種の半客観的なテストを私に指摘したり、考え出すのを手伝ってくれることを望んでいます. 特定のシステムに適応して、最終的に「はい、データ ウェアハウスが必要です」または「いいえ、今日の見返りは小さすぎる」という結果になるものです。私が答えることができるはずの具体的な質問は次のとおりだと思います。

  1. データ ウェアハウスの構築を検討する価値のあるオプションは、どの時点ですか? 言い換えれば、標準的なトランザクション環境がもはや十分ではないことを示している可能性がある兆候、メトリック、またはその他の基準を確認する必要がありますか?

  2. 完全なデータ ウェアハウスに代わるものは何ですか? トランザクション データベースの非正規化とボグ標準のレプリケートされた "レポート サーバー" の 2 つが思い浮かびます。DW にコミットする前に調査すべきものは他にありますか?

  3. データ ウェアハウスが上記の代替案よりも優れているのはなぜですか? 答えが「依存する」である場合、それは何に依存していますか?

  4. データ ウェアハウスの構築を試みてはいけないのはどのような場合ですか? コンテキストに関係なく、「ベストプラクティス」として宣言されているものには懐疑的です。確かに、DW が間違った選択であるシナリオがいくつかあるに違いありません。

  5. データ ウェアハウスの導入によって改善されたシステムの実際の例はありますか? 彼らがどのような決定や分析のために倉庫を必要としたか、倉庫に何を入れるかをどのように決定したか、倉庫が最終的により大きな環境にどのように適合したかをエンドツーエンドで説明してくれる何か? 「AdventureWorks データベースから立方体を作ろう」というわざとではありません。実装は私には関係ありません。仕様と設計、および関連する全体的な思考プロセスに興味があります。

私は通常、マルチパートに尋ねないようにしていますが、これらはすべて非常に密接に関連していると思います. 少なくとも最初の 4 つの質問に対応する回答であれば喜んで受け入れますが、最後の質問は私の頭の中でこれを具体化するのに本当に役立ちます。これについて誰かがすでに書いている場合は、リンクが適度に簡潔で具体的であれば問題ありません (Ralph Kimball のホームページへのリンク = 役に立ちません)。

質問が明確になったことを願っています-回答ありがとうございます！

4

7 に答える 7

46

ご質問に簡潔にお答えできるよう最善を尽くします。

1. データ ウェアハウスの構築を検討する価値があるのはどの時点ですか? 言い換えれば、標準的なトランザクション環境がもはや十分ではないことを示している可能性がある兆候、メトリック、またはその他の基準を確認する必要がありますか?

a. レポートと監視が実稼働システムやオフライン データ ストアのパフォーマンスを低下させていることがわかった場合。

b. ビジネス上の質問に対する答えを得るには、毎回複雑な SQL を大量に作成する必要がある場合。

c. トランザクション スキーマを変更するたびに、すべてのレポート クエリをやり直す必要があることがわかった場合。

d. 複数のソースからのデータをまとめたい場合。

2.完全なデータ ウェアハウスに代わるものは何ですか? トランザクション データベースの非正規化と、ボグ標準のレプリケートされた "レポート サーバー" の 2 つが思い浮かびます。DW にコミットする前に調査すべきものは他にありますか?

3.データ ウェアハウスが上記の代替案よりも優れているのはなぜですか? 答えが「依存する」である場合、それは何に依存していますか?

これらをまとめてお答えします。私は、データ ウェアハウスをオール オア ナッシングのベンチャーとは考えていません。これは単に、「ビジネス上の質問に、より簡単かつ迅速に回答できるようにデータを保存する」ことを意味する簡潔なフレーズです。

トランザクション データベースは、アプリケーションと効率的にやり取りするように設計されています。データ ウェアハウス、データ マート、オペレーショナル データ ストア、およびレポート テーブルは、人々と効率的にやり取りできるように構築されています。

4.データ ウェアハウスの構築を試みてはいけないのはどのような場合ですか? コンテキストに関係なく、「ベストプラクティス」として宣言されているものには懐疑的です。確かに、DW が間違った選択であるシナリオがいくつかあるに違いありません。

良い質問。取引システムがビジネスに関する十分な洞察を提供する場合、おそらく倉庫は必要ありません。

データ ソースが 1 つしかなく、パフォーマンスが問題にならない場合は、単純なレポート テーブルを作成することで洞察を得ることができます。

5.データウェアハウスを導入して改善されたシステムの実践例はありますか? 彼らがどのような決定や分析のために倉庫を必要としたか、倉庫に何を入れるかをどのように決定したか、そして倉庫が最終的により大きな環境にどのように適合したかをエンドツーエンドで説明してくれる何か? 「AdventureWorks データベースから立方体を作ろう」というわざとらしいことはしたくありません。実装は私には関係ありません。関連する仕様と設計、および全体的な思考プロセスに興味があります。

これは、ここで割り当てられているよりもはるかに多くのスペースを必要とする大きな問題です。

これについては、あなたが求める洞察を提供してくれるかもしれないいくつかの場所を紹介できます。

  • Bruce Ullrey による「データ ウェアハウスの実装: 効果的な方法論」は、ある人物がデータ ウェアハウスを構築するまでの道のりを記録した本です。高度に洗練されていないため、よりリアルになります。彼の努力をよく表しているモデルやその他のビジュアルがたくさん掲載された日記のように読めます。
  • Larissa Moss による「ビジネス インテリジェンス ロードマップ」。標準運賃。BI プラクティスを構築するプロセスの概要を説明します。
  • Steve Williams による「The Profit Impact of Business Intelligence」では、データ ウェアハウスの構築の価値を示す多くのケース スタディが紹介されています。
于 2010-01-02T21:33:06.493 に答える
6

  1. DWの主な目的は、レポートと分析を高速化（簡素化）することです。これにより、ビジネスユーザーが考えられるあらゆる方法でデータのスライスとダイシングが可能になります。

  2. 最初のステップのDWでは、Kimballスタースキーマを実装し、それに対してSQLクエリを実行するだけです。これがまだ遅すぎることが判明した場合は、事前に計算された集計（キューブ）について考え始めてください。

  3. DWに対する情報のスライスとダイシングは、正規化されたDBに対するよりもはるかに簡単です。複製されたレポートサーバーはパフォーマンスを向上させますが、スライスとダイシングを単純化することはありません。また、DWはビジネスユーザーのものであるため、いつでもさまざまなスライス/ダイスのアイデアを思いつくのはビジネスユーザーの責任であることに注意してください。IT担当者は、このようなことが可能な環境を提供するだけで済みます。

  4. 運用システムで時々いくつかのレポートを実行し、パフォーマンスに満足している場合は、DWは必要ありません。

  5. 私の経験はすべて、ビジネスユーザーがレポートの速度が遅く、「複雑なクエリ」を記述できないことについて際限なく不満を言う一方で、本番ユーザーはレポートが原因でデータベースが機能しなくなると不満を言うシステムでの経験です。すべての場合において、単純なキンボールスターとキャッシュとスナップショットを備えたレポートサーバーで十分でした。

于 2010-01-02T21:12:13.507 に答える
3

  1. 次の条件のうち 2 つが一致する場合は、データ ウェアハウスの構築を検討する必要があります。

    • 膨大なデータ
    • 実行に時間がかかりすぎる（そして書くのが複雑な）多くの大きく複雑な選択（おそらく少数の挿入、更新、および削除と比較して）
    • 異なるシステムからのデータを組み合わせる必要がある

  2. データ ウェアハウスをどう考えるかが問題です。多くの場合、リレーショナル データベース管理システムに固執できる限り、いくつかのレポートを含む OLTP システムから本格的なデータ ウェアハウスに徐々に移行できます。最初に、最初のファクト テーブルを作成し、正規化されたテーブルをディメンションに使用し続けることができます。次に、ファクト、ファクト テーブル、または専用のディメンション テーブルをゲームに追加します。最初は同じデータベース (または関連するシステムのデータベースの 1 つ) で、後で別のデータベースに移動する可能性があります。

  3. 完全なデータ ウェアハウス (個別のデータベース、スター スキーマ) は、特殊なシステムを使用する以外に、select ステートメントをチューニングするための最良のオプションを提供します。また、OLTP システムからも完全に切り離されています。スキーマの設計だけでなく、CPU、I/O、メモリなどのリソースや、新しいリリースのスケジューリングなどの組織についても考えてください。もちろん、それはおそらく必要のない多くの作業です。

  4. それは上記の回答にあります。複雑なクエリが一握りあるからといって、DWHを構築する必要があるという意味ではありません。他の基準が孤立している場合も同様です。

  5. ここで多くを提供することはできませんが、アドバイス: アジャイルに進みましょう。DWH の要件は、ユーザーが見る可能性に大きく依存します。要件は変更される可能性があります。データベースを使用してテストを自動化するのは面倒ですが、適切なテストを行わずに運用システムをいじるのはもっと悪いことです。

于 2010-01-02T20:38:33.967 に答える
2

私の経験から言うと、データ ウェアハウスについて考え始める最初の兆候は、トランザクション データベースを持っている (または開発している) ときに、ユーザーが多くのレポートとデータ履歴の要件を追加し始めるときです。これはほとんど常にです。エンド ユーザーが常に必要とするレポートのニーズを処理するトランザクション システムを設計するよりも、別個のデータ ウェアハウスまたはレポート データベースを用意する方が常に簡単です。トランザクション システムに (ビジネス エンティティの) 履歴を保存すると、複雑さが増し、可能な限り応答性の高いデータベースが必要になります。

反対に、私は大企業に所属しており、多くのグループがデータ ウェアハウスを作成していました。対象となるデータが多くのシステムに分散していたため、クエリを実行するのが困難だったからです。問題は、各グループが独自のデータ ウェアハウスを作成したことでした。これは、社内のすべての既存のウェアハウスに適切な情報のサブセットがないか、最適ではない、または正しくないと見なされたデータ モデルがあったためです。これにより、比較が困難なさらに異なるデータ システムが作成され、状況が悪化しました。

于 2010-01-02T20:04:45.970 に答える
2

データ ウェアハウスの構築を検討する価値のあるオプションは、どの時点ですか? 言い換えれば、標準的なトランザクション環境がもはや十分ではないことを示している可能性がある兆候、メトリック、またはその他の基準を確認する必要がありますか?

トランザクション データ ストアでレポートと分析のアクティビティを実行すると、両方に有害であることがわかった場合は、データ ウェアハウスをお勧めします。

完全なデータ ウェアハウスに代わるものは何ですか? トランザクション データベースの非正規化と、ボグ標準のレプリケートされた "レポート サーバー" の 2 つが思い浮かびます。DW にコミットする前に調査すべきものは他にありますか?

ここで提供するものは何もありません。トランザクション データベースとレポート データベースを保持することは、倉庫と呼ぶかどうかに関係なく、私には理にかなっているように思えます。データ マイニングは、非常に CPU を集中的に使用するアクティビティになる可能性があります。

データ ウェアハウスが上記の代替案よりも優れているのはなぜですか? 答えが「依存する」である場合、それは何に依存していますか?

ここで提供するものは何もありません。

データ ウェアハウスの構築を試みてはいけないのはどのような場合ですか? コンテキストに関係なく、「ベストプラクティス」として宣言されているものには懐疑的です。確かに、DW が間違った選択であるシナリオがいくつかあるに違いありません。

長い履歴を保持する必要がなく、データの集中的な分析を行っておらず、レポートのニーズがその時々のアドホック クエリに限定されている場合、おそらくデータ ウェアハウスはそうではありません。必要。

データ ウェアハウスの導入によって改善されたシステムで、私が参照できる実用的な例はありますか? 彼らがどのような決定や分析のために倉庫を必要としたか、倉庫に何を入れるかをどのように決定したか、そして倉庫が最終的により大きな環境にどのように適合したかをエンドツーエンドで説明してくれる何か? 「AdventureWorks データベースから立方体を作ろう」というわざとらしいことはしたくありません。実装は私には関係ありません。関連する仕様と設計、および全体的な思考プロセスに興味があります。

私の雇用主は皆、私が到着する前から何年もの間データ ウェアハウスを使用していたので、私が到着する前の状況について話すことはできません。

于 2010-01-02T19:54:30.610 に答える
0

DW は、「トランザクション システム」を長期間使用している場合に検討できます。その後、ビジネスのさまざまなデータ パターンを特定するために、データ マイニングを実行する必要があることに気付きます。そして最後に、決定されたデータ パターンの助けを借りて、トップ マネジメントが会社の利益のためにさらなる決定を下すのを支援したいと考えています。

データ ウェア ハウスを構築するには、次の手順を実行する必要があります。

  1. データベースの ETL プラットフォームとデータベースを決定する必要があります。
  2. 視覚化には、SSRS、Tableau などのレポート ツールを選択する必要があります。
  3. さらに使用するために、R などのデータ分析言語を選択することもできます。
  4. 最後に、これらすべてがデータ ウェア ハウスとレポート ツールの開発に役立ちます。 
于 2015-07-20T05:04:16.657 に答える