Должны ли таблицы K SQL отображать несколько строк на ключ для агрегатов? - PullRequest
Новая
       27

Должны ли таблицы K SQL отображать несколько строк на ключ для агрегатов?

0 голосов
/ 25 мая 2020

Насколько я понимаю, таблицы K SQL показывают, что они показывают наши данные в виде « как есть », а не всех данных. Поэтому, если у меня есть простой агрегатный запрос и я ВЫБИРАЮ из своей таблицы, я должен видеть данные такими, какие они есть на данный момент.

Мои данные (поток): 

MY_TOPIC_STREAM:

15 | BEACH  | Steven Ebb    | over there
24 | CIRCUS | John Doe      | an adress
30 | CIRCUS | Alice Small   | another address
35 | CIRCUS | Barry Share   | a home
35 | CIRCUS | Garry Share   | a home
40 | CIRCUS | John Mee      | somewhere
45 | CIRCUS | David Three   | a place
45 | CIRCUS | Mary Three    | a place
45 | CIRCUS | Joffrey Three | a place

Определение моей таблицы: 

CREATE TABLE MY_TABLE WITH (VALUE_FORMAT='AVRO') AS 
  SELECT ROWKEY AS APPLICATION, COUNT(*) AS NUM_APPLICANTS 
  FROM MY_TOPIC_STREAM
  WHERE header->eventType = 'CIRCUS' 
  GROUP BY ROWKEY;

Я не понимаю, почему я вижу несколько строк в моей таблице, даже если возможные агрегаты верны? 

    SELECT * FROM MY_TABLE;

    APPLICATION       NUM_APPLICANTS
    24                1
    30                1
--> 35                1 <-- why do I see this?
    35                2
    40                1
--> 45                1 <-- why do I see this?
--> 45                2 <-- why do I see this?
    45                3

Моя раковина topi c также показывает мне то же самое, что и вывод таблицы - предположительно, это правильно?

Я ожидал, что результат моей таблицы будет: 

    APPLICATION       NUM_APPLICANTS
    24                1
    30                1
    35                2
    40                1
    45                3

Выводы сокращены для краткости и удобочитаемости выше, но вы понимаете суть.

Итак, мои ожидания таблицы и раковины topi c выходят не на должном уровне?

UPDATE Ответ Матиаса ниже правильно объясняет, что таблица и раковина topi c показывают события журнала изменений, поэтому это нормально увидеть промежуточные значения. Однако меня смущало то, что я видел все промежуточные строки. Оказалось, что это произошло потому, что я использовал конфлюэнтную комбинацию 5.2.1 docker -compose, которая устанавливает переменную окружения KSQL_STREAMS_CACHE_MAX_BYTES_BUFFERING=0. Это отключает кеширование всех промежуточных результатов в агрегатах K SQL, и поэтому в таблице отображается больше строк, чем ожидалось, но в конечном итоге достигается правильные агрегаты. При установке, например, 10 МБ данные будут выводиться, как и ожидалось. Эта функция не сразу очевидна в документации для тех, кто начинает играть с K SQL и использует docker для защиты от инстансов! Эта проблема указала мне правильное направление, и эта страница документирует параметры. Я потратил на это много времени и не мог понять, почему он не работает так, как ожидалось! Надеюсь, это кому-то поможет.

1 Ответ

1 голос
/ 25 мая 2020

Не уверен, какую версию вы используете, однако SELECT * FROM MY_TABLE; возвращает не текущее содержимое таблицы, а поток таблицы changelog (это справедливо для более старых версий; в более новой версии запрос, который вы показываете, недействителен, так как синтаксис был изменен).

После перехода с K SQL на ksqlDB, показанный вами запрос будет называться pu sh запрос выражается как SELECT * FROM my_table EMIT CHANGES;.

Кроме того, ksqlDB представил pull-запросы , которые позволяют вам искать текущее состояние. Однако SELECT * FROM my_table; пока не поддерживается как пул-запрос (он будет добавлен в будущем). Вы можете выполнять поиск в таблице только для указанного ключа c, то есть в данный момент должно быть предложение WHERE.

Дополнительные сведения см. В документации: https://docs.ksqldb.io/en/latest/concepts/queries/pull/

...