home.social

#kafka — Public Fediverse posts

Live and recent posts from across the Fediverse tagged #kafka, aggregated by home.social.

  1. "A Dramatic Irony." (by Team.ACHV)

    "A Dramatic Irony." (by Team.ACHV) #kafka #animeart #NotMyArtSeePostBodyForCredits

    kbin.earth/m/[email protected]

  2. 📢 Data Prepper 2.16 is out!
    It's got some highlights around , , pull-based ingestion and more:
    ▶️ scrape Prometheus metrics with pull-based ingestion
    ▶️ direct time-series (metrics) data ingestion for the TSDB engine
    ▶️ support for pull-based ingestion (using Apache topic or similar)
    ▶️ support for logs & traces in the OTLP sink

    release blog:
    lnkd.in/d4StMYDP
    @OpenSearchProject

  3. 📢 #OpenSearch Data Prepper 2.16 is out!
    It's got some highlights around #OpenTelemetry, #Prometheus, pull-based ingestion and more:
    ▶️ scrape Prometheus metrics with pull-based ingestion
    ▶️ direct time-series (metrics) data ingestion for the TSDB engine
    ▶️ support for pull-based ingestion (using Apache #Kafka topic or similar)
    ▶️ #OpenTelemetry support for logs & traces in the OTLP sink

    release blog:
    lnkd.in/d4StMYDP
    @OpenSearchProject #ingestion #Observability #OpenSearchAmbassador

  4. redb 3.3.0: решение уровня энтерпрайз на .NET — своя БД, свой Apache Camel и рантайм с дашбордом (и всё это бесплатно)

    Когда говорят «энтерпрайз-стек на .NET», обычно имеют в виду зоопарк: база от одного вендора, шина от другого, ORM с миграциями, отдельный оркестратор, ещё что-нибудь для наблюдаемости — и клей между всем этим, который пишешь сам и потом сам же чинишь по ночам. Мы пошли другим путём и последние полгода собираем это как одну согласованную экосистему : типизированное хранилище redb поверх Postgres/MSSQL/SQLite, интеграционный движок redb.Route (наш ответ Apache Camel под .NET) и рантайм redb.Tsak с дашбордом, hot-reload и кластером. Три слоя, один код, один стиль. Сегодня вышла версия 3.3.0 — синхронный бамп всей экосистемы. Это не «добавили пару фич»: это релиз, в котором мы починили то, что молча не работало под нагрузкой (и это, пожалуй, главное), добавили два новых транспорта, довели до конца RAG-петлю для LLM и сделали конкурентность на любом источнике. Ниже — по делу, с кодом. И сразу главное: с версии 3.3.0 все Pro-решения бесплатны. Никаких лицензий, никаких ключей, никакой регистрации — просто ставишь пакет и юзаешь. Change tracking, bulk, продвинутый кэш, аналитика, кластер Tsak с координатором и failover — всё включено из коробки, в разработке и в проде одинаково. dotnet add package redb.Postgres.Pro — и оно работает. Никакого пейволла, никакого лицензионного сервера, ничего активировать не надо.

    habr.com/ru/articles/1057616/

    #c# #sqlite #dotnet #kafka #rabbitmq #redb #sqs #telegram

  5. От 0 до 10 миллионов ИИ-проверок в месяц: как мы продуктивизировали CV в Пятёрочке за 8 месяцев

    Статья про то, как CV-сервис вырос с MVP до 10 миллионов проверок фото в месяц и не развалился в проде. 🔧 Это не про «у нас классные модели» и не про «просто прикрутили YOLO», а про честную инженерную продуктивизацию. Про то как универсальный классификатор путал фарш с грязью, почему часть анкет всё равно лучше отдавать человеку, зачем отдельно мониторить качество моделей и что приходится чинить, когда реальный мир меняется быстрее обучающей выборки. Внутри: компьютерное зрение, 26 моделей, 62 проверки, CNN, VLM, Triton, vLLM, Kafka, Human-in-the-loop, мониторинг качества, сезонность, баги под нагрузкой и немного «веган-версии ИИ». Заходите, читайте и делитесь своим опытом продакшена ML-сервисов ❤️

    habr.com/ru/companies/X5Tech/a

    #computer_vision #multimodal #yolo #resnet #vlm #cnn #tritoninferenceserver #humanintheloop #kafka #ритейл

  6. redb.Route — уходим от MassTransit, идём к Apache Camel: Kafka, Scatter‑Gather и транзакции

    Серия: redb ecosystem / redb.Route deep-dive Очередная статья из цикла про redb.Route — наш Apache Camel под .NET. Если вы только подключились, вот предыдущие на Хабре: redb.Route — Apache Camel для .NET, который мы написали потому что выхода другого не было — с чего всё началось; redb.Route изнутри: четыре in‑memory канала и Exchange, который их связывает ; redb.Route 3.0.1 — плоская навигация по DSL, рефакторинг CRTP и тихий null ; Apache Camel под .NET, разбор по косточкам: HTTP‑коннектор без ASP.NET MVC + паттерн Content‑Based Router — предыдущая «EIP + коннектор». Сегодня заходим с Kafka‑коннектора — разбираем его по косточкам, как делали с HTTP, — а потом сажаем на него два EIP‑паттерна: Scatter‑Gather и Aggregator . И главное — разбираем то, о чём в туториалах молчат: как это живёт под транзакциями . Заодно вышел 3.2.0 .

    habr.com/ru/articles/1054148/

    #kafka #c# #c#net #eip #esb #integration

  7. Шесть недель с agentic AI против фрода в adversarial-системе

    Я слишком рано понёс первые результаты в наш продукт. Тогда это выглядело логично: мы прикрутили агентный ИИ к анализу логов и поведения пользователей в regulated продукте с реальными денежными операциями, качество обнаружения пошло вверх, аналитики по фроду стали меньше возвращать инженерам мусорные кейсы. Снаружи это уже выглядело рабочим слоем защиты: аналитики видели меньше мусора, инженеры получали более понятные issues, и продукт наконец увидел практическую пользу вместо очередного демо. Я примерно так и сказал: “смотрите, это уже не игрушка”. Плохая фраза, как оказалось. Потому что как только защита начинает работать, даже чуть-чуть, вокруг сразу появляются нормальные взрослые вопросы. А давайте это в платежи? А в бонусный абьюз? А в L7? А в социнженерию? А в странные кейсы саппорта, где один тикет внезапно объясняет половину графика? Вопросы честные. Только дорогие. И в системах с живым противником есть ещё одна неприятная деталь: рабочая защита становится сигналом для другой стороны. Пишу по собственному инженерному опыту. Детали слегка обобщены и обезличены, потому что в антифроде лишняя конкретика быстро превращается в инструкцию для другой стороны.

    habr.com/ru/articles/1053668/

    #fraud_detection #llm #agentic_ai #observability #clickhouse #kafka #langgraph #антиабьюз

  8. Погружение в Kafka c KRaft

    Обязательной частью является валидировать понимание работы с распределенными событийными моделями. Тут начинается аномалия. Не смотря на то, что все кандидаты заявляют об опыте с Kafka, многие теряются в рассуждениях на тему что это и как организовано. Для того, чтобы коллегам было комфортное на техническом интервью, а так же для желающих понять работу Kafka без Zookeper предлагаю статью. Понимаю, что мы все не любим длинные тексты, поэтому вложил максимум деталей в схемы и краткие формулировки.

    habr.com/ru/articles/1053670/

    #kafka #kraft #raft #java #python #devops #development #broker #partitioning #replica

  9. Kafka Consumer в тестовой автоматизации: архитектурный разбор

    Привет, Хабр! На связи Егор Лаптев — QA Fullstack Java в SENSE на проекте крупного российского банка. End-to-end тесты UI проверяют только то, что видно на экране: кнопка нажалась, форма открылась, данные отобразились. Но в распределённых системах значительная часть бизнес-логики уходит за кадр — в асинхронные события, которые летят через Kafka. Если событие не дошло до топика или пришло с неверным payload, пользователь этого не увидит, а бизнес-процесс сломается. В этой статье расскажу, как мы научились проверять Kafka-события прямо в автотестах — без Kafka UI, kcat и обёрточных сервисов, одной зависимостью и так, чтобы это работало в корпоративной сети с SSL. Покажу архитектуру коннектора, разберу три основных проблемы (SSL-сертификаты, конфликты consumer group и асинхронные тайминги), и поделюсь моделью работы инженера в связке с AI-агентом. Кому будет полезно: QA-инженерам и специалистам по автоматизации, которые тестируют распределённые системы и хотят проверять Kafka-события прямо в автотестах; и инженерам, которым интересна практическая модель работы в связке с AI-агентом — как она ускоряет разработку тестовой инфраструктуры.

    habr.com/ru/companies/it_sense

    #kafka #kafka_consumer #kafka_в_тестировании #qa_automation #sasl #асинхронное_тестирование #aiагенты #allure #consumer_group #распределенные_системы

  10. Kafka Consumer в тестовой автоматизации: архитектурный разбор

    Привет, Хабр! На связи Егор Лаптев — QA Fullstack Java в SENSE на проекте крупного российского банка. End-to-end тесты UI проверяют только то, что видно на экране: кнопка нажалась, форма открылась, данные отобразились. Но в распределённых системах значительная часть бизнес-логики уходит за кадр — в асинхронные события, которые летят через Kafka. Если событие не дошло до топика или пришло с неверным payload, пользователь этого не увидит, а бизнес-процесс сломается. В этой статье расскажу, как мы научились проверять Kafka-события прямо в автотестах — без Kafka UI, kcat и обёрточных сервисов, одной зависимостью и так, чтобы это работало в корпоративной сети с SSL. Покажу архитектуру коннектора, разберу три основных проблемы (SSL-сертификаты, конфликты consumer group и асинхронные тайминги), и поделюсь моделью работы инженера в связке с AI-агентом. Кому будет полезно: QA-инженерам и специалистам по автоматизации, которые тестируют распределённые системы и хотят проверять Kafka-события прямо в автотестах; и инженерам, которым интересна практическая модель работы в связке с AI-агентом — как она ускоряет разработку тестовой инфраструктуры.

    habr.com/ru/companies/it_sense

    #kafka #kafka_consumer #kafka_в_тестировании #qa_automation #sasl #асинхронное_тестирование #aiагенты #allure #consumer_group #распределенные_системы

  11. Kafka Consumer в тестовой автоматизации: архитектурный разбор

    Привет, Хабр! На связи Егор Лаптев — QA Fullstack Java в SENSE на проекте крупного российского банка. End-to-end тесты UI проверяют только то, что видно на экране: кнопка нажалась, форма открылась, данные отобразились. Но в распределённых системах значительная часть бизнес-логики уходит за кадр — в асинхронные события, которые летят через Kafka. Если событие не дошло до топика или пришло с неверным payload, пользователь этого не увидит, а бизнес-процесс сломается. В этой статье расскажу, как мы научились проверять Kafka-события прямо в автотестах — без Kafka UI, kcat и обёрточных сервисов, одной зависимостью и так, чтобы это работало в корпоративной сети с SSL. Покажу архитектуру коннектора, разберу три основных проблемы (SSL-сертификаты, конфликты consumer group и асинхронные тайминги), и поделюсь моделью работы инженера в связке с AI-агентом. Кому будет полезно: QA-инженерам и специалистам по автоматизации, которые тестируют распределённые системы и хотят проверять Kafka-события прямо в автотестах; и инженерам, которым интересна практическая модель работы в связке с AI-агентом — как она ускоряет разработку тестовой инфраструктуры.

    habr.com/ru/companies/it_sense

    #kafka #kafka_consumer #kafka_в_тестировании #qa_automation #sasl #асинхронное_тестирование #aiагенты #allure #consumer_group #распределенные_системы

  12. Как мы ушли от ETL к CDC: выбираем архитектуру real-time аналитики на PostgreSQL, Kafka и ClickHouse. Часть 1

    Все началось с просьбы сделать отчеты в реальном времени. На первый взгляд задача выглядела простой, но довольно быстро выяснилось, что существующая архитектура для этого не подходит. Проект был разбит на множество микросервисов, каждый из которых хранил данные в собственной PostgreSQL-базе. Чтобы строить сквозные отчеты, информацию нужно было где-то объединять. На тот момент аналитика уже работала через ETL: раз в сутки Airflow восстанавливал общую PostgreSQL из ежедневных бекапов, а Redash выполнял запросы уже к ней. Решение было надежным и не требовало нагрузки на production, но для real-time оно не годилось — в лучшем случае отчеты показывали состояние системы на начало дня.

    habr.com/ru/articles/1051760/

    #postgresql #clickhouse #kafka #debezium #cdc #kubernetes #etl #realtime_аналитика #kafka_connect #devops

  13. Как мы ушли от ETL к CDC: выбираем архитектуру real-time аналитики на PostgreSQL, Kafka и ClickHouse. Часть 1

    Все началось с просьбы сделать отчеты в реальном времени. На первый взгляд задача выглядела простой, но довольно быстро выяснилось, что существующая архитектура для этого не подходит. Проект был разбит на множество микросервисов, каждый из которых хранил данные в собственной PostgreSQL-базе. Чтобы строить сквозные отчеты, информацию нужно было где-то объединять. На тот момент аналитика уже работала через ETL: раз в сутки Airflow восстанавливал общую PostgreSQL из ежедневных бекапов, а Redash выполнял запросы уже к ней. Решение было надежным и не требовало нагрузки на production, но для real-time оно не годилось — в лучшем случае отчеты показывали состояние системы на начало дня.

    habr.com/ru/articles/1051760/

    #postgresql #clickhouse #kafka #debezium #cdc #kubernetes #etl #realtime_аналитика #kafka_connect #devops

  14. Как мы ушли от ETL к CDC: выбираем архитектуру real-time аналитики на PostgreSQL, Kafka и ClickHouse. Часть 1

    Все началось с просьбы сделать отчеты в реальном времени. На первый взгляд задача выглядела простой, но довольно быстро выяснилось, что существующая архитектура для этого не подходит. Проект был разбит на множество микросервисов, каждый из которых хранил данные в собственной PostgreSQL-базе. Чтобы строить сквозные отчеты, информацию нужно было где-то объединять. На тот момент аналитика уже работала через ETL: раз в сутки Airflow восстанавливал общую PostgreSQL из ежедневных бекапов, а Redash выполнял запросы уже к ней. Решение было надежным и не требовало нагрузки на production, но для real-time оно не годилось — в лучшем случае отчеты показывали состояние системы на начало дня.

    habr.com/ru/articles/1051760/

    #postgresql #clickhouse #kafka #debezium #cdc #kubernetes #etl #realtime_аналитика #kafka_connect #devops

  15. Реалтайм-аналитика «без боли»: миграция из PostgreSQL и Kafka в ClickHouse и визуализация в Superset

    Когда у вас появляется продукт с активными процессами и большим количеством пользователей, объём данных начинает расти быстрее, чем ожидалось. На старте всё выглядит достаточно просто: есть PostgreSQL, где хранятся основные сущности, есть Kafka с событиями, и кажется, что этого достаточно для решения большинства задач. Но со временем появляются новые вопросы. Команде становится недостаточно просто посчитать количество записей или получить текущее состояние объекта. Хочется понять, что происходило в системе: какие события привели к изменению состояния, какие действия выполнялись, где возникла проблема и на каком этапе произошёл сбой. В этот момент становится понятно, что обычные источники данных не всегда подходят для аналитики. PostgreSQL должен обслуживать основную нагрузку приложения, а Kafka отлично решает задачи доставки событий, но не является удобным инструментом для сложного анализа. В этой статье расскажу, как мы с командой построили отдельный аналитический контур: организовали миграцию данных из разных источников, объединили события Kafka и данные PostgreSQL, а затем вывели результат в удобные дашборды для технических специалистов и бизнеса. Узнать больше

    habr.com/ru/companies/magnit/a

    #clickhouse #kafka #postgresql #superset #peerdb #kafkaconnect

  16. Что спросить у вендора ESB, если вы подбираете интеграционную шину

    На связи Сергей Скирдин, технический директор ИТ-интегратора «Белый код». Последние два года я изучаю российский рынок ESB и интеграционных платформ, делаю обзоры на продукты. Есть интересная закономерность: многие компании, которые выбирают ESB, готовят собственный опросник. В прошлом году вместе с вендорами, мы решили составить единый опросный лист. Рассказываю и показываю, что из этого получилось.

    habr.com/ru/companies/w_code/a

    #шины_данных #опросный_лист #интеграции #коннектор #мониторинг #производительность #ESB #интеграционные_платформы #kafka #open_source

  17. Простой API, умный сервер: третий класс брокеров, который пропускают между Kafka и RabbitMQ

    Привет, Хабр! Меня зовут Андрей Серебрянский. Раньше я строил платформы потоковой обработки данных в банках, а теперь вместе с командой разрабатываю YDB Topics и YMQ. После своих докладов на конференциях мы с коллегами по индустрии часто обсуждаем брокеры сообщений. И меня, как разработчика таких решений, огорчает упрощённый подход: «RabbitMQ не нужен, всё можно собрать на Kafka». Вспоминая известную шутку: да, с помощью буханки бородинского и двух спиц можно собрать модель троллейбуса. Но зачем? Да, я люблю Kafka и с удовольствием про неё рассказываю на Хабре и Хайлоаде. Но, кроме Kafka и RabbitMQ, есть и третий класс брокеров сообщений: SQS-совместимые очереди в облачных платформах ( и не только ), которые для многих продакшн-задач подходят лучше, чем Kafka. Опытные разработчики, проводя system design interview, любят спрашивать друг друга о разнице между брокерами сообщений. А мне каждый раз хочется ответить: «Зависит от контекста». В статье под катом я начну с такого контекста: напомню, для чего изначально создавались SQS, RabbitMQ, Kafka. После этого расскажу про принцип «простой API, умный сервер» и про задачи, которые в эпоху микросервисов решаются с помощью брокеров. А в завершение — про реализацию SQS, над которой сейчас работаю: Yandex Message Queue.

    habr.com/ru/companies/ydb/arti

    #kafka #rabbitmq #sqs #celery #ydb

  18. Dead Letter Queue в Kafka на практике

    DLQ — это просто топик. Сложное — всё, что вокруг него. Эта статья — про практическую архитектуру обработки событий из Kafka с отправкой данных во внешний REST API. Главная проблема такого сценария — нестабильность внешнего API. Он периодически деградирует по latency или начинает отвечать с ошибками, и это напрямую влияет на пропускную способность всего консьюмера.

    habr.com/ru/articles/1045324/

    #kafka #concurrency #asyncio #semaphore #finite_state_machine #dead_letter_queue #highload #api

  19. Обзор «1С: Шины» и не только: 17 российских ESB спустя 100+ часов изучения

    На связи Сергей Скирдин, технический директор ИТ-интегратора «Белый код». Два года я изучаю российский рынок шин данных. За это время удалось связаться с более 40 вендорами, с половиной из них мы встретились, чтобы написать обзор. Каждый такой материал — это вопросы разработчикам, демонстрация решения, изучение документации. Недавно я объединил все обзоры в один большой, чтобы было удобнее знакомиться с разными продуктами. Рассказываю, в чем идея и что у меня получилось сделать за 2 года.

    habr.com/ru/companies/w_code/a

    #esb #шина_данных #интеграционные_платформы #datareon #1с_шина #корпоративная_шина_данных #микросервисная_архитектура #kafka #open_source

  20. Контракты данных между командами: гайд по data contracts в дата‑пайплайнах

    Когда пайплайн отработал без ошибок, тесты зелёные, а в дашборде внезапно нули, проблема может быть не в инфраструктуре, а в отсутствии договорённостей между командами. В статье разбираем, как data contracts помогают фиксировать структуру, правила и ответственность за данные — и почему это спасает витрины, отчёты и нервы дата-инженеров.

    habr.com/ru/companies/otus/art

    #контракты_данных #data_contracts #датапайплайны #DWH #Data_Lake #Data_Engineering #dbt #Kafka #Schema_Registry #качество_данных