データのグルーピング処理名寄せ処理

ビッグデータ時代に突入し、様々な場所で発生するデータを管理する手段が重要になって来ています。
膨大なデータを高速にデータを処理して、有益な結果を出せる事は必須の要件になってきましたが、
散逸して存在している情報をグルーピングし、有効活用する必要性（ニーズ）は高速データ処理以上に
増して来ています。
ここでは、複雑な統合処理をシンプルなルールの組み合わせと簡単な結合方法で、解決する事を主眼に
考えたいと思います。
それぞれの考え方が有りますので断定はしませんが、データクレンジングは良い方法だとは考えません。
クレンジングの条件は明確にすべきですが、データクレンジングにより作成したデータは派生物なので
根本的に厳格な原本管理と矛盾すると考えます。
良きにつけ悪しきにつけ、生成しオーソライズされた原本（誤りが含まれていても）は厳格に管理され
るべきであり、安易にデータを修正してしまう習慣は、コンプライアンスの点からも問題が有ると考え
ます。データライフサイクルを十分に検討した上で、一定のタイミングで全データを更新し、世代管理
する事が、望ましい対処方法だと思います。
コンピュータの性能は劇的に向上していますので、必要な作業の都度原本に修正手順を適応して、その
データ対して適切な操作を行っても、十分に時間的余裕は有るはずです。

前提

結合方式

結合条件

検証方法

上記結合ルールは、二値画像処理で広く一般的に行われている、４連結のラベリング処理と等価である。
画像処理の場合は、画素の配置情報を参考情報に利用できるので、連結解析処理は劇的に軽量化出来る。

グルーピング処理（名寄せ処理）の評価では、本性質を利用して、容易に検証を行う事を検討する。
　
適当な二値画像を用意し、画像情報から画像の縦横、位置色等を要素にした、オブジェクトを生成する。　
今回のテスト用画像（図１）の大きさ 1600x1200画素。（ 1,920,000 個のオブジェクトを生成する）
オブジェクト構造の、参考例として　OBJECT:{ value, x, y, lx, ly, group_id, random }
初期時点では、group_id, random は未使用状態。

オブジェクトの random パートに新たに乱数を生成し登録する。
全オブジェクトを random 要素でソートする事で、元の画像と位置の関連性が全く無い、配置順序が
バラバラなデータを作成し、検証用の元データとする。（図2 確認用にデータ順のまま画像化）

本結合処理でグループ化した対象物には、別途グループ IDを付与する。オブジェクトの group_id には、
そのグループIDを（画像のラベリング処理で付与するラベル番号に相当）を格納(図3 確認用画像化)する。
オブジェクト中の、x, y, lx, ly 要素を用いれば、画像の再合成が可能で、グループID (group_id)を
疑似カラ―化し、画像の再合成処理をする事で、グループ識別値を画像要素とした、画像を合成できる。
この再合成画像において、図4 ４連結のラベリング処理が正しく行われたかの検証をもって、結合処理が
正しく行われているかの確認方法とする。

処理フロー

実際のグルーピング処理（名寄せ処理）をプログラムで表現すれば、下記の様になる。

for( a=0; a<N; a++ ) {        // 名寄せ処理オブジェクトの数は N 個
      for( b=a+1; b<N; b++ ) {  // 比較の組合せ回数  N * (N-1) / 2 回
          // a, b が処理対象外のオブジェクトの時は、処理をスキップする
if( ! isTarget( obj, a, b ) ) continue;
          // 名寄せの判断基準    Ex.２条件の何れかを満たす時、同じと判断
          if( conditions1( obj, a, b ) || conditions2( obj, a, b ) ){
              gathering( obj, a, b );  // 同一と判断した時の結合処理
          }
      }// OBJECT *obj; obj[a], obj[b] の要素を比較し同一性の確認をする
}// 名寄せ処理の終了

本処理（アルゴリズム）は、非常に単純な処理として、定義(プログラム)できる。
(望ましくない利用を制限する目的で、これ以上の詳細に関しては非公開)

実行結果

今回の評価試験では、全オブジェクト 1,920,000 中 775,759 が比較対象

>aggregationOfNames.exe full.obj
1920000 / 1920000
START:Time: 00:00:48
E N D:Time: 01:34:42
>

１時間35分程度必要（旧式のCore i7搭載ノートパソコンにて）

※ Haswell-E なら１時間に短縮される。本ソフトはシングルスレッドのアプリ
　　処理時間は長いが、この種別の処理においては、非常に高速な処理


