通过 OpenTelemetry Protocol 和 Apache Arrow 将遥测流量减少 10 倍
博客文章在发布后不会更新。这篇文章已经发布一年多了，其内容可能已过时，部分链接可能无效。在依赖任何信息之前，请务必核实。
我们非常激动地发布 带有 Apache Arrow 的 OpenTelemetry 协议，该协议基于 Apache Arrow——一种用于开发分析型应用的列式内存格式。此次集成通过压缩可将遥测数据流量减少至原来的 1/10，与启用 Zstandard (zstd) 压缩的最佳现有 OTLP 配置相比，性能提升了 40%。因此，这一新协议成为跨互联网传输遥测数据的理想选择。同时，我们很高兴地宣布在 opentelemetry-collector-contrib 仓库中发布了一对支持该协议的新接收器（receiver）和导出器（exporter）。该协议旨在作为遥测数据量巨大场景下 OTLP 协议的补充，已历经两年的讨论与开发。这是由 F5、ServiceNow Cloud Observability 以及 OpenTelemetry 社区众多技术领袖共同努力的成果（详见 捐赠议题）。压缩效益十分显著，对于大多数工作负载，压缩效率提升了 40%，而对于包含共享属性的多变量指标（multivariate metrics）工作负载，提升幅度更大。此集成的一大亮点是其无缝的适应性。在典型部署中，引入带有 Apache Arrow 的 OpenTelemetry 协议不需要任何实质性更改，用户只需重新部署新版本的 OpenTelemetry Collector 并稍微调整配置即可。
这一新协议将成为未来遥测数据处理进步的基石，并总体上促进与现代遥测后端的更好集成。
为何需要新协议？
遥测数据的增长是不可否认且迅速的。这种激增归因于以下几个因素：
- 设备和传感器的激增
- 应用部署从单体架构转向更细粒度的形式，如容器和无服务器函数
- 对数据驱动和 AI 驱动技术的日益依赖
随着遥测数据变得越来越分布式，工作负载变得与位置无关，跨越数据中心、云端和边缘。这种分布放大了优化跨互联网遥测传输的紧迫性。随着生态系统的转型，端到端优化和对齐遥测管道组件的需求变得更加迫切。
带有 Apache Arrow 的 OpenTelemetry 协议正是为满足这一日益增长的需求而打造的关键解决方案。
从历史上看，当遥测数据量适中时，它们的线路表示形式并不会引起太多关注。这类数据通常使用各种序列化框架封装为结构化对象。直到最近，OpenTelemetry 主要支持 JSON 或更常见的基于 Protobuf 的二进制格式来传输指标、日志和追踪。这种选择（尤其是 Protobuf）在简单性、数据表示效率和性能之间提供了良好的平衡，特别是在网络中传输低到中等容量的复杂遥测对象时。
然而，在后端，这些数据通常以列式格式存储，以优化压缩率、数据检索和处理效率（见图 1 比较行式与列式数据表示）。在整个管道中转向端到端的列式表示可以简化遥测传输与后端之间的接口。此外，它还减少了遥测数据传输所需的网络带宽。带有 Apache Arrow 的 OpenTelemetry 协议对指标、日志和追踪采用这种列式表示，从而显著节省网络开销。
图 1：内存表示：行式与列式数据。
为了进一步优化 OTel 实体批次的传输，新协议使用 gRPC 流来高效地利用字典编码。批次之间的大部分文本数据是冗余的；属性名称和值经常重复。Apache Arrow 支持字典编码，而面向流的协议允许我们仅在连续批次之间发送这些字典的增量。这些技术增强了协议的可压缩性。
另一个低效领域是 OTel 数据模型处理多变量指标的方式。目前，缺乏一种流式方法来报告具有共享属性的批量指标，而无需冗余地复制这些属性。在特定场景下，这种冗余给网络带宽和整体资源利用带来了不必要的压力。我们新设计的协议通过提供多变量指标的增强表示解决了这个问题。在某些场景中，我们观察到与 OTLP 相比，压缩率提高了 7 倍，且无需在客户端进行任何修改。未来的客户端 SDK 可以通过实现来无缝暴露这种增强，从而可能为应用程序带来更好的结果。
以下热图代表了在不同的批次大小和连接时长（以每个流的批次数表示）组合下，此新协议与 OTLP（均使用 zstd 压缩）之间的额外压缩收益百分比。此处使用的数据来自生产环境中捕获的 Span 流量。在大多数情况下，收益是巨大的。有趣的是，对于中等规模的批次（例如，每批 100 和 1000 个 Span），这些相对于 OTLP+zstd 的收益更为显著，这使得该协议对于必须最小化批处理引入的额外延迟的场景也非常有吸引力。几乎没有任何场景会因为微批次（例如，每批 10 个 Span）而导致 Arrow Schema 的开销变得无法接受，或使列式表示的优势变得微不足道。在其他情况下，这种初始开销很快就会在仅几个批次后被抵消。列式组织也更适合压缩。对于非常大的批次，只要压缩窗口足够大，zstd 的表现就非常出色，但即便在这种情况下，新协议仍然更胜一筹。如前所述，对于主要包含多变量指标的流量，这些压缩收益可能会更高。
进步并未止步于此。在项目的后续阶段，我们旨在利用列式布局，在扩展的 OpenTelemetry Collector 架构中显著提升数据处理速度，该架构将原生支持基于 Arrow 的新管道。根据我们的概念验证，我们预计这种更新后的 Collector 在数据处理速度上至少会有一个数量级的提升。
这些不同的低效来源和不匹配正是我们支持带有 Apache Arrow 的新 OpenTelemetry 协议作为现有 OTLP 协议替代方案的初衷。我们选择利用知名的 Apache Arrow 项目进行这种新的列式表示，具有诸多优势。Apache Arrow 非常高效，在数据库、数据流处理领域得到了广泛采用。其丰富的生态系统拥有一系列强大的库和工具，从 Parquet 桥接到 DataFusion 等查询引擎。这些资源可以加速创新特性的引入，使 OpenTelemetry 与日益转向 Apache Arrow 的现代数据管道对齐得更加紧密。
查看该协议的规范 OTEP 0156。编码/解码功能的参考实现可见于 open-telemetry/otel-arrow。
如何在我的部署中利用带有 Apache Arrow 的 OpenTelemetry 协议？
在项目的初始阶段，我们的主要目标是优化两个 Collector 之间的通信。这在遥测流量经由一个或多个 Collector 汇聚后再通过互联网转发至后端处理的设置中非常常见。鉴于带有 Apache Arrow 的 OpenTelemetry 协议比原始 OTLP 更复杂，将其局限在两个 Collector 之间提供了一个更容易实现的目标，并减少了对更广泛生态系统的潜在干扰。现有的客户端 SDK、处理器（processor）、接收器和导出器可以继续无缝工作。仅需重新配置两个 Collector 之间的导出器和接收器。直接的好处是减少网络带宽，从而直接节省网络成本（指标最高节省 7 倍，日志和追踪最高节省 2 倍）。有关此部署的详细说明，请点击此处：构建 Collector。
通常情况下，不存在万能的解决方案。资源有限或产生遥测数据极少的部署应坚持使用基于 OTLP 的标准 Collector。此外，带有 Apache Arrow 的 OpenTelemetry 协议需要双向 gRPC 流支持以及一定程度的批处理才能从列式表示中获益。这可能使该方案在某些特定场景下不适用。同样值得注意的是，在此项目阶段，Collector 的 CPU 和内存使用量预计会略有增加。这是由于将 OTLP 对象自动转换为带 Apache Arrow 的 OpenTelemetry 协议对象所带来的开销。然而，这种开销将在项目的后续阶段完全消除。
我们非常重视用户，因此开发了一个验证框架来减少错误并降低回归风险。我们利用遥测数据生成器来测试编码和解码过程，具体包括 OTLP 与带有 Apache Arrow 的 OpenTelemetry 协议之间的相互转换。此外，还建立了一个灵活的比较器，从语义上比较生成器产生的原始 OTLP 请求与经编码/解码过程后生成的 OTLP 请求。这种方法使我们能够处理众多的边缘情况并纠正几个关键错误。为了准确定位潜在问题的根源，我们的评估在两个不同层级进行：首先是基础层，我们直接与核心编码/解码机制交互，绕过 Collector 集成和网络通信；其次是 Collector 层，对包含网络交互在内的整个管道进行全面审查。
为了加强解码方法对格式错误（无论有意无意）的带有 Apache Arrow 的 OpenTelemetry 协议消息的防御，我们在解码前故意向消息中引入异常。我们的目标是确保解码方法在遇到无效输入时会返回错误消息，而不是崩溃。
除了这些自动化程序外，ServiceNow Cloud Observability 还采取了进一步措施，在各种分阶段环境（staging environments）中部署了实验性 Collector。这样做是为了评估 Collector 在面对真实流量时的行为以及协议的弹性。这些部署不仅增强了我们的自动化验证框架，还证实了我们的基准测试结果。
虽然我们一直在努力识别并解决回归和问题，但我们认识到现实场景的复杂性和多样性。因此，我们鼓励社区在各种部署情况和流量负载下评估这一新协议，从最不敏感的环境开始。您的部署和反馈将帮助我们进一步加强这一项目。
为了促进这一测试阶段，我们还改进了文件导出器，以便以压缩格式保存和匿名化数据。我们开发了工具来对这些匿名流量进行分析和重放，以识别错误或效率低下的根源。这种方法最近在优化为给定流量定义最佳 Arrow Schema 的逻辑中发挥了重要作用。在生产环境的一次实验中，我们注意到在处理一百万个 Span 后压缩率出现了下降。通过分析，我们能够找出问题根源并调整协议，以确保不再观察到此类下降（见此 PR）。
后续计划
未来，我们计划专注于在整个生态系统中全面集成带有 Apache Arrow 的 OpenTelemetry 协议。拟议的发展方向如下（排名不分先后）：
- 开发 Schema 优先的客户端 SDK 生成器，原生支持带有 Apache Arrow 的 OpenTelemetry 协议和多变量指标：旨在优化高遥测产量场景。
- 在 Collector 中引入新的管道类型：这将引入新一代的接收器、处理器和导出器，每一个都专门为消费和/或生产带有 Apache Arrow 的 OpenTelemetry 协议消息而设计。通过简化组件间的通信，我们期望提升数据处理效率。由于将绕过与 OTLP 的往返转换以及遥测批次的序列化和反序列化，预计会有显著的加速。
- 利用 Apache Arrow 生态中基于 SIMD 的数据处理引擎：这将进一步加速遥测数据处理并扩大数据处理能力范围。
- 考虑添加 Parquet 导出器：得益于 Apache Arrow 与 Apache Parquet 之间现有的桥接。
- 更广泛的社区预计也将开发更精简的导出器，以便更好地与特定的遥测后端集成。
结论
我们很期待看到社区对这一新协议的测试和基准评估。在我们看来，这代表了 OpenTelemetry 社区的一个重要里程碑，未来还会有更多令人兴奋的发展。
对于那些热衷于钻研 OpenTelemetry 与 Apache Arrow 集成细节的人，我们建议阅读 Apache Arrow 博客上的这两篇文章 [1, 2]。你将看到关于如何有效表示 OTel 指标、日志和追踪等分层且动态对象的各种方法的介绍。
我们要向我们的雇主 F5 和 ServiceNow Cloud Observability 表示感谢，感谢他们支持我们领导并执行这个项目。此外，感谢众多 OTel 技术领袖提供的宝贵帮助。