Что делать с гарантированными дублями

Продолжаем разговор о методах интеграции данных.

Мы уже разобрались в прошлой статье, как искать похожие записи в базе клиентов. В двух словах: поиск по жестким правилам не подходит, расчет «коэффициента похожести» в вакууме — тоже так себе. Лучший вариант — вычислять «похожесть» записей с учетом контекста.

Допустим, мы придумали хорошие правила поиска дубликатов и обработали по ним данные. Алгоритм дал ответ: карточка A гарантированно похожа на карточку Б. Но что делать дальше?

Дубли убрать, данные сохранить

Перед нами две гарантированно похожие карточки. Родина первой — автоматизированная банковская система, а вторую сформировали из заявки на сайте.

Наша задача — собрать данные в единую «золотую» карту. Самое очевидное решение, которое часто применяют в жизни, — объединить лучшие данные в одной карточке. Другую же удалить.

Все довольны: дублирующихся карточек нет, а лучшие данные на месте. Отлично, не так ли? Не так.

Вдруг что-то изменится, сэр!

Клиентская база — не статичный снимок. Люди живут: меняют фамилии, документы и адреса, пользуются новыми продуктами компании и отказываются от старых. Поэтому в карточки А и Б приходят обновления.

Стоп, а как же карточка Б получит обновление, если ее удалили при слиянии? Все верно, здесь появляется проблема. Обычно решают так: когда приходит обновление, вместо карточки Б создают техническую карточку Б2. Новые данные записывают туда.

После этого CDI-система естественным путем находит для Б2 дубликат — карточку А. Теперь предстоит вновь найти лучшие данные из двух карт и собрать их в одной. Вторую же удалить.

Такая схема работает в «живых» промышленных системах. Но решение не оптимально — при каждом обновлении повторяется один и тот же цикл.

1. Создать техническую карточку.
2. Найти дубли.
3. Найти лучшие данные в дублированных карточках.
4. Объединить лучшие данные в одной карточке.
5. Удалить техническую карточку.

На базах с миллионами клиентов, где обновления приходят каждую секунду, лишние действия чрезмерно нагрузят CDI-систему.

Пусть создается сильнейший

Хорошая идея — изменить первый шаг. Зачем выбирать лучшую карточку, если можно оставить все на местах, а из лучших данных создать новую карту. У нее не будет прообраза, она станет «золотым» собранием лучших данных. При этом мы сохраним источник, из которого пришел в «золотую» карту каждый атрибут.

Тогда при обновлении карточек А и Б не нужно создавать новые записи, достаточно обновить существующие. Более того, не придется заново искать дубликаты: мы знаем, что А и Б похожи и являются родителями одной и той же «золотой» карточки.

Во всем искать лучшее

Ключевая задача при формировании «золотой» карточки: понять, какие данные лучше. Расскажу на примерах о базовых принципах, которым мы следуем в HFLabs.

Полное лучше, чем пустое. Самый простой критерий. Мы вводим некий коэффициент полноты и смотрим, для какой карточки этот коэффициент выше.

Из карточки А в «золотую» попадет телефон, а из карточки Б — ФИО. Потому что они более полные, все логично.

Правильное лучше, чем неправильное. Здесь тоже просто. Предположим, во второй карточке имя хранится с опечаткой.

Естественно, при таком условии мы выбираем правильное ФИО.

Перейдем к телефонам: у второго номера некорректная длина и несуществующий код города.

В этом случае мы опять выберем правильный телефон — первый.

Но! Будь у телефонов разный тип — один мобильный, другой домашний — мы поступили бы по-другому: сохранили бы оба, и отправили на разбор дата-стюарду. Совсем терять новые данные жалко, пусть специалист попробует восстановить номер.

Новое лучше старого. В обеих карточках хранятся номера́ документов, причем разные. Оба номера выглядят адекватно. Непонятно, какой же выбрать.

Все решает дата: в карточке Б номер проверяли в прошлом году, а в карточке А — 5 лет назад. Лучше выбрать свежие данные.

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

Что же лучше: новый документ с плохой серией или старый, но с проверенной и правильной?

Казалось бы, все очевидно — оставляем правильный, зачем нам ошибочный номер. Пусть и новый. Но здесь, как мы любим, не все так просто.

Человек поменял паспорт, пришел в отделение. Операционист внес новые данные и, вот незадача, ошибся в серии.

Если мы не пропустим обновление в «золотую» карту, проморгаем сам факт изменения паспорта.

Поэтому новый паспорт все же пойдет в «золотую» карту, но с флажком, означающим ошибку. Дата-стюард увидит новый номер, предупреждение и разберется в ситуации.

Чем больше данных для анализа и опыта, тем точнее можно (и нужно!) настроить правила слияния.

Знай, кому доверять. Напомню, что родина карточки А — автоматизированная банковская система, а карточка Б появилась из заявки на сайте. Логично, что к первой системе доверия больше, при прочих равных мы выберем данные из нее.

Выше я описал базовые правила слияния, который использует «Единый клиент» HFLabs. Но вот небольшой сюрприз: правила при обновлении карточек несколько иные, чем при слиянии.

Казалось бы, какая разница: выбрать между карточкой А и Б или между новой и старой версией карточки Б? Тем не менее, правила будут несколько разными.

При слиянии в одной карточке место работы клиента — ООО «Цветочек», а в другой работа не указана. В «золотую» однозначно пойдет «Цветочек».

При обновлении правила разрешают замену ООО «Цветочек» на пустое значение — человек мог стать безработным.

Обновление карточки — признак того, что появились неактуальные, старые данные. Мы заменяем их свежими и актуальными.

При слиянии же мы всегда выбираем непустое значение. Задача — собрать в «золотую» карточку максимум того, что известно о клиенте. Поэтому мы сохраняем все корректные данные.

Правила зависят от конкретных данных и бизнес-процесса.

Дорогой проб и ошибок

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

• адреса,
• телефоны,
• емейлы,
• документы (все виды паспортов, права),
• ИНН,
• СНИЛС,
• даты и места рождения.

И это только часть атрибутов клиента. А есть еще связанные сущности: автомобили, договоры, контракты, лицевые счета...

А есть еще взаимосвязанные правила:

• используем дату рождения для проверки корректности даты выдачи документа;
• используем адрес для проверки корректности кода города.

Данные изменяются в десятках исходных систем каждый день. Это все нужно учитывать в правилах обновления и слияния.

В «Едином клиенте» уже есть готовые модели для банков, страховых и телекомов. Мы собирали и настраивали их годами. Для каждого поля или атрибута есть наборы правил обновления и слияния, они требуют лишь подстройки при внедрении. Поэтому «Единый клиент» приносит бизнес-пользу уже в первый месяц.