空间数据作业从经典集群迁到 Serverless，最容易出现的误判是：代码能 import，就认为读写、几何、栅格和输出都没有变化。

GeoBrix 的官方 README 把这种差异显式拆成 lightweight 与 heavyweight 两层：前者是纯 Python 与 SQL bindings，不带 JAR、init script 或 native GDAL bundle；后者是 Scala、Python/SQL bindings 加 native GDAL，服务于经典 x86 集群的分布式处理。两层尽量复用函数名，但部署位置、依赖、格式实现和能力范围仍须逐项验收。

数据口径与可核验事实

GeoBrix 官方 README 将其定义为 Databricks Labs 的高性能空间库，提供 raster、离散全球网格与 vector format I/O，并强调应让用户更深入使用 Databricks 原生 GEOMETRY/GEOGRAPHY 与 ST/H3 functions，而非取代它们。README 说明 GeoBrix 是 Mosaic 的现代后继项目。

轻量层使用 rasterio、pyogrio 和 shapely 的 pure Python 加 SQL bindings，不需要 JAR、init script 或 native GDAL bundle；

官方列出的适用环境包括 Serverless、standard/shared、Lakeflow pipelines 和 ARM。重型层则使用 Scala、Python/SQL bindings 与 native GDAL，面向 classic x86 clusters 的分布式处理。README 声明两层使用相同函数名，切换可从一行 import 开始，但这不是跳过数据回归的理由。

功能包分为 RasterX、GridX、VectorX 和 VizX。

RasterX 覆盖栅格 I/O、重投影、地形、光谱指数、XYZ/PMTiles、网格聚合、virtual tiles 和面向大栅格的 COG preparation；GridX 覆盖 BNG、quadbin、自定义网格、cell math、polyfill、tessellation 与聚合；VectorX 补充 MVT、TIN、authority-string CRS transform、反经线处理和几何有效性；VizX 为 Python-only 的 notebook visualization。

README 还给出具体接口约束：SQL functions 使用 gbx_ 前缀。

轻量 *_gbx readers/writers 不用 JAR，并与对应 heavyweight reader 保持相同 schema，官方以 row-count / byte parity 约束。轻量 vector I/O 以 WKB/WKT 加 *_srid companion columns 交换几何，需要用 Databricks 原生 st_geomfromwkb / st_aswkb 转换；README 明确原生 GEOMETRY/GEOGRAPHY 尚不能直接产出。

当前 README 表列 DBR 17.3、18 与 19 supported，并称一个 wheel 加一个 JAR 可覆盖三者；GeoBrix Light 需按目标 runtime 选择显式 pin 的 extra。Databricks Labs 项目按 AS-IS 提供，不受 Databricks SLA 覆盖。

研究的八项固定口径

  1. GeoBrix 提供 raster、离散全球网格和 vector format I/O。

  2. README 说明它增强 Databricks 原生 GEOMETRY/GEOGRAPHY 与 ST/H3 functions。

  3. 轻量层是 pure Python 与 SQL bindings，不含 JAR、init script 或 native GDAL。

  4. 轻量层可用于 Serverless、standard/shared、Lakeflow 和 ARM。

  5. 重型层以 Scala 与 native GDAL 在 classic x86 clusters 分布式处理。

  6. 两层使用相同函数名，但读写实现与部署环境不同。

  7. *_gbx 轻量格式与重型对应格式保持相同 schema，并以 row-count/byte parity 约束。

  8. 轻量 vector I/O 用 WKB/WKT 与 *_srid 列，原生 GEOMETRY/GEOGRAPHY 尚不能直接产出。

核心机制：同名函数不是同一运行条件

同一业务函数能在两层使用，降低了代码迁移成本；但运行面仍要单独建证据。Serverless 或 ARM 适合优先使用轻量层，因为它不依赖 native GDAL 或集群 init script。处理大量栅格、需要经典 x86 分布式 GDAL 行为时，重型层可能才满足需求。选层的输入不应只是“哪个快”，还包括计算类型、数据格式、部署策略、依赖许可、集群形态和数据落点。

