矢量瓦片技术自 Mapbox 推出 MVT（Mapbox Vector Tile）规范以来，已成为在线地图渲染的事实标准。然而，随着地理空间数据体量从城市级跃升至行星级，MVT 在存储效率、解析性能与多维数据支持方面的局限性日益凸显。MapLibre 社区历经数年研发，于 2025 年推出 MLT（MapLibre Tile）格式，作为 MVT 的继任者，从底层架构重塑了矢量瓦片的数据组织方式。本文将从工程实践角度，深度剖析 MLT 的核心技术设计及其带来的系统性收益。
列式存储架构的范式转换
传统 MVT 采用行式存储模型，每个瓦片由若干层（Layer）组成，每层包含多个要素（Feature），每个要素由几何数据与属性数据交织构成。这种记录导向的布局在数据聚合与可视化场景中存在明显的结构性瓶颈：首先，几何坐标与属性数据混放导致列级别的压缩策略难以有效应用；其次，解码过程必须完整读取整个要素后才能访问其属性，内存访问模式不具备空间局部性；再者，行式布局产生的大量小对象对浏览器等运行时的垃圾回收机制造成持续压力。
MLT 采用列式存储架构，这一设计决策根植于分析型数据系统的成熟经验，同时针对瓦片渲染场景进行了精细调优。在 MLT 中，一个瓦片由若干 FeatureTable 组成，每个 FeatureTable 对应 MVT 中的 Layer 概念。关键差异在于，MLT 的 FeatureTable 不再以 Feature 为基本读写单元，而是将数据按列组织：几何坐标列、ID 列、各属性列分别存储，形成结构化程度更高的数据布局。
具体而言，MLT 的列式架构引入了流（Stream）的概念来描述物理存储单元。每个逻辑列可分解为多个物理流：Present 流用于标记空值存在性，Length 流记录可变长数据的尺寸，Data 流承载实际数据值，Offset 流则服务于字典编码场景下的索引定位。这种细分设计借鉴自 ORC 文件格式，但针对瓦片数据的特性进行了裁剪与扩展。例如，对于固定宽度的整型列，仅需 Data 流即可完整描述；而对于字符串属性列，则需 Present、Length、Data 三个流的协同配合。
列式布局的核心工程价值体现在三个层面。第一是压缩效率的跃升：同一列中的数据具有更高的类型一致性与值域相似性，使得差分编码、字典编码等轻量级压缩技术能够发挥更大效能。根据 MapLibre 官方基准测试，MLT 在大型瓦片上实现了最高 6 倍的体积缩减，典型缩放级别（Zoom 4-9）的压缩率达到 68% 至 81%。第二是解码性能的优化：列式存储支持按需读取特定列，避免了行式读取中无谓的数据遍历；配合 SIMD 加速的向量化指令，单线程解码吞吐量可达到 MVT 的 2 至 3 倍。第三是内存效率的改善：解析后的内存布局直接对应列式结构，省去了行式数据到列式结构的转换开销，且连续内存布局有利于 CPU 缓存的充分利用。
递归编码策略与编码器选择
MLT 的压缩策略并非单一技术的简单堆砌，而是一套精心设计的递归编码体系。该体系将编码过程划分为逻辑层与物理层两个抽象层次：逻辑层根据数据类型选择基础编码方案，物理层则在基础编码之上应用次级压缩。更为关键的是，这两层编码可以级联组合，形成混合编码（Hybrid Encoding），从而在特定数据集上榨取更高的压缩率。
在逻辑层，MLT 根据字段的语义类型确定基础编码家族。布尔型字段采用 RLE（Run-Length Encoding），利用连续相同值的出现概率进行压缩。整型字段提供 Plain（无压缩）、RLE、Delta（差分编码）、Delta-RLE 四种选项，Delta 编码特别适合序列值递增或递减的场景，如瓦片索引或要素 ID。浮点型字段引入 ALP（Alluxio Lazy Persistence）编码，这是一种针对浮点数优化的字典变体，在保留数值精度的同时实现较高压缩比。字符串与几何坐标则支持字典编码与 FSST（Fast Static Symbol Table）编码，FSST 作为现代字符串压缩算法，在保持词典压缩优势的同时具备更快的编解码速度。
物理层编码主要关注整数序列的高效处理。MLT 采用 SIMD-FastPFOR 作为默认整数编码方案，该算法利用向量化指令并行处理多个整数，在输出体积与解码速度两个维度均优于传统的 Varint 编码。FastPFOR 的核心思想是将整数分组后统一处理，通过位操作将大部分数值压缩至单字节存储，仅对溢出值采用额外存储。值得注意的是，MLT 并未完全弃用 Varint，而是将其保留作为兼容性与简单性兜底，特别是在与 MVT 互转或需要与其他系统交互的场景下，Varint 的普适性仍具价值。
编码器的选择策略同样经过严谨论证。MLT 官方推荐采用 BTRBlocks 论文中的启发式算法：首先计算数据集的统计指标（如平均游程长度、数值分布范围），据此排除明显不适用的编码方案；然后在约 1% 采样数据上穷举测试候选编码；最终选择压缩效果最佳的方案。这种采样评估机制避免了全量数据上的穷举搜索开销，同时保证了工程上可接受的选码质量。实践表明，对于 OSM（OpenStreetMap）等典型瓦片数据集，该策略能够在数秒内完成编码方案决策，而压缩率损失通常不超过最优解的 5%。
几何数据的结构化表示
几何数据是矢量瓦片的核心，也是 MLT 设计中技术含量最高的部分。MLT 摒弃了 MVT 中 Blob 化的几何编码方式，转而采用 Structure of Arrays（SoA）布局，将几何信息拆解为多个独立数组：GeometryType 标识要素类型，NumGeometries、NumParts、NumRings 等描述几何结构，VertexBuffer 存储实际坐标，IndexBuffer 与 VertexOffsets 则服务于预三角化与字典编码场景。
这种细粒度拆分带来了多重收益。一方面，不同类型的数据可以采用最适合其特性的编码策略：结构描述符通常数值较小且连续，适合 Delta-RLE；坐标序列则可应用 Morton 序编码（Z-Order Curve），将二维坐标映射为一维序列后在空间局部性上获得显著提升，从而增强后续压缩效率。另一方面，SoA 布局与 GPU 缓冲区的内存结构天然对齐，几何数据可经由极少的额外处理甚至零拷贝直接上传至显存，这对于 WebGL 等现代图形 API 的高效渲染至关重要。
MLT 还在几何表示层面引入了对三维数据的原生支持。GeometryZ 类型在二维坐标基础上增加 Z 坐标流，可存储高程信息用于地形渲染或三维建筑可视化。更为精妙的是，MLT 通过 M-value 机制支持顶点作用域属性（Vertex-Scoped Properties），即允许为每个顶点绑定独立属性值，这在传统 GIS 中对应线性参照（Linear Referencing）概念，可用于表达沿道路中心线的限速变化或公交线路的站点序列。Overture Maps 等下一代地理数据规范已开始采用类似模型，MLT 的前瞻性设计为未来数据源的对接奠定了基础。
内存格式与 GPU 直传设计
瓦片数据的处理链路涉及磁盘存储、网络传输、内存解析与 GPU 渲染多个环节，每个环节的数据表示都可能引入转换开销。MLT 在设计之初即将「存储格式」与「内存格式」作为统一问题考量，力求在各个阶段最小化数据转换成本。
MLT 的内存格式借鉴自 Apache Arrow、Velox 与 DuckDB 等分析型执行引擎，采用列式向量（Columnar Vector）作为基本抽象。每个向量包含类型元数据、可选的空值位图、以及连续存储的数据缓冲区。向量类型系统支持 Flat Vector、Constant Vector、Sequence Vector、Dictionary Vector、FSST Dictionary Vector、Shared Dictionary Vector 以及 REE（Run-End Encoded）Vector 等多种变体，每种变体对应特定的编码特征与访问模式。这种设计使得存储格式到内存格式的转换几乎是零开销的：对于已压缩数据，解析过程即是内存映射的直接过程；对于字典编码数据，向量格式本身就是字典的内存化表达。
MLT 内存格式的另一核心设计目标是 GPU 友好性。现代图形 API（如 Vulkan、WebGPU）要求几何数据以特定布局提交至显存，而 MLT 的 VertexBuffer 结构与这一要求高度契合。顶点坐标以交错（Interleaved）或分块（Strided）方式组织，可直接绑定至顶点着色器的输入变量；预三角化的多边形数据携带 IndexBuffer，可一次性提交至 GPU 进行绘制。这种「渲染就绪」（Render-Ready）的数据格式设计，使得 MLT 瓦片在解码后无需额外的内存拷贝或格式转换即可进入渲染管线，对于追求 60fps 流畅体验的地图应用意义重大。
工程迁移与生态兼容
任何格式的革新都不可避免地涉及迁移成本。MLT 在设计上充分考虑了与现有 MVT 生态的共存与过渡。ID 列的设计兼容 MVT 约定，优先使用 u32 以获得最佳编码效率；几何类型采用 OGC Simple Feature Access 模型，与 GeoJSON 等主流格式保持一致；JSON 类型的逻辑类型支持，使得属性数据中的元数据可直接以原生形式存储而无需 Base64 封装。
在实现层面，MapLibre 社区已提供多语言的参考实现，包括 Rust 解码器、TypeScript/JavaScript 解码器、Java 编码器与解码器，以及面向 C++ 的原生库。Rust 实现以其内存安全特性与高性能著称，适合服务端瓦片生成与转换流水线；TypeScript 实现则无缝集成至 MapLibre GL JS，为前端开发者提供熟悉的编程接口。截至 2026 年 1 月，MapLibre GL JS 与 MapLibre Native 已启动 MLT 格式支持开发，预计将在后续版本中正式提供生产级支持。
对于现有 MVT 瓦片服务，迁移路径是渐进式的。Java 实现的 MVT-to-MLT 转换器可作为过渡工具，在不改变前端的情况下逐步验证 MLT 的压缩收益；服务端批量转换则可一次性将历史瓦片迁移至 MLT 格式，配合 tileset metadata 文件的外部化策略，可进一步削减单瓦片的元数据冗余。对于性能敏感场景，MLT 的解码速度优势将直接转化为用户体验提升；对于存储成本敏感场景，6 倍的压缩率意味着带宽费用与存储费用的显著削减。
技术展望
MLT 的设计展现了 MapLibre 社区对地理空间数据系统演进方向的深刻洞察。列式存储不是新鲜概念，但其在瓦片场景的落地需要精巧的工程平衡；轻量级编码技术早已成熟，但其在 GIS 数据上的系统化应用仍属首次；GPU 直传是图形渲染的常识，但将其融入瓦片格式设计则需要格式设计者与渲染引擎开发者的深度协同。MLT 的成功在于将这些已知技术以正确的方式组合，并针对地图渲染的特定负载进行了深度调优。
展望未来，MLT 的扩展性设计为更多创新留出空间。实验性标记的复杂类型（Struct、List、Map）支持未来可能解锁属性数据的嵌套建模；RangeMap 类型已为 Overture Maps 的线性参照语义做好铺垫；而 GPU 可直接处理的向量格式则可能延伸至计算着色器场景，实现瓦片数据的并行预处理。MLT 不仅是一份格式规范，更是 MapLibre 社区面向下一代地理空间应用的技术承诺。
资料来源：MapLibre Tile 规范（https://maplibre.org/maplibre-tile-spec/specification/）、MapLibre Tile Spec GitHub 仓库（https://github.com/maplibre/maplibre-tile-spec）。