Дайджест статей


📰 Почему Big Data стек небезопасен по своей природе
🔗 https://habr.com/ru/articles/1030842/
💡 Разбор доклада Sheila A. Berta (Black Hat 2021): основные уязвимости Big Data-инфраструктур живут не внутри компонентов, а на стыках. HDFS, Spark, ZooKeeper, ClickHouse — каждый строился под "доверенную среду", и атака превращается в навигацию: ZooKeeper отдаёт карту кластера, Spark/YARN дают исполнение кода, дальше — данные.
Вывод: Attack surface растёт быстрее архитектуры; безопасность отдельных сервисов не работает без единой модели доверия между слоями и регулярной чистки "цифрового мусора" (старые пайплайны, реплики, забытые доступы) — иначе в какой-то момент данных становится больше, чем контроля.

📰 Почему 70% BI-систем не окупаются: 5 фатальных ошибок
🔗 https://habr.com/ru/articles/1027986/
💡 Пять типичных провалов: ожидание "магической кнопки", культ красивых графиков, отсутствие data quality, слепое исполнение запросов вместо диалога с заказчиком, отсутствие версионирования дашбордов.
Вывод: BI — зеркало бизнеса, а не его хирург; окупаемость появляется только при чистых данных, простых дашбордах под конкретный бизнес-вопрос и регламенте на каждый отчёт (владелец, версии, аудит). Без этого получаешь 200 дашбордов "Отчёт_новый_финальный_v15" с расхождениями 20% по одному и тому же KPI.

📰 Управление данными в ERP-проектах на основе DAMA-DMBoK
🔗 https://habr.com/ru/articles/1028864/
💡 Обзор: 11 областей знаний DAMA-DMBoK (от моделирования и качества до руководства и метаданных) ложатся на пирамиду Питера Айкена и фазы ERP-внедрения. Управление данными — отдельный бизнес-процесс уровня закупок и финансов, не разовая активность.
Вывод: DMBoK — рабочая карта для ERP-проектов, но порядок применения важнее охвата: фундамент (моделирование, хранение, качество) → метаданные и архитектура → governance. Попытка начать с governance без чистого слоя 1–2 даёт красивые регламенты на грязных данных.

📰 A "meshy" approach to Data: Enabling 100+ teams to build Data Models (Monzo)
🔗 https://monzo.com/blog/a-meshy-approach-to-data
💡 Monzo перестроил dbt-warehouse (12 000+ моделей, 100+ команд) на трёх принципах: opinionated стандарты, формализованные interfaces между командами, автоматизация в CI вместо ручного gatekeeping. Слои landing → normalised → logical → presentation, межкомандный обмен — только через явно объявленные контракты. Первые результаты — ~40% снижение стоимости warehouse и ~25% ускорение поставки данных в ряде доменов.
Вывод: При масштабе data mesh централизованное владение не работает, но и анархия тоже — выход в том, чтобы перенести "правильность" в инструменты (model-gen из YAML, CI-проверки на unique key, freshness, инкрементальность). Это самый трезвый кейс по data mesh за последний год: не манифест, а архитектура.

📰 DuckLake 1.0: Data Lake Format with SQL Catalog Metadata
🔗 https://www.infoq.com/news/2026/05/ducklake-sql-catalog/
💡 DuckDB Labs выпустили production-ready формат лейкхауса, хранящий метаданные таблиц в SQL-базе, а не россыпью файлов в object storage (как Iceberg/Delta/Hudi). Главные фичи — data inlining (мелкие insert/update/delete пишутся прямо в каталог, без small files), сортировка, bucket-партиционирование, deletion vectors совместимые с Iceberg.
Вывод: Серьёзный challenger Iceberg для команд, которым критичны быстрые мелкие записи и простая операционка; компромисс — SQL-каталог это и сила (скорость), и новая точка отказа (ещё одна БД в архитектуре). Для on-prem и средних объёмов "лейкхаус из коробки" может оказаться дешевле и быстрее всей экосистемы вокруг Iceberg.

Вышел Quack от DuckDB протокол превращающий эту in-process локальную базу данных в серверный вариант. У меня лично и в мыслях не было использовать DuckDB как серверную СУБД, в моем понимании это скорее инструмент доступа к данным (query engine) чем база данных, но у меня свои кейсы, а других свои. Надо подумать как эти новые функции можно применить на практике.

#opensource #rdbms #datatools

Итак, сегодня проходим закон Конвея, выполнение которого я видел в любой организации, где имел опыт разработки ИТ систем :)

Как StarRocks защищает production от перегрузки. Query Queues

В прошлых постах я рассказывал про Multi-Warehouse и про Resource Groups. Сегодня третья часть, и она отвечает на вопрос, которым предыдущий пост закончился: что делает кластер, когда запросов прилетает больше, чем все группы вместе способны обработать?

