Apache *

Буквально на секунду представьте, что у вас есть парочка здоровенных кластеров Apache Kafka, каждый из которых держит по нескольку миллионов rps. И тут вас попросили зеркалировать топик из одного кластера в другой. Максимально близко к реалтайму, да ещё и с некоторыми специфическими условиями. Если стало страшно, интересно или страшно интересно, то это статья для вас.

Под катом я расскажу, что такое зеркалирование и зачем оно нужно. Как нам перестало хватать Mirror Maker’а. Поговорим о возможных решениях и выборе между ними. И дам подробную инструкцию, как вам развернуть такое решение у себя.

Данная статья является продолжением статьи - Ивентная модель данных с использованием Kafka и Kafka Connect: Построение гибкой и распределенной архитектуры.

Добро пожаловать во вторую часть статьи о построении гибкой и распределенной архитектуры с использованием Apache Kafka и Kafka Connect! В первой части мы ознакомились с ивентной моделью данных, разработали сервис отправителя и настроили интеграцию с Kafka, чтобы асинхронно отправлять сообщения. Теперь настало время рассмотреть вторую часть этого увлекательного проекта.

Apache Kafka — распределенный программный брокер сообщений с открытым исходным кодом. Его ключевая задача заключается в сборе данных у приложений и их хранении в распределенном хранилище. Сегодня обсудим литературу, которая поможет разобраться в его работе и понять, какую роль он играет в проектах, связанных с большими данными.  

Представляем вашему вниманию избранную подборку новых высокооцененных книг для начинающих и опытных специалистов.

Есть простая, можно сказать, типовая – задача, передать данные из системы «А» в систему «Б». А – классическая legacy-трехзвенка из 00х с IIS-MSSQL, «Б» - новая-нулевая-микросервисная с внутренней шиной на apache kafka и собственным ETL на Apache NiFi, развернута в k8s. Направление передачи – из «А» в «Б», по расписанию , в общем ничего сложного – «Работенка на 5 минут»: идем в NiFi делаем QueryDatabaseTable->PublishKafkaRecord и продолжаем спать – но тут начинаются «Нюансы»(ТМ) в виде ИБ, которая говорит, что прямая интеграция корпоративных систем – харам, архитектуры которой (дикие люди!) не нравится хождение в чужую БД (Подержи моё пиво! Я сто раз так делал!) и прочих скучных регламентов, требующих «наличия аутентификации», «направления установления соединения совпадающего с направлением передачи» и тому подобных глупостей.

И вот тут на сцену выходит корпоративная интеграционная шина – (low|no)-code решение, которое умеет в расписания, подключение к ИС по различным протоколам (в том числе и *dbc), передачу данных с помощью REST\SOAP, аутентификацию, обработку ошибок, алертинг и кучу других вещей. Оооок, шина по расписанию будет ходить в БэДэ (Или не БэДэ – там уже видно будет), забирать данные и передавать… А куда, собственно, передавать?

Первый вариант – «в kafka’у!» хорош примерно всем – кроме реализации. Собственно, бинарный протокол kafka’и шина не умеет, ИБ не умеет в инспекцию этого самого протокола, ingress-nginx контроллер не умеет (Нормально – не умеет, ssl-passthrough в данном случае не очень-то «нормально») в публикацию kafka’и, а согласовывать с ИБ публикацию брокеров через LB – удачи, пацаны. Плюс нормальная аутентификация\авторизация на kafka’е – тот еще геморрой между нами говоря. Отметаем.

Вряд ли можно поспорить сегодня с аргументом, что скорость и эффективность обработки информации стали ключевыми факторами успеха любого цифрового проекта. При этом традиционные подходы к хранению и обработке данных уже не могут удовлетворить растущие потребности бизнеса и пользователей. Именно в этот момент на сцену выходит Apache Ignite — высокопроизводительная, распределенная платформа для вычислений в памяти. Рассказывает Александр Столяров, ведущий программист компании Comindware.

Всем привет, меня зовут Алексей, являюсь IT‑инженером в одной из крупных компаний. Иногда включаю внутреннего авантюриста и ищу что‑то редкое и очень интересное.И в данной статье хочу поделиться стеком, который имеет право на жизнь.

Да и надеюсь, что информация для кого‑то будет интересна, как и для меня.

Если бы я раньше нашел такой туториал — быстрее бы разобрался со всеми нюансами.

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

