Ключ в том, что KTable
разделен, что означает, что если у вас есть основная тема с N разделами, экземпляр, который заботится о подмножестве этих разделов, будет иметь доступ к данным этих разделов, но не кданные о разделах, которыми этот экземпляр не управляет.
Однако GlobalKTable
будет использовать все данных темы в всех экземпляров.Например, вы хотите использовать его для объединения с набором внешних данных, разделение которых напрямую не связано с входящими данными (или не может быть предсказано их отношение).
Например, скажем, у вас есть поток из темы users
, с циклическим разбиением по умолчанию, который имеет поле country
, и вам нужно обогатить этот поток users
данными из страны пользователя,Затем вы можете использовать GlobalKTable
с данными для стран и присоединиться, например, к потоку users
с этим country GlobalKTable
по стране.
Поскольку GlobalKTable предоставляет вам доступ ко всем потенциальным присоединяемым данным, он намного эффективнее KTable для небольших данных, поскольку вам не нужно перераспределять данные для этого объединения(все данные прямо там).Но вы должны знать о размере: вы должны обрабатывать все наборы данных в каждом из разделов.Вот почему он обычно используется в коллекциях данных ограниченного размера, а не сверхбольших.
Если вы выполняете объединение между KStream
и KTable
, потребуется перераспределение данных (создание внутренней темы), чтобы перегруппировать данные в соответствии с ключом присоединения.
Точно так же, если вы используете Processor API, если вы запрашиваете KTable
из экземпляра, у вас будут данные, сгенерированные этим экземпляром, а не другие экземпляры.
ОБНОВЛЕНИЕ : Также см. @ Matthias-j-sax комментарий о синхронизации.