关键字: [亚马逊云科技， Graviton， 数据平台基于Graviton， 降本增效实践， 广告投放服务， 大数据量处理， 高并发业务需求]

导读

林树荣先生在本次分享中介绍了FreeWheel如何基于Amazon Web Services Graviton实例降低成本并提高效率。他详细阐述了FreeWheel的数据平台架构，以及在监控平台、查询引擎、数据同步、Matcher、流处理平台和批处理平台等组件中采用Graviton实例的实践。测试结果显示，与x86架构相比，Graviton实例在性能和成本方面都有明显优势。通过大规模采用Graviton实例，FreeWheel能够在业务数据量持续增长的情况下，将成本控制在稳定水平，节省了超过20%的总成本。

演讲精华

以下是小编为您整理的本次演讲的精华。

在这场富有洞见的分享中，来自FreeWheel的林树荣先生向我们揭示了他们公司如何通过采用亚马逊云科技的Graviton处理器来实现降本增效的实践历程。FreeWheel是一家以先进视频广告技术和优质视频内容服务全球的综合广告服务提供商，其服务的媒体包括Comcast、NBCU和Sky等传媒巨头。他们多次成功支持奥运会、世界杯和超级碗等大型赛事的广告投放服务。FreeWheel业务的特点主要是高并发、大数据量以及相对复杂的业务流程。

林树荣先生继而简要介绍了FreeWheel的数据平台架构。该平台由多个组件构成，自左而右依次是:广告投放服务器、Kafka消息队列、MirrorMaker和Kafka Connect用于数据同步、Matcher用于匹配不同类型的日志、近实时流处理平台(Spark Streaming)、离线批处理平台(Spark)、查询引擎(Presto/Trino)、业务应用和仪表板，以及覆盖整个平台的监控系统(Prometheus、Cortex、Grafana Loki)。

FreeWheel的数据平台面临着两大挑战。首先是业务数据量巨大且增长迅速，每天会有300TB的数据产生，增长速度一年接近翻倍，随之而来的是处理成本快速升高。其次是新上线的产品要求更低的数据延迟，从10分钟降低到3分钟，同时大型赛事会引发流量突增，需要更大的资源缓冲区来满足实时需求。公司新业务的引入虽然会增加客户的流量变现能力，但也带来了日志数据量的增长。当成本的增加和营收的增加不成正比时，控制成本就变得尤为重要。

过去，FreeWheel一直以在日志数据量持续增加的情况下控制成本保持稳定为目标。为实现降本增效，除了业务和服务层面的优化，他们也关注基础架构层面的优化，其中Graviton处理器是重点关注的对象。

自从亚马逊云科技推出Graviton处理器以来，已经陆续推出了Graviton二代、三代和四代的机型。这些ARM架构的处理器性能不断提升，但单价都远低于x86架构的机型。为全面评估Graviton处理器的性能，FreeWheel进行了多维度的测试，主要包括单机基准测试和完整Pipeline测试。单机基准测试使用UnixBench、SysBench等工具，采集不同的系统指标进行对比;完整Pipeline测试则是等比例缩放线上集群，回放线上数据来采集性能指标。对于基于Java的应用，他们还测试了不同JDK版本在Graviton处理器上的表现。

基准测试结果显示，Graviton处理器在CPU、内存读取等方面的性能远超过x86架构，包括CPU每秒的事件数、P95延迟、内存每秒的操作数等，且性价比更高。这为FreeWheel在数据平台中采用Graviton处理器奠定了基础。

接下来，林树荣先生分享了FreeWheel数据平台中各个组件采用Graviton处理器的具体情况。最早在2021年，他们就在监控平台上开始使用Graviton二代处理器。监控平台主要包括三个组件:Prometheus、存储组件Cortex(现已升级到Mimir)和日志系统Loki。测试过程中，他们使用Mork Server回放线上的指标数据来模拟Agent Server集群，然后起两套不同架构的Prometheus来采集指标，观察CPU使用情况等。测试结果显示，在使用相同机器数量的情况下，Graviton二代处理器的性能与x86持平，但价格优势达20%。当测试负载需要更多CPU时，Graviton二代的表现更加出色，CPU使用率上涨比x86更缓慢。上线后，成本降低20%。由于部署在EKS上，迁移过程相对简单，只需构建跨平台镜像并滚动重启服务即可，迁移时间也很短。

