Apache *

В мире распределённых систем выбор брокера сообщений — это не просто вопрос технологии, а стратегическое решение, от которого зависит надёжность, масштабируемость и устойчивость всей архитектуры. Несмотря на популярность решений вроде Apache Kafka и Amazon SQS, их выбор часто бывает продиктован модой или привычкой, а не реальными потребностями приложения. 

В этой статье подробно разберём ключевые отличия между потоковыми и очередными брокерами, особенности их масштабирования, работы с ошибками и поддержки разных паттернов обмена сообщениями — от команд до передачи состояния.

Статья рассматривает внедрение Open Policy Agent (OPA) для управления авторизацией в кластерах Apache Kafka на bare metal‑серверах.

В рамках статьи проанализированы ограничения стандартных ACL и предложено решение на основе Open Policy Agent (OPA), обеспечивающее декларативное управление доступом через Policy as Code (PaaC). Особое внимание уделено обновлению OPA Kafka Plugin: создан pull request, в котором устранены уязвимости привносимые в OPA библиотекой Guava и реализован переход на более производительную библиотеку Caffeine. Описан процесс интеграции OPA с Kafka, включая автоматизацию доставки политик через Bundle API и S3-хранилище.

«Миллионы сообщений в секунду» - величина, лишённая смысла без профиля нагрузки: кластер, прокачивающий 2 млн сообщений по 200 байт, и кластер на 50 тыс. сообщений по 100 КБ упираются в совершенно разные ресурсы. Прежде чем крутить параметры, зафиксируйте средний и максимальный размер сообщения, целевой объём в МБ/с, требуемый p99 end-to-end и допустимость потерь. Без этих четырёх чисел настройка превращается в угадывание.

Вторая частая причина неудачного тюнинга - перенос советов из статей 2016–2020 годов: с тех пор сменились дефолты acks, session.timeout.ms, replica.lag.time.max.ms и режим работы кластера целиком. Все значения ниже приводятся для Kafka 3.x-4.x, и там, где дефолт менялся, это отмечено по месту.

За рамками сознательно оставлены Kafka Streams, Kafka Connect, Schema Registry и мультирегиональные развёртывания.

Добрый день! Меня зовут Богдан, я тимлид в одном из отечественных финтехов. Сегодня я хочу поделиться нашей историей: как нам удалось, ненарочно, зашедулить падение всех нод одного из наших кластеров Kafka.

В один из холодных февральских дней пришло сообщение от мониторинга с виртуальных машин кластера Kafka: «Свободное дисковое пространство достигло значения < 15%». Было решено исследовать, нужно ли добавлять дискового пространства или же можно потюнить настройки ретеншена данных.

Тут стоит немного вспомнить теорию. Как известно, в Kafka сообщения распределяются по партициям, а каждая партиция на брокере представлена набором сегментов. Число сегментов у партиций может быть разным — оно варьируется в зависимости от интенсивности записи и настроек размера сегмента.

Сегмент (если упростить) — это лог-файл, в который просто пишутся данные в конец. По достижении временного предела либо его размера он ротируется: создается новый сегмент, и запись идет уже в него.

Держа вышесказанное в голове, мы отправились смотреть настройки хранения сегментов в нашем кластере Kafka..

В этой статье мы рассмотрим, какие методы передачи пароля через интернет наиболее безопасны. Хэширование паролей или протокол TLS — что выбрать для защиты данных? Разберемся, как работают эти технологии и какие риски скрываются за каждой из них.

Столкнулся с небольшим и интересным моментом: внедрение переменных окружения (а ля environment variables) в стандартный микросервис написанный на Java (классика жанра – Spring Boot).

Автор статьи Якушков Федор.

Apache Kafka — это мощная распределённая платформа для обработки потоков данных, которая завоевала популярность благодаря своей способности эффективно управлять большими объёмами информации в реальном времени. В этой статье мы подробно разберём, как использовать Kafka в языке программирования Go с помощью библиотеки kafka-go. Мы рассмотрим все ключевые аспекты: от event-driven архитектуры до топиков и партиций, от создания продюсеров и консьюмеров до управления оффсетами и обработки ошибок. Разберем гарантии доставки, а также обсудим, где и как применять Kafka в проектах.

Меня зовут Роман Ремизов. Я — системный аналитик ГК Юзтех. В рамках цикла статей «Хроники архитектурного дизайна» я делюсь своей экспертизой о разных автоматизированных банковских системах (АБС) и рассказываю, что нужно знать перед тем, как приступить к архитектурному дизайну.

Данная статья, как и первая из этого цикла, написана с допустимым уровнем конкретики. И ещё, стоит помнить, что все банки разные и на других проектах могут преобладать иные архитектурные решения.

В этой статье мы обсудим такую интересную тему, как использование шаблонов гарантированной доставки.

Пишите вы себе EDA на основе Apache Kafka, и ваши сервисы тщательно логируют все свои действия, процесс отлажен и работает годами. Вдруг один из сервисов отчитался в логах, что отправил событие в брокер, но другой по какой-то его не прочитал. Как понять, кто виноват?

Как правило, брокер сообщений между сервисами – черная коробка, которая работает, что называется «As Is». Разработчики подключают зависимости, вешают аннотации консюмеров и продюсеров, оно заводится и все рады. Но что они там подключили и как это работает никто не видит.

Так давайте же посмотрим, как мы можем открыть этот чёрный ящик на примере наиболее популярных брокеров сообщений.

Всем привет! Меня зовут Макс. Я Lead Backend в компании ИдаПроджект и автор YouTube-канала PyLounge.

