Хм, clickhouse-client запущенный по SSH похоже потерял часть данных при копировании в него запроса. Слева на скрине оригинал в текстовом редакторе, справа - CLI кликхауса.
В чем может быть проблема?

клиент надо с ключами запускать -n (начиная с  20...)

тяжело в это поверить.  
select from system.settings where name = что показывает?

нам, чесно-говоря тоже:

SELECT 
    name, 
    value, 
    changed
FROM system.settings
WHERE (changed = 1) AND (name = 'joined_subquery_requires_alias')

┌─name───────────────────────────┬─value─┬─changed─┐
│ joined_subquery_requires_alias │ 0     │       1 │
└────────────────────────────────┴───────┴─────────┘

????

create table aaa(A UUID) Engine=Memory;

INSERT INTO aaa
VALUES ('00000000-0000-0000-0000-000000000000');

Ok.

1 rows in set. Elapsed: 0.001 sec


не случшайте @BloodJazMan  он предлагает плохое, toUIID превращает стримабл инсерт в говно

SELECT 
    name, 
    value, 
    changed
FROM system.settings
WHERE (changed = 1) AND (name = 'joined_subquery_requires_alias')

┌─name───────────────────────────┬─value─┬─changed─┐
│ joined_subquery_requires_alias │ 0     │       1 │
└────────────────────────────────┴───────┴─────────┘

запрос покажите из той же сессии где вы сейчас FROM system.settings сделали

Всем доброго дня!

Подскажите, пожалуйста, является ли такой путь реализации витрины данных на КХ оптимальным?


Имеется 3 шарда, на них созданы локальные таблицы:

CREATE TABLE datamart.trafficEdiEds (
billingRecID UUID,
...
shard UInt64
) ENGINE = MergeTree
PARTITION BY toDate(documentReceptionDate)
ORDER BY (documentReceptionDate, senderAccountID)


Есть DISTRIBUTED таблица, которая смотрит на них:

CREATE TABLE datamart.trafficEdiEds_distributed (
billingRecID UUID,
...
shard UInt64
) ENGINE = Distributed(click_3s, datamart, trafficEdiEds, shard - 1)

Над DISTRIBUTED таблицей имеется VIEW только на первом шарде:

CREATE VIEW datamart.trafficEdiEdsView AS
SELECT billingRecID,
 dictGetUInt64('gln',
'glnevoid',
senderGlnID) AS senderGlnEvoID,
dictGetString('gln',
'glnname',
senderGlnID) AS senderGlnName,
...
shard
FROM datamart.trafficEdiEds_distributed  

В общем, в финальной вьюшке используются 3 разных словаря, из которых тянется по 5-10 полей через dictGet*.
На эту вьюшку смотрит Tableau. Пользователи строят по ней отчеты. Группируют и фильтруют по полям, которые тянутся из словарей.

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

Идея: сделать так, чтобы не было лишней утилизации сети. Словари можем и на всех шардах разместить (пока только на первом),
если это нужно для оптимального исполнения запросов.

тогда видимо у него просто ошибка в другом...

а у вас такой запрос с вью и без вью работает без ошибки разве? Не верю.
В таком виде как у вас к словарям уже на шардах будет обращение и частичный расчет сумм уже на шардах

shard - 1 -- это зачем? Distributed сам считает остаток от деления на кол-во шардов в кластере, а  не то что вы подумали

Запрос приблизительно такого плана (в тот-же сесиии changed = 1 и флаг установлен):

CREATE TABLE secret.generator_tmp_table_1595421478_1249483_xMO3soAa ON CLUSTER secret
ENGINE = Log() AS
SELECT *
FROM 
(
    SELECT 
        id, 
 .....
        gp_install_finish_time
    FROM secret.generator_tmp_table_1595421476_1277494_iVmLdgCn 
)
ANY LEFT JOIN 
(
    SELECT 
        conversion_unique_id, 
        *
    FROM secret.generator_tmp_table_1595421477_340448_DQJZN0ah 
) USING (conversion_unique_id);

CREATE TABLE secret.generator_tmp_table_1595421478_1249483_xMO3soAa ON CLUSTER secret
ENGINE = Log() AS
SELECT *
FROM 
(
    SELECT 
        id, 
 .....
        gp_install_finish_time
    FROM secret.generator_tmp_table_1595421476_1277494_iVmLdgCn 
)
ANY LEFT JOIN 
(
    SELECT 
        conversion_unique_id, 
        *
    FROM secret.generator_tmp_table_1595421477_340448_DQJZN0ah 
) USING (conversion_unique_id);

ON CLUSTER -- надо на всех серверах параметр ставить (через on cluster не передаются параметры сессии), без on cluster тоже ошибка?

Да, запрос работает на пустых таблицах. Хотя, наверное, когда появятся данные он перестанет работать...

да, вы знаете без ON CLUSTER работает

a без вью работает?

потому что надо на всех серверах параметр ставить

У нас данные в локальные таблицы пишутся не через distributed таблицу, а самописным загрузчиком. При таком раскладе shard -1 все равно не нужен?

он на всех на самом деле проставлен - проверяли.  Тут возможно КХ Оператор не-до брасывает.  Но спасибо вам за подсказку!

Да, на всех шардах

ясно, и при таком раскладе если вы не используете optimize_skip_unused_shards можно вообще этот параметр не писать в Distributed