Продолжим наше знакомство с 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. Это позволяет эффективно управлять процессами извлечения, преобразования и загрузки данных, обеспечивая надежность и гибкость в аналитической инфраструктуре.
Крупной металлургической компании с большим количеством филиалов, нужно было простое решение, ускоряющее работу с аналитикой данных и извлечением из различных гетерогенных источников. При этом требовалось достаточно гибкое к расширению функционала загрузок решение.
Можно было решать задачу клиента классическим образом — написанием кода, но тогда разработка заняла бы около трех месяцев. У нас не было столько времени, поэтому приняли решение разработать фреймворк, чтобы ускорить и упростить разработку.
В данной статье рассматривается подход к созданию пользовательских функций (UDF) в Scala, специфически в контексте использования в Apache Spark. Автор исследует проблему динамической генерации и передачи лямбда-выражений через JSON, обсуждая ограничения сериализации функций в Spark и возможные решения с использованием типа Any для универсальной обработки различного числа аргументов. Статья призывает к дискуссии и поиску альтернативных подходов, не претендуя на единственно верное решение, и представляет предложенный метод лишь как один из возможных вариантов решения задачи.
По техзаданию необходимо было создать сервис, который в зависимости от топика, отправлял бы сообщения или на один инстанс Kafka (строку, с простой авторизацией с помощью SSL), или на другой, но уже с сериализацией и авторизацией через Kerberos.
Orange Tsai недавно запостил про «Одну из уязвимостей PHP, которая влияет на XAMPP, развернутый с настройками по умолчанию», и нам было интересно рассказать немного об этом. XAMPP - очень популярный способ администраторов и разработчиков развернуть Apache, PHP и множество других инструментов, и любая ошибка, которая может быть RCE в установке этого набора по умолчанию, звучит очень заманчиво.
Где нашлась очередная уязвимость PHP? Читайте далее.
Привет, Хабр! Представляю вам вторую часть из серии статей, посвященных оптимизации развертывания Kafka кластера (ссылка на первую часть). Это перевод руководства от Confluent. Сегодняшняя статья посвящена тому, как уменьшить задержку и повысить надежность и доступность. Заключительная третья часть будет посвящена мониторингу и бенчмаркингу.
Привет, Хабр! Представляю вам перевод технического документа от Confluent, который посвящен тому, как определить, что именно нужно оптимизировать (пропускная способность, задержка, надежность или доступность), как настроить развертывание Kafka в соответствии с этими целями и убедиться в их достижении с помощью мониторинга. Сегодня я выкладываю первую часть, в которой обсуждается, как определить цели оптимизации и улучшить пропускную способность Kafka. Последующие статьи будут посвящены задержке, надежности, доступности, мониторингу и бенчмаркингу.
В прошлой статье я писал о том, что такое Schema Registry и как используется в Apache Kafka. Сегодня я хочу углубиться в тему и описать поведение системы при различных типах совместимости . Правильное понимание и применение этих типов совместимости поможет обеспечить стабильность и гибкость системы при изменениях структуры данных.
Привет. Меня зовут Николай Шувалов, я занимаюсь коммерческим программированием около семи лет, владею Rust, JavaScript, PHP. Сейчас я работаю в отделе данных билайна. Наша платформа позволяет делиться с партнерами данными, не раскрывая их. Например, можно расширить данные с помощью фильтра Блума.
Arrow в сравнении со строковыми форматами
Возьмём простую таблицу, которая состоит из трех столбцов: телефона, даты и имени. Рассмотрим, как она будет выглядеть в строковом и столбчатом форматах. Для строкового формата мы возьмем csv и json, для столбчатого формата структура будет одинаковой. Если же таблица состоит, например, из миллиона строк, а нужно получить имя на строке с номером 10 000, то придется бежать по всей строчке. В json то же самое. А в столбчатом формате ситуация иная — значения привязаны к столбцам. Когда мы хотим получить имя на строке 10 000, то сразу обращаемся к этому столбцу и получаем все его данные.
Существуют RA (random access) файлы, в которых можно пропускать заданное количество строк, но все равно парсеру нужно читать и анализировать пройденные строчки.
Привет, Хабр! Меня зовут Антон, я работаю аналитиком в отделе бизнес-аналитики и анализа доходности в ОТП Банке. В нашей новой статье мы погрузимся в мир Apache Superset 2024 и откроем вам лучшие практики и продвинутые методы работы с этим мощным инструментом. После прочтения вы научитесь мастерски кастомизировать Pivot-таблицы, создавать уникальные цветовые палитры для дашбордов, эффективно настраивать систему алертов и использовать удобные CSS/HTML-шпаргалки для ускорения работы. Эти знания помогут значительно повысить эффективность использования Apache Superset, делая вашу аналитическую работу не только производительной, но и визуально привлекательной. Итак, поехали.
Одним из популярных оркестратором задач является Apache Airflow. Он, как и все инструменты, имеет свои преимущества и недостатки, о которых пойдет речь в данной статье.
Год назад я планировал выпустить серию статей по мотивам бесед с моими коллегами, но дальше одной статьи не пошло, хотя материала накопилось достаточно. Большинство моих товарищей остались на прошлых местах работ и считаю необходимым в знак уважения перед этими неординарными и талантливыми личностями продолжить свои рассказы охотника до талантов.
Сегодня — это руководитель и senior fullstack Марк Локшин. В этой беседе мы обсуждаем о заходе в тему разработки собственного инструмента Business Intelligence. Тема недвусмысленно намекает на то, что данная тема уже не раз была описана на соответствующих ресурсах, а российский рынок даже после ухода с него западных вендоров обладает собственным набором вполне зрелых и рабочих решений.
Собственно, откуда у нас появилась такая задача? Конечно же от заказчиков. А заказчики у нас чаще специфические: государственные и около организации, администрации субъектов регионов. У этих «ребят» чаще всего основная задача показать большому начальнику на совещании красивый график и отчитаться, как же все классно поработали, у особенных из этих заказчиков предъявлены жесткие требования к инструментам разработки.
В статье расскажу о практических аспектах использования Apache NiFi, опишу преимущества и проблемы, с которыми я столкнулся.
Для наглядности собрал "песочницу" в контейнере Docker, в которой представлены упрощенные примеры пайплайнов, аналогичные тем, которые были использованы в реальном проекте.
Привет, Хабр!
Apache Ignite - это высокопроизводительная, распределённая in-memory платформа, которая предназначена для хранения и обработки больших объёмов данных с ультранизкой задержкой. Основная фича Ignite заключается в его способности обеспечивать молниеносный доступ к данным, распределённым по горизонтально масштабируемому кластеру.
Сегодня в статье разберем, как Kafka обрабатывает оффсеты сообщений и какие существуют стратегии их сохранения и обновления.
Оффсет в Kafka — это числовой идентификатор, который указывает позицию каждого сообщения внутри партиции топика. Оффсеты представляют собой порядковые номера, начинаемые с нуля, и уникальны в рамках каждой партиции, но не между разными партициями. Т.е сообщение с оффсетом 5 в партиции 1 и сообщение с оффсетом 5 в партиции 2 — это разные сообщения.
