IO的优化一般由如下几个方面：

一般来说，为了获取更好的数据本地性，我们会将 datanode 与 nodemanager 混合部署，这就意味着相同的一块硬盘需要同时承担 hdfs读写 / spark中间数据(shuffle)读写等负载，任务运行时间在一定程度上是不可控的，同时也会影响计算效率。

缺点：

优点：

可以发现，分离部署的性能瓶颈主要存在于没有数据本地性，所有的数据都要从远程存储读取。这种场景下可以尝试将 Alluxio 与 计算节点混合部署，同时将远程存储挂载在Alluxio上。热数据第一次从远程读取后，可以在本地进行备份（RAM/SSD/HDD），下一次读取将可以从 local 或者 local remote 直接读取。再配合LRU或LFU等策略，不断的将热数据置换到上层存储，冷数据则逐渐不再计算节点存储。

nodemanager / alluxio / datanode 混合部署，alluxio 每个节点分配10G内存，单副本缓存，hdfs 使用3副本。

在没有其余任务干扰的情况下，HDFS 数据本地性应是 Alluxio 的3倍左右，Alluxio 没有命中本地数据的读取速度是 HDFS 的 2.5 倍左右

对 24G parquet.snappy 数据进行单字段 filter

Alluxio 数据本地性 5%，HDFS 数据本地性 16.5%

presto 本地没有部署 Alluxio (所有数据通过网络传输)

结果 相同sql，连续执行5次

1）千万级表

tableA 1.2G (2千万)

2）亿级表

tableB 900G (45亿)

为模拟真实环境，在任务高峰期同时运行两任务，运行时可能会受其他任务影响，主要是磁盘IO和网络IO。

使用 spark-sql-perf 使用工具进行测试

结果 前11个查询耗时对比

在所有的99个查询中

在整个测试中，alluxio 使用单副本缓存，本地命中率并不高（5%），读取速度主要取决于网络IO。

HDFS 虽然有三备份，不过数据从磁盘读取时可能会受到其他任务的干扰，因此速度不太稳定。

Alluxio 的落地非常依赖场景，否则优化效果并不明显（无法发挥内存读取的优势）。

展望Alluxio 2.0，下个版本的 Alluxio 有很多重大的更新，可以持续关注。