このドキュメントは、Adobe Analytics Data Workbench のトレーニングを終了した新しい管理者およびアナリストを支援するためのものです。この記事を読むと、問題のトラブルシューティングや詳細分析の実行時に、このソフトウェアがどのように機能するかを把握しやすくなります。
リレーショナルデータベースなどの従来のアーキテクチャは、キーによって相互に関連付けられているテーブルにデータを分類します。逆に、Adobe Analytics の Data Workbench コンポーネントは、「ホイール」アーキテクチャと呼ばれる基本的に異なるプロセスを使用します。この記事では、従来のものと比較してホイールアーキテクチャがどのように機能するかを説明し、その長所とと欠点について説明します。
また、他のユーザーも結果を照会する必要がある場合は、ホイールを参照して、ホイールの同じ一回転または異なる一回転からちょうど一回転バッグを監視することができます。このコンベヤーまたはホイールは常に回転し、照会はいつでも始めることができ、一周が完了するまで続けることができます。
また、Data Workbench はベルト上のバッグは完全にランダムな順序であることを保証します。（航空会社もこの点で良い仕事をしています）。これにより、循環データの照会を全体のデータのランダムなスナップショットとして見ることができます。これにより、人口統計全体の結果を想定して、クエリーはおおよその解答を素早く計算できます。
50 のデータではこれが適切に機能しない可能性があります。ただし、数百万、数十億のデータがあれば、最終的な集計の非常に正確な予測をほとんど瞬時に取得できます。
このアナログをさらに展開しましょう。詳細な分析クエリーについては、すべての項目をバッグから出します（ただし、旅行者によってグループ化されます）。コンテンツは、小さなバッグ、さらには、より小さい整理ケース、及び個別の項目で構成されます。
このバッゲージアナロジーを分析のために、訪問者データに変換します。各旅行者の 1 つのバッグは、Visitor、Visit ID などのネームタグ、訪問を表す小さなバッグ、整理ケースは Hits、及び個々のアイテムはイベントです。
Data Workbench クライアントでは、この構造をスキーマ図として記述できます。スキーマダイアグラムの説明は以下のとおりです。
このアーキテクチャに従ってデータをレイアウトする操作を「ログ処理」と呼びます。階層構造が大幅に変更されるたびに発生します。 このプロセスには時間がかかりますが、非常に迅速な分析クエリーのためのデータセットが最適化されます。
ホイールが表とどのように異なるかを説明する前に、この荷物のアナロジーが従来のアプローチをどのように検索するかを検討してください。リレーショナルデータベースでは、データはバッグを置く多数の棚のようなものです。このような従来のアーキテクチャにより、素早く新しいバッグを挿入したり、特定のバッグを引き出すことができます。
1 つのエンティティに対してクエリーをターゲットにすると、リレーショナルデータベースは非常に迅速にクエリを完了できます。たとえば、「太郎さんの Adobe はいくつのイベントを実行しましたか？」というクエリーは訪問者テーブルの記録を、訪問者テーブルのいくつか、及び Hit とイベントテーブルで検索するクエリエージェントを必要とします。また、イベント数のカウントも必要です。これらはこれらの外部キーを使用するデータベースの高価な手順ですが、1 人のユーザーに対しても実用的です。
ただし、分析クエリーはより変更自由ですが、「セッションあたりの実行したユーザー数は？」という質問に対する回答が必要です。このためには、すべてのユーザーに対して高価な手順を繰り返すためのクエリーエージェントを使用して、多数の記録をクエリーする必要があります。このため何百万、何十億という訪問者数の場合、これはすぐに実用的ではなくなります。
データホイールを使用すると、各訪問者のデータは 1 つのバッグにまとめられます。したがって、クエリエージェントは各バッグを一度に評価し、次へ移動することができ、次のホイールは一度でクエリーを終了できます。 したがって、ホイールアーキテクチャは分析クエリーにより適しています。
分析クエリーの速度を向上させるため、一般的なビジネスインテリジェンス（BI）ソフトウェアは、OLAP キューブと呼ばれる計算済みサマリデータを持つ多次元構造に依存します。これらの要約に対してクエリを行うと、一部のアプリケーションでは応答時間が大幅に短縮されますが、高度なクエリ問題が発生する場合があります。
例えば、1つの会社は 50 の異なる州に顧客があり、1000 の製品ラインおよび 100 億のトランザクションはありません。データは、時間、製品、状態に基づいて 3 D キューブを使用して保存されます。これは 120 万キューブの事前計算を必要とします。
このアーキテクチャでは、「各州で 1 時間あたり販売した製品数は？」という分析クエリがキューブの概要を見ることで、非常に迅速に回答できます。これは外部参照を使用した標準のテーブルクエリの大幅な向上です。
ただし、「各州で 1 分毎に販売した製品数は？」というより詳細なクエリは、 OLAP キューブのために 60 で乗算する事前計算を必要とします。新しい製品の追加、国ごとのカウントの延長、または新しい次元の導入（サイズ、性別、マテリアルなどに基づく）OLAP キューブの概要が指数レートでスタックに乗算されます。
キューブのスタックが大きくなると、事前計算およびデータの更新がオーバーヘッドを増加させ、数日遅れである場合が多いデータセットに対してアナリストがクエリを実行する必要が出てくる。このトランザクションのオーバーヘッドと表のデータの指数の増大により、待ち時間が増加し、OLAP キューブアーキテクチャを使用した分析クエリが大幅に制限されます。
これに対し、同等の精度がホイール上で増加すると、増分の品質が小さくなります。
また、事前計算のオーバーヘッドがないと、新たに追加されたデータは到着後すぐに利用できるようになります。これにより、アナリストはほぼリアルタイムでクエリを実行できます。次の記事で、リアルタイム処理の仕組みについて詳しく説明します。
Twitter™ および Facebook の投稿には、Creative Commons の規約内容は適用されません。