Вместе с экспертом по работе с данными рассказываем об удобном инструменте, который помогает управлять данными и организовывать их взаимодействие между собой.
Разбираемся, что это за инструмент, какие у него есть плюсы, минусы и аналоги.
Apache ZooKeeper — это сервис, который помогает разным частям распределенной системы (серверам, приложениям, процессам) работать согласованно.
TL;DR: KIP‑1150 (Diskless Topics) предлагает Kafka писать сообщения сразу в облачное хранилище (S3 и аналоги), минуя диски брокеров. Это сильно экономит деньги и упрощает масштабирование в облаке, но увеличивает задержки и делает Kafka зависимой от облачных сервисов. Отлично для дешёвых, «толстых» потоков логов, но плохо подходит для real‑time систем с миллисекундными требованиями.
Представим себе картину из идеального мира данных, в котором всё стабильно, изменений нет и на горизонте не предвидятся. Аналитик полностью согласовал с заказчиком требования к витрине, спроектировал решение и передал в разработку. Разработчики внедрили витрину в продуктивный контур, пользователи счастливы, всё работает корректно — сопровождение разработчиков и аналитиков не требуется. Представили?
Но, как мы знаем, «IT» и «изменения» — синонимы, поэтому в идеальном мире, как гром среди ясного неба, появляются новые требования: разработать инструмент для регулярного добавления в витрину данных новых атрибутов, на текущий момент в неизвестном количестве.
Сразу отмечу, что решения и оценки, о которых пойдёт речь, подбирались для работы с большими данными на стеке технологий Apache Hadoop, где для обработки данных использовали фреймворк Apache Spark, СУБД — Apache Hive для анализа данных, оркестратор — Airflow, данные хранятся в колоночном формате Parquet.
Привет, Хабр! Меня зовут Лев Маковеев. Я младший инженер по обработке данных в компании «Криптонит». В этой статье хочу поделиться с вами результатами небольшого исследования, в ходе которого мы протестировали ускоритель запросов Apache DataFusion Comet и пришли к довольно впечатляющим результатам. Забегая вперёд, отмечу, что в отдельных тестах ускорение было более чем десятикратным!
В мире распределённых систем выбор брокера сообщений — это не просто вопрос технологии, а стратегическое решение, от которого зависит надёжность, масштабируемость и устойчивость всей архитектуры. Несмотря на популярность решений вроде 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-хранилище.
Apache Kafka является одной из самых популярных платформ для обработки потоков данных, обеспечивая высокую пропускную способность и низкие задержки при передаче сообщений. В высоконагруженных системах, где необходимо обрабатывать миллионы сообщений в секунду, важность правильной настройки Kafka трудно переоценить. Без оптимизации её параметров можно столкнуться с серьёзными проблемами, такими как рост задержек, потеря сообщений и переполнение очередей. Эффективная настройка Kafka критична для обеспечения бесперебойной работы в условиях высокой нагрузки и стабильной обработки данных в реальном времени.
Цель этой статьи — рассмотреть основные аспекты настройки Apache Kafka, которые влияют на производительность системы. Мы сосредоточимся на оптимизации параметров брокеров и продюсеров для достижения максимальной пропускной способности, минимальных задержек и надежности. Также рассмотрим важность мониторинга и тестирования системы для своевременного выявления и устранения узких мест.
Добрый день! Меня зовут Богдан, я тимлид в одном из отечественных финтехов. Сегодня я хочу поделиться нашей историей: как нам удалось, ненарочно, зашедулить падение всех нод одного из наших кластеров 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), о котором сегодня и пойдет речь.
Погнали!
Данные библиотеки можно использовать при работе со SparkOperator:
1. Создание виртуального окружения с необходимыми библиотеками
2. Создание задачи в даге и установка окружения в SparkSubmit
Фреймворк с открытым исходным кодом 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 и продолжала работать в штатном режиме. Да, без обновлений и поддержки, но благодаря этому мы смогли тщательно подойти к выбору нового решения и обеспечить плавный переход пользователей на новую платформу.
