#kafkaconnect — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #kafkaconnect, aggregated by home.social.
-
Реалтайм-аналитика «без боли»: миграция из PostgreSQL и Kafka в ClickHouse и визуализация в Superset
Когда у вас появляется продукт с активными процессами и большим количеством пользователей, объём данных начинает расти быстрее, чем ожидалось. На старте всё выглядит достаточно просто: есть PostgreSQL, где хранятся основные сущности, есть Kafka с событиями, и кажется, что этого достаточно для решения большинства задач. Но со временем появляются новые вопросы. Команде становится недостаточно просто посчитать количество записей или получить текущее состояние объекта. Хочется понять, что происходило в системе: какие события привели к изменению состояния, какие действия выполнялись, где возникла проблема и на каком этапе произошёл сбой. В этот момент становится понятно, что обычные источники данных не всегда подходят для аналитики. PostgreSQL должен обслуживать основную нагрузку приложения, а Kafka отлично решает задачи доставки событий, но не является удобным инструментом для сложного анализа. В этой статье расскажу, как мы с командой построили отдельный аналитический контур: организовали миграцию данных из разных источников, объединили события Kafka и данные PostgreSQL, а затем вывели результат в удобные дашборды для технических специалистов и бизнеса. Узнать больше
https://habr.com/ru/companies/magnit/articles/1049072/
#clickhouse #kafka #postgresql #superset #peerdb #kafkaconnect
-
Реалтайм-аналитика «без боли»: миграция из PostgreSQL и Kafka в ClickHouse и визуализация в Superset
Когда у вас появляется продукт с активными процессами и большим количеством пользователей, объём данных начинает расти быстрее, чем ожидалось. На старте всё выглядит достаточно просто: есть PostgreSQL, где хранятся основные сущности, есть Kafka с событиями, и кажется, что этого достаточно для решения большинства задач. Но со временем появляются новые вопросы. Команде становится недостаточно просто посчитать количество записей или получить текущее состояние объекта. Хочется понять, что происходило в системе: какие события привели к изменению состояния, какие действия выполнялись, где возникла проблема и на каком этапе произошёл сбой. В этот момент становится понятно, что обычные источники данных не всегда подходят для аналитики. PostgreSQL должен обслуживать основную нагрузку приложения, а Kafka отлично решает задачи доставки событий, но не является удобным инструментом для сложного анализа. В этой статье расскажу, как мы с командой построили отдельный аналитический контур: организовали миграцию данных из разных источников, объединили события Kafka и данные PostgreSQL, а затем вывели результат в удобные дашборды для технических специалистов и бизнеса. Узнать больше
https://habr.com/ru/companies/magnit/articles/1049072/
#clickhouse #kafka #postgresql #superset #peerdb #kafkaconnect
-
Реалтайм-аналитика «без боли»: миграция из PostgreSQL и Kafka в ClickHouse и визуализация в Superset
Когда у вас появляется продукт с активными процессами и большим количеством пользователей, объём данных начинает расти быстрее, чем ожидалось. На старте всё выглядит достаточно просто: есть PostgreSQL, где хранятся основные сущности, есть Kafka с событиями, и кажется, что этого достаточно для решения большинства задач. Но со временем появляются новые вопросы. Команде становится недостаточно просто посчитать количество записей или получить текущее состояние объекта. Хочется понять, что происходило в системе: какие события привели к изменению состояния, какие действия выполнялись, где возникла проблема и на каком этапе произошёл сбой. В этот момент становится понятно, что обычные источники данных не всегда подходят для аналитики. PostgreSQL должен обслуживать основную нагрузку приложения, а Kafka отлично решает задачи доставки событий, но не является удобным инструментом для сложного анализа. В этой статье расскажу, как мы с командой построили отдельный аналитический контур: организовали миграцию данных из разных источников, объединили события Kafka и данные PostgreSQL, а затем вывели результат в удобные дашборды для технических специалистов и бизнеса. Узнать больше
https://habr.com/ru/companies/magnit/articles/1049072/
#clickhouse #kafka #postgresql #superset #peerdb #kafkaconnect
-
Безошибочная работа с Kafka из Node js. Часть 3 Cтруктура сообщений, когда Kafka не нужна и теряет данные
В предыдущих частях рассматривались аспекты публикации сообщений , ребалансировки консьюмер групп и масштабирования чтения, а также проектирования консьюмеров . Эта часть посвящена базовой структуре сообщений, неподходящим сценариям использования Kafka и гарантиям записи.
https://habr.com/ru/articles/1013046/
#kafka #nodejs #брокеры_сообщений #kafkaconnect #producerconsumer #messagebroker #apache_kafka #событийная_архитектура #kafka_consumer #kafka_apache
-
Безошибочная работа с Kafka из Node js. Часть 3 Cтруктура сообщений, когда Kafka не нужна и теряет данные
В предыдущих частях рассматривались аспекты публикации сообщений , ребалансировки консьюмер групп и масштабирования чтения, а также проектирования консьюмеров . Эта часть посвящена базовой структуре сообщений, неподходящим сценариям использования Kafka и гарантиям записи.
https://habr.com/ru/articles/1013046/
#kafka #nodejs #брокеры_сообщений #kafkaconnect #producerconsumer #messagebroker #apache_kafka #событийная_архитектура #kafka_consumer #kafka_apache
-
Безошибочная работа с Kafka из Node js. Часть 3 Cтруктура сообщений, когда Kafka не нужна и теряет данные
В предыдущих частях рассматривались аспекты публикации сообщений , ребалансировки консьюмер групп и масштабирования чтения, а также проектирования консьюмеров . Эта часть посвящена базовой структуре сообщений, неподходящим сценариям использования Kafka и гарантиям записи.
https://habr.com/ru/articles/1013046/
#kafka #nodejs #брокеры_сообщений #kafkaconnect #producerconsumer #messagebroker #apache_kafka #событийная_архитектура #kafka_consumer #kafka_apache
-
Cказ о том, как мы с Oracle на PostgreSQL переехали
Привет, Хабр! Меня зовут Даша Александрова, я Java‑разработчик. Хочу поделиться опытом миграции данных из Oracle в PostgreSQL без простоя сервисов. Причина миграции — импортозамещение. Теперь немного про сам проект. В его основе — микросервисная архитектура на Java 11/17 и Spring Boot 2/3. В качестве основной базы данных использовалась Oracle с несколькими схемами. В коде сочетаются нативные SQL‑запросы и Hibernate, вся бизнес‑логика живет на уровне приложения — без процедур, триггеров и другой логики в базе. Идентификаторы генерируются через sequence. Проект активно развивается, регулярно выпускаются релизы. Система ориентирована на клиентские приложения — мобильное и веб, при этом нагрузка остается умеренной и не относится к highload‑сценариям. Ключевое нефункциональное требование — выполнить миграцию без простоя системы и без заметного влияния на пользователей . Может возникнуть логичный вопрос: если такие миграции уже делались не раз, почему просто не взять готовое решение? На практике универсального подхода не существует. Где‑то допустим простой на несколько часов, где‑то — нет. В одних системах хватает простого переноса, в других приходится использовать сложные стратегии вроде двойной записи. Многие статьи подробно разбирают инструменты, но их применение в конкретном проекте — это отдельная инженерная задача. К тому же у каждой системы есть свои ограничения и нюансы. Поэтому дальше я разберу конкретный кейс и те решения, которые были приняли по ходу миграции.
https://habr.com/ru/articles/1025336/
#java #postgresql #debezium #cdc #oracle #kafkaconnect #миграция_базы_данных #миграция_данных
-
Cказ о том, как мы с Oracle на PostgreSQL переехали
Привет, Хабр! Меня зовут Даша Александрова, я Java‑разработчик. Хочу поделиться опытом миграции данных из Oracle в PostgreSQL без простоя сервисов. Причина миграции — импортозамещение. Теперь немного про сам проект. В его основе — микросервисная архитектура на Java 11/17 и Spring Boot 2/3. В качестве основной базы данных использовалась Oracle с несколькими схемами. В коде сочетаются нативные SQL‑запросы и Hibernate, вся бизнес‑логика живет на уровне приложения — без процедур, триггеров и другой логики в базе. Идентификаторы генерируются через sequence. Проект активно развивается, регулярно выпускаются релизы. Система ориентирована на клиентские приложения — мобильное и веб, при этом нагрузка остается умеренной и не относится к highload‑сценариям. Ключевое нефункциональное требование — выполнить миграцию без простоя системы и без заметного влияния на пользователей . Может возникнуть логичный вопрос: если такие миграции уже делались не раз, почему просто не взять готовое решение? На практике универсального подхода не существует. Где‑то допустим простой на несколько часов, где‑то — нет. В одних системах хватает простого переноса, в других приходится использовать сложные стратегии вроде двойной записи. Многие статьи подробно разбирают инструменты, но их применение в конкретном проекте — это отдельная инженерная задача. К тому же у каждой системы есть свои ограничения и нюансы. Поэтому дальше я разберу конкретный кейс и те решения, которые были приняли по ходу миграции.
https://habr.com/ru/articles/1025336/
#java #postgresql #debezium #cdc #oracle #kafkaconnect #миграция_базы_данных #миграция_данных
-
Cказ о том, как мы с Oracle на PostgreSQL переехали
Привет, Хабр! Меня зовут Даша Александрова, я Java‑разработчик. Хочу поделиться опытом миграции данных из Oracle в PostgreSQL без простоя сервисов. Причина миграции — импортозамещение. Теперь немного про сам проект. В его основе — микросервисная архитектура на Java 11/17 и Spring Boot 2/3. В качестве основной базы данных использовалась Oracle с несколькими схемами. В коде сочетаются нативные SQL‑запросы и Hibernate, вся бизнес‑логика живет на уровне приложения — без процедур, триггеров и другой логики в базе. Идентификаторы генерируются через sequence. Проект активно развивается, регулярно выпускаются релизы. Система ориентирована на клиентские приложения — мобильное и веб, при этом нагрузка остается умеренной и не относится к highload‑сценариям. Ключевое нефункциональное требование — выполнить миграцию без простоя системы и без заметного влияния на пользователей . Может возникнуть логичный вопрос: если такие миграции уже делались не раз, почему просто не взять готовое решение? На практике универсального подхода не существует. Где‑то допустим простой на несколько часов, где‑то — нет. В одних системах хватает простого переноса, в других приходится использовать сложные стратегии вроде двойной записи. Многие статьи подробно разбирают инструменты, но их применение в конкретном проекте — это отдельная инженерная задача. К тому же у каждой системы есть свои ограничения и нюансы. Поэтому дальше я разберу конкретный кейс и те решения, которые были приняли по ходу миграции.
https://habr.com/ru/articles/1025336/
#java #postgresql #debezium #cdc #oracle #kafkaconnect #миграция_базы_данных #миграция_данных
-
Параллельная обработка Kafka сообщений с гарантией at-least-once в условиях медленного внешнего сервиса
В данной статье я хочу рассказать об подходе к организации параллельной обработки сообщений из Kafka, когда Kafka Topic используется как транспорт бизнес-событий, например транзакций или ордеров, которые необходимо отправить во внешнюю систему. При это важно обеспечить стабильную скорость обработки трафика и надёжность (отсутствие потерь) в условиях, когда downstream-система не на все запросы отвечает стабильно и быстро. Покажу почему стандартные подходы, такие как обработка batch'ами, в определённых сценариях перестают работать и приводят к деградации производительности или рисками потери сообщений. Для иллюстрации подходов далее будет использоваться код из демонстрационного проекта на Kotlin с использованием spring boot, webFlux, spring reactor и reactor-kafka. Код проекта не является production-ready: в нём, например, отсутствует обработка rebalance, а также ряд других моментов, обязательных для промышленной системы. Используется reactor-kafka, однако описываемые решения не зависят от конкретного фреймворка работы с Kafka и могут быть реализованы с использованием других. В статье намеренно опущены детали реализации бизнес-протокола и механизма идемпотентности. В реальной системе они реализованы с использованием внутреннего хранилища и машины состояний обработки ордеров, но это за рамками данной статьи.
-
Параллельная обработка Kafka сообщений с гарантией at-least-once в условиях медленного внешнего сервиса
В данной статье я хочу рассказать об подходе к организации параллельной обработки сообщений из Kafka, когда Kafka Topic используется как транспорт бизнес-событий, например транзакций или ордеров, которые необходимо отправить во внешнюю систему. При это важно обеспечить стабильную скорость обработки трафика и надёжность (отсутствие потерь) в условиях, когда downstream-система не на все запросы отвечает стабильно и быстро. Покажу почему стандартные подходы, такие как обработка batch'ами, в определённых сценариях перестают работать и приводят к деградации производительности или рисками потери сообщений. Для иллюстрации подходов далее будет использоваться код из демонстрационного проекта на Kotlin с использованием spring boot, webFlux, spring reactor и reactor-kafka. Код проекта не является production-ready: в нём, например, отсутствует обработка rebalance, а также ряд других моментов, обязательных для промышленной системы. Используется reactor-kafka, однако описываемые решения не зависят от конкретного фреймворка работы с Kafka и могут быть реализованы с использованием других. В статье намеренно опущены детали реализации бизнес-протокола и механизма идемпотентности. В реальной системе они реализованы с использованием внутреннего хранилища и машины состояний обработки ордеров, но это за рамками данной статьи.
-
Параллельная обработка Kafka сообщений с гарантией at-least-once в условиях медленного внешнего сервиса
В данной статье я хочу рассказать об подходе к организации параллельной обработки сообщений из Kafka, когда Kafka Topic используется как транспорт бизнес-событий, например транзакций или ордеров, которые необходимо отправить во внешнюю систему. При это важно обеспечить стабильную скорость обработки трафика и надёжность (отсутствие потерь) в условиях, когда downstream-система не на все запросы отвечает стабильно и быстро. Покажу почему стандартные подходы, такие как обработка batch'ами, в определённых сценариях перестают работать и приводят к деградации производительности или рисками потери сообщений. Для иллюстрации подходов далее будет использоваться код из демонстрационного проекта на Kotlin с использованием spring boot, webFlux, spring reactor и reactor-kafka. Код проекта не является production-ready: в нём, например, отсутствует обработка rebalance, а также ряд других моментов, обязательных для промышленной системы. Используется reactor-kafka, однако описываемые решения не зависят от конкретного фреймворка работы с Kafka и могут быть реализованы с использованием других. В статье намеренно опущены детали реализации бизнес-протокола и механизма идемпотентности. В реальной системе они реализованы с использованием внутреннего хранилища и машины состояний обработки ордеров, но это за рамками данной статьи.
-
Паттерн Transactional Outbox на примере двух микросервисов на java
Всем привет! В данной статье будет описан один из возможных вариантов реализации паттерна outbox transactional. План данной статьи такой. Вначале немного теории, а потом на примере двух микросервисов будет показала реализация данного паттерна с помощью debezium и kafka. Данная статья будет полезна для новичков, которые не встречались с данным паттерном. Весь код микросервисов будет доступен по ссылкам. Но вначале немного теории. Самый главный вопрос зачем нужен данный паттерн и какую он решает задачу. Паттерн Outbox – используется в распределенных транзакциях, то есть в транзакциях, которые проходят и затрагивают несколько микровервисов, для обеспечения гарантированной доставки сообщения от одного микросервиса до другого. Данный паттерн используется там, где очень критично чтобы сообщение не потерялось, даже при сбоях в системе. Outbox паттерн получил распространение именно в микросервисной архитектуре, где нет возможности с помощью одной аннотации обеспечить транзакционность какого-то метода и возможный откат всей транзакции в рамках нескольких микросервисов. Теперь перейдем к практике. Допустим у нас имеется два микросервиса: order-servic, в котором клиент заказывает какой-то товар и bank-service, в котором происходит оплата за этот товар. Весь код микросервисов будет доступен по ссылкам. Задача в том, чтобы при заказе товара обязательно произошло списание денег за него или если денег недостаточно или возникла ошибка на стороне банка микросервис по заказам узнал об этом. Для реализации этого паттерна я буду использовать debezium и kafka.
https://habr.com/ru/articles/991934/
#java #паттерны_проектирования #outbox #outboxпаттерн #transactional_outbox #kafkaconnect #debezium
-
Паттерн Transactional Outbox на примере двух микросервисов на java
Всем привет! В данной статье будет описан один из возможных вариантов реализации паттерна outbox transactional. План данной статьи такой. Вначале немного теории, а потом на примере двух микросервисов будет показала реализация данного паттерна с помощью debezium и kafka. Данная статья будет полезна для новичков, которые не встречались с данным паттерном. Весь код микросервисов будет доступен по ссылкам. Но вначале немного теории. Самый главный вопрос зачем нужен данный паттерн и какую он решает задачу. Паттерн Outbox – используется в распределенных транзакциях, то есть в транзакциях, которые проходят и затрагивают несколько микровервисов, для обеспечения гарантированной доставки сообщения от одного микросервиса до другого. Данный паттерн используется там, где очень критично чтобы сообщение не потерялось, даже при сбоях в системе. Outbox паттерн получил распространение именно в микросервисной архитектуре, где нет возможности с помощью одной аннотации обеспечить транзакционность какого-то метода и возможный откат всей транзакции в рамках нескольких микросервисов. Теперь перейдем к практике. Допустим у нас имеется два микросервиса: order-servic, в котором клиент заказывает какой-то товар и bank-service, в котором происходит оплата за этот товар. Весь код микросервисов будет доступен по ссылкам. Задача в том, чтобы при заказе товара обязательно произошло списание денег за него или если денег недостаточно или возникла ошибка на стороне банка микросервис по заказам узнал об этом. Для реализации этого паттерна я буду использовать debezium и kafka.
https://habr.com/ru/articles/991934/
#java #паттерны_проектирования #outbox #outboxпаттерн #transactional_outbox #kafkaconnect #debezium
-
Паттерн Transactional Outbox на примере двух микросервисов на java
Всем привет! В данной статье будет описан один из возможных вариантов реализации паттерна outbox transactional. План данной статьи такой. Вначале немного теории, а потом на примере двух микросервисов будет показала реализация данного паттерна с помощью debezium и kafka. Данная статья будет полезна для новичков, которые не встречались с данным паттерном. Весь код микросервисов будет доступен по ссылкам. Но вначале немного теории. Самый главный вопрос зачем нужен данный паттерн и какую он решает задачу. Паттерн Outbox – используется в распределенных транзакциях, то есть в транзакциях, которые проходят и затрагивают несколько микровервисов, для обеспечения гарантированной доставки сообщения от одного микросервиса до другого. Данный паттерн используется там, где очень критично чтобы сообщение не потерялось, даже при сбоях в системе. Outbox паттерн получил распространение именно в микросервисной архитектуре, где нет возможности с помощью одной аннотации обеспечить транзакционность какого-то метода и возможный откат всей транзакции в рамках нескольких микросервисов. Теперь перейдем к практике. Допустим у нас имеется два микросервиса: order-servic, в котором клиент заказывает какой-то товар и bank-service, в котором происходит оплата за этот товар. Весь код микросервисов будет доступен по ссылкам. Задача в том, чтобы при заказе товара обязательно произошло списание денег за него или если денег недостаточно или возникла ошибка на стороне банка микросервис по заказам узнал об этом. Для реализации этого паттерна я буду использовать debezium и kafka.
https://habr.com/ru/articles/991934/
#java #паттерны_проектирования #outbox #outboxпаттерн #transactional_outbox #kafkaconnect #debezium
-
One Open-source Project Daily
Change data capture for a variety of databases.
https://github.com/debezium/debezium
#1ospd #opensource #apachekafka #cdc #changedatacapture #datapipeline #database #debezium #eventstreaming #kafka #kafkaconnect #kafkaproducer -
One Open-source Project Daily
Change data capture for a variety of databases.
https://github.com/debezium/debezium
#1ospd #opensource #apachekafka #cdc #changedatacapture #datapipeline #database #debezium #eventstreaming #kafka #kafkaconnect #kafkaproducer -
One Open-source Project Daily
Change data capture for a variety of databases.
https://github.com/debezium/debezium
#1ospd #opensource #apachekafka #cdc #changedatacapture #datapipeline #database #debezium #eventstreaming #kafka #kafkaconnect #kafkaproducer -
One Open-source Project Daily
Change data capture for a variety of databases.
https://github.com/debezium/debezium
#1ospd #opensource #apachekafka #cdc #changedatacapture #datapipeline #database #debezium #eventstreaming #kafka #kafkaconnect #kafkaproducer -
One Open-source Project Daily
Change data capture for a variety of databases.
https://github.com/debezium/debezium
#1ospd #opensource #apachekafka #cdc #changedatacapture #datapipeline #database #debezium #eventstreaming #kafka #kafkaconnect #kafkaproducer -
Битва, где все проигрывают, или Как Kafka Compact Topics остановил войну данных
В статье рассказывается о типичной проблеме синхронизации данных между микросервисами через связку «снапшот + инкременты» и предлагается решение на основе Kafka Compact Topics . Это своего рода «волшебная тетрадь», которая автоматически оставляет только последние версии записей, избавляя от головной боли с рассинхронизацией. Разбираются практические кейсы применения, подводные камни, тонкости настройки и интеграция с Debezium для автоматической выгрузки из PostgreSQL. Что получите: понимание, когда компактные топики решают проблему, а когда лучше использовать классические подходы, плюс готовые конфиги для быстрого старта
-
Битва, где все проигрывают, или Как Kafka Compact Topics остановил войну данных
В статье рассказывается о типичной проблеме синхронизации данных между микросервисами через связку «снапшот + инкременты» и предлагается решение на основе Kafka Compact Topics . Это своего рода «волшебная тетрадь», которая автоматически оставляет только последние версии записей, избавляя от головной боли с рассинхронизацией. Разбираются практические кейсы применения, подводные камни, тонкости настройки и интеграция с Debezium для автоматической выгрузки из PostgreSQL. Что получите: понимание, когда компактные топики решают проблему, а когда лучше использовать классические подходы, плюс готовые конфиги для быстрого старта
-
Битва, где все проигрывают, или Как Kafka Compact Topics остановил войну данных
В статье рассказывается о типичной проблеме синхронизации данных между микросервисами через связку «снапшот + инкременты» и предлагается решение на основе Kafka Compact Topics . Это своего рода «волшебная тетрадь», которая автоматически оставляет только последние версии записей, избавляя от головной боли с рассинхронизацией. Разбираются практические кейсы применения, подводные камни, тонкости настройки и интеграция с Debezium для автоматической выгрузки из PostgreSQL. Что получите: понимание, когда компактные топики решают проблему, а когда лучше использовать классические подходы, плюс готовые конфиги для быстрого старта
-
Пишем свой Config Provider для Kafka Connect с поддержкой значений по умолчанию
Для инжекции значений из различных источников в конфигурации тасок Kafka Connect используются различные реализации интерфейса org.apache.kafka.common.config.provider.ConfigProvider. Это специализированный интерфейс, реализации которого отвечают за то, чтобы подставить значения используя различные источники.
-
Пишем свой Config Provider для Kafka Connect с поддержкой значений по умолчанию
Для инжекции значений из различных источников в конфигурации тасок Kafka Connect используются различные реализации интерфейса org.apache.kafka.common.config.provider.ConfigProvider. Это специализированный интерфейс, реализации которого отвечают за то, чтобы подставить значения используя различные источники.
-
Пишем свой Config Provider для Kafka Connect с поддержкой значений по умолчанию
Для инжекции значений из различных источников в конфигурации тасок Kafka Connect используются различные реализации интерфейса org.apache.kafka.common.config.provider.ConfigProvider. Это специализированный интерфейс, реализации которого отвечают за то, чтобы подставить значения используя различные источники.
-
Как в Sidec благодаря exactly-once сократили потребление ресурсов без потери производительности
Меня зовут Сергей Гребенюк, я лидер разработки Sidec ( Росреестр ). Расскажу, как решили задачу объединения двух топиков с соотношением один ко многим и почему не устроило решение на Kafka-streams ( kafka docs ) и RocksDB ( github ). А также о том, как, опираясь на гарантии доставки exactly-once (EOS) ( confluent docs ), смогли снизить требования к ресурсам в несколько раз. На иллюстрации показаны два подхода к объединению топиков: с persistent cache и in-memory cache. Мы перейдём от первой схемы ко второй.
-
Как в Sidec благодаря exactly-once сократили потребление ресурсов без потери производительности
Меня зовут Сергей Гребенюк, я лидер разработки Sidec ( Росреестр ). Расскажу, как решили задачу объединения двух топиков с соотношением один ко многим и почему не устроило решение на Kafka-streams ( kafka docs ) и RocksDB ( github ). А также о том, как, опираясь на гарантии доставки exactly-once (EOS) ( confluent docs ), смогли снизить требования к ресурсам в несколько раз. На иллюстрации показаны два подхода к объединению топиков: с persistent cache и in-memory cache. Мы перейдём от первой схемы ко второй.
-
Как в Sidec благодаря exactly-once сократили потребление ресурсов без потери производительности
Меня зовут Сергей Гребенюк, я лидер разработки Sidec ( Росреестр ). Расскажу, как решили задачу объединения двух топиков с соотношением один ко многим и почему не устроило решение на Kafka-streams ( kafka docs ) и RocksDB ( github ). А также о том, как, опираясь на гарантии доставки exactly-once (EOS) ( confluent docs ), смогли снизить требования к ресурсам в несколько раз. На иллюстрации показаны два подхода к объединению топиков: с persistent cache и in-memory cache. Мы перейдём от первой схемы ко второй.
-
Kafka. Лучшие практики применения. Настройки Prudcer & Consumer
Привет, Хабр! Меня зовут Михаил, я являюсь ФинТех системным аналитиком, исполняющим роль архитектора на проектах. И сегодня я хочу поделиться материалами по Kafka, которые подготовил для обучения сотрудников из своей команды. В материале постарался отразить самые важные технические моменты по Kafka, которые будут подкреплены наглядными кейсами и примерами использования. Материал будет полезным как для начинающих, так и для продвинутых пользователей. Желаю приятного прочтения. Kafka. Лучшие практики применения.
https://habr.com/ru/articles/853652/
#kafka #кафка #kafka_consumer #producer/consumer #producer #consumer #kafkaconnect #kafka_listener #kafka_apache #kafka_connect
-
Kafka. Лучшие практики применения. Настройки Prudcer & Consumer
Привет, Хабр! Меня зовут Михаил, я являюсь ФинТех системным аналитиком, исполняющим роль архитектора на проектах. И сегодня я хочу поделиться материалами по Kafka, которые подготовил для обучения сотрудников из своей команды. В материале постарался отразить самые важные технические моменты по Kafka, которые будут подкреплены наглядными кейсами и примерами использования. Материал будет полезным как для начинающих, так и для продвинутых пользователей. Желаю приятного прочтения. Kafka. Лучшие практики применения.
https://habr.com/ru/articles/853652/
#kafka #кафка #kafka_consumer #producer/consumer #producer #consumer #kafkaconnect #kafka_listener #kafka_apache #kafka_connect
-
Kafka. Лучшие практики применения. Настройки Prudcer & Consumer
Привет, Хабр! Меня зовут Михаил, я являюсь ФинТех системным аналитиком, исполняющим роль архитектора на проектах. И сегодня я хочу поделиться материалами по Kafka, которые подготовил для обучения сотрудников из своей команды. В материале постарался отразить самые важные технические моменты по Kafka, которые будут подкреплены наглядными кейсами и примерами использования. Материал будет полезным как для начинающих, так и для продвинутых пользователей. Желаю приятного прочтения. Kafka. Лучшие практики применения.
https://habr.com/ru/articles/853652/
#kafka #кафка #kafka_consumer #producer/consumer #producer #consumer #kafkaconnect #kafka_listener #kafka_apache #kafka_connect
-
Kafka как хранилище справочников
Хочу поделиться тем, как мы используем kafka для организации оперативного хранилища справочной информации.
-
Kafka как хранилище справочников
Хочу поделиться тем, как мы используем kafka для организации оперативного хранилища справочной информации.
-
Kafka как хранилище справочников
Хочу поделиться тем, как мы используем kafka для организации оперативного хранилища справочной информации.
-
Пишем свой Http Kafka Sink Connector
В данной статье приведу реализацию своего kafka http sink connector. Он не претендует на универсальность, но возможно поможет разобраться как разработать свой connector.
-
Пишем свой Http Kafka Sink Connector
В данной статье приведу реализацию своего kafka http sink connector. Он не претендует на универсальность, но возможно поможет разобраться как разработать свой connector.
-
Пишем свой Http Kafka Sink Connector
В данной статье приведу реализацию своего kafka http sink connector. Он не претендует на универсальность, но возможно поможет разобраться как разработать свой connector.
-
Seamless data exchange with Kafka Connect and Strimzi on Kubernetes at Decathlon https://medium.com/decathlondigital/seamless-data-exchange-with-kafka-connect-and-strimzi-on-kubernetes-at-decathlon-e6f81d034535
#kafka #kafkaconnect #cdc #kubernetes #decathlon -
Seamless data exchange with Kafka Connect and Strimzi on Kubernetes at Decathlon https://medium.com/decathlondigital/seamless-data-exchange-with-kafka-connect-and-strimzi-on-kubernetes-at-decathlon-e6f81d034535
#kafka #kafkaconnect #cdc #kubernetes #decathlon -
Seamless data exchange with Kafka Connect and Strimzi on Kubernetes at Decathlon https://medium.com/decathlondigital/seamless-data-exchange-with-kafka-connect-and-strimzi-on-kubernetes-at-decathlon-e6f81d034535
#kafka #kafkaconnect #cdc #kubernetes #decathlon -
Seamless data exchange with Kafka Connect and Strimzi on Kubernetes at Decathlon https://medium.com/decathlondigital/seamless-data-exchange-with-kafka-connect-and-strimzi-on-kubernetes-at-decathlon-e6f81d034535
#kafka #kafkaconnect #cdc #kubernetes #decathlon -
Seamless data exchange with Kafka Connect and Strimzi on Kubernetes at Decathlon https://medium.com/decathlondigital/seamless-data-exchange-with-kafka-connect-and-strimzi-on-kubernetes-at-decathlon-e6f81d034535
#kafka #kafkaconnect #cdc #kubernetes #decathlon -
Also, we should use kcctl to manage our #KafkaConnect objects. Even if I love curl and jq, a user friendly tool designed for this specific need will definitely make our life easier.
-
Also, we should use kcctl to manage our #KafkaConnect objects. Even if I love curl and jq, a user friendly tool designed for this specific need will definitely make our life easier.
-
Also, we should use kcctl to manage our #KafkaConnect objects. Even if I love curl and jq, a user friendly tool designed for this specific need will definitely make our life easier.
-
Also, we should use kcctl to manage our #KafkaConnect objects. Even if I love curl and jq, a user friendly tool designed for this specific need will definitely make our life easier.
-
📚 Translating #ApacheKafka messages from JSON to AVRO allows you to use #KafkaConnect sink connectors which require a schema, like the JDBC one.
📽️ Check how to convert messages with #ApacheFlink https://www.youtube.com/watch?v=FED4u6er9DE
-
📚 Translating #ApacheKafka messages from JSON to AVRO allows you to use #KafkaConnect sink connectors which require a schema, like the JDBC one.
📽️ Check how to convert messages with #ApacheFlink https://www.youtube.com/watch?v=FED4u6er9DE
-
📚 Translating #ApacheKafka messages from JSON to AVRO allows you to use #KafkaConnect sink connectors which require a schema, like the JDBC one.
📽️ Check how to convert messages with #ApacheFlink https://www.youtube.com/watch?v=FED4u6er9DE