Представим ситуацию: в кластер одновременно приходит 500 тяжёлых запросов. Resource Groups поделят между ними CPU и память, но сами запросы всё равно продолжат конкурировать друг с другом. В результате всё начинает замедляться: растёт latency, память забивается, появляется риск OOM и каскадной деградации.

В этом случае помогут Query Queues. Это механизм back-pressure: когда нагрузка превышает возможности кластера, лишние запросы встают в очередь со статусом PENDING. Как только ресурсы освобождаются, запрос запускается. Кластер обрабатывает поток порциями ровно настолько, насколько у него хватает ресурсов.

По сути:
1️⃣ Resource Groups отвечают на вопрос: кому сколько ресурсов
2️⃣ Query Queues: кого вообще пускать на выполнение

Запрос уходит в очередь, если превышен любой из порогов:
🔹 число выполняющихся запросов на BE
🔹 использование памяти на BE
🔹 загрузка CPU на BE

Работает это на двух уровнях:
🔹 глобальная очередь, на весь кластер
🔹 очередь внутри Resource Group, отдельно для каждого класса нагрузки

Например, можно ограничить ETL пятью одновременными запросами, а BI-дашборды 50 запросами. Запрос стартует только тогда, когда одновременно свободны и глобальный лимит, и лимит его группы.

При этом StarRocks смотрит на реальную загрузку кластера. Каждый BE регулярно отправляет FE статистику по памяти и числу выполняющихся запросов, а Leader FE собирает единую картину нагрузки по всему кластеру. Без этого разные FE могли бы независимо принять слишком много запросов одновременно.

Примечание. Выше описано поведение Query Queues v1 (с порогами на ресурсы BE). С версии StarRocks 3.3 есть v2 на логических слотах: каждый запрос занимает какое-то их число в зависимости от веса, и в очередь попадают те, для кого слотов сейчас нет. В StarRocks 4.1 v2 включён по умолчанию. Принцип back-pressure общий для обеих моделей.

Ещё пара нюансов:
🔹 Если запрос не помещается в очередь или ждёт слишком долго, он получает явную ошибку, клиент сразу видит отказ.
🔹 Query Queues не ускоряют запросы и не оптимизируют планы, а только регулируют, кого пускать на выполнение прямо сейчас.

Как включать и какие параметры настроить, см. документацию StarRocks (en, ru).

В следующем посте рассмотрим Pipeline DOP: как StarRocks подстраивает параллелизм запроса под текущую загрузку.

Ставьте 🔥, если материал был полезен.

#StarRocks #Selena #MPP #DataArchitecture #Lakehouse #DataEngineering #starrocks_tutorials

Дайджест статей

📰 RAG в энтерпрайзе: почему демо работает, а прод нет
🔗 https://habr.com/ru/articles/1038670/
📝 О чём: разбор причин, по которым RAG-прототип ломается в проде. Проблемы чанкинга длинных таблиц, эмбеддинги, не знающие корпоративный жаргон, ненадёжность top-k и cosine similarity, парсинг PDF и сканов, проброс ACL в метаданные, multi-hop запросы и сложность оценки качества без ground truth. В конце — набор приёмов: сужение домена, гибрид BM25 + векторный поиск через RRF, вынос структурированных данных в SQL.

📰 The Death of Traditional ETL: How AI Agents Are Rewriting Data Engineering (по метаданным)
🔗 https://medium.com/@arrufus/the-death-of-traditional-etl-...
📝 О чём: статья об использовании ИИ-агентов в data engineering. По доступному фрагменту — сценарий, где при изменении схемы выше по потоку ломается downstream-консьюмер, и агент берёт на себя трассировку lineage и починку джоба.

📰 Как мы построили сквозную аналитику в Power BI
🔗 https://habr.com/ru/articles/1038944/
📝 О чём: кейс интегратора VSL-BI для компании по продаже стройматериалов. Сбор данных из Яндекс.Директ, Google Ads, Яндекс Метрики и Битрикс24 в отдельную аналитическую БД на MySQL, загрузка через Python, объединение продаж и рекламных источников по UTM-меткам, построение модели данных и дашбордов в Power BI с метриками ДРР, CpC, CpL, CR.

📰 OCR для Data Lakehouse: от Apache Tika к Docling
🔗 https://habr.com/ru/companies/diasoft_company/articles/1039044/
📝 О чём: путь команды Диасофт от Apache Tika + Tesseract к собственному сервису парсинга документов на базе docling-serve. Описана гибридная архитектура: лёгкий анализ структуры (Layout, TableFormer, Figure Classifier) локально, тяжёлая VL-модель — за внешним шлюзом Digital Q.GPT по OpenAI-протоколу. Рекурсивная обработка вложений, OCR изображений внутри Office-документов, бенчмарки по скорости, CER и потреблению ресурсов в Kubernetes.

