简介面向需要在离线或内网环境部署数据可视化平台的运维人员与数据分析师这套资源打包了Superset 4.1.1中文版的Docker离线部署所需要件可帮助在无外网条件下快速搭建起数据探索与可视化服务。压缩包共六个文件总大小约五百二十四兆字节包括三个镜像包对应Superset主程序、PostgreSQL数据库与Redis缓存以及编排服务、配置参数、环境变量三类辅助文件整体结构清晰便于部署前逐一核对。已有三百六十四人学习/下载参考价值得到初步认可。通过编排文件即可一键启动整套容器组免去手动导入镜像与串联配置的流程中文版界面也降低了英文命令行不熟悉者的上手成本。拿到这份资源可直接在隔离环境中完成从环境准备到服务运行的全过程并在此基础上按实际需要调整数据库连接、端口映射与安全设定支撑后续的数据分析与图表展示。1. Superset 4.1.1 离线部署先想清楚这三件事把 Apache Superset 4.1.1 部署到内网听起来就是导个镜像、跑个容器的事实际动手才发现十次部署里至少有六次卡在同一个环节镜像搞定了初始化命令也执行了页面就是起不来。不是 Docker 不会用而是离线环境把“在线安装时代随手就能做的动作”全部变成了显式操作——拉不到 pip 包、下不了示例数据、中文字体缺失、时区不对任何一个都能让你在 8088 端口前干瞪眼。这篇文章面向的是要在政务网、企业内网、军工院所这类无外网环境里落地 BI 看板的人。我会用自己做过的一套方案从镜像准备、中文适配、数据库初始化到排错完整走一遍 Superset 4.1.1 的 Docker 离线部署链路。核心结论先放在这里离线部署 Superset 的技术难点不在 Superset而在你是否有意识地提前处理“初始化数据、字体、驱动、密钥”这四个离线拦路虎。2. 离线镜像与资源准备把外网能做的事提前做完离线部署的第一原则是所有需要外网的动作必须在有网的环境里全部做完并且用文件形式固化下来。Superset 4.1.1 本身是一个依赖很重的 Python 应用底层要 Node 构建前端资源、要一堆系统库支撑一旦进了内网再想补任何组件都极其痛苦。所以这一章要解决的是上飞机之前行李到底要带哪些。2.1 在有网环境拉取镜像并用 docker save 打包先找一台能访问 Docker Hub 的机器提前把 apache/superset 的 4.1.1 镜像拉下来。需要注意架构选择如果内网服务器是 x86_64直接拉默认 tag 就行如果是飞腾、鲲鹏这类 ARM64 节点必须指定 arm64 版本。等你到了内网才发现拉错架构连 docker pull 都用不了只能回去重来。# 在有网环境执行拉取官方 4.1.1 镜像 docker pull apache/superset:4.1.1 # 把镜像导出为 tar 包便于拷贝进内网 docker save -o superset-4.1.1.tar apache/superset:4.1.1 # 查看镜像的架构信息确认与内网服务器匹配 docker image inspect apache/superset:4.1.1 | grep -E Architecture|Variant执行完这三条命令你手上会有一个 superset-4.1.1.tar 文件。docker save 和 docker load 是离线部署最常用的镜像传输组合相当于给镜像打了一个包含所有文件层和元数据的快照包而不是简单地复制镜像索引。建议 save 后立即检查一下 tar 的大小官方 4.1.1 镜像在 1GB 到 1.5GB 之间如果只有几百 MB大概率是拉取过程出了问题趁还连得上网赶紧重拉。这里有个不少新手会踩的坑误以为用了docker export也可以。export 导出的是容器文件系统不含镜像的 CMD、ENTRYPOINT、ENV 等关键元数据load 回来根本跑不起来。离线分发必须使用docker save这个区别值得先记下来。2.2 在内网服务器上加载镜像并核验完整性把 tar 包通过移动硬盘或者内网共享目录拷入目标服务器后执行 docker load。加载本身很快但加载完不能直接开跑要先验证镜像的元数据是否完整。很多内网环境里 Docker 服务被安全策略限制过镜像加载时报错“permission denied”或“no space left on device”都是常见的因此我习惯把核验动作固化成一个三步检查。# 在内网服务器执行加载镜像 tar 包 docker load -i superset-4.1.1.tar # 确认镜像已出现在本地仓库 docker images | grep superset # 核验镜像的 ENTRYPOINT 和环境变量是否完整 docker image inspect apache/superset:4.1.1 --format {{.Config.Entrypoint}}docker load 之后docker images里能看到 apache/superset 和 4.1.1 的 tag说明文件层全部落地。第三条 inspect 命令会打印镜像的 Entrypoint 数组正常情况下输出类似[/usr/bin/docker-entrypoint.sh]。如果这条命令报错或者输出为空说明 tar 包本身损坏重新拷贝一遍别犹豫。确认镜像没问题后顺手启动一次容器做冒烟测试不映射端口、不挂配置跑三秒就删。这一步能在内网环境里提前暴露 Docker 运行时的问题比如容器引擎版本过低、内核不兼容等。# 用镜像启动一个临时容器做冒烟测试确认文件系统可读写 docker run --rm --name superset-smoke apache/superset:4.1.1 python -c import superset; print(superset.__version__) # 如果上面命令不方便执行也可用更简单的检查容器能否正常启动 docker run --rm --name superset-smoke apache/superset:4.1.1 /bin/true冒烟测试输出 4.1.1 才算过关。这里补充一个经验部分内网服务器的 Docker 版本停留在 18.09 甚至更旧而 Superset 4.x 的镜像基于较新的基础镜像构建旧版 Docker 在解压高版本镜像层时会失败。启动容器时报“unknown instruction”或“failed to extract layer”基本都是这个原因届时要先升级内网的 Docker 引擎这是无法绕过的前提。2.3 建立离线资源清单除了镜像还要带什么镜像只是 Superset 运行的本体离线上生产还需要准备配置、字体、数据库驱动和初始化脚本。我把这些整理成清单每次离线部署前照着打勾。下面是我常用的资源清单你可以直接拷贝成自己的模板资源项内容说明是否必带superset-4.1.1.tarSuperset 主程序镜像必带postgres:15-alpine.tar元数据库镜像推荐替代默认 SQLite生产必带redis:7-alpine.tar缓存队列镜像高并发或多 worker 时使用按需superset_config.py自定义配置文件含中文、时区、SECRET_KEY必带fonts-noto-cjk 离线包中文字体解决看板图表乱码必带数据库驱动 wheel 包如 pymssql、oracledb 等业务库驱动按连接库而定docker-compose.yml编排文件管理多容器启动顺序推荐第二项元数据库需要单独说明。Superset 默认使用 SQLite镜像内部已经把初始化逻辑内置了单机演示没问题。但生产环境多 worker 并发、定时报表一开SQLite 的锁机制会拖垮整个实例。离线部署时如果内网已经有 PostgreSQL 或 MySQL 服务就直接复用如果没有就提前在有网环境 pull 好 postgres 镜像一并带进去。2.4 用私有 Registry 做内网镜像分发如果你要在一批内网服务器上重复部署不建议每台都拷 tar 包再 load费时且容易出错。更好的做法是在内网搭一个私有镜像仓库把 tar 包 load 到一台管理机上再 push 到私有 Registry其余节点直接 pull。虽然这又多了一个容器但长期维护看板环境会轻松很多镜像升级时只需要在管理机替换镜像再 push 一次。# 在管理机上运行一个 registry 容器 docker run -d --name registry \ -p 5000:5000 \ -v /data/registry:/var/lib/registry \ registry:2 # 为本地镜像打上内网 registry 的 tag 并推送 docker tag apache/superset:4.1.1 192.168.1.10:5000/superset:4.1.1 docker push 192.168.1.10:5000/superset:4.1.1其他内网节点拉取时需要先在 Docker daemon 配置中把insecure-registries指向 registry 地址因为内网环境基本没有 HTTPS 证书。具体配置写在/etc/docker/daemon.json里改完重启 docker 服务。如果是在 Windows 或 macOS 上的 Docker Desktop则在设置界面的 Docker Engine 配置段里做同样的修改。这一步的常见报错是http: server gave HTTP response to HTTPS client大概率就是忘记了 insecure-registries 配置。3. 中文版适配语言包、中文字体与默认时区Superset 本身带多语言翻译最新热词里有人调侃“english only dashboard”其实 4.1.1 的中文翻译已经覆盖了大部分菜单和按钮。真正让用户体验变差的不是翻译缺失而是两个隐藏问题语言配置没有生效以及图表里的中文渲染成方块。这一章把中文版的三个关键适配点一次说清。3.1 修改 superset_config.py 开启中文界面Superset 的语言机制由 Flask-Babel 管理。默认配置里 URL 参数?languagezh可以临时切换成中文但用户每次打开都要手点很反人类。正式部署时应该把默认语言直接设成中文把自己人用的舒服一点。# superset_config.py 关键配置片段 # 开启可用语言列表zh 是内置翻译直接引用即可 LANGUAGES { en: {flag: us, name: English}, zh: {flag: cn, name: Chinese}, } # 把默认语言设为中文用户访问时不再需要手动切换 BABEL_DEFAULT_LOCALE zh # 以中国标准时间作为看板默认时区 SUPERSET_TIME_ZONE Asia/Shanghai配置文件的加载路径由环境变量SUPERSET_CONFIG_PATH控制默认指向容器内的/app/pythonpath/superset_config.py。因此挂载配置最直接的方式是把宿主机的一个 config 目录映射到/app/pythonpath。参数说明如下LANGUAGES是白名单不在列表里的语言即使翻译文件存在也不会出现于切换菜单BABEL_DEFAULT_LOCALE决定首次打开界面时使用哪个语言包SUPERSET_TIME_ZONE影响时间维度的展示和筛选器解析内网用户在国内就统一设置 Asia/Shanghai。3.2 用自定义镜像打入中文字体解决图表与截图乱码这是整个中文版适配里最容易被忽视的一环。Superset 4.1.1 的官方镜像基于精简版 Linux 构建默认不携带 CJK 字体。你在界面上看到的中文菜单正常因为网页渲染走的是浏览器的本地字体但看板导出 PDF、邮件报表附件、以及缩略图生成时走的是容器内的 Chromium 无头浏览器它找不到中文字体会退化成一个个方框。解决办法是构建一个自定义镜像在基础镜像里安装 Noto CJK 字体。推荐把字体打进镜像而不是运行时挂载因为挂载方案要求每台宿主机都准备字体目录并且在容器重建后要重新执行字体缓存刷新出问题的概率大幅增加。# Dockerfile.superset-cn FROM apache/superset:4.1.1 USER root # 安装 Noto CJK 中文字体并重建字体缓存 RUN apt-get update \ apt-get install -y --no-install-recommends fonts-noto-cjk \ fc-cache -f \ rm -rf /var/lib/apt/lists/* # 把写好的配置文件拷入镜像内省去运行时挂载 COPY superset_config.py /app/pythonpath/superset_config.py # 恢复非 root 用户保证容器安全基线 USER superset构建命令在有网环境执行因为 apt-get 需要 Debian 软件源。构建出的镜像 tag 建议命名为superset-cn:4.1.1后续内网分发就基于这个镜像来做而不是原始官方镜像。fonts-noto-cjk是 Debian 体系下的标准中文字体包包含黑体和宋体两类字型覆盖简体繁体常用字。fc-cache -f强制刷新字体缓存缺了这一行Chromium 还是找不到新装的字体导出的 PDF 依旧方块。构建成功后可以在有网环境先启动容器用fc-list :langzh确认字体已注册。3.3 把时区同步到业务数据的“原始时区”做过 BI 的人都知道时区配置不统一会导致时间维度统计错乱。Superset 的时间列解析会受到后端数据库时区、Superset 本身时区、以及前端浏览器时区三层影响。离线内网环境里业务库通常是国产数据库或老旧的 Oracle 实例时区往往存的不是 UTC这就更需要把 Superset 的默认时区固定下来。# docker-compose.yml 中为 Superset 容器追加时区参数 services: superset: image: superset-cn:4.1.1 environment: TZ: Asia/Shanghai SUPERSET_CONFIG_PATH: /app/pythonpath/superset_config.py容器的 TZ 环境变量控制的是 JVM、Python 这类运行时进程的本地时间它影响日志文件的时间戳和部分时间函数的默认值。建议 TZ 和 SUPERSET_TIME_ZONE 保持一致避免日志时间与界面时间出现两套标准。如果你连接的是 PostgreSQL注意在连接串里显式指定客户端的时区例如给 SQLAlchemy URI 追加?options-c%20timezone%3DAsia%2FShanghai防止驱动用 UTC 读取时间字段后展示偏差 8 小时。4. 初始化与启动数据库升级、管理员账号与 compose 编排镜像准备好、配置也挂进去了接下来是真正决定部署成败的初始化阶段。Superset 首次启动必须先执行数据库迁移和角色初始化顺序一错后面任何请求都会报出千奇百怪的错误。本章按我验证过的顺序从初始化命令讲到 compose 编排。4.1 首次初始化的三个必跑命令Superset 的数据模型会随版本演进4.1.1 的数据库结构必须在启动 Web 服务前完成迁移。官方镜像的 entrypoint 脚本通常会代为执行这部分工作但离线环境里由于环境变量、挂载权限等问题entrypoint 的自动化逻辑经常被跳过或失败所以手动执行一遍更稳妥。三件事按照固定顺序来做升级数据库结构、初始化角色权限、创建管理员账号。# 先以交互模式启动一个后台容器不直接跑 Web 服务 docker run -d --name superset-init \ -v /opt/superset/config:/app/pythonpath \ -v /opt/superset/data:/app/data \ superset-cn:4.1.1 \ sleep infinity # 第一步升级数据库结构到 4.1.1 版本 docker exec -it superset-init superset db upgrade # 第二步初始化角色、权限和数据源元数据 docker exec -it superset-init superset init # 第三步创建管理员账号密码至少 8 位且带字母数字 docker exec -it superset-init superset fab create-admin \ --username admin \ --firstname Admin \ --lastname Admin \ --email adminexample.com \ --password YourStrongPass123为什么用sleep infinity而不是直接启动 superset因为初始化阶段如果 Web 进程同时跑起来数据库迁移和 Web 进程读库会发生竞争常见现象是日志刷database is locked。先让容器处于空闲状态执行完三个命令后再把它删掉、正式运行。superset db upgrade会用 Alembic 迁移脚本把数据库 schema 推到 4.1.1 对应版本执行中如果报错通常不是 SQLite 就是版本冲突后文避坑部分会专门讲到。superset init负责写入角色权限执行完会看到一行行 role created 之类的输出。fab create-admin是 Flask-AppBuilder 提供的命令参数即用户字段。如果这一步忘记执行后续 Web 界面登录页能打开但没有任何账号可以登录这是新手最容易遇到的情况。创建成功后用docker rm -f superset-init把初始化容器删掉即可。4.2 用 PostgreSQL 替换 SQLite 的 compose 编排生产环境不要用 SQLite。SQLite 是文件型数据库在容器场景下有两个致命问题一是文件锁在 NFS 或 overlay 文件系统上表现不稳定容器重启后偶发database disk image is malformed二是并发读写能力弱多个用户同时刷看板时查询超时率剧增。离线部署时我一般固定用 PostgreSQL 15 Redis 7 的组合前者做元数据库后者做缓存。# docker-compose.ymlSuperset PostgreSQL Redis 完整编排 services: superset: image: superset-cn:4.1.1 container_name: superset restart: always ports: - 8088:8088 environment: TZ: Asia/Shanghai SUPERSET_SECRET_KEY: please-change-me-to-a-long-random-string SUPERSET_CONFIG_PATH: /app/pythonpath/superset_config.py volumes: - ./config:/app/pythonpath - ./data:/app/data depends_on: - db - redis db: image: postgres:15-alpine container_name: superset-db restart: always environment: POSTGRES_USER: superset POSTGRES_PASSWORD: superset-pass POSTGRES_DB: superset volumes: - ./pgdata:/var/lib/postgresql/data redis: image: redis:7-alpine container_name: superset-redis restart: always command: redis-server --appendonly yes volumes: - ./redisdata:/data这个 compose 文件里Superset 通过环境变量SUPERSET_SECRET_KEY注入密钥同时挂载了 config 目录。PostgreSQL 数据目录持久化到./pgdata容器重建不会丢元数据。PostgreSQL 要提前在 superset_config.py 里把连接串改成对应的库地址我一般这样写# superset_config.py 中的元数据库连接配置 SQLALCHEMY_DATABASE_URI postgresqlpsycopg2://superset:superset-passdb:5432/superset连接串里db是 compose 服务名容器网络内会自动解析到 PostgreSQL 容器 IP。如果你把 Superset 跑在宿主机 Docker 外、而数据库在容器内则需要把db改成127.0.0.1并确保端口已映射。两种方式选一种不要混用。4.3 两个必调参数SECRET_KEY 与元数据库 URL这两个参数是 Superset 部署里最重要的配置却也是离线环境里最容易被忽略的。先说 SECRET_KEYFlask 用它签名会话 Cookie、CSRF Token同一个集群内所有 worker 的 SECRET_KEY 必须一致。如果你今天部署完忘了设置容器重建后 Docker 生成的随机密钥变了所有登录用户的会话全部失效表现为“登录成功马上跳回登录页”。# 生成一个足够随机的 SECRET_KEY推荐用 openssl openssl rand -base64 48把输出粘到 superset_config.py 的SECRET_KEY变量中或者通过SUPERSET_SECRET_KEY环境变量传入。注意不要在 shell 脚本里写死同一段字符串用于所有环境至少开发和生产要用不同的值否则内网里一台机器泄露密钥整套环境都跟着遭殃。第二个必调参数是SQLALCHEMY_DATABASE_URI它决定 Superset 把看板定义、用户、角色存到哪里。默认值是 SQLite 文件路径生产必须改成 PostgreSQL原因上节已经说过了。改这两个参数后需要重新执行superset db upgrade才能生效因为数据库结构中部分表会因驱动不同产生差异。5. 离线部署避坑镜像加载了却起不来的 5 个现场原因离线部署 Superset 遇到问题你没法像有网环境那样随手去 GitHub 搜 issue 或者 pip install 补依赖。以下 5 个坑是我在实际部署中反复见到的按“现象 → 原因 → 解决”写清楚希望你能在第一次部署时就绕开。这里每一条都是血泪经验换来的建议直接把这一章截图或者复制到你的运维手册里。5.1 容器启动即退出日志停在 gunicorn “Address already in use”这就是典型的端口占用问题。现象docker run 之后容器一直处于 restart 状态docker logs 里能看到[ERROR] [Errno 98] Address already in use。原因不一定是 8088 被占用Superset 的 gunicorn 会绑定 8088但如果你之前在容器里用superset run -p 8088调试过或者同时启动了多个容器端口就会冲突。解决方式不推荐盲目换端口而是先把占用进程找出来# 查看 8088 端口被谁占用 netstat -tulpn | grep 8088 # 如果是宿主机进程占用kill 掉或者换端口映射 docker run -d -p 8089:8088 --name superset superset-cn:4.1.1 # 如果是另一个容器占用先停掉它 docker ps | grep superset额外提醒如果你把容器端口映射改成宿主机 8089而浏览器访问的还是 8088打不开是正常的别急着怀疑镜像坏了。5.2 执行加载示例数据卡在下载 CSV或显示 “Failed to fetch”这是离线环境必踩的坑。Superset 的superset load_examples命令会从 GitHub 仓库下载一批演示用的 CSV 数据内网环境没有外网下载必然失败。现象是命令执行到某个示例时停止或者提示urllib.error.URLError: urlopen error [Errno -2] Name or service not known。原因是官方镜像把示例数据集当作在线资源并没有内置到镜像文件系统里。解决思路很简单离线部署时不要执行 load_examples直接跳过。如果业务方一定要看演示看板就要在有网环境的宿主机上先把示例 CSV 抓到本地再拷贝到内网通过挂载目录读取。不过说实话生产部署用不到演示数据跳过去反而是最省事的方案。5.3 连接业务数据库时报缺少驱动报错包含 “No module named ‘pymssql’”Superset 连接 MySQL、PostgreSQL 时官方镜像已经内置了mysqlclient和psycopg2-binary不会报错。但如果你要连 SQL Server、Oracle、DB2官方镜像默认是不带对应驱动的。现象是在“数据库连接”页面填好 SQLAlchemy URI点测试连接报No module named pymssql或者ModuleNotFoundError: No module named oracledb。原因很明确驱动不在镜像里而离线环境不能 pip install。解决方式是在有网环境把驱动 wheel 包下载好一并带进内网再在容器里安装。注意 Superset 4.1.1 镜像的 Python 版本是 3.9下载 wheel 时务必选cp39对应版本否则装不上。# 在有网环境用目标镜像挂载目录下载驱动到本地文件夹 docker run --rm -v /tmp/packages:/packages superset-cn:4.1.1 \ pip download pymssql -d /packages # 将 /tmp/packages 拷进内网服务器后挂载到容器内并安装 docker run --rm -v /tmp/packages:/packages superset-cn:4.1.1 \ pip install /packages/pymssql*.whl安装完成后把 wheel 包保留在资源清单里以后每台内网服务器初始化时都装一遍。如果业务库比较多建议提前把常用驱动全部下载齐别等现场报错再等拷贝。5.4 登录之后立刻跳回登录页日志刷 CSRF token invalid现象特别迷惑admin 账号密码输入正确点击登录页面刷新后依然停留在登录页。查看容器日志能看到CSRF token invalid或The CSRF token has expired。原因是容器重建或配置修改后SECRET_KEY发生了变化Flask-WTF 用它来签名 CSRF Token密钥变了旧 Token 自然校验失败但浏览器页面还是用旧 Cookie 在提交。解决方式是重启后再等半分钟重新访问并且强制刷新浏览器缓存。关键在于这与网络无关别在 docker 网络不通上浪费时间。要根治的话保证每次启动都用同一个 SECRET_KEY写在 compose 的环境变量里而不是依赖镜像内随机值。5.5 看板中文全部显示为方块导出 PDF 全空这个坑我们在第 3 章提过字体问题但现实里很多人第一次部署时不会立即发现因为网页上看板显示正常直到第一次邮件报表发送附件里面全是空框才反应过来。现象是图表标题、坐标轴文字全部变成矩形占位符。原因是容器内没有中文字体Chromium 找不到字形。解决方式有两种最推荐的是按第 3 章的 Dockerfile 构建带字体镜像如果已经部署完不想重建镜像也可以运行时挂载字体目录并刷新缓存# 把宿主机字体目录挂载到容器内然后执行字体缓存刷新 docker run -d --name superset \ -v /usr/share/fonts:/usr/share/fonts:ro \ superset-cn:4.1.1 docker exec superset fc-cache -f注意挂载宿主机/usr/share/fonts要求宿主机系统里有可用的中文字体文件比如 Windows 下的 simhei.ttf 或 Linux 的 Noto CJK。字体缓存刷新完成后重启一次容器确保 Chromium 重新加载字体列表。6. 离线部署验证与留后路从健康检查到数据备份部署完成不代表可用离线环境里更没有“先上线看看再说”的余地。我每次做完 Superset 离线部署都会按固定顺序做一遍验证把问题留在自己手里而不是用户面前。这套验证清单很简单但每一条都能挡住 80% 的后续投诉。# 第一步确认容器健康状态 docker compose ps docker logs --tail 50 superset # 第二步Superset 自带的健康检查接口 curl -sf http://localhost:8088/health echo health ok # 第三步验证关键 API 是否返回 JSON curl -sf http://localhost:8088/api/v1/database/ | head -c 200 # 第四步确认数据库连接池无报错 docker exec superset superset db upgrade健康检查接口返回 OK 只说明 Web 进程活着不代表登录和数据库连接正常。第二步之后还要手动打开浏览器走一遍完整链路登录 admin 账号、创建一个最简单的图表、切换界面语言为中文、查看图表配置里中文字段是否能正常渲染。这一步建议让最终用户参与因为“能登录”和“能用”之间差着数据库连接池、行级权限、缓存预热等一堆隐性环节。关于留后路我再多说一个习惯升级前一定先备份元数据库。Superset 的看板配置、仪表盘布局、用户权限全在元数据库里容器本身随时可以销毁重建元数据库才是真正的资产。备份命令很简单但很多人在离线环境里懒得做等到升级翻车才追悔莫及。# 基于 compose 服务名备份 PostgreSQL 元数据库 docker exec superset-db pg_dump -U superset superset superset_backup_$(date %F).sql如果只是想换 Superset 镜像版本备份元数据库后直接修改 compose 里的 image tag执行docker compose up -d再用第 4 章的初始化命令跑一遍db upgrade。但只要升级前忘了备份中途出现 schema 不兼容想回到旧版本就只能对着报错干瞪眼。所以我的教训是无论多赶时间备份这条命令永远先执行。希望这个习惯连同前面所有步骤能帮你在内网环境里顺利跑起一套靠谱的中文 Superset 4.1.1少走几趟我走过的弯路。本文还有配套的精品资源点击获取