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空间以提升性能

• fsimage是文件系统元数据的持久检查点

• Seen_txid存放transactionId

DataNode的文件结构主要由blk_前缀文件、BP-random integer-NameNode-IP Addr-creation time和VERSION组成

• BP-random integer-NameNode-IP Addr-creation time：

  BP代表BlockPool，即唯一的blockpoolID

• Finalized/rbm

  这两个目录都用用于实际存储HDFS BLOCK的数据，里面包含许多的block_xx文件以及相应的元数据文件，rbm用于存储用户当前正在写入的数据

• blk_前缀文件

  存储原始文件内容

当目录中存储的块数据量增加到一定规模时，DataNode会创建一个新的目录，用于保存新的块及元数据。当目录中的块数据量达到64（可由dfs.DataNode.numblocks属性确定）时，便会新建一个子目录，这样就会形成一个更宽的文件树结构，避免了由于存储大量数据块而导致目录很深，使检索性能免受影响。通过这样的措施，数据节点可以确保每个目录中的文件块都可控的，也避免了一个目录中存在过多文件。

Ceph设计目标

• 优势在于易拓展、无单点
• 缺点是执行计算任务时性能低于HDFS，大概慢30%

Ceph数据结构

RADOS主要由两种节点组成：一种是为数众多的、负责完成数据存储和维护功能的OSD，另一种是若干个负责完成系统状态检测和维护的monitor

Ceph RBD ：Ceph里的块设备

Ceph OSD 在扁平的命名空间内把所有数据存储为对象（也就是没有目录层次）。对象包含一个标识符、二进制数据、和由名字/值对组成的元数据，元数据语义完全取决于 Ceph 客户端。例如， CephFS 用元数据存储文件属性，如文件所有者、创建日期、最后修改日期等等。

HDFS文件导出

• 关系型数据库使用sqoop
• NoSQL特别是HBase自带Export类
• 导入数据仓库Hive直接可以用SQL语句完成

Ceph文件导出

暂时没找到

暂时的结论

1. Hadoop及HDFS，其设计的初衷是批处理，大量数据的Map-Reduce。而实时计算，并不擅长，要考虑Storm之类流式计算矿建。

2. HDFS适合存储大问题，ChunkSize通常64M，非常不适合小文件，比如我们几M大小的图片。

3. Ceph的对象存储，减少了很多在文件系统下储存小文件的i-node开销。

4. Ceph似乎是完全去中心化的。而HDFS要设置NameNode，通过master-slave的方式来备份容灾。

5. Ceph在基于Hadoop的情况下速度比较慢，且运维成本偏高

6. HDFS生态链相对好

其它FS选型

TFS：腾讯淘宝文件系统，淘宝内部应用海量的图片小文件放到tfs上。比较符合当前的业务场景，但是社区不活跃，相关资料很少。实际用的时候如果遇到bug可能很棘手。

其它思路

• 进行小文件的合并然后存在HDFS(麻烦，但是可以根据业务尝试，可以利用Hbase实现HDFS小文件的合并)

总结

从开发的便捷性和生态链考虑还是选择HDFS最好，Ceph不是很好用。后续可以从小文件的合并着手来优化存储

疑问：Cassendra，Hbase之类也可以存文件，为什么要上HDFS，这一块没什么经验，可能还需要讨论一下

Hbase、Cassendra、TiDB适用场景以及相关生态

Hbase

基本简介

HBase 是一个开源的 非关系型分布式数据库（NoSQL），它参考了 谷歌 的 BigTable 建模，实现的编程语言为 Java。它是 Apache 软件基金会的 Hadoop 项目的一部分，运行于 HDFS 文件系统之上，为 Hadoop 提供类似于 BigTable 规模的服务。因此，它可以 容错地 存储 海量稀疏 的数据。

特性

• 大：一个表可以有数十亿行，上百万列；
• 无模式：每行都有一个可排序的主键和任意多的列，列可以根据需要动态的增加，同一张表中不同的行可以有截然不同的列；
• 面向列：面向列（族）的存储和权限控制，列（族）独立检索；
• 稀疏：空（null）列并不占用存储空间，表可以设计的非常稀疏；
• 数据多版本：每个单元中的数据可以有多个版本，默认情况下版本号自动分配，是单元格插入时的时间戳；
• 数据类型单一：Hbase中的数据都是字符串，没有类型。

优势

• Hbase作为一个NoSQL，在性能上不如Memcached和Redis，但是强在持久化存储

• Hbase是在Hadoop生态链中与HDFS、MR、Spark结合最好的

• 数据强一致，数据零丢失

缺点

• 太依赖Hadoop和HDFS
• 高并发读写效率相对低

Cassendra

基本简介

