Spark Connect — это, пожалуй, самая ожидаемая фича Apache Spark 3.4.0. Она была анонсирована на конференции Data+AI Summit 2022 и сейчас широко освещается в социальных сетях. Вот и я решил приобщиться и внести свой небольшой вклад в это дело, продемонстрировав вам несколько интересных деталей реализации.
В предыдущей статье про микросервисную архитектуру на основе событий с использованием Kafka Streams достаточно поверхностно был упомянут io.confluent.connect.jdbc.JdbcSourceConnector, который использовался для вычитания данных из SQLite и отправки их в топик Kafka. Сейчас я бы хотел более подробно разобрать технологию Kafka Connect на примере io.debezium.connector.postgresql.PostgresConnector. Как и в прошлый раз, я реализовал небольшой демо проект, код которого доступен на GitHub. В проекте кода совсем немного, однако чтобы понять все настройки, примененные в коннекторе, придется достаточно подробно пройтись по теоретической части. Итак, приступим.
Всем привет!
Сегодня поговорим о немного нетипичной для меня теме, а именно — Apache Superset. Обычно я пишу длинные «философские» статьи «на свободную тему», но в этот раз — это будет туториал. Так что кому‑то может показаться банальностью, но, опять таки, вдруг кому поможет. Почему‑то именно по суперсету на Хабре оскорбительно мало материалов. Да, у него в целом неплохая документация, но она все же — документация, поэтому в меру сухая, в ней нет дополнительных объяснений, примеров. Попробуем хоть немного исправить эту ситуацию.
Apache Spark — это фреймворк для обработки и анализа данных, который позволяет выполнять операции на вычислительных кластерах и поддерживает несколько языков программирования: Scala, Java, Python, R и SQL.
В статье рассмотрим основные понятия для понимания обработки данных на Spark, разберем функционал его компонентов и сформируем DataFrame разными способами.
Рассказываем историю о том, как калькулятор скидок в составе кассового ПО стал CDP-платформой с аналитическим модулем, управляемым с минимальным участием разработчиков.
Всем привет! Это моя первая статья на Habr, так что не судите строго за стиль, а вот по содержанию буду рад любой конструктивной критике.
Статья основана на публикациях Confluent о том, как можно реализовать микросервисную архитектуру на основе событий с помощью Kafka Streams и KSQL.
Поднимаем BI Apache Superset в 2023 году - полный гайд с последними обновлениями и полезными настройками самого BI после установки.
Привет! Столкнулся с тем, что быстро не нашел простой инструкции, как с использованием SSL и SASL настроить безопасный кластер из нескольких Linux узлов Zookeeper, и решил это исправить.
В этой статье поговорим о том, как:
• Настроить Zookeeper в кластере из трех узлов без шифрования (Plain);
• Добавить шифрование во внутрикластерное взаимодействие (Quorum TLS);
• Создать сертификаты для подключения к узлам Zookeeper клиентов (Server TLS);
• Создать сертификаты для подключения клиентов к узлам (Client TLS);
• Добавить авторизацию в шифрованный кластер (SASL with MD5);
• Показать на примере, как работают ACL, посмотреть, чем отличается суперпользователь super от всех остальных (как работает ACL в действии).
Kafka — это универсальный и мощный инструмент для построения конвейеров данных в реальном времени и событийно-ориентированных приложений. Перевели туториал, где рассматривается интеграция Kafka с экосистемой Spring Boot.
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’е – тот еще геморрой между нами говоря. Отметаем.
