ウェブサイトデータ分析の問題点3: データウェアハウス関連の問題

前回の記事「Web サイト データ分析におけるいくつかの問題 2」では、主に BI 関連の問題を整理しました。この記事では、主にデータ ウェアハウス関連の問題を整理します。最近、データ ウェアハウスに関する情報や本を読み直しているので、これまでおよび現在遭遇している主な問題を取り上げたいと思います (ブログ内のデータ ウェアハウスに関する関連コンテンツについては、Web サイトの「データ ウェアハウス」ディレクトリを参照してください)。同時に、データ ウェアハウスに関する知識を再整理し、再理解しています。長い間、ブログに新しい記事を投稿していないので、怠けるわけにはいきません。

これまでに Inmon の「Building a Data Warehouse」と「DW 2.0」を読んだことがありますが、別のデータ ウェアハウスの巨匠 Kimball の「Data Warehouse Lifecycle Toolbox」を読む時間がありませんでした。最近、そのほとんどを読む時間ができたので、何か書くのが待ちきれません。実際、データ ウェアハウスの分野では、Inmon と Kimball の理論は矛盾しているというのが一般的な考えです。2 人はデータ ウェアハウスの構築における方向性の違いについて延々と議論を続けており、どちらの方法が優れているかを納得させることはできません。 Evernote のメモで、この 2 つのビューの概要説明をいつどこで見つけたのかはわかりません。非常に簡潔で要点を押さえた内容です。

インモン対キンボール

Kimball – 誰もが望むものを、望むときに構築できるようにし、必要なときにすべてを統合します。(ボトムアップ アプローチ)

利点: 構築が速い、ROIが早い、機敏

短所: エンタープライズ リソースとして維持するのが難しく、冗長になることが多く、データ マートの統合が難しいことが多い

Inmon – すべてを設計し終わるまで何もしないでください。(トップダウンアプローチ)

利点: メンテナンスが容易、緊密に統合されている

短所: 最初のプロジェクトの納品に時間がかかりすぎる、堅苦しい

実際、「データ ウェアハウス ライフサイクル ツールボックス」を読んでみると、2 つのビューの間にはそれほど大きな本質的な違いはないことがわかりました。おそらく、データ ウェアハウスの継続的な開発により、全体的なアーキテクチャにおいて、2 つのビューは徐々に収束していくでしょう。基本的には、統合されたエンタープライズレベルのデータウェアハウスを構築するという方向性は一貫していますが、Inmon は下位レベルのデータ統合から始めるのに対し、Kimball は上位レベルの需要視点から始める傾向があります。これは、携わっているプロジェクトや立場に関係しているのかもしれません。

上記の高品質な要約を踏まえて、最初の質問は、「データ ウェアハウスを構築するにはどちらの方法 (ボトムアップまたはトップダウン) が好みですか。それぞれの利点と欠点は何ですか?」です。実際、尋ねる必要はありません。そのため、よく遭遇する可能性のある、または実際に検討する必要があるいくつかの質問を次に示します。

Q1. データ ウェアハウスの技術的ソリューションは何ですか? これらのソリューションの利点とボトルネックは何ですか?

データ ウェアハウスの継続的な発展と成熟に伴い、「ビッグ データ」という概念が普及し、関連製品もますます多く登場しています。最も一般的な技術ソリューションには、Hadoop と Hive、Oracle、MySQL の InfoBright、GreenPlum と NoSQL、または複数の組み合わせが含まれます。

実際には、それらは2つのカテゴリにまとめることができます。1つは、従来のRDBMSが支配するデータベースでデータを管理することです。Oracle、MySQLなどはすべて従来のリレーショナルデータベースに基づいています。利点は、より厳密なデータ構造を持ち、リレーショナルデータベースの方がデータ管理が標準化されていることです。データ処理中に発生する可能性のある非人為的エラーは極めて少なく、標準のSQLインターフェイスによりデータ取得コストが低くなり、データのクエリと取得がより柔軟で効率的になります。しかし、欠点も明らかです。大量のデータを処理および保存する能力が不十分であり、データ量が一定レベルに達すると、明らかなボトルネックが発生します。代わりに、それらはテキストベースの分散処理エンジンです。Hadoop、Greenplum、NoSQLはすべてテキストデータの処理とストレージに基づいています。それらの利点は、強力なデータ処理機能、並列コンピューティングをサポートする分散アーキテクチャ、および超拡張と拡張機能です。欠点は、不便な上位レベルのインターフェイスです。したがって、Hive on HadoopとPostgreSQL on Greenplumはどちらもデータインターフェイスの問題を解決するように設計されており、データのクエリと取得に対するリアルタイム応答を実現することが難しく、柔軟性に欠けています。

Q2. データ ウェアハウスには集計データを保存するべきでしょうか。詳細データはデータ ウェアハウスに配置しないほうがよいでしょうか。

