Apache *

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

Немного лирики, что такое Apache Airflow — это оркестратор (ваших данных), инструмент для создания, планирования и мониторинга рабочих процессов (так называемых DAGs — Directed Acyclic Graphs).

Все знают, что 1С поддерживает работу по HTTP через Apache как в режиме Тонкого клиента, так и в режиме Веб клиента. Так же в тонком клиенте 1C можно указать скорость соединения. Мы знаем, что танки грязи не боятся, боится ли 1С плохих линий?

Тема преимуществ открытых табличных форматов при работе с озерами данных всё чаще поднимается в среде дата-инженеров. Предполагается, что их использование способно устранить недостатки популярного Apache Hive. Но так ли это на практике?

Меня зовут Иван Биленко, я инженер данных в команде дата-платформы Циан. В этой статье я хочу немного познакомить вас с процессами и стеком внутри нашей платформы, рассказать, почему мы решили попробовать Iceberg, с какими проблемами столкнулись при тестировании и какие преимущества Iceberg может дать тем, кто еще только задумывается о переходе. Дисклеймер: статья носит обзорный характер.

Superset не самый новый bi-инструмент, но его популярность продолжает расти. На мой взгляд, он достаточно прост в освоении, но все же требует некоторых усилий и времени, чтобы разобраться куда тыкать, чтобы загрузить данные и нарисовать красивый отчет. Лично я за свою карьеру в IT уже второй раз сталкиваюсь с необходимостью переезда на этот инструмент. Он снова новый для компании и многие сотрудники с ним раньше не работали. Поэтому я и решила написать статью-шпаргалку, которая поможет в несколько кликов создать работающий дашборд и всегда будет под рукой.

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

В предыдущих статьях [ноль, один] мы рассмотрели основные концепции Kafka Streams и сравнили их со стандартными подходами обработки потоковых данных. В этой части мы сосредоточимся на stateless processing (обработке без сохранения состояния) и поймем как применять различные операции Kafka Streams для решения практических задач. Мы создадим приложение для обработки данных медицинской клиники.

Требования к ETL пайплайну:

Приложение должно обрабатывать поток JSON-сообщений из входного топика Kafka (patient-records), содержащих информацию о пациентах медицинской клиники. Цель состоит в том, чтобы применять различные stateless операции для трансформации данных и отправлять результаты в выходной топик (clinic-notifications-topic). Это позволит продемонстрировать, как использовать основные возможности Kafka Streams для обработки данных без сохранения состояния.

В данной статье мы рассмотрим взаимодействие apache airflow, rabbitMQ и postgreSQL. Научимся правильно устанавливать соединения между ними и напишем базовый ETL.

DSL — это то, что делает Kafka Streams таким простым и позволяет подняться на более высокий уровень абстракции.

Причины написания статьи, общие правила использования handlebars в superset и советы содержатся в первой статье, поэтому сразу опишу следующие шаблоны.

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

Однако, при серьезном использовании любой системы рано или поздно возникает необходимость в гибкой настройке. А необходимость в отладке как правило возникает гораздо раньше. 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, ну а от опытных разработчиков всегда жду комментариев с дополнениями или с конструктивной критикой.