Apache *

Мониторинг 

Продолжаем разговор о том, что в NiFi делать можно и нужно, а что можно, но лучше не стоит. Если вы пропустили первую часть разговора, то вам сюда. Там про улучшение читаемости схем и повышение производительности (ну почти). Здесь же пойдет речь о том, как проводить мониторинг бизнес-части схемы, чтобы всем было хорошо (ну или чтобы не было плохо), ну и немного о переносимости процессоров. Поехали!

Есть мнение, что хуже всего — не вести мониторинг бизнес-части схемы совсем, используя популярный подход «и так сойдет!». Но если подумать, есть одна вещь хуже отсутствия мониторинга — неправильный мониторинг.

Привет! Меня зовут Алексей Карпов, я DevOps-инженер (MLOps) отдела ML разработки в OKKO. Хочу поделиться опытом в работе с Apache Airflow в связке с Kubernetes. Расскажу, как установить Airflow в Kubernetes, настроить автоматическую синхронизацию DAG'ов с удалённым репозиторием, а также как отладить его работу. Всё это — на примере запуска простейшего DAGа. 

Появилась у нас тут задачка, вывести на портале Incomand данные из разных подсистем (1С, Тезис…) . Конечно можно было бы написать плагины, каждый из которых слазил бы в подсистему, получил данные и показал их на портале - НО - мы бы получили p2p и спагетти, порталу пришлось бы разбираться с форматами и протоколами работы каждой системы….

В этой статье продемонстрирую и объясню работу Kafka, используя как можно меньше определений и больше практики. Мы рассмотрим 3 сценария работы с Kafka. Для последнего сценария мы поднимем Kafka Cluster в Docker и с помощью UI увидим, как происходит общение между сервисами.

Привет! Меня зовут Глеб Гончаров, и я руковожу подгруппой ИТ-инфраструктуры в СберМаркете. В работе мы широко используем Kafka как шину данных для микросервисов и не раз убедились на практике, что к инструменту важно подобрать правильный подход. Об этом сегодня и поговорим в двух частях — сначала обсудим основы, а в конце статьи будет ссылка на практические задания.

1. В монолите концентрировалось большое количество бизнес-процессов, которые охватывали сразу несколько потребителей: пользователей облачной платформы, сейлз-менеджеров (через CRM-систему), администраторов, обработчиков метрик. Получилась такая одна большая точка отказа сразу для 4 групп бизнес-процессов.
2. Каждый бизнес-процесс потребляет свой объем ресурсов. Например, для обработки метрик нужно 5 подов (чтобы запараллелить и ускорить обработку), для администрирования хватит и одного. Так как у нас все в одном сервисе, при масштабировании монолита мы будем ориентироваться на самый «прожорливый» бизнес-процесс. Часть ресурсов будет просто простаивать.
3. Хотелось добиться гранулярности, чтобы независимо писать и деплоить код для каждого бизнес-процесса. И не переживать, что какие-то изменения в одном бизнес-процессе неожиданно отрикошетят в соседний.

Меня зовут Вадим Опольский и я работаю data-инженером и участвую в проведении онлайн-тренингов. В статье есть ссылки на воркшопы, чтобы повторить практические вещи из Apache Flink, о которых я расскажу. А обсудим мы следующие проблемы:

➜ Неравномерный поток данных;

➜ Потери данных при передаче их из Kafka в storage;

➜ Масштабирование и скейлинг;

➜ Backpressure;

➜ Мелкие файлы на HDFS;

➜ Стриминговый процессинг.

Эта статья посвящена особенностям доработок в Apache Superset, и в ней я расскажу, как его можно использовать для визуализации больших объемов данных в рамках сводных таблиц.

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

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

В статье мы будем говорить о встроенных в Kafka механизмах защиты и не будем касаться использования каких-либо наложенных средств.

Мы в #CloudMTS разделяем мнение, что важно объяснять своим детям устройство различных цифровых технологий. Но пытались ли вы когда-нибудь рассказать ребенку о, например, Apache Kafka as a Service? Ответ на вопрос, «чем занимается папа/мама?» может оказаться гораздо сложнее, чем хрестоматийное «почему небо голубое, солнце желтое, а трава зеленая?».

Поэтому не удивительно, что однажды мы решили собрать вместе несколько ресурсов, которые помогут нашим (и вашим) детям узнать больше об ИТ.  Кроме того, умение объяснить доступным языком, как работает та или иная технология, помогает лучше разобраться в вопросе. Такой навык пригодится, если приходится часто взаимодействовать с не техническим персоналом — например, бухгалтерами или маркетологами.

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

