KSQL — изменение часового пояса в предложении WINDOW TUMBLING

Вот мой KSQL с использованием пункта WINDOW TUMBLING:

SELECT 
    sale_date,
    region,
    SUM(total)
FROM orders
WINDOW TUMBLING (SIZE 24 HOURS)
GROUP BY sale_date, region;

Некоторый результат:

2018-09-29|+|zskx_fz : Window{start=1538179200000 end=-} | 2018-09-29 | zskx_fz | 16119.8
2018-09-30|+|zskx_fz : Window{start=1538179200000 end=-} | 2018-09-30 | zskx_fz | 2031.6
2018-09-30|+|zskx_fz : Window{start=1538265600000 end=-} | 2018-09-30 | zskx_fz | 894.7

И эпоха миллис до настоящего времени:

1538179200000 = 2018-09-29 08:00:00 (UTC+8)
1538265600000 = 2018-09-30 08:00:00 (UTC+8)

Как мы видим, я в UTC+8. Но независимо от часового пояса, start время даты должно быть 2018-09-29 00:00:00 не на 8 часов раньше. Так он может изменить часовой пояс?

PS: я попробовал несколько размеров окна в 2018-09-30 11:33:00, и я полностью проиграл..

WINDOW TUMBLING (SIZE 1 minutes)    2018-09-30 11:32:00
WINDOW TUMBLING (SIZE 2 hours)      2018-09-30 10:00:00
WINDOW TUMBLING (SIZE 5 hours)      2018-09-30 07:00:00
WINDOW TUMBLING (SIZE 10 hours)     2018-09-30 02:00:00
WINDOW TUMBLING (SIZE 11 hours)     2018-09-30 07:00:00
WINDOW TUMBLING (SIZE 12 hours)     2018-09-30 08:00:00
WINDOW TUMBLING (SIZE 24 hours)     2018-09-30 08:00:00

apache-kafka confluent-platform ksqldb
person Archon    schedule 30.09.2018    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Окна временных меток всегда рассчитываются относительно эпохи, то есть UTC/GMT.

Я вижу обоснованность желания агрегировать по дням в зависимости от вашего часового пояса. Я поднял ее как проблему проекта KSQL github и предлагаю вам отслеживать это там.

person Robin Moffatt    schedule 01.10.2018

arrow_upward
1
arrow_downward

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

<sale_date BIGINT, region VARCHAR, total DOUBLE>

Предполагая, что sale_date — это отметка времени продажи, а наше местное время — PST, мы можем использовать функцию TIMESTAMPTOSTRING для извлечения разной степени детализации времени для каждой продажи для заданного часового пояса следующим образом:

CREATE STREAM foo AS SELECT TIMESTAMPTOSTRING(sale_date, 'yyyy-MM-dd HH', 'PST') AS sale_hour, TIMESTAMPTOSTRING(sale_date, 'yyyy-MM-dd', 'PST') AS sale_day, TIMESTAMPTOSTRING(sale_date, 'yyyy-MM', 'PST') AS sale_month, region, total FROM orders; Теперь вы сможете писать агрегированные запросы по этому потоку. Например, для ежедневных продаж для каждого региона вы можете написать следующий запрос:

CRAETE TABLE daily_sale AS SELECT sale_day, region, sum(total) FROM foo GROUP BY sale_day, region;

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

person Hojjat    schedule 08.10.2018