Apache Cassandra是一套开源分布式NoSQL数据库系统。它最初由Facebook开发，用于储存收件箱等简单格式数据，集Google BigTable的数据模型与Amazon Dynamo的完全分布式的架构于一身。Facebook于2008将 Cassandra 开源，此后，由于Cassandra良好的可扩放性，被Digg、Twitter等知名Web 2.0网站所采纳，成为了一种流行的分布式结构化数据存储方案。

它是一个开源的、分布式、无中心、支持水平扩展、高可用的KEY-VALUE类型的NOSQL数据库。

重要特性

1. 分布式和去中心化

   Cassandra 是分布式的，这意味着它可以运行在多台机器上，并呈现给用户一个一致的整体。它的很多设计和实现让系统不仅可以在多个节点上运行，更为多机架部署进行了优化，甚至一个 Cassandra 集群可以运行在分散于世界各地的数据中心上。将数据写到集群的任意一台机器上，Cassandra 都会收到数据。

   对于很多存储系统（比如 MySQL, Bigtable），一旦你开始扩展它，就需要把某些节点设为主节点，其他则作为从节点。但 Cassandra 是无中心的，也就是说每个节点都是一样的。与主从结构相反，Cassandra 的协议是 P2P 的，并使用 gossip 来维护存活或死亡节点的列表。

   去中心化这一事实意味着 Cassandra 不会存在单点失效。Cassandra 集群中的所有节点的功能都完全一样， 所以不存在一个特殊的主机作为主节点来承担协调任务。有时这被叫做服务器对称（server symmetry）。

   综上所述，Cassandra 是分布式、无中心的，它不会有单点失效，所以支持高可用性。

2. 弹性可拓展

   可扩展性是指系统架构可以让系统提供更多的服务而不降低使用性能的特性。仅仅通过给现有的机器增加硬件的容量、内存进行垂直扩展，是最简单的达到可扩展性的手段。而水平扩展则需要增加更多机器，每台机器提供全部或部分数据，这样所有主机都不必负担全部业务请求。但软件自己需要有内部机制来保证集群中节点间的数据同步。

   弹性可扩展是指水平扩展的特性，意即你的集群可以不间断的情况下，方便扩展或缩减服务的规模。这样，你就不需要重新启动进程，不必修改应用的查询，也无需自己手工重新均衡数据分布。在 Cassandra 里，你只要加入新的计算机，Cassandra 就会自动地发现它并让它开始工作。

3. 高可用和容错

   从一般架构的角度来看，系统的可用性是由满足请求的能力来量度的。但计算机可能会有各种各样的故障，从硬件器件故障到网络中断都有可能。如何计算机都可能发生这些情况，所以它们一般都有硬件冗余，并在发生故障事件的情况下会自动响应并进行热切换。对一个需要高可用的系统，它必须由多台联网的计算机构成，并且运行于其上的软件也必须能够在集群条件下工作，有设备能够识别节点故障，并将发生故障的中端的功能在剩余系统上进行恢复。

   Cassandra 就是高可用的。你可以在不中断系统的情况下替换故障节点，还可以把数据分布到多个数据中心里，从而提供更好的本地访问性能，并且在某一数据中心发生火灾、洪水等不可抗灾难的时候防止系统彻底瘫痪。

4. 可调节的一致性

   Cassandra 的应用场景更多的是为了满足可用性，Cassandra 提供了可调节的一致性，允许我们选定需要的一致性水平与可用性水平，在二者间找到平衡点。因为客户端可以控制在更新到达多少个副本之前，必须阻塞系统。这是通过设置副本因子（replication factor）来调节与之相对的一致性级别。

   通过副本因子（replication factor），你可以决定准备牺牲多少性能来换取一致性。 副本因子是你要求更新在集群中传播到的节点数（注意，更新包括所有增加、删除和更新操作）。

   客户端每次操作还必须设置一个一致性级别（consistency level）参数，这个参数决定了多少个副本写入成功才可以认定写操作是成功的，或者读取过程中读到多少个副本正确就可以认定是读成功的。这里 Cassandra 把决定一致性程度的权利留给了客户自己。

   所以，如果需要的话，你可以设定一致性级别和副本因子相等，从而达到一个较高的一致性水平，不过这样就必须付出同步阻塞操作的代价，只有所有节点都被更新完成才能成功返回一次更新。而实际上，Cassandra 一般都不会这么来用，原因显而易见（这样就丧失了可用性目标，影响性能，而且这不是你选择 Cassandra 的初衷）。而如果一个客户端设置一致性级别低于副本因子的话，即使有节点宕机了，仍然可以写成功。

   总体来说，Cassandra 更倾向于 CP

