FANNG1 commented on code in PR #11280: URL: https://github.com/apache/gravitino/pull/11280#discussion_r3463989749
########## design-docs/spark-rest-catalog-registration.md: ########## @@ -0,0 +1,315 @@ +<!-- + Licensed to the Apache Software Foundation (ASF) under one + or more contributor license agreements. See the NOTICE file + distributed with this work for additional information + regarding copyright ownership. The ASF licenses this file + to you under the Apache License, Version 2.0 (the + "License"); you may not use this file except in compliance + with the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, + software distributed under the License is distributed on an + "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + KIND, either express or implied. See the License for the + specific language governing permissions and limitations + under the License. +--> + +# Design: Spark REST Catalog Automatic Registration + +## Problem + +Spark users can already connect to Gravitino with a small amount of configuration: + +```text +spark.plugins=org.apache.gravitino.spark.connector.plugin.GravitinoSparkPlugin +spark.sql.gravitino.uri=http://127.0.0.1:8090 +spark.sql.gravitino.metalake=test +``` + +However, when users want Spark to access Iceberg or Lance through their REST protocols, they still +need to hand-write Spark catalog configuration for each catalog: + +```text +spark.sql.catalog.iceberg_prod=org.apache.iceberg.spark.SparkCatalog +spark.sql.catalog.iceberg_prod.type=rest +spark.sql.catalog.iceberg_prod.uri=http://127.0.0.1:9001/iceberg/ +spark.sql.catalog.iceberg_prod.warehouse=iceberg_prod + +spark.sql.catalog.lance_vectors=org.lance.spark.LanceNamespaceSparkCatalog +spark.sql.catalog.lance_vectors.impl=rest +spark.sql.catalog.lance_vectors.uri=http://127.0.0.1:9101/lance +spark.sql.catalog.lance_vectors.parent=lance_vectors +``` + +This duplicates information already managed by Gravitino and forces users to update Spark +configuration whenever Gravitino catalogs change. + +## Goal + +The Gravitino Spark connector should register Spark REST catalogs automatically for supported +Gravitino catalogs. The user-facing goal is simple: Gravitino remains the catalog inventory, and +Spark derives the Iceberg/Lance REST catalog configuration from that inventory. + +V1 scope is Spark only. + +Non-goals in V1: + +1. Do not introduce a generic access-mode framework. +2. Do not introduce a dedicated Lance catalog provider. +3. Do not change the Gravitino REST API contract. + +## Supported Catalogs + +This design supports the following Gravitino catalog providers in V1: + +| Gravitino catalog provider | Extra catalog constraints | Default Spark registration | REST catalog registration | +|----------------------------|------------------------------|-------------------------------------------|-------------------------------------------------------------------| +| `lakehouse-iceberg` | None | Existing Gravitino Spark catalog behavior | Enabled only when `spark.sql.gravitino.iceberg.enableRestAccess=true` | +| `lakehouse-generic` | Catalog-level `format=lance` | Existing behavior | Enabled only when `spark.sql.gravitino.lance.enableRestAccess=true` | +| Other providers | None | Existing behavior | Not supported in V1 | + +For `lakehouse-generic + format=lance`, `format=lance` is interpreted as a catalog-level marker only +for Lance REST catalog registration. This does not change the existing behavior of other generic +catalogs. When the marker is present, the catalog is treated as a Lance catalog, and tables under +this catalog must be Lance tables. Generic catalogs without catalog-level `format=lance` are ignored +by Lance REST catalog registration. Because there is no Lance Gravitino Spark catalog in V1, Lance +only supports REST catalog registration. + +## Spark Configuration + +Iceberg REST catalog registration is disabled by default to preserve existing Gravitino Spark +connector behavior. Users enable it with: + +```text +spark.sql.gravitino.iceberg.enableRestAccess=true +``` + +Lance REST catalog registration is disabled by default because registration needs to load Lance +Spark catalog and extension classes, and users may not have the Lance Spark runtime on the +classpath. Users explicitly enable Lance REST access with: + +```text +spark.sql.gravitino.lance.enableRestAccess=true +``` + +When Lance REST access is enabled, the Spark connector registers REST catalogs for +`lakehouse-generic + format=lance` catalogs. + +Optional REST service URI overrides: + +| Configuration | Default | +|---------------|---------| +| `spark.sql.gravitino.iceberg.restUri` | Inferred from `spark.sql.gravitino.uri` | +| `spark.sql.gravitino.lance.restUri` | Inferred from `spark.sql.gravitino.uri` | + +The Iceberg switch applies to all Gravitino Iceberg catalogs visible to the Spark connector in V1. +Per-catalog REST registration override is future work. + +## Registration Precedence + +For each Spark catalog name, the connector should register exactly one Spark catalog implementation. +When `spark.sql.gravitino.iceberg.enableRestAccess=true`, REST catalog registration replaces the +existing Gravitino Spark catalog registration for matching `lakehouse-iceberg` catalogs and keeps the +same Spark catalog name. + +This is an explicit opt-in behavior change. Users who do not set +`spark.sql.gravitino.iceberg.enableRestAccess=true` keep the existing Gravitino Spark catalog +behavior. + +## REST URI Resolution + +Spark needs the REST service URI for REST catalog registration. The URI is resolved in this +order: + +1. Use the explicit Spark-side override if configured: + - `spark.sql.gravitino.iceberg.restUri` + - `spark.sql.gravitino.lance.restUri` +2. Otherwise infer the endpoint from `spark.sql.gravitino.uri` using the default Gravitino auxiliary + service layout. + +Default inference reuses only the scheme and host from `spark.sql.gravitino.uri`. It replaces the +port and path with the REST service defaults: + +| REST service | Default port | Default path | +|--------------|--------------|--------------| +| Gravitino Iceberg REST server | `9001` | `/iceberg/` | +| Lance REST service | `9101` | `/lance` | + +For example, `spark.sql.gravitino.uri=http://gravitino.example.com:8090` infers: + +```text +spark.sql.gravitino.iceberg.restUri=http://gravitino.example.com:9001/iceberg/ +spark.sql.gravitino.lance.restUri=http://gravitino.example.com:9101/lance +``` + +When the connector infers a REST URI, it should log a warning with the inferred URI and the source +`spark.sql.gravitino.uri`. Deployments with a different host, port, path, protocol, or gateway must +configure the explicit override. Production deployments should prefer explicit `restUri` +configuration over inference. + +## Iceberg Mapping + +This mapping requires the Gravitino Iceberg REST server to expose catalog names that match Gravitino +catalog names. With `dynamic-config-provider`, this is the intended behavior because the REST server +loads catalog configuration from Gravitino and registers catalogs by Gravitino catalog name. With +`static-config-provider`, users must manually configure REST-server catalog names to match the +corresponding Gravitino catalog names. + +For a Gravitino Iceberg catalog: + +```text +name = iceberg_prod +type = RELATIONAL +provider = lakehouse-iceberg + +catalog-backend = jdbc +uri = jdbc:postgresql://127.0.0.1:5432 +warehouse = s3://warehouse/iceberg_prod +data-access = vended-credentials +``` + +The Gravitino catalog properties describe the backend used by Gravitino Iceberg REST server. For +example, `uri` may be a JDBC URL, Hive Metastore URI, or upstream Iceberg REST URI. Spark should not +use this catalog property as the Iceberg REST client URI. + +Generated Spark configuration: + +```text +spark.sql.catalog.iceberg_prod=org.apache.iceberg.spark.SparkCatalog +spark.sql.catalog.iceberg_prod.type=rest +spark.sql.catalog.iceberg_prod.uri=<resolved-iceberg-rest-uri> +spark.sql.catalog.iceberg_prod.warehouse=iceberg_prod Review Comment: Thanks for pointing this out. I think this corresponds to the case where the Gravitino Iceberg catalog name and the Iceberg REST server catalog name are different. Technically, we could support this by adding a catalog-level alias property, for example: ```text iceberg-rest-catalog-name = <iceberg-rest-server-catalog-name> ``` Then Spark would still register the Spark catalog using the Gravitino catalog name, but generate: ```text spark.sql.catalog.<gravitino-catalog-name>.warehouse=<iceberg-rest-server-catalog-name> ``` instead of: ```text spark.sql.catalog.<gravitino-catalog-name>.warehouse=<gravitino-catalog-name> ``` However, this adds another name-mapping layer for users to understand and maintain. I am not sure whether this is a common requirement. The current design assumes the Gravitino Iceberg REST server exposes catalogs by Gravitino catalog name, which is naturally satisfied by the dynamic config provider and is also the recommended deployment model. So my preference is to keep V1 simple and not support a separate REST catalog alias first. What do you think? Do you think the alias case is important enough to include in V1? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
