Привет.

Здесь публикую короткие технические заметки и анонсы статей по теме DWH, Managed DBA и open-source data-стека.

Кто пишет: Максим Юдин, основатель WARP.D. 30 лет в инфраструктуре данных - банки, ритейл, ИТ-интеграция.

Что в канале:

▪️ Анонсы новых статей на warpd.ru/blog и Habr с тезисами
▪️ Короткие технические заметки из текущей работы
▪️ Разборы интересных production-инцидентов
▪️ Реакции на отраслевые релизы (ClickHouse, Apache Iceberg, Trino, MS SQL Server)

Тематика: MS SQL Server, ClickHouse, Apache Iceberg, Trino, BI-системы, архитектура хранилищ данных, Managed DBA. Без маркетинговой воды и хайпа.

Если у вас задача по DWH, Managed DBA или архитектуре - пишите @maxpiter или используйте бот @warpd_dataing_bot для структурированной заявки.

💭 Заметка

Почему дашборды на боевой OLTP - это техдолг, не MVP или «Подключим Power BI на пару недель» - сценарий на 3 года

Типичная история: компании нужна аналитика. Бюджета и времени на DWH нет.

Решение: подключаем Power BI или Apache Superset напрямую к продакшен-MS SQL / Oracle / PostgreSQL и строим дашборды.

Звучит как разумный «MVP». На практике это «MVP» который потом годами не могут переделать на нормальную архитектуру.

Что начинает происходить через 2-3 месяца после такого старта:

1. Локи разрастаются. Аналитический запрос на годовую выборку забирает page-locks на таблицах, которые сейчас пишет основной бизнес-процесс. Кассы тормозят, заказы зависают, генеральный звонит DBA.

2. Plan cache засоряется. OLTP-движок оптимизирован под повторяемые запросы по индексам. Аналитические запросы каждый раз другие, заставляют перекомпилировать планы. Cache hit-rate падает, CPU растёт.

3. Transaction log пухнет. Длинные read-запросы держат RH-locks на странице, blocking growing transactions, log не truncate'ится по графику. Backups стали по 8 часов вместо 2.

4. Дашборды тормозят. Параллельно с пунктами выше, сами дашборды показывают цифры за 30+ секунд вместо ожидаемых пары секунд. Пользователи отказываются ими пользоваться.

Лечится только построением отдельного аналитического слоя. Минимум - выделенная схема analytics с агрегатными таблицами, обновляемая ночными джобами + Columnstore-индексы (если SQL Server) или In-Memory Column Store (если Oracle). Максимум - полноценное хранилище.

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

В наших проектах WARP.D первый разговор с клиентом, у которого «Power BI на боевой» - не «давайте делать DWH», а «давайте оценим что у вас сейчас вообще не работает и от чего отказаться в первую очередь».

#заметка #mssql #dwh

📰 Релиз

ClickHouse 26 пишет Iceberg как production. Подключать напрямую или копировать в MergeTree?

С релизами 25.7-25.9 ClickHouse научился полноценно читать и писать Iceberg, а в 26.2 (февраль 2026) запись в Iceberg перестала быть experimental - стала production-ready. Теперь можно использовать в боевых системах, не оглядываясь на статус «пробуем».

Что конкретно появилось за последние месяцы:

▪️ Запись (INSERT) в Iceberg - production (26.2)
▪️ Создание новых Iceberg-таблиц прямо из ClickHouse через CREATE TABLE (25.8)
▪️ ALTER DELETE и ALTER UPDATE - можно изменять данные в существующих Iceberg-таблицах (25.8-25.9)
▪️ Equality deletes - механизм для CDC-сценариев, чтение появилось в 24.12, полная поддержка с 25.8
▪️ Distributed writes - запись параллельно с нескольких нод (25.9)

Каталог - подключаемся к существующему

Своего каталога метаданных ClickHouse не навязывает. Через DataLakeCatalog engine он цепляется к тому, что у вас уже есть: REST-каталог (Nessie, Polaris), Unity Catalog, AWS Glue, Hive Metastore. Сценарий из жизни: Iceberg-таблицы лежат в S3, метаданные ведёт Nessie. ClickHouse подключается к Nessie как REST-клиент и видит те же таблицы, что Spark и Flink. Никакого дублирования каталогов или синхронизации между ними.

