Данные библиотеки можно использовать при работе со SparkOperator:
1. Создание виртуального окружения с необходимыми библиотеками
2. Создание задачи в даге и установка окружения в SparkSubmit
Фреймворк с открытым исходным кодом Apache Spark, входящий в экосистему проектов Apache Hadoop, используется для реализации распределённой обработки данных. Для работы в Spark могут использоваться различные языки программирования: Scala, Java, Python и R.
В рамках данной статьи мы не будем рассуждать о преимуществах использования того или иного языка, на эту тему достаточно публикаций. Мы рассмотрим PySpark — фреймворк с открытым исходным кодом, построенный на базе Apache Spark и предназначенный для упрощения и ускорения решения масштабных задач обработки данных и аналитики. PySpark предлагает высокоуровневый API для языка программирования Python, что позволяет легко интегрироваться с существующими экосистемами Python.
Но для начала рассмотрим архитектуру Apache Spark.
Я хочу рассказать, как мы решаем задачи миграции данных кластеров Cassandra с помощью инструмента Cassandra Data Migrator (CDM). Выбор этой темы продиктован продуктовыми задачами по корректной миграции данных между кластерами Cassandra сложной топологии. Статей с обзором этого решения в русскоязычном сегменте я не нашел и решил описать сам, так как оно будет полезно всем администраторам СУБД Cassandra.
Привет! Меня зовут Виталий Флёрин, я руководитель отдела BI-аналитики в M2. За год мы успешно перевели всю отчетность компании с Cognos Analytics на Apache Superset и увеличили MAU до 200 (каждый третий сотрудник компании). В статье хочу поделиться опытом внедрения новой системы отчетности и ее эффективного использования.
Материал будет полезен BI-специалистам, кто работает над развитием внутренних систем и хочет переехать на Superset.
История началась с того, что после ухода Cognos Analytics с российского рынка, нам нужно было выбрать новую BI для компании и мигрировать всю отчетность. Текущая система была развернута on-premises и продолжала работать в штатном режиме. Да, без обновлений и поддержки, но благодаря этому мы смогли тщательно подойти к выбору нового решения и обеспечить плавный переход пользователей на новую платформу.
Идея написания этого небольшого руководства появилась у меня, когда я начал изучать одну из самых популярных библиотек для работы с Apache Kafka - modern-cpp-kafka.
Однако, как водится, ничто не идеально, и порой приходиться делать самые простые вещи за библиотеку.
В статье расскажу, как настроить мониторинг Apache NiFi и алерты при переполнении очереди по достижении 8000 FlowFiles.
Зачем вам читать эту статью? Переполнение очереди FlowFiles в Apache NiFi может привести к замедлению или остановке обработки данных, мониторинг позволит своевременно среагировать на проблемы с производительностью и выявить узкие места.
Что делает инженер, если DAG не выполняется? Проверяет Airflow 50 раз, а потом вспоминает, что забыл поставить @dag над функцией.
Развертывание Apache Airflow в промышленной среде — это сложная задача, требующая учета множества аспектов: от обеспечения безопасности конфиденциальных данных до эффективного управления ресурсами. Одной из ключевых проблем, с которыми сталкиваются команды, является безопасное управление секретами, оптимизация конфигураций и наблюдаемость.
В этой статье мы рассмотрим, как использовать инструменты, такие как Sops и YAML-якоря, для упрощения управления конфиденциальными данными и улучшения читаемости конфигураций. А так же как обеспечить полную наблюдаемость инсталляции Apache Airflow.
В 2024 году мы не дождались выхода в свет Apache Kafka 4.0, в которой окончательно исчезнет поддержка ZooKeeper, оставив нам для создания кластеров только KRaft. Кто-то давно уже перешёл на эту прекрасную технологию, другие же размышляют, как им жить дальше — оставаться на линейке 3.х или в омут с головой.
Новогодние каникулы самое подходящее время для того, чтобы пощупать новую версию. Хотя код невозбранно доступен в Github проекта Apache Kafka, docker-образов текущих сборок 4.0 мне найти не удалось. Также поддержку 4.0 ещё не добавили в довольно популярный, и с недавних пор мною любимый, k8s-оператор strimzi. Ну что же, придётся устроить себе праздник самому!
Однажды в студеную зимнюю пору из-за морей, из-за океанов прилетело известие: лицензии не выдаем, тех.поддержку не оказываем, а можем и вовсе отключить все системы. В компании погоревали, но делать нечего, решили переходить на новые системы, да такие, чтобы не смогли в любой момент их превратить в тыкву. И стали смотреть в сторону open-sourсe решений. Проанализировали несколько BI-систем и остановились на SuperSet. /*После QlikSense и Tableau казалось, что это так себе затея*/
Меня зовут Корнева Настя, я отвечаю за разработку BI-отчетности в Magnit Tech в рамках проекта Аналитика УЦП (управление цепочками поставок). В этой статье поделюсь нашим опытом создания динамических сводных таблиц в BI-инструменте SuperSet, что будет полезно разработчикам отчетности и всем, кому интересна тематика.
Всем привет, случалось такое, что вам надо поставить кучу агентов битрикса на крон, а потом сидеть и разбираться - сколько они отрабатывают, отрабатывают ли вообще, когда падают или зависают?
Ну конечно случалось. Так вот, чтобы получить визуальное представление о том, что там происходит, было принято решение, вынести агенты даже не на крон, а на apache airflow. Поведаю вам, как это было реализовано.
Агенты
По факту, агенты - это выполнение php команд по-расписанию. Но мы пойдем дальше и выделим их в отдельную сущность, в классы с расширением Agents.php
Создадим интерфейс для агентов
Привет, Хабр! Меня зовут Саша Петраки, два года я занимаюсь разработкой интеграционных решений в К2Тех. И сегодня хочу рассказать, почему мы с командой снова задались вопросом: “Как связать воедино все информационные системы компании?” Казалось бы, ответ очевиден — настроить интеграции между ними. Но если раньше для решения этой задачи можно было использовать готовые импортные продукты, то сейчас необходим другой подход, причем сделать это, как правило, требуется максимально быстро.
Нам поступил запрос от коллег из департамента внутренней автоматизации (ДВА). Мы искали пути решения… а в итоге докрутили ПО до такой степени, что получился готовый продукт с возможностями low-code для типовых задач и pro-code для кастомных кейсов. О его создании, реализованных кейсах и результатах разработки пойдет речь в нашей статье.
Как-то один из самых главных контрибьюторов в Airflow Ярек Потиюк рассказал, что Airflow 3 станет новым золотым стандартом индустрии. Это довольно смелое заявление. Я же считаю, что в Airflow 3 еще многого не хватает, чтобы действительно стать стандартом.
Если вы еще не знаете, что такое Airflow, то, к сожалению, это статья будет сложной. Давайте вместе освежим память.
Airflow - это платформа с открытым исходным кодом для написания и управления рабочих процессов. Airflow была основана в 2014 году в AirBnB. С тех пор платформа прошла путь до версии 1.0 в 2015 году, стала Apache Top Level Project в 2019 и плотно обосновалась как Enterprise Production-Ready в 2020 с версией 2.0.
На сегодняшний день потоковая обработка и анализ данных стала неотъемлемой частью многих бизнес-процессов и технологических решений. Для эффективного управления большими объемами данных необходимы инструменты, которые не только обеспечивают надежность передачи сообщений, но и позволяют визуализировать их потоки, обеспечивая прозрачность и удобство мониторинга.
В моей предыдущей статье про симулятор одного из самых популярных брокеров сообщений — RabbitMQ (https://habr.com/ru/articles/859 982/) много читателей оставляли в личку разные вопросы, но одним из самых популярных и часто задаваемых стал: «Очень классный и удобный симулятор! А есть ли такой же для Kafka?» И тут я понял: действительно, несправедливо рассказывать и, так сказать, нести в массы симулятор одного типа брокеров, но совершенно забыть про другой. Ну что ж, Кафка, значит, Кафка!
На просторах всемирной паутины, к сожалению, стопроцентного аналога‑конструктора, такого как RabbitMQ Simulator, к сожалению, я не нашел. Но мы же знаем, что этой статьи не было бы, если бы я не нашел что‑то интересное.
И сегодня это будет Kafka Visualization от компании SoftwareMill.
Table API — это API для взаимодействия с данными в табличном виде. Если рассматривать аналогию со Spark, то наша таблица в Table API — это датафреймы в Spark. Нет четкой структуры, каждая точка потока — таблица, то есть после преобразования таблицы нам возвращается таблица, как это происходит и в Spark.
Так же, как и Spark, Table API использует свой диалект SQL, который можно использовать над таблицами. Таблицу мы можем зарегистрировать в каталоге Table API и обращаться к ней с помощью SQL, используя команду Execute SQL. Все преобразования можно делать как обращаясь к таблице напрямую, через метод, так и при помощи SQL, то есть при помощи Select можно создать новую таблицу. Может запускаться как приложение, так и интерактивно SQL-запросами. То есть если у вас развернут Flink-кластер, то можно к нему подключиться при помощи Flink SQL, вбивать команды, создавать каталоги, подключаться к каталогам и проворачивать, например, батчевые SQL-запросы, которые перетягивать данные.
Главная фишка: источники и приемники могут создаваться и конфигурироваться при помощи DDL SQL.
Apache Kafka — это решение для распределенной потоковой передачи сообщений. Проект, построенный на основе Scala и Java, направлен на создание единой платформы с высокой пропускной способностью и низкой задержкой для управления потоками данных в реальном времени. Основными возможностями платформы потоковой передачи данных является возможность публиковать потоки записей и подписываться на них, подобно очереди сообщений или системе бизнес‑обмена сообщениями. Также большое значение имеет возможность обрабатывать потоки записей по мере их поступления и хранить их отказоустойчивым и долговечным способом.
Привет! Меня зовут Александр Булатов, я старший инженер данных в Блоке Данных билайна. В этой серии статей я расскажу, как выглядит создание Source и Sink для Table API & SQL и как Table API взаимодействует с DataStream API.
Я работаю на проекте Radcom, в котором мы получаем данные о детализации звонков. И есть источник потоковых данных, которые мы получаем с Kafka. Таких потоков у нас внутри Radcom одиннадцать штук, и данные от них идут в формате csv. Формат не самый удобный для обработки, потому что он не имеет в себе схему — нам присылают просто голые строки csv, без какой-либо схемы, и нам нужно парсить эти строки относительно ее.
В одном подобном потоке вполне может находиться сто миллиардов записей в сутки, а это со всех потоков почти семь терабайт в день. У нас в билайне это считается одним из самых больших потоков, которому требуется очень много ресурсов, в год с учетом репликации мы занимаем почти семь петабайт данных.
Так вот, мы принимаем данные в csv и должны их сохранять в Hive в колоночных форматах, чтобы впоследствии аналитики и Data Scientists могли пользоваться этими данными. У нас принято использовать либо ORC, либо Parquet. Мы попробовали оба формата, пришли к Parquet.
В предыдущих статьях мы познакомились с основами Kafka Streams и рассмотрели stateless операции. В этой статье мы погрузимся в stateful processing и создадим приложение для управления запасами в реальном времени. Шаг за шагом мы реализуем функциональность, которая позволит отслеживать состояние запасов товаров, обрабатывать поступления и продажи, а также предоставлять доступ к текущему состоянию через REST API.
Multi-Agent Orchestrator — гибкая и мощная платформа для управления несколькими AI-агентами и обработки сложных разговоров.
GitHub Repo - https://github.com/awslabs/multi-agent-orchestrator
