"Дайджест статей 📰 Наш стек сквозной аналитики для SaaS-сервиса: коннекторы, хранилище, BI 🔗 https://habr.com/ru/articles/1068254/ 💡 Вывод: На длинном цикле сделки честная оценка окупаемости трафика требует когорт по дате первого касания, а не деления бюджета месяца на продажи того же месяца: такая арифметика систематически занижает ранние месяцы. Единственный ключ связывания, переживающий переименования кампаний, это CampaignId в utm_campaign, а перед постройкой витрин проверять надо стык ""обращение - сделка"": именно там BI начинает красиво визуализировать дыру в данных. Четыре сверки целостности (клики vs визиты, формы vs обращения, витрина vs CRM, продажи без источника) стоят дешевле любого дашборда. 📰 Как я встроил AI-агента прямо в интерфейс Apache Superset и не сломал ему CSP 🔗 https://habr.com/ru/articles/1066586/ 💡 Вывод: Ключевое решение при встраивании агента в BI не выбор модели, а наследование модели прав: автор сознательно отказался от штатного MCP-сервера Superset, потому что тот в дефолтной конфигурации работает от админа без авторизации, и любой пользователь получил бы доступ к данным с админскими правами. Агент, выполняющий SQL, обязан работать от имени того, кто нажал кнопку, с трёхуровневым read-only гардом. Это чек-лист вопросов к любому вендору ""AI в вашем BI"". 📰 Двигаем PostgreSQL в сторону OLAP: оптимизация параллельного вычисления агрегатов 🔗 https://habr.com/ru/companies/tantor/articles/1066692/ 💡 Вывод: Прототип shared-memory агрегации по мотивам PVLDB 2025 даёт до 4.8x ускорения на равномерных данных, но проваливается до 0.04x при перекосе 95% на одну группу: процессная модель Postgres платит за разделяемое изменяемое состояние кратно больше, чем тредовые движки, ради которых метод придуман. Практическое следствие для владельцев data-платформ: решения ""растянем Postgres на OLAP"" упираются в фундамент архитектуры, а безопасное применение таких оптимизаций требует качественной MCV-статистики и cost-based выбора стратегии, то есть зрелости эксплуатации, а не одной фичи. 📰 База встала под нагрузкой: как найти, кто кого блокирует в PostgreSQL 🔗 https://habr.com/ru/companies/otus/articles/1065588/ 💡 Вывод: Картина ""приложение задыхается, база отдыхает"" почти всегда означает не нехватку железа, а длинные транзакции, которые через блокировки исчерпывают пул соединений и роняют сервис целиком. Дешёвая страховка, которую стоит требовать включённой на каждом prod-инстансе: log_lock_waits, idle_in_transaction_session_timeout и lock_timeout на любой DDL. Это превращает разбор инцидента из детектива в чтение лога и снимает типовой класс аварий до их наступления. 📰 Lightdash — BI, который живёт внутри вашего dbt-проекта 🔗 https://habr.com/ru/articles/1067570/ 💡 Вывод: Проблема ""три разных цифры выручки на одном созвоне"" решается не инструментом, а переносом определений метрик в код: в Lightdash семантика живёт в YAML dbt-проекта, проходит ревью, версионируется и валидируется в CI как обычный код, а RLS/CLS описываются рядом с данными. Ограничение честно названо: валидатор проверяет ссылки и определения, но не исполняемый SQL. Для оценки: это паттерн metrics-as-code в чистом виде, применимый и без конкретного вендора. 📰 Anthropic is telling you that Agentic Analytics is not just text-to-SQL 🔗 https://medium.com/data-science-collective/anthropic-is-telling-you-that-agentic-analytics-is-not-just-text-to-sql-ce605454bbc9 💡 Вывод: Автор вводит термин ""analytics slop"": подключение агента к базе снижает барьер входа в анализ, но никто не проверяет полученные цифры, потому что беглость LLM в SQL создаёт ложное чувство корректности. Позиция Anthropic, которую автор пересказывает: доверенная агентная аналитика это semantic layer, skills, evals и классический data engineering до того, как модель коснётся запроса. Флаг: заявленные 95% точности — самоотчёт вендора через вторичный источник, независимой проверки нет; полный текст Medium обрезал, разбор по вводной части."