Добрый день, Хабр!
Меня зовут Сергей Игнатенко, я — девлид в поезде «Операционная платформа» ВСК. Хочу сегодня рассказать об опыте использования 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. Это позволяет эффективно управлять процессами извлечения, преобразования и загрузки данных, обеспечивая надежность и гибкость в аналитической инфраструктуре.
Крупной металлургической компании с большим количеством филиалов, нужно было простое решение, ускоряющее работу с аналитикой данных и извлечением из различных гетерогенных источников. При этом требовалось достаточно гибкое к расширению функционала загрузок решение.
Можно было решать задачу клиента классическим образом — написанием кода, но тогда разработка заняла бы около трех месяцев. У нас не было столько времени, поэтому приняли решение разработать фреймворк, чтобы ускорить и упростить разработку.
В данной статье рассматривается подход к созданию пользовательских функций (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. Сегодня я хочу углубиться в тему и описать поведение системы при различных типах совместимости . Правильное понимание и применение этих типов совместимости поможет обеспечить стабильность и гибкость системы при изменениях структуры данных.
