Мы рады объявить, что Starburst Enterprise 481-e STS теперь поддерживает планирование сканирования на стороне сервера, которое было добавлено в Iceberg Connector через REST Catalog API. Это означает, что любой Iceberg REST Catalog, реализующий конечную точку /plan, теперь может планировать сканирование от имени Starburst, возвращая точные файлы данных для чтения, без необходимости для Starburst обрабатывать файлы метаданных Iceberg. Движок выполняет план в его исходном виде, и Starburst уважает предоставленные учетные данные, включенные в ответ плана.

Хотя Starburst поддерживает планирование сканирования на стороне сервера с любым REST Catalog, наиболее привлекательной первоначальной интеграцией является Databricks Unity Catalog. Теперь Unity Catalog может обеспечивать детальный контроль доступа, включая фильтры строк и маски столбцов с управляемыми тегами, для управляемых таблиц Iceberg в Starburst с использованием планирования сканирования на стороне сервера. Мы тесно сотрудничали с Databricks, чтобы убедиться, что политика Unity Catalog соблюдается, когда Starburst запрашивает управляемую Unity таблицу Iceberg, что позволяет централизовать управление в Unity Catalog без специальной логики в движке запросов.

Что такое планирование сканирования на стороне сервера?

Спецификация Iceberg REST Iceberg REST specдобавила POST …/tables/{table}/plan в Iceberg version 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.