Как мне объединить связанные записи в apache beam / data flow, основываясь на сотнях правил? - PullRequest
Новая
       25

Как мне объединить связанные записи в apache beam / data flow, основываясь на сотнях правил?

0 голосов
/ 04 ноября 2018

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

Пример данных 

Source System 1:
{userid = 123, first_name="John", last_name="Smith", many other columns...}

Source System 2:
{userid = EFCBA-09DA0, fname="J.", lname="Smith", many other columns...}
  • Существует около 100 правил, которые я могу использовать для сравнения одной записи с другой. чтобы увидеть, совпадает ли клиент в исходной системе 1 с исходной системой 2.
  • Некоторые правила могут определять значения записей и добавлять данные в основную запись о клиенте.
  • Поскольку некоторые правила могут выводить / добавлять данные к какой-либо конкретной записи, правила должны повторно применяться при изменении записи.
  • У нас есть миллионы записей в день, которые мы должны объединить

Реализация Apache Beam / Dataflow

  • Apache beam DAG по определению является ациклическим, но я мог бы просто переиздать данные через pubsub на тот же DAG, чтобы сделать его циклическим алгоритмом.
  • Я мог бы создать PC-коллекцию хэш-карт, которые непрерывно объединяются самостоятельно со всеми другими элементами, но это, вероятно, неэффективный метод
  • Неизменность PCollection - это проблема, если я хочу постоянно изменять вещи, когда они идут по правилам. Похоже, это было бы более эффективно с Flink Gelly или Spark GraphX

Есть ли какой-нибудь способ, которым вы можете знать в потоке данных, чтобы эффективно обработать такую ​​проблему?

Другие мысли

  • Пролог: я пытался запустить подмножество этих данных с подмножеством правил, но swi-пролог не выглядел масштабируемым, и я не мог понять, как я буду непрерывно передавать результаты другим процессам.
  • JDrools / Jess / Rete: прямое связывание было бы идеальным для логического вывода и эффективного частичного применения, но этот алгоритм больше относится к применению множества правил к отдельным записям, а не к выводу информации о записях из возможных связанных записей.
  • База данных графиков: было бы неплохо что-то вроде neo4j или datomic, поскольку объединения выполняются на уровне записи, а не сканирования строк / столбцов, но я не знаю, возможно ли в луче сделать что-то подобное
  • BigQuery или Spanner: грубое форсирование этих правил в SQL и полное сканирование таблицы для каждой записи действительно медленное. Было бы намного предпочтительнее хранить график всех записей в памяти и вычислять в памяти. Мы также можем попытаться объединить все столбцы и выполнить несколько сравнений и обновлений для всех столбцов

Или, может быть, есть более стандартный способ решения этого класса проблем.

1 Ответ

0 голосов
/ 08 ноября 2018

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

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

  • записи поступают из ряда источников:
    • это логически те же данные, но отформатированные по-разному;
  • Существуют правила, позволяющие определить, представляют ли записи одну и ту же сущность:
    • коллекция правил статична;

Итак, логика, вероятно, выглядит примерно так:

  • прочитать запись;
  • попытаться найти существующие подходящие записи;
  • если найдена соответствующая запись:
    • обновить его новыми данными;
  • в противном случае сохранить запись для последующего сопоставления;
  • повторить;

Для меня это выглядит очень высоким уровнем, и, вероятно, не существует единственного «правильного» решения на этом уровне детализации.

Я бы, вероятно, попытался бы подойти к этому, сначала поняв это более подробно (возможно, вы уже делаете), несколько мыслей:

  • каковы свойства данных?
    • есть шаблоны? Например. когда одна система публикует что-то, ожидаете ли вы чего-то другого от других систем?
  • каковы требования в целом?
    • задержка, согласованность, доступность и т. Д .;
  • как данные читаются из источников?
    • могут ли все системы публиковать записи партиями в файлах, отправлять их в PubSub, нужно ли вашему решению их опрашивать и т. Д.?
    • Можно ли читать данные параллельно или это один поток?
  • тогда главный вопрос о том, как вы можете эффективно сопоставить запись в целом, вероятно, будет выглядеть по-разному при разных предположениях и требованиях. Например, я бы подумал о:
    • можете ли вы разместить все данные в памяти;
    • Ваши правила динамичны. Они вообще меняются, что происходит, когда они делают;
    • можете ли вы разбить данные на категории, которые можно хранить отдельно и эффективно сопоставлять, например, если вы знаете, что можете попытаться сопоставить некоторые вещи по полю id, другие - по хешу и т. д .;
    • вам нужно сопоставить все исторические / существующие данные?
    • можете ли вы использовать логику быстрого исключения, чтобы не выполнять дорогостоящие проверки?
  • каков выход решения? Каковы требования к выходу?
...