hdfs
架构设计
HDFS按照Master和Slave的结构。分NameNode、SecondaryNameNode、DataNode这几个角色。
NameNode：是Master节点，是管理者。1、管理数据块映射；2、处理客户端的读写请求；3、配置副本策略；4、管理HDFS的名称空间；
NameNode保存的metadata包括文件ownership和permission , 文件包含的block信息 , Block保存在那些DataNode节点上（这部分数据并非保存在NameNode磁盘上的，它是在DataNode启动时上报给NameNode的，
Name接收到之后将这些信息保存在内存中）, NameNode的metadata信息在NameNode启动后加载到内存中 , Metadata存储到磁盘上的文件名称为fsimage , Block的位置信息不会保存在fsimage中 , Edits文件记录
了客户端操作fsimage的日志，对文件的增删改等。用户对fsimage的操作不会直接更新到fsimage中去，而是记录在edits中
SecondaryNameNode：分担namenode的工作量；是NameNode的冷备份；合并fsimage和fsedits然后再发给namenode。
部署方式和使用方法
Hdfs https://blog.csdn.net/qq_41946557/article/details/102753444
应用场景
1） HDFS不适合大量小文件的存储
2） HDFS适用于高吞吐量，而不适合低时间延迟的访问
3）流式读取的方式，不适合多用户写入一个文件
5）HDFS更加适合写入一次，读取多次的应用场景
tfs
架构设计
一个TFS集群由两个NameServer节点（一主一备）和多个DataServer节点组成。以block（通常为64M，可配置）为单位存储和组织数据。这些服务程序都是作为一个用户级的程序运行在普通Linux机器上的。
NameServer主要管理维护Block和DataServer相关信息,包括DataServer加入，退出, 心跳信息, block和DataServer的对应关系建立，解除。正常情况下，一个块会在DataServer上存在， 主NameServer
负责Block的创建，删除，复制，均衡，整理， NameServer不负责实际数据的读写，实际数据的读写由DataServer完成。
DataServer主要负责实际数据的存储和读写。
TFS会将多个小文件存储在同一个block中，并为block建立索引，以便快速在block中定位文件；每个block会存储多个副本到不同的机架上，以保证数据的高可靠性。
部署方式和使用方法
TFS https://blog.csdn.net/qq_41946557/article/details/102753394
应用场景
TFS为淘宝提供海量小文件存储，通常文件大小不超过1M，满足了淘宝对小文件存储的需求，被广泛地应用在淘宝各项应用中。主要针对海量的非结构化数据，构筑在普通的Linux机器集群上，可为外部提供高可靠和高并发的存储访问。
fastdfs
架构设计
在FastDFS有三种角色，第一种是Client客户端，第二种是Tracker追踪服务器，第三种就是Storage存储服务器。其中Client客户端就是官方提供的C、Java和PHP的调用API，这里后面会讲到。而对于追踪服务器和存储服务器我们这里详细介绍一下。
关于存储服务器，是采用分组的方式，同一个组内的服务器的文件是完全相同的(利用同步线程进行同步)，组和组之间是不通信的。而存储服务器会主动定期向追踪服务器报告目前的状态，追踪服务器可以有多个，多个之间是对等的，不存在主从。
关于客户端，是不需要存储有关存储服务器的任何信息的。一般用户的请求不是直接请求存储服务器，而是会请求追踪服务器。例如一个客户端需要上传文件，此时追踪服务器就会从存储服务器中找出一个组分配给客户端，供其上传文件，此时客
户端拿到组的信息后，开始直接和存储服务器的这个组进行交互，无需再通过追踪服务器进行中转。
即：
Tracker Servre：追踪服务器，主要做调度工作，在访问中起负载均衡的作用。在内存中记录集群中group和storage server的状态信息，是连接Client和Storage的枢纽。因为相关信息全部在内存中，Tracker server的性能非常高，一个比较
大的集群(比如上百个group)中有三台就足够了。
Storage Server：存储服务器，文件和文件属性(meta data)都保存在存储服务器上。
部署方式和使用方法
fastdfs https://blog.csdn.net/qq_41946557/article/details/102753972
应用场景
FastDFS适合的存储范围为4KB至500M之间，它更倾向于存储中小型文件，如图片网站、短视频网站、文档、app下载站等。
FastDFS的用户有支付宝、京东、赶集网、58同城、UC、51CTO和一些网盘公司，可以说目前用到FastDFS的公司特别多，因为移动互联网的兴起，一些短视频、电子书、小音频和一些app，都在十几兆或者一两百兆左右，使用FastDFS十分合适。
tachyon
架构设计
Tachyon的架构是传统的Master—Slave架构，这里和Hadoop（Hadoop也是master-slave结构，Hadoop主要有两个结构NameNode和DateNode），Tachyon有三个主要的部件：
Master， Client，与Worker。在每个Spark Worker节点上，都部署了一个Tachyon Worker，Spark Worker通过Tachyon Client访问Tachyon进行数据读写。所有的
Tachyon Worker都被Tachyon Master所管理，Tachyon Master通过Tachyon Worker定时发出的心跳来判断spark worker是否已经崩溃以及每个spark worker剩余的内存空间量
部署方式和使用方法
tachyon https://blog.csdn.net/qq_41946557/article/details/102754415
应用场景
由于其解决分布式内存计算的分布式数据存储所产生的的问题。所以应用场景基于Spark进行大多数批处理工作。
目前，很多公司（如Pivotal、EMC、红帽等）已经在使用Tachyon，并且来自20个组织或公司（如雅虎、英特、红帽等）的60多个贡献者都在为其贡献代码。Tachyon是于UC Berkeley数据分析栈(BDAS)的存储层，它还是Fedora操作系统自带应用。