図1、オブジェクト化する画像	図2、確認用にデータ順のまま画像化

図3、グルーピング結果を画像化	図4、オブジェクト中の座標情報で再合成

グループ番号を付与した、オブジェクトと、画像化プログラム（ソース、Windows用 exe)の提供

numbered_objects.zip	d152b1d20d00c388f4fdeeccc43bdf50
object2bmp.zip	7642280f25ddf43f07ba71b32589b6e7
usage: object2bmp.exe [-p] [-r] [ input_obj [ output_bmp ]] -p: pseudocolor option -r: restoration option input_obj : name of a object file for input data. default name: source.obj output_bmp: name of a BMP file for output image. default name: object2bmp.bmp
Ex. object2bmp.exe -p -r numbered_objects.obj pseudo_color.bmp object2bmp.exe -r numbered_objects.obj source.bmp object2bmp.exe -p numbered_objects.obj pseudo_color_obj.bmp object2bmp.exe numbered_objects.obj random_obj.bmp

補足事項

全オブジェクト中から２つを選ぶ組み合わせは、(全オブジェクトの数＊(全オブジェクトの数-1))/２
種類有るので、全組合せに対して同一処理を行うには、多くの処理時間を必要とするが、
　１、名寄せ基準が明確で且つ、コンピュータで処理出来るのであれば、
　２、処理時間はかかるが、現実的な時間の範囲で処理は完了出来る。
処理時間は要するが、アルゴリズム的には凡庸な処理であり、多大な投資をして失敗する様な、高度な
処理では決して無い。
ただし、名寄せ基準が曖昧で、人間も処理出来ないような出鱈目な状況であれば、コンピュータも当然
処理出来ない。　これはもはや、人災レベルの話。
コロンブスの卵ではないが、誰かが可能性を証明すれば誰でも出来る様になるのも、また事実である。

終わりに

断片的で些末な情報も、名寄せを行う事で、"有益なデータに変容してしまう事" を考慮すべきであり、
またその処理自体が、特殊な処理では無く非常に容易である事も忘れるべきではない。言い換えれば、
”些細な不手際” で情報が漏えいして、”誤って” 名寄せ処理が行われ、データベース化された情報が、
一度イン―ネットに流出すれば、永久に消す事の出来ない情報とし存在し続ける事となる。
人は過ちを犯しやすいので、”些細な不手際”や”誤った操作”が、起こらない事を保証するのはかなり
難しい事である。"意図せずに生成された" データに、POS(販売時点情報管理)データが登録されたり、
監視カメラが認識した符号化データの問い合わせ、などが発生すると、某映画の様に人工衛星を使用
しなくとも、特定対象の追尾が可能となる事も合わせて懸念すべきではないのだろうか。
現行のコンピュータは、数億件程度のデータ量であれば、秒で条件検索を完了する処理能力を有して
いる事も、合わせて記載する。

繰り返しとなるが、今回の処理で分かる通り、断片的、些末的なデータが、データとデータを結び
つけるボンドとして働く可能性を、特に懸念すべき事として、あらためて注意喚起したい。

　　見やすい色に変更し、マークを付けた画像
この例では左側の赤丸の中心（一か所）で、情報A と情報B に関係性が有ると判断され、同一グループ
の情報とみなされており、右側の赤丸の中心（一か所）で、情報B と情報C に関係があると判断され、
情報B と情報C が同一グループの情報と認識された。また、情報Aと情報B の同一性と情報Bと情報Cの
同一性により、情報A、情報B と情報C は同一グループに属する情報であるとして、統合化された。
つまり、1回でも情報を結びつける行為（全く種類の異なる事でも）を行えば、情報を繋ぐときのルール
として、該当行為（ガードでの支払い、住所、など）を考慮すれば、芋づる式に繋がる事を意味する。

別の評価も検討しているのですが....　　国立国会図書館の蔵書数が、4,107万4,863点の様なので、
http://www.ndl.go.jp/jp/aboutus/outline/numerically.html
これを上回る、5千万件以上のデータで評価を開始したら、予想終了日が３０日を超えてしまいました。
流石にこのクラスのデータ量になると、シングルスレッドの処理では難しく、マルチスレッド化は必須
の様です。　まともに TSX命令が使える CPU の入手が出来た時点で再検討したいと思います。

名寄せって、簡単だよ！

高速でシンプルなデータ統合処理

はじめに

前提