Хозяйке на заметку или как я только сейчас понял, что произошло на вебинаре.
Сетап
Есть связка S3 + Iceberg JDBC Catalog + Trino. Облачная связка на платформенных сервисах. Рядом с этим есть Jupyter Notebook, который общаемся с данными в S3 через PyIceberg. JDBC каталог шерится между Trino и PyIceberg.
Кэтч
Я работаю с Трино и создаю несколько таблиц. Потом хочу подключиться к этим же таблицам в PyIceberg, что-то поменять (докинуть колонку) и сразу же увидеть изменения в Трино. Красивая история про мульти-агентный Zero-Copy ETL.
Подключаюсь питоном к каталогу и не вижу в нем таблиц. Хм, каталог-то (JDBC host, login, pass, dbname) точно правильный и ошибок никаких при подключении нет. Что за ерунда? Иду в S3, там объекты точно есть.
Окей, думаю, давай-ка попробуем создать новую таблицу и просто залить туда данные. Создаю питоном схему (Iceberg namespace), создаю табличку, лью туда рандомный датасет. Все замечательно работает. Иду смотреть в S3 - чудо, рядом с Трино схемами по тому же пути в бакете появились новые объекты, созданные из питона!
Иду смотреть в Трино - питонячьих объектов нет. Да что за ерунда тут происходит?
Разгадка
Что происходит, я понял, глядя на таблицы в JDBC Postgres - см. картинку в первом комменте.
В одной инсталляции JDBC каталога - в одной постгресовой БД, схеме, в одной и той же таблице лежат объекты с разными catalog_name! То есть у JDBC каталога фактически имеется слой логического разделения объектов.
Делая в питоне
load_catalog(name='ice')
можно увидеть только часть объектов которые есть на S3.
А сделав
load_catalog(name='i_misprint_my_catalog_name')
вы приземлитесь в новый пустой каталог, и код вам ошибку не кинет! Я бы предпочел чтобы в этом месте мне кинули exception catalog not found, но сделано вот так.
Будьте внимательней и учитывайте при планировании работ
И подписывайтесь на канал в ВК, там в начале следующего года точно будут новые технические вебинары!