Apache *

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

Однако, при серьезном использовании любой системы рано или поздно возникает необходимость в гибкой настройке. А необходимость в отладке как правило возникает гораздо раньше. Apache Spark в этом плане не является исключением и в этой статье мы поговорим о механизмах настройки Spark и некоторых параметрах, которые пользователям может понадобиться отрегулировать под свои нужды. Также мы рассмотрим механизмы журналирования.

Apache Superset всё чаще становится выбором для визуализации данных благодаря открытому коду. Но, увы, столкнувшись с его ограничениями и тонкостями, даже самые опытные пользователи могут столкнуться с трудностями. Есть много ограничений, которые требуют обращения за доработками к разработчикам, но с помощью шаблона Handlebars в сочетании с шаблонизацией jinja некоторые трудности можно обойти.

С его помощью можно внедрить web-верстку прямо в ваши дашборды, обходя множество подводных камней. Готовых шаблонов для handlebars (superset) мало, так как это довольно трудоемкая задача, часто выходящая за рамки работы с готовыми BI-системами.

Привет, сообщество HABR! =)

Начав изучать Kafka Streams, я заметил, что для решения различных задач приходится искать информацию по разным источникам, поэтому со временем накопилось много собственных конспектов. Хочу поделиться ими в виде серии туториалов на Хабре.

Несмотря на обилие ресурсов по Kafka Streams и отличные статьи на Хабре [ноль, один, два], мне не хватало пошаговых руководств, которые детально раскрывают изъяны и преимущества этой технологии. Поэтому решил создать такой материал, чтобы помочь другим разобраться структурно и последовательно.

Приветствую, сообщество!

Меня зовут Александр, я java разработчик в компании БФТ. Тружусь я на проекте СМЭВ-адаптера, где мы занимаемся транзитивной обработкой сообщений. В нашу зону ответственности входит несколько микросервисов, которые обрабатывают очень много сообщений, почти ничего не пишут в БД, но часто обращаются в сторонние прикладные сервисы.

Для отслеживания пути сообщения через наши микросервисы мы используем Zipkin. Помимо этого в проекте задействован Apache Camel, с помощью которого мы выстраиваем цепочку обработки сообщения в одном конкретном микросервисе. Стандартные средства для работы с Zipkin обычно позволяют легко добавить к трассе вход, выход в сервис и запись в БД, но, т.к. к нас не совсем стандартное поведение у сервисов, нам хотелось выделять в Zipkin и обращение в сторонние сервисы.

Хотелось эту логику как-то элегантно встроить в роут Camel, но существующие средства такой возможности не предоставляли.

Было принято решение написать свой компонент для Apache Camel. Делали мы это впервые и, к сожалению, полноценного гайда в интернетах найти не удалось...

Встречайте! Гайд по написанию собственного Camel-компонента!

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

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

Привет, Хабр! Меня зовут Марина, я QA-инженер в Купере. Как специалисту по тестированию, мне часто приходится сталкиваться с задачами, связанными с тестированием микросервисов, использующих асинхронное общение через Apache Kafka. Уверена, многие QA-инженеры, да и разработчики знакомы с подобными вызовами.

На одном из проектов, где я работаю, у меня возникла проблема: используемые инструменты для тестирования Kafka были недостаточно удобными:

Консольная утилита Protokaf не имеет интерфейса и полученные данные для лучшей читаемости нужно отформатировать в json структуру (а это еще одно доп приложение).

UI-приложение Kowl удобно только для мониторинга состояния топиков, и только недавно в нём стала доступна возможность чтения сообщений без сложного флоу для расшифровки, но всё так же нет возможность отправки сообщений в топик. 

В поисках более удобного решения коллега посоветовал Plumber — графическое приложение, с возможностью коньюмера и продюсера сообщения.

В этой статье я не буду объяснять, что такое Kafka и как работают брокеры — на эти темы уже есть множество отличных материалов, например, вот. Хочу поделиться своим опытом использования этого инструмента. Я не ставлю цель сравнивать его с другими существующими решениями, а просто расскажу, как Plumber помог мне упростить процесс ручного тестирования Kafka на стейджах. 