Известная боль из практики: REST-catalog в ClickHouse сейчас не работает с иерархическими namespace - это распространённая структура, когда внутри namespace есть точки, например prod.warehouse.sales (баг [#93464](https://github.com/ClickHouse/ClickHouse/issues/93464)). Если у вас в Nessie или Polaris такая структура - ClickHouse может не увидеть таблицы из нижних уровней. Перед миграцией обязательно проверить. Лечится либо ожиданием фикса, либо временной плоской структурой namespace.

Главный вопрос релиза

Подключать ClickHouse напрямую к Iceberg или продолжать копировать данные в нативный MergeTree?

ClickHouse - это OLAP-движок для дашбордов и отчётов end-user. Его задача - отдавать запросы за миллисекунды-секунды и держать тысячи параллельных пользователей BI-системы. На такой работе физика хранения данных решает многое:

▪️ Native MergeTree - локальный column-storage на диске самой ClickHouse-ноды, родные codec'и сжатия, skip-индексы и projections (всё это - оптимизации ClickHouse под колоночное хранение). Запросы быстрые, оптимизатор раскрывается полностью.
▪️ Iceberg напрямую - данные в Parquet через S3, чужой формат, сетевой round-trip к S3 на каждом запросе. Skip-индексы и projections ClickHouse тут не работают, оптимизатор может опираться только на Iceberg-метаданные.

Разница в скорости на типичных BI-запросах - порядок-два. То есть запрос, который из MergeTree отдаётся за 200мс, из Iceberg напрямую легко уходит в 5-30 секунд. Это не «ClickHouse медленный над Iceberg», а несовпадение storage-формата с потребностями serving-слоя.

Когда что использовать

В проектах, где ClickHouse держит BI-нагрузку, расклад такой:

▪️ Дашборды и отчёты для end-user - только нативный MergeTree. Копируем из Iceberg инкрементально, под свой регламент refresh.
▪️ Ad-hoc-запросы аналитика на stage - Iceberg напрямую оправдан. Не каждый день, без жёстких SLA, исследовательский характер. Заводить копию ради этого нет смысла.
▪️ Один тяжёлый отчёт раз в день - пограничный случай. Можно жить на Iceberg-direct, можно держать мини-MergeTree-копию под этот отчёт. Зависит от того, сколько готовы ждать ответа.

Ограничение про V3-формат Iceberg

У формата Apache Iceberg есть несколько версий: V1 (базовая), V2 (добавила equality deletes для CDC) и V3 (новые фичи - deletion vectors как эффективный способ помечать удалённые строки, lineage, и другое).

В ClickHouse сейчас работает только V2. Если ваши таблицы созданы как V3 и используют V3-only-фичи (в первую очередь deletion vectors) - ClickHouse их просто не прочитает, выдаст ошибку. Это не «прочитает с ограничениями», а «откажется работать с такой таблицей». Поддержку V3 обещают после полного покрытия V2, конкретных дат пока нет. Вариантов два: ждать, либо держать таблицы в V2-формате.

Резюме
Маркетинг ClickHouse в этом релизе даже скромнее реальности. Звучит как «теперь читает и пишет», а пользоваться можно полноценно. Серьёзный stack-design при этом не меняется: Iceberg остаётся хорошим форматом для stage и архивных слоёв, MergeTree - для serving-слоя под BI. ClickHouse 26 - удобный мост между ними, а не замена самой идеи моста.

Конкретные цифры «где порог переключения», «какие codec'и MergeTree дают наибольший выигрыш» и «как минимизировать копирование инкрементальной выгрузкой» - разберу отдельным постом.

#релиз #clickhouse #iceberg #lakehouse

За тридцать лет в DBA у меня было примерно пятнадцать настоящих инцидентов. Тех, после которых я в одну минуту бросал всё и искал ближайшее интернет-кафе или доставал планшет прямо на улице.

И тысячи других алертов, которые пришли и были проигнорированы без последствий.

Соотношение - один к пятистам.

Вопрос, который я задаю каждому клиенту первым: как ваша команда отличает тот единственный важный алерт от пятисот остальных?

В девяти случаях из десяти ответа нет. И это - сегодняшняя болезнь индустрии.

Давайте посмотрим, что произошло:

1. Слово «критичный» превратилось в украшение

Каждая команда называет «критичными» свои алерты, потому что они их боятся. В итоге у вас 800 «critical» в день, и единственный способ выжить - не реагировать. Включая и тот один, который реально важен.

2. Менеджмент покупает покрытие, а не "таргетированную важность"

Тендер на observability оценивается по охвату: «покрываем 100% метрик», а не по тому, что у вас 5 действительно критичных алертов в неделю и каждый ведёт к реальному действию. Первое продаётся, второе - нет.

3. Усталость передаётся по наследству

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

Правильный алертинг устроен одним способом: если мир не рухнул, всё может подождать.

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

В компаниях, где я бываю с аудитом, первый шаг - выкидываем 80% существующих "алертов" и оставляем те самые 5 в неделю. И тогда оставшиеся 5 становятся снова заметными.

Хороший мониторинг - не тот, который видит всё. Хороший мониторинг - тот, который молчит, пока не случилось что-то, ради чего нужно бежать в ближайшее интернет-кафе.

📢 Анонс

Идеальный failover в AlwaysOn AG. И 7,5 часов скрытого простоя.

Воскресенье, 06:50. SQL Server AlwaysOn отработал безупречно: 4 секунды на переключение, secondary в SYNCHRONIZED, listener перебиндился. Microsoft бы поставил пятёрку.

Ручной failback - в 14:24. Семь с половиной часов между двумя точками. Бизнес-системы «вроде бы» работали. Алерты шли - только не туда, где их могли бы интерпретировать в правильном контексте.

Главная опасность не в видимых сбойных джобах. Главная опасность - в данных. За 7,5 часов ETL-процессы либо не отрабатывали, либо работали на неконсистентном source-state. Смежные корпоративные системы могли получить пропущенные batch'и, частичные данные, рассогласованность - такую, которая всплывает только при reconciliation в конце периода.

Длинный разбор только что вышел: https://warpd.ru/blog/alwayson-failover-7h/.

Что в нём:

- Четыре независимых триггера failover, которые DBA путают друг с другом
- Почему SameSubnetThreshold=20 не спас от потери кворума
- Как обвязка AG превращает «failover за 30 секунд» в часы потенциальной рассогласованности данных
- Что меняет Contained AG в SQL Server 2022 и какие новые failure modes он создаёт
- Чек-лист зрелости AlwaysOn AG из 13 пунктов

Это первая статья серии «AlwaysOn AG в 2026». За ней пойдут разборы иерархии таймаутов, дизайна кворума и witness, и пяти параметров AG, которые лучше не трогать.

Подписывайся, если занимаешься SQL Server в проде - в серии будет вся «обвязочная» правда, о которой Microsoft не пишет в документации.

#анонс #alwayson #mssql #dba

📢 Анонс

Что услышал инженер с Data Summit 2026

На прошлой неделе в Бостоне прошёл Data Summit 2026 - конференция, где собираются те, кто принимает архитектурные решения, а не продаёт слайды. Записал три тезиса, которые касаются всех, кто проектирует данные в 2026 году:

🔹 Стек схлопывается, но не так, как говорят со сцены. Sanjeev Mohan заявил, что граница между OLTP и аналитикой растворяется. Согласен наполовину: пускать AI в боевую базу - способ организовать инцидент. ETL никуда не денется, но классический ночной батч умирает. На его место приходит CDC → Kafka → Iceberg с задержкой в секунды.

🔹 Retrieval - новая инженерная дисциплина. Бизнес-пользователь больше не хочет открывать дашборд, он хочет напрямую спросить у AI. Аналитической головы между данными и ответом больше нет, её место занял слой retrieval. Это работа для data engineering, не для AI-команды. И главное - отчёты при этом никуда не денутся, они становятся слоем верификации.

🔹 Bring AI to your data. 97% предприятий планируют построить собственную data + AI платформу в ближайшие 3 года. Для российского рынка после санкций это уже не выбор, а единственный реалистичный путь. Технологически всё готово: open-source модели сравнялись с проприетарными.

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

🔗 warpd.ru/blog/data-summit-2026

#анонс #DataEngineering #DWH #Lakehouse