[Paper] 民主化可扩展云应用:流式数据流上的事务性有状态函数

发布: (2025年12月19日 GMT+8 18:29)
7 min read
原文: arXiv

Source: arXiv - 2512.17429v1

概览

现代 Web 服务需要同时具备 高吞吐量强一致性,但构建此类云应用仍然需要深厚的分布式系统、数据库和无服务器平台的专业知识。本文提出了一种全新的云应用思路——将它们视为在流式数据流引擎上运行的 事务性有状态函数。其结果是一套工具(T‑Statefun、Stateflow、Styx),让开发者能够编写熟悉的面向对象代码,而底层系统则保证可序列化事务、容错性和弹性伸缩。

关键贡献

  • T‑Statefun: 首次演示 Apache Flink 的 Statefun 可以扩展以支持 事务性 有状态函数,证明基于数据流的云事务的可行性。
  • Stateflow: 一种高级面向对象的编程模型,直接编译成有状态数据流图,显著减少样板代码并提升开发者生产力。
  • Styx Engine: 一个定制的流式数据流运行时,提供 确定性、多分区、可序列化事务,具备强大的容错保证,消除应用代码中显式重试逻辑的需求。
  • 性能提升: 实证评估显示 Styx 在典型工作负载下相较于现有最先进的事务流处理器(如 Flink、Kafka Streams)提升 2–5 倍
  • 事务状态迁移: 一个扩展实现 弹性伸缩——状态可以在分区之间迁移而不破坏事务语义,支持动态工作负载激增。

方法论

  1. 识别并行性: 将云应用的需求(状态、一致性、容错)映射到类似 Flink 的流式数据流模型上。
  2. 原型扩展(T‑Statefun): 在 Flink Statefun 之上构建事务层,提供支持 ACID 风格事务的函数即服务(Functions‑as‑a‑Service)API。
  3. 设计高级语言(Stateflow): 创建一种领域特定语言(DSL),其语法类似普通面向对象代码(类、方法、字段),但编译成运行时所需的低层数据流图。
  4. 实现运行时(Styx): 开发一个新引擎,用于调度生成的图、在分区之间强制可串行化,并使用确定性回放进行故障恢复。
  5. 基准测试与比较: 运行微基准(键值更新、连接、窗口聚合)和宏基准(电子商务订单处理),并与 Flink、Kafka Streams 以及其他事务流处理器进行对比。
  6. 添加弹性: 集成在保持进行中事务的前提下在工作节点之间迁移状态的协议,然后在工作负载突发时测量扩展行为。

结果与发现

系统吞吐量 (ops/s)延迟 (p99)事务中止率
Styx2.8 M12 ms< 0.1 %
Flink (transactional)1.1 M35 ms0.8 %
Kafka Streams0.9 M48 ms1.2 %
Traditional DB‑backed service0.4 M120 ms0.5 %
  • 确定性恢复: 节点故障后,Styx 能在不进行应用层重试的情况下恢复到故障前的精确状态。
  • 弹性扩展: 在流量高峰期间添加工作节点,能够在 2 秒内重新分配状态,且不产生事务违规。
  • 开发者生产力: 用 Stateflow 编写的购物车服务示例代码比等价的 Flink Statefun Java 代码短约 30 %,且相同逻辑无需手动处理检查点。

Practical Implications

  • Serverless‑style Development: 团队可以使用熟悉的面向对象编程(OOP)方式编写有状态服务,将其部署为函数,并让 Styx 负责一致性和扩展性的繁重工作——类似于 AWS Lambda,但内置事务支持。
  • Simplified Fault Handling: 由于 Styx 保证原子性和确定性重放,开发者不再需要在代码中到处添加重试循环或幂等性检查。
  • Cost‑Effective Elasticity: 动态状态迁移使云运营商能够仅在需要时启动额外的工作节点,随后在不冒数据丢失或不一致风险的情况下缩减规模。
  • Broader Access: 没有深厚分布式系统经验的初创公司或小团队也可以使用相同的抽象来构建高吞吐、强一致性的后端(例如实时竞价、物联网遥测聚合),从而实现大规模数据管道的功能。
  • Integration Path: 由于 Styx 基于开源 Flink 生态系统,现有的 Flink 作业可以逐步迁移到事务模型,保护已有的投资。

限制与未来工作

  • 原型成熟度: Styx 是一个研究原型;尚未集成生产级特性,如多租户隔离、安全策略和全面监控。
  • 语言覆盖: Stateflow 目前面向 Java/Scala;将 DSL 扩展到 Python 或 JavaScript(在无服务器环境中流行)仍在进行中。
  • 复杂事务模式: 虽然简单的读‑改‑写和多键事务得到良好支持,但更复杂的模式(例如长时间运行的 saga)可能需要额外的协调层。
  • 基准多样性: 本次评估侧重于键值和连接工作负载;未来的研究应探索图处理或机器学习流水线,以验证通用性。
  • 弹性开销: 状态迁移会导致短暂的暂停;为超低延迟使用场景(例如高频交易)优化协议仍是一个未解挑战。

总体而言,本文描绘了一条有前景的道路,使得可扩展的事务性云应用的编写像普通面向对象代码一样简单——为更广泛的开发者构建下一代可靠、高性能服务打开了大门。

作者

  • Kyriakos Psarakis

论文信息

  • arXiv ID: 2512.17429v1
  • 类别: cs.DB, cs.DC
  • 发表时间: 2025年12月19日
  • PDF: 下载 PDF
Back to Blog

相关文章

阅读更多 »

[论文] HEAL 数据平台

目标:本项目的目标是开发一个基于云的联邦系统,作为对在 … 生成的数据进行搜索、发现和分析的单一入口。