Unification Algorithm の解説#

graph_unify_loop_0#

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

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

  2. 前回実行時の最終 graph

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

_images/graph_unify_loop_05.png

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

2. 前回実行時の最終 graph#

_images/graph_unify_loop_4.png

Fig. 52 前回実行時の graph#

graph_unify_loop_0#

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

_images/graph_unify_loop_06.png

Fig. 53 graph_unify_loop_0#

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

graph_unify_loop_1 (2,graph も同様)#

_images/graph_unify_loop_14.png

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 に追記する形となる。これによって、エンリッチタスクにかかる時間を圧倒的に少なくできる。