Для запуска Kafka можно использовать решения для управления кластером, такие как ZooKeeper или KRaft. В статье мы рассмотрим работу с ZooKeeper. Zookeper это распределенное приложение для управления кластером, состоящим из большого количества узлов.

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

Apache Kafka — это фреймворк, реализующий программную шину, использующую потоковую обработку. Это программная платформа с открытым исходным кодом, разработанная Apache Software Foundation и написанная на Scala и Java. Проект направлен на предоставление унифицированной платформы с высокой пропускной способностью и малой задержкой для обработки потоков данных в реальном времени.
Иными же словами распределенная система обмена сообщениями между серверными приложениями в режиме реального времени.

Эта установка Kafka использует проект ранней версии под названием Apache Kafka Raft (KRaft). Это проект, в котором устранена зависимость от ZooKeeper.

Если вы используете в своей работе NiFi, то наверняка не раз задумывались об оптимизации, а может быть и делали ее. В этом посте я поделюсь своими наработками в области настроек NiFi, благодаря которым мы получили позитивные результаты и улучшили работу наших собственных сервисов. А если конкретно, речь пойдет про выбор стратегии балансировки нагрузки между нодами кластера (load balancing), настройке работы процессоров NiFi в рамках одной ноды (Concurrent tasks, Run Duration), а также о том, что делать с косяками Merge Record. Если интересно, ныряйте под кат и давайте обсудим, что еще хорошего можно сделать с NiFi. 

Apache Kafka де-факто превратился в стандарт потоковой передачи событий для обработки данных на лету. По мере его широкого распространения в отрасли появляются вопросы: «А когда НЕ нужно использовать Apache Kafka? Какие ограничения у этой платформы? В каких ситуациях он не предлагает необходимые возможности? Как понять, что Kafka — неподходящий инструмент для какой-то задачи?»

В статье, перевод которой мы подготовили, автор Kai Waehner постарается ответить на эти вопросы. В отдельных главах приводится объяснение, когда стоит использовать Kafka, когда — нет, а когда — возможно.

- Вы работали с Кафкой?
- Нет, только читали.

За несколько десятилетий развития ИТ систем разработчики накопили огромный опыт хранения и обработки данных. Различные СУБД позволяют с помощью запросов извлекать нужные данные за определенный период и обрабатывать их так как необходимо. Однако, со временем увеличились вычислительные мощности серверов, пропускная способность каналов связи, и соответственно, возникла необходимость обрабатывать бОльшие объемы данных за единицу времени. И тут выяснилось, что при всем многообразии различных решений для хранения данных, отсутствуют решения для обработки непрерывных потоков больших объемов данных. Для решения этой проблемы стали появляться различные системы, такие как системы обмена сообщениями и агрегирования журналов. Но они не могли в полной мере обеспечить нужную производительность на больших, непрерывных потоках данных.

Для решения этой проблемы в LinkedIn решили создать нужное решение что называется с нуля. Разработчики решили отказаться от хранения больших объемов данных, как в реляционных базах данных, хранилищ пар «ключ/значение», поисковых индексов или кэшей, а рассматривать данные как непрерывно развивающийся и постоянно растущий поток и проектировать информационные системы и архитектуру данных — на этой основе. Так появилось решение Apache Kafka, которое изначально использовалось для обеспечения функционирования работающих в реальном масштабе времени приложений и потоков данных социальной сети. Но сейчас это решение используется во многих крупных компаниях. Посмотрим подробнее как оно устроено.

Apache NlpCraft - библиотека с открытым исходным кодом, предназначенная для интеграции языкового интерфейса с пользовательскими приложениями. Новая версия 1.0.0 привнесла в проект наиболее существенные изменения за все время его существования. 

Основные идеи развития библиотеки были изложены в данной заметке, вкратце напомню их суть:

1. Предельное упрощение, отказ от всех вспомогательных enterprise возможностей, предельно точная фокусировка продукта.

2. Максимальная  плагабильность, позволяющая контролировать все элементы обработки текста и как следствие, решающая проблему поддержки мультиязычности.

Привет, Хабр! Я занимаюсь инженерией данных в Х5 Tech. В этой статье я решил поделиться проблемами, с которыми столкнулись при распараллеливании CatBoost на Spark, и как мы нашли решение. Возможно, это не rocket science, но если бы со мной поделились такими ответами заранее, я бы сэкономил себе пару вечеров свободного времени.