Это разве аналитика?

Безопасность в Iceberg-Lakehouse Берем Iceberg REST Catalog в виде Apache Polaris. Коннектим его к Трино как каталог. При этом передаем общие принципала и креды. Все подключается и успешно создаем, удаляем, работаем со схемами и таблицами. Теперь хотим подцепиться к тому же каталогу через PyIceberg. С теми же кредами. И Ловим 401 на попытке прочитать таблицу? Почему? Потому что PyIceberg честный и спрашивает креды на значимые действия с таблицей. Подчинаяется ролевой модели поляриса в этом плане. А трино просто взял metadata.json из каталога и пошел сам по S3 расшифровывать айсберговскую дату и метадату, никакого разрешения от каталога ему для этого не нужно. Ну и свою ролевую модель поверх наложил. Одна и та же таблица, одна схема подключения, но два представления о прекрасном от двух движков данных. Напоследок - доступные роли в Полярисе, грантов которых PyIceberg от нас ждет. Грантуется это исключительно через CURL. # Доступные права в поларис [ CATALOG_MANAGE_ACCESS, CATALOG_MANAGE_CONTENT, CATALOG_MANAGE_METADATA, NAMESPACE_CREATE, TABLE_CREATE, VIEW_CREATE, NAMESPACE_DROP, TABLE_DROP, VIEW_DROP, NAMESPACE_LIST, TABLE_LIST, VIEW_LIST, NAMESPACE_READ_PROPERTIES, TABLE_READ_PROPERTIES, VIEW_READ_PROPERTIES, NAMESPACE_WRITE_PROPERTIES, TABLE_WRITE_PROPERTIES, VIEW_WRITE_PROPERTIES, TABLE_READ_DATA, TABLE_WRITE_DATA, NAMESPACE_FULL_METADATA, TABLE_FULL_METADATA, VIEW_FULL_METADATA ] В другом каталоге Iceberg REST роли могут быть другие. В JDBC/Hive каталогах - вообще своя атмосфера.

Apache Airflow 3.3.0: Stateful Tasks and Multi-Language Support В Airflow 3.3 появился AIP-108 — Language Task SDK. Теперь отдельные tasks можно реализовывать на Java или Go, при этом сам DAG и scheduling остаются в Python. В DAG задача объявляется как stub: @task.stub(queue="golang") Дальше Airflow через Coordinator передает выполнение нужному runtime: JavaCoordinator для JVM или ExecutableCoordinator для Go. При этом задача остается частью Airflow: доступны XCom, Variables, Connections, retries и стандартный logging. Это особенно интересно для команд, где orchestration построен на Airflow, а часть production-кода уже написана на Java или Go. Теперь такую логику не обязательно переписывать на Python или выносить за пределы task model Airflow. Пока Language Task SDK — experimental feature, поэтому API и protocol еще могут меняться. Документация @tldr_data

Поделюсь своими ощущениями по использованию AI агентов. Этап эйфории прошёл. Немножко поподробней про этот этап. У вас есть Claude Code и больше ни у кого его нет. У вас уже настроены MCP ко всем дата-сервисам и базам, и Claude делает за вас 100% работы. Любую задачу вы решаете мгновенно. Коллеги не понимают, что такое Claude Code, и все делают по старинке руками. На их фоне вы просто монстр производительности, даже можете менять и траблшутить Source Code. Дальше компании начинают инвестировать в подписки Claude Code, и уже волей-неволей у всех появляется Claude. Ты им показываешь, как с ним работать и как всё работает. 2–3 месяца — и коллеги уже могут сами использовать MCP и делать PR через агентов. Первый звоночек — обычно что-то вроде: «Ты слишком быстро всё сделал, и агент написал лабуду». То есть надо уже больше смотреть за агентом, всё перечитывать и перепроверять. Особенно сложно это делать, когда открыты несколько активных серий в разных репозиториях с серьёзными изменениями. Также изначально Claude создавал код поверх кода, написанного руками. Этот код очень понятен, ведь ты его сам писал. Но спустя полгода код весь написан уже агентом, и мы уже на 100% зависимы от агента, ведь без него уже очень сложно разобраться, как там всё устроено и как это дело быстро подправить. И теперь мы приходим к тому, что все одинаково умеют использовать агентов, друг другу проверяют PR, пишут огромные простыни текста — что починить, что исправить. То есть человек как proxy между общением агентов. 😄 Вся скорость и производительность выветриваются, и по факту вам надо больше и тяжелее работать. Если раньше вы работали на 120%, а команда лишь на 20%, то теперь это уже 115% на 120%, то есть в лучшем случае вы немного лучше, но какой ценой?! Таким образом, мы пришли к тому, о чём говорили всегда: работы стало больше, задачи стали сложнее, а требования по скорости и качеству — выше. Я вижу на примерах, как растут аппетиты у VP-уровня, особенно когда они сами могут общаться с данными и находить инсайты. Они хотят больше и быстрее. У бизнеса теперь много идей, которые надо внедрить. Да, даже элементарно — частота стендапов возросла до ежедневной, и уже не скажешь «я там ковыряю код», ведь за тебя агент может всё перековырять — сиди и читай, читатель-инженер. Что будет дальше? А дальше требования будут расти. Даже от новичков будут требовать больше. Вам ведь думать не надо — за вас агент думает, поэтому просто сидите и общайтесь с ним, разбирайтесь. Задач будет больше, требований больше, свободного времени меньше. Людей однозначно нужно больше. Агенты ещё те шалунишки — нужен глаз да глаз за ними, а то положат продакшн. Это ещё не так критично в области data, а вот в customer-facing apps — там ещё сложнее. Я спросил агента про известные концепции: Jevons Paradox (Парадокс Джевонса) Чем эффективнее технология, тем больше её потребляют. Производительность выросла → бизнес поднял планку → работы стало больше, а не меньше. Классика, описанная ещё в 19 веке применительно к паровым машинам. Automation Bias Склонность доверять автоматизированным системам больше, чем следует. Отсюда и «агент написал лабуду, но никто не заметил» — люди перестают критически проверять вывод системы. Skill Atrophy / Deskilling Деградация навыков из-за делегирования задач инструментам. Ты описал это точно: «код весь написан агентом, и без него уже сложно разобраться». Это активно обсуждается сейчас применительно к junior-разработчикам, которые никогда не научатся думать самостоятельно. Productivity Paradox (Парадокс производительности) Технологии растут, а реальная производительность и удовлетворённость сотрудников — не обязательно. Впервые описан в контексте IT-революции 80-90х годов (Solow Paradox). Alert Fatigue / Review Fatigue Когда объём вещей, требующих внимания, превышает когнитивные возможности человека. У тебя это — несколько открытых PR в разных репозиториях одновременно. Shifting Bottleneck Узкое место не исчезает, оно перемещается. Раньше бутылочное горлышко — написание кода. Теперь — ревью, понимание, верификация того, что написал агент.