Любой крупный проект так или иначе используют брокеры сообщений — и чаще всего это Apache Kafka. Так что уметь взаимодействовать с Kafka (хотя бы на базовом уровне) будет полезно как разработчику, так и тестировщику или аналитику. 

Я в своей работе практически ежедневно взаимодействую с кафкой, поэтому решил поделиться опытом. В команде мы используем графический интерфейс Offset Explorer (далее OE), о котором сегодня и пойдет речь.

Погнали!

Фреймворк с открытым исходным кодом Apache Spark, входящий в экосистему проектов Apache Hadoop, используется для реализации распределённой обработки данных. Для работы в Spark могут использоваться различные языки программирования: Scala, Java, Python и R.

В рамках данной статьи мы не будем рассуждать о преимуществах использования того или иного языка, на эту тему достаточно публикаций. Мы рассмотрим PySpark — фреймворк с открытым исходным кодом, построенный на базе Apache Spark и предназначенный для упрощения и ускорения решения масштабных задач обработки данных и аналитики. PySpark предлагает высокоуровневый API для языка программирования Python, что позволяет легко интегрироваться с существующими экосистемами Python.

Но для начала рассмотрим архитектуру Apache Spark.

Я хочу рассказать, как мы решаем задачи миграции данных кластеров Cassandra с помощью инструмента Cassandra Data Migrator (CDM). Выбор этой темы продиктован продуктовыми задачами по корректной миграции данных между кластерами Cassandra сложной топологии. Статей с обзором этого решения в русскоязычном сегменте я не нашел и решил описать сам, так как оно будет полезно всем администраторам СУБД Cassandra.

Привет! Меня зовут Виталий Флёрин, я руководитель отдела BI-аналитики в M2. За год мы успешно перевели всю отчетность компании с Cognos Analytics на Apache Superset и увеличили MAU до 200 (каждый третий сотрудник компании). В статье хочу поделиться опытом внедрения новой системы отчетности и ее эффективного использования.

Материал будет полезен BI-специалистам, кто работает над развитием внутренних систем и хочет переехать на Superset.

История началась с того, что после ухода Cognos Analytics с российского рынка, нам нужно было выбрать новую BI для компании и мигрировать всю отчетность. Текущая система была развернута on-premises и продолжала работать в штатном режиме. Да, без обновлений и поддержки, но благодаря этому мы смогли тщательно подойти к выбору нового решения и обеспечить плавный переход пользователей на новую платформу.

Идея написания этого небольшого руководства появилась у меня, когда я начал изучать одну из самых популярных библиотек для работы с Apache Kafka - modern-cpp-kafka.

Однако, как водится, ничто не идеально, и порой приходиться делать самые простые вещи за библиотеку.

В статье расскажу, как настроить мониторинг Apache NiFi и алерты при переполнении очереди по достижении 8000 FlowFiles.

Зачем вам читать эту статью? Переполнение очереди FlowFiles в Apache NiFi может привести к замедлению или остановке обработки данных, мониторинг позволит своевременно среагировать на проблемы с производительностью и выявить узкие места.

Что делает инженер, если DAG не выполняется? Проверяет Airflow 50 раз, а потом вспоминает, что забыл поставить @dag над функцией.

Развертывание Apache Airflow в промышленной среде — это сложная задача, требующая учета множества аспектов: от обеспечения безопасности конфиденциальных данных до эффективного управления ресурсами. Одной из ключевых проблем, с которыми сталкиваются команды, является безопасное управление секретами, оптимизация конфигураций и наблюдаемость.

В этой статье мы рассмотрим, как использовать инструменты, такие как Sops и YAML-якоря, для упрощения управления конфиденциальными данными и улучшения читаемости конфигураций. А так же как обеспечить полную наблюдаемость инсталляции Apache Airflow.

В 2024 году мы не дождались выхода в свет Apache Kafka 4.0, в которой окончательно исчезнет поддержка ZooKeeper, оставив нам для создания кластеров только KRaft. Кто-то давно уже перешёл на эту прекрасную технологию, другие же размышляют, как им жить дальше — оставаться на линейке 3.х или в омут с головой.

Новогодние каникулы самое подходящее время для того, чтобы пощупать новую версию. Хотя код невозбранно доступен в Github проекта Apache Kafka, docker-образов текущих сборок 4.0 мне найти не удалось. Также поддержку 4.0 ещё не добавили в довольно популярный, и с недавних пор мною любимый, k8s-оператор strimzi. Ну что же, придётся устроить себе праздник самому!

Это моя финальная часть(ну пока что ;)) серии статей про Kafka Streams, прошлые статьи тут [ноль, один, два, три] Теперь давайте разработаем приложение, которое считывает: cобытия о пульсе из топика pulse-events.

Однажды в студеную зимнюю пору из-за морей, из-за океанов прилетело известие: лицензии не выдаем, тех.поддержку не оказываем, а можем и вовсе отключить все системы. В компании погоревали, но делать нечего, решили переходить на новые системы, да такие, чтобы не смогли в любой момент их превратить в тыкву. И стали смотреть в сторону open-sourсe решений. Проанализировали несколько BI-систем и остановились на SuperSet.  /*После QlikSense и Tableau казалось, что это так себе затея*/

Меня зовут Корнева Настя, я отвечаю за разработку BI-отчетности в Magnit Tech в рамках проекта Аналитика УЦП (управление цепочками поставок). В этой статье поделюсь нашим опытом создания динамических сводных таблиц в BI-инструменте SuperSet, что будет полезно разработчикам отчетности и всем, кому интересна тематика.