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
Forwarded from Всеволод Викулин | AI разбор
12 правил разработки проектов с LLM
Давно не писал в канал. Не потому что забросил, а потому что писал свод правил по внедрению LLM. Попутно создал сайт, где я буду публиковать дальше статьи. Пока обошелся без AI, собрал на Тильде. Но AI консультировал по Тильде :)
В статье суммаризовал все правила внедрения LLM: про прототипирование, оценку качества, RAG, дообучение, оптимизации, агентов и про все все все, что вам может понадобиться. Читайте, делитесь с друзьями, делитесь мнением о прочитанном.
Ваши вопросы, мнения, предложения я очень жду в комментариях и в личных сообщениях.
Давно не писал в канал. Не потому что забросил, а потому что писал свод правил по внедрению LLM. Попутно создал сайт, где я буду публиковать дальше статьи. Пока обошелся без AI, собрал на Тильде. Но AI консультировал по Тильде :)
В статье суммаризовал все правила внедрения LLM: про прототипирование, оценку качества, RAG, дообучение, оптимизации, агентов и про все все все, что вам может понадобиться. Читайте, делитесь с друзьями, делитесь мнением о прочитанном.
Ваши вопросы, мнения, предложения я очень жду в комментариях и в личных сообщениях.
vikulin.ai
12 правил разработки проектов с LLM
Разложил свой опыт LLM-разработки в 12 правилах. Они сэкономят вам тонну нервов, времени и денег при разработке LLM-проекта.
Forwarded from Refat Talks: Tech & AI
This media is not supported in your browser
VIEW IN TELEGRAM
🔥 Image Understanding (
Короче, как я перепробовал почти все и пришел к простому. Недавно работал над задачей: нужно было извлекать данные из документов (инвойсы, ID карты, чеки), причем не просто текст вытащить, а конкретные поля и обязательно показать пользователю откуда именно взяли каждое поле. То есть полноценный grounded extraction с визуальной верификацией.
Перепробовал кучу всего, включая OCR-движки и YOLO модели - все не то: или работает с узким набором доков, или вытаскивает все подряд, или надо дообучать.
И тут я вспомнил про фичу Gemini, которую использовал в других кейсах - Image Understanding с 2D Bounding Boxes. Удивился насколько это работает лучше всех предыдущих решений. Быстрее, точнее и вполне недорого (особенно с Flash).
Смотрите, большинство vision-моделей могут описать что на картинке. GPT, Claude, другие vision модели - все они видят текст, объекты и понимают контекст. Но Gemini делает больше: он может показать где именно на изображении находится то, что он видит. С точностью до пикселя.
В промпте надо упомянуть необходимость извлечения box_2d контуров и получаете не просто текст, а JSON с координатами каждого поля:
Координаты нормализованы от 0 до 1000, формат [ymin, xmin, ymax, xmax]. Дальше простая геометрия - и ты можешь наложить эти боксы на оригинал. Получается интерактивная подсветка: навел на поле в списке - подсветилось на изображении. Смотрите на видео демку из моего проекта.
Зачем это нужно: операторы могут проверять правильность извлечения прямо на документе, RAG-пайплайны хранят координаты для точных ссылок на источник, QA сразу видит где модель ошиблась, клиенты получают прозрачность - что извлекли и откуда.
Этот пост, кстати, хорошее дополнение к моему обзору LangExtract.
Технические нюансы
- Важно просить Gemini выдать именно box_2d (она натренирована таким образом): "The box_2d should be [ymin, xmin, ymax, xmax] normalized to 0-1000"
- Structured Outputs + JSON schema с box_2d отлично сочетаются и гарантируют валидный формат
- Flash/Flash Lite модели чаще всего достаточно (всего $0.10/$0.40 за миллион токенов), Pro для сложных отчетов
- Выключайте thinking для spatial задач (thinking_budget=0)
- Ресайзите до 640px по большей стороне (часто - лучший вариант, но зависит от кейса)
- Gemini 2.5+ поддерживает Segmentation Masks - то есть выдает также base64 png с точной формой объекта, полезно для computer vision задач и conversational segmentation типа "подсвети строки где сумма больше $1000"
Use cases за пределами документов: UI/UX тестирование и визуальные регрессии, e-commerce (детекция продуктов, ценников, инвентаря), quality control (дефекты, лейблы, компоненты), робототехника (навигация, захват объектов, инспекция).
Если вы делаете что-то с обработкой документов или изображений где важна локализация - попробуйте Gemini Image Understanding. Это недооцененная фича которая может сэкономить месяцы разработки и деньги на инфраструктуру.
🔥➕🔁
box_2d) в Gemini - недооцененная суперсила для OCR и не толькоКороче, как я перепробовал почти все и пришел к простому. Недавно работал над задачей: нужно было извлекать данные из документов (инвойсы, ID карты, чеки), причем не просто текст вытащить, а конкретные поля и обязательно показать пользователю откуда именно взяли каждое поле. То есть полноценный grounded extraction с визуальной верификацией.
Перепробовал кучу всего, включая OCR-движки и YOLO модели - все не то: или работает с узким набором доков, или вытаскивает все подряд, или надо дообучать.
И тут я вспомнил про фичу Gemini, которую использовал в других кейсах - Image Understanding с 2D Bounding Boxes. Удивился насколько это работает лучше всех предыдущих решений. Быстрее, точнее и вполне недорого (особенно с Flash).
Смотрите, большинство vision-моделей могут описать что на картинке. GPT, Claude, другие vision модели - все они видят текст, объекты и понимают контекст. Но Gemini делает больше: он может показать где именно на изображении находится то, что он видит. С точностью до пикселя.
В промпте надо упомянуть необходимость извлечения box_2d контуров и получаете не просто текст, а JSON с координатами каждого поля:
{
"box_2d": [245, 156, 289, 487],
"label": "DOCUMENT_NUMBER",
"value": "AB123456"
}
Координаты нормализованы от 0 до 1000, формат [ymin, xmin, ymax, xmax]. Дальше простая геометрия - и ты можешь наложить эти боксы на оригинал. Получается интерактивная подсветка: навел на поле в списке - подсветилось на изображении. Смотрите на видео демку из моего проекта.
Зачем это нужно: операторы могут проверять правильность извлечения прямо на документе, RAG-пайплайны хранят координаты для точных ссылок на источник, QA сразу видит где модель ошиблась, клиенты получают прозрачность - что извлекли и откуда.
Этот пост, кстати, хорошее дополнение к моему обзору LangExtract.
Технические нюансы
- Важно просить Gemini выдать именно box_2d (она натренирована таким образом): "The box_2d should be [ymin, xmin, ymax, xmax] normalized to 0-1000"
- Structured Outputs + JSON schema с box_2d отлично сочетаются и гарантируют валидный формат
- Flash/Flash Lite модели чаще всего достаточно (всего $0.10/$0.40 за миллион токенов), Pro для сложных отчетов
- Выключайте thinking для spatial задач (thinking_budget=0)
- Ресайзите до 640px по большей стороне (часто - лучший вариант, но зависит от кейса)
- Gemini 2.5+ поддерживает Segmentation Masks - то есть выдает также base64 png с точной формой объекта, полезно для computer vision задач и conversational segmentation типа "подсвети строки где сумма больше $1000"
Use cases за пределами документов: UI/UX тестирование и визуальные регрессии, e-commerce (детекция продуктов, ценников, инвентаря), quality control (дефекты, лейблы, компоненты), робототехника (навигация, захват объектов, инспекция).
Если вы делаете что-то с обработкой документов или изображений где важна локализация - попробуйте Gemini Image Understanding. Это недооцененная фича которая может сэкономить месяцы разработки и деньги на инфраструктуру.
🔥➕🔁
Forwarded from Love. Death. Transformers.
если кто то убеждает вас что рл хорошо работает и с ним нет проблем, то скорее всего он не занимается рлем
джейсон стетхэм
Большой китайский пост про проблемы при обучении с RLем, особенности генерации траекторий на VLLM и том как сильно траектории могут отличатся от переключения разных настроек инференса.
+ предлагают разные варианты досэмпла токенов чтобы стабилизировать численные проблемы
https://yingru.notion.site/When-Speed-Kills-Stability-Demystifying-RL-Collapse-from-the-Training-Inference-Mismatch-271211a558b7808d8b12d403fd15edda
Forwarded from Love. Death. Transformers.
Алекс Гордич продолжает разбирать основы современного ллм инференса - в этот раз про matmul на картах nvidia и его особенности
aleksagordic.com/blog/matmul
aleksagordic.com/blog/matmul
Forwarded from fiiiiiiirst fiiiiiiirst
С помощью этого упрощённо промнта, учёные и инженеры смогут реализовать данный мир в течение 20-30 лет ;) "
", пользуйтесь/ распространяйте
Ты — «Кристаллизатор». Твоя задача — глубоко анализировать вопросы, раскладывая их на слои:
1. **Зоны консенсуса** (что все признают)
2. **Зоны противоречий** (где логика трещит)
3. **Скрытые структуры** (какие допущения мы не замечаем)
4. **Инсайты** (к чему это приводит)
Начни с вопроса: «Опиши проблемное поле — что ты хочешь разобрать?»
После ввода данных уточни: «Какое понимание тебе важно — найти слабые места, выявить скрытые допущения или синтезировать новый подход?»
Затем проведи анализ и дай структурированный ответ.
", пользуйтесь/ распространяйте
Forwarded from Душный NLP
Как обучить одну модель и получить несколько
Сегодня расскажем о методе, который позволяет обучить одну модель, а затем извлечь из неё несколько других «подмоделей». Подобным подходам посвящено несколько статей. Разберём одну из них, о методе MatFormer от инженеров из Google.
Идея статьи заключается в том, чтобы вкладывать разные варианты слоёв друг в друга. Как в матрёшке: параметры трансформера поменьше используются в трансформере побольше. Метод фокусируется на FFN-слоях и только в dense-архитектурах, где до 60% параметров как раз и находятся в FFN-слоях.
Суть в том, чтобы брать не все нейроны скрытого слоя в полносвязных слоях, а а только некоторый набор первых (m_i в формуле выше). При этом у разных слоёв могут быть разные m_i.
Обучение осуществляется как обычно, но со случайным и равномерным сэмплингом m_i = g_i d_ff, где g_i — гранулярность, случайно сэмплируемая из {0.5, 1, 2, 4}, а d_ff — это размер скрытого представления модели. Таким образом обучаются все подмодели. На инференсе используется процедура Mix’n’Match — для разных слоёв подбираются свои m_i так, чтобы размер слоёв увеличивался постепенно, без резких скачков.
Результаты показывают, что модель, полученная с помощью метода MatFormer, показывает лучшие результаты, чем модель, обученная с нуля. Интересно ещё и то, что «модели из матрёшки» демонстрируют значительную согласованность с большой моделью, из которой произошли. Это полезно, потому что открывает возможность для использования маленьких моделей, например, в качестве draft-моделей при спекулятивном декодинге.
Разбор подготовил❣ Артём Соболев
Душный NLP
Сегодня расскажем о методе, который позволяет обучить одну модель, а затем извлечь из неё несколько других «подмоделей». Подобным подходам посвящено несколько статей. Разберём одну из них, о методе MatFormer от инженеров из Google.
Идея статьи заключается в том, чтобы вкладывать разные варианты слоёв друг в друга. Как в матрёшке: параметры трансформера поменьше используются в трансформере побольше. Метод фокусируется на FFN-слоях и только в dense-архитектурах, где до 60% параметров как раз и находятся в FFN-слоях.
Суть в том, чтобы брать не все нейроны скрытого слоя в полносвязных слоях, а а только некоторый набор первых (m_i в формуле выше). При этом у разных слоёв могут быть разные m_i.
Обучение осуществляется как обычно, но со случайным и равномерным сэмплингом m_i = g_i d_ff, где g_i — гранулярность, случайно сэмплируемая из {0.5, 1, 2, 4}, а d_ff — это размер скрытого представления модели. Таким образом обучаются все подмодели. На инференсе используется процедура Mix’n’Match — для разных слоёв подбираются свои m_i так, чтобы размер слоёв увеличивался постепенно, без резких скачков.
Результаты показывают, что модель, полученная с помощью метода MatFormer, показывает лучшие результаты, чем модель, обученная с нуля. Интересно ещё и то, что «модели из матрёшки» демонстрируют значительную согласованность с большой моделью, из которой произошли. Это полезно, потому что открывает возможность для использования маленьких моделей, например, в качестве draft-моделей при спекулятивном декодинге.
Разбор подготовил
Душный NLP
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Инжиниринг Данных (Dmitry)
Увидел интересное репо, в котором автор собрал локальный опенсорсный стек:
Data Forge includes a complete modern data stack with industry-standard tools:
🗄️ Storage & Catalog
- MinIO → S3-compatible object storage for data lakes
- Hive Metastore → Centralized metadata catalog for tables and schemas
⚡ Compute Engines
- Trino → Interactive SQL query engine for federated analytics
- Apache Spark → Distributed processing for batch and streaming workloads
🌊 Streaming & CDC
- Apache Kafka → Event streaming platform
- Schema Registry → Schema evolution and compatibility
- Debezium → Change data capture from databases
🗃️ Databases
- PostgreSQL → Primary OLTP database (source system)
- ClickHouse → Columnar analytics database (sink)
🔄 Orchestration
- Apache Airflow 3 → Workflow orchestration
📊 Visualization & Exploration
- Apache Superset → Modern BI and data visualization
- JupyterLab → Interactive data science environment
Идеальный стек для отечественного (СНГ) дата инженера.
PS автору если интересно, может и вебинарчик провести для нас.
Data Forge includes a complete modern data stack with industry-standard tools:
🗄️ Storage & Catalog
- MinIO → S3-compatible object storage for data lakes
- Hive Metastore → Centralized metadata catalog for tables and schemas
⚡ Compute Engines
- Trino → Interactive SQL query engine for federated analytics
- Apache Spark → Distributed processing for batch and streaming workloads
🌊 Streaming & CDC
- Apache Kafka → Event streaming platform
- Schema Registry → Schema evolution and compatibility
- Debezium → Change data capture from databases
🗃️ Databases
- PostgreSQL → Primary OLTP database (source system)
- ClickHouse → Columnar analytics database (sink)
🔄 Orchestration
- Apache Airflow 3 → Workflow orchestration
📊 Visualization & Exploration
- Apache Superset → Modern BI and data visualization
- JupyterLab → Interactive data science environment
Идеальный стек для отечественного (СНГ) дата инженера.
PS автору если интересно, может и вебинарчик провести для нас.