Команда разработчиков Trendyol Tech видоизменила архитектуру и решила эту проблему с помощью outbox-шаблона, но столкнулась с другой проблемой — дублированием событий. Приводим перевод статьи о том, как разработчики залезли под капот Kafka и нашли решение этих двух проблем.

Всем привет!

В этой статье рассмотрим применение библиотеки Apache Flink ML для построения конвейеров машинного обучения. Затем реализуем простой проект по прогнозированию поведения системы, а также ответим на вопросы: какие задачи Machine Learning подходят для Flink и какие особенности Flink делают его подходящим для использования в задачах Machine Learning.

Статья является продолжением предыдущей статьи в рамках цикла статей, посвященных обработке больших и очень больших графов. В статье реализованы распределенные версии четырех классических алгоритмов: "Связные компоненты", "Кратчайшее расстояние", "Топологическая сортировка" и PageRank на Apache Spark DataFrame API. Алгоритмы составлены в соответствии с идеями популярного фреймворка распределенной обработки графов Pregel.

Как Redpanda и Materialize — продукты, не основанные на JVM — делают потоковую обработку доступной для широких масс за счет снижения операционных издержек? Обсудим в статье.

Databricks — это аналитическая платформа для облачных вычислений, работы с большими данными и машинного обучения. Компания разрабатывает data lake и работает с фреймворком Apache Spark. Приводим перевод статьи Databricks о нововведениях Apache Spark 3.4, который вошел в релиз Databricks Runtime 13.0.

Переносимость процессоров и паттерны

Вот и обещанная третья часть саги о том, что в NiFi можно делать и как это делать правильно, без претензий на истину в последней инстанции, конечно. Сегодня расскажу о переносимости процессоров и дам несколько паттернов для самых популярных задач на платформе ZIIoT. Если вдруг вам интересно почитать про оптимизацию схем и производительности в NiFi — велком в первую часть. Если мечтаете узнать больше о мониторинге, то вторая часть — must read. Только потом сюда не забудьте вернуться.

Привет, Хабр! В наше время при постоянном росте объемов данных и необходимостью более быстрой и надежной обработки информации, мы сталкиваемся с требованием к эффективному обмену и синхронизации данных между различными системами. Отслеживание и обработка данных в реальном времени стало жизненно необходимым для современных приложений.

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

Построим гибкую и масштабируемую архитектуру, которая позволит нам забыть о проблемах связанных с несогласованными данными и наслаждаться мгновенным доступом к актуальной информации для наших бизнес-процессов.

Apache Kafka является ключевым продуктом не только для преобразования сообщений, но и при обработке данных в реальном времени, а также для многих других случаев использования. Архитектуры, размещенные в облаке, утверждают, что они безопасны с точки зрения коммуникации и обеспечения общей безопасности. Но когда дело доходит до частого взаимодействия клиента/потребителя с сервером/производителем, Kafka обеспечивает встроенную поддержку SSL, а также пользовательскую аутентификацию. В этой статье мы шаг за шагом настроим такой механизм аутентификации.

В этой статье я расскажу, как, используя недокументированные возможности фреймворка Apache Spark, качественно подобрать гиперпараметры для модели градиентного бустинга всего за один человеко-день вместо обычных пяти.

При реализации потоковой обработки и анализа данных может возникнуть необходимость агрегирования записей для объединения нескольких независимых поток данных или обогащения какой-либо модели данных. Для этой цели может использоваться Kafka Streams, которая позволяет выполнять обработку данных в режиме реального времени. 

В этой статье мы рассмотрим основные компоненты Kafka Streams и теоретические аспекты их использования. Мы будем использовать последние версии технологий, доступных на сегодня: Kafka 3.4.0 и Java 17 в качестве языка программированию. Для снижения входного порога мы будем использовать только нативные возможности Kafka и Kafka Streams, и не будем рассматривать решения с использованием различных фреймворков вроде Spring.

Apache Flink является популярным фреймворком для обработки больших данных и аналитики в режиме реального времени. Одним из ключевых компонентов этого фреймворка является Table API, который предоставляет удобный и выразительный способ работы с данными в формате таблиц, аналогичный SQL.

Если вы разработчик, который хочет узнать больше о том, как использовать Apache Flink Table API для обработки потоковых данных, или если вы интересуетесь современными инструментами аналитики данных, эта статья для вас.