Главная » Хабрахабр » Проблемы матчинга и как можно с ними бороться

Проблемы матчинга и как можно с ними бороться

Добрый день! Меня зовут Алексей Булавин, я представляю центр компетенций Сбертеха по Big Data. Представители бизнеса, владельцы продуктов и аналитики часто задают мне вопросы по одной и той же теме — матчинг. Что это такое? Зачем и как его делать? Особенно популярен вопрос «Почему он может не получиться?» В этой статье я постараюсь на них ответить.

Начнем с бытового примера. У меня есть маленький сын. Недавно он освоил мобильный телефон и теперь любит таскать его с собой, чтобы, как взрослый, непринужденно позвонить кому-нибудь когда вздумается и поговорить на какую-нибудь «очень важную» тему. Звонит он только маме, папе и бабушке. Больше всего достается бабушке: порой он по 10 раз в день звонит ей, чтобы рассказать, что с ним произошло 5 минут назад.

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

Дела подождут. — Почему бы тебе не позвонить и не поболтать с другом о том о сем, обсудить свои дела?
— Папа, мне это совсем не нужно, мы и так встречаемся в саду каждый день и, если что, поговорим там.

Выяснилось, что просто ни он, ни Денис не знают своего собственного номера телефона и не могут ими обменяться. Мне стало интересно, как же так? Налицо отсутствие связи из-за отсутствия ключей.

Что же такое матчинг?

Новые средства взаимодействия в обществе порождают новые возможности, более тесно связывают людей, а системам указывают об их связанности. Матчинг — это один из типов связанности, который указывает на отношения субъекта с самим собой. Например, когда на разных досках объявлений продается одна и та же машина, а мы хотим связать и воспринимать эти объявления вместе, как единое целое.

Зачем нужен матчинг?

Информация сегодня представляет ценность, которую можно монетизировать. Соответственно, дополнительная информация дает дополнительную ценность, увеличение прибыли или сокращение издержек — с помощью разработки новых фич, качественного изменения существующих или вообще создания новых продуктов.

Чем больше дополнительной информации из новых источников мы получаем, тем актуальней становится задача объединения информации из всех источников в единое информационное пространство, как будто это атрибуты одной системы. Как правило, наш продукт четко связан с теми или иными объектами, знания по которым мы хотим обогащать.

Трудности матчинга

Добыть и связать данные — вроде бы стандартная техническая задача. Но из-за ряда проблем это бывает затруднительно или вовсе невозможно:

  • Нет общих ключей

Люди, организации, объекты  – в каждой новой системе все регистрируются заново и получают новые собственные идентификаторы.

  • Нет ключей вообще

Для некоторых типов данных ID присваивается отдельным событиям или сообщениям в потоке, а не тому объекту, который нас интересует. Например, система фиксирует кредитные заявки, и если один и тот же человек оформит две отдельные заявки, то это будет два разных ID. А для самого человека ID в системе не будет.

  • Записи по ключу не уникальны

В идеале каждому уникальному ID соответствует уникальный объект, но на практике это бывает не так. Например, машина сменила цвет или номер ПТС, человек сменил фамилию или пол. По формальным признакам для автоматической системы это новый объект. Также проблема может возникнуть если, например, оператор вместо поиска уже существующей записи в базе просто заводит новую — так ему проще.

  • Записи по ключу ошибочны или преднамеренно испорчены

Например в социальных сетях, где владелец странички искажает свое имя и фамилию или совсем заменяет их на вымышленные. Можно найти десятки Иванов Ургантов или Владимиров Познеров, и это не однофамильцы.

  • Записи по ключу непостоянны

В разное время для одного и того же ID можно ожидать разные объекты или субъекты. Например, когда у телефонных номеров меняются владельцы.

Можно попробовать собрать ключ как комбинацию нескольких информационных полей, составной ключ. Получается, что связать объекты двух систем между собой по ключу бывает либо невозможно, либо процент и качество связанности оказываются ниже желаемого уровня. Но здесь возникают новые трудности:

  • Поля составного ключа недостаточно заполнены

Никто не обещает, что обычные информационные поля будут «not null». А дальше как повезет. Чем больше полей в составном ключе, тем больше вероятность, что какие-то ключи не будут получаться.

  • У полей в составном ключе разные стандарты заполнения

