数据产品经理有必要了解的HDFS

       本文是Hadoop组件之HDFS的学习总结性文章。因本人非技术出身，所学均来源于网络，难免有不严谨甚至错误之处，恳请大家指正。

       我们接着上一篇文章来讲，假设A公司最起初是用Excel来存放数据的，随着业务发展发现业务数据使用Excel存不下了（百万行），则过渡于使用数据库进行存储，而数据库的数据其实是存储在硬盘上的。
       就拿我们日常使用的电脑来举例，假设其有D（512G）、E（512G）、F（512G）三个硬盘。我们在上面装了一个数据库系统（比如：Mysql，关系型数据库的一种），然后指定它存放数据的地方为D盘。A公司的所有业务数据都会存在D盘中，随着数据不断增加，D盘的512G空间快不能满足需求时，一般有2种方案来解决，一是：增加D盘的存储空间，比如升级到1T（这种叫垂直扩展）。 二是：把业务数据分成不同部分，分别存储至D、E、F盘中（这种叫水平扩展）。在实际的情况中最后一般都是使用第二种方案，因为电脑硬件达到一定性能后，再升级成本会非常大，带来的边际效益会越来越小，最后可能为负。
       上面的说法只是为了方便技术功底不深的朋友理解，但其实是不严谨的。在我的认知水平中，实际的情况是企业会使用单独的服务器（可以理解为企业使用的专业主机）作为数据库，且使用的是linux系统，不分 C、D、E、F盘。所以当这个服务器的存储空间使用完毕后，要么升级服务器的存储空间，要么是增加一台新的服务器同时作为数据库。所以可以简单的理解这种多个独立的服务器共同存储数据的机制叫做分布式存储。

       以上并没有直接讲到HDFS，但是其中提到的扩容思想与HDFS思想类似，在此基础上更有助于我们来理解HDFS。顺便说一下上文提到的关系型数据库与HDFS的区别，关系型数据库存储的是关系型数据（常见的有MySQL、Oracle、DB2、PostgreSQL等），可以快速的执行增删改查（所以上面的例子说的是业务数据——需要经常的增删改查）。而HDFS是分布式文件系统，是一种通用型的数据存储系统，可以存储各种类型的数据，比如用户行为数据，图片，视频等等。

什么是HDFS？

       前面讲到，随着数据量越来越大，在一台服务器上已经无法存储所有的数据了，那我们会将这些数据分配到不同的服务器进行存储，但是这就带来一个问题：不方便管理和维护，所以就出现了分布式文件系统来统一管理这些分布在不同服务器的数据。
       而HDFS（Hadoop Distributed File System）就是Hadoop框架下的一种分布式文件系统，为整个Hadoop分布式体系提供底层文件存储。通过HDFS，我们不必去管文件到底被分片存储在多少服务器上，就像是使用一台服务器存储数据文件一样便捷，大大的减少了日常的工作量。能达到这种效果是因为那些大佬把整个逻辑做了底层封装，就像我们的产品在调用微信/支付宝的支付接口一样，我们不必去实现背后复杂的逻辑，只需要调用即可。

HDFS是如何工作的呢？

       现在A公司使用到了Hadoop框架来处理大数据相关的需求。假设A公司每天产生2个G的用户行为数据需要存储至HDFS中，那么整个流程如下图：

