Forwarded from DeepSchool
Персонализированная генерация: Textual Inversion и DreamBooth
Персонализированная генерация добавляет новые концепции в такие генеративные модели, как Stable Diffusion. С ней можно создавать изображения с определённым объектом или художественным стилем, которые модель не видела раньше.
В новой статье расскажем, как работают базовые алгоритмы персонализированной генерации — Textual Inversion и DreamBooth 🧙♂️
А также рассмотрим:
- какие существуют проблемы наивных подходов
- как алгоритмы добавляют концепт в модель по пяти примерам
- визуализацию работы алгоритмов
Читайте новую статью по ссылке! 👈
🪔 DeepSchool
Персонализированная генерация добавляет новые концепции в такие генеративные модели, как Stable Diffusion. С ней можно создавать изображения с определённым объектом или художественным стилем, которые модель не видела раньше.
В новой статье расскажем, как работают базовые алгоритмы персонализированной генерации — Textual Inversion и DreamBooth 🧙♂️
А также рассмотрим:
- какие существуют проблемы наивных подходов
- как алгоритмы добавляют концепт в модель по пяти примерам
- визуализацию работы алгоритмов
Читайте новую статью по ссылке! 👈
Please open Telegram to view this post
VIEW IN TELEGRAM
DeepSchool
Персонализированная генерация: Textual Inversion и DreamBooth - DeepSchool
Рассказываем, как работают базовые алгоритмы генерации — Textual Inversion и DreamBooth
Forwarded from Data Funk
Традиционно эмбеддинги получаем нейросетями. Если хотите "экологически чистые" эмбединги🌳, то ребята из Королёвского колледжа Лондона сделали "деревянный" автоэнкодер. В отличие от классического варианта, тут кодер и декодер учатся независимо.
Кодер работает как GAN: лес учится отличать реальные данные от синтетических, а из его листьев-ошибок семплируются всё более правдоподобные точки. После нескольких итераций лес перестает их различать. Так модель учит внутреннюю структуру данных. Затем для n точек строится матрица близости K (насколько часто пары точек попадают в один лист). В простом варианте первые d собственных векторов (V) и значений (Λ) этой матрицы формируют d-мерные эмбеддинги: Z = √n*V*Λ.
Декодер это просто k-nn в пространстве эмбеддингов: чтобы восстановить объект по эмбеддингу, берём k ближайших точек из обучающей выборки и усредняем их фичи (берём моду для категорий).
Что бы получить эмбеддинг новый точки из test набора ищем ее близость к тем же n точкам - K' и умножаем на собственные вектора: Z' = √n*K'*V.
Всё без градиентов, только 🌲🌳🪵!
Кодер работает как GAN: лес учится отличать реальные данные от синтетических, а из его листьев-ошибок семплируются всё более правдоподобные точки. После нескольких итераций лес перестает их различать. Так модель учит внутреннюю структуру данных. Затем для n точек строится матрица близости K (насколько часто пары точек попадают в один лист). В простом варианте первые d собственных векторов (V) и значений (Λ) этой матрицы формируют d-мерные эмбеддинги: Z = √n*V*Λ.
Декодер это просто k-nn в пространстве эмбеддингов: чтобы восстановить объект по эмбеддингу, берём k ближайших точек из обучающей выборки и усредняем их фичи (берём моду для категорий).
Что бы получить эмбеддинг новый точки из test набора ищем ее близость к тем же n точкам - K' и умножаем на собственные вектора: Z' = √n*K'*V.
Всё без градиентов, только 🌲🌳🪵!
Forwarded from Applied AI by David
Перечитал полностью docs+api refs openai,anthropic,gemini,grok,cerebras,groq,deepseek,litellm,openrouter вместо вас
Последний раз читал год назад. Тогда рассказывали про кэширование, ризонинг - решил изучить, что сейчас есть "перспективного" в апихах
- в конце текста вам подарок
из прикольного:
- грок берет 5 центов штрафа если запрос "улетел в этику"
- openai responses api boost accuracy in 3% by mean (comparing to completions api)
- (старая фича) открыл для себя predicted outputs = можно вывести в ответ текст в 10к токенов, при этом генерироваться будет лишь малая часть (стоит чуть дороже, но работает сильно быстрее)
- prefill output позволяет начинать ответ с правильного персонажа/текста etc., сразу пропуская "преамбулу"
- грок апи самый бедный по фичам, ниче нет, даже батч апи без скидки
- у image-edit моделей есть МАСКИ на вход (нативно и параметром!)
- у опенаи есть прикольный flex tier, понижающий стоимость в 2 раза (по-другому поданный batching)
- батч+кэш = скидка до 95% = платим меньше или юзаем модели больше
- работать с видео не так уж и дорого, если использовать самые крошечные модели + батчинг + кэширование
- o3 (и выше) умеют ДУМАТЬ картинками (в процессе размышлений рассматриваются участки изображения, например модель может приблизить картинку в каком-то месте и рассмотреть подробнее (н. прочитать мелкий текст)
- у gpt-image есть параметр input_fidelity=high, который превращает ее в ультимативный фотошоп - есть ощущение, что на аренах он отключен
- у gpt-image есть параметр для прозрачности фона: auto/transparent/opaque
- анторпик дает несколько чекпоинтов для кэширования промптов
- на оперрутере есть моделька cognitivecomputations/dolphin-mistral-24b-venice-edition:free (uncensored)
- в опенаи ответ можно получать на вебхук (не батчевый!)
- VLM очень точно возвращают box_2d (границы предметов на изображении, относительными координатами) [проверил гугл, тропик, оаи]
- image-edit модели очень точно создают маску для объекта
- (на всякий случай решил напомнить) у tool_call_mode есть режим required
- у дипсика есть fill in the middle completion (блин это очень круто, представляю сколько всего надо было сделать ради этой фичи)
- антропик упоминает у себя XML промптинг среди самых мощных техник
- в api gigachat&yandexgpt всё еще нет кучи параметров начиная с банальных stop, что даже хз что говорит о продактах (или их ресурсах) - под капотом в моделях больше 100 параметров по управлению "пулом токенов для генерации" (в я. в конце 2025 года так вообще кроме температуры ничего нет)
- proprietary vlm's находятся в больгинстве на уровне понимания изображений, сопоставимом с уровнем пониманием текста gpt-3.5. Все еще хорошо работают техники с ролями "You have perfect vision and pay great attention to detail" (прочитал 20+ статей по vlm за неделю, напишите в комменты если нужен пост на эту тему)
- про текущие VLM: поворот изображения = смерть. изменение экспозиции = смерть. изменение освещения = смерть. spatial understanding & counting везде слабый. ждем обучение на videogen моделях
- фичами в апи обычно занимаются целые команды, поэтому у маленьких провайдеров типа groq/cerebras/etc нет почти никаких фич - паттерн
- гемини 2.5 поддерживает сегментацию из коробки (шок) (возвращает label + box_2d + base64 маску для каждого объекта)
- gemini несовместим с reasoning_effort в litellm и кажется не будет
- подарок: все дают 0.1-1тб бесплатного диска для files api, который можно использовать для каких угодно задач = можно на все аккаунты наспамить себе хранилищ
А еще сильно разочаровался в litellm. Про это будет следующий пост
Последний раз читал год назад. Тогда рассказывали про кэширование, ризонинг - решил изучить, что сейчас есть "перспективного" в апихах
- в конце текста вам подарок
из прикольного:
- грок берет 5 центов штрафа если запрос "улетел в этику"
- openai responses api boost accuracy in 3% by mean (comparing to completions api)
- (старая фича) открыл для себя predicted outputs = можно вывести в ответ текст в 10к токенов, при этом генерироваться будет лишь малая часть (стоит чуть дороже, но работает сильно быстрее)
- prefill output позволяет начинать ответ с правильного персонажа/текста etc., сразу пропуская "преамбулу"
- грок апи самый бедный по фичам, ниче нет, даже батч апи без скидки
- у image-edit моделей есть МАСКИ на вход (нативно и параметром!)
- у опенаи есть прикольный flex tier, понижающий стоимость в 2 раза (по-другому поданный batching)
- батч+кэш = скидка до 95% = платим меньше или юзаем модели больше
- работать с видео не так уж и дорого, если использовать самые крошечные модели + батчинг + кэширование
- o3 (и выше) умеют ДУМАТЬ картинками (в процессе размышлений рассматриваются участки изображения, например модель может приблизить картинку в каком-то месте и рассмотреть подробнее (н. прочитать мелкий текст)
- у gpt-image есть параметр input_fidelity=high, который превращает ее в ультимативный фотошоп - есть ощущение, что на аренах он отключен
- у gpt-image есть параметр для прозрачности фона: auto/transparent/opaque
- анторпик дает несколько чекпоинтов для кэширования промптов
- на оперрутере есть моделька cognitivecomputations/dolphin-mistral-24b-venice-edition:free (uncensored)
- в опенаи ответ можно получать на вебхук (не батчевый!)
- VLM очень точно возвращают box_2d (границы предметов на изображении, относительными координатами) [проверил гугл, тропик, оаи]
- image-edit модели очень точно создают маску для объекта
- (на всякий случай решил напомнить) у tool_call_mode есть режим required
- у дипсика есть fill in the middle completion (блин это очень круто, представляю сколько всего надо было сделать ради этой фичи)
- антропик упоминает у себя XML промптинг среди самых мощных техник
- в api gigachat&yandexgpt всё еще нет кучи параметров начиная с банальных stop, что даже хз что говорит о продактах (или их ресурсах) - под капотом в моделях больше 100 параметров по управлению "пулом токенов для генерации" (в я. в конце 2025 года так вообще кроме температуры ничего нет)
- proprietary vlm's находятся в больгинстве на уровне понимания изображений, сопоставимом с уровнем пониманием текста gpt-3.5. Все еще хорошо работают техники с ролями "You have perfect vision and pay great attention to detail" (прочитал 20+ статей по vlm за неделю, напишите в комменты если нужен пост на эту тему)
- про текущие VLM: поворот изображения = смерть. изменение экспозиции = смерть. изменение освещения = смерть. spatial understanding & counting везде слабый. ждем обучение на videogen моделях
- фичами в апи обычно занимаются целые команды, поэтому у маленьких провайдеров типа groq/cerebras/etc нет почти никаких фич - паттерн
- гемини 2.5 поддерживает сегментацию из коробки (шок) (возвращает label + box_2d + base64 маску для каждого объекта)
- gemini несовместим с reasoning_effort в litellm и кажется не будет
- подарок: все дают 0.1-1тб бесплатного диска для files api, который можно использовать для каких угодно задач = можно на все аккаунты наспамить себе хранилищ
А еще сильно разочаровался в litellm. Про это будет следующий пост
Forwarded from Душный NLP
Kimi K2 — огромная модель с интересными решениями «под капотом»
Сегодня разберём статью о MoE-модели Kimi K2 на триллион параметров. У Kimi в полтора раза больше экспертов, чем у DeepSeek-V3 — 384 против 256. А ещё — в два раза меньше голов аттеншена — 64 против 128.
Создатели вводят понятие sparsity — это разница между общим количеством экспертов и активными экспертами. Так, у Kimi K2 sparsity 48, а у DeepSeek-V3 — 36. Авторы утверждают, что при увеличении sparsity улучшается validation loss модели, но и растёт её инфраструктурная сложность. Что касается небольшого, по сравнению с DeepSeek, числа голов аттеншена, то это решение связано с тем, что удвоение голов даёт прибавку к validation loss всего в 1,2% и кажется нецелесообразным.
На претрейне Kimi K2 использовался собственный алгоритм Muon, включающий в себя быстрое преобразование к ортогональной матрице. Однако при применении этого метода происходит «взрыв» логитов аттеншена. Чтобы справиться с этой проблемой, авторы устанавливают максимальные логиты для каждой головы. Дальше, всё, что больше заданного T, клипают. Следом идёт рескейлинг матриц W_k и W_q с gamma_h = min(1 или T/на максимальный логит). В случае с обычным MHA все это домножается на гамму, а в случае с MLA скейлятся только не пошаренные веса голов аттеншена.
Также на претрейне авторы перефразировали данные с помощью промптов — то есть буквально переписывали их, сохраняя семантическое родство. Большие тексты разбивались на отдельные фрагменты, которые затем переписывались и подавались в качестве контекста для следующего фрагмента. После десяти перефразирований и одной эпохи прибавка на SimpleQA получается более чем в пять пунктов по сравнению с использованием «оригинального» текста в течение 10 эпох.
На пострейне использовали 3000 MCP тулов с GitHub и ещё 10 тысяч — синтетических инструментов. По тулам сгенерировали тысячи агентов. Они получили сгенерированные задачи, оценкой которых происходила в режиме LLM-as-a-Judge. Успешные траектории становились базой для обучения.
На этапе RL для случая, когда нет верифицируемой награды, модель использовали одновременно и как актора, и как критика. Актор генерировал набор ответов, которые критик попарно сравнивал относительно набора аспектов. Сам критик обновлялся за счёт verifiable-сигналов.
Разбор подготовил❣ Владимир Платонов
Душный NLP
Сегодня разберём статью о MoE-модели Kimi K2 на триллион параметров. У Kimi в полтора раза больше экспертов, чем у DeepSeek-V3 — 384 против 256. А ещё — в два раза меньше голов аттеншена — 64 против 128.
Создатели вводят понятие sparsity — это разница между общим количеством экспертов и активными экспертами. Так, у Kimi K2 sparsity 48, а у DeepSeek-V3 — 36. Авторы утверждают, что при увеличении sparsity улучшается validation loss модели, но и растёт её инфраструктурная сложность. Что касается небольшого, по сравнению с DeepSeek, числа голов аттеншена, то это решение связано с тем, что удвоение голов даёт прибавку к validation loss всего в 1,2% и кажется нецелесообразным.
На претрейне Kimi K2 использовался собственный алгоритм Muon, включающий в себя быстрое преобразование к ортогональной матрице. Однако при применении этого метода происходит «взрыв» логитов аттеншена. Чтобы справиться с этой проблемой, авторы устанавливают максимальные логиты для каждой головы. Дальше, всё, что больше заданного T, клипают. Следом идёт рескейлинг матриц W_k и W_q с gamma_h = min(1 или T/на максимальный логит). В случае с обычным MHA все это домножается на гамму, а в случае с MLA скейлятся только не пошаренные веса голов аттеншена.
Также на претрейне авторы перефразировали данные с помощью промптов — то есть буквально переписывали их, сохраняя семантическое родство. Большие тексты разбивались на отдельные фрагменты, которые затем переписывались и подавались в качестве контекста для следующего фрагмента. После десяти перефразирований и одной эпохи прибавка на SimpleQA получается более чем в пять пунктов по сравнению с использованием «оригинального» текста в течение 10 эпох.
На пострейне использовали 3000 MCP тулов с GitHub и ещё 10 тысяч — синтетических инструментов. По тулам сгенерировали тысячи агентов. Они получили сгенерированные задачи, оценкой которых происходила в режиме LLM-as-a-Judge. Успешные траектории становились базой для обучения.
На этапе RL для случая, когда нет верифицируемой награды, модель использовали одновременно и как актора, и как критика. Актор генерировал набор ответов, которые критик попарно сравнивал относительно набора аспектов. Сам критик обновлялся за счёт verifiable-сигналов.
Разбор подготовил
Душный NLP
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from DevFM
You Should Write An Agent
Недавно проводил опрос: по поводу использования агентов и оказалось, что многие используют.
Нашёл отличную статью – в ней автор предлагает самостоятельно разобраться, как базово устроены агенты под капотом, и попробовать реализовать своего.
В первой части – пошагово и с кодом объясняется, как работает агентский цикл: мы храним историю контекста, передаём её языковой модели и получаем ответы.
Дальше – интереснее: как подключать tools к агенту. Автор даёт агенту возможность выполнять команду ping. LLM сама инициирует вызов нужного инструмента. Получается очень прикольно: ты не описывал логики, не писал условий – модель сама решила, какие адреса пинговать, как интерпретировать результаты и как сформировать ответ.
В конце автор затрагивает важный вопрос контекста. Он показывает, что вся магия мультиагентности – это просто несколько массивов контекста и чуть-чуть управляющего кода.
В общем, рекомендую посмотреть и поэкспериментировать самостоятельно.
#ai
Недавно проводил опрос: по поводу использования агентов и оказалось, что многие используют.
Нашёл отличную статью – в ней автор предлагает самостоятельно разобраться, как базово устроены агенты под капотом, и попробовать реализовать своего.
В первой части – пошагово и с кодом объясняется, как работает агентский цикл: мы храним историю контекста, передаём её языковой модели и получаем ответы.
Дальше – интереснее: как подключать tools к агенту. Автор даёт агенту возможность выполнять команду ping. LLM сама инициирует вызов нужного инструмента. Получается очень прикольно: ты не описывал логики, не писал условий – модель сама решила, какие адреса пинговать, как интерпретировать результаты и как сформировать ответ.
В конце автор затрагивает важный вопрос контекста. Он показывает, что вся магия мультиагентности – это просто несколько массивов контекста и чуть-чуть управляющего кода.
В общем, рекомендую посмотреть и поэкспериментировать самостоятельно.
#ai
Telegram
DevFM
Друзья, хотел спросить: какие агенты вы используете в работе? Если не используете, то расскажите в комментах почему.
Cursor / Claude Code / Roo Code / Другой инструмент – напишу в коммантах / Не использую
Cursor / Claude Code / Roo Code / Другой инструмент – напишу в коммантах / Не использую
Forwarded from Agentic World
На днях у одного из моих любимых авторов вышла новая крутая статья, посвященная альтернативам классическому трансформеру в LLM. Она очень интересная, поэтому сделал ее перевод. Будет про гибриды с линейным вниманием, диффузионные LLM, модели мира и малые рекурсивные трансформеры.
https://habr.com/ru/articles/964658/
https://habr.com/ru/articles/964658/
Хабр
Не только трансформеры: за пределами стандартных архитектур LLM
Привет! Это перевод очень крутой и захватывающей статьи, в которой автор рассматривает альтернативные архитектуры LLM: гибриды с линейным вниманием, диффузионные LLM, модели мира и малые рекурсивные...
Forwarded from Data Blog
Привет, друзья!
💫 В DLS вышли обещанные лекция и семинар по базовым методам XAI. Семинар мне самой нравится очень — в нем показаны и визуализированы разные тонкости методов LIME, SHAP и всех, которые я отношу к "графическим" — PDP, ALE, ICE.
Лекция [YouTube, Vk, презентация]
Семинар [YouTube, Vk, ноутбук]
Очень рада была записать что-то в DLS! Безумно люблю их и много-много лекций смотрела от школы (в частности, разные разборы от Тани), когда только начинала заниматься DS.
Тогда я мало понимала. Поэтому становилось ещё интереснее)
Надеюсь, вам будет полезно!
По крайней мере, на первой лекции очень громко мурчит кот.🐈⬛
💫 В DLS вышли обещанные лекция и семинар по базовым методам XAI. Семинар мне самой нравится очень — в нем показаны и визуализированы разные тонкости методов LIME, SHAP и всех, которые я отношу к "графическим" — PDP, ALE, ICE.
Лекция [YouTube, Vk, презентация]
Семинар [YouTube, Vk, ноутбук]
Очень рада была записать что-то в DLS! Безумно люблю их и много-много лекций смотрела от школы (в частности, разные разборы от Тани), когда только начинала заниматься DS.
Тогда я мало понимала. Поэтому становилось ещё интереснее)
Надеюсь, вам будет полезно!
По крайней мере, на первой лекции очень громко мурчит кот.
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Лекция. Основы области Explainable AI для моделей машинного обучения
Занятие ведёт Садиех Сабрина
Ссылка на материалы занятия:
---
Deep Learning School при ФПМИ МФТИ
Каждые полгода мы запускаем новую итерацию нашего двухсеместрового практического онлайн-курса по глубокому обучению. Наборы проводятся в августе-сентябре…
Ссылка на материалы занятия:
---
Deep Learning School при ФПМИ МФТИ
Каждые полгода мы запускаем новую итерацию нашего двухсеместрового практического онлайн-курса по глубокому обучению. Наборы проводятся в августе-сентябре…
Forwarded from Варим МЛ
Сегодня почти отвлечёмся от LLM и прочего ML, а порассуждаем на тему более приземлённую - что делать с бесконечной тревогой, когда работаешь в сфере ML в 2025 году.
Кстати, у нас новая вакансия на CV-инженера.
#Жека
Кстати, у нас новая вакансия на CV-инженера.
#Жека
Telegraph
Тревога в мире LLM
Недавно наткнулся на твит от авторов свежей опенсорсной LLM MiniMax M2. Уже первые абзацы заставили меня почувствовать сильную внутреннюю тревогу. Окей, я хотя бы смог прочитать и понять, что написано, уже хорошо, бывает, что прям совсем не выкупаю. Но если…
Forwarded from что-то на инженерном
Гарантии доставки сообщений в Kafka✈️
В распределенных системах часто приходится выбирать: в каких сценариях можно позволить себе потерю или задержку сообщения, а где важно гарантировать его обработку без повторов.
В Kafka есть несколько уровней гарантий доставки: At Most Once, At Least Once и Exactly Once. От выбора уровня зависит поведение системы при сбоях, баланс между производительностью и надежностью, а также требования к идемпотентности обработки.
Предлагаю разобрать подробно, что означает каждая гарантия и где её целесообразно применять.
✅ At Most Once (Не более одного раза)
Это гарантия, при которой сообщение отправляется только один раз, и если оно потерялось, повторной доставки не будет. Такой подход исключает дублирование, но допускает потерю данных.
Как это работает в Kafka?
⭕️ Продюсер отправляет сообщение, не дожидаясь подтверждения от брокера (
⭕️ Брокер не гарантирует сохранение, т.е. сообщение может быть потеряно при сбое.
⭕️ Консьюмер может использовать автофиксацию смещений (
Когда использовать?
Подходит для систем, где допустима небольшая потеря данных ради высокой пропускной способности, например:
⭕️ сбор событий кликов на веб-сайтах;
⭕️ телеметрия с IoT-устройств, где пропуски некритичны.
✅ At Least Once (Как минимум один раз)
Гарантирует, что сообщение будет доставлено минимум один раз. Это исключает потерю сообщений, но допускает их дублирование.
Как это работает в Kafka?
⭕️ Продюсер отправляет сообщение и ждет подтверждения от брокера (
⭕️ Консьюмер получает сообщение, обрабатывает его и только после успешной обработки коммитит смещение (manual commit).
⭕️ Если консьюмер или процесс обработки упадет после выполнения бизнес-логики, но до комитта, консьюмер сможет запросить то же сообщение повторно.
Когда использовать?
Подходит для систем, где потеря данных недопустима, а дублирование можно обработать:
⭕️ обработка заказов или событий e-commerce;
⭕️ системы мониторинга и логирования;
⭕️ ETL-пайплайны, где данные могут быть дедуплицированы на следующем шаге.
✅ Exactly Once (Ровно один раз)
Строгая гарантия, при которой сообщение обрабатывается ровно один раз, даже при сбоях или повторных доставках.
Как это работает в Kafka?
⭕️ Продюсер включает идемпотентность (
⭕️ Используются транзакции, объединяющие запись сообщений и фиксацию смещений в одну атомарную операцию.
⭕️ После успешной транзакции коммит смещений и запись данных происходят одновременно, что исключает двойную обработку.
Когда использовать?
Идеален для критичных сценариев, где недопустимы ни потери, ни дублирование:
⭕️ финансовые расчеты и платежные системы;
⭕️ обработка заказов с жесткими гарантиями;
⭕️ интеграции, где консистентность данных обязательна.
Источники:
📎 Доставка сообщений и гарантии Kafka
📎 Гарантированная доставка и хранение данных в Apache Kafka: внутренняя механика
©️что-то на инженерном
В распределенных системах часто приходится выбирать: в каких сценариях можно позволить себе потерю или задержку сообщения, а где важно гарантировать его обработку без повторов.
В Kafka есть несколько уровней гарантий доставки: At Most Once, At Least Once и Exactly Once. От выбора уровня зависит поведение системы при сбоях, баланс между производительностью и надежностью, а также требования к идемпотентности обработки.
Предлагаю разобрать подробно, что означает каждая гарантия и где её целесообразно применять.
Это гарантия, при которой сообщение отправляется только один раз, и если оно потерялось, повторной доставки не будет. Такой подход исключает дублирование, но допускает потерю данных.
Как это работает в Kafka?
acks=0).enable.auto.commit=true), что приведет к автоматическому коммиту даже до успешной обработки данных.Но! Если консьюмер упадет после чтения сообщения, но до завершения обработки, это сообщение уже не будет доступно для повторной обработки.
Когда использовать?
Подходит для систем, где допустима небольшая потеря данных ради высокой пропускной способности, например:
Гарантирует, что сообщение будет доставлено минимум один раз. Это исключает потерю сообщений, но допускает их дублирование.
Как это работает в Kafka?
acks=1 или acks=all).Чтобы избежать искажений при повторной обработке, операции должны быть идемпотентными, т.е. повторное выполнение не должно изменять результат.
Когда использовать?
Подходит для систем, где потеря данных недопустима, а дублирование можно обработать:
Строгая гарантия, при которой сообщение обрабатывается ровно один раз, даже при сбоях или повторных доставках.
Как это работает в Kafka?
enable.idempotence=true), чтобы брокер игнорировал дубликаты сообщений.Консьюмер должен использовать isolation.level=read_committed, чтобы видеть только зафиксированные транзакции.
Когда использовать?
Идеален для критичных сценариев, где недопустимы ни потери, ни дублирование:
Зафиксируемся:⭕️ At Most Once - высокая скорость, но есть риск потери данных.⭕️ At Least Once - надежно, но возможны дубликаты.⭕️ Exactly Once - идеальная консистентность, но требует дополнительных усилий и ресурсов.
Источники:
©️что-то на инженерном
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from что-то на инженерном
Разбираемся с TTL в Clickhouse
Представьте, что вы храните логи пользователей, которые активно используются только в течение первого месяца. Далее эти данные нужны только для редких запросов, и хранить их на быстром и дорогом SSD нецелесообразно.
С помощью TTL (Time-to-Live) в Clickhouse можно настроить автоматический перенос данных старше 30 дней в холодное хранилище, а в быстром доступе оставить агрегированные данные для статистики. Как это сделать расскажу ниже.
Что такое TTL?
TTL задает правило, по которому данные (строки или значения столбцов) автоматически обновляются или удаляются после истечения указанного времени, обычно связанного со столбцом типа Date, DateTime или DateTime64.
Виды TTL
🟣 TTL для столбца задает правило для конкретного поля таблицы: через заданный интервал значение этого столбца заменяется на значение по умолчанию.
Если все значения столбца в части таблицы устарели, Clickhouse удалит этот столбец из части, экономя место. Такой подход полезен для частичной очистки данных, например, удаления чувствительных атрибутов (IP, имя пользователя) через сутки, но сохранения остальной информации.
Например:
➡️ Через сутки IP-адрес будет заменен на значение '' (пустую строку).
Или
➡️ Через месяц агрегируются данные по product_id.
🟣 TTL для таблицы задает условие для удаления всех строк целиком. Например, хранение логов за 30 дней, по истечении которых устаревшие строки полностью удаляются. Это более простое и часто используемое правило управления историей данных.
Например:
➡️ Через 30 дней данные переместятся на том cold_storage, а после дальнейшего срока удалятся.
Рекомендации по настройке TTL
⭐️ Официальной докой рекомендуется всегда включать настройку ttl_only_drop_parts
⭐️ С включенной ttl_only_drop_parts можно уменьшить значение merge_with_ttl_timeout - интервала между слияниями с удалением устаревших частей, поскольку операция удаления становится проще и занимает меньше ресурсов.
⭐️ Принудительно запустить применение TTL можно командой:
⭐️ Для моментального обновления данных без ожидания фоновых слияний можно использовать команду OPTIMIZE ... FINAL, но она тяжелая и не рекомендуется к частому применению.
Подробнее про TTL и больше примеров➡️ в моей статье на Medium.
©️что-то на инженерном
Представьте, что вы храните логи пользователей, которые активно используются только в течение первого месяца. Далее эти данные нужны только для редких запросов, и хранить их на быстром и дорогом SSD нецелесообразно.
С помощью TTL (Time-to-Live) в Clickhouse можно настроить автоматический перенос данных старше 30 дней в холодное хранилище, а в быстром доступе оставить агрегированные данные для статистики. Как это сделать расскажу ниже.
Что такое TTL?
TTL задает правило, по которому данные (строки или значения столбцов) автоматически обновляются или удаляются после истечения указанного времени, обычно связанного со столбцом типа Date, DateTime или DateTime64.
Важно: TTL-операции (удаление, обновление) выполняются не мгновенно. Они происходят во время фоновых операций слияния (merges) частей данных. Если части долго не сливаются, устаревшие строки могут сохраняться в таблице дольше указанного срока.
Виды TTL
Если все значения столбца в части таблицы устарели, Clickhouse удалит этот столбец из части, экономя место. Такой подход полезен для частичной очистки данных, например, удаления чувствительных атрибутов (IP, имя пользователя) через сутки, но сохранения остальной информации.
Например:
ip_address String TTL event_time + INTERVAL 1 DAY;
Или
price Float64 TTL event_time + INTERVAL 1 MONTH GROUP BY product_id SET price = avg(price);
Например:
TTL event_date + INTERVAL 30 DAY
TO VOLUME 'cold_storage'
DELETE;
TTL для таблицы можно комбинировать с TTL для отдельных столбцов. Это удобно при хранении чувствительных данных, которые нужно анонимизировать раньше, чем удалять весь ряд.
Рекомендации по настройке TTL
Параметр ttl_only_drop_parts = 1 означает, что Clickhouse будет удалять только целые части данных, в которых все строки устарели по TTL, вместо попыток частичного удаления строк внутри части.
Это существенно облегчает процесс удаления и снижает нагрузку.
При таком подходе, особенно если партиции совпадают с единицами удаления по TTL (например, по дням), данные из отдельных дней не сливаются между собой, что позволяет эффективно и быстро удалять устаревшие части.
Это снижает влияние TTL на производительность сервера и уменьшает время реакции на удаление устаревших данных.
По умолчанию составляет 14400 секунд (4 часа), но можно безопасно уменьшать, например, до 300-600 секунд.
При слишком низком значении могут возникать частые внеплановые слияния, что увеличит нагрузку на систему.
ALTER TABLE my_table MATERIALIZE TTL;
Подробнее про TTL и больше примеров
©️что-то на инженерном
Please open Telegram to view this post
VIEW IN TELEGRAM
Medium
Mastering TTL in ClickHouse: Automating Data Lifecycle
TTL (Time-to-Live) in ClickHouse is a built-in mechanism that automatically manages your data by deleting, moving, or aggregating it based…