Например, адрес офиса организации заполняется произвольным образом: д.5 к.2 офис 16; дом 5 корпус 2 офис 16; 5-2-16.  Или телефон: +7(495)344-3…, 8-495-344…, 495344….

Поля, входящие в составной ключ, тоже могут быть не уникальны, ошибочны, преднамеренно искажены и не постоянны. Кроме того, для информационных полей в составном ключе характерны трудности, которые мы упоминали ранее.

Количество vs качество

Как же победить перечисленные выше трудности и добиться 100% матчинга? Начать стоит с вопроса: а действительно ли нужно достигать таких высоких уровней качества? Может, для решения бизнес-задачи вполне достаточно 70%?

Каждый из них с некоторой вероятностью будет заполнен и с некоторой вероятностью подойдет для применения в качестве элемента ключа. Есть у нас составной ключ, состоящий из набора атрибутов. Все это еще нужно умножить на вероятность того, что объект в принципе присутствует в двух системах. Вероятность что весь составной ключ будет нормален — это произведение всех вероятностей по всем атрибутам ключа. А умножив ее на общее число сущностей, получим количественный прогноз по сопоставлению.
Чем меньше атрибутов в составном ключе, тем вероятность матчинга выше и при этом ближе к вероятности того, что объект есть в двух системах. Тогда мы получим вероятность матчинга. Это связано с тем, что с уменьшением числа атрибутов в составном ключе растет вероятность ошибочного сопоставления. Но количество сопоставлений при этом растет и чаще всего превышает прогноз.

Как бы количество борется против качества. Проще говоря, с уменьшением количества атрибутов в составном ключе растет как число объектов сопоставленных правильно, так и число сопоставленных ошибочно. И в зависимости от бизнес-задачи можно выбрать стратегию матчинга, смещающую результат либо в сторону количества, либо в сторону качества.

Обогащение, фильтрация, нормализация

А можно ли увеличить качество и количество одновременно? Конечно можно. Для этого нужно потратить больше, а иногда и намного больше ресурсов на дополнительную обработку данных.
«Дырки» в данных можно заполнять, получая их из других полей источника. Город локации можно получить из кода телефонного номера, ИНН, кода региона. Пол можно получить из имени и фамилии или по анализу авторского текста. Алгоритмов обогащения достаточно много.

Фильтры могут быть как стандартные, так и специфические, связанные с особенностями наполнения и трансформации данных конкретного источника. Далее данные следует пропускать через фильтры. Например, к стандартным можно отнести фильтр, убирающий непечатные символы, дубли, задвоения символов, скобки, кавычки, пробелы.

Или обнаружение и замену символов другой языковой раскладки, которые звучат одинаково или почти одинаково в обоих языках (Света и Sвета). К специфичным фильтрам можно отнести обнаружение и замену символов другой языковой раскладки, которые выглядят одинаково визуально в обоих языках — например, буква О в английской раскладке в имени Оля.

К нормализации можно отнести перевод на другой язык, транслитерацию, приведение к шаблону заполнения (название, марка, телефон, адрес, пол), а также замену коротких названий на полные, замену сленга и уменьшительно-ласкательных форм.

Это связано с тем, как конкретный источник заполняется данными. Даже при одном составе ключа для разных источников данных зачастую следует использовать разные критерии. На улучшение качества может повлиять применение коэффициента частотности по полю в источнике (например, для марки машины, фамилии), коэффициента «емкости» (например, для названия населенного пункта в зависимости от того, насколько большой этот населенный пункт по количеству жителей). Чтобы правильно подобрать критерии, желательно собрать и проанализировать статистику по заполнению полей источника.

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

Другие матчинги

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

У любой машины или квартиры за всю ее историю, в среднем, имеется от 1 до 5 владельцев. Приведем пример. Если в двух системах объект квартиры или машины проматчен по сильному ключу, то субъекта — владельца этой квартиры, явно с ней связанного — можно матчить по любому самому слабому параметру, например фамилии и имени.

Сами объекты матчинга могут иметь в дополнение собственный слабый ключ, а могут не иметь. Объекты любой социальной сети или подобной ей структуры данных с большим числом устойчивых связей можно матчить по слабым ключам, принадлежащим не самому объекту матчинга, а его окружению. Фактически алгоритмизируется утверждение древнегреческого поэта Еврипида: «Скажи мне, кто твои друзья, и я скажу тебе, кто ты».

