Apache *

Как я встроил AI‑агента прямо в интерфейс Apache Superset и не сломал ему CSP

Есть Apache Superset. Есть аналитик, который открывает SQL Lab и десять минут вспоминает, как называется таблица с заказами — orders, olist_orders или fact_orders_v2. Есть языковые модели, которые отлично пишут SQL, но понятия не имеют, что лежит в вашем хранилище.

Задача звучала просто: добавить в интерфейс Superset кнопку, по которой открывается чат с моделью. Причём агент должен работать по принципу MCP — не фантазировать имена колонок, а сходить и посмотреть их в метаданных. Подключаться к любому OpenAI‑совместимому API: локальная Ollama, llm7, OpenAI — что угодно.

Дальше — про то, как это делается без форка Superset, без пересборки фронтенда и без ослабления политики безопасности. И про несколько ловушек, каждая из которых стоила мне отдельного расследования.

Перед техническим разбором можно посмотреть короткую демонстрацию того, как AI‑ассистент работает непосредственно в интерфейсе Apache Superset: видео на YouTube.

parquet - данные лежат в открытом формате - казалось бы, бери кто хочешь. Но есть неприметный артефакт, от которого зависит, увидите вы таблицы или мусор из файлов и кого вообще к ним подпустят. Это каталог. Разбираю просто, что такое Apache Iceberg, зачем ему каталог - и почему новость про Polaris важнее, чем кажется. В продолжение анонса новостей…

Работая единственным QA в команде, в обязанности которого активно входит мониторинг, я столкнулась с проблемами тайм-менеджмента: очень много времени уходит на анализ упавших пайплайнов, заведение однотипных задач, поднятие тревоги, отмена тревоги, потому что проблема уже исправляется и прочие прелести тестерской работы. В один прекрасный осенний денек, сидя на окне и думая о нем (мониторинге), я решила - хватит это терпеть. Посидела, погуглила, вспомнила родительские слова “Хочешь сделать что-то хорошо - сделай это сама”. Что ж таков путь.

Привет, Хабр! Меня зовут Александр Бардаш, и я CTO интеграционной платформы MWS Octapi. В одной из предыдущих статей я рассказывал, как мы выбирали движок для low-code и почему остановились на Temporal, отказавшись от Apache Camel. С тех пор регулярно получаю один и тот же вопрос — от продактов, аналитиков, а иногда и от коллег-архитекторов: «Подождите, ну сейчас же есть Karavan, Kaoto, нормальные визуальные редакторы. Аналитик там накидает кубики, настроит логику, разве это не cделает Camel доступнее?» Короткий ответ — нет, не cделает. А вот почему, предлагаю разобрать в материале.

Дисклеймер: это мой личный опыт и опыт команды. Тема спорная, у вас может быть своя картина.

Пару дней назад я собрал сводку новостей по lakehouse и закончил её обещанием: разберу каждый громкий анонс по отдельности. Выполняю - и начинаю с самого шумного.

На своём июньском саммите Databricks вышел на сцену с заявлением масштаба смены эпохи: отдельные быстрые базы под витрины больше не нужны, перекачка данных между системами умерла, а всё хозяйство теперь живёт в едином озере, готовом под ИИ-агентов. Звучит так, что хочется встать и поверить.

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

Я Игорь Юрченко, backend-разработчик Сбера, в этой статье расскажу о нашем опыте автоматизации деплоя потоков Apache NiFi.

Apache NiFi — инструмент для управления потоками данных между автоматизированными системами (реализует подход ETL — extract, transform, load). Документация: https://nifi.apache.org/documentation/v1 (на момент написания статьи актуальна версия 2.x, но тут речь про 1.x). Физически это Java-приложение с графическим web-интерфейсом, в котором настраивается поток — в общем случае набор процессоров, которые получают на вход какие-то данные от предыдущего процессора или из внешней системы, обрабатывают их определённым образом и передают следующему процессору или во внешнюю систему. Процессор — готовый модуль с параметрами интеграции и/или обработки данных (например, строка подключения к БД, или схема трансформации данных). То есть ETL настраивается графически, без написания кода. NiFi обладает возможностями горизонтального масштабирования (ноды кластера имеют одинаковую копию настроек потока, обрабатывают данные параллельно), и расширения (пользователь может писать custom процессоры и использовать их в потоках наравне со штатными). Из коробки поддерживается множество внешних систем и протоколов передачи данных.

