mirror of
https://github.com/apache/superset.git
synced 2026-05-24 09:15:19 +00:00
04451766e7
Previously docusaurus.config.ts had `onBrokenLinks: 'warn'`, so broken
internal links produced advisory warnings during build but didn't gate
merges. Tightening to `throw` surfaces every broken internal route at
build time. Three classes of issue fell out:
1. Stale `/docs/...` and `/docs/6.0.0/...` references in the 6.0.0
versioned snapshot. The user-facing docs section was renamed
`docs` → `user-docs` (routeBasePath) at some point after 6.0.0 was
cut, but the snapshot's links still pointed at the old prefix. The
live site redirects /docs/* → /user-docs/* at runtime, but
Docusaurus's onBrokenLinks checker doesn't honor redirects.
Bulk-rewrote /docs/* → /user-docs/* across the snapshot (and one
/docs/api → /developer-docs/api).
2. Bare-relative MDX links like `[Label](./mcp)` (no .md/.mdx
extension). Docusaurus renders an absolute href in SSR HTML, so
static crawlers see correct links — BUT React Router's `<Link>`
component on the client side resolves the bare path relative to
the current URL on click, so when the page URL has a trailing
slash (e.g. /extensions/overview/), `./mcp` becomes
/extensions/overview/mcp (404). This is exactly the broken-flow a
user reported on /developer-docs/extensions/overview/. Added the
`.md`/`.mdx` extension to all 44 such links across 17 files; this
makes Docusaurus resolve them to the canonical doc URL at the
<Link> level, so SPA navigation works regardless of trailing slash.
3. Miscellaneous content fixes:
- 4 `/configuration/feature-flags` references in 6.0.0 snapshot
pointed at a page that doesn't exist in that version (the
dedicated feature-flags page was added later). Repointed to the
`#feature-flags` anchor inside `configuring-superset.mdx`.
- 3 references to `superset-core/src/superset_core/rest_api/decorators.py`
in extensions docs were rendered as relative URLs, resolving to
/developer-docs/extensions/superset-core/... (404). Converted to
absolute GitHub URLs.
- 1 `/storybook/?path=...` link in extensions/components/index.mdx
pointed at a non-existent route. Repointed to the existing
`/developer-docs/testing/storybook` page that explains how to
run Storybook locally.
- 4 unclosed-paren markdown links in 6.0.0 installation-methods.mdx
(pre-existing source bugs).
Build now passes with `onBrokenLinks: 'throw'`. Note that
`onBrokenAnchors` is still `'warn'` (default); a separate effort
should tighten that and fix the surviving anchor warnings (currently
~60 instances of `/community#superset-community-calendar`).
73 lines
3.8 KiB
Plaintext
73 lines
3.8 KiB
Plaintext
---
|
|
title: Architecture
|
|
hide_title: true
|
|
sidebar_position: 1
|
|
version: 1
|
|
---
|
|
|
|
import useBaseUrl from "@docusaurus/useBaseUrl";
|
|
|
|
# Architecture
|
|
|
|
This page is meant to give new administrators an understanding of Superset's components.
|
|
|
|
## Components
|
|
|
|
A Superset installation is made up of these components:
|
|
|
|
1. The Superset application itself
|
|
2. A metadata database
|
|
3. A caching layer (optional, but necessary for some features)
|
|
4. A worker & beat (optional, but necessary for some features)
|
|
|
|
### Optional components and associated features
|
|
|
|
The optional components above are necessary to enable these features:
|
|
|
|
- [Alerts and Reports](/user-docs/6.0.0/configuration/alerts-reports)
|
|
- [Caching](/user-docs/6.0.0/configuration/cache)
|
|
- [Async Queries](/user-docs/6.0.0/configuration/async-queries-celery/)
|
|
- [Dashboard Thumbnails](/user-docs/6.0.0/configuration/cache/#caching-thumbnails)
|
|
|
|
If you install with Kubernetes or Docker Compose, all of these components will be created.
|
|
|
|
However, installing from PyPI only creates the application itself. Users installing from PyPI will need to configure a caching layer, worker, and beat on their own if they wish to enable the above features. Configuration of those components for a PyPI install is not currently covered in this documentation.
|
|
|
|
Here are further details on each component.
|
|
|
|
### The Superset Application
|
|
|
|
This is the core application. Superset operates like this:
|
|
|
|
- A user visits a chart or dashboard
|
|
- That triggers a SQL query to the data warehouse holding the underlying dataset
|
|
- The resulting data is served up in a data visualization
|
|
- The Superset application is comprised of the Python (Flask) backend application (server), API layer, and the React frontend, built via Webpack, and static assets needed for the application to work
|
|
|
|
### Metadata Database
|
|
|
|
This is where chart and dashboard definitions, user information, logs, etc. are stored. Superset is tested to work with PostgreSQL and MySQL databases as the metadata database (not be confused with a data source like your data warehouse, which could be a much greater variety of options like Snowflake, Redshift, etc.).
|
|
|
|
Some installation methods like our Quickstart and PyPI come configured by default to use a SQLite on-disk database. And in a Docker Compose installation, the data would be stored in a PostgreSQL container volume. Neither of these cases are recommended for production instances of Superset.
|
|
|
|
For production, a properly-configured, managed, standalone database is recommended. No matter what database you use, you should plan to back it up regularly.
|
|
|
|
### Caching Layer
|
|
|
|
The caching layer serves two main functions:
|
|
|
|
- Store the results of queries to your data warehouse so that when a chart is loaded twice, it pulls from the cache the second time, speeding up the application and reducing load on your data warehouse.
|
|
- Act as a message broker for the worker, enabling the Alerts & Reports, async queries, and thumbnail caching features.
|
|
|
|
Most people use Redis for their cache, but Superset supports other options too. See the [cache docs](/user-docs/6.0.0/configuration/cache/) for more.
|
|
|
|
### Worker and Beat
|
|
|
|
This is one or more workers who execute tasks like run async queries or take snapshots of reports and send emails, and a "beat" that acts as the scheduler and tells workers when to perform their tasks. Most installations use Celery for these components.
|
|
|
|
## Other components
|
|
|
|
Other components can be incorporated into Superset. The best place to learn about additional configurations is the [Configuration page](/user-docs/6.0.0/configuration/configuring-superset). For instance, you could set up a load balancer or reverse proxy to implement HTTPS in front of your Superset application, or specify a Mapbox URL to enable geospatial charts, etc.
|
|
|
|
Superset won't even start without certain configuration settings established, so it's essential to review that page.
|