在监控平台上验证了Graviton处理器的可行性后，FreeWheel尝试在更大规模的服务上进行使用和测试，即查询引擎Presto。之前的峰会上，他们已经分享过相关内容，这里只是简单回顾测试结论。测试结果表明，JDK 11在ARM上的表现优于JDK 8。使用Graviton二代处理器和Corretto 11，性能可以与x86的九叉蜡烛持平，同时机器价格下降接近1/3。在线上负载测试中，Graviton二代处理器的性能还有6%的提升，整体成本节省20%。迁移规模大约是1，200台实例。

接下来是在数据同步组件MirrorMaker中的实践。测试方法同样是回放线上的采样数据，分为没有Lag的同步和追溯情况下的同步两种场景。从线上同步数据后，起两套不同架构的MirrorMaker来测试吞吐表现。测试结果显示，对于这种纯IO型应用，使用ARM架构处理器具有价格优势，但没有其他应用那么明显。从x86的c5系列换成Graviton二代的c6g时，吞吐略有下降，但当时已经推出了Graviton三代，使用c7g后发现性能提升12.5%。因此，FreeWheel最终使用c7g上线，在吞吐提升10%的情况下还可以节省10%的成本。迁移过程与监控平台和Prometheus类似，也是部署在EKS上，相对简单。

对于实时性要求高的Matcher组件，FreeWheel使用Apache Flink作为框架。测试方法同样是回放线上数据，测试对象是Graviton三代处理器。结果发现，三代处理器比x86的r5系列机器的吞吐提升20%，上线后可以节省32%的成本。由于是Flink on K8s的部署，迁移过程只需换起机器并重启应用即可，相对简单。

FreeWheel的Spark应用主要分为流处理平台和批处理平台。流处理平台基于Spark Streaming和Spark Structured Streaming，支持不同业务线动态提交ETL任务，SLA在2分钟到10分钟不等，输出以Iceberg和Hudi为主。批处理平台包含两个Pipeline，Pipeline A用于构建ODS层的基础数据建模，Pipeline B用于构建数仓层。

对于流处理平台，FreeWheel的测试方法是全量回放线上数据。测试结果显示，Graviton三代处理器的m7g性能与使用第三代英特尔至强处理器的m6i相当，但有价格优势;Graviton四代的m8g性能则比前两者都要好。最终上线后能够节省10%的成本。由于是Spark on K8s的部署，迁移过程与Flink类似，也比较简单。

对于批处理平台的Pipeline A，它是内存密集型应用，使用r系列机型。测试发现，使用Graviton三代处理器，平均运行耗时降低29%;使用四代处理器，平均运行耗时降低43%，因此上线后成本节省30%。Pipeline B是以聚合计算为主的计算密集型应用，使用c系列机型。测试结果显示，使用Graviton三代的c7g，性能可以提升8%，成本节省20%。对于离线应用，迁移过程比较简单，只需更改自动扩缩容组(ASG)的启动模板即可，涉及将JDK从8升级到11，节点大约300台。

在实践过程中，FreeWheel也遇到了一些问题和挑战。问题一是在Pipeline运行前或运行中进行扩容时，由于使用的是新机型，数量较少，常常会导致扩容失败，进而引起吞吐不足。他们的解决思路是在ASG中同时配置从Graviton二代到四代的多种机型，并调整应用的资源请求和Pod数量，使其可以适应不同规格的机型。另外，还配置了多个可用区，让应用可以使用各个可用区的机器资源。

问题二是，对于需要大量数据shuffle的应用，使用多个可用区部署会引入明显的跨可用区网络传输费用。他们的解决思路是在自研的ASG管理工具中引入逻辑ASG集合的概念，一个Pipeline对应一个集合，包含多个ASG，每个ASG只配置一个可用区的资源。Pipeline在扩容时会自动优先从一个ASG中扩容，只有在资源不足时才会扩容到另一个ASG，从而尽可能减少使用多个可用区的概率，降低跨可用区网络传输费用。