Apache NiFi Registry — инструмент версионирования потоков, Java-приложение с web-интерфейсом, интегрировано с NiFi. Что-то вроде системы контроля версий исходного кода, но проще. Пользователь может сохранять в Registry, просматривать и восстанавливать старые версии потока. Документация: https://nifi.apache.org/docs/nifi-registry-docs.

Сегодня разберемся, что такое кросс-фильтрация в Apache Superset и какую неожиданную опасность она может нести.

Привет, Хабр! На связи системный аналитик Илья Глазунов и разработчик Захар Корсаков. Мы работаем с платформой карточного хранилища Т-Банка.

Когда данных становится много, а архитектура обязана оставаться простой, классические решения начинают упираться в ограничения стека. В нашем случае нужно было организовать асинхронную доставку событий из Cassandra, но без CDC, без отдельного брокера и без разрастания зоопарка технологий. Так мы пришли к Non-transactional Outbox — схеме, которая по духу напоминает Kafka Inside the Database, но живет в рамках наших ограничений и требований к отказоустойчивости.

В статье покажем, что такое Outbox, с чем его едят и как готовят. Расскажем допущения по реализации в нашем случае, вытекающие из отличий от классического паттерна Outbox. Обрисуем ту реализацию, которую сделали своими руками, и покажем бенчмарки нагрузочного тестирования. В конце поделимся списком вопросов, которые возникали чаще всего при обсуждении решения внутри банковского сообщества Apache Cassandra.

Меня зовут Игорь Симаков, работаю engineering manager’ом и руковожу командами разработки

На одном из наших сервисов, который работает с XLSX-файлами, прилетел production-алерт на высокое потребление памяти. Стандартный P3, обычно решается рестартом. Пошёл смотреть поды и нашёл проблему, к памяти отношения не имеющую, но представляющую больший риск, чем сам алерт. Об этом и расскажу ниже: чем «утечка диска» отличается от «утечки памяти», как мы наткнулись на грабли в Apache POI и как закрыли их на уровне архитектуры

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

На первый взгляд кажется, что достаточно найти соответствующие сообщения и удалить их из Kafka topic. Но Kafka хранит данные как commit log, поэтому точечное удаление сообщений по версии таксономии или другому бизнес-признаку оказывается небезопасным.

В статье рассмотрим, почему прямое удаление сообщений не подошло, какие варианты были рассмотрены и как в итоге был применён комбинированный подход: стабильный Kafka key, tombstone-сообщения, compact/delete policy и проверка состояния таксономии на стороне consumer.

Столкнулась с задачей локализации Apache Superset — и внезапно оказалось, что «из коробки» он переводится только частично.

Поделюсь пошаговой инструкцией по локализации и сборке Docker image. Бонусом — сразу подключим PostgreSQL и Redis вместо дефолтных SQLite и встроенного кеша.

Алерт по Kafka lag выглядит убедительно, пока не приходится объяснять, что именно значат «50 000 сообщений отставания» для пользователей и SLA. В статье разбираем, почему offset lag часто создает ложное ощущение контроля, где ломаются популярные подходы к расчету задержки и как перейти к мониторингу по реальному time lag.

На примере klag-exporter покажем, как считать задержку через таймстемпы сообщений, настроить метрики для Prometheus и Grafana и сделать алерты, которые помогают дежурному инженеру понять критичность проблемы без гадания по дашборду.

Всем привет! На связи Антон Воробьёв — архитектор в Альфа‑Банке. Некоторое время назад у нас появился нативный порт C‑клиента librdkafka, который сделали наши коллеги из компании BTC. Чтобы порт работал быстрее, мы допортировали последнюю на тот момент версию librdkafka 2.3, разобрались с оптимизациями под нашу специфичную ОС, починили все юнит‑автотесты в её составе, сделали свои, и внедрили в июне 2024 года. На сегодня порт отправляет ежедневно 100 миллионов сообщений в 50+ топиков и суммарно в сотни партиций, примерный объём — 200 ГБ в неделю.

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

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

