KS
причем удалось застать вот такое состояние данных, когда группировка по toDate возвращает вот такой набор
Size: a a a
2020 August 24
KS
а точно такой же запрос с группировко по toStartOfFifteenMinutes() выдает урезанное нечто
KS
и в итоге это всё коллапсирует в 3 строчки, хотя в таблицах источниках явно есть данные по каждому дню
DT
подскажите, 3й день мучаюсь - матвью себя очень странно ведет. при создании с POPULATE нормально заполняется и какое то время данные появляются как ожидается, через какое то вермя данные за текущий день схлопываются в одну строку, еще через какое то время схлопывается весь август - более ранние даты не затрагиваются. В логах с trace - тишина как будто всё работает как надо
покажите Mat view DDL
KS
покажите Mat view DDL
CREATE MATERIALIZED VIEW tmp.table
(
account_id String,
created_dttm AggregateFunction(min, DateTime),
content AggregateFunction(argMin, String, DateTime),
partition_key UInt32
)
ENGINE = ReplicatedAggregatingMergeTree('/clickhouse/tables/{shard}/table', '{replica}')
PARTITION BY partition_key
ORDER BY created_dttm
SETTINGS index_granularity = 8192 AS
SELECT
account_id,
minState(created) AS created_dttm,
argMinState(content_uid, created) AS content,
toYYYYMM(min(created)) AS partition_key
FROM distr.source_events
WHERE lowerUTF8(account_type) = 'test'
GROUP BY account_id
DT
А какой результат то хотите от этого матвью?
KS
поверх матвью идет дист вот такой:
CREATE TABLE tmp.table_dist
(
`account_id` String,
`created_dttm` AggregateFunction(min, DateTime),
`content` AggregateFunction(argMin, String, DateTime),
`partition_key` UInt32
)
ENGINE = Distributed(cluster, tmp, table)
KS
А какой результат то хотите от этого матвью?
результат - получать уникальные account_id по created_dttm+content
DT
Для каждого account_id вам нужны минимальные created_dttm и content относящийся к минимальному created_dttm?
KS
что то вида:
SELECT toDate(dt) date,
content,
uniq(account_id) count
from (
SELECT account_id,
minMerge(created_dttm) AS dt,
argMinMerge(content) AS content
FROM tmp.table_dist
GROUP BY account_id)
WHERE date = today()
group by date, content
DT
В таком случае вам нужен
ORDER BY account_id в DDL mat_view
ORDER BY account_id в DDL mat_view
DT
но в вашем случае я бы посмотрел на ReplacingMergeTree, с столбцом версии что то вроде maxUInt32 - created_dttm
KS
В таком случае вам нужен
ORDER BY account_id в DDL mat_view
ORDER BY account_id в DDL mat_view
расскажите пожалуйста на что это влияет?
DT
расскажите пожалуйста на что это влияет?
aggregatingMergeTree агрегирует по ключу указанному в ORDER BY,
те при ORDER BY account_id для каждого account_id в партиции останется только одна запись в идеальном варианте.
те при ORDER BY account_id для каждого account_id в партиции останется только одна запись в идеальном варианте.
DT
В вашем же случае, вы ключем агрегации указали стейт агрегатной функции, оно возможно вообще не работает нормально.
KS
aggregatingMergeTree агрегирует по ключу указанному в ORDER BY,
те при ORDER BY account_id для каждого account_id в партиции останется только одна запись в идеальном варианте.
те при ORDER BY account_id для каждого account_id в партиции останется только одна запись в идеальном варианте.
спасибо, понял. сейчас попробую поменять ключ, а в чем преимущество реплейсинга тут будет? у меня достаточно много записей на каждого пользователя идет в исходные таблицы, реплейсинг не начнет по скорости сильно проигрывать?
DT
спасибо, понял. сейчас попробую поменять ключ, а в чем преимущество реплейсинга тут будет? у меня достаточно много записей на каждого пользователя идет в исходные таблицы, реплейсинг не начнет по скорости сильно проигрывать?
реплейсинг тупо проще, а значит и считаться будет эффективнее-быстрее
KS
хм, но у меня каждый запрос будет тогда с FINAL
DT
Не обязательно, можно доагрегировать, как вы делаете сейчас с AggregatingMergeTree