第05章 海量数据调度：真正的技术护城河
本章导读
性能一出问题，第一反应往往是换引擎，真正该查的却是调度。本章对应原报告 2.3.1—2.3.3 节：2.3.1 节讲 LOD 与瓦片金字塔的四个手段，其中隐式分块正是 CesiumJS 1.146 取得 23 倍加载提速、13 倍内存下降的直接原因；2.3.2 节用一张表比较 PostGIS、Oracle Spatial、GeoScene、SDX+ 与专用点云引擎的边界；2.3.3 节拆开从无人机采集到前端调度的链路，指出空三失败、网格破洞、纹理色差、瓦片粒度这些很少写进方案的脏活才是成败所在。上一章讲引擎能力，这一章讲能力为什么发挥不出来。
学习目标
读完本章，你应当能够：
- 画出 2.3.1 节 LOD 与瓦片金字塔的四个手段，并说明各自降低的是哪类开销；
- 复述隐式分块的机制，并说出 CesiumJS 1.146 的 23 倍与 13 倍分别指什么；
- 按 2.3.2 节的表，为“中等规模三维要素管理”与“数十亿点级别的点云组织”各选一种技术并说明理由；
- 说明 PostGIS 在三维上的能力边界，以及把 TB 级实景网格塞进数据库的架构错误在哪里；
- 按 2.3.3 节复述实景三维数据链路，并指出其中至少四个容易出问题的环节；
- 用本章框架诊断一个具体项目首屏慢的位置，并给出三项优化动作。
2.3.1 LOD 与瓦片金字塔
三维数据的量级决定了“一次加载”不可能。调度体系的核心是空间分块 + 多级细节 + 按需请求：
- 几何 LOD：按屏幕误差（geometric error）决定瓦片细化层级。3D Tiles 的
geometricError就是这套机制的量化表达。 - 纹理 LOD：
EXT_texture_info_constant_lod解决的正是纹理细节与视距的匹配问题。 - 隐式分块（implicit tiling）：不再为每个瓦片写 JSON 条目，而是用数学规则生成——3DTILES_implicit_tiling + subtree 的组合。这是 CesiumJS 1.146 性能跃升的直接原因（23×加载速度、13×内存下降）。
- 包围体优化：S2 单元（全球尺度）、圆柱/椭球区域（特殊形体）、地平线遮挡点（视锥剔除），共同降低无效请求。
2.3.2 空间索引与数据库
| 技术 | 三维能力 | 适用场景 |
|---|---|---|
| PostGIS | 3.x 系列支持 3D 几何类型、SFCGAL 三维运算（体积、3D 距离、3D 相交）、PGPointcloud 点云扩展 | 开源栈首选，适合中等规模三维要素管理与空间查询 |
| Oracle Spatial | 三维几何与 LRS（线性参考）成熟 | 大型企业与政务既有栈 |
| Esri GeoScene / ArcGIS | 商用一体化，I3S 原生 | Esri 生态项目 |
| SuperMap SDX+ | 空间数据库引擎，支持 S3M | 国产全栈项目 |
| 专用点云引擎 | PDAL、Entwine/EPT、Potree | 数十亿点级别的点云组织与流式浏览 |
PostGIS 在三维上的真实边界：它能很好地管理“带 Z 值的矢量”、做三维距离与相交判断、用 SFCGAL 计算体积；但它不适合直接存储与调度 TB 级实景三维网格——这类数据应在瓦片化后放到对象存储 + CDN，数据库只存元数据与索引。混淆这两者，是很多架构设计的根本错误。
2.3.3 数据链路的工程现实
一条完整的实景三维数据链路通常是：
无人机采集(多视角影像 + POS)
→ 空三加密(SfM/BA)
→ 密集匹配 → 网格重建 → 纹理映射
→ OSGB(分块) → 3D Tiles 转换(含 LOD 重排)
→ 对象存储 + CDN → 服务发布 → 前端调度
每一步都有坑：空三失败（弱纹理、大面积水面）、网格破洞、纹理色差（不同架次光照差异，SuperMap 2026 的“智能匀光匀色”正是针对此）、OSGB 转换后瓦片粒度不合理导致首屏慢。这些“脏活”决定了项目成败，却很少出现在技术方案里。
本章小结
- 三维数据的量级决定了一次加载不可能，调度体系的核心是空间分块、多级细节与按需请求三件事。
- 隐式分块把瓦片层级的描述从逐条 JSON 换成数学规则生成，元数据量与请求次数一起下降；这也是 1.146 版本性能跃升的来源。
- PostGIS 适合管理带 Z 值的矢量、做三维距离与相交判断，但不适合直接存储与调度 TB 级实景三维网格。
- TB 级实景网格应在瓦片化后放对象存储加 CDN，数据库只存元数据与索引；混淆这两者，是很多三维架构设计的根本错误。
- 实景三维链路的每一步都有坑：空三失败、网格破洞、纹理色差、瓦片粒度不合理导致首屏慢，这些脏活决定项目成败。
- 性能优化应先查分块与索引，再谈引擎与硬件；顺序反了，投入很难换来效果。
思考与练习
- 记录你所在项目平台的首屏加载时间与首屏请求数，按 2.3.1 节判断瓶颈在 LOD、分块还是包围体。
- 辨析：某架构方案把 TB 级倾斜摄影成果直接导入 PostGIS，并称“统一存储便于管理”。用 2.3.2 节说明问题并给出替代架构。
- 给定实景三维链路的四个环节（空三、网格重建、OSGB 转换、服务发布），为每个环节写一条可执行的验收检查项。
- 某项目已启用隐式分块但仍卡顿。按 2.3.1 节四个手段逐项排查，写出排查顺序与每一步的判据。
- 取一份你单位的倾斜摄影成果，检查其瓦片粒度与生产时间跨度，判断是否适合直接上线。