1. Описание проблемы

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

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

Предположим, что имеется три источника данных, содержащих следующие типы информации о клиентах:

Источник1(SSN, электронная почта, адрес)

Источник2(SSN, телефон, имя, возраст)

Источник3 (электронная почта, телефон, пол)

Кроме того, предположим, что SSN, адрес электронной почты и номер телефона достаточны для однозначной идентификации человека (то есть они представляют собой PII, личную информацию). В реальном мире телефонные номера и адреса электронной почты могут не однозначно идентифицировать человека, но в этом примере мы предполагаем, что это так. Проблема в том, что в разных источниках используются разные идентификаторы, и в отдельных записях может отсутствовать некоторая информация. Со временем отсутствующая личная информация клиента может появиться позже в другом источнике данных. Цель состоит в том, чтобы использовать любую PII, которая у нас есть о клиенте, чтобы найти всю информацию (атрибуты) клиента во всех источниках данных.

Во-первых, если мы не объединим таблицы данных, то попытка собрать воедино информацию об одном клиенте во время выполнения будет очень сложной и очень несистематической. Например, если мы хотим выполнить поиск по SSN 123–45–7890, чтобы найти всю информацию об этом клиенте, нам нужно сделать следующее:

1. Найдите Source1 в столбце SSN, чтобы найти значения Address и Email.

2. Если в Source1 присутствует значение Email, используйте это значение Email (скажем, e1) для поиска Source3 в столбце Email, чтобы найти значения Пол и Телефон.

3. Если значение телефона присутствует в источнике 3, используйте это значение телефона (скажем, p1) для поиска в источнике 2, чтобы найти имя и возраст.

4. Нам также нужно выполнить поиск Source2 в SSN, чтобы увидеть, есть ли совпадающая запись.

Мы можем попробовать разные последовательности поиска в трех источниках данных, чтобы собрать воедино всю информацию об одном клиенте. Например, мы можем сначала выполнить поиск Source2 в столбце SSN, а затем выполнить поиск Source3 и Source1. Тем не менее, любая стратегия поиска будет иметь одинаковую сложность. Этот тип сбора информации о клиентах взад и вперед не только медленный, но и неуправляемый, учитывая сложность добавления дополнительных источников данных.

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

Клиент (SSN, электронная почта, телефон, имя, возраст, пол, адрес).

Непосредственная проблема использования РСУБД с таким подходом заключается в том, что мы не знаем, какой PII следует использовать в качестве первичного ключа (который не допускает отсутствия информации и не может быть NULL), поскольку в какой-то момент любая PII может отсутствовать. Мы могли бы добавить сгенерированный системой уникальный идентификатор CustomerID в каждую строку таблицы Customer, чтобы обойти требование первичного ключа. Однако, когда нам нужно объединить записи из нескольких источников данных в одну запись в таблице Customer, нам нужно собрать воедино информацию из нескольких источников данных (аналогично рассмотренному ранее примеру поиска). Реляционные базы данных не предназначены для сложной обработки ETL, требующей неизвестной длины «связывания» и «объединения» различных записей. Каждый новый источник данных с новым идентификатором или новым атрибутом потребует прохождения этого медленного и сложного процесса поиска по нескольким атрибутам в поисках соответствия, а затем создания или изменения таблицы. Опытные разработчики СУБД и администраторы баз данных знают о присущих СУБД ограничениях для обработки этого типа ETL и разрешения сущностей.

2. Решение на основе графа

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

2.1 Моделирование графов

Рекомендуемое решение на основе графа — создать вершину клиента для каждого клиента, связанную с различными вершинами PII, такими как SSN, электронная почта, телефон.

На рис. 1 показан пример схемы графа (созданной в GraphStudio, визуальном SDK на основе браузера TigerGraph). Каждая вершина Customer представляет уникального клиента. Каждая вершина PII (телефон/SSN/электронная почта) представляет уникальное значение PII. Эта схема представляет нашу гибкую и расширяемую концепцию идентификатора для Клиента. Достаточно любого из трех типов вершин, и можно добавить больше. Все остальные атрибуты (такие как возраст, пол и адрес) будут храниться в вершине клиента.

2.2 Загрузка данных и создание графика

Сначала мы покажем шаг за шагом, как по мере загрузки данных мы постепенно строим и объединяем график. Затем мы суммируем шаги в виде алгоритма.

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

Мы будем читать данные сверху вниз, от источника 1 к источнику 3, сверху вниз.

Строка 1: Первая строка данных в Source1, ‹s1, _, a1›, создает график, показанный ниже.

Так как SSN s1 никогда не было в графе, создается вершина SSN s1. Поскольку в этой записи нет электронной почты, мы не создаем вершину электронной почты и не пытаемся сопоставить ее с существующей вершиной электронной почты. Каждая запись данных должна соответствовать новому или существующему клиенту, поэтому создается новая вершина клиента U1 с данными атрибута Address=a1, и добавляется ребро между двумя вершинами (U1 и s1).