Добрый день. Меня зовут Иван Клименко, и я архитектор департамента поддержки продаж компании Arenadata. В основном занимаюсь продуктом Arenadata Streaming (ADS) — это масштабируемая отказоустойчивая система для потоковой обработки данных в режиме реального времени, адаптированная для корпоративного использования и построенная на базе Apache Kafka и Apache NiFi. В продукт входит cервис Arenadata Streaming NiFi, который является LowCode-средством построения интеграционных потоков с возможностью масштабирования.

Сегодня я бы хотел открыть цикл статей практического применения, так называемого «HowTo…», и первой темой выбрано взаимодействие с базами данных в NiFi. Рассмотрим простые заготовки потоков обработки данных, которые извлекают данные из таблиц и помещают данные в другую, либо эту же базу. Разберем, как создавать подключение к базам, какими процессами пользуемся для выборки, а также как оптимизировать эти процессы. Эта статья будет интересна в первую очередь новичкам в NiFi, ну а от опытных разработчиков всегда жду комментариев с дополнениями или с конструктивной критикой.

Добрый день, Хабр!

Меня зовут Сергей Игнатенко, я — девлид в поезде «Операционная платформа» ВСК. Хочу сегодня рассказать об опыте использования SchemaRegistry и Avro в Kafka.

Начну с базовой схемы работы с Kafka, которая, возможно, будет знакома многим, но важна для понимания контекста.

Принцип работы прост: продюсер отправляет сообщение в Kafka, где оно размещается в очереди. Далее один или несколько консюмеров считывают это сообщение.

В статье обсуждается процесс интеграции Apache Spark с Apache Atlas для визуализации выполнения ETL-процессов на основе построения связей между операциями в Spark. Автор описывает создание пользовательских сущностей в Apache Atlas, таких как Process и DataSet, которые необходимы для отражения трансформаций данных.

Основной фокус статьи заключается в построении графа lineage (происхождения данных) для операций в Spark. Автор выделяет ограничения архитектуры Apache Atlas, например, необходимость наследования от стандартных типов Process и DataSet для корректного отображения lineage. Также описывается создание и отправка новых типов сущностей в Apache Atlas с использованием REST API, а также проблемы, возникающие при попытках обновления сущностей.

В маркетинге и продажах крупных компаний есть несколько аналитических задач, которые требуют регулярной обработки сотен тысяч и миллионов записей из разных источников. Например, это прогнозирование продаж или планирование рекламных кампаний. Как правило, их решение не обходится без построения длинного пайплайна обработки данных. ML‑инженеру или аналитику данных нужен ансамбль из нескольких моделей и сервисов, чтобы собрать качественный датасет, провести эксперименты и выбрать наиболее подходящие алгоритмы.

Сбор, очистка и агрегация данных занимают большую часть времени и вычислительных ресурсов, а эти затраты хочется оптимизировать. В статье покажем, как мы ускорили построение пайплайнов обработки данных с помощью связки DataSphere Jobs и Apache Airflow™.

В этой статье представлен кейс по интеграции Apache NiFi с Apache Atlas с использованием Docker. В процессе развертывания и настройки системы возникли проблемы с загрузкой образов и установкой необходимых пакетов. Основное внимание уделяется созданию и настройке пользовательского репортера, который позволяет фильтровать и отображать только те компоненты DAG в Atlas, которые соответствуют заданным критериям. В статье подробно описаны шаги по созданию и сборке .nar архива, добавлению его в NiFi и настройке фильтрации с использованием кастомных классов.

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

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

Уверен, что мой рассказ будет полезен не только пользователям Superset, но и всем аналитикам, которые используют SQL в своей работе и учёбе.

