Продолжаем разговор о методах интеграции данных.
Мы уже разобрались в прошлой статье, как искать похожие записи в базе клиентов. В двух словах: поиск по жестким правилам не подходит, расчет «коэффициента похожести» в вакууме — тоже так себе. Лучший вариант — вычислять «похожесть» записей с учетом контекста.
Допустим, мы придумали хорошие правила поиска дубликатов и обработали по ним данные. Алгоритм дал ответ: карточка A гарантированно похожа на карточку Б. Но что делать дальше?
Дубли убрать, данные сохранить
Перед нами две гарантированно похожие карточки. Родина первой — автоматизированная банковская система, а вторую сформировали из заявки на сайте.
Поле | Карточка А | Карточка Б |
ФИО | Травин Иван | Травин Иван Сергеевич |
Телефон | (495) 960-42-42 | 960-42-42 |
Дата рождения | 31.03.1984 | |
Документ | 7701 359743 |
Наша задача — собрать данные в единую «золотую» карту. Самое очевидное решение, которое часто применяют в жизни, — объединить лучшие данные в одной карточке. Другую же удалить.
Поле | Карточка А | Карточка Б |
ФИО | Травин Иван Сергеевич | Травин Иван Сергеевич |
Телефон | (495) 960-42-42 | 960-42-42 |
Дата рождения | 31.03.1984 | |
Документ | 7701 359743 | 7701 359743 |
Все довольны: дублирующихся карточек нет, а лучшие данные на месте. Отлично, не так ли? Не так.
Вдруг что-то изменится, сэр!
Клиентская база — не статичный снимок. Люди живут: меняют фамилии, документы и адреса, пользуются новыми продуктами компании и отказываются от старых. Поэтому в карточки А и Б приходят обновления.
Стоп, а как же карточка Б получит обновление, если ее удалили при слиянии? Все верно, здесь появляется проблема. Обычно решают так: когда приходит обновление, вместо карточки Б создают техническую карточку Б2. Новые данные записывают туда.
Поле | Карточка А | Карточка Б | Карточка Б2 |
ФИО | Травин Иван Сергеевич | Травин Иван Сергеевич | Травин Иван Сергеевич |
Телефон | (495) 960-42-42 | 960-42-42 | 960-42-42 |
Дата рождения | 31.03.1984 | ||
Документ | 7701 359743 | 7701 359743 | 7712 346424 |
После этого CDI-система естественным путем находит для Б2 дубликат — карточку А. Теперь предстоит вновь найти лучшие данные из двух карт и собрать их в одной. Вторую же удалить.
Поле | Карточка А | Карточка Б | Карточка Б2 |
ФИО | Травин Иван Сергеевич | Травин Иван Сергеевич | Травин Иван Сергеевич |
Телефон | (495) 960-42-42 | 960-42-42 | 960-42-42 |
Дата рождения | 31.03.1984 | ||
Документ | 7712 346424 | 7701 359743 | 7712 346424 |
Такая схема работает в «живых» промышленных системах. Но решение не оптимально — при каждом обновлении повторяется один и тот же цикл.
- Создать техническую карточку.
- Найти дубли.
- Найти лучшие данные в дублированных карточках.
- Объединить лучшие данные в одной карточке.
- Удалить техническую карточку.
На базах с миллионами клиентов, где обновления приходят каждую секунду, лишние действия чрезмерно нагрузят CDI-систему.
Пусть создается сильнейший
Хорошая идея — изменить первый шаг. Зачем выбирать лучшую карточку, если можно оставить все на местах, а из лучших данных создать новую карту. У нее не будет прообраза, она станет «золотым» собранием лучших данных. При этом мы сохраним источник, из которого пришел в «золотую» карту каждый атрибут.
Поле | Карточка А | Карточка Б | «Золотая» |
ФИО | Травин Иван | Травин Иван Сергеевич | Травин Иван Сергеевич |
Телефон | (495) 960-42-42 | 960-42-42 | (495) 960-42-42 |
Дата рождения | 31.03.1984 | 31.03.1984 | |
Документ | 7701 359743 | 7701 359743 |
Тогда при обновлении карточек А и Б не нужно создавать новые записи, достаточно обновить существующие. Более того, не придется заново искать дубликаты: мы знаем, что А и Б похожи и являются родителями одной и той же «золотой» карточки.
Во всем искать лучшее
Ключевая задача при формировании «золотой» карточки: понять, какие данные лучше. Расскажу на примерах о базовых принципах, которым мы следуем в HFLabs.
Полное лучше, чем пустое. Самый простой критерий. Мы вводим некий коэффициент полноты и смотрим, для какой карточки этот коэффициент выше.
Поле | Карточка А | Карточка Б |
ФИО | Травин Иван | Травин Иван Сергеевич |
Телефон | (495) 960-42-42 | 960-42-42 |
Из карточки А в «золотую» попадет телефон, а из карточки Б — ФИО. Потому что они более полные, все логично.
Правильное лучше, чем неправильное. Здесь тоже просто. Предположим, во второй карточке имя хранится с опечаткой.
Поле | Карточка А | Карточка Б |
ФИО | Травин Иван | Травин Ивлн |
Естественно, при таком условии мы выбираем правильное ФИО.
Перейдем к телефонам: у второго номера некорректная длина и несуществующий код города.
Поле | Карточка А | Карточка Б |
Телефон | (495) 960-42-42 | (743) 960-42-4 |
В этом случае мы опять выберем правильный телефон — первый.
Но! Будь у телефонов разный тип — один мобильный, другой домашний — мы поступили бы по-другому: сохранили бы оба, и отправили на разбор дата-стюарду. Совсем терять новые данные жалко, пусть специалист попробует восстановить номер.
Новое лучше старого. В обеих карточках хранятся номера́ документов, причем разные. Оба номера выглядят адекватно. Непонятно, какой же выбрать.
Поле | Карточка А | Карточка Б |
Документ | 7794 346438 | 7701 359743 |
Актуальность | 2012 год | 2017 год |
Все решает дата: в карточке Б номер проверяли в прошлом году, а в карточке А — 5 лет назад. Лучше выбрать свежие данные.
Но есть исключения. Например, существует справочник серий документа. Справочник говорит, что серия в карточке Б ошибочная.
Поле | Карточка А | Карточка Б |
Документ | 7794 346438 | 7701 359743 |
Актуальность | 2012 год | 2017 год |
Качество | Корректный | Неверная серия |
Что же лучше: новый документ с плохой серией или старый, но с проверенной и правильной?
Казалось бы, все очевидно — оставляем правильный, зачем нам ошибочный номер. Пусть и новый. Но здесь, как мы любим, не все так просто.
Человек поменял паспорт, пришел в отделение. Операционист внес новые данные и, вот незадача, ошибся в серии.
Если мы не пропустим обновление в «золотую» карту, проморгаем сам факт изменения паспорта.
Поэтому новый паспорт все же пойдет в «золотую» карту, но с флажком, означающим ошибку. Дата-стюард увидит новый номер, предупреждение и разберется в ситуации.
Чем больше данных для анализа и опыта, тем точнее можно (и нужно!) настроить правила слияния.
Знай, кому доверять. Напомню, что родина карточки А — автоматизированная банковская система, а карточка Б появилась из заявки на сайте. Логично, что к первой системе доверия больше, при прочих равных мы выберем данные из нее.
Выше я описал базовые правила слияния, который использует «Единый клиент» HFLabs. Но вот небольшой сюрприз: правила при обновлении карточек несколько иные, чем при слиянии.
Казалось бы, какая разница: выбрать между карточкой А и Б или между новой и старой версией карточки Б? Тем не менее, правила будут несколько разными.
При слиянии в одной карточке место работы клиента — ООО «Цветочек», а в другой работа не указана. В «золотую» однозначно пойдет «Цветочек».
При обновлении правила разрешают замену ООО «Цветочек» на пустое значение — человек мог стать безработным.
Обновление карточки — признак того, что появились неактуальные, старые данные. Мы заменяем их свежими и актуальными.
При слиянии же мы всегда выбираем непустое значение. Задача — собрать в «золотую» карточку максимум того, что известно о клиенте. Поэтому мы сохраняем все корректные данные.
Правила зависят от конкретных данных и бизнес-процесса.
Дорогой проб и ошибок
Я легко рассказал о четырех правилах, по которым HFLabs выбирает лучшие данные. Даже в них нашлось место для исключения. В реальной жизни еще веселее: у клиентской карточки сотни атрибутов, многим нужны специальные правила:
- адреса,
- телефоны,
- емейлы,
- документы (все виды паспортов, права),
- ИНН,
- СНИЛС,
- даты и места рождения.
И это только часть атрибутов клиента. А есть еще связанные сущности: автомобили, договоры, контракты, лицевые счета...
А есть еще взаимосвязанные правила:
- используем дату рождения для проверки корректности даты выдачи документа;
- используем адрес для проверки корректности кода города.
Данные изменяются в десятках исходных систем каждый день. Это все нужно учитывать в правилах обновления и слияния.
В «Едином клиенте» уже есть готовые модели для банков, страховых и телекомов. Мы собирали и настраивали их годами. Для каждого поля или атрибута есть наборы правил обновления и слияния, они требуют лишь подстройки при внедрении. Поэтому «Единый клиент» приносит бизнес-пользу уже в первый месяц.