KSQL - изменить часовой пояс в предложении WINDOW TUMBLING - PullRequest
Новая
       41

KSQL - изменить часовой пояс в предложении WINDOW TUMBLING

0 голосов
/ 30 сентября 2018

Здесь мой 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

Ответы [ 2 ]

0 голосов
/ 09 октября 2018

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

<sale_date BIGINT, region VARCHAR, total DOUBLE>

Предполагая, что sale_date - это отметка времени продажи, а наше местное время - PST, мы можем использовать * 1007.* функция для извлечения различных временных гранул для каждой продажи для данного часового пояса, как показано ниже:

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;

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

0 голосов
/ 01 октября 2018

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

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

...