这是个极为宏大的分布式存储与计算话题，本文先简单介绍它们之间的作用和架构关系。后续有机会再慢慢细聊：
技术介绍
首先这四种技术分别代表：分布式文件系统（HDFS）、实时数据库（Druid）、大数据查询引擎（Presto）和内存中的分布式文件系统（Alluxio）。
HDFS是我们最常听到的分布式文件系统，也就是说它主要还是以文件的组织形式保存客户端传来的数据，关键是在多节点多副本的条件下提供文件的高可靠。
Druid是结合了数仓、时序和日志搜索为一体的实时分析数据库。Druid是列式结构存储，主要是针对日志、工业和实时交易之类的海量数据写入和实时分析。它的分布式结构非常庞大，面向实时流数据、也面向批量冷数据的定时存储，为各种实时、离线提供全面的支撑。
Presto是大数据的查询引擎，具有分布式结构，我们可以让它与hive，impala，spark sql并列去对比，都是面向mpp的大规模并行计算引擎，presto的强大之处还是在于它的查询速度很高，在计算过程中，因为对内存的极致利用，使得查询速度是其最大的优势。
Alluxio是基于内存的分布式文件系统，也是以文件组织形式提供给客户端，它可以介于spark和hdfs之间(不止于这两种大数据框架)形成内存映射磁盘的分布式文件缓冲架构，既可以同hdfs形成内存与磁盘的文件数据交换，又可以适配spark建立内存级的checkpoint点，做到分布式环境下在内存中完成检测点的计算恢复，用于加速spark等查询计算引擎的处理能力，还能提供计算容错的支持，相对于在线事务领域，我们可以理解Alluxio为大数据领域的Redis，但Redis只是字典，不具备文件组织能力，也不具备数据在内存与磁盘的实时交换能力。
架构用法
介绍完它们的作用，我们从架构的用法上看，hdfs肯定是大数据的底座，用于全量数据的高可靠存储，尤其是高性能的写入与复制，如果用spark进行批量分析，例如数据挖掘，机器学习，那么在hdfs之上加一层Alluxio，这会让spark通过Alluxio来缓存数据，并无缝建立与hdfs的桥梁，处理速度效果会非常好。
如果使用presto，则不需要考虑Alluxio，因为presto本身就是数据与计算分离的架构，也是纯内存计算的架构，他可以和很多数据存储平台对接，如果做通用型大数据离线分析，对接hdfs即可，如果做工业时序查询分析，也可以对接Druid。
作为Druid，它本身既是一个时序数据的存储平台，也是一个实时查询分析的计算平台，而且它还可以连接hdfs批量获取数据，也可以连接kafka流式获取数据，但最终都会归集到它的历史数据库，在进入历史数据库之前，它还可以外接hdfs作为批量冷数据的临时中转地，等待协调节点的调度后，再将hdfs上的冷数据转移到历史数据中。总之Druid是面向时序、数仓的全套解决方案，架构也非常开放。
但是作为一般的大数据技术实施公司，切莫追逐于技术上的先进性，满足SLA服务承诺的条件下，稳定性更重要，数据量大的环境下，各种技术框架里面都会产生很多坑，例如presto虽然内存应用到极致，但是海量数据频繁操作下，jvm对内存的垃圾回收会有很多意想不到的问题。
再比如Druid，分布式架构非常复杂，可以和TiDB、OceanBase的分布式架构角色之多有一拼了，那么对于Druid的部署就涉及到实时节点，历史节点，协调节点，查询节点，还有zookeeper，hdfs的接入，任何角色节点出现故障都是麻烦事，那么你是否能应付的过来呢？
因此一定要循序渐进的使用大数据技术，例如：hdfs和spark sql是否就已经可以解决问题了，是否一定因为速度需求要换成presto；再比如，es栈(elk)就能解决日志问题，influxdb栈(tick)就能解决工业监测问题，是否对数据业务的功能需求的复杂程度一定要将所有采集和分析统一融合到Druid上呢？这都是架构上需要慎之又慎的事情。