数据文件存储至HDFS

       一个2GB的文件发给HDFS客户端，HDFS会按照每一份文件分片大小为128M对这个文件进行切分(单个分片文件大小可设置，本文采用默认值128MB)。所以会切分为16个文件(专业称呼为block)，然后每个服务器都会存储这些切分后的文件，现在我们假设每个服务器都存储4个。
       这些存放真实数据的服务器，叫做DataNode。在这个过程中，如果有心的朋友肯定会想到一个问题，那么就是HDFS会存储很多很多文件，并且每个文件都会被切分很多片后再存储至不同的服务器上，那到时候需要使用这些数据的时候，如何快速定位数据文件所在的位置呢？
       所以这个时候就需要有一个指挥官NameNode，来掌控全局。NameNode就是负责管理文件的各种信息。主要是维护一个目录树来记录这些Block信息的。主要包括：文件路径名，每个Block的ID和存放的位置等等。所以，无论是读还是写，HDFS客户端都会先向NameNode请示。如果是写操作，HDFS切分完文件以后，会询问NameNode应该将这些切分好的block往哪几台DataNode上写。如果是读操作，HDFS拿到文件名，也会去询问NameNode应该往哪几台DataNode上去读这个文件的数据。

额外补充一个Block块大小设置规则
在实际应用中，hdfs block块的大小设置为多少合适呢？为什么有的是64M，有的是128M、256M、512呢？
首先我们先来了解几个概念：
1）寻址时间：HDFS中找到目标文件block块所花费的时间。
2）原理：文件块越大，寻址时间越短，但磁盘传输时间越长；文件块越小，寻址时间越长，但磁盘传输时间越短。
Block不能设置过大，也不要能设置过小
1）如果块设置过大，一方面从磁盘传输数据的时间会明显大于寻址时间，导致程序在处理这块数据时，变得非常慢；另一方面，MapReduce中的map任务通常一次只处理一个块中的数据，如果块过大运行速度也会很慢。
2）如果设置过小，一方面存放大量小文件会占用NameNode中大量内存来存储元数据，而NameNode的内存是有限的，不可取；另一方面块过小，寻址时间增长，导致程序一直在找block的开始位置。因此，块适当设置大一些，减少寻址时间，那么传输一个有多个块组成的文件的时间主要取决于磁盘的传输速度。
多大合适呢？
1）HDFS中平均寻址时间大概为10ms；
2）经过前任的大量测试发现，寻址时间为传输时间的1%时，为最佳状态，所以最佳传输时间为：10ms/0.01=1000ms=1s
3）目前磁盘的传输速度普遍为100MB/s，最佳block大小计算：100MB/s*1s=100MB。所以我们设置block大小为128MB。
4）实际中，磁盘传输速率为200MB/s时，一般设定block大小为256MB;磁盘传输速率为400MB/s时，一般设定block大小为512MB。

       到这里我们其实已经大致了解了HDFS的工作原理，但是呢他作为文件存储系统，并且能被各公司使用，在数据安全这方面肯定是需要得到保障的。我们来想一下，一个数据文件被分成了很多片存储在多台服务器上，如果其中的一台服务器突然坏了，数据不就丢失了嘛，所以HDFS和数据库一样都需要有容灾手段（凡是涉及到数据的东西，大家都可以简单粗暴的认为他们都会有备份的机制，比如消息中间件Kafka会有数据备份的机制、数据库会有主从备份等）。因此为了容错，Block都会有副本(可以简单理解一模一样的文件)，每个文件的Block大副本数与其大小一样都是可配置的。
下面使用一个图片来示意下HDFS的备份机制：（假设设置副本数为3）

HDFS备份机制

假设第一个备份先传到DataNode A，那么第二个备份是从DataNode A上以流的形式传输到DataNode B，第三个备份是从DataNode B以流的形式传输到DataNode C上面的。即这里的备份并不需要HDFS客户端去写，只要DataNode之间互相传递数据就好了。

       好了！关于HDFS的就大致讲这么多，很多细节性的东西，比如HDFS客户端读写数据的具体流程和步骤我觉得作为产品无需过多了解，当然，如果有兴趣的朋友欢迎来一起探讨学习。下一篇文章我打算写点关于MapReduce的内容。

传送门
Hadoop系列文章（一）数据产品经理有必要了解的Hadoop
Hadoop系列文章（三）数据产品经理有必要了解的MapReduce
Hadoop系列文章（四）数据产品经理有必要了解的YARN