Dataflow状态持久化技术相较于Flink RocksDB等方案有哪些已知局限性？

• 存储成本与弹性不足
  Windmill完全绑定GCP持久化磁盘（PD）存储，无法像RocksDB一样灵活适配本地磁盘、对象存储、分布式存储等多种底层存储介质，PD的计费模式和固定容量配置会拉高中小规模作业的存储成本；同时PD扩容缩容存在分钟级滞后，无法根据作业状态的实时变化动态调整存储资源，容易出现资源浪费或容量不足的问题。
• 性能调优空间有限
  RocksDB作为开源嵌入式KV存储，支持用户根据作业特征调整内存表大小、压缩策略、布隆过滤器规则、读写线程数等数十种参数实现针对性优化。而Windmill是Dataflow托管的黑盒组件，用户几乎没有自定义调优的权限，对于状态访问延迟要求极高的场景（如亚毫秒级实时规则匹配）很难满足需求；另外Windmill的IO路径需要走PD网络存储调用，相比RocksDB直接读写本地磁盘的场景，平均延迟高2~5倍，长尾延迟波动也更大。
• 状态可移植性差
  RocksDB的状态快照为标准SSTable格式，可便捷导出、离线分析、跨集群迁移恢复，也可对接第三方工具实现状态校验、裁剪等操作。Windmill的存储格式为Google闭源格式，仅支持Dataflow服务内部的快照和恢复，无法导出做离线分析，也不能迁移到非Dataflow的Beam运行环境，厂商绑定程度极高。
• 大状态场景适配能力弱
  RocksDB支持增量Checkpoint，仅需同步最新修改的SSTable文件到持久化存储，TB级大状态作业的Checkpoint开销极低，对作业运行的影响很小。而Windmill目前对单作业10TB以上的超大规模状态支持不够成熟，Checkpoint耗时会随状态体量线性增长，很容易触发作业背压甚至故障转移。
• 高级状态特性支持受限
  RocksDB支持用户自定义序列化器、列族、前缀扫描等高级KV特性，可灵活适配各类复杂有状态计算需求。Windmill目前对复杂状态类型、范围扫描操作的支持存在较多限制，部分Beam高级状态API在Dataflow运行时会出现性能下降甚至不兼容的问题。

内容的提问来源于stack exchange，提问作者py-r