3. 流式遥测数据模型与编码

在 Juniper Telemetry 体系中，数据模型与编码格式决定了“设备发出什么、采集器如何解析、后端如何存储与查询”。很多团队在部署初期只关注“能不能收到数据”，忽略了编码选择对带宽、CPU、Schema 演进和查询效率的长期影响。本节围绕 GPB、JSON、KV 三种主流编码，讲清它们的结构差异、适用场景，以及如何根据业务需求做出可落地的选择。

一、三种编码的本质差异

Juniper 的流式遥测（Streaming Telemetry）通过 gRPC 或 UDP 推送数据，编码格式决定了 payload 的形态：

• GPB（gRPC Protocol Buffers）：基于 .proto 定义的二进制编码，字段以 tag 编号标识，体积最小、解析最快，适合高频、大规模采集。Juniper 提供大量预定义 .proto 文件（如 telemetry.proto、jnpr_interface_ext.proto），采集端需加载对应 schema 才能解码。
• JSON：文本编码，字段名自描述，可读性强，调试方便，但体积通常是 GPB 的 3～10 倍，解析开销大，适合低频、调试或与现有 JSON 生态对接的场景。
• KV（Key-Value）：以“路径—值”对形式组织，如 /interfaces/interface[name=ge-0/0/0]/state/counters/in-octets = 123456，结构扁平、易于映射到时序数据库的标签体系，适合指标类数据的快速入库与查询。

三者的核心区别可以归纳为：GPB 重“紧凑与性能”，JSON 重“可读与通用”，KV 重“扁平与可索引”。选择哪一种，取决于采集频率、数据量、后端存储模型和团队运维能力。

二、Schema 与 Path：数据模型的骨架

无论使用哪种编码，数据都来源于设备上的 Sensor Path。Path 是 YANG 模型中的节点路径，例如：

/interfaces/interface[name=ge-0/0/0]/state/counters/in-octets
/interfaces/interface[name=ge-0/0/0]/state/oper-status
/system/cpu/memory/used

Path 决定了采集的粒度和范围。粒度越细，单条数据越小，但采集条目越多；粒度越粗，单条数据越大，但解析和存储的字段更复杂。实际部署中，建议按业务域拆分 Path，例如接口流量、CPU/内存、路由协议状态分别订阅，便于独立调整频率和编码。

Schema 则是 Path 对应的结构定义。GPB 依赖 .proto 文件，字段以编号和类型描述；JSON 和 KV 虽然自描述，但在后端入库时仍需映射到统一的标签和字段模型。Schema 演进时，GPB 需要同步更新 .proto 并重新编译采集端，JSON/KV 则相对灵活，但容易因字段名变化导致解析失败。因此，Schema 版本管理是流式遥测工程化的重要环节。

三、Key-Value 结构与标签映射

KV 编码的典型形态是“路径 + 值”，采集端通常将其转换为时序数据库的标签（label）和指标（metric）。例如：

Path: /interfaces/interface[name=ge-0/0/0]/state/counters/in-octets
Value: 123456789
映射为：
metric: interface_in_octets
labels: {device="r1", interface="ge-0/0/0"}
value: 123456789

这种映射的关键在于：Path 中的 [name=...] 部分应提取为标签，而不是拼进指标名。否则标签基数会爆炸，查询性能急剧下降。对于 GPB，同样需要在采集端将字段映射为标签和指标；对于 JSON，则需解析嵌套结构后扁平化。三种编码最终都要落到同一套标签模型上，才能保证后端查询的一致性。

四、如何根据业务需求选择编码

选择编码时，可以从以下四个维度判断：

实际工程中，常见做法是混合使用：核心高频指标用 GPB，保证性能和带宽；调试或临时采集用 JSON，快速验证 Path 和字段；需要快速入库和标签查询的指标用 KV。关键是保持后端标签模型统一，避免同一指标在不同编码下产生不同的标签结构。

总结来说，GPB、JSON、KV 不是互斥的“三选一”，而是面向不同采集目标和后端模型的工具。理解 Path 与 Schema 的关系、掌握 KV 到标签的映射方法、根据频率和数据量选择编码，才能让流式遥测在可观测性体系中真正发挥价值。