注意：

この記事は、厳密にいうと、製品の簡易化されたイラストです。問題を解決するために操作を視覚化しアナリストに役立つように表示します。

概要

弊社の前の記事で、複数チャネルフォームからログデータ単一の訪問者データについて説明してきました。現在フォーカスをデータセット全体に移動しています。

ログプロセス - 構築データセット -

データセットの作成は、2 つのフェーズで構成されログプロセスと呼ばれます。

(1) ログプロセスのフェーズ

最初にサーバーが生ログのデータファイルを復号化し、訪問者のデータ（連絡先カード）として整理してから、データセット（カード保持者）に保存する必要があります。このフェーズでは、Fast Input として知られています。

このフェーズでは、大量のログファイルを行単位でデコードする必要があります。したがって、このフェーズにはかなり時間がかかります。

(2) 変換フェーズ

前のフェーズでは、生のログデータのデコードに関するすべてでしたが、このフェーズではデコードされたデータをより有用なフォームに変換することに重点を置きます。このフェーズは、Fast Merge として知られています。

この時点で、サーバーはデータセット上で動作し、フラットなログファイルとは異なり、すばやいアクセスでより小容量に整理することができます。このため、通常、このフェーズはログ処理フェーズよりも短時間で完了します。

進行中、完了した部分はクエリで徐々に使用できるようになります。

注意：

CrossRows の変換などのリソースの負荷の変換を使用して、このフェーズの長さやディスク消費量を展開できます。

ログ処理のフェーズの変換タスク

ログ処理フェーズの間、変換フェーズを待たずに単純な変換タイプを実行できます。次の図で、単一スイープの前の記事に記載された同じ参照の変換について説明します。

注意：

一部の変換タイプは、ログ処理フェーズの完了を待機する必要があります。例えば、クロス行変換では、カード上の他のフィールドが入力として扱われ、まだデコードされない場合があります。これらは、変換フェーズで後から実行できます。

リアルタイム処理 - 継続的な更新 -

ログプロセスが完了した後でも、データセットを最新の状態に保つために新しいデータが連続的に追加されます。この継続的な増分はリアルタイム処理モードと呼ばれ、クエリに応答している間に、サーバー上ではバックグラウンドで実行されます。

センサーモジュール経由でフィードする時、イベントデータは、十分なサイズで設定されたクラスターで、数分以内で処理されました。その後、アナリストはほぼリアルタイムでイベントに対してクエリを実行できます。

ただし、ログデータ量が急増すると、クラスターに過度な負荷がかかる可能性があります。例えば、ある製品のリリース日に訪問者数が数倍に増えるとします。これにより、保留データが積み重なり、現在の時刻と実際の時間の差が広がります。

- 遅延のキャッチアップ -

現在の時刻の遅れがしきい値に達すると、データセットは、ログプロセスおよび変換のフェーズに再び戻ります。これにより、遅れをキャッチアップの手助けをします。

Fast Input として知られるログ処理フェーズ（増分）：データセットの既存のフィールドデータを再利用できるので、保留中のデータのみがデコードされ、比較的簡単に終了します。このフェーズの間は、データセットはクエリーの受け入れを停止し、ログの処理時にリソース全体に焦点を合わせます。

Fast Merge として知られる変換フェーズ（フル）：新しくデコードされたデータを追加するには、既存の変換されたデータは無効になります。これにより、変換フェーズが完全に再変換を実行する必要があります。部分的なデータは、進行中のクエリで使用できるようになります。

すべての変換が完了すると、データセットはリアルタイムの処理モードに戻ります。

注意：

クラスターへのデータのフィード方法はケースによって異なります。お客様の組織は、センサー、Adobe Analytics レポート（SiteCatalyst）からのデイリーフィード、様々なカスタムアプリケーションのログファイル、またはそれらのコンビネーションを使用してデータをフィードできます。上記の例は、メカニズムを説明する必要最小限のものです。特定の使用事例に最適なプランをカスタマイズするには、Adobe コンサルタントにお問い合わせください。

再処理 - データセットの再構築 -

大幅なアーキテクチャの変更、予期しない損傷から回復、定期的なメンテナンスはログプロセスと変換がもう一度必要です。このような再構築は再処理中と呼ばれます。

例えば、設計者はコールセンターのログを組み込むことを決定します。黄色でマークされたデータアーキテクチャを更新し、再処理を開始します。

再分析が終了すると、このようなより高度なクエリを実行できます。

「インストアアドオン購入アイテムの間で、どの製品がサポートコールが発生しやすいですか？」

注意：

本来、データセット全体の再処理は時間がかかるので、ビジネス時間外で実行する必要があります。

再変換 - 部分的な再構築 -

設計者が変換段階の操作に変更を加える必要がある場合は、変換フェーズのみを繰り返すことは不十分である可能性があります。これは、再変換と呼ばれ、ログ処理フェーズをスキップします。

明らかに、再変換はログ処理フェーズ操作をさかのぼって更新しません。したがって、これらの変更内容に対する変更は完全に再処理されます。

- データセットメンテナンス -

計画的に、Data Workbench ではログデータ処理が無制限に保持され、データセットは再処理されるまで増大し続けます。データオーバーフローが発生しないように、Adobe のサポートは開始時間を更新するとともに定期的に再処理することをお勧めしますデータセットサイズを管理するベストプラクティスは、ここで見つけられます。

分析データセットのライフサイクル

概要