よくある失敗#
失敗1. “” や “N/A” などの値で不特定多数が紐づいてしまう#
空文字やエラー値、欠損を意味する値が文字列で入ってしまっている場合、その値を持っている全ての個人が紐づいてしまうことになる。ただし NULL
は自動的に除外される。
解決策#
WF の keys:
の設定で、以下の2種類の key の値の制御方法を組み合わせることで解決することができる。以下の例で解説してみよう。
keys:
- name: td_client_id
valid_regexp: "[0-9a-fA-F]{8}-..."
invalid_texts: ['']
- name: td_global_id
valid_regexp: "[0-9a-fA-F]{8}-..."
invalid_texts: ['', '0000000000-...']
- name: email
valid_regexp: ".*@.*"
1. invalid_texts: を用い、この正規表現ルールにマッチする値しか key として扱わない#
記述した正規表現にマッチする値のみが使われる。td_client_id の例では、全て “307423ab-9cbc-4bca-9cae-05c3700cc8f2” のような以下の正規表現で表される値を持つ。
valid_regexp: "[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}"
2. valid_regexp: を用い、特定の値 (複数可) を除外する#
記述した文字列にマッチする値は使用されない。ここに
"", "N/A", "None", "error"
などの不特定多数が持ちうる値を全てを指定しておくことで、不要な紐付きを回避することができる。
NULL
は初めから紐付きから除外される。
失敗2. loop 回数が足りず、縫い合わせが完了していない#
Unification Algorithm のループ回数が不十分で、縫い合わせが完了 (アルゴリズムが収束) していない結果を活用してしまうことがある。
解決策#
収束のチェック方法1:#
graph や lookup テーブルに対して以下のクエリを実行し、件数が0件であるかをチェックする。0件ならば収束している。なぜなら、収束している graph は、全ての key (follower、leader も自分自身を指すため folllower となっている。 ) はただ1つの leader のみを指している、つまり辺を1つしか持たないからである。以下の SQL は全ての key (follower) の辺の数をチェックして2本以上ある key を抽出しているものである。
lookup Table#
SELECT id, id_key_type, COUNT(1) AS cnt
FROM ${canonical_id_name}_lookup
GROUP BY 1,2
HAVING 1 < COUNT(1)
ORDER BY cnt DESC
id |
id_key_type |
cnt |
---|---|---|
3rd_006 |
2 |
2 |
3rd_012 |
2 |
2 |
先ほどの例では、 (0件ではなく) 2件のレコードが結果となるため、ループが不十分であることが判明した。
graph Table#
SELECT follower_id, follower_ns, COUNT(1) AS cnt
FROM ${canonical_id_name}_graph
GROUP BY 1,2
HAVING 1 < COUNT(1)
ORDER BY cnt DESC
follower_id |
follower_ns |
cnt |
---|---|---|
3rd_006 |
2 |
2 |
3rd_012 |
2 |
2 |
こちらも同様に (0件ではなく) 2件のレコードが結果となる。
Important
do_not_merge_key:
を使用している場合は、収束状態であっても、follower が複数の leader を指している状態となる。つまり、上記の SQL の実行結果は0件とならず、判定方法として利用できない。
収束のチェック方法2:#
WORKFLOW LOGS の該当箇所 (report_diff で検索) を確認することで、収束を判断できる。
Updated number of records: 0
となっているループがあれば、そこで収束してることになる。
+report_diff
タスクは、WORKFLOW LOGS の中に出力されるので、具体的には report_diff
の文字列で検索して行くことになる。
2023-08-12 00:07:54.070 +0000 [INFO] (0110@[1:test_id_unification:41227749:44704900]+test_id_unification_ex1+call_unification^sub+unification+canonical_ids+unified_cookie_id+unify_loop^sub+loop-0+report_diff) io.digdag.core.agent.OperatorManager: echo>: Updated number of records: 22
Updated number of records: 22
1回目のループにおける report_diff の出力。graph_unify_loop_0 と graph_unify_loop_1 の graph の更新箇所をカウントしている。22 あるのでまだ収束していないことがわかる。
2023-08-12 00:08:23.983 +0000 [INFO] (0073@[1:test_id_unification:41227749:44704900]+test_id_unification_ex1+call_unification^sub+unification+canonical_ids+unified_cookie_id+unify_loop^sub+loop-1+report_diff) io.digdag.core.agent.OperatorManager: echo>: Updated number of records: 8
Updated number of records: 8
2回目のループでもまだ収束していない。
…
2023-08-12 00:09:36.109 +0000 [INFO] (0112@[1:test_id_unification:41227749:44704900]+test_id_unification_ex1+call_unification^sub+unification+canonical_ids+unified_cookie_id+unify_loop^sub+loop-4+report_diff) io.digdag.core.agent.OperatorManager: echo>: Updated number of records: 0
Updated number of records: 0
4回目のループで Updated number of records: 0
となり、収束したことがわかる。