截至目前，FreeWheel数据平台中已有多个组件使用了Graviton处理器，包括监控平台、查询引擎Presto、数据同步组件MirrorMaker、Matcher、流处理平台和批处理平台。他们还在调研其他有状态应用如Kafka、KV存储Mattress、HBase和持久化数据库在Graviton处理器上的使用情况，但这些应用由于涉及数据迁移和混合部署带来的金丝雀问题，需要更多时间来给出解决方案。

最后，林树荣先生总结了FreeWheel数据平台使用Graviton处理器带来的显著效益，节省了超过20%的总成本。从右侧图表可以看出，在Graviton处理器的帮助下，结合自身的业务和服务层面优化，FreeWheel能够在流量翻倍的情况下控制成本保持稳定。

他建议，Graviton处理器适合于对ARM架构友好的原生应用，以及大数据场景中的内存密集型和计算密集型应用，推荐使用Java 10以上版本。FreeWheel能够快速采用Graviton处理器，主要原因是他们优先考虑无状态应用和在EKS上部署的应用，这些应用的迁移风险和成本较低;另一方面，他们使用的大部分开源组件都已经支持ARM架构。林先生对亚马逊云科技企业级服务的大力支持表示衷心感谢，这让他们在迁移Graviton的过程中非常顺利，最终为公司节省了大量成本。

总的来说，这次分享详细介绍了FreeWheel如何基于Graviton处理器在其数据平台上实现降本增效的实践，分享了他们的测试方法、迁移过程、遇到的挑战和解决方案，以及取得的显著效益。这对于其他企业在基础架构优化方面具有很好的借鉴意义。

下面是一些演讲现场的精彩瞬间：

在演讲中，讲者强调了公司面临的两大挑战:新产品需要更低的数据延迟和更高的处理性能，以及新业务带来的日志数据量增长，需要控制成本。

测试结果显示，对于纯 IO 型应用，使用 ARM 架构的 Amazon Web Services Graviton 3 处理器可提升 12.5% 的性能，同时降低 10% 的成本。

总结

亚马逊云科技的 Graviton 处理器为 FreeWheel 带来了显著的成本节省和性能提升。作为一家领先的视频广告技术服务提供商，FreeWheel 拥有高并发、大数据量和复杂业务需求的数据平台。为应对日益增长的数据量和更低延迟的新产品需求，FreeWheel 在其各个组件中逐步采用了 Graviton 处理器，包括监控平台、查询引擎、数据同步、Flink 应用和 Spark 应用等。

通过全面测试和逐步迁移，FreeWheel 发现 Graviton 处理器在性能和成本方面都有显著优势。例如，在监控平台上，使用 Graviton 2 代可节省 20% 的成本;在查询引擎 Presto 上，使用 Graviton 3 代可将成本降低近三分之一;在数据同步组件中，使用 Graviton 3 代可在吞吐提升 10% 的同时节省 10% 的成本。此外，在 Spark 应用的流处理和批处理平台上，采用 Graviton 4 代可分别节省 10% 和 30% 的成本。

虽然在实践中也遇到了一些挑战，如扩容失败和跨可用区网络传输费用增加等，但 FreeWheel 通过优化资源请求、多可用区部署等策略予以解决。最终，Graviton 处理器在 FreeWheel 数据平台上的广泛应用，使其在流量翻倍的情况下仍能控制成本保持稳定。FreeWheel 建议 Graviton 适用于对 ARM 友好的应用、内存密集型和计算密集型大数据场景，并推荐使用 Java 10 及以上版本。

我们正处在Agentic AI爆发前夜。2025亚马逊云科技中国峰会提出，企业要从“成本优化”转向“创新驱动”，通过完善的数据战略和AI云服务，把握全球化机遇。亚马逊将投入1000亿美元在AI算力、云基础设施等领域，通过领先的技术实力和帮助“中国企业出海“和”服务中国客户创新“的丰富经验，助力企业在AI时代突破。