Огляд процесу

...

Дедуплікація — це завдання пошуку записів у наборі даних (MPI), які відносяться до тієї самої Особи. Для того, щоб гарантувати якість даних, слід також поставити задачу визначення шахрайства. Якщо є різні особи з однаковим номером документа/tax_id тощо, такі випадки не дублюватимуться, і це завдання визначення шахрайства.

...

• підготовка та очистка даних 

• блокування та пошук можливих пар

• розрахунок змінних для кожної пари

• використання моделі вірогідності об'єднання

• пошук мастер персони в парі та деактивація персони, яка не є мастер

• отримання декларацій, які належать деактивованим особам, і припинення дії декларації

Підготовка та очистка даних

Для полів, які використовуються для блокування чи обчислення змінних, необхідно застосувати такі регулярні вирази:

• для first_name, second_name та last_name, birth_settlement  змінити: [ --'] to '',  'є' to 'е', 'и' to 'і'

• для birth_certificate змінити: [ /%#№ _-]  to '',  [iі!IІ] to 1

• для інших документів: [ /%#№ _-]  to ''

• для birth_settlement - ([сc][ \.,])|([сc]ело[\.,]*)|([сc]мт[\.,]*)|([сc]елище [мm][іi][сc]ького типу)|([сc]елище[\.,]*)|([мm][іi][сc][tт][оo][\.,]*)|([мm][\.,]*)

Блокування та пошук можливих пар

Дубльовані записи майже завжди мають щось спільне. Якщо ми визначаємо групи даних, які мають щось спільне, і порівнюємо лише записи в цій групі або блоці, тоді ми можемо зменшити кількість порівнянь, які ми будемо робити. Іншими словами, ми повинні застосувати розумне порівняння.

Блоки даних

Нам потрібно визначити таким чином, щоб мати набагато менше пар для порівняння та все одно мати впевненість, що порівнюватиме записи, які справді є дублікатами.

...

• tax_id

• documents.number 

• номер автентифікації 

• адреса реєстрації + first_name

• адреса реєстрації + last_name

Складові індекси для блоків

Щоб зробити процес сполучення більш ефективним

• індекс побудови для кожного поля, яке бере участь у блоках

• додати логічне поле для перевірки та побудувати на ньому індекс

• одну за одною взяти особу з відміткою "перевірено" як нуль і взяти ідентифікатори осіб з однаковими характеристиками (tax_id, документ та всі поля блоку)

Розрахунок змінних для кожної пари

Після побудови моделі на наборі даних є знання про те, які змінні корелюють із цільовими показниками та мають рівень IV.

...

Після декодування кожної змінної ми можемо застосувати модель і обчислити ймовірність

Використання моделі вірогідності об'єднання

Наразі в якості предикативного методу було обрано логістичну регресію.

...

• score >=0.9 - об'єднати (мінімальний скор, який має бути збережений до `merge candidates` and auto merged)

• скор між 0.7 та 0.9 - ручне об'єднання  (як мінімальний бал, по якому потрібно об’єднати вручну)

• score < 0.7 - не об'єднувати

Визначити мастер персону та розірвати декларацію

Наразі master_person_id визначається updated_at. Іншими словами, останній запис буде активним, а інші будуть об’єднані в цей.

...

Огляд ручного об'єднання

Для person_id у статусі «NEW»  і score>=max_manul_score (0,9) від merge_candidates знайти декларацію в статусі «VERIFIED» та змінити статус на «TERMINATED» і змінити person.id.status на INACTIVE

...

Після того, як рішення досягне значення, яке перевищує decision_amount і final_decision є MERGE, консьюмер OPS kafka повинен знайти декларацію в статусі «VERIFIED» та змінити статус на «TERMINATED» і змініть person.id.status на INACTIVE і змінити persons.id.status на INACTIVE:

Деактивувати користувача:

1. знайти користувача по person_id, якщо вказано (Mithril.users DB)

   1. встановити is_active = false

   2. встановити updated_at = now()

2. викликати функцію expire_user_tokens

Огляд автоматичного об'єднання

Після того, як було рішення об'єднати пару персон, виконати

1. Перевірити персон

   1. перевірити, чи персона або master_person існує в DB

   2. перевірити `updated_at` по персонам, якщо (merge_candidate.person.inserted_at або merge_candidate.measter_person.inserted_at) < mpi.person.updated_at встановити статус STALE на merge_candidates

2. Деактивувати персону

   1. знайти декларацію person_id, якщо існує

      1. створити подію в kafka

      2. встановити статус DECLARATION_READY_DEACTIVATE на merge_candidates

   2. змінити статус person_id на inactive

   3. додати інформацію до merged_pairs з person_id та master_person_id

   4. встановити статус MERGED до merge_candidates

   5. додати зміну статусу персони до event_manager

3. Деактивувати користувача

   1. знайти користувача по person_id, якщо існує (Mithril.users DB)

      1. встановити user.is_active = false

      2. встановити updated_at = now()

   2. викликати функцію expire_user_tokens

Статусна діаграма Merge_candidates

...