"Дайджест статей 📰 Почему 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."