Не буду рассказывать про базовое построение таблиц на BI системе Superset, с этим прекрасно справятся тонны видео на ютубе и бесполезные курсы (про которые я писал ранее). Но сразу скажу, что суперсет в отличие от некоторых других BI систем начинает раскрываться только если ты знаешь SQL, так что хотим мы этого или нет – погружаться в тонкости языка придётся.

Больше двух недель на поиск оптимального решения, ошибки, костыли и элегантный финал.

Итак, Что такое «Вес в приросте» и чем он отличается от обычного «Прироста», и в чем собственно говоря — сложность?

Разберёмся на примере:

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

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

Введение

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

Вы поймёте, как можно улучшить и оптимизировать работу с Apache Flink. В частности, мы разберём важную концепцию водяных знаков (watermark), которая играет ключевую роль в обработке потоковых данных с временными метками.

Будучи DevOps-инженером и работая с масштабируемыми облачными решениями, мне часто приходится глубоко погружаться в механизмы работы потоковых платформ. Трудно переоценить важность подробного изучения архитектуры и оптимизации обработки данных, когда речь идёт о системах вроде Apache Flink. Эта технология стала неотъемлемой частью моего инструментария благодаря её возможностям по реализации потоковых приложений.

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

Ещё мы подробно рассмотрим использование Apache Flink в задачах, где требуется высокая скорость обработки и точность управления данными. Особое внимание уделим изучению архитектурных основ и методов разработки высокоэффективных потоковых систем.

Материал объёмный, и поэтому я разделил его на две части. Запаситесь чаем и печеньками =)

Добрый день. Меня зовут Иван Клименко, и я архитектор департамента поддержки продаж компании Arenadata. В основном занимаюсь продуктом Arenadata Streaming (ADS) — это масштабируемая отказоустойчивая система для потоковой обработки данных в режиме реального времени, адаптированная для корпоративного использования и построенная на базе Apache Kafka и Apache NiFi. В продукт входит замечательный сервис Arenadata Streaming NiFi, который является low‑code средством построения интеграционных потоков с возможностью масштабирования.

Сегодня хочу показать на одном из практических случаев, что не всегда в NiFi удаётся следовать шаблонному подходу record‑oriented в разработке потоков обработки и трансформации данных.

Будет большой JSON, будет Avro‑схема, будет JOLT‑спецификация.

Небольшое отступление.
Работая работу, вдруг, появилась необходимость познакомиться с таким инструментом, как Apache Airflow. Задачу дали простую - нет никаких уведомлений в DAG'ах, при сбое необходимо уведомлять. Так как про этот сервис я только "слышал", уверенных знаний я показать даже сейчас, боюсь, не смогу. Зато смогу поделиться с вами простым кодом оповещения, который поможет вам не придумывать велосипед и воспользоваться (а то и улучшить) текущим. За основу я взял статью на Хабре, само собой официальная документация и другие открытые источники.

Данный alerting предназначен для любых версий, но если вы хотите использовать преимущества Apache Airflow на полную, то при версии >= 2.6.0 лучше читать статью выше.

Если вы здесь, скорее всего, вы уже примерно представляете что такое Apache Airflow, таски (джобы) и даги, поэтому не буду вдаваться в подробности и сразу перейду к сути.
Для начала я советую вам повторить (а в будущем и превзойти, если нужно!) текущую конфигурацию.

Для того чтобы понять, работают ли уведомления, напишем простейший dag со сломанной таской.

Аналитика данных и витрины аналитики — источники аналитической отчетности, на основе которой принимаются стратегические управленческие решения. Однако на рынке нет готовых фреймворков, которые полностью удовлетворяют потребности в извлечении данных.

Конечно, есть Apache NiFi, но с ним возникает много проблем при работе с большими объемами данных. Связка Python и Apache Airflow на сегодняшний день является одной из лучших практик в области управления данными не только для оркестрации данных, но и для извлечения, поэтому логично разрабатывать ETL-систему (Extract, Transform, Load) поверх Airflow. Это позволяет эффективно управлять процессами извлечения, преобразования и загрузки данных, обеспечивая надежность и гибкость в аналитической инфраструктуре.

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

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