Apache Doris 4.1 добавляет UPDATE, DELETE и MERGE INTO на Iceberg-таблицы прямо из SQL-клиента — без отдельного Spark job. Iceberg V3 Deletion Vectors и Row Lineage делают этот DML архитектурно здоровым: нет линейной деградации от delete files, нет false positives в CDC после compaction. Перевод и адаптация статьи Mingyu Chen (CC BY 4.0) с бенчмарками, SQL-примерами и Quick Start.

Работать с Kafka в DBaaS — удобно: инфраструктура поддерживается сильно проще, пока вы фокусируетесь на логике приложения. Но есть нюанс: прямой доступ к брокерам и CLI ограничен. Это усложняет отладку, анализ данных и диагностику consumer — особенно если у вас десятки топиков и групп.

Kafka UI — это Open Source-инструмент, который решает описанную проблему: он предоставляет веб-интерфейс для просмотра топиков, сообщений и состояния consumer groups без прямого доступа к брокерам.

На связи Ксения Ершова, проектировщик интерфейсов в Selectel. В статье расскажу, как развернуть на облачном сервере Kafka UI в публичном доступе, подключить его к Kafka-кластеру в DBaaS Selectel и проверить, что все работает.

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

Greenplum много лет был в опенсорсе на GitHub под лицензией Apache 2.0. Казалось бы, лицензия Apache 2.0, что может пойти не так? Осенью 2023 года репозиторий неожиданно перестал принимать наши пул‑реквесты. Все наши CLA отозвали, а новые не подтвердили без каких‑либо пояснений.

А в мае 2024-го репозиторий был закрыт. Да, к опенсорс‑проекту могут потерять интерес — и он окажется заброшен. Но здесь, по сути, присвоили наши пул‑реквесты, изменив лицензию у кода, который мы написали, просто потому, что «ничего личного, это бизнес». Обстоятельства менялись, и вот — новые правила использования БД. Твои опыт и достижения либо присваиваются корпорацией, либо обнуляются.

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

В начале Апреля 2026 года устанавливал я Zabbix 7.4, самой новый на тот момент, на LUbuntu v. 25.10 - тоже самой новой на начало апреля.

Выбрал пакетный вариант установки.

На связи Сергей Скирдин, технический директор компании «Белый код». Поставил себе цель — сделать обзоры на шины данных из реестра отечественного ПО. Сегодня в обзоре Compo ESB.

С 2024 года я встречаюсь с вендорами и делаю обзоры продуктов, которые относятся к классу ESB. За это время удалось пообщаться с разработчиками 20+ разных решений. Для всех, кто интересуется шинами данных, я также создал сообщество в Телеграме «Шины не для машины». Это площадка для диалога между российскими разработчиками ESB и компаниями, которым нужна интеграционная шина.

Представим ситуацию: у нас есть сервисы, которые пишут логи событий и сообщения из очередей (Kafka, RabbitMQ) в формате Avro для гарантии схемы и потоковой доставки. В это же время отдел машинного обучения работает с датасетами в Parquet — ребята ценят столбцовое хранение и производительность на скалярных чтениях.  Соседняя команда фиксирует фактовые таблицы в ORC, поскольку этот формат подходит для тяжелых аналитических агрегаций. 

Пока объемы данных измерялись гигабайтами, такой «зоопарк форматов» был терпим: каждый отдел использовал свой инструмент, а данные копировались между ними через ETL-конвейеры. Но с ростом до терабайтов и выше эта архитектура начинает ломаться: запросы становятся медленными, стоимость хранения и вычислений стремительно растет, а главное — теряется единый источник истины. Теперь одна и та же бизнес-сущность существует в трех разных форматах, схемах и состояниях. 

В этот момент возникает потребность не в очередном хранилище, а в табличной абстракции поверх существующих форматов. Такой слой должен обеспечивать ACID-транзакционность, централизованное управление схемой и единый каталог для всех потребителей — от потоковой инженерии до машинного обучения и BI. Именно так и приходят к Apache Iceberg и к идее построения собственной платформы данных.