📰 Бизнес-аналитика для сети из 300 аптек
🔗 https://habr.com/ru/companies/w_code/articles/1039952/
📝 О чём: внедрение BI-системы интегратором «Белый код» для аптечной сети поверх «СмартАптеки». Пять витрин — оперативный мониторинг с почасовым обновлением, сводка по сети с KPI и LFL, продажи с цветовой индикацией, остатки с drill-down, финансы. Прогноз продаж на день и месяц с учётом времени последней продажи в каждой точке, отдельный мобильный дашборд.

📰 ИИ в работе с данными: почему без человека пока никак
🔗 https://habr.com/ru/companies/yandex_praktikum/articles/1039950/
📝 О чём: пересказ вебинара Яндекс Практикума о применении ИИ аналитиками и дата-сайентистами. Сценарии использования (борьба с «белым листом», ревью кода, саммари по данным, второе мнение), обзор инструментов (чат-боты, Perplexity, NotebookLM, ИИ-агенты) и ограничения: ИИ не учитывает корнер-кейсы, чувствителен к формулировке запроса и не понимает доменный контекст.

📰 Inside AI Meetup (Wildberries) — записи докладов
🔗 https://habr.com/ru/companies/wildberries/articles/1040624/
📝 О чём: анонс с видеозаписями и презентациями митапа Wildberries & Russ от 20 мая. Доклады по AIOps на платформе KeepHQ, автоматическим guardrails (МФТИ), Discovery-платформе VK, отекстовке видео, поиску вакансий на Avito, ИИ-платформе M2, векторной модерации с 200+ моделями и RAG-ассистенту MWS на QWEN3-8B, BGE-M3 и гибридном поиске Vector + BM25 через RRF.

Это случилось: Vitess для PostgreSQL. Чувак, который делал Vitess (шардинг из коробки, MySQL@YouTube) - Sugu Sougoumarane - теперь в Supabase, и они открывают вот такое:

https://supabase.com/blog/multigres-v0-1-alpha

Если кратко, это Vitess для PostgreSQL: шардинг из коробки, пул соедиений, HA.

Дайджест статей

📰 База знаний для распределённых производств: как синхронизировать филиалы
🔗 https://habr.com/ru/companies/teamly/articles/1043664/
💡 Вывод: Локальная вики на каждой площадке не лечит рассинхронизацию знаний, а множит её: версии расходятся, обновления не доходят, администрирование съедает ресурс. Работает не ещё один портал, а единая точка входа плюс управленческое правило «новые регламенты публикуются только здесь». И формализовать стоит не всё подряд, а сценарии с высокой частотой и высокой ценой ошибки, где экономический эффект прямой.

📰 Как Data Fabric и HTAP превращают сырые данные в бизнес-события для мгновенной аналитики
🔗 https://habr.com/ru/companies/vk/articles/1044946/
💡 Вывод: Ускорение ночного ETL до почасового разрыв не закрывает: растёт стоимость инфраструктуры, а сырые события всё равно нужно обогащать смыслом в момент возникновения. Если бизнесу нужен ответ в день запуска продукта, а не на следующее утро, проблема архитектурная. Связка не заменяет DWH, а делит роли: HTAP держит оперативные 7–30 дней, DWH остаётся для истории и ML, Data Fabric обогащает и доставляет.

📰 Tarantool DataBase и Kafka: событийная архитектура без лишних слоёв
🔗 https://habr.com/ru/companies/vktech/articles/1045344/
💡 Вывод: Самописный сервис синхронизации, это скрытый постоянный налог: мониторинг, redelivery, риск потери и дублей, переделка при каждом изменении схемы. Аргумент за готовый CDC сводится к стоимости владения и time-to-market. Но читать его стоит честно: это не «удаление слоя интеграции», а замена своего слоя на вендорский, и выгода реальна там, где нет специфичных требований к ландшафту.

📰 «К нам едет ревизор», или Как не построить космические замки на бюджете сарая при внедрении DWH
🔗 https://habr.com/ru/companies/glowbyte/articles/1046548/
💡 Вывод: Состав артефактов предпроектного обследования определяется его целью, а не «лучшими практиками»: для решения о запуске нужна аргументированная презентация на 25–30 слайдов, для тендера — требования, архитектура, сайзинг и TCO на 3–5 лет. Позиция заказчика «вы эксперты, вам виднее» чаще означает не доверие, а попытку снять с себя ответственность за решения. И отдельно сильное: Agile, прекрасный для проектов развития, на greenfield-запуске DWH растягивает срок втрое.

📰 Как я собрал эталонный Data Engineering проект: ClickHouse, Kafka, Spark, dbt, Airflow и Superset за одну команду
🔗 https://habr.com/ru/articles/1047304/
💡 Вывод: Ценность проекта не в списке инструментов, он у всех одинаковый, а в операционной дисциплине, которая делает «одну команду деплоя» работающей: идемпотентность на каждом шаге, graceful degradation для необязательных стадий, честный список version-конфликтов. Разделение ответственности тоже по делу: dbt для SQL-трансформаций, Spark для того, что горизонтально масштабируется. Бонус для CROSSx-контекста: данные крипто, паттерны детекции аномалий рабочие.