注意：
この記事は、厳密にいうと、製品の簡易化されたイラストです。 問題を解決するために操作を視覚化しアナリストに役立つように表示します。
弊社の前の記事で、複数チャネルフォームからログデータ単一の訪問者データについて説明してきました。 現在フォーカスをデータセット全体に移動しています。
最初にサーバーが生ログのデータファイルを復号化し、訪問者のデータ（連絡先カード）として整理してから、データセット（カード保持者）に保存する必要があります。 このフェーズでは、Fast Input として知られています。
前のフェーズでは、生のログデータのデコードに関するすべてでしたが、このフェーズではデコードされたデータをより有用なフォームに変換することに重点を置きます。このフェーズは、Fast Merge として知られています。
この時点で、サーバーはデータセット上で動作し、フラットなログファイルとは異なり、すばやいアクセスでより小容量に整理することができます。 このため、通常、このフェーズはログ処理フェーズよりも短時間で完了します。
進行中、完了した部分はクエリで徐々に使用できるようになります。
注意：
CrossRows の変換などのリソースの負荷の変換を使用して、このフェーズの長さやディスク消費量を展開できます。
ログ処理フェーズの間、変換フェーズを待たずに単純な変換タイプを実行できます。 次の図で、単一スイープの前の記事に記載された同じ参照の変換について説明します。
注意：
一部の変換タイプは、ログ処理フェーズの完了を待機する必要があります。例えば、クロス行変換では、カード上の他のフィールドが入力として扱われ、まだデコードされない場合があります。これらは、変換フェーズで後から実行できます。
ログプロセスが完了した後でも、データセットを最新の状態に保つために新しいデータが連続的に追加されます。この継続的な増分はリアルタイム処理モードと呼ばれ、クエリに応答している間に、サーバー上ではバックグラウンドで実行されます。
現在の時刻の遅れがしきい値に達すると、データセットは、ログプロセスおよび変換のフェーズに再び戻ります。これにより、遅れをキャッチアップの手助けをします。
Fast Input として知られるログ処理フェーズ（増分）：データセットの既存のフィールドデータを再利用できるので、保留中のデータのみがデコードされ、比較的簡単に終了します。 このフェーズの間は、データセットはクエリーの受け入れを停止し、ログの処理時にリソース全体に焦点を合わせます。
Fast Merge として知られる変換フェーズ（フル）：新しくデコードされたデータを追加するには、既存の変換されたデータは無効になります。これにより、変換フェーズが完全に再変換を実行する必要があります。 部分的なデータは、進行中のクエリで使用できるようになります。
注意：
クラスターへのデータのフィード方法はケースによって異なります。お客様の組織は、センサー、Adobe Analytics レポート（SiteCatalyst）からのデイリーフィード、様々なカスタムアプリケーションのログファイル、またはそれらのコンビネーションを使用してデータをフィードできます。上記の例は、メカニズムを説明する必要最小限のものです。特定の使用事例に最適なプランをカスタマイズするには、Adobe コンサルタントにお問い合わせください。
大幅なアーキテクチャの変更、予期しない損傷から回復、定期的なメンテナンスはログプロセスと変換がもう一度必要です。 このような再構築は再処理中と呼ばれます。
例えば、設計者はコールセンターのログを組み込むことを決定します。黄色でマークされたデータアーキテクチャを更新し、再処理を開始します。
注意：
本来、データセット全体の再処理は時間がかかるので、ビジネス時間外で実行する必要があります。
Twitter™ および Facebook の投稿には、Creative Commons の規約内容は適用されません。