Apache *

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

Мы уже изучили тонну материалов, сами стали носителями знаний, делимся ими в команде и на Хабре. Но не перестаем натыкаться на интересные механики и особенности Cassandra, которые приходится разбирать по принципу «с миру по нитке». 

Та механика, о которой пойдет речь, могла проявиться только в системе со специфическим дизайном, предназначенной для очень конкретных задач, при значительной нагрузке на запись и высоком коэффициенте параллельности.

В статье разберем, почему утверждение «Cassandra — колоночная БД» частично верное. Приоткроем занавес, как база данных работает с мета-данными и объединением неизменяемых файлов при высокой пишущей нагрузке. А еще подискутируем на тему понятия атомарности операций во вселенной Apache Cassandra и разберемся, причем же тут UDT и frozen UDT. 

Привет, Хабр!

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

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

Со временем проект развивался, и недавно я завершил работу над его второй версией – Spark Cluster 2.

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

Glafira for Apache Kafka — бесплатный desktop-клиент для Kafka под macOS, Windows и Linux: Tauri 2, Rust, librdkafka, код открыт под Apache 2.0. Просмотр сообщений с фильтрами и JSONPath, Producer с шаблонами, consumer-сессии, топики, группы, сброс оффсетов и встроенная проверка кластера.

Самое интересное — MCP-шлюз для LLM. Claude, GigaCode, Cursor или любой другой клиент с поддержкой MCP подключается к Glafira, читает метаданные кластера, находит проблемы, оставляет замечания и предлагает изменения. Применить что-либо модель не может: у неё физически нет ни одного изменяющего инструмента, а предложение открывается заполненной формой, где кнопку нажимает человек. В статье — как это устроено, почему это гарантия, а не обещание, и два настоящих диалога с Claude Code.

С версии Superset 6.0 в метрики сводных таблиц можно подставлять произвольный HTML. Это открывает возможности, которые раньше казались недоступными — например, карточки KPI прямо в ячейках Pivot Table.

Я уже описывала различные фишки, которые можно реализовывать в сводных таблицах: здесь, здесь и здесь.

В данной статье продолжу раскрывать потенциал сводных таблиц.

В шестой версии SuperSet появилась возможность прописывать HTML код в метриках  и измерениях сводных таблиц, что значительно расширило  приемы для BI-разработчиков по форматированию  таблиц.  Покажу как в SuperSet можно реализовать сводную таблицу со сменой периодов и выводом красивой дельты.

Компактация лога в Kafka может привести к ситуации, когда разные реплики одного топика начинают хранить разную версию данных — и расхождение сохраняется даже после восстановления брокера. Проблема возникает из-за гонки между компактацией и репликацией и затрагивает Kafka 3.9–4.2. Разбираемся, как воспроизвести баг и почему координированная компактация решает проблему.

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

Superset умеет строить сводные таблицы,  но при выводе подытогов и итогов (subtotals/total)  в сводных таблицах с иерархически структурированной метрикой сталкиваешься с ограничением: из коробки можно строить только простые метрики. А если нужна процентная метрика с корректными подытогами и итогами — приходится искать обходные решения.

 В этой статье разберём, как обойти это ограничение на уровне обращения к БД (ClickHouse).

Я  нашла два подхода: UNION и массивы. И начну с первого, детально разобрав именно через UNION.

Kwai перенесла расчёт метрик A/B-экспериментов со Spark на Apache Doris: до 145 раз быстрее при снижении потребления ресурсов на 72%. В переводе разбираем, как команда переработала размещение данных, Local Distinct, UDF, планирование и метаданные FE на кластере из 2000 BE-узлов. С примечаниями о границах сравнения и доступности оптимизаций в открытом Doris.

Привет, Хабр. Я Игорь Юрченко, backend-разработчик Сбера. В предыдущей статье я описал автоматизацию развёртывания потоков NiFi, а сейчас расскажу о дальнейшем развитии этого подхода для интеграции с корпоративной системой управления секретами — SecMan. Буду использовать терминологию предыдущей статьи.

Если вы хоть раз эксплуатировали Kafka, то знаете, сколько нервных клеток способен съесть её кластер. Поднять Kafka для PoC несложно, а вот дальше начинается планирование ёмкости, диски, replication factor, перераспределение партиций и восстановление после отказа брокера. 

В MWS Cloud Platform мы решили, что так дальше жить нельзя, и запустили Serverless Queue — бессерверный Kafka-совместимый брокер. Читайте статью, чтобы узнать, как с его помощью быстро и просто можно запустить сценарии обработки сообщений по Kafka-протоколу.

