Forwarded from Young&&Yandex
Что чаще всего спрашивают на теории и какие темы стоит повторить — в карточках.
Оставляй заявку на стажировку
Подписывайся
@Young_and_Yandex
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Quant Researcher
🤖 ML инструменты кванта
В мире квантовых стратегий всем известны оси Ильинского: гамма‑риск, вега‑риск, jump‑риск (и тета). Эти оси помогают понять, какие риски и премии мы продаём или покупаем. Но когда речь заходит о машинном обучении, многие сразу представляют себе «магическую коробочку», которая будет угадывать цену завтра. Это заблуждение. ML в работе кванта — это набор инструментов для анализа и понимания данных.
Рассказываем, где ML действительно полезен.
📊 1. Сбор, отчистка и подготовка данных
Любая стратегия начинается с данных (треш на входе — треш на выходе). В современном альфа‑конвейере данные бывают числовые (котировки, фундаментальные показатели), реляционные (например, граф связей между компаниями), альтернативные (тексты в соцсетях, новости, спутниковые снимки, Wi‑Fi‑трафик) и даже симуляции (From Deep Learning to LLMs: A survey of AI in Quantitative Investment). Такие разнородные потоки нужно очистить, стандартизировать и привести к единому формату, а затем превратить в признаки, чтобы они могли служить входом для моделей, необязательно ML.
На этот этап уходит львиная доля времени кванта. И опыт ML может в этом сильно-сильно помочь!
🔍 2. Извлечение признаков и скрытых факторов
После чистки данных следует этап построения признаков и поиска скрытых структур. Здесь на помощь приходят методы без учителя. Кластеризация (K‑means, иерархические алгоритмы, DBSCAN) используется для сегментации рынка: данные группируются по объёму торгов, волатильности и другим атрибутам, что помогает выявить разные режимы и типы участников, иногда — натолкнуть на стратегию. Алгоритмы обнаружения аномалий (density‑based clustering, автоэнкодеры) нужны для выявления паттернов на рынке (Quantitative Finance and Machine Learning:
Transforming Investment Strategies, Risk Modeling, and
Market Forecasting in Global Markets).
Кластеризация, кстати, применяется не только на рыночных данных, но и в кредитном скоринге, но об этом можно почитать почти в любом ML-канале или изучить на практике, если поработать в банке.
🧠 3. Алгоритмическая торговля и управление ордерами
ML помогает не только анализировать данные, но и выполнять действия. В алгоритмической торговле модели управляют исполнением ордеров: supervised‑алгоритмы предсказывают краткосрочные движения, риски и факторы, unsupervised‑модели ищут необычные паттерны, а reinforcement learning обучает агента выбирать время выхода на рынок, максимизируя, например, дифференциальный коэффициент Шарпа. Такие системы анализируют ликвидность, волатильность и косты, чтобы оптимизировать execution.
⚖️ 4. Прозрачность
Мощные ML‑модели дают преимущество, но несут риски: переобучение, «чёрный ящик» и зависимость от качественных данных. Поэтому прозрачность и explainable AI — не пустые слова. Важно понимать, какие признаки определяют решения модели, и в идеале уметь объяснить их инвестору или хотя бы себе. Использование машинного обучения — это прежде всего развитие аналитики: мы усиливаем классические финансовые подходы, а не подменяем их.
Вместо итогов
Машинное обучение в работе кванта — это не про «угадывать цены», а строить инструменты:
• чистить и структурировать данные,
• извлекать информативные факторы,
• находить скрытые паттерны,
• измерять и контролировать риски,
• использовать новые источники информации.
Это ценный набор в арсенале кванта, дополняющий опционную геометрию и понимание рисков. Как и в примере с гаммой, вегой и jump‑риском, главное — понимать, какие риски вы покупаете, где вы зарабатываете премию и как ваша модель взаимодействует с рынком.
Что думаете? Какие ML‑инструменты уже использовали в своих стратегиях?
Quant Researcher
В мире квантовых стратегий всем известны оси Ильинского: гамма‑риск, вега‑риск, jump‑риск (и тета). Эти оси помогают понять, какие риски и премии мы продаём или покупаем. Но когда речь заходит о машинном обучении, многие сразу представляют себе «магическую коробочку», которая будет угадывать цену завтра. Это заблуждение. ML в работе кванта — это набор инструментов для анализа и понимания данных.
Рассказываем, где ML действительно полезен.
📊 1. Сбор, отчистка и подготовка данных
Любая стратегия начинается с данных (треш на входе — треш на выходе). В современном альфа‑конвейере данные бывают числовые (котировки, фундаментальные показатели), реляционные (например, граф связей между компаниями), альтернативные (тексты в соцсетях, новости, спутниковые снимки, Wi‑Fi‑трафик) и даже симуляции (From Deep Learning to LLMs: A survey of AI in Quantitative Investment). Такие разнородные потоки нужно очистить, стандартизировать и привести к единому формату, а затем превратить в признаки, чтобы они могли служить входом для моделей, необязательно ML.
На этот этап уходит львиная доля времени кванта. И опыт ML может в этом сильно-сильно помочь!
🔍 2. Извлечение признаков и скрытых факторов
После чистки данных следует этап построения признаков и поиска скрытых структур. Здесь на помощь приходят методы без учителя. Кластеризация (K‑means, иерархические алгоритмы, DBSCAN) используется для сегментации рынка: данные группируются по объёму торгов, волатильности и другим атрибутам, что помогает выявить разные режимы и типы участников, иногда — натолкнуть на стратегию. Алгоритмы обнаружения аномалий (density‑based clustering, автоэнкодеры) нужны для выявления паттернов на рынке (Quantitative Finance and Machine Learning:
Transforming Investment Strategies, Risk Modeling, and
Market Forecasting in Global Markets).
Кластеризация, кстати, применяется не только на рыночных данных, но и в кредитном скоринге, но об этом можно почитать почти в любом ML-канале или изучить на практике, если поработать в банке.
🧠 3. Алгоритмическая торговля и управление ордерами
ML помогает не только анализировать данные, но и выполнять действия. В алгоритмической торговле модели управляют исполнением ордеров: supervised‑алгоритмы предсказывают краткосрочные движения, риски и факторы, unsupervised‑модели ищут необычные паттерны, а reinforcement learning обучает агента выбирать время выхода на рынок, максимизируя, например, дифференциальный коэффициент Шарпа. Такие системы анализируют ликвидность, волатильность и косты, чтобы оптимизировать execution.
⚖️ 4. Прозрачность
Мощные ML‑модели дают преимущество, но несут риски: переобучение, «чёрный ящик» и зависимость от качественных данных. Поэтому прозрачность и explainable AI — не пустые слова. Важно понимать, какие признаки определяют решения модели, и в идеале уметь объяснить их инвестору или хотя бы себе. Использование машинного обучения — это прежде всего развитие аналитики: мы усиливаем классические финансовые подходы, а не подменяем их.
Вместо итогов
Машинное обучение в работе кванта — это не про «угадывать цены», а строить инструменты:
• чистить и структурировать данные,
• извлекать информативные факторы,
• находить скрытые паттерны,
• измерять и контролировать риски,
• использовать новые источники информации.
Это ценный набор в арсенале кванта, дополняющий опционную геометрию и понимание рисков. Как и в примере с гаммой, вегой и jump‑риском, главное — понимать, какие риски вы покупаете, где вы зарабатываете премию и как ваша модель взаимодействует с рынком.
Что думаете? Какие ML‑инструменты уже использовали в своих стратегиях?
Quant Researcher
Forwarded from Data Blog
"Gotta Catch 'Em All"
С 1997 года существовала медиафраншиза — Pokemon. Покемоны были чем-то вроде животных, которые могли обретать в течении своей жизни разные стадии — эволюционировать. Я смотрела все серии аниме, поэтому на слово "эволюция" у меня не нормальная реакция. Но мы здесь собрались за другим контентом, поэтому это интро связано со статьей EVOLUTION OF CONCEPTS IN LANGUAGE MODEL PRE-TRAINING.
Предыстория.
С относительно недавнего времени мы можем разбивать всё пространство активаций LLM на атомарные сущности — признаки (features). Представьте: берем активационные векторы размерности n и проектируем их в пространство размерности N >> n, добиваясь разреженности.
Методы.
Этот трюк обычно делается с помощью Sparse Autoencoders — сетей, которые в латенте дают разреженный вектор, обещающий понятные человеку концепты. Отдельные единицы такого вектора активируются только на схожих признаках, например: один компонент может реагировать на упоминания городов, другой — на математические формулы.
Позже появились Transcoders — продвинутая версия SAE, которая учится разлагать не активации, а вычисления внутри MLP слоя. Так как трансофрмер аддитивен, трансокдеры на разных слоях позволяют строить цепочки — эволюцию прохождений фичей от слоя к слою.
А потом к ним пришли Crosscoders — модели, с архитектурой транскодера, но адаптированные к учету информации из нескольких слоёв.
Каждый "кодер" состоит из трех частей:
1) Энкодер — делает разреженное представление.
2) Латент — само разреженное представление.
3) Декодер — восстанавливает input из разреженного представления.
К исследованию.
В классике кодеры применялись, чтобы изучить признаки в уже обученных моделей. А тут статья предлагает изучить процесс обучения, используя разреженность.
Для этого используют используют crosscoders и теоретическую предпосылку — если признак не существует, штраф за разреженность подавит веса декодеров в "неактивных" моментах до нуля (признака нет — восстанавливать мы его тоже не будем).
Из этой теории рассматривают норму весов декодера||W_dec|| для фичи i (из теории построения также мы знаем, что столбец декодера всегда кодирует какую-то фичу).
Для нормы авторы ввели Peak Snapshot Index — число k [1, 32], показывающее, на каком моменте времени в обучении фича достигла максимальной силы. В частности 143 000 шага обучения побили на 32 снэпшота и на них смотрели активации признака (при этом норму декодера снимали на каждом шаге).
В такой постановке нашли следующее:
1. Двухфазная структура:
Статистическая фаза (ранние шаги): модель изучает частоты токенов, потери падают до теоретического минимума
Фаза фич (поздние шаги): формируются сложные концепты в суперпозиции
2.Иерархия:
Простые фичи (предыдущий токен) ~1000-5000 шагов
Индукционные фичи ~10000-100000 шагов
Контекстно-зависимые — на финальных стадиях
3. Точку поворота: Около шага 1000 большинство фич кардинально меняют направление в пространстве активаций
Красивые картинки нашли тоже.
С 1997 года существовала медиафраншиза — Pokemon. Покемоны были чем-то вроде животных, которые могли обретать в течении своей жизни разные стадии — эволюционировать. Я смотрела все серии аниме, поэтому на слово "эволюция" у меня не нормальная реакция. Но мы здесь собрались за другим контентом, поэтому это интро связано со статьей EVOLUTION OF CONCEPTS IN LANGUAGE MODEL PRE-TRAINING.
Предыстория.
С относительно недавнего времени мы можем разбивать всё пространство активаций LLM на атомарные сущности — признаки (features). Представьте: берем активационные векторы размерности n и проектируем их в пространство размерности N >> n, добиваясь разреженности.
Методы.
Этот трюк обычно делается с помощью Sparse Autoencoders — сетей, которые в латенте дают разреженный вектор, обещающий понятные человеку концепты. Отдельные единицы такого вектора активируются только на схожих признаках, например: один компонент может реагировать на упоминания городов, другой — на математические формулы.
Позже появились Transcoders — продвинутая версия SAE, которая учится разлагать не активации, а вычисления внутри MLP слоя. Так как трансофрмер аддитивен, трансокдеры на разных слоях позволяют строить цепочки — эволюцию прохождений фичей от слоя к слою.
А потом к ним пришли Crosscoders — модели, с архитектурой транскодера, но адаптированные к учету информации из нескольких слоёв.
Каждый "кодер" состоит из трех частей:
1) Энкодер — делает разреженное представление.
2) Латент — само разреженное представление.
3) Декодер — восстанавливает input из разреженного представления.
К исследованию.
В классике кодеры применялись, чтобы изучить признаки в уже обученных моделей. А тут статья предлагает изучить процесс обучения, используя разреженность.
Для этого используют используют crosscoders и теоретическую предпосылку — если признак не существует, штраф за разреженность подавит веса декодеров в "неактивных" моментах до нуля (признака нет — восстанавливать мы его тоже не будем).
Из этой теории рассматривают норму весов декодера||W_dec|| для фичи i (из теории построения также мы знаем, что столбец декодера всегда кодирует какую-то фичу).
Для нормы авторы ввели Peak Snapshot Index — число k [1, 32], показывающее, на каком моменте времени в обучении фича достигла максимальной силы. В частности 143 000 шага обучения побили на 32 снэпшота и на них смотрели активации признака (при этом норму декодера снимали на каждом шаге).
В такой постановке нашли следующее:
1. Двухфазная структура:
Статистическая фаза (ранние шаги): модель изучает частоты токенов, потери падают до теоретического минимума
Фаза фич (поздние шаги): формируются сложные концепты в суперпозиции
2.Иерархия:
Простые фичи (предыдущий токен) ~1000-5000 шагов
Индукционные фичи ~10000-100000 шагов
Контекстно-зависимые — на финальных стадиях
3. Точку поворота: Около шага 1000 большинство фич кардинально меняют направление в пространстве активаций
Красивые картинки нашли тоже.
Forwarded from Data Blog
Эволюция фичей. Можно идти из предположения, что темные — статистические и светлые — более сложные. Структура "скрещивания" отражает, как меняется сила наличия фичи step by step.
Forwarded from Quant Valerian
Как я принимаю решения
Пару недель назад рефлексировали на «мастермайнде», как мы принимаем решения. Оказалось, что у миддл-менеджеров всё в принципе похоже.
Сначала нужно понять, что за решение: какое влияние оно окажет, масштаб проблемы. Дальше нужно понять, типовая ли проблема, решалась ли она уже раньше и как. Затем смотрим, какие есть варианты, как они согласуются со стратегией и целями.
Если проблема мелкая или влияние от решения минимальное, просто подбрасываем монетку. Реально, когда у меня спрашивают, куда лучше добавить график: в левую или в правую колонку, мне по барабану. Приятным побочным эффектом иногда выходит опыт сотрудника, который спрашивал. Если ткнуть в более сложный или невозможный вариант, то он, блин, пойдет и сам наконец разберется, какой же вариант нужен. Человек ленив и придумает тебе обоснование, почему надо делать по-другому. В следующий раз с этого начнет и не придет вообще🧠
Если проблема типовая, то нужно либо вспомнить, какое там типовое решение, либо отправить к тому, кто вспомнит. Бонус трек — вопрошающий заносит это в какую-то базу знаний, такой вопрос больше не возникает.
Если у проблемы есть альтернативные варианты решения, какие-то из альтернатив срезаются стратегией или целями, поздравляю — вы уменьшили пространство решений!👨🦳
Если же проблема сложная и с большим влиянием, то и решение будет приниматься сложно и с большими затратами. Здесь обычно рассказывают что-то про аналитику, числа, эксперименты и т.д. — такое и без меня найдёте в интернете. От меня лишь несколько нюансов:
1. На старте ограничьте время на принятие решения и исследования
2. Если есть альтернативы, попробуйте их скрестить, даже если на первый взгляд, они не женятся
3. К брейншторму (НО НЕ К РЕШЕНИЮ!) привлеките других людей, создайте им комфортную среду для лучшего понимания контекста и проблемы. Пусть они принесут ещё и своего контекста. Здесь может лежать много крутых решений
4. Если вы найдёте банальное, очевидное и простое решение, скорее всего именно оно будет лучшим
И помните, что ответственность за принятое решение лежит на вас. А лучший способ поменьше сожалеть о решении: либо очень тщательно его продумать, либо не думать над ним вообще.
Пару недель назад рефлексировали на «мастермайнде», как мы принимаем решения. Оказалось, что у миддл-менеджеров всё в принципе похоже.
Сначала нужно понять, что за решение: какое влияние оно окажет, масштаб проблемы. Дальше нужно понять, типовая ли проблема, решалась ли она уже раньше и как. Затем смотрим, какие есть варианты, как они согласуются со стратегией и целями.
Если проблема мелкая или влияние от решения минимальное, просто подбрасываем монетку. Реально, когда у меня спрашивают, куда лучше добавить график: в левую или в правую колонку, мне по барабану. Приятным побочным эффектом иногда выходит опыт сотрудника, который спрашивал. Если ткнуть в более сложный или невозможный вариант, то он, блин, пойдет и сам наконец разберется, какой же вариант нужен. Человек ленив и придумает тебе обоснование, почему надо делать по-другому. В следующий раз с этого начнет и не придет вообще
Если проблема типовая, то нужно либо вспомнить, какое там типовое решение, либо отправить к тому, кто вспомнит. Бонус трек — вопрошающий заносит это в какую-то базу знаний, такой вопрос больше не возникает.
Если у проблемы есть альтернативные варианты решения, какие-то из альтернатив срезаются стратегией или целями, поздравляю — вы уменьшили пространство решений!
Если же проблема сложная и с большим влиянием, то и решение будет приниматься сложно и с большими затратами. Здесь обычно рассказывают что-то про аналитику, числа, эксперименты и т.д. — такое и без меня найдёте в интернете. От меня лишь несколько нюансов:
1. На старте ограничьте время на принятие решения и исследования
2. Если есть альтернативы, попробуйте их скрестить, даже если на первый взгляд, они не женятся
3. К брейншторму (НО НЕ К РЕШЕНИЮ!) привлеките других людей, создайте им комфортную среду для лучшего понимания контекста и проблемы. Пусть они принесут ещё и своего контекста. Здесь может лежать много крутых решений
4. Если вы найдёте банальное, очевидное и простое решение, скорее всего именно оно будет лучшим
И помните, что ответственность за принятое решение лежит на вас. А лучший способ поменьше сожалеть о решении: либо очень тщательно его продумать, либо не думать над ним вообще.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from AbstractDL
VAR эквивалентен дискретной диффузии
Прикол, оказывается VAR генератор картинок это дискретная диффузия. Только после этой статьи дошло, как оно на самом деле работает. По сути текстовая диффузия, но для масштабов картинки.
Если вы не в курсе что такое VAR — это такой подход к генерации изображений от ByteDance, который вместо того чтобы предсказывать токены последовательно (как GPT), предсказывает сразу все токены следующего разрешения. То есть сначала генерирует картинку 1×1, потом 2×2, потом 4×4 и так далее до полного размера. Каждый шаг — это увеличение разрешения в 2 раза.
Авторы из Johns Hopkins в статье "Scale-Wise VAR is Secretly Discrete Diffusion" показали, что если сделать VAR марковским (то есть каждое разрешение зависит только от предыдущего, а не от всех предыдущих сразу), то математически это становится обычной дискретной диффузией!
И вот тут начинается магия: раз это диффузия, значит можно применять все трюки из диффузионных моделей! Авторы проверили classifier-free guidance, token resampling и distillation — всё работает и даёт прирост. FID падает на 20% на MiniImageNet (21.01→16.76), а zero-shot задачи типа inpainting и super-resolution тоже улучшаются без дополнительного обучения.
Самое прикольное, что такая интерпретация объясняет, ПОЧЕМУ VAR хорошо работает и масштабируется. До этого использование cfg в VAR было эмпирическим, а теперь есть теоретическое обоснование. Плюс можно выкидывать промежуточные scales (distillation), ускоряя инференс на x2 без сильной потери качества.
Самое смешное, что авторы VAR в оригинальной статье уже подавали в модель номер текущего разрешения (как timestep в диффузии), использовали cross-entropy loss (как в дискретной текстовой диффузии), и даже SNR у них растёт от низкого разрешения к высокому. Они буквально сделали диффузию, но не поняли этого 🤷♂️
Статья, GitHub (скоро будет)
Прикол, оказывается VAR генератор картинок это дискретная диффузия. Только после этой статьи дошло, как оно на самом деле работает. По сути текстовая диффузия, но для масштабов картинки.
Если вы не в курсе что такое VAR — это такой подход к генерации изображений от ByteDance, который вместо того чтобы предсказывать токены последовательно (как GPT), предсказывает сразу все токены следующего разрешения. То есть сначала генерирует картинку 1×1, потом 2×2, потом 4×4 и так далее до полного размера. Каждый шаг — это увеличение разрешения в 2 раза.
Авторы из Johns Hopkins в статье "Scale-Wise VAR is Secretly Discrete Diffusion" показали, что если сделать VAR марковским (то есть каждое разрешение зависит только от предыдущего, а не от всех предыдущих сразу), то математически это становится обычной дискретной диффузией!
И вот тут начинается магия: раз это диффузия, значит можно применять все трюки из диффузионных моделей! Авторы проверили classifier-free guidance, token resampling и distillation — всё работает и даёт прирост. FID падает на 20% на MiniImageNet (21.01→16.76), а zero-shot задачи типа inpainting и super-resolution тоже улучшаются без дополнительного обучения.
Самое прикольное, что такая интерпретация объясняет, ПОЧЕМУ VAR хорошо работает и масштабируется. До этого использование cfg в VAR было эмпирическим, а теперь есть теоретическое обоснование. Плюс можно выкидывать промежуточные scales (distillation), ускоряя инференс на x2 без сильной потери качества.
Самое смешное, что авторы VAR в оригинальной статье уже подавали в модель номер текущего разрешения (как timestep в диффузии), использовали cross-entropy loss (как в дискретной текстовой диффузии), и даже SNR у них растёт от низкого разрешения к высокому. Они буквально сделали диффузию, но не поняли этого 🤷♂️
Статья, GitHub (скоро будет)
Forwarded from Эмбеддинг бенчмарка
RTEB (Retrieval Embedding Benchmark)
Voyage AI by MongoDB добавила в MTEB новый бенчмарк -- для оценки эмбеддингов на retrieval-задачах.
RTEB использует гибридный подход, объединяющий открытые и закрытые датасеты, чтобы измерять обобщающую способность и не допускать «train on test».
Разработан для реальных приложений: включает датасеты на 20 языках (в основном английский и без русского) и в ключевых доменах — право, здравоохранение, финансы, программный код.
В качестве метрики по умолчанию применяется NDCG@10.
Уже выявляет разрывы в качестве: у некоторых моделей наблюдается заметное падение на закрытых датасетах, что указывает на переобучение к публичным бенчмаркам.
Доступен на лидерборде MTEB в Hugging Face.
Подрбонее в посте на HF blog
Voyage AI by MongoDB добавила в MTEB новый бенчмарк -- для оценки эмбеддингов на retrieval-задачах.
RTEB использует гибридный подход, объединяющий открытые и закрытые датасеты, чтобы измерять обобщающую способность и не допускать «train on test».
Разработан для реальных приложений: включает датасеты на 20 языках (в основном английский и без русского) и в ключевых доменах — право, здравоохранение, финансы, программный код.
В качестве метрики по умолчанию применяется NDCG@10.
Уже выявляет разрывы в качестве: у некоторых моделей наблюдается заметное падение на закрытых датасетах, что указывает на переобучение к публичным бенчмаркам.
Доступен на лидерборде MTEB в Hugging Face.
Подрбонее в посте на HF blog
Forwarded from Женя Янченко
Это произошло, когда я только недавно пришла в новую компанию лидом.
Мы начали новый проект, и одному из сервисов требовалось:
1️⃣ принимать поток данных
2️⃣ сохранять их в БД
3️⃣ некоторые из них отправлять дальше в Кафку
Идёт обсуждение сервиса. Терять данные нельзя. Как быть?
🤔 Допустим, мы будем сохранять данные в БД, комитить транзакцию, а потом отправлять в Кафку. Но если приложение вдруг упадет, не успев отправить данные, то окажется, что данные в БД есть, а дальше мы их не отправили. Так нельзя.
🤔 Ок, тогда давайте не будем закрывать транзакцию после сохранения в БД, а оставим её открытой пока не отправим в Кафку. Если с отправкой все хорошо — закоммитим транзакцию. А если брокер будет недоступен и нужны повторные попытки? Будем удерживать транзакцию? Плохо.
🤔 А если уже после отправки в момент коммита транзакции произойдет ошибка в БД, и транзакция откатится? Получается мы данные отправим, а себе не сохраним. Так тоже нельзя.
Пазл не складывается. Я понимаю, что наверняка не мы первые столкнулись с такой задачей и у меня в памяти всплывает, что есть паттерн как раз для этого. Вспоминаю суть, но не могу вспомнить название!
Свежеиспечённому лиду не пристало ударять лицом в грязь и нужно срочно выдать решение 🙈 Начинаю нервничать и от этого никак не могу поймать ускользающее название. Что-то с транзакциями и таблица там специальная.
Ситуацию осложняет то, что в тот момент я была знакома с этим паттерном в теории, но ещё не использовала его на практике.
Как же его... как он называется? Погуглить паттерн для отправки в Кафку с отдельной таблицей?
Фууух, ура!
Кратко, в чем идея паттерна Transactional Outbox?
У нас есть бизнес-таблица (например,
➡️ В одной транзакции мы пишем данные и в таблицу
➡️ Отдельный процесс (например, джоба по расписанию или change data capture) читает
➡️ После успешной отправки сообщение помечается как обработанное (может потом удаляться).
Таким образом, если при сохранении данных что-то пойдет не так, и транзакция откатится, то эти данные никак в брокер не попадут.
Если же мы всё сохраним, а потом приложение упадет, не успев отправить данные — ничего страшного 😊 Всё, что нужно отправить, будет дожидаться в таблице
Таблица
Паттерн применим не только при создании записей, но и при изменении/удалении, если об этом нужно отправлять событие.
Реализация паттерна даёт at-least-once доставку, то есть сообщение не потеряется, но возможны дубликаты.
С тех пор мы успешно используем Transactional Outbox на проектах.
🤔 А зачем отдельная таблица? Можно же сделать поле со статусом в таблице
Да, так можно сделать, это проще. Но у такого подхода есть минусы:
➖ мы смешаем бизнес-логику (данные
➖
_______
Сталкивались ли вы с Transactional Outbox на практике? Делали по классике или через статусы отправки в основной таблице?
Мы начали новый проект, и одному из сервисов требовалось:
Идёт обсуждение сервиса. Терять данные нельзя. Как быть?
🤔 Допустим, мы будем сохранять данные в БД, комитить транзакцию, а потом отправлять в Кафку. Но если приложение вдруг упадет, не успев отправить данные, то окажется, что данные в БД есть, а дальше мы их не отправили. Так нельзя.
🤔 Ок, тогда давайте не будем закрывать транзакцию после сохранения в БД, а оставим её открытой пока не отправим в Кафку. Если с отправкой все хорошо — закоммитим транзакцию. А если брокер будет недоступен и нужны повторные попытки? Будем удерживать транзакцию? Плохо.
🤔 А если уже после отправки в момент коммита транзакции произойдет ошибка в БД, и транзакция откатится? Получается мы данные отправим, а себе не сохраним. Так тоже нельзя.
Пазл не складывается. Я понимаю, что наверняка не мы первые столкнулись с такой задачей и у меня в памяти всплывает, что есть паттерн как раз для этого. Вспоминаю суть, но не могу вспомнить название!
Свежеиспечённому лиду не пристало ударять лицом в грязь и нужно срочно выдать решение 🙈 Начинаю нервничать и от этого никак не могу поймать ускользающее название. Что-то с транзакциями и таблица там специальная.
Ситуацию осложняет то, что в тот момент я была знакома с этим паттерном в теории, но ещё не использовала его на практике.
Как же его... как он называется? Погуглить паттерн для отправки в Кафку с отдельной таблицей?
— Transactional Outbox! — выпаливаю я.
— Точно! — подхватывает коллега. — Мы как раз его на прошлом проекте использовали, подойдет для нашей ситуации.
Фууух, ура!
Потом я конечно поняла, что лид совсем не обязан всё знать и не нужно так переживать, но это уже совсем другая история😉
Кратко, в чем идея паттерна Transactional Outbox?
У нас есть бизнес-таблица (например,
orders) и отдельная таблица outbox.orders, и в outbox. Записав, комитим транзакцию.outbox и отправляет сообщение в брокер.Таким образом, если при сохранении данных что-то пойдет не так, и транзакция откатится, то эти данные никак в брокер не попадут.
Если же мы всё сохраним, а потом приложение упадет, не успев отправить данные — ничего страшного 😊 Всё, что нужно отправить, будет дожидаться в таблице
outbox. Отправим после восстановления.Таблица
outbox может содержать как уже готовое к отправке сообщение "payload", так и набор полей, а также поле со статусом.Паттерн применим не только при создании записей, но и при изменении/удалении, если об этом нужно отправлять событие.
Реализация паттерна даёт at-least-once доставку, то есть сообщение не потеряется, но возможны дубликаты.
С тех пор мы успешно используем Transactional Outbox на проектах.
🤔 А зачем отдельная таблица? Можно же сделать поле со статусом в таблице
orders: NEW, PROCESSED. И пусть фоновый процесс берет данные из самой orders и меняет статус после отправки.Да, так можно сделать, это проще. Но у такого подхода есть минусы:
orders) с логикой интеграции: статус отправки, timestamp отправки, другая служебная информация, которая не нужна в orders. Отдельная таблица outbox дает больше гибкости.outbox-таблицу можно чистить (сразу или спустя время), а добавленные в orders статус (дата и др.) отправки останутся там✏️ Паттерн Transactional Outbox решает так называемую dual-write problem — как записать данные в базу и одновременно отправить событие наружу так, чтобы они не разъехались. С ним мы можем гарантировать, что сообщение будет отправлено после успешного выполнения транзакции в базе данных и не потеряется. Cхема в комментах.
_______
Сталкивались ли вы с Transactional Outbox на практике? Делали по классике или через статусы отправки в основной таблице?
Please open Telegram to view this post
VIEW IN TELEGRAM