Ctrl+K

よくある失敗

よくある失敗#

失敗1. “” や “N/A” などの値で不特定多数が紐づいてしまう#

空文字やエラー値、欠損を意味する値が文字列で入ってしまっている場合、その値を持っている全ての個人が紐づいてしまうことになる。ただし NULL は自動的に除外される。

_images/9-2-1.png

Fig. 56 本来異なるユーザー同士が、ともに Gamer ID=”N/A” の値を持つが故に、ひとつに紐づいてしまったケース#

解決策#

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 のループ回数が不十分で、縫い合わせが完了 (アルゴリズムが収束) していない結果を活用してしまうことがある。

_images/9-3-2.png

Fig. 57 Example1 においてループ回数を2とした時の出力。ループ回数が不十分だったために、アルゴリズムが収束していない例#

解決策#

収束のチェック方法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 となっているループがあれば、そこで収束してることになる。

_images/9-4-1.png

Fig. 58 +report_diff タスクの確認#

+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 となり、収束したことがわかる。

Contents