Методы replaceUsing и replaceOn обеспечивают более удобный способ перезаписи, а каталог теперь проверяет каждую операцию, а не только фиксацию.

Выпуск Delta Lake 4.3 состоялся в июне 2026 года, и он основан на Apache Spark 4.1.0 и 4.0.1. Если прочитать примечания к выпуску от начала до конца, вы увидите длинный список изменений, охватывающих Delta Spark, ядро, UniForm, Sharing и Flink, который легко принять за релиз с исправлениями, дополненный описанием каталога обновлений.

Два момента заслуживают вашего внимания, и они находятся на противоположных концах стека. Первый — небольшой и сразу полезный: replaceUsingнаконец replaceOn-то API DataFrame получает возможность выборочной перезаписи, которая не является replaceWhere. Второй — структурный: теперь каждая операция с таблицей, управляемой каталогом, проходит через API Unity Catalog Delta , а не только фиксация изменений. В Delta 4.2 фиксации изменений были скоординированы с каталогом. В Delta 4.3 остальная часть интерфейса, загрузка таблиц, CREATE, CTAS, REPLACE, и запись метаданных, объединены в один проверенный путь.

В этой статье рассматривается версия 4.3 с точки зрения разработчика конвейера: какие изменения в коде вы вносите, какие изменения происходят под вашим контролем и что следует проверить перед обновлением. Приводятся примеры testing.defaultдля каталога и схемы, а также пример компании CH Enterprise. Ссылки на исходный код находятся внизу.

Привет, Хабр! Я Артём Борисов, Java-разработчик, в основном занимаюсь развитием микросервисов в команде РСХБ «Свои инвестиции». Представьте ситуацию: вы работаете с инвестиционными сделками, обрабатываете миллионы сделок в день, но все они обрабатываются один раз только ночью. А бизнес требует реального времени. Это была наша рутина, пока мы не внедрили Kafka Streams. В этой статье я расскажу о том, как мы трансформировали систему обработки сделок на фондовом рынке (SOFR) с batch-обработки на полноценную real-time систему, способную обрабатывать миллионы сделок в сутки.

Представьте: вы разрабатываете антифрод-систему для банка. Пользователь совершает пять покупок подряд за пару минут. Все транзакции успешно попадают в Kafka, никаких ошибок, consumer lag почти нулевой, Flink работает стабильно.

Но модель выдачи решений получает на вход признак: transactions_in_10_minute_window = 3 Хотя по факту их было пять, а вместо вероятности мошенничества 0.91 она выдаёт 0.42.

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

Теперь настало время ответить на практический вопрос: как все эти метаданные связать в единую систему, чтобы несколько движков могли работать с одними и теми же таблицами без хаоса. Помимо теории развернем HMS в Docker, настроим PyIceberg и разберем внутреннюю анатомию файла metadata.json.

Привет! Я Денис, старший бэкенд-разработчик в Selectel. Надеюсь, материал будет полезен инженерам данных и архитекторам. Мы рассмотрим Hive Metastore, AWS Glue, REST Catalog и Nessie и расскажем как выбрать подходящий инструмент под специфику проекта.

Всем привет! Меня зовут Александр Цай, я ведущий инженер-аналитик в МТС Web Services.
Занимаюсь всем, что связано с данными и ИИ. Найти, заполучить, обработать, спроектировать, развернуть — это все ко мне.

Опущу все нудные подробности, решили мы развернуть себе Superset 6.1.0 — последнюю версию, но столкнулись с тем, что заказчику категорически не нравится штатный фильтр по датам и он не хочет пересаживаться со своего BI, а хочет он календарик. А еще — пару плагинов с оглядкой на PowerBI. Поэтому встал вопрос создания собственного плагина-фильтра.

Казалось бы, задача несложная. Пара-тройка гайдов в en сегменте имеется, есть даже документация и штатный генератор шаблонов. Но по факту оказалось, что все это не работает. Генератор так вообще не обновлялся аж с 2024 года: выдает шаблон, который ссылается на уже несуществующие классы и типы, что автоматически делает все гайды неактуальными…

А что все это значит? Время написать свой собственный!
Об этом и расскажу в сегодняшнем материале. 

Дисклеймер: Я питонист до мозга костей и в тайпскрипте, да и фронте в целом, понимаю не очень много. Простите меня, адепты сего языка программирования, но код самого плагина навайбкожен (хоть и проверен насколько я смог).
В npm не запушил тоже умышленно, цель статьи — дать исходники и показать, как можно собрать плагин. Любой желающий может что-то додумать и доработать, собрать или разобрать и так далее.

Как я встроил 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.

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

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

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

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

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

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