Можем ли мы использовать исходный соединитель kafka JDB C для извлечения данных из нескольких баз данных и помещения их в один вход topi c? - PullRequest
0 голосов
/ 27 апреля 2020

У нас есть сценарий использования, при котором бизнес-логика c требует, чтобы мы объединяли таблицы из разных баз данных и выводили конечный результат * sh. * Topi c.

table1 from schema1 in database1

table2 from schema2 in database2

Бизнес логи c

SELECT a,b FROM table1 INNER JOIN table2 ON table1.c = table2.d;

здесь a от table1 и b от table2, а значение сообщения на входе topi c выглядит следующим образом: { "payload":{ "a":xyz,"b":xyz} }

Есть ли способ выполнить это требование с помощью одного разъема источника jdb c?

PS :

  • Я ссылался на Может ли JDB C Kafka Connector извлекать данные из нескольких баз данных? , но в принятых ответных сообщениях выдвигаться на ввод topi c без Внедрение любых бизнес логи c. С этой реализацией мы не сможем отправить sh сообщение для ввода topi c согласно нашему требованию.
  • Альтернативным способом было бы использование потоков kafka, то есть pu sh сообщений для введите topi c из каждой таблицы и обработайте объединяющие логики c на уровне приложения потока kafka. Но мы ищем решение, если бы мы могли реализовать logi c на самом уровне соединителя?

1 Ответ

1 голос
/ 27 апреля 2020

Краткий ответ: Нет, таким способом нельзя использовать разъем источника JDB C.

Более длинный ответ: исходный соединитель JDB C может подключаться к одной базе данных на экземпляр экземпляра. У вас есть несколько вариантов:

  1. Потоковое содержимое обеих таблиц в Kafka и использование ksqlDB (или Kafka Streams, если вы предпочитаете), чтобы присоединиться к ним и передать sh полученные данные в новый Kafka. топи c.
  2. Напишите новый подключаемый модуль, который подключается к обеим базам данных и выполняет объединение (это звучит как ужасная идея)
  3. Если база данных поддерживает это, используйте удаленное объединение (например, Oracle DB Link) и опцию JDB C исходного соединителя query.

В зависимости от объемов данных и сложности запросов лично я go для варианта 1. ksqlDB идеально подходит здесь.

...