Мы рады сообщить, что Starburst Enterprise 481-e STS теперь включает поддержку планирования сканирования на стороне сервера, которая была добавлена в коннектор Iceberg через REST Catalog API. Это означает, что любой каталог Iceberg REST, реализующий конечную точку /plan, теперь может планировать сканирование от имени Starburst, возвращая точные файлы данных для чтения без необходимости обработки метаданных Iceberg со стороны Starburst. Движок выполняет план «как есть», а Starburst учитывает учетные данные, включенные в ответ плана.
Хотя Starburst поддерживает планирование сканирования на стороне сервера с любым REST Catalog, наиболее значимой первоначальной интеграцией является Databricks Unity Catalog. Unity Catalog теперь может обеспечивать детальный контроль доступа, включая фильтры строк и маски столбцов с управляемыми тегами, для управляемых таблиц Iceberg в Starburst с использованием планирования сканирования на стороне сервера. Мы тесно сотрудничали с Databricks, чтобы гарантировать соблюдение политик Unity Catalog при выполнении запросов Starburst к таблицам Iceberg, управляемым Unity, что позволяет централизовать управление в Unity Catalog без необходимости внедрения специальной логики в движок запросов.
Что такое планирование сканирования на стороне сервера?
Спецификация Iceberg REST добавила POST …/tables/{table}/plan в версии Iceberg 1.7.0. Вместо того чтобы движок запросов Starburst считывал файлы метаданных и планировал сканирование самостоятельно, клиент отправляет выбранные столбцы и выражения фильтров на сервер каталога через эту конечную точку. Каталог возвращает список задач сканирования файлов и ограниченные по области действия учетные данные хранилища, которые движок выполняет в обычном режиме.
Это небольшое изменение протокола дало каталогу возможность влиять на путь чтения запроса. Теперь каталог может решать, какие файлы видит движок, применять преобразования, предоставлять кратковременные учетные данные, ограниченные конкретными файлами в ответе, и проводить аудит доступа к файлам. Ничто из этого не требует от нашего движка понимания модели политик Databricks, но политики по-прежнему соблюдаются при возврате данных вызывающей стороне.
Для Starburst ценность поддержки этого протокола заключается в том, что он работает во всей экосистеме Iceberg REST и будет работать «из коробки» по мере того, как другие каталоги будут внедрять эту конечную точку.
Детальный контроль доступа в Unity Catalog
Databricks Unity Catalog использует /plan для реализации «ScanAPI»: конечной точки для обеспечения детального контроля доступа для внешних движков. С помощью ScanAPI, когда запрос Starburst достигает управляемой Unity таблицы Iceberg, имеющей активные политики FGAC, Unity:
- Оценивает политики ABAC вызывающей стороны на основе идентификатора пользователя.
- Материализует очищенные данные во временные файлы данных с уже примененными фильтрами строк и масками столбцов.
- Возвращает задачи сканирования файлов, указывающие на эти очищенные файлы, а также ограниченные учетные данные.
Движок видит только данные, авторизованные для этого пользователя. Политика была определена один раз в Unity Catalog и применяется независимо от того, выполняется ли запрос в Databricks или Starburst.
Это решает проблему разрыва в управлении, с которой сталкиваются многие клиенты lakehouse. Unity Catalog уже обеспечивает контроль доступа на уровне таблиц между движками посредством предоставления учетных данных, но это предоставление является грубым: у вас есть доступ ко всей таблице или его нет вовсе. Реальное управление требует большего: маски столбцов для PII, региональные фильтры строк, ролевые представления одних и тех же данных и т. д. Репликация этой политики в каждом движке не масштабируется. Планирование сканирования на стороне сервера позволяет Unity централизованно управлять данными, а такие движки, как Starburst, могут соблюдать эти решения с помощью ScanAPI.
Пример из реальной жизни
Хотите узнать больше о том, как это работает на практике? Посмотрите это видео от Databricks.
Что дальше?
Поддержка планирования сканирования на стороне сервера поставляется в Starburst Enterprise Platform 481-e STS. Хотя интеграция с Unity Catalog на сегодняшний день является наиболее развитым примером, Starburst будет поддерживать любые другие REST-каталоги, реализующие эту конечную точку.
В целом, это представляет собой шаг к общему языку политик. Это отражает другие инициативы в отрасли, направленные на достижение аналогичных целей, в частности подход Snowflake к открытому способу управления таблицами с помощью определенных доверенных вычислительных движков.
Подробнее о протоколе и совместной работе Databricks/Starburst см. в анонсе Databricks о кросс-движковой ABAC и нашей предыдущей публикации об интеграции Starburst с Unity Catalog.
