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

Гайз, знаю что все ждали этого — новый сезон опроса State Of Data оч прошу потратить 10 минут времени всем и каждому + разослать по чатикам с коллегами в этом году, ожидаемо, появились вопросы про всякие llm и прочих агентов ) https://forms.gle/Fp6HrZxBw7Y5VbFw7 давайте посмотрим насколько помирает хадуп (особенно по сравнению с позапрошым годом) насколько выстреливает старрокс (или наоборот стагнирует) и прочие интересные инсайты вытащим там в форме есть ссылки на .parquet с исходниками опросов '24 и '25 по текущему опросу исходник выложу в ту же гуглопапку ~ в середине октября

По заявкам. Разные движки воспринимают ролевую модель айсберг-лейкхауса по-разному. И с этим надо смириться и воспринимать как вариант нормы. Поэтому учимся защищать данные даже в тех ситуациях, когда конкретный движок решит забить на правила. Один из способов- начать работать с S3 ключами. А как? А вот так. 1️⃣ команде пользователю данных выдаем ключ не на весь бакет, а более гранулярно. Пользуемся тем, что если default location у нас s3://ice-bucket/data, то объекты по умолчанию будут разложены по префиксам s3://ice-bucket/data/schema/table. Вот и выписываем их гранулярно на схемы и таблицы. Эти же ключи раскладываем по ноутбукам, спаркам, трино каталогам, аэрфлоу и тд. 2️⃣ В айсберг таблице есть параметр location. Это корень обхода дерева метадаты айсберг и то куда айсберг складывает свой стафф. По умолчанию он берется из настроек коннектора и каталога. Так вот, ничего не мешает этот локейшен точечно переопределить. Например на s3://ice-bucket/secret/ или s3://secret-bucket или (внезапно!) hdfs://path И все будет работать до тех пор пока чтец обладает правами на предоставленных ему s3 ключах. Причем во многих s3 реализациях нельзя на один ключ грантовать права в разных бакетах. Разнося таблицы по бакетам мы получаем гарантию, что команды из чистой зоны физически не смогут добраться до секретной зоны со своими ключами. Вот так мы добавляем доп слой гарантированной безопасности, который будет работать на низком уровне даже если сервисы джейлбрейкнут Ranger или REST Catalog. (А они ведь могут!) Не забудьте только навайбкодить сервис, который будет выпускать, отзывать, аудировать и раскладывать в конфиги и волты ваши s3 ключи! 😎

Безопасность в 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 каталогах - вообще своя атмосфера.