2

次のようなファイルがあります。

150 event4
160 event4
160 event0
170 event4
175 event4
180 event4
190 event4
192 event3
195 event4
----------
----------

最初の列は、対応するイベントが実際に発生したミリ秒単位の時間です。したがって、event4 は 150 ミリ秒で発生しました。

次のタスクがあります。

  1. 行を 1 つずつ繰り返します。

  2. 連続するイベント間に 80 ミリ秒未満のギャップがある場合、それらは単一のアクティビティのシーケンスです。

例えば

100 event4
120 event5 
140 event6
200 event4

それらのすべてが 80 ミリ秒以下の連続差を持っています。80 ミリ秒以上の差がある場合は、現在のシーケンスが終了し、新しいシーケンスが開始されたことを意味します。私の目標は、シーケンスをクラスター化することです。また、さまざまなクラスターで、特定のイベントの数を報告します。したがって、クラスター 1 の次の例では、イベント 4 が 4 回、イベント 5 が 1 回、イベント 6 が 1 回発生しました。2 番目のクラスターでは、イベント 4 が 3 回、イベント 5 が 1 回です。

100 event4
120 event5 
140 event6
200 event4

300 event4
320 event4 
340 event4
400 event5

私が今やっていることは、

  1. 文字列のリストを作成します。ファイルを解析し、行間のギャップが 80 ミリ秒未満の場合はリストに追加します。
  2. ギャップが 80 ミリ秒を超えるイベントを見つけたら、追加を停止し、次のシーケンスのために新しいリストを作成します。
  3. 異なるリストにすべてのシーケンスを配置した後、リストをトラバースして特定のイベントの数を測定します。

これが効率的なアプローチであるかどうかはわかりません。特定の問題があります。

  • そこにシーケンスのクラスターがいくつあるかわからないため、特定のクラスターを保存するリストの数は固定されていません。
  • イベント名は固定ではありません。event1 から event100 または event 1 から 45 のいずれかです。そのため、イベント番号を格納するために使用される変数の数も固定されていません。

では、他に何か良いアイデアはありますか?

4

1 に答える 1

1

これは、科学で「クラスタリング」と呼ばれるものではなく、単なるグループ化または集約です。あまりにも多くの時間が離れていない限り、イベントを集約します。

アプローチに関しては、標準的なアプローチを追求しています。データが複雑なデータベース インデックスに既に含まれていない限り、線形以上のことはできません。テキストファイルである以上、直線的に読むしか方法がありません。

データ構造に関しては、イベント ID が文字列であるため、ArrayList<ArrayList<String>>またはとして編成しても問題はありません。ArrayList<HashMap<String, Integer>>メモリ要件は中程度で、ギガバイトまでスケールアップする必要があります。メモリの問題が発生している場合は、各イベント文字列のコピーを1 つHashSet<String>だけ保持し、時刻を数値データ型に変換するように維持してみてください。十分なイベントがほとんどない場合は、数 GB をロードできるはずです。

実際、ここには大きな課題はありません。

于 2012-09-12T06:38:23.733 に答える