Unification Algorithm の解説

graph_unify_loop_0

incremental_update においては、初期 graph の作り方が異なる。以下の2つの graph が結合されたものが初期 graph となるのだ。

1. 新しく追加されたレコードに対する graph

2. 前回実行時の最終 graph

1. 新しく追加されたレコードに対する graph

Fig. 51 新しく追加されたレコードに対する graph_unify_loop_0

2. 前回実行時の最終 graph

Fig. 52 前回実行時の graph

graph_unify_loop_0

これら2つを結合した graph が incremental_update における初期 graph となる。

Fig. 53 graph_unify_loop_0

この graph からスタートすることによって、ループ回数少なく収束させることができる。ほとんどの場合、1回目のループで leader を入れ替える際に aaa_001 に入れ替わることになるため (Exapmle2 参照)、収束が近くなる。

graph_unify_loop_1 (2,graph も同様)

Fig. 54 graph_unify_loop_1

実際、1回目のループで収束していることが確認できる。

アウトプット

master_table

レコード追加された分も同一人物だったため、master_table は1つのレコードとなる。canonical_id も aaa_001 をベースに生成しているため、前回と値は変わっていない。

結果

unified_cookie_id	td_client_id	td_global_id
Su-bHvUu9NN_	[“yyy_007”, “aaa_005”, “xxx_006”, “yyy_006”, “zzz_008”]	[“3rd_019”, “3rd_019”, “3rd_019”, “3rd_019”, “3rd_019”]

enriched_ Table

incremental_columns: [time] の設定のもとでは、incremental_update が行われた際には、各 enriched_ Tableには、全レコードに対して canonical_idを付与してテーブルを Replace する処理にはならず、 更新されたレコード分のみに canonical_id が付与され、従来の enriched_ Table に追記する形となる。これによって、エンリッチタスクにかかる時間を圧倒的に少なくできる。