Apache *

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 и к идее построения собственной платформы данных.

Начнем с того, как микросервисы могут общаться? На самом деле все просто, сложные приложения могут состоять из нескольких разных микросервисов.

Каждый сервис будет иметь свою логику, свою ответственность. Сервисы одной системы могут быть написаны на разных языках программирования. Однако это не будет мешать им общаться. Так вот общение это буквально - обмен информацией. Обмен сообщениями определенного формата, который смогут понять все сервисы. Это похоже на общение между нами. Я говорю что-то собеседник слушает информацию, дальше обрабатывает ее неким образом своим мыслительным аппаратом и формирует ответное сообщение и проговаривает его вслух адресуя голос в направлении оппонента. Для отправки сообщения нам людям, нужно знать адресата или видеть его, для того, чтобы обратиться к нему.

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

Переводим нашу платформу с JSON на Apache Avro и Schema Registry. Заменяем сериализаторы и десериализаторы, генерируем классы из схем и разбираем разницу между GenericRecord и SpecificRecord.

Практика на реальном проекте.

На старте у клиента уже были дашборды, но они не закрывали текущие задачи бизнеса. Данные находились в разных системах — 1С, Excel, Google Таблицы, XML-выгрузки и внутренняя система.

Клиент принял решение выстроить аналитику заново и выбрал Apache Superset как инструмент визуализации. Сначала собрали единый слой в PostgreSQL, настроили загрузку через Python, привели метрики к одной логике и зафиксировали правила расчётов.

После этого уже собрали дашборды под управленческие задачи клиента. Визуализация строилась так, чтобы быстро находить отклонения и принимать решения, а не просто смотреть отчёты.

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

Привет, Хабр! Расскажу, как мы спасли крупный новостной сайт ugra-news.ru от постоянных падений — без покупки нового железа и переписывания с нуля. Только точечные оптимизации, знание архитектуры Битрикс и немного детективной работы. Приступим.

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

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

JMX-файл на 50 000 строк, merge-конфликты при каждом коммите и PR-ревью, которое никто не читает - знакомо? Я столкнулся с этим на реальном проекте и нашёл способ декомпозировать JMeter-тесты так, чтобы основной файл похудел в 10 раз, а работать с тестами стало можно прямо из IDE.

В этой статье продолжаем борьбу с фильтрами по дате в Apache Superset. Сегодня разберем, как реализовать подобие логики remove_filter в старых версиях (до 5), чтобы виртуальный датасет не оборачивался фильтрами.

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

Меня зовут Елизавета Колесникова, и вот уже 4 года я работаю системным аналитиком СПАО «Ингосстрах»

Этой статьёй я бы хотела начать серию материалов для аналитиков и разработчиков, которые только начинают свой путь в ИТ.

Когда-то я сама жестко плавала в бульоне ИТ-терминов, а также тыкалась по разным сайтам в поисках подходящей информации, как слепой котенок, без возможности соединить воедино полученные данные таким образом, чтобы моих интеллектуальных ресурсов хватило для написания ТЗ. Толковых гайдов и памяток я не находила, в основном попадалась или сухая теория, или жидкая вода. Поднабравшись немного опыта, я решила составить серию памяток, где буду расписывать ключевые вопросы, которые помогут начинающим специалистам разобраться, как писать ТЗ по интеграциям.

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

В этой статье хотелось бы начать раскрытие больной для многих пользователей Apache Superset темы — фильтры по дате. Начнем с малого: как суперсет выбирает колонку даты; как выбрать желаемую колонку вместо той, которую он выбирает; каким образом это реализовано; какие баги породили этим решением; почему КОП не доведет до добра.

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

Представим типичную ситуацию. Есть таблица с десятками колонок и миллионами строк. Нужно понять, почему изменился какой-то показатель — например, выручка или конверсия. Обычно это превращается в цепочку SQL-запросов: сначала агрегируем данные по стране, потом по городу, потом по конкретному сегменту пользователей и тд.

Если таких гипотез несколько, количество запросов быстро растёт с геометрической прогрессией. Каждый новый уровень детализации требует отдельного SQL.

В какой-то момент хочется просто кликнуть по графику и мгновенно увидеть более детальные данные. Без написания нового запроса.

Именно здесь на помощь приходят BI-инструменты. Один из самых популярных open-source инструментов для аналитики — Apache Superset.

Почему использование JSON как формата сообщений может стать узким местом в высоконагруженных системах? Что такое Apache Avro и Schema Registry?

Простым языком об этих технологиях, их работе и причинах их возникновения.

В 2021 году Databricks ввели в моду термин «lakehouse», и индустрия дружно решила, что это и есть будущее. Аналитики писали восторженные статьи о том, что классические DWH мертвы. Вендоры спешно проводили ребрендинг своих продуктов, а на конференциях обещали единую архитектуру, которая решит вообще любые проблемы с данными.

Некоторые обещания Lakehouse сбылись. Другие оказались лишь маркетингом. А еще всплыли проблемы, которых никто не ожидал.

В этой статье разберем честный опыт внедрения Lakehouse к 2025 году: какие обещания оказались маркетингом, почему расходы на вычисления часто растут вместо экономии, и как на самом деле выглядит прагматичная работа с Delta Lake, Iceberg и Hudi в современных проектах. Что выжило в продакшене, что тихо скончалось, а о чем принято помалкивать?

Разбираемся как Apache Iceberg проводит Insert запрос и что происходит под капотом. Поднимем локально через Docker несколько образов и посмотрим на мета данные, которые генерируются.