Hadoop分布式文件系统--HDFS的诞生

1.牛刀小试

张大胖找了个实习的工作， 第一天上班Bill师傅给他分了个活儿：日志分析。

张大胖拿到了师傅给的日志文件，大概有几十兆，打开一看， 每一行都长得差不多，类似这样：

212.86.142.33 – - [20/Mar/2017:10:21:41 +0800] “GET / HTTP/1.1″ 200 986 “” “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; )"

张大胖知道，这些日志都是Web服务器产生的，里边包含了像客户端IP, 访问时间， 请求的URL，请求处理的状态， referer, User Agent等信息。

师傅说，你想个办法统计一天之内每个页面的访问量(PV)，独立的IP数， 还有用户最喜欢搜索的前10个关键字。

张大胖心说这简单啊，我用Linux上的cat,awk等小工具就能做出来， 不过还是正式一点，用我最喜欢的Python写个程序吧，把每一行文本分割成一个个字段，然后分分组、计算一下不就得了。

慢着， 这样一来这个程序就只能干这些事儿，不太灵活，扩展性不太好。

要不把分割好的字段写入数据库表？

比如access_log(id,ip,timestamp,url, status,referer, user_agent)， 这样就能利用数据库的group 功能和count功能了，sql多强大啊， 想怎么处理就怎么处理。

对，就这么办！

半天以后，张大胖就把这个程序给搞定了，还画了一个架构图，展示给了师傅。

师傅一看：“不错嘛，思路很清晰，还考虑到了扩展性，可以应对以后更多的需求。”

于是这个小工具就这么用了起来。

张大胖毕业以后也顺利地加入了这家公司。

2.分布式

互联网尤其是移动互联网发展得极快，公司网站的用户量暴增，访问量也水涨船高，日志量也很感人，每小时都能产生好几个G，张大胖实习期间“引以为傲”的小程序没法再用了，数据库根本就放不下啊。

不仅数据库放不下，在Web服务器上也放不下了，更不用说去做分析了。

张大胖主动请缨，打算搞定这个问题。 当然他也很聪明地把经验丰富的师傅Bill给拉上了。

两个人来到会议室，开始了讨论。

张大胖先算了一笔账：如果是一台机器，一个硬盘，读取速度是75M/s  ，那需要花费10多天才能读取100T的内容。 但是如果是有100个硬盘， 并行的读取速度就能达到75G/s  , 几十分钟就可以把100T的数据给读出来了，多快啊。

他对Bill说道：“看来只有分布式存储才能拯救了。多来几台机器吧，把log1, log2,log3...这些文件存放在不同的机器上。”

师傅Bill说道：“你想得太简单了，分布式可不是简单地添加机器， 机器的硬盘坏了怎么办？日志文件是不是就丢失了？ 热门文件怎么办？ 访问量特别大，那对应的机器负载就特别高， 这样不公平啊！

张大胖说道：“第一个问题好办，我可以做备份啊，把每个文件都存三个备份。这样坏的可能性就大大降低了。你说的第二个问题，我们的日志哪有什么热门文件？”

“要考虑下通用性嘛！将来你这个分布式的文件系统可以处理别的东西啊。”

“好吧， 我可以被文件切成小块，让他们分散在各个机器上，这就行了吧。 备份的时候，把每个小块都备份三份就解决问题了。”

（备注：三份是最低要求）

“那问题就来了，我们该怎么使用呢？ 客户端总不能说把文件的第一块从服务器1上取出来，第二块从服务器4上取出来，第三块从服务器2上取出来.....   再说客户端保留这些‘乱七八糟’的信息该多烦人啊。”  Bill提出的问题很致命。

“这个......” 张大胖思考了半天， “看来还得做抽象啊，我的分布式文件系统得提供一个抽象层，让文件分块对客户端保持透明， 客户端根本不必知道文件是怎么分块的，分块后存放在什么服务器上。他们只需要知道一个文件的路径/logs/log1，就可以读写了，细节不用操心。”

“不错，看来你已经Get到了，一定要通过抽象给客户端提供一个简单的视图，尽可能让他们像访问本地文件一样来使用！” Bill 立刻做了升华。