Alluxio 部分阅读

现有的streaming architecture 的bottleneck是：

1.hdfs 存储系统位于远端的服务器：文件的输入输出会引起大量的网络延迟，数据的更改变成流处理的一个bottleneck
。
2.HDFS使用普通的磁盘，因此IO操作，尤其是读操作有很高的延迟，spark streaming的executor需要重复的跨集群读操作从HDFS，进一步降低了整体的性能。
3.当spark stremaing的 executor 用光内存并且失败，将会在另外的节点重启，但是这样就不会利用之前的checkpoint。因此某些任务可能永远不能完成。
4.当spark streaming 任务持久化数据使用 MEMORY_ONLY时，会复制数据在jvm的内存中。会引起垃圾回收，有时候会导致任务失败。
如果持久化的级别的为MEMORY_TO_DISK 或者DISK_ONLY时，磁盘的IO又成了系统的瓶颈。

问题的解决：
并没有改变之前的架构逻辑，只是在计算框架和HSDF之间部署了Alluxio，因为Alluxio可以加速数据的处理，
因此计算框架可以高效的交换数据。在架构中，只有最终的输出结果才会持久化到HDFS上。

架构的大部分和之前类似。主要的不同是由spark streaming生成和使用的大部分数据存储在Alluxio中，避免了和慢速的远端hdfs集群交互。与此同时数据存储在Alluxio中可以很方便的被其他的计算框架Flink，Zeppelin共享。
因为Alluxio具备以下的特点，所以在提升系统性能的过程中扮演了重要的角色。

    01： Alluxio的workers部署在每个计算节点上，以管理本地的内存，SSD和磁盘
    。流处理所需的数据尽可能的保存在本地，以节省带宽。与此同时，Alluxio提供多种赶出策略，以将大多数使用的
    数据保存在内存中。这极大的提高了数据的访问效率。
    02：除了spark streaming，其他组件也可以从Alluxio中读取数据，Spark Streaming和spark batch作业也可以与Alluxio