実際、この問題については基本的にコンセンサスがあります。エンタープライズレベルのデータウェアハウスを構築する場合、詳細なデータの統合と保存は不可欠です。ただし、実際には、外部データソースからデータを直接計算して集計し、データウェアハウスにインポートする例がまだ多くあります。データ ウェアハウスが単なる軽量アプリケーションである場合、集約されたデータのみを保存するのは理解できます。結局のところ、データ ウェアハウスがどのようなものでなければならないかを規定する人はいません。最終的な目標は、データのサポートと需要を満たすことだけです。

しかし、企業の長期的な発展の観点から見ると、データ ウェアハウスに詳細データを保存することには 2 つの利点があります。一方では、技術的な観点から、データ ウェアハウスに詳細データを保存すると、フロントエンド データベースのクエリ負荷が軽減されると同時に、テキスト データと外部ドキュメント データがウェアハウスに保存された後の管理がより標準化されます。データ ウェアハウスは履歴を保持し、その不変の特性により情報が失われるのを防ぎます。他方では、データの使用の観点から見ると、データ ウェアハウスによりデータの取得と使用が容易になり、詳細データの統合により大量のテキスト データがクエリ可能で関連付けられるようになり、主題指向の設計によりデータの提示と分析がより方向性と目的を持ち、詳細データはデータ分析とデータ マイニング アプリケーションのサポートに不可欠です。したがって、データ ウェアハウスがより大きな価値を生み出し続けるためには、詳細なデータの保存が不可欠です。

Q3. データ ウェアハウスを何層に分割しますか? 各層のデータの機能は何ですか?

標準的な答えはありません。データ ウェアハウス内のデータの複雑さとデータ使用の需要に応じて、データ ウェアハウスはさまざまなレベルに分けられます。

私は通常、データ ウェアハウスを 3 つの層に分けます。最下層は詳細データで、管理戦略はストレージを最適化することです。一般的に、インポートされた生データは、上向きの統計集計を容易にするために保存されます。データ量が多いため、ストレージを最適化する必要があります。中間層は多次元モデルで、管理戦略は構造とクエリを最適化することです。主題指向の多次元モデルの設計では、クエリの利便性を確保しながら、OLAP とデータ クエリの多様なニーズを満たす必要があります。鍵となるのは、ディメンション テーブルの設計とディメンションの選択と組み合わせです。ファクト テーブルは、ストレージとインデックスの最適化に重点を置く必要があります。最上層はプレゼンテーション データで、管理戦略は効率を最適化することです。一般的に、毎日提示する必要があるサマリー レポートや、多次元モデルに従って組み立てられたビューを格納します。プレゼンテーション層のデータは、できるだけ早く提示する必要があり、一般的に BI プラットフォームのダッシュボードやレポートに使用されます。

Q4. データ ウェアハウスの構築で最も複雑なことは何ですか。また、最も欠落している可能性が高い部分はどれですか。

私は、データ ウェアハウスの核心はデータ統合ではないと常に感じてきました。もちろん、データ統合はデータ ウェアハウスがその価値を実現するための前提条件です。データ ウェアハウスの真の価値は、データの効果的な適用にあります。データはビジネスから生まれ、ビジネスに反応します。データ ウェアハウス構築の核心は、データ ウェアハウス アーキテクチャとデータ モデルの設計にあります。データ保存とデータ取得効率の矛盾をいかにバランスさせるかが、データ ウェアハウス管理の難しさです。この難しさはどのデータ ウェアハウスにも存在し、ビッグ データによってこのトレードオフの難しさが増します。データ統合とデータ品質管理は、データ ウェアハウスの構築において最も複雑なタスクであり、特にデータ クリーニング プロセスは複雑です。私はこれまでにもデータ品質管理に関する記事をいくつか書きましたが、実際にはこのプロセスははるかに複雑です。上位レベルのデータ出力の正確性と有効性を確保するには、この作業を行う必要があり、可能な限り慎重に行う必要があります。

データ ウェアハウスの構築で最も見落とされがちなのが、メタデータの管理です。完全なメタデータを持っているデータ ウェアハウス チームはほとんどありません。もちろん、データ ウェアハウスを構築するエンジニア自身が生きたメタデータですが、メタデータは、データを使用する人々にとっても、データ ウェアハウス チーム自体にとっても不可欠です。一方では、メタデータはデータ要求者に完全なデータ ウェアハウスの使用ドキュメントを提供し、データを迅速かつ独立して取得するのに役立ちます。他方では、データ ウェアハウス チーム メンバーは日々のデータ解釈から解放されるため、その後の継続的な反復更新とメンテナンス、および新入社員のトレーニングに非常に役立ちます。メタデータにより、データ ウェアハウスのアプリケーションとメンテナンスの効率が向上します。

最後に：上記はあくまでも私の個人的な意見です。皆様からの批判を歓迎します。また、専門家の方々がコメント欄で貴重な回答をくださることを期待しています。あらゆる角度からの意見や議論を歓迎し、私たちの知恵を集めます。

ウェブサイトデータ分析のいくつかの問題点 1

ウェブサイトデータ分析におけるいくつかの問題 2

原題: ウェブサイトデータ分析の問題点3: データウェアハウスに関する問題点

キーワード: ウェブサイト、いくつか、問題、倉庫、関連、以前、記事ネットワーク、サイト数、ウェブマスター、ウェブサイトのプロモーション、収益化