同 schema 的含义是可以对比，不是可以不比。以一个 GeoTIFF 或 GeoJSON 回归样本为例，先比字段名、字段类型、行数、字节数、SRID companion 列、空值、边界几何和读取失败记录；再比统计、空间覆盖和下游原生 ST 函数的结果。若轻量读写与重型读写不同，必须把差异归因到格式驱动、GDAL、分区、对象存储或数据本身，不能由 Agent 或 notebook 输出掩盖。

GIS 场景

一个 Serverless 的洪涝影像筛查任务可先在轻量层把 COG 或 GeoTIFF 读为 raster 表，计算宽度、SRID、裁剪范围与基础统计；向下游交付时，用 WKB/WKT 与 *_srid 列把矢量边界桥接到 Databricks 原生空间函数。若同一项目转为高分辨率栅格的分布式批处理，再在 classic x86 集群测试 heavyweight 层，并拿固定 AOI、固定文件清单和固定输出 schema 与轻量结果对照。

另一个常见场景是把 GeoJSON、GeoPackage 或 File Geodatabase 写回 Volume。不能把“写成功”当作验收完成：README 指出 FileGDB 写入是 hybrid，需要 heavyweight GDAL init script；缺少 native 时应明确失败并改用 gpkg_gbx 或 geojson_gbx。因此导出格式必须成为部署选择的一部分，而不是在作业末尾临时决定。

技术路径

第一，按工作负载建立选择表：Serverless/ARM、常规共享集群和经典 x86 集群分别列出可用 tier、格式、安装 extra、JAR 与 init script。

第二，选择一个小而稳定的栅格和矢量样本，固定 hash、CRS、范围和预期 schema。第三，在每一层运行相同 reader、转换、空间函数与 writer，保存 row-count、byte size、SRID、空值和输出路径。第四，使用原生 ST 函数验证 WKB/WKT 转换后面积、边界与空间谓词。第五，只有当同 schema 和业务统计差异均已解释，才把切换扩展至完整 Delta 表或生产管道。

SQL 调用需明确 gbx_ 前缀，避免把 GeoBrix 辅助函数与平台原生函数混淆。对于大文件，先验证 virtual tiles、分区与内存上限，再测吞吐；不要仅以一次 notebook 的运行时间决定 tier。

风险与局限

README 的功能列表和同名函数承诺不是任何数据格式、运行时或规模下的性能保证。轻量与重型的格式支持并不完全相同；WKB/WKT bridge 也可能在 SRID、空值、维度或边界处理上暴露差异。原生 GEOMETRY/GEOGRAPHY 暂不能直接由库产出，意味着下游原生空间 SQL 前需要显式转换和核验。

GeoBrix 是 Databricks Labs 的 AS-IS 项目，不受 Databricks SLA 覆盖。生产团队仍须自行处理版本 pin、镜像、权限、Volume 路径、数据许可、失败重试与支持责任。

检查清单

  1. 是否按 Serverless、ARM、shared 与 classic x86 明确选择 lightweight 或 heavyweight？

  2. 是否记录目标 DBR、extra、wheel、JAR 与 GDAL init script？

  3. 是否对同一输入比对 schema、行数、字节、SRID、空值和空间覆盖？

  4. 是否用原生 ST 函数验证 WKB/WKT 与 *_srid 的转换？

  5. 是否确认目标读写格式在该 tier 下可用，尤其是 FileGDB hybrid 写入？

  6. 是否区分 GeoBrix gbx_ 函数和平台原生空间函数？

  7. 是否把 AS-IS 支持边界和生产运维责任写入发布记录？

结论

GeoBrix 的轻重两层为空间作业提供了跨环境的接口连续性，但连续性需要通过同 schema、行数、字节、SRID 与空间结果来证明。先把 Serverless 轻量链路或经典集群重型链路中的一个小样本验收清楚，再扩展到大栅格和生产写入，才能让执行层切换成为可复跑的 GIS 工程变更。

资料来源