Строка 2: при загрузке второй строки в Source1‹_,e1, a2› создается график, показанный ниже.

Поскольку Email e1 ранее не отображался на графе, создается новая вершина Email e1. Поскольку значение SSN отсутствует, мы не можем связать эту запись с каким-либо существующим клиентом. Таким образом, создается новая вершина Заказчика U2 и создается ребро между двумя вершинами (U2 — e1).

Строка 3: при загрузке третьей строки в Source1‹s2, e2, a3› создается график, показанный ниже.

Поскольку в графе нет ни s2, ни e2, создаются две новые вершины (вершина SSN s2, вершина Email e2), создается одна вершина Customer U3 и добавляются два ребра (U3 — s2 и U3 — e2).

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

Строка 4: Загрузка первой строки в Source2 ‹s1, p1, n1, 22› дает график, показанный ниже.

Поскольку s1 уже есть в графе, мы отмечаем его Заказчика U1. Поскольку p1 еще нет в графе, создается телефонная вершина p1 и добавляется ребро между p1 и вершиной U1 клиента s1. Кроме того, мы добавляем значения атрибутов Name=n1 и Age=22 в U1. Обратите внимание, что здесь мы фактически «объединяем» две записи: первую запись Source1 и первую запись Source2.

Строка 5: Загрузка второй строки в Source2 ‹s2, p2, n2, 32› дает график, показанный ниже.

Поскольку вершина SSN s2 уже присутствует в графе, создается только вершина Phone p2, а новая вершина Customer не создается. Добавляется ребро между вершиной U3 Клиента p2 и s2. Мы снова объединяем две записи, последнюю запись Source1 и последнюю запись Source2.

Строка 6: Наконец, загрузка первой строки в Source3 ‹e1, p1, f› дает график, показанный ниже.

И e1, и p1 уже есть в графе, но связаны с двумя разными вершинами Customer (U2 и U1 соответственно). Если мы уверены, что все наши значения данных верны и являются уникальными идентификаторами, то вершины Customer U1 и U2 должны быть объединены.

Обратите внимание, что здесь возникает проблема конфликта данных: U1 имеет адрес a1, а U2 имеет адрес a2. Как мы должны обрабатывать конфликты данных при объединении двух вершин?

В TigerGraph это полностью зависит от пользователя или бизнес-требований каждого варианта использования. Пользовательские функции можно использовать в сочетании с богатой семантикой GSQL, чтобы решить, нужно ли выполнять слияние, а затем как выполнять слияние. Например, при объединении нескольких значений в один атрибут вы можете сохранить старое значение, использовать более новое значение или объединить/добавить их в виде списка значений (и запомнить их источники для управления происхождением/происхождением данных). В этом примере мы сохраняем вершину U1 и адрес a1 для простоты.

2.3 Алгоритм слияния данных и разрешения сущностей

Следующий псевдокод обобщает шаги, которые мы представили в нашем примере выше:

Используя язык TigerGraph высокоуровневая загрузка GSQL, выражение этой бизнес-логики в виде задания загрузки с параллельной обработкой является простой задачей.

2.4 Запрос клиента

Запросить клиента с использованием любого поля PII или комбинации полей PII очень просто. Например, по любому адресу электронной почты, телефону или SSN мы можем быстро найти вершину Customer, связанную с такой входной вершиной PII, и все атрибуты, связанные с вершиной Customer. В частности, запрос GSQL, например

getCustomer(SSN s1, телефон p1, электронная почта e1)

принимает список ввода PII и возвращает всю информацию о клиенте, связанную с вводом PII. Единственным требованием к входным данным запроса является наличие хотя бы одной PII.

3. Резюме

Базы данных Graph предоставляют понятный и эффективный способ объединения наборов данных и выполнения критического разрешения сущностей:

  1. Гибкость схем графов позволяет легко обрабатывать отсутствующую информацию и динамические изменения схемы.
  2. Параллельная загрузка и преобразование на основе графов делает отображение и разрешение данных эффективным и простым в управлении.
  3. Вывод на основе графа делает цепочку/объединение записей (сущностей) простым и эффективным.

Мощная технология Native Parallel Graph от TigerGraph [1] предлагает лучшую платформу для разрешения сущностей клиентов. Разрешение сущностей клиентов на основе графа — это только один пример использования возможностей графовой базы данных. Соединение ваших данных и построение истинного графика знаний Customer 360 или другого — это только начало. Реальные преимущества быстрой, гибкой и масштабируемой графовой базы данных вытекают из доступных вам запросов, аналитики и полученных результатов. Профилирование клиентов на основе графов с использованием таких методов, как кластеризация вершин, сходство вершин и соседей, ранжирование по влиянию, временной анализ и прогнозирование оттока, позволит получить полезную информацию, обогащая и расширяя возможности любого предприятия и ставя вас впереди других.

[1] Native Parallel Graph: следующее поколение базы данных Graph для аналитики Deep Link в реальном времени.

Исходное сообщение: https://www.tigergraph.com/2018/12/18/graph-based-customer-entity-resolution/