HDFS、Ceph文件系统以及Hbase、Cassendra、TiDB比较

HDFS、Ceph差异对比

HDFS设计目标

• 存储非常大的文件：这里非常大指的是几百M、G、或者TB级别。实际应用中已有很多集群存储的数据达到PB级别。根据Hadoop官网，Yahoo！的Hadoop集群约有10万颗CPU，运行在4万个机器节点上。更多世界上的Hadoop集群使用情况，参考Hadoop官网.

• 采用流式的数据访问方式: HDFS基于这样的一个假设：最有效的数据处理模式是一次写入、多次读取数据集经常从数据源生成或者拷贝一次，然后在其上做很多分析工作
  分析工作经常读取其中的大部分数据，即使不是全部。 因此读取整个数据集所需时间比读取第一条记录的延时更重要。

• 运行于商业硬件上: Hadoop不需要特别贵的、reliable的机器，可运行于普通商用机器（可以从多家供应商采购） 商用机器不代表低端机器在集群中（尤其是大的集群），节点失败率是比较高的HDFS的目标是确保集群在节点失败的时候不会让用户感觉到明显的中断。

  有些场景不适合使用HDFS来存储数据。下面列举几个：

1. 低延时的数据访问
   对延时要求在毫秒级别的应用，不适合采用HDFS。HDFS是为高吞吐数据传输设计的,因此可能牺牲延时HBase更适合低延时的数据访问。

2. 大量小文件
   文件的元数据（如目录结构，文件block的节点列表，block-node mapping）保存在NameNode的内存中， 整个文件系统的文件数量会受限于NameNode的内存大小。
   经验而言，一个文件/目录/文件块一般占有150字节的元数据内存空间。如果有100万个文件，每个文件占用1个文件块，则需要大约300M的内存。因此十亿级别的文件数量在现有商用机器上难以支持。

3. 多方读写，需要任意的文件修改

   HDFS采用追加（append-only）的方式写入数据。不支持文件任意offset的修改。不支持多个写入器（writer）。

   1、小文件过多，会过多占用namenode的内存，并浪费block。

   • 文件的元数据（包括文件被分成了哪些blocks，每个block存储在哪些服务器的哪个block块上），都是存储在namenode上的。
     HDFS的每个文件、目录、数据块占用150B，因此300M内存情况下，只能存储不超过300M/150=2M个文件/目录/数据块的元数据
   • dataNode会向NameNode发送两种类型的报告：增量报告和全量报告。
     增量报告是当dataNode接收到block或者删除block时，会向nameNode报告。
     全量报告是周期性的，NN处理100万的block报告需要1s左右，这1s左右NN会被锁住，其它的请求会被阻塞。

   2、文件过小，寻道时间大于数据读写时间，这不符合HDFS的设计:

   HDFS为了使数据的传输速度和硬盘的传输速度接近，则设计将寻道时间相对最小化，将block的大小设置的比较大，这样读写数据块的时间将远大于寻道时间，接近于硬盘的传输速度。

HDFS文件目录

HDFS文件目录主要由NameNode、SecondaryNameNode和DataNode组成

HDFS(Hadoop Distributed File System)默认的存储单位是128M的数据块

NameNode的文件结构如下

NameNode文件结构包括edits、fsimage、seen_txid、VERSION

• 编辑日志（edit log）：当客户端执行写操作时，首先NameNode会在编辑日志中写下记录，并在内存中保存一个文件系统元数据，这个描述符会在编辑日志改动之后更新。

• edits_start transaction ID-end transaction ID
  finalized edit log segments，在HA（高可用）环境中，Standby Namenode只能读取finalized log segments，

• edits_inprogress__start transaction ID

  当前正在被追加的edit log，HDFS默认会为该文件提前申请1MB空间以提升性能