Связать таблицу с потоком Кафки / KSQL?

Question

Я импортирую БД, которая содержит некоторую таблицу ссылок, представляющую отношения «многие ко многим» и «один ко многим».

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

Следовательно, у меня есть таблица BioAssay [BioAssay, ..., ..., ...] и таблица ссылок [Document, BioAssay].

В конечном итоге мне нужно объединить эти 2 в полный биоанализ со всем его документом, например. [BioAssayxyz, ...., "Документ1: Документ2: Документ3"]

Интересно, кто-нибудь здесь может дать мне представление о том, что должно произойти с потоком Кафки?

1 - До сих пор, исходя из моего понимания потока Кафки, кажется, что мне нужен поток для каждой таблицы ссылок, чтобы выполнить агрегацию. KTable не будет использоваться, потому что записи обновляются для каждого ключа. Однако результат агрегации может быть в Ktable.

2 - Затем возникает проблема объединения внешних ключей. Кажется, единственный способ сделать это через GlobalKtable. link-table-topic-> link-table-stream-> link-tableGlobaKTable. Это может привести к большому использованию дискового пространства, так как моя таблица очень большая. Это очень большая БД с большим количеством таблиц, и это требование построения нескольких логических представлений данных является частью ядра проекта и его нельзя избежать.

а) Понимаю ли я это прямо здесь?

б) Это единственный способ справиться с этим?

EDIT1

Похоже, единственное, что существует, это KStream-to-GlobalKTable, похоже, мне нужно немного перевернуть все с ног на голову. Моя исходная таблица БД BioAssay должна быть превращена в поток, в то время как моя таблица документов ссылок должна быть сначала превращена в поток для агрегирования, а затем в таблицу GlobalKTable для объединения.

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

Answer 1

Несколько месяцев назад мне довелось поработать над аналогичным сценарием использования Kafka Streams, и я рад поделиться своими знаниями.

Использование KStreams-to-KTable, как вы предлагаете, будет работать, хотя и с некоторыми оговорками, которые могут быть неприемлемы для вас.

Во-первых, напомним, что соединение потоков с таблицами обновляется Kafka Streams только при получении нового события на стороне потока, а не на стороне ktable.

Во-вторых, если вы используете CDC для импорта БД, то, насколько я понимаю, у вас нет гарантий порядка, в котором обновления попадают на Кафку. Это означает, что даже если вы наслаждаетесь изоляцией транзакции на стороне БД, которая делает обновление или вставку в таблицы Document и BioAssay «все сразу», на стороне Кафки вы получите один, а затем другой в произвольном порядке.

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

Решение, которое я выбрал, состояло в том, чтобы пойти «под капот» и присоединить свои потоки вручную, используя Processor API. Это позволило достичь семантического объединения таблиц, которое обновляется всякий раз, когда обновляется любая из сторон. Я описал основную идею в этом посте:

https://svend.kelesia.com/one-to-many-kafka-streams-ktable-join.html

Используя эту технику, я смог правильно импортировать из БД отношения «один ко многим» и «многие ко многим».

Answer 2

Если в ваших таблицах используется один и тот же ключ (т. Е. Внешний ключ), вы можете использовать это в своих интересах и направить все свои таблицы в одну и ту же тему (вы можете использовать несколько разделов для масштабирования).