Forwarded from Aspiring Data Science (Anatoly Alekseev)
#eda
В жизни не видел такого подробного разведанализа!
https://medium.com/@writeronepagecode/deciphering-the-market-a-visual-guide-to-the-jane-street-prediction-challenge-58391826f1c4
В жизни не видел такого подробного разведанализа!
https://medium.com/@writeronepagecode/deciphering-the-market-a-visual-guide-to-the-jane-street-prediction-challenge-58391826f1c4
Medium
Deciphering the Market: A Visual Guide to the Jane Street Prediction Challenge
A step-by-step journey through exploratory data analysis, feature engineering, and modeling financial time series.
Forwarded from Душный NLP
Подборка статей об альтернативах квадратичному селф-аттеншну
В последние годы всё больше обсуждают альтернативы классическому аттеншну — прежде всего из-за стоимости квадратичного скейлинга и работы с длинными контекстами. Ниже — краткий обзор нескольких любопытных работ и блогпостов на тему линейного, sparse- и гибридного аттеншна.
Why Did MiniMax M2 End Up as a Full Attention Model?
Начнём с поста от команды MiniMax. Их первая модель, MiniMax M1, была гибридной и использовала простой линейный аттеншн на матричных стейтах. Но во второй версии, MiniMax M2, они неожиданно вернулись к полному квадратичному аттеншну — даже без sliding window attention (SWA), который уже встречается в опенсорсных моделях.
Авторы говорят, что гибридная архитектура у них попросту не заработала. На классических текстовых бенчмарках всё выглядело приемлемо, а вот на агентских задачах — с кодом, итерациями и длинным контекстом — модель стабильно проигрывала. SWA тоже не помог: при дообучении моделей, изначально предобученных с полным аттеншном, ключевые головы не перестраивались и деградировали.
Итоговый вывод у MiniMax осторожный: линейные и гибридные подходы выглядят перспективно, но пока не хватает инфраструктуры, реализаций и бенчмарков. Поэтому на данный момент они остаются со стандартным трансформером и считают, что сначала нужно больше данных и экспериментов с длинным контекстом.
The Sparse Frontier: Sparse Attention Trade-offs in Transformer LLMs
В этой работе изучают training free sparsity в аттеншне и пытаются понять, что реально работает с точки зрения баланса compute/accuracy. На умеренных контекстах спарсификация аттеншна почти не помогает и часто ухудшает качество. На очень длинных — даёт выигрыш по FLOPs, но часто приводит к ухудшению качества: авторы замечают, что метод, работающий на одной задаче, ломается на другой. В среднем удаётся получить около 5× сжатия без сильной деградации качества, но разброс большой, особенно для маленьких моделей.
Evaluating Long Context (Reasoning) Ability
В следующем посте автор критикует популярные long-context-бенчмарки. Он говорит, что needle-in-a-haystack-like-задачи в основном проверяют ретривал и плохо отражают реальную (более сложную) работу с длинным контекстом. На более сложных задачах, где контекст нужно понять, а не просто найти факт (например, в длинном коде с логическими ошибками), модели начинают деградировать уже на десятках тысяч токенов — даже с Full Attention. Вывод: бенчмарков, которые реально проверяют ризонинг на длинном контексте, пока недостаточно.
Kimi Linear: an expressive, efficient attention architecture
Спустя неделю после скептического поста MiniMax Moonshot AI (авторы модели Kimi K2 и не только) выпустили работу с почти противоположным тезисом: Linear Attention работает. В Kimi Linear предложили Kimi Delta Attention с gated delta rule и рекуррентной матричной памятью. В модели используют соотношение 3:1 линейных слоёв к Full Attention. Качество на бенчмарках в статье не хуже полного аттеншна, а эффективность выше: prefill на длинных промптах быстрее примерно в три раза, декодинг и memory footprint тоже выигрывают за счёт меньшей зависимости от KV-cache.
Разбор подготовил❣ Иван Рубачёв, а ещё он приглашает вас на семинары Yandex Research Reading Group
Душный NLP
В последние годы всё больше обсуждают альтернативы классическому аттеншну — прежде всего из-за стоимости квадратичного скейлинга и работы с длинными контекстами. Ниже — краткий обзор нескольких любопытных работ и блогпостов на тему линейного, sparse- и гибридного аттеншна.
Why Did MiniMax M2 End Up as a Full Attention Model?
Начнём с поста от команды MiniMax. Их первая модель, MiniMax M1, была гибридной и использовала простой линейный аттеншн на матричных стейтах. Но во второй версии, MiniMax M2, они неожиданно вернулись к полному квадратичному аттеншну — даже без sliding window attention (SWA), который уже встречается в опенсорсных моделях.
Авторы говорят, что гибридная архитектура у них попросту не заработала. На классических текстовых бенчмарках всё выглядело приемлемо, а вот на агентских задачах — с кодом, итерациями и длинным контекстом — модель стабильно проигрывала. SWA тоже не помог: при дообучении моделей, изначально предобученных с полным аттеншном, ключевые головы не перестраивались и деградировали.
Итоговый вывод у MiniMax осторожный: линейные и гибридные подходы выглядят перспективно, но пока не хватает инфраструктуры, реализаций и бенчмарков. Поэтому на данный момент они остаются со стандартным трансформером и считают, что сначала нужно больше данных и экспериментов с длинным контекстом.
The Sparse Frontier: Sparse Attention Trade-offs in Transformer LLMs
В этой работе изучают training free sparsity в аттеншне и пытаются понять, что реально работает с точки зрения баланса compute/accuracy. На умеренных контекстах спарсификация аттеншна почти не помогает и часто ухудшает качество. На очень длинных — даёт выигрыш по FLOPs, но часто приводит к ухудшению качества: авторы замечают, что метод, работающий на одной задаче, ломается на другой. В среднем удаётся получить около 5× сжатия без сильной деградации качества, но разброс большой, особенно для маленьких моделей.
Evaluating Long Context (Reasoning) Ability
В следующем посте автор критикует популярные long-context-бенчмарки. Он говорит, что needle-in-a-haystack-like-задачи в основном проверяют ретривал и плохо отражают реальную (более сложную) работу с длинным контекстом. На более сложных задачах, где контекст нужно понять, а не просто найти факт (например, в длинном коде с логическими ошибками), модели начинают деградировать уже на десятках тысяч токенов — даже с Full Attention. Вывод: бенчмарков, которые реально проверяют ризонинг на длинном контексте, пока недостаточно.
Kimi Linear: an expressive, efficient attention architecture
Спустя неделю после скептического поста MiniMax Moonshot AI (авторы модели Kimi K2 и не только) выпустили работу с почти противоположным тезисом: Linear Attention работает. В Kimi Linear предложили Kimi Delta Attention с gated delta rule и рекуррентной матричной памятью. В модели используют соотношение 3:1 линейных слоёв к Full Attention. Качество на бенчмарках в статье не хуже полного аттеншна, а эффективность выше: prefill на длинных промптах быстрее примерно в три раза, декодинг и memory footprint тоже выигрывают за счёт меньшей зависимости от KV-cache.
Разбор подготовил
Душный NLP
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Поступашки - ШАД, Стажировки и Магистратура
How to заботать android-разработку
Периодически можно услышать мнение, что нативная разработка сдаёт позиции, которые перехватывают flutter и real native. Но, во-первых, реальность такова, что для приложений с критическими требованиями к производительности и безопасности (например, в финтехе) нативная разработка - всё ещё мастхев. А, во-вторых, стоит упомянуть быстрое развитие технологии Kotlin Multiplatform, позволяющей разрабатывать фичи для обеих платформ, используя всё тот же котлин и фреймворк Jetpack Compose.
Итак, переходим к роадмапу:
Kotlin
Если вы уже знакомы с экосистемой JVM, то переход на котлин не займёт много времени. Разберитесь с null-safety, классами данных, обработкой исключений, синтаксическим сахаром вроде функций-расширений, в общем, теми концепциями языка, которые делают его удобным и современным. Вопросы на эти темы частенько встречаются на собеседованиях, в том числе в контексте различий между джавой и котлином.
Основы android
После котлина вам нужно разобраться, собственно, с самим андроидом и освоить среду разработки Android Studio, начав реализовывать простое приложение. На этом этапе важно понимание компонентов Activity и Fragment, которые позволяют управлять экранами приложений, и их жизненных циклов.
Далее учимся создавать интерфейс с помощью XML. Да, потом вы перейдёте на Compose, но знание XML-разметки необходимо из-за огромного количества legacy-проектов, которые всё ещё нуждаются в поддержке. Разберитесь с этапами отрисовки View и его жизненным циклом, уделите внимание компоненту RecyclerView, чтобы чётенько разложить интервьюеру, почему списки данных в андроиде так эффективны.
Здесь же автоматизируйте сборку с помощью Gradle.
Многопоточка
Многопоточность - важнейший аспект в мобильной разработке. На собесах этой теме уделяется особое внимание, поэтому здесь стоит потратить время на базу. Разберитесь с основными концепциями асинхронности и корутинами (suspend-функции, structured concurrency), которые позволяют её реализовывать. Иногда интервьюеры спрашивают об эволюции подходов к обеспечению асинхронности, поэтому нелишним будет немного погуглить.
Работа с сетью и хранение данных
Стандарт - библиотека Retrofit, которая преобразует api в kotlin-интерфейс.
Что касается хранения данных, то здесь два варианта: библиотека Room для SQLite и Jetpack DataStore (о Jetpack поговорим следующим пунктом), который пришёл на смену SharedPreferences (но о нём всё ещё спрашивают на собесах).
Jetpack Compose
После того, как вы вдоволь намучились с XML, самое время перейти к фреймворку Jetpack Compose, обновляющему интерфейс автоматически при изменении данных, и базово в нём освоиться (composable-функции, рекомпозиция, управление состоянием, модификаторы, макеты). Можете глянуть для начала этот краткий плейлист, а потом разобраться более основательно.
На работе, вероятнее всего, в какой-то момент вам придётся решать задачу на совместимость Compose и XML, так как большинство проектов проходят через gradual migration.
Архитектура
При проектировании общепринято соблюдение Clean Architecture подхода (хороший плейлист), суть которого в разделении приложения на слои и отделении бизнес-логики от логики интерфейса.
Вам нужно разобраться с ключевым паттерном MVVM, концептуально посмотрите MVP и MVI.
Затем научитесь внедрять зависимости через библиотеку Dagger Hilt (в качестве более простой, но менее популярной альтернативы применяется Koin) для реализации Dependency Injection.
Тестирование
И, конечно, вам нужно научиться покрывать код тестами:
Unit-тесты: JUnit и Mockito
UI-тесты: Espresso, UiAutomator, Kaspresso
видео от Яндекса для лучшего понимания.
Итак, пройдя эти пункты, вы заботаете базу, необходимую для любого android-разработчика.
Ставьте 🔥, если считаете, что мобильщиков несправедливо обделяют, и мы напишем гайд по созданию мощного пет-проекта для прохождения на стажировку мечты!!!
@postypashki_old
Периодически можно услышать мнение, что нативная разработка сдаёт позиции, которые перехватывают flutter и real native. Но, во-первых, реальность такова, что для приложений с критическими требованиями к производительности и безопасности (например, в финтехе) нативная разработка - всё ещё мастхев. А, во-вторых, стоит упомянуть быстрое развитие технологии Kotlin Multiplatform, позволяющей разрабатывать фичи для обеих платформ, используя всё тот же котлин и фреймворк Jetpack Compose.
Итак, переходим к роадмапу:
Kotlin
Если вы уже знакомы с экосистемой JVM, то переход на котлин не займёт много времени. Разберитесь с null-safety, классами данных, обработкой исключений, синтаксическим сахаром вроде функций-расширений, в общем, теми концепциями языка, которые делают его удобным и современным. Вопросы на эти темы частенько встречаются на собеседованиях, в том числе в контексте различий между джавой и котлином.
Основы android
После котлина вам нужно разобраться, собственно, с самим андроидом и освоить среду разработки Android Studio, начав реализовывать простое приложение. На этом этапе важно понимание компонентов Activity и Fragment, которые позволяют управлять экранами приложений, и их жизненных циклов.
Далее учимся создавать интерфейс с помощью XML. Да, потом вы перейдёте на Compose, но знание XML-разметки необходимо из-за огромного количества legacy-проектов, которые всё ещё нуждаются в поддержке. Разберитесь с этапами отрисовки View и его жизненным циклом, уделите внимание компоненту RecyclerView, чтобы чётенько разложить интервьюеру, почему списки данных в андроиде так эффективны.
Здесь же автоматизируйте сборку с помощью Gradle.
Многопоточка
Многопоточность - важнейший аспект в мобильной разработке. На собесах этой теме уделяется особое внимание, поэтому здесь стоит потратить время на базу. Разберитесь с основными концепциями асинхронности и корутинами (suspend-функции, structured concurrency), которые позволяют её реализовывать. Иногда интервьюеры спрашивают об эволюции подходов к обеспечению асинхронности, поэтому нелишним будет немного погуглить.
Работа с сетью и хранение данных
Стандарт - библиотека Retrofit, которая преобразует api в kotlin-интерфейс.
Что касается хранения данных, то здесь два варианта: библиотека Room для SQLite и Jetpack DataStore (о Jetpack поговорим следующим пунктом), который пришёл на смену SharedPreferences (но о нём всё ещё спрашивают на собесах).
Jetpack Compose
После того, как вы вдоволь намучились с XML, самое время перейти к фреймворку Jetpack Compose, обновляющему интерфейс автоматически при изменении данных, и базово в нём освоиться (composable-функции, рекомпозиция, управление состоянием, модификаторы, макеты). Можете глянуть для начала этот краткий плейлист, а потом разобраться более основательно.
На работе, вероятнее всего, в какой-то момент вам придётся решать задачу на совместимость Compose и XML, так как большинство проектов проходят через gradual migration.
Архитектура
При проектировании общепринято соблюдение Clean Architecture подхода (хороший плейлист), суть которого в разделении приложения на слои и отделении бизнес-логики от логики интерфейса.
Вам нужно разобраться с ключевым паттерном MVVM, концептуально посмотрите MVP и MVI.
Затем научитесь внедрять зависимости через библиотеку Dagger Hilt (в качестве более простой, но менее популярной альтернативы применяется Koin) для реализации Dependency Injection.
Тестирование
И, конечно, вам нужно научиться покрывать код тестами:
Unit-тесты: JUnit и Mockito
UI-тесты: Espresso, UiAutomator, Kaspresso
видео от Яндекса для лучшего понимания.
Итак, пройдя эти пункты, вы заботаете базу, необходимую для любого android-разработчика.
Ставьте 🔥, если считаете, что мобильщиков несправедливо обделяют, и мы напишем гайд по созданию мощного пет-проекта для прохождения на стажировку мечты!!!
@postypashki_old
Forwarded from DeepSchool
Ruff: современный и быстрый linter + formatter для Python
Правила оформления кода закреплены в стандартах: какие нужны отступы, длина строк и названия переменных. Они делают код разработчика понятным и единообразным. Правила бывают внутренними (для конкретного проекта) или общими. Например, в Python главный стандарт — PEP8.
Привести код в нужный формат, например, под PEP8 — задача, которая может занять много времени. Поэтому были разработаны вспомогательные инструменты — linters и formatters.
🔜 Linter выполняет статический анализ кода, проверяя его на соответствие заданным правилам, например, PEP8 или пользовательским.
🔜 Formatter автоматически преобразовывает внешний вид кода, не затрагивая его логику и приводя в соответствие заданному стилю оформлению.
Linter и formatter безопасно исправляют код, не меняя его поведения. Они упрощат жизнь разработчка и помогают избежать споров о форматировании и правильности именования классов во время ревью, экономя участникам время и нервы 🙂.
Разработчик вызовом одной команды автоматически форматирует код и находит конкретные участки, которые не соответствуют принятому стандарту, чтобы их поправить. А ревьювер не тратит силы на проверку форматирования, если в CI MR прошёл этапы linter и formatter, уделяя всё внимание на ревью реализации функционала.
Основной linter для python — flake8, а formatters — isort и black. Каждый из них имеет свою конфигурацию и команду запуска.
Использование нескольких инструментов вызывает ряд неудобств:
1. Отдельные файлы конфигураций замусоривают корень проекта и могут конфликтовать между собой.
2. Каждый инструмент — отдельная зависимость, которую надо установить. Кроме того, для flake8, как правило, необходимо доустанавливать отдельные плагины.
3. Каждый инструмент запускается отдельным процессом / задачей в CI и может работать относительно долго на больших кодовых базах.
Ruff помогает избавиться от них: он ставится одним python package, правила для форматирования и различных linters описываются в одном конфиге, а реализация на Rust делает его быстрее аналогов🚀.
Пример внедрения ruff в проект
В
В
Далее:
Автор: Иван Перминов
Правила оформления кода закреплены в стандартах: какие нужны отступы, длина строк и названия переменных. Они делают код разработчика понятным и единообразным. Правила бывают внутренними (для конкретного проекта) или общими. Например, в Python главный стандарт — PEP8.
Привести код в нужный формат, например, под PEP8 — задача, которая может занять много времени. Поэтому были разработаны вспомогательные инструменты — linters и formatters.
Linter и formatter безопасно исправляют код, не меняя его поведения. Они упрощат жизнь разработчка и помогают избежать споров о форматировании и правильности именования классов во время ревью, экономя участникам время и нервы 🙂.
Разработчик вызовом одной команды автоматически форматирует код и находит конкретные участки, которые не соответствуют принятому стандарту, чтобы их поправить. А ревьювер не тратит силы на проверку форматирования, если в CI MR прошёл этапы linter и formatter, уделяя всё внимание на ревью реализации функционала.
Основной linter для python — flake8, а formatters — isort и black. Каждый из них имеет свою конфигурацию и команду запуска.
Использование нескольких инструментов вызывает ряд неудобств:
1. Отдельные файлы конфигураций замусоривают корень проекта и могут конфликтовать между собой.
2. Каждый инструмент — отдельная зависимость, которую надо установить. Кроме того, для flake8, как правило, необходимо доустанавливать отдельные плагины.
3. Каждый инструмент запускается отдельным процессом / задачей в CI и может работать относительно долго на больших кодовых базах.
Ruff помогает избавиться от них: он ставится одним python package, правила для форматирования и различных linters описываются в одном конфиге, а реализация на Rust делает его быстрее аналогов🚀.
Пример внедрения ruff в проект
В
pyproject.toml добавляются следующие строки:[tool.ruff] # Общие настройки ruff
extend-exclude = ["*.ipynb"] # Исключаем Jupyter-ноутбуки из проверки
line-length = 120 # Лимит длины строки
lint.select = [ # Добавляем правила из списка https://docs.astral.sh/ruff/rules
"E", # pycodestyle
"F", # pyflakes
"I", # isort
]
lint.ignore = [
"F821", # Пример добавления игнорирования правил
]
[tool.ruff.format] # Отдельные настройки форматтера
quote-style = "double" # Перевод одинарных кавычек в двойные
indent-style = "space" # Перевод табов в пробелы
В
.pre-commit-config.yaml добавляются следующие строки:repos:
- repo: https://github.com/astral-sh/ruff-pre-commit
rev: v0.14.7
hooks:
- id: ruff
types_or: [ python, pyi, jupyter ]
- id: ruff-format
types_or: [ python, pyi, jupyter ]
args: [ "--check", "--diff" ]
Далее:
# Устанавливаем зависимости
pip install pre-commit ruff
# После настройки linter и formatter создаем hooks для commit/push
pre-commit install
# Использование
ruff check --fix # Запустит linter, подсветит ошибки и исправит некоторые ошибки
ruff format # Запустит formatter и отформатирует код
Автор: Иван Перминов
Про форматтеры, линтеры и другие инженерные практики, помогающие навести порядок в репозиториях DL-инженеров, рассказываем на курсе «Деплой DL-сервисов»⚡️
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Всеволод Викулин | AI разбор
Друзья, опубликовал подробный фреймворк оценки качества LLM.
Он состоит из 7-ми шагов, по которым вы сделаете метрику под вашу LLM-задачу. Там много примеров, наглядных схем, основанных на моей 3-летней практике.
Если после прочтения остались вопросы, как в вашем случае строить метрики качества, напишите мне в личные сообщения — разберем ваш случай отдельно.
Он состоит из 7-ми шагов, по которым вы сделаете метрику под вашу LLM-задачу. Там много примеров, наглядных схем, основанных на моей 3-летней практике.
Если после прочтения остались вопросы, как в вашем случае строить метрики качества, напишите мне в личные сообщения — разберем ваш случай отдельно.
vikulin.ai
Как оценить качество LLM? Пошаговая методика создания надежных метрик.
Оценка качества — ключ к успешному внедрению LLM. В статье разберем, какими свойствами должна обладать метрика LLM, и выведем формулу, по которой вы сможете настроить надежную оценку качества.
Forwarded from Всеволод Викулин | AI разбор
Друзья, привет! Нас уже более 3-х тысяч, спасибо вам за это. Для тех, кто недавно со мной знаком, расскажу про себя и канал.
Я Сева, и уже 9 лет занимаюсь внедрением AI. Работал в VK, Яндексе, сейчас в Т-Банке. Начинал стажером, стал разработчиком, сейчас руководитель команд.
За 9 лет я много раз делал не так. Пришлось структурировать свой опыт в методику «как внедрять AI хорошо», чтобы избежать дальнейших ошибок. Год назад я понял — в этой методике нет ничего сложного, и я могу ей обучить. Не только инженера, но и аналитика, продуктового менеджера, маркетолога. И создал этот канал.
Я верю, что всем нужны эти знания. Каждый из нас лучше других знает, как и куда ему внедрить AI, чтобы было хорошо его компании, отделу и лично ему.
Далее перечислю материалы, которыми я горжусь больше всего.
Статьи про методику внедрения AI:
- 12 правил внедрения LLM
- Почему генеративный AI не приносит прибыли
- Методика оценки качества LLM
Основные посты про методику:
- Главный пост про итеративный фреймворк работы с AI-проектом
- Платформа — ключ к массовому внедрению AI
- Почему нельзя купить AI из коробки
- Как неправильное внедрение стоило компании полмиллиарда долларов
- Почему чаще всего не стоит делать своего code-ассистента. Кейс Uber
- 3 кита улучшения любой LLM
- Как можно сделать модель лучше, чем OpenAI и всего за 8 долларов
Кейсы:
- Ставим разработку AI-агентов на поток
- Как создали AI-агента аналитика
- Агент, который исследует информацию в интернете
- Массовая обработка документов на LLM
Уверен, в следующем году в этом посте будет минимум в 2 раза больше полезных материалов.
Если у вас есть мысли, идеи или вопросы по внедрению AI, всегда можно написать мне @seva_batareika
Я Сева, и уже 9 лет занимаюсь внедрением AI. Работал в VK, Яндексе, сейчас в Т-Банке. Начинал стажером, стал разработчиком, сейчас руководитель команд.
За 9 лет я много раз делал не так. Пришлось структурировать свой опыт в методику «как внедрять AI хорошо», чтобы избежать дальнейших ошибок. Год назад я понял — в этой методике нет ничего сложного, и я могу ей обучить. Не только инженера, но и аналитика, продуктового менеджера, маркетолога. И создал этот канал.
Я верю, что всем нужны эти знания. Каждый из нас лучше других знает, как и куда ему внедрить AI, чтобы было хорошо его компании, отделу и лично ему.
Далее перечислю материалы, которыми я горжусь больше всего.
Статьи про методику внедрения AI:
- 12 правил внедрения LLM
- Почему генеративный AI не приносит прибыли
- Методика оценки качества LLM
Основные посты про методику:
- Главный пост про итеративный фреймворк работы с AI-проектом
- Платформа — ключ к массовому внедрению AI
- Почему нельзя купить AI из коробки
- Как неправильное внедрение стоило компании полмиллиарда долларов
- Почему чаще всего не стоит делать своего code-ассистента. Кейс Uber
- 3 кита улучшения любой LLM
- Как можно сделать модель лучше, чем OpenAI и всего за 8 долларов
Кейсы:
- Ставим разработку AI-агентов на поток
- Как создали AI-агента аналитика
- Агент, который исследует информацию в интернете
- Массовая обработка документов на LLM
Уверен, в следующем году в этом посте будет минимум в 2 раза больше полезных материалов.
Если у вас есть мысли, идеи или вопросы по внедрению AI, всегда можно написать мне @seva_batareika
Forwarded from Женя Янченко
Очереди в Кафке
В 2025 году в Kafka начиная с версии 4.0 появился новый тип групп — share groups, которые обеспечивают работу с сообщениями как в очередях, а не в виде лога (как это обычно в Kafka).
Сообщения в Kafka логически распределены по топикам (например, orders, checks). Топик разбиты на партиции. Именно партиция является физической группировкой сообщений. Про топики, партиции, продюсеров и консьюмер группы у меня есть серия постов.
Consumer groups и привычные паттерны работы остались, просто появилась альтернатива в виде share groups.
Основные различия между share group и consumer group:
➡️ Совместное чтение из одной партиции
Внутри consumer группы одну партицию может читать только один консьюмер.
В share group консьюмеры совместно читают из партиций, то есть одна партиция может быть назначена нескольким консьюмерам одновременно. Kafka сама динамически распределяет доступные сообщения из партиций между консьюмерами так, чтобы балансировать нагрузку.
➡️ Количество консьюмеров в share group может превышать количество партиций в топике.
В случае с consumer groups, если мы хотим сильнее масштабироваться, нужно увеличить количество партиций. Если для топика с 3 партициями мы поднимем 4 консьюмера, то 4-й будет простаивать (пока кто-то из 3-х не отвалится). Поэтому число партиций определяет максимальный параллелизм, с которым мы можем обрабатывать сообщения. Но уменьшить их потом нельзя, плюс топик может быть другой команды.
В случае с share group мы можем поднять много консьюмеров, чтобы обработать нагрузку в пике.
➡️ Порядок сообщений не сохраняется
В партиции сообщения лежат по порядку. Но поскольку из одной и той же партиции в share группе могут читать два и более консьюмера, они могут обработать сообщения не по порядку.
Продолжение⬇️
В 2025 году в Kafka начиная с версии 4.0 появился новый тип групп — share groups, которые обеспечивают работу с сообщениями как в очередях, а не в виде лога (как это обычно в Kafka).
Совсем кратко: в share groups несколько консьюмеров читают одну партицию, поэтому не сохраняется порядок доставки, зато удобно масштабировать.
Сообщения в Kafka логически распределены по топикам (например, orders, checks). Топик разбиты на партиции. Именно партиция является физической группировкой сообщений. Про топики, партиции, продюсеров и консьюмер группы у меня есть серия постов.
Consumer groups и привычные паттерны работы остались, просто появилась альтернатива в виде share groups.
Основные различия между share group и consumer group:
Внутри consumer группы одну партицию может читать только один консьюмер.
В share group консьюмеры совместно читают из партиций, то есть одна партиция может быть назначена нескольким консьюмерам одновременно. Kafka сама динамически распределяет доступные сообщения из партиций между консьюмерами так, чтобы балансировать нагрузку.
В случае с consumer groups, если мы хотим сильнее масштабироваться, нужно увеличить количество партиций. Если для топика с 3 партициями мы поднимем 4 консьюмера, то 4-й будет простаивать (пока кто-то из 3-х не отвалится). Поэтому число партиций определяет максимальный параллелизм, с которым мы можем обрабатывать сообщения. Но уменьшить их потом нельзя, плюс топик может быть другой команды.
В случае с share group мы можем поднять много консьюмеров, чтобы обработать нагрузку в пике.
В партиции сообщения лежат по порядку. Но поскольку из одной и той же партиции в share группе могут читать два и более консьюмера, они могут обработать сообщения не по порядку.
Пример:
Два консьюмера в share group читают топик с одной партицией. Первый консьюмер получает записи с offset 100 по 109 включительно и падает. В это же время второй консьюмер получает, обрабатывает и подтверждает записи 110–119. Затем второй консьюмер получает необработанные первым записи 100–109, обрабатывает и подтверждает. Все сообщения обработаны, но порядок обработки не сохранен.
Продолжение
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Женя Янченко
Очереди в Кафке (продолжение)
Продолжаем рассматривать особенности share groups, которые обеспечивают работу с сообщениями как в очередях.
➡️ Чтение каждого сообщения подтверждается индивидуально
В случае consumer groups чтение фиксируется коммитом оффсета для каждой партиции. Если для этой консьюмер-группы закоммичен оффсет на сообщении 90, значит все сообщения до 90 включительно, прочитаны.
В share группе появляется понятие окна чтения (in-flight records) и статусная модель сообщения.
Статусы:
🌟 Available — сообщение доступно для чтения консьюмером
🌟 Acquired — сообщения было взято в обработку (залочено) конкретным консьюмером (время, на которое сообщение залочено, настраивается параметром
🌟 Acknowledged — сообщение обработано консьюмером (можно сказать, что это аналог коммита оффсета, но лишь для одного сообщения)
🌟 Archived — сообщение признано архивным, больше недоступно для чтения никаким консьюмером в этой share группе.
➡️ Лимит количества попыток доставки сообщения
Для share группы настраивается параметр
Жизненный цикл сообщение в share группе:
1️⃣ Сначала сообщение находится в статусе Available. Его забирает на обработку какой-то из консьюмеров. Счетчик попыток доставки увеличивается на 1. Если у сообщения еще не исчерпан лимит попыток обработки, то его статус становится Acquired. Если лимит попыток исчерпан, то оно становится Archived.
2️⃣ Если консьюмер обработал сообщение, то оно переводится в статус Acknowledged. Также консьюмер может зареджектить сообщение (например, если оно невалидное). Тогда оно становится Archived. Если консьюмер не успел обработать сообщение за время лока (30 сек), то оно снова становится Available.
3️⃣ Со временем, когда окно чтения сдвигается, все Acknowledged из прошлого окна становятся Archived.
Важно, что эти статусы работают в рамках конкретной share group. В одной share group это сообщение уже Archived, а в другой - Available.
Share groups — это просто другой тип группы потребителей, использующий другую модель распределения записей и другой протокол подтверждения:
🟢 consumer groups читают топик как лог
🟢 share groups читают тот же топик как очередь
Когда может пригодиться новый подход с share groups?
Если нам нужна очередь, а не лог: сообщения - это независимые события, которые можно обрабатывать параллельно, порядок некритичен, при этом мы хотим динамически масштабировать их обработку. Хотим ускорить обработку - добавляем больше воркеров (консьюмеров).
Подробно почитать про нововведение можно в доке: KIP-932: Queues for Kafka
Очень круто, что Kafka так развивается! Конечно, фича новая, сейчас правят баги, но для будущих проектов считаю интересно иметь в виду.
#kafka
Продолжаем рассматривать особенности share groups, которые обеспечивают работу с сообщениями как в очередях.
В случае consumer groups чтение фиксируется коммитом оффсета для каждой партиции. Если для этой консьюмер-группы закоммичен оффсет на сообщении 90, значит все сообщения до 90 включительно, прочитаны.
В share группе появляется понятие окна чтения (in-flight records) и статусная модель сообщения.
Статусы:
share.record.lock.duration.ms, по-умолчанию 30 сек)Для share группы настраивается параметр
group.share.delivery.attempt.limit (по-умолчанию 5) — это лимит попыток доставки. Для каждого сообщения Kafka ведет счетчик. Лимит позволяет бороться с невалидными сообщениями, чтобы они не доставлялись бесконечно.Жизненный цикл сообщение в share группе:
Важно, что эти статусы работают в рамках конкретной share group. В одной share group это сообщение уже Archived, а в другой - Available.
Топики и партиции остаются теми же, что были. Один сервис может читать топик через consumer группу, а другой - читать этот же топик через share группу. Продюсер вообще не знает, кто там и как читает. Его дело в партиции записать.
Share groups — это просто другой тип группы потребителей, использующий другую модель распределения записей и другой протокол подтверждения:
Когда может пригодиться новый подход с share groups?
Если нам нужна очередь, а не лог: сообщения - это независимые события, которые можно обрабатывать параллельно, порядок некритичен, при этом мы хотим динамически масштабировать их обработку. Хотим ускорить обработку - добавляем больше воркеров (консьюмеров).
Подробно почитать про нововведение можно в доке: KIP-932: Queues for Kafka
Очень круто, что Kafka так развивается! Конечно, фича новая, сейчас правят баги, но для будущих проектов считаю интересно иметь в виду.
#kafka
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Женя Янченко
Грабли карьерного роста
На своем первом месте работы я очень хотела расти. Правда, не знала, как это сделать и совершила ошибку. Я была вовлеченной, много делала, старалась делать ещё больше и ещё быстрее. Но я ни разу не сказала своему руководителю, что хочу расти.
Поэтому мне казалось, что мои усилия никуда не ведут, что место какое-то тупиковое (хотя это была большая компания) и написала заявление.
А когда принесла заявление, то оказалось, что начальник начал готовить мое повышение, но я решила, что фарш не провернуть назад и всё же ушла.
На новом месте я учла ошибку. На испытательном срока постаралась зарекомендовать себя как человек, способный на большее, и почти сразу после ИС поговорила с руководителем о том, что хочу и готова расти.
Удивительно, но он не сказал: «конечно, какие вопросы, с завтрашнего дня ты межгалактический директор» 😂
Он ответил, что это здорово, и он будет иметь в виду 😃
Я стала искать все способы проявить себя. Оказалось, что если их искать, они найдутся. Усилия дали результат, и я выросла до лида проджектов.
Но я слишком сильно горела работой, не умела говорить «нет» на работе, и через пару лет у меня периодически стал дергаться глаз 🙈
Сейчас вижу, как можно было прийти к тем же результатам меньшими усилиями 😅
Когда перешла в разработку, то наступила на другие грабли. Я была не уверена в себе, и это чувствовалось при общении. При этом я много читала, учила и работала, но голос дрожал что ли) Вот пост, как я это преодолевала.
Когда пришла лидом в новую компанию, то постаралась учесть все предыдущие ошибки 🤓 Держать фокус на том, что важно, не закапываться, не бояться задавать вопросы, наладить отношения с коллегами и руководством, проявлять инициативу. Иииии это сработало!
Мне предложили повышение раньше, чем я могла на это рассчитывать 😱 Работы, конечно, стало больше, но я постаралась организовать режим так, чтобы работа меня не съела.
Иногда мне хочется обернуться назад и потрясти себя прошлую за плечи. Ну вот чего ты боялась, стеснялась, работу свою не показывала толком. Иди 1-1 с руководителем поставь и план напиши. Увы, эти знания я приобрела только с опытом🙂
А у вас было такое, что вы хотели роста, но явно не говорили, а руководитель не замечал?
На своем первом месте работы я очень хотела расти. Правда, не знала, как это сделать и совершила ошибку. Я была вовлеченной, много делала, старалась делать ещё больше и ещё быстрее. Но я ни разу не сказала своему руководителю, что хочу расти.
Поэтому мне казалось, что мои усилия никуда не ведут, что место какое-то тупиковое (хотя это была большая компания) и написала заявление.
А когда принесла заявление, то оказалось, что начальник начал готовить мое повышение, но я решила, что фарш не провернуть назад и всё же ушла.
На новом месте я учла ошибку. На испытательном срока постаралась зарекомендовать себя как человек, способный на большее, и почти сразу после ИС поговорила с руководителем о том, что хочу и готова расти.
Удивительно, но он не сказал: «конечно, какие вопросы, с завтрашнего дня ты межгалактический директор» 😂
Он ответил, что это здорово, и он будет иметь в виду 😃
Я стала искать все способы проявить себя. Оказалось, что если их искать, они найдутся. Усилия дали результат, и я выросла до лида проджектов.
Но я слишком сильно горела работой, не умела говорить «нет» на работе, и через пару лет у меня периодически стал дергаться глаз 🙈
Сейчас вижу, как можно было прийти к тем же результатам меньшими усилиями 😅
Когда перешла в разработку, то наступила на другие грабли. Я была не уверена в себе, и это чувствовалось при общении. При этом я много читала, учила и работала, но голос дрожал что ли) Вот пост, как я это преодолевала.
Когда пришла лидом в новую компанию, то постаралась учесть все предыдущие ошибки 🤓 Держать фокус на том, что важно, не закапываться, не бояться задавать вопросы, наладить отношения с коллегами и руководством, проявлять инициативу. Иииии это сработало!
Мне предложили повышение раньше, чем я могла на это рассчитывать 😱 Работы, конечно, стало больше, но я постаралась организовать режим так, чтобы работа меня не съела.
А через пару лет мой руководитель даже рекомендовал меня на позицию CTO другого продукта внутри компании. Я прошла собес, но отказалась от офера и осталась в своем продукте. Так тоже бывает 🙃
Иногда мне хочется обернуться назад и потрясти себя прошлую за плечи. Ну вот чего ты боялась, стеснялась, работу свою не показывала толком. Иди 1-1 с руководителем поставь и план напиши. Увы, эти знания я приобрела только с опытом
А у вас было такое, что вы хотели роста, но явно не говорили, а руководитель не замечал?
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Свет из чёрного ящика
Подборка статей 2025 (часть 3)
Attention-based ranking
- LONGER: Scaling Up Long Sequence Modeling in Industrial Recommenders
- TransAct V2: Lifelong User Action Sequence Modeling on Pinterest Recommendation
- Twin-Flow Generative Ranking Network for Recommendation
- InterFormer: Effective Heterogeneous Interaction Learning for Click-Through Rate Prediction
- MARM: Unlocking the Recommendation Cache Scaling-Law through Memory Augmentation and Scalable Complexity
- GReF: A Unified Generative Framework for Efficient Reranking via Ordered Multi-token Prediction
- RankMixer: Scaling Up Ranking Models in Industrial Recommenders
- Climber: Toward Efficient Scaling Laws for Large Recommendation Models
- MTGR: Industrial-Scale Generative Recommendation Framework in Meituan
- Action is All You Need: Dual-Flow Generative Ranking Network for Recommendation
- Make It Long, Keep It Fast: End-to-End 10k-Sequence Modeling at Billion Scale on Douyin
- OneTrans: Unified Feature Interaction and Sequence Modeling with One Transformer in Industrial Recommender
- Massive Memorization with Hundreds of Trillions of Parameters for Sequential Transducer Generative Recommenders
- Practice on Long Behavior Sequence Modeling in Tencent Advertising
- Pyramid Mixer: Multi-dimensional Multi-period Interest Modeling for Sequential Recommendation
- Adaptive Domain Scaling for Personalized Sequential Modeling in Recommenders
- From Features to Transformers: Redefining Ranking for Scalable Impact
- From Scaling to Structured Expressivity: Rethinking Transformers for CTR Prediction
- Meta Lattice: Model Space Redesign for Cost-Effective Industry-Scale Ads Recommendations
Non-Two-Tower retrieval
- Autoregressive Generative Retrieval for Industrial-Scae Recommendations at Pinterest
- MPFormer: Adaptive Framework for Industrial Multi-Task Personalized Sequential Retriever
- MISS: Multi-Modal Tree Indexing and Searching with Lifelong Sequential Behavior for Retrieval Recommendation
- Sparse Meets Dense: Unified Generative Recommendations with Cascaded Sparse-Dense Representations
- Bidding-Aware Retrieval for Multi-Stage Consistency in Online Advertising
- Equip Pre-ranking with Target Attention by Residual Quantization
- GRank: Towards Target-Aware and Streamlined Industrial Retrieval with a Generate-Rank Framework
- SilverTorch: A Unified Model-based System to Democratize Large-Scale Recommendation on GPUs
- DualGR: Generative Retrieval with Long and Short-Term Interests Modeling
- An Efficient Embedding Based Ad Retrieval with GPU-Powered Feature Interaction
- Hierarchical Structured Neural Network: Efficient Retrieval Scaling for Large Scale Recommendation
Attention-based ranking
- LONGER: Scaling Up Long Sequence Modeling in Industrial Recommenders
- TransAct V2: Lifelong User Action Sequence Modeling on Pinterest Recommendation
- Twin-Flow Generative Ranking Network for Recommendation
- InterFormer: Effective Heterogeneous Interaction Learning for Click-Through Rate Prediction
- MARM: Unlocking the Recommendation Cache Scaling-Law through Memory Augmentation and Scalable Complexity
- GReF: A Unified Generative Framework for Efficient Reranking via Ordered Multi-token Prediction
- RankMixer: Scaling Up Ranking Models in Industrial Recommenders
- Climber: Toward Efficient Scaling Laws for Large Recommendation Models
- MTGR: Industrial-Scale Generative Recommendation Framework in Meituan
- Action is All You Need: Dual-Flow Generative Ranking Network for Recommendation
- Make It Long, Keep It Fast: End-to-End 10k-Sequence Modeling at Billion Scale on Douyin
- OneTrans: Unified Feature Interaction and Sequence Modeling with One Transformer in Industrial Recommender
- Massive Memorization with Hundreds of Trillions of Parameters for Sequential Transducer Generative Recommenders
- Practice on Long Behavior Sequence Modeling in Tencent Advertising
- Pyramid Mixer: Multi-dimensional Multi-period Interest Modeling for Sequential Recommendation
- Adaptive Domain Scaling for Personalized Sequential Modeling in Recommenders
- From Features to Transformers: Redefining Ranking for Scalable Impact
- From Scaling to Structured Expressivity: Rethinking Transformers for CTR Prediction
- Meta Lattice: Model Space Redesign for Cost-Effective Industry-Scale Ads Recommendations
Non-Two-Tower retrieval
- Autoregressive Generative Retrieval for Industrial-Scae Recommendations at Pinterest
- MPFormer: Adaptive Framework for Industrial Multi-Task Personalized Sequential Retriever
- MISS: Multi-Modal Tree Indexing and Searching with Lifelong Sequential Behavior for Retrieval Recommendation
- Sparse Meets Dense: Unified Generative Recommendations with Cascaded Sparse-Dense Representations
- Bidding-Aware Retrieval for Multi-Stage Consistency in Online Advertising
- Equip Pre-ranking with Target Attention by Residual Quantization
- GRank: Towards Target-Aware and Streamlined Industrial Retrieval with a Generate-Rank Framework
- SilverTorch: A Unified Model-based System to Democratize Large-Scale Recommendation on GPUs
- DualGR: Generative Retrieval with Long and Short-Term Interests Modeling
- An Efficient Embedding Based Ad Retrieval with GPU-Powered Feature Interaction
- Hierarchical Structured Neural Network: Efficient Retrieval Scaling for Large Scale Recommendation