Apache Kafka – это платформа для обработки потоков данных в реальном времени, которая позволяет эффективно передавать и обрабатывать огромные объемы данных. Не погруженным в технологию пользователям сложно настраивать и осуществлять мониторинг Kafka без специализированных инструментов с графическим интерфейсом.
В этой статье мы поделимся опытом внедрения такого инструмента и расскажем про CMAK.
Бывало у вас так, что некоторые аналитики запрашивают побольше вычислительных ядер и оперативной памяти для своих Jupyter-ноутбуков, а у вас в это время ничего не работает? У меня бывало, ведь недостаточно уметь разрабатывать код на Spark — еще нужно уметь его настраивать, правильно инициализировать сеансы работы и эффективно управлять доступом к вычислительным ресурсам. Если отдать настройку на волю случая, Spark может (и будет) потреблять ресурсы всего кластера, а другие приложения будут стоять в очереди.
Меня зовут Владислав, я работаю Дата инженером в Альфа-Банке, и в этой статье мы поговорим о том, как правильно подобрать необходимое количество параметров и не положить кластер на коленочки.
Приветствую!
На пути инженера данных часто встречаются задачи связанные с DevOps. Одна из таких - развернуть Airflow в Kubernetes кластере. Если до этого похожего опыта работы не было, то эта задача может показаться нетривиальной. Конечно, можно выполнить несколько команд из официального гайда, но если нужно будет что-то поправить, то без понимания, что происходит внутри, обойтись будет сложно.
Эта статья призвана облегчить данную задачу. Она поможет тем, кто уже работал с Airflow, но еще не касался технологии Kubernetes.
Всем привет! Я Алексей Пономаревский, разработчик решений для платформ сбора и обработки больших данных.
Два года назад мы в ITSumma создали решение для потоковой обработки данных с помощью Apache Spark и базы данных Greenplum — spark-greenplum-connector. Это многофункциональный плагин для Spark, на его основе инженеры могут строить ETL-решения и анализировать данные in-memory.
Изначально мы разработали его, как часть клиентской платформы потоковой обработки данных. Но со временем он прирос одной интересной функциональностью, которая недоступна сейчас в других подобных решениях. В этой статья я хочу сделать краткое сравнение между двумя opensource-продуктами Apache Spark и Flink, а также рассказать об одной интересной особенности Spark, которую мы реализовали в коннекторе.
Задача — настроить безпопасное соединение (ssl, которое сейчас tls) к вашему хосту, на котором работает apache2. Самоподписанные сертификаты нам не подходят, так как требуется чтобы с нашим сайтом работали интернет магазины. Они самоподписанным сертификатам не доверяют.
Иногда возникает необходимость в переносе сайта, обслуживаемого веб-сервером Apache, на новый домен. Снизить издержки такого переноса помогает настройка перенаправления HTTP-запросов к старому домену на новый.
Решение, описанное в этой статье:
• перенаправляет HTTP-запросы с домена old.com и всех его поддоменов на домен new.com и соответствующие его поддомены;
• исключает префикс www. путём перенаправления HTTP-запросов с доменов www.*.new.com на *.new.com;
• может использоваться для преобразования HTTP-запросов в HTTPS-запросы.
Буквально на секунду представьте, что у вас есть парочка здоровенных кластеров 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.
