为模型服务的数据系统正在从0开始发展：
1. 传统机器学习领域虽然已经发展了多年，但是由于算力和架构的限制，对数据的消耗能力非常有限。大模型时代pre training, post training 阶段数据的消费能力是非常惊人的。特别是在大家尝到1 epoch的甜头以后，对于数据的需求上涨了成千上万倍。
2. 如何在短时间内生产这么多数据来供应模型训练就成了很大的问题。其中最重要的是计算和存储。
先说计算，近几年如此大规模的计算需求基本发生在互联网公司的数据仓库链路中，承担ETL，数据建模，adhoc查询等需求。Spark也在这些IO密集型，重shuffle，aggregate的场景中胜出，所以生态基建和普及率是最高的。也正因为此成为了各家模型公司的主要数据计算引擎。但也明显有水土不服，早期版本无法使用GPU，pyspark 昂贵的序列化反序列化代价，虽然都已经补上，但异构集群困难的自定义调度，昂贵的容错代价等还是阻碍了它接管所有计算场景。
3. 一众像ray一样提供更底层任务/数据编排调度的框架弥补了Spark的不足，在这种map算子占绝大多数的轻分布式计算场景中获得了先机。我觉得ray.data被推崇的主要原因是开放了task的调度接口，以及放弃对job级别幂等性保障而全面转向到min batch带来更低的心里使用成本。
4. 但是年轻的ray.data问题还非常多，经常被我吐槽还是一个toy project。缝合的类型系统洞非常多，经常出现写出去读不回来的尴尬处境。一些为了避免OOM的提前资源切分又做的很粗，在追求性能的场景下成为累赘。聊胜于无的auto scale和backpressure机制等都让它看起来无法胜任超大型的任务。但也正是因为这个生态位的短缺，ray.data正被很多大模型公司赶着上架。