На фото выделяются объекты или лица и сравниваются с такими же объектами или лицами в другом источнике. Для двух источников с одной или несколькими фотографиями объектов, которые явным образом связаны с их идентификаторами в источниках, можно применить матчинг по фотографиям. Критерий для матчинга специально выбран мягким, чтобы получалось отдаленное, но достаточное сходство. По сути, по такому принципу работают нейросетевые сервисы типа «Is your portrait in a museum?» от Google: они матчат лицо с загруженной вами фотографии с лицами средневековых людей на портретах музеев.

При наличии большого числа авторской текстовой информации в разных источниках можно попробовать алгоритмы text mining, чтобы связать авторов. Это что-то вроде анализа почерка, только анализируется не форма написания, а содержание текста.

Big data

Чтобы повышать качество матчинга, требуется применять различные алгоритмы, которые в свою очередь требуют много ресурсов. Чем больше алгоритмов, тем больше ресурсов требуется. А если данных много, они постоянно изменяются, а считать их нужно быстро и недорого?

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

Это решение позволяет обрабатывать разнородные неструктурированные данные большого объема, запускать вычисления на большом кластере, где хранятся данные без накладных расходов. В Сбербанке, например, матчинг внутрикорпоративных данных реализован  как компонент data lake на Hadoop, Spark и HBase. Про Big Data на Hadoop написано много. При этом используется опенсорсный софт и commodity-сервера, что делает решение достаточно дешевым и эффективным для такого класса задач. Мне, например, вполне нравится, как это сделано у DataArt.

Наш MatchBox

MatchBox — это система для автоматической нормализации и матчинга, которую мы используем в data lake Сбербанка. Она была недавно разработана в центре компетенций Big Data Сбертеха.
MatchBox в основном используется для построения и поддержания в актуальном состоянии единого семантического слоя данных и единого профиля клиента. Система дает возможность автоматически объединять информацию из большого числа источников в единую информационную суперсущность, встраиваться в процесс обновления информации источников. Это обогащает знания о текущих и потенциальных клиентах банка: их социально-демографических, психологических, поведенческих особенностях и потребительских предпочтениях.

MatchBox умеет масштабироваться, и количество регулярно обрабатываемых источников ограничивается только ресурсными квотами кластера. MatchBox работает с данными любого качества, использует библиотеки с провалидированными алгоритмами нормализации и матчинга, имеет для этого конфигуратор пользовательских правил, работает в полностью автоматическом режиме по событию, расписанию или как сервис.

Вот чего нам удалось добиться благодаря внедрению MatchBox:

  • высокая скорость обработки больших объемов при низкой себестоимости процесса
  • объединение большого числа источников
  • полная автоматизация матчинга на bigdata-кластере — и, как следствие, низкая стоимость
  • регулярность матчинга — при использовании в регулярных циклических бизнес-процессах финансовые издержки снижаются
  • высокое качество матчинга за счет нормализации, обогащения и подбора оптимальной конфигурации — стоимость конечных данных повышается
  • вариативность матчинга благодаря конфигурированию правил — стоимость внедрения новых инициатив снижается
  • унификация публикуемого результата (низкой стоимости внедрения новых инициатив)
  • выстраивание цепочек матчинга

Сейчас мы также исследуем и пилотируем сложные комбинаторные матчинги, графовые матчинги, матчинги по фото. А для источников, требующих высокой точности — подсистему валидации.

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


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

[Из песочницы] Ночник с выключением по расписанию

Где-то прочитали, что он необходим для спокойного сна. С рождением ребёнка встал вопрос о ночнике. Очень удобно просыпаться от криков и воев среди ночи и видеть на что жалуется малыш (если удастся понять). Быстро привыкли спать с тусклым светом. Так ...

Почему я не верю микробенчмаркам

Скриншот с сайта с микробенчмарками"/>Думаю, что одного этого скриншота реально существующего замера производительности хватит, чтобы донести смысл статьи, но, если читателю интересны мои мысли на этот счет, то добро пожаловать. <img src="http://orion-int.ru/wp-content/uploads/2018/12/pochemu-ya-ne-veryu-mikrobenchmarkam.png" alt="typescript работает быстрее javascript и занимает меньше памяти. ...