5. 面向行

   Cassandra 经常被看做是一种面向列（Column-Oriented）的数据库，这也并不算错。它的数据结构不是关系型的，而是一个多维稀疏哈希表。稀疏（Sparse）意味着任何一行都可能会有一列或者几列，但每行都不一定（像关系模型那样）和其他行有一样的列。每行都有一个唯一的键值，用于进行数据访问。所以，更确切地说，应该把 Cassandra 看做是一个有索引的、面向行的存储系统。

   Cassandra 的数据存储结构基本可以看做是一个多维哈希表。这意味着你不必事先精确地决定你的具体数据结构或是你的记录应该包含哪些具体字段。这特别适合处于草创阶段，还在不断增加或修改服务特性的应用。而且也特别适合应用在敏捷开发项目中，不必进行长达数月的预先分析。对于使用 Cassandra 的应用，如果业务发生变化了，只需要在运行中增加或删除某些字段就行了，不会造成服务中断。

6. 高性能

   Cassandra 在设计之初就特别考虑了要充分利用多处理器和多核计算机的性能，并考虑在分布于多个数据中心的大量这类服务器上运行。它可以一致而且无缝地扩展到数百台机器，存储数 TB 的数据。Cassandra 已经显示出了高负载下的良好表现，在一个非常普通的工作站上，Cassandra 也可以提供非常高的写吞吐量。而如果你增加更多的服务器，你还可以继续保持 Cassandra 所有的特性而无需牺牲性能。

优势

1. 容错能力强，去中心化以及P2P，不会出现单点故障
2. 性能好,可用性高，扩展性好
3. 相比Hbase，基于一致性hash，数据定位很快
4. 部署更简单，只有一种角色

劣势

1. 弱一致性，数据可能丢失
2. 配置困难，开发成本高
3. Scan效率低
4. 热数据负载不够均衡

TiDB

基本简介

特性

• 大数据量下MySQL复杂查询（兼容MySQL），大数据量下时延相对更小
• 水平扩展，不用分库分表，业务侵入性较小
• 高并发实时写入、实时查询、实时统计分析
• 使用 TiSpark 兼容OLAP场景
• 批量写入与读取效率高
• 不适合存储超宽表（单行数据不超过64k），若列过多建议分表存储
• 多线程GC

使用场景

• MySQL分片分表
• 直接替代MySQL
• 数据仓库
• OLTP + OLAP场景
• TiKV可以单独作为一个 HBase 的 Replacement 来用

生态

• TiDB
• TiKV
• TiSpark
• TiDB-Ansible: 自动部署（支持裸机及云部署）
• TiDB-docker-compose: docker部署方案
  • 安全地扩展TiDB集群
  • 滚动更新TiDB群集
  • 多租户支持: 用户可以轻松地在单个Kubernetes集群上部署和管理多个TiDB集群
  • 自动故障转移
• TiDB-operator:
• Syncer: MySQL 到 TiDB 间的实时同步工具
• Binlog: 收集TiDB二进制日志
  • 数据复制: 将数据从TiDB群集同步到异构数据库。
  • 实时备份(可增量备份)和恢复
  • 多种输出格式:支持MySQL，转储文件等
  • 历史重播
• Lightning: 大量数据快速导入 TiDB 工具
• TiDB Vision: 数据可视化
• Prometheus: TiDB 后台监控

已存在HDFS中的解析成结果数据

[外链图片转存失败(img-G8MK7WUx-1569488877340)(sql_hadoop.png)]

在处理来自 Hadoop 的原始的、经过处理的数据时，需要获得 Hadoop 作业的文件输出。与导出时一样，应该确保您的 Hadoop 作业以您可以有效读回的格式输出信息。

导入到 SQL

使用 CSV 既简单又直观，但对于更复杂的结构，也可以考虑使用 JSON 格式，因为它使整个转换和翻译过程变得非常容易。

要获取该信息，需要使用 HDFS 工具将输出文件放回您可以执行加载的文件系统中 — 例如 $ hdfs dfs -copyToLocal processed_logs/*。拥有这些文件后，就可以使用适合来源信息和结构的方法来加载信息。

从 Sqoop 中导出

与导入过程一样，Sqoop 提供了一种将信息从 Hadoop 作业转换回 SQL 表的简化方法。

从 Sqoop 中输出结果信息时，对于最简单的导出，可以采用 CSV 格式。然后，要导入该信息，需要创建一个合适的表来接受经过处理的日志。例如，从我们的访问日志可以看出，Hadoop 输出已将该数据映射到操作次数摘要中，所以必须先创建一个合适的表：CREATE TABLE summary_logs (operation CHAR(80), count int)。然后，可以直接将信息从 Hadoop 导入到您的 SQL 表中

在我的博客查看更多
作者：槐洛文

转载：https://blog.csdn.net/Lj_550566181/article/details/101454645