[Refactor] Make the FE codebase more modular and maintainable with multi module (#62220)

This commit is contained in:
Harbor Liu 2025-08-22 17:54:20 +08:00 committed by GitHub
parent 71b51eec1f
commit 835248f265
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
77 changed files with 495 additions and 40 deletions

View File

@ -27,8 +27,8 @@ The build system is extremely resource-intensive and time-consuming. Building th
**Language**: Java
**Purpose**: SQL parsing, query planning, and metadata management
- `fe/fe-core/` - Core frontend services (SQL parser, planner, catalog)
- `fe/fe-common/` - Common frontend utilities
- `fe/plugin-common/` - Plugin framework common components
- `fe/fe-testing/` - Common test utilities
- `fe/fe-utils/` - Common utilities and helpers
- `fe/spark-dpp/` - Spark data preprocessing integration
- `fe/hive-udf/` - Hive UDF compatibility layer

View File

@ -505,13 +505,13 @@ cd ${STARROCKS_HOME}
FE_MODULES=
if [ ${BUILD_FE} -eq 1 ] || [ ${BUILD_SPARK_DPP} -eq 1 ] || [ ${BUILD_HIVE_UDF} -eq 1 ]; then
if [ ${BUILD_SPARK_DPP} -eq 1 ]; then
FE_MODULES="fe-common,spark-dpp"
FE_MODULES="fe-testing,plugin/spark-dpp"
fi
if [ ${BUILD_HIVE_UDF} -eq 1 ]; then
FE_MODULES="fe-common,hive-udf"
FE_MODULES="fe-testing,plugin/hive-udf"
fi
if [ ${BUILD_FE} -eq 1 ]; then
FE_MODULES="hive-udf,fe-common,spark-dpp,fe-core"
FE_MODULES="plugin/hive-udf,fe-testing,plugin/spark-dpp,fe-core"
fi
fi
@ -556,15 +556,15 @@ if [ ${BUILD_FE} -eq 1 -o ${BUILD_SPARK_DPP} -eq 1 ]; then
cp -r -p ${STARROCKS_HOME}/fe/fe-core/target/starrocks-fe.jar ${STARROCKS_OUTPUT}/fe/lib/
cp -r -p ${STARROCKS_HOME}/java-extensions/hadoop-ext/target/starrocks-hadoop-ext.jar ${STARROCKS_OUTPUT}/fe/lib/
cp -r -p ${STARROCKS_HOME}/webroot/* ${STARROCKS_OUTPUT}/fe/webroot/
cp -r -p ${STARROCKS_HOME}/fe/spark-dpp/target/spark-dpp-*-jar-with-dependencies.jar ${STARROCKS_OUTPUT}/fe/spark-dpp/
cp -r -p ${STARROCKS_HOME}/fe/hive-udf/target/hive-udf-1.0.0.jar ${STARROCKS_OUTPUT}/fe/hive-udf/
cp -r -p ${STARROCKS_HOME}/fe/plugin/spark-dpp/target/spark-dpp-*-jar-with-dependencies.jar ${STARROCKS_OUTPUT}/fe/spark-dpp/
cp -r -p ${STARROCKS_HOME}/fe/plugin/hive-udf/target/hive-udf-1.0.0.jar ${STARROCKS_OUTPUT}/fe/hive-udf/
cp -r -p ${STARROCKS_THIRDPARTY}/installed/async-profiler ${STARROCKS_OUTPUT}/fe/bin/
MSG="${MSG}${MSG_FE}"
elif [ ${BUILD_SPARK_DPP} -eq 1 ]; then
install -d ${STARROCKS_OUTPUT}/fe/spark-dpp/
rm -rf ${STARROCKS_OUTPUT}/fe/spark-dpp/*
cp -r -p ${STARROCKS_HOME}/fe/spark-dpp/target/spark-dpp-*-jar-with-dependencies.jar ${STARROCKS_OUTPUT}/fe/spark-dpp/
cp -r -p ${STARROCKS_HOME}/fe/hive-udf/target/hive-udf-1.0.0.jar ${STARROCKS_HOME}/fe/hive-udf/
cp -r -p ${STARROCKS_HOME}/fe/plugin/spark-dpp/target/spark-dpp-*-jar-with-dependencies.jar ${STARROCKS_OUTPUT}/fe/spark-dpp/
cp -r -p ${STARROCKS_HOME}/fe/plugin/hive-udf/target/hive-udf-1.0.0.jar ${STARROCKS_HOME}/fe/hive-udf/
MSG="${MSG}${MSG_DPP}"
fi
fi

View File

@ -88,8 +88,8 @@ The main frontend module containing all core database functionality:
- `fe-core/src/main/java/com/starrocks/http/` - HTTP API endpoints
### Other Frontend Modules
- `fe-common/` - Common frontend utilities and shared code
- `plugin-common/` - Plugin framework common components
- `fe/fe-testing/` - Common test utilities
- `fe/fe-utils/` - Common utilities and helpers
- `spark-dpp/` - Spark data preprocessing integration
- `hive-udf/` - Hive UDF compatibility layer

View File

@ -1,14 +1,14 @@
# fe-common
# fe-testing
This module is used to store some common classes of other modules.
# spark-dpp
This module is Spark DPP program, used for Spark Load function.
Depends: fe-common
Depends: fe-testing
# fe-core
This module is the main process module of FE.
Depends: fe-common, spark-dpp
Depends: fe-testing, spark-dpp

73
fe/README.md Normal file
View File

@ -0,0 +1,73 @@
# StarRocks Frontend (FE) Overview
The Frontend (FE) is the Java layer of StarRocks that provides the SQL interface and cluster coordination. It parses and validates SQL, builds optimized query plans, manages metadata, and coordinates execution with the Backend (BE).
## Key responsibilities
- SQL parsing and AST construction
- Semantic analysis and validation
- Cost-based optimization and plan generation
- Metadata/catalog management and statistics
- Session management, authentication, and authorization
- Scheduling and coordination of query execution with BEs
## Directory layout (high level)
- `fe-core/`
- `src/main/java/com/starrocks/`
- `sql/` — Analyzer and optimizer
- `planner/` — Plan fragments and physical planning
- `catalog/` — Metadata (databases, tables, partitions, statistics)
- `qe/` — Query execution coordination and session management
- `privilege/` — Authentication and authorization
- `scheduler/`, `load/`, `backup/` — Scheduling, data loading, backup/restore
- `fe/fe-parser/` — StarRocks SQL parser and full AST definitions
- `fe/fe-spi/` — FE Service Provider Interfaces (contracts for connectors/plugins)
- `fe/connector/` — Data source connector implementations and FE-side integration
- `fe/plugin/` — Plugin implementations extending FE core capabilities (non-data-source)
- `fe/fe-utils/` — FE utilities and base libraries (no business logic)
- `fe/fe-testing/` — Shared test utilities, fixtures, and mock implementations
Related:
- `be/` — C++ Backend engine (execution and storage)
## Extensibility overview
- Syntax/AST:
- Extend grammar in `fe/fe-parser/` and add new AST nodes under `com.starrocks.sql.ast`.
- Follow AST conventions: include source positions; keep nodes immutable.
- Update analyzer/optimizer and add tests.
- Connectors (data sources):
- Implement FE SPI in a dedicated module; provide discovery metadata (e.g., ServiceLoader or plugin manifest).
- Register catalogs and handle metadata/scan capabilities.
- Plugins (core extensions):
- Implement FE SPI to extend authentication, authorization, auditing, observability, governance, etc.
- Examples: Ranger-based authorization, LDAP/Kerberos authentication.
## Development guidelines
- AST immutability:
- Do not add setter methods to AST nodes; do not use AST as temporary storage between Parser and Analyzer; keep the AST immutable.
- Utilities:
- `fe/fe-utils/` contains general-purpose helpers only; no business logic or FE internals.
- SPI boundaries:
- Keep connectors/plugins decoupled from FE internals; depend only on `fe/fe-spi/`.
- Performance and correctness:
- Prefer unambiguous grammar; avoid heavy work in the parser; push semantic checks to analyzer.
- Security:
- Validate inputs; avoid leaking secrets/PII in logs; honor FE authN/authZ policies.
## Testing
- Unit tests for FE modules: `fe/fe-'xxx'/src/test/`
- Shared testing helpers and mocks: `fe/fe-testing/`
- Add positive/negative/edge cases for new syntax, SPI implementations, and security paths.
## Critical notes
- Build system is heavy. Avoid running full builds or UT unless necessary.
- Prefer targeted changes and module-level verification.
## References
- Parser and AST: `fe/fe-parser/`
- SPI contracts: `fe/fe-spi/`
- Connectors: `fe/connector/`
- Plugins: `fe/plugin/`
- Utilities: `fe/fe-utils/`
- Testing: `fe/fe-testing/`
- Docs: https://docs.starrocks.io/

View File

@ -119,10 +119,10 @@ subprojects {
implementation("com.qcloud:chdfs_hadoop_plugin_network:3.2")
implementation("com.squareup.okhttp3:okhttp:4.10.0")
implementation("com.squareup.okio:okio:3.4.0")
implementation("com.starrocks:fe-common:1.0.0")
implementation("com.starrocks:fe-testing:1.0.0")
implementation("com.starrocks:hive-udf:1.0.0")
implementation("com.starrocks:jprotobuf-starrocks:${project.ext["jprotobuf-starrocks.version"]}")
implementation("com.starrocks:plugin-common:1.0.0")
implementation("com.starrocks:fe-utils:1.0.0")
implementation("com.starrocks:spark-dpp:1.0.0")
implementation("com.starrocks:starclient:${project.ext["staros.version"]}")
implementation("com.starrocks:starmanager:${project.ext["staros.version"]}")

63
fe/connector/README.md Normal file
View File

@ -0,0 +1,63 @@
# StarRocks Data Source Connectors
This directory is the home for data source connector implementations and FE-side integration. Each connector is an independent module that implements the contracts defined in `fe/spi`, enabling StarRocks to query heterogeneous external data sources.
## Responsibilities
- Provide concrete implementations of FE SPI for external catalogs and tables.
- Bridge StarRocks FE planning/execution with external metadata and I/O.
- Offer minimal integration and shared FE-side utilities for connectors.
## Relationship to FE SPI
- FE core programs against interfaces defined in `fe/spi`.
- Connectors implement those interfaces and are discovered/loaded by FE.
- Keep implementations decoupled from FE internals beyond the SPI boundary.
## Where things live
- This package: FE-side integration classes and built-in connector.
- Independent connectors: separate modules that depend on `fe/spi` and optionally reuse helpers from here.
- Do not place FE private types into connector-facing APIs.
## Implementing a new connector
1. Identify the relevant SPI interfaces in `fe/spi` (capabilities, metadata, scanning).
2. Create a new module for your connector; depend on `fe/spi`.
3. Implement the SPI contracts and provide discovery metadata (e.g., ServiceLoader entries or plugin manifest supported by StarRocks).
4. Add configuration parsing and validation; prefer explicit, typed configs.
5. Integrate with FE by registering the connector and exposing catalog(s).
6. Write tests (unit for SPI conformance; integration for end-to-end queries).
Guidelines:
- Favor stateless or explicitly thread-safe implementations.
- Fail fast on misconfiguration; return well-typed errors.
- Avoid blocking FE critical paths; use timeouts and backoff for I/O.
- Log actionable messages; never log secrets or PII.
## Lifecycle
- Initialize: receive context/config, validate connectivity and schema access.
- Runtime: serve concurrent metadata and split/scan requests.
- Shutdown: release resources (clients, threads) idempotently.
## Configuration
- Use namespaced keys for connector-specific options.
- Support secure credentials handling (env/keystore/injected secrets).
- Provide sensible defaults and minimal required options.
## Compatibility and versioning
- Track the `fe/spi` version your connector supports.
- Prefer backward-compatible changes; deprecate before breaking.
- Document supported external system versions and features.
## Testing
- Unit tests against SPI interfaces with mocks/fakes.
- Integration tests that query real or embedded backends where feasible.
- Include negative tests for permissions, schema drift, and network failures.
## Security considerations
- Enforce authorization checks exposed via SPI contexts.
- Sanitize external inputs; validate identifiers and filter expressions.
- Obfuscate or omit sensitive fields from logs and error messages.
## References
- FE SPI (contracts): `fe/spi/`
- FE connector integration: this package (`com.starrocks.connector`)
- Project docs: https://docs.starrocks.io/

View File

@ -55,10 +55,10 @@ dependencies {
antlr("org.antlr:antlr4:${project.ext["antlr.version"]}")
// Internal project dependencies
implementation(project(":fe-common"))
implementation(project(":plugin-common"))
implementation(project(":hive-udf"))
implementation(project(":spark-dpp"))
implementation(project(":fe-testing"))
implementation(project(":fe-utils"))
implementation(project(":plugin:hive-udf"))
implementation(project(":plugin:spark-dpp"))
// dependency sync start
implementation("com.aliyun.datalake:metastore-client-hive3") {

82
fe/fe-parser/README.md Normal file
View File

@ -0,0 +1,82 @@
# StarRocks SQL Parser and AST
This module implements the StarRocks SQL parser and defines the Abstract Syntax Tree (AST) for the StarRocks SQL dialect. It converts raw SQL text into a typed AST consumed by the analyzer and optimizer layers.
## Responsibilities
- Tokenize and parse SQL text into a strongly-typed AST
- Provide accurate error diagnostics with source positions
- Define the full set of StarRocks SQL AST nodes (DDL/DML/DQL/admin/transaction/resource statements and expressions)
- Offer visitor utilities to traverse and transform AST nodes
## Where things live
- Parser entry points and helpers: this package (`com.starrocks.sql.parser`)
- AST node definitions: `com.starrocks.sql.ast`
- AST visitors: `com.starrocks.sql.ast` (visitor classes and utilities)
- Analyzer and optimizer: outside of this module (e.g., `com.starrocks.sql.analyzer`, `com.starrocks.sql.optimizer`)
Note: Exact class names and file layout may evolve; consult sources in the above packages.
## Parsing pipeline
1. Input SQL text is tokenized and parsed by the parser front-end.
2. A typed AST is built for statements and expressions.
3. The analyzer validates semantics and decorates the AST with metadata.
4. The optimizer generates physical plans from the analyzed AST.
The parser is responsible only for steps 12.
## AST conventions
- Nodes represent StarRocks SQL constructs (statements and expressions).
- Statement nodes (e.g., DQL, DML, DDL) and expression nodes are distinct families.
- Nodes carry source location information (line/column) where available.
- A visitor pattern is provided (e.g., `AstVisitor`) for traversal.
- Nodes aim to be immutable after construction; analysis does not belong in constructors.
## Error handling
- Syntax errors include clear messages with line/column and offending token when possible.
- The parser tries to surface the earliest, most relevant error.
- Keep grammar/extensions unambiguous to reduce cascading diagnostics.
## Typical usage
- Parse SQL text into AST nodes using the parser entry point in this package.
- Walk the AST via visitor utilities to inspect or transform nodes.
- Hand the AST to the analyzer for semantic checks and binding.
Pseudo-flow:
- create parser with session/config if needed
- parse the SQL string into a list of statements
- for each statement, either run visitors or pass to analyzer
## Extending the syntax
When adding new SQL syntax:
1. Update the parser to recognize the new construct and produce an AST node.
2. Add a new AST class (or extend existing ones) under `com.starrocks.sql.ast`.
3. Provide visitor hooks and `toSql`/printer support if applicable.
4. Update analyzer and optimizer to understand the new node.
5. Add tests (positive, negative, and edge cases).
Guidelines:
- Prefer minimal and orthogonal syntax extensions.
- Preserve backward compatibility; avoid ambiguous productions.
- Always include source position in new nodes if possible.
- Keep AST construction free of semantic logic.
- Do not add setter methods to AST nodes; do not use the AST as temporary storage between the Parser and Analyzer; keep the AST immutable.
## Performance notes
- Parser instances are not intended to be shared across threads.
- Avoid excessive backtracking/ambiguity in grammar to keep parse times predictable.
- Keep AST lightweight; defer heavy work to analyzer/planner.
## Testing
- Parser unit tests: FE test modules (Java) for AST shape and error messages.
- End-to-end SQL tests: `test/sql/` for correctness and compatibility.
- Add representative cases for new syntax, including failure diagnostics.
## Known dialect notes
StarRocks follows a SQL dialect broadly aligned with common analytics systems and MySQL-like constructs, with StarRocks-specific extensions (e.g., materialized views, lakehouse connectors, resource/session management).
## References
- Frontend overview: `fe/fe-core/src/main/java/com/starrocks/`
- AST: `com.starrocks.sql.ast`
- Analyzer: `com.starrocks.sql.analyzer`
- Optimizer: `com.starrocks.sql.optimizer`
- Project docs: https://docs.starrocks.io/

23
fe/fe-parser/pom.xml Normal file
View File

@ -0,0 +1,23 @@
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>com.starrocks</groupId>
<artifactId>starrocks-fe</artifactId>
<version>3.4.0</version>
<relativePath>../pom.xml</relativePath>
</parent>
<artifactId>fe-parser</artifactId>
<version>1.0.0</version>
<packaging>jar</packaging>
<properties>
<maven.compiler.source>17</maven.compiler.source>
<maven.compiler.target>17</maven.compiler.target>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
</project>

40
fe/fe-spi/README.md Normal file
View File

@ -0,0 +1,40 @@
# StarRocks FE SPI (Service Provider Interface)
The `fe/spi` module defines the public Service Provider Interfaces (SPIs) for the StarRocks Frontend. It is the foundation of the pluggable architecture: connectors and plugins must implement these contracts, while the FE core programs against the interfaces.
## Responsibilities
- Provide stable, minimal contracts for connectors and plugins.
- Decouple FE core from concrete implementations.
- Enable safe evolution via versioning and deprecation policies.
## Design goals
- Stability first: interfaces evolve conservatively and compatibly.
- Clear separation: SPI must not depend on FE core internal types.
- Minimal surface: small, orthogonal interfaces; no hidden coupling.
- Testability: interfaces are mock-friendly and deterministic.
## What lives here
- Public Java interfaces and data contracts for plugin authors.
- Common exceptions, result/status types intended for SPI boundaries.
- Documentation and guidance for implementers.
## Typical extension points
- Connectors (external catalogs, metadata/external table access, etc.)
- Resource and system integrations (e.g., external services)
- Administrative or management hooks exposed via well-defined SPI
## How FE core uses SPI
- FE core depends only on SPI interfaces.
- Concrete plugins/connectors are discovered and wired at runtime.
- Implementations must be prepared for concurrent use by FE subsystems.
## Testing guidance
- Unit test against SPI interfaces with mocks/fakes.
- Add integration tests that exercise real interactions where applicable.
- Include negative tests for error paths and boundary conditions.
## References
- Architecture overview: see project root README and FE module docs
- Testing structure: `test/sql/`, `fe/fe-core/src/test/`
- StarRocks documentation: https://docs.starrocks.io/

24
fe/fe-spi/pom.xml Normal file
View File

@ -0,0 +1,24 @@
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>com.starrocks</groupId>
<artifactId>starrocks-fe</artifactId>
<version>3.4.0</version>
<relativePath>../pom.xml</relativePath>
</parent>
<artifactId>fe-spi</artifactId>
<version>1.0.0</version>
<packaging>jar</packaging>
<properties>
<maven.compiler.source>17</maven.compiler.source>
<maven.compiler.target>17</maven.compiler.target>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
</project>

29
fe/fe-testing/README.md Normal file
View File

@ -0,0 +1,29 @@
# StarRocks Testing Utilities and Mocks
This directory hosts shared test dependencies used across the project: common test code, utilities, fixtures, and mock/stub implementations. The goal is to maximize reuse, keep tests consistent, and reduce duplication.
## What lives here
- Utilities: helpers for assertions, data generation, temporary files/dirs, config parsing, JSON/CSV helpers.
- Mocks/Stubs/Fakes: lightweight implementations of SPI/core-facing interfaces for isolated tests (e.g., mock connectors, auth providers, catalog services).
- Fixtures: reusable datasets, schemas, DDLs, and golden files for deterministic tests.
- Test-only common code: shared abstractions and base classes to simplify test setup/teardown.
## Usage
- Import and reuse helpers instead of duplicating logic in individual test modules.
- Prefer fakes/stubs for fast unit tests; reserve heavy integrations for dedicated test suites.
- Keep fixtures small and deterministic; document assumptions in comments.
## Guidelines
- Deterministic: avoid time, randomness, and network unless explicitly controlled.
- Thread-safe: mocks/utilities should be safe for concurrent tests or document limitations.
- Minimal coupling: do not reference FE/BE internal classes unless strictly necessary; prefer public APIs/SPI.
- Clear ownership: place helpers close to their domain but keep them generic and reusable.
- No secrets: never include real credentials or PII in fixtures or logs.
## Non-goals
- Not a place for production utilities or runtime dependencies.
- Avoid embedding heavy external services; use in-memory fakes or containers only in dedicated integration tests.
## References
- Test suites: `fe/fe-core/src/test/`
- Project docs: https://docs.starrocks.io/

View File

@ -30,7 +30,7 @@ under the License.
<relativePath>../pom.xml</relativePath>
</parent>
<artifactId>fe-common</artifactId>
<artifactId>fe-testing</artifactId>
<version>1.0.0</version>
<packaging>jar</packaging>

47
fe/fe-utils/README.md Normal file
View File

@ -0,0 +1,47 @@
# StarRocks FE Utilities and Base Libraries
The `fe/utils` module provides foundational, business-agnostic utilities for the Frontend. It offers reusable helpers and lightweight base libraries that other FE modules can depend on. No business logic lives here.
## Responsibilities
- Common helpers: collections, concurrency, I/O, serialization, string/bytes, hashing/encoding.
- Runtime utilities: clocks/timers, retry/backoff, rate limiting, validation/preconditions.
- Error handling: shared exceptions and error codes intended for cross-module use.
- Small, focused abstractions that simplify FE development.
## Design principles
- No business logic or domain-specific behavior.
- Dependency-light: avoid coupling to FE core internals; no cycles.
- Thread-safe or clearly documented threading semantics.
- Stable, minimal APIs; prefer composition over inheritance.
- Deterministic and side-effect-free where possible.
## What lives here (examples)
- Utility classes (e.g., StringUtils, CollectionUtils, Json/Yaml helpers).
- Concurrency helpers (executor wrappers, retry/backoff, locks).
- Validation and precondition checks.
- Lightweight data holders and result types shared across modules.
What does NOT live here:
- SQL/Planner/Optimizer/Analyzer code
- Connector/Plugin implementations
- RPC clients, storage, or environment-specific integrations
## Usage guidelines
- Other FE modules may depend on `fe/utils`; `fe/utils` must not depend on FE business modules.
- Keep helpers generic; avoid leaking domain concepts.
- Prefer small, single-purpose classes and clear method contracts.
- Cover utilities with unit tests and document edge cases.
## Testing
- Provide unit tests for all utilities, including negative and concurrency scenarios.
- Ensure determinism; avoid non-deterministic time or randomness unless injected.
## Versioning and compatibility
- Evolve APIs conservatively and keep backward compatibility.
- Deprecate before removal; document migration paths.
## References
- FE core: `fe/fe-core/src/main/java/com/starrocks/`
- Testing: `fe/fe-core/src/test/`
- Project docs: https://docs.starrocks.io/

View File

@ -28,7 +28,7 @@
<relativePath>../pom.xml</relativePath>
</parent>
<artifactId>plugin-common</artifactId>
<artifactId>fe-utils</artifactId>
<version>1.0.0</version>
<packaging>jar</packaging>

71
fe/plugin/README.md Normal file
View File

@ -0,0 +1,71 @@
# StarRocks FE Plugins
The `fe/plugin` directory hosts plugin implementations and integration glue for the Frontend. Plugins extend the FE core with capabilities beyond the built-in features by implementing interfaces from `fe/spi` and interacting with FE core through stable contracts.
Unlike connectors:
- Connectors focus on integrating external data sources and catalogs.
- Plugins focus on extending core capabilities (authorization, authentication, governance, observability, etc.) and do not act as data source bridges.
## Responsibilities
- Implement FE SPI contracts to augment core behavior.
- Provide optional features that can be enabled/disabled without altering FE internals.
- Remain decoupled from FE private classes; depend only on `fe/spi` and public abstractions.
## Typical plugin capabilities
- Authorization providers (e.g., Apache Ranger integration)
- Authentication providers (e.g., LDAP, Kerberos)
- Auditing and logging sinks
- Observability hooks (metrics/tracing exporters)
- Resource governance and admission control hooks
- Policy, masking, and row-level access integrations
Note: Exact plugin types depend on the available SPI extension points.
## How it interacts with FE core
- FE core programs against `fe/spi` interfaces.
- Plugins implement those interfaces and are discovered/loaded at runtime.
- FE core invokes plugin hooks during authentication, authorization, session, or administrative flows as defined by the SPI.
## Implementing a plugin
1. Identify relevant interfaces in `fe/spi` (e.g., authN/authZ, auditing, hooks).
2. Create a new module or package for your plugin and depend on `fe/spi`.
3. Implement the SPI contracts and provide discovery metadata.
4. Add configuration parsing/validation and document required settings.
5. Ensure thread-safety; plugins may be invoked concurrently.
6. Write tests (unit for SPI behavior; integration for end-to-end flows).
Guidelines:
- Keep implementations stateless where possible or guard state with proper synchronization.
- Fail fast on misconfiguration; surface actionable error messages.
- Do not block FE critical paths; use timeouts/backoff for I/O.
- Never log secrets or PII; honor FE security and redaction policies.
## Lifecycle
- Initialize: receive configuration/context and validate dependencies.
- Runtime: serve concurrent requests through defined SPI hooks.
- Shutdown: release external resources (clients, threads) idempotently.
## Configuration
- Use namespaced keys for plugin options.
- Support secure secret handling (env, keystores, injected credentials).
- Provide safe defaults and minimal required parameters.
## Versioning and compatibility
- Track and declare the `fe/spi` version supported by the plugin.
- Prefer backward-compatible changes; deprecate before breaking compatibility.
- Document compatibility with external systems (e.g., Ranger/LDAP/Kerberos versions).
## Security considerations
- Enforce authorization and authentication semantics defined by FE.
- Validate and sanitize all external inputs.
- Avoid leaking sensitive data in logs, errors, or metrics.
## Non-goals
- Plugins are not data source connectors and should not expose catalog/table access.
- Plugins must not depend on FE private/internal classes beyond SPI boundaries.
## References
- SPI contracts: `fe/spi/`
- FE core entry points: `fe/fe-core/src/main/java/com/starrocks/`
- Project docs: https://docs.starrocks.io/

View File

@ -25,7 +25,7 @@ java {
}
dependencies {
implementation(project(":plugin-common"))
implementation(project(":fe-utils"))
compileOnly("io.trino.hive:hive-apache")
compileOnly("org.apache.hadoop:hadoop-client")
}
@ -39,7 +39,7 @@ tasks.withType<JavaCompile> {
tasks.named<com.github.jengelman.gradle.plugins.shadow.tasks.ShadowJar>("shadowJar") {
// Minimize JAR
minimize {
exclude(dependency("${project.group}:plugin-common:${project.version}"))
exclude(dependency("${project.group}:fe-utils:${project.version}"))
}
// Relocate packages

View File

@ -6,6 +6,7 @@
<artifactId>starrocks-fe</artifactId>
<groupId>com.starrocks</groupId>
<version>3.4.0</version>
<relativePath>../../pom.xml</relativePath>
</parent>
<modelVersion>4.0.0</modelVersion>
@ -21,7 +22,7 @@
</dependency>
<dependency>
<groupId>com.starrocks</groupId>
<artifactId>plugin-common</artifactId>
<artifactId>fe-utils</artifactId>
</dependency>
<dependency>
<groupId>org.apache.hadoop</groupId>

View File

@ -30,8 +30,8 @@ val feUtParallel = project.findProperty("fe_ut_parallel") ?: "1"
dependencies {
// StarRocks modules
implementation(project(":fe-common"))
implementation(project(":plugin-common"))
implementation(project(":fe-testing"))
implementation(project(":fe-utils"))
// Regular dependencies
implementation("com.google.guava:guava")

View File

@ -27,7 +27,7 @@ under the License.
<groupId>com.starrocks</groupId>
<artifactId>starrocks-fe</artifactId>
<version>3.4.0</version>
<relativePath>../pom.xml</relativePath>
<relativePath>../../pom.xml</relativePath>
</parent>
<artifactId>spark-dpp</artifactId>
@ -42,12 +42,12 @@ under the License.
<dependencies>
<dependency>
<groupId>com.starrocks</groupId>
<artifactId>fe-common</artifactId>
<artifactId>fe-testing</artifactId>
</dependency>
<dependency>
<groupId>com.starrocks</groupId>
<artifactId>plugin-common</artifactId>
<artifactId>fe-utils</artifactId>
</dependency>
<!-- https://mvnrepository.com/artifact/commons-codec/commons-codec -->

View File

@ -29,11 +29,13 @@ under the License.
<packaging>pom</packaging>
<modules>
<module>plugin-common</module>
<module>fe-common</module>
<module>spark-dpp</module>
<module>fe-spi</module>
<module>fe-utils</module>
<module>fe-testing</module>
<module>plugin/spark-dpp</module>
<module>plugin/hive-udf</module>
<module>fe-core</module>
<module>hive-udf</module>
<module>fe-parser</module>
</modules>
<name>starrocks-fe</name>
@ -177,7 +179,7 @@ under the License.
<dependency>
<groupId>com.starrocks</groupId>
<artifactId>plugin-common</artifactId>
<artifactId>fe-utils</artifactId>
<version>1.0.0</version>
</dependency>
@ -189,7 +191,7 @@ under the License.
<dependency>
<groupId>com.starrocks</groupId>
<artifactId>fe-common</artifactId>
<artifactId>fe-testing</artifactId>
<version>1.0.0</version>
</dependency>

View File

@ -15,9 +15,9 @@
rootProject.name = "starrocks-fe"
include(
"plugin-common",
"fe-common",
"spark-dpp",
"fe-utils",
"fe-testing",
"plugin:spark-dpp",
"fe-core",
"hive-udf"
"plugin:hive-udf"
)