Если бы этот пункт проверялся при модерации, то в расширении AI-Less Habr не пришлось бы делать никаких настроек вообще, а просто скрывать хаб ИИ и всё. Но пришлось извращаться.
Если для статьи проставлен хаб "Искусственный интеллект", то по умолчанию попадает. Но:
Могу ошибаться, но мне кажется, что в таких статьях хаб “Искусственный интеллект” не ставят, так как сейчас под этим подразумевают в основном LLM (во всяком случае на момент тестов расширения я как раз видел статью про игровой ИИ, и она была без этого хаба и не скрывалась)
Фильтр по хабу "Искусственный интеллект" можно отключить и оставить фильтры только по ключевым словам
В фильтрах по ключевым словам по умолчанию нет "ИИ" и "AI" как раз для уменьшения числа ложноположительных срабатываний
В любом случае можно поставить расширение, настроить фильтры, нажать галочку "Инвертировать фильтры" и увидеть, что оно скрывает, и есть ли среди этого то, что вам не нужно скрывать.
Спасибо, в целом интересно, но местами есть недосказанность существенная.
Данные мы тянули из заводской MES-системы. Она непрерывно записывает все производственные параметры и хранит их за много лет. ...В итоге датасет по пилотному кейсу: 77 технологических параметров, 547 дней работы
Почему 547 дней, если данные есть за много лет?
Чтобы модель обучилась, данные должны были меняться, но по идее на производстве должно быть более-менее фиксировано в относительно узких пределах. Вы ведь не специально меняли параметры, а брали историю реального производства. Так почему они менялись в истории?
обрастание труб как-то измеряется постоянно?
трубы обрастают везде одинаково, или в разных местах по-разному? Может ли при изменении параметров в одном месте усилиться обрастание, а в другом уменьшиться?
Реакторы приходилось останавливать на чистку каждые 3-5 месяца. … Запустили опытный пробег: 45 дней непрерывной работы без остановки на чистку. Это было начало.
А как вы поняли, что это начало чего-то большего? Обрастание было меньше, чем раньше за такой же срок или что? Что показали эти 45 дней?
И хотелось бы каких-то подробностей по итоговой модели (насколько это возможно). Например:
Зависят ли оптимальные параметры от степени обрастания? Например: сначала ставим такую температуру, а по мере обрастания поднимаем.
Параметры получаются статические, монотонно изменяющиеся в одну сторону, или, например, выгодно варьировать параметры туда-сюда в течение суток/дней?
Какие-то наблюдения, что раньше все думали так, а оказалось вот так вот, и это всех удивило.
Судя по всему, модель уже несколько лет в работе. Она после первого "прохода" потом переобучалась по данным следующих лет? Сильно ли что-то изменилось?
На счет правильного спорно. Тут всякие дополнительные истории возникают с сессиями, с распределенным кластером - легко можно вообще не обнаружить созданную таблицу при запросе с попыткой ее использования.
Если хочется cte, то это можно обойти с помощью костыля:
with
(
select groupArray(num)
from ( /* тут исходный запрос из cte */
SELECT
num
FROM generateRandom('num UInt64', NULL)
LIMIT 1000000
)
) as cte_constant,
cte_numbers as (
select arrayJoin(cte_constant) as num
)
SELECT
count()
FROM cte_numbers
WHERE num IN (SELECT num FROM cte_numbers)
┌─count()─┐
│ 1000000 │
└─────────┘
через groupArray() возвращаем одно значение, которое через синтаксис with (...) as материализуется в константу, а потом обратно разворачиваем где нужно через arrayJoin().
В более общем случае надо в tuple завернуть значения, если их несколько:
with
(
select groupArray((c1, c2, ...))
from (
select c1, c2, ...
)
) as cte_constant,
cte_values as (
select (arrayJoin(cte_constant) as tpl).1 as c1, tpl.2 as c2...
)
select ...
Но у меня работа во многом про оптимизацию, и как правило я сталкиваюсь с тем, что cte из запроса выпиливаю, потому что в разных местах запроса оптимальнее использовать разные подзапросы, чем переиспользовать что-то универсальное.
Когда мне пытаются рассказывать, что decimal точнее, чем float аналогичной размерности, мое лицо похоже на лицо этих аудиторов. Хотя мои примеры обычно попроще, вроде вставки в базу 0.009 и получением в результате 0.00.
Если анализировать за большой промежуток времени, то лучше не "лайкать" query_log, так как это может быть долго, а вместо этого использовать not has(tables, 'system.query_log').
Когда к ClickHouse обращаются несколько сервисов (дашборды, оркестраторы пайплайнов, ручные запросы аналитиков), в query_log тысячи записей, и непонятно, кто создаёт нагрузку.
Странно, что тут не написано про банальные initial_user и user. Ну и есть еще полезные client_hostname и initial_address. Статья про поиск проблемы, а наличие прописанного log_comment - это не дефолтное поведение. Про это, наверное, можно было бы в конце статьи написать как рекомендацию к использованию.
Пример тяжёлого запроса … FROM events final WHERE event_date > ‘2024-01-01’ … PARTITION BY toYYYYMM(event_date) ORDER BY (event_id, user_id, event_date); … Теперь картина ясна. Что можно сделать?
Самое эффективное здесь будет добавить в конец запроса settings do_not_merge_across_partitions_select_final = 1;. А еще помимо замены на uniq можно воспользоваться хаком из моей статьи :-) uniqExact(cityHash64(event_id)) - всего x2 памяти сэкономим, но посчитаем точно.
Ну и не по теме статьи, но если это реальная таблица у вас, то скорее всего у вас там ключ сортировки неоптимальный. На первом месте event_id UUID и после него всё остальное уже не имеет смысла в плане эффективности ключа. Полагаю любой из вариантов (event_date, user_id, event_id) или (user_id, event_date, event_id) будет лучше, а если вам нужен поиск по event_id, то можно bloom_filter на эту колонку навесить.
Когда гуглил, там было какое-то расширение для скрытия по авторам. А что если автор "исправится"? Понимаю желание, но нет, я в свое не буду это добавлять. Вообще изначально было суперпросто - только скрытие хаба, но выяснилось, что хабы проставляются не везде, и не везде добавлен нужный.
Это правильный вопрос. Но сбрасывая кеши тоже получаешь результат отличный от того, что будет в продакшене, так как там кеши есть. Тот же Mark Cache если сбросить, то это будет ситуация, не имеющая отношения к реальности. Page cache тоже в реальности должен хоть как-то работать. Поэтому я не фанат тестов со сбросом кеша. Query cache, конечно, не использовался :-).
Тесты проводились в clickhouse-client локально на машине с clickhouse. Обычно я сначала делаю запросы, не имеющие отношения к тесту, потом тестовые. Затем повторно тестовые + в обратном порядке, чтобы убедиться, что время особо не меняется. Не слишком строгий подход, но мне этого достаточно, когда я вижу, что время сильно не скачет. Вообще статья больше про память, а скорость - это бонус (могло быть и медленнее, но статья всё равно бы была).
Сейчас посмотрел в логах OpenedFileCacheHits и OpenedFileCacheMisses по тестовым запросам - там 50/50 было примерно.
Про разные таблицы - как вариант, но что-то мне интуитивно не нравится. Как минимум те же кеши получаются раздельные и на более "легких" тестах заполняемость может быть лучше, что даст дополнительное преимущество. Разные парты будут, а если до одного схлопнуть, тоже обычно не реальная ситуация. Но это не слишком сильные аргументы с моей стороны.
В любом случае я специально сделал воспроизводимые тесты, чтобы желающие могли повторить. Если в каких-то условиях оно будет давать качественно иной результат, можно обсудить.
Успехов. Но хеширование, конечно, не единственный и не главный прием при оптимизации сферического запроса в вакууме. Начать всегда стоит с максимума условий в where (для каждой используемой таблицы) и правильного порядка джойнов (справа меньше данных, чем слева).
Главная проблема клиппинга это не сама потеря скорости, а непредсказуемость этого процесса для едущих позади пилотов. И главное обсуждение в руководстве сейчас именно с точки зрения безопасности.
сейчас обсуждение ведется в основном по поводу квалификации
Вот только в квалификации на быстром круге друг за дружкой не едут, и эта опасность не проявляется
Только с боковой панелью (где закладки, загрузки и т.д.) как-то странно и неудобно работает. Она у меня изначально полностью скрыта. Но если включаю режим автоскрытия, то боковая панель появляется в развернутом виде и остается висеть пока не наведешь на нее мышкой и не уберешь мышь опять. Но после выхода из режима автоскрытия боковая панель становится видимой (в узком виде, где только иконки).
Как у вас устроено создание новых версий схем в Schema Registry? Новая версия согласуется командой Databus, или всё в руках команд сервисов, отправляющих события? Если первое, то сразу делаются схемы Dev/Stage/Prod или последовательно сначала только Dev, потом проверка данных по новой версии схемы на Dev и только потом Stage/Prod? Или как-то еще иначе?
Ну реально же. Как в здравом уме можно самому писать с длинным тире? Самое забавное, что оно в рекомендациях есть:
и кавычки ёлочками, ага
Если бы этот пункт проверялся при модерации, то в расширении AI-Less Habr не пришлось бы делать никаких настроек вообще, а просто скрывать хаб ИИ и всё. Но пришлось извращаться.
поставьте расширение AI-Less Habr - оно ровно для этого делалось
Если для статьи проставлен хаб "Искусственный интеллект", то по умолчанию попадает. Но:
Могу ошибаться, но мне кажется, что в таких статьях хаб “Искусственный интеллект” не ставят, так как сейчас под этим подразумевают в основном LLM (во всяком случае на момент тестов расширения я как раз видел статью про игровой ИИ, и она была без этого хаба и не скрывалась)
Фильтр по хабу "Искусственный интеллект" можно отключить и оставить фильтры только по ключевым словам
В фильтрах по ключевым словам по умолчанию нет "ИИ" и "AI" как раз для уменьшения числа ложноположительных срабатываний
В любом случае можно поставить расширение, настроить фильтры, нажать галочку "Инвертировать фильтры" и увидеть, что оно скрывает, и есть ли среди этого то, что вам не нужно скрывать.
Спасибо, в целом интересно, но местами есть недосказанность существенная.
Почему 547 дней, если данные есть за много лет?
Чтобы модель обучилась, данные должны были меняться, но по идее на производстве должно быть более-менее фиксировано в относительно узких пределах. Вы ведь не специально меняли параметры, а брали историю реального производства. Так почему они менялись в истории?
обрастание труб как-то измеряется постоянно?
трубы обрастают везде одинаково, или в разных местах по-разному? Может ли при изменении параметров в одном месте усилиться обрастание, а в другом уменьшиться?
А как вы поняли, что это начало чего-то большего? Обрастание было меньше, чем раньше за такой же срок или что? Что показали эти 45 дней?
И хотелось бы каких-то подробностей по итоговой модели (насколько это возможно). Например:
Зависят ли оптимальные параметры от степени обрастания? Например: сначала ставим такую температуру, а по мере обрастания поднимаем.
Параметры получаются статические, монотонно изменяющиеся в одну сторону, или, например, выгодно варьировать параметры туда-сюда в течение суток/дней?
Какие-то наблюдения, что раньше все думали так, а оказалось вот так вот, и это всех удивило.
Судя по всему, модель уже несколько лет в работе. Она после первого "прохода" потом переобучалась по данным следующих лет? Сильно ли что-то изменилось?
На счет правильного спорно. Тут всякие дополнительные истории возникают с сессиями, с распределенным кластером - легко можно вообще не обнаружить созданную таблицу при запросе с попыткой ее использования.
Если хочется cte, то это можно обойти с помощью костыля:
через
groupArray()возвращаем одно значение, которое через синтаксисwith (...) asматериализуется в константу, а потом обратно разворачиваем где нужно черезarrayJoin().В более общем случае надо в tuple завернуть значения, если их несколько:
Но у меня работа во многом про оптимизацию, и как правило я сталкиваюсь с тем, что cte из запроса выпиливаю, потому что в разных местах запроса оптимальнее использовать разные подзапросы, чем переиспользовать что-то универсальное.
Когда мне пытаются рассказывать, что decimal точнее, чем float аналогичной размерности, мое лицо похоже на лицо этих аудиторов. Хотя мои примеры обычно попроще, вроде вставки в базу 0.009 и получением в результате 0.00.
Если анализировать за большой промежуток времени, то лучше не "лайкать" query_log, так как это может быть долго, а вместо этого использовать
not has(tables, 'system.query_log').Странно, что тут не написано про банальные initial_user и user. Ну и есть еще полезные client_hostname и initial_address. Статья про поиск проблемы, а наличие прописанного
log_comment- это не дефолтное поведение. Про это, наверное, можно было бы в конце статьи написать как рекомендацию к использованию.Самое эффективное здесь будет добавить в конец запроса
settings do_not_merge_across_partitions_select_final = 1;.А еще помимо замены на uniq можно воспользоваться хаком из моей статьи :-)
uniqExact(cityHash64(event_id))- всего x2 памяти сэкономим, но посчитаем точно.Ну и не по теме статьи, но если это реальная таблица у вас, то скорее всего у вас там ключ сортировки неоптимальный. На первом месте
event_id UUIDи после него всё остальное уже не имеет смысла в плане эффективности ключа. Полагаю любой из вариантов(event_date, user_id, event_id)или(user_id, event_date, event_id)будет лучше, а если вам нужен поиск поevent_id, то можно bloom_filter на эту колонку навесить.Когда гуглил, там было какое-то расширение для скрытия по авторам. А что если автор "исправится"? Понимаю желание, но нет, я в свое не буду это добавлять. Вообще изначально было суперпросто - только скрытие хаба, но выяснилось, что хабы проставляются не везде, и не везде добавлен нужный.
Ссылку поправил, спасибо.
Это правильный вопрос. Но сбрасывая кеши тоже получаешь результат отличный от того, что будет в продакшене, так как там кеши есть. Тот же Mark Cache если сбросить, то это будет ситуация, не имеющая отношения к реальности. Page cache тоже в реальности должен хоть как-то работать. Поэтому я не фанат тестов со сбросом кеша. Query cache, конечно, не использовался :-).
Тесты проводились в clickhouse-client локально на машине с clickhouse. Обычно я сначала делаю запросы, не имеющие отношения к тесту, потом тестовые. Затем повторно тестовые + в обратном порядке, чтобы убедиться, что время особо не меняется. Не слишком строгий подход, но мне этого достаточно, когда я вижу, что время сильно не скачет. Вообще статья больше про память, а скорость - это бонус (могло быть и медленнее, но статья всё равно бы была).
Сейчас посмотрел в логах OpenedFileCacheHits и OpenedFileCacheMisses по тестовым запросам - там 50/50 было примерно.
Про разные таблицы - как вариант, но что-то мне интуитивно не нравится. Как минимум те же кеши получаются раздельные и на более "легких" тестах заполняемость может быть лучше, что даст дополнительное преимущество. Разные парты будут, а если до одного схлопнуть, тоже обычно не реальная ситуация. Но это не слишком сильные аргументы с моей стороны.
В любом случае я специально сделал воспроизводимые тесты, чтобы желающие могли повторить. Если в каких-то условиях оно будет давать качественно иной результат, можно обсудить.
Ответ про cityHash64() оформил в виде статьи, спасибо за идею:)
https://habr.com/ru/articles/1012624/
Успехов. Но хеширование, конечно, не единственный и не главный прием при оптимизации сферического запроса в вакууме. Начать всегда стоит с максимума условий в where (для каждой используемой таблицы) и правильного порядка джойнов (справа меньше данных, чем слева).
Вот только в квалификации на быстром круге друг за дружкой не едут, и эта опасность не проявляется
Не судьба.upd. Без vpn получилось.
У меня нет этой кнопки, без гугла не смог бы разобраться как это включить. Но да, в гостевом профиле тоже самое.
Имеется в виду приватный режим? Да, также.
del
Фича с автоскрытием классная (наверное😀).
Только с боковой панелью (где закладки, загрузки и т.д.) как-то странно и неудобно работает. Она у меня изначально полностью скрыта. Но если включаю режим автоскрытия, то боковая панель появляется в развернутом виде и остается висеть пока не наведешь на нее мышкой и не уберешь мышь опять. Но после выхода из режима автоскрытия боковая панель становится видимой (в узком виде, где только иконки).
Что-то такой упор на число поворотов и оптимальные алгоритмы. Но кажется, что в первую очередь всё упирается на механическую скорость и точность.
Как у вас устроено создание новых версий схем в Schema Registry? Новая версия согласуется командой Databus, или всё в руках команд сервисов, отправляющих события? Если первое, то сразу делаются схемы Dev/Stage/Prod или последовательно сначала только Dev, потом проверка данных по новой версии схемы на Dev и только потом Stage/Prod? Или как-то еще иначе?