日志分析
比如说现在给你一个活：日志分析，一个日志大概有几十兆，而且每一行都很类似，比如
212.86.142.33 – - [20/Mar/2017:10:21:41 +0800] “GET / HTTP/1.1″ 200 986 “http://www.baidu.com/” “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; )"
可以看出这些日志是从Web服务器里面产生的，包含了
客户端IP
访问时间
请求的URL
返回的状态
referer
User Agent
现在我们需要统计，一天之内
每个页面的访问量（PV）
独立的IP数
用户最喜欢搜索的前10个关键字
最简单的就是使用cat , awk等小工具来做，或者使用python，方式是把每一行文本分割为一个一个的字段，然后分组，计算。
那么存在什么样的问题呢？一个程序就只能干这样一种事情，不灵活，扩展性不好。
那么可不可以把分割好的字段写入数据库表呢？比如access_log(id,ip,timestamp,url,status,referer,user_agent)这样的数据库，然后就可以使用数据库的group功能和count功能了。
分布式
问题就是如今互联网发展太快，用户量访问暴增，日志量大大增加，每小时都能产生好几个G，所以数据库根本就放不下了，甚至说Web服务器也放不下了。
一台机器，一个硬盘，读取速度是75M/s，那么需要10天才能读完100T的内容。
但是如果有100个硬盘，并行读取的速度可达75G/s，几十分钟就可以把100T的数据读出来了。
所以可以使用分布式存储的方法。
但是分布式不是简单的添加机器，
当机器的硬盘坏了怎么办？
热门文件怎么办
如果访问量特别大，能不能分散到其他的机器上？
那么怎么解决呢：
为了高可靠性，我们可以做备份，把每个文件都存三个备份，这样坏的可能性就降低了。
-
日志虽然没有热门文件，但是考虑一下通用性，可以让分布式文件系统处理别的东西吧。
我们可以把文件切分成小块，然后分散到各个机器上。备份的时候，把每个小块都备份三份即可。
image.png这样就不会影响热门文件的读取了。
不过既然分块了，那么客户端读取岂不是变得更麻烦呢？如果由客户端来保存每个块存放在哪一个主机上，岂不是很烦人？
所以还可以再做抽象，分布式文件系统可以提供一个抽象层，让文件分块对客户端保持透明，客户端不需要知道文件是怎么分块的，也不需要知道分块是存放在什么样的服务器上的，他只需要知道一个文件的路径/logs/log1，然后就可以读写了，里面的细节自有分布式文件系统来处理。
这样提供一个中间层，就可以为客户端提供一个简单的视图，尽可能让他们像访问本地文件一样来使用这个分布式文件系统呢。
这种分布式文件系统存在一个问题，就是只适合在文件末尾不断的追加，如果想随机地读写，则比较麻烦。
所以这种系统最合适一次写入，多次读取的场景。
架构图
我们之前说过，客户端不可能保存数据块与服务器之间的对应关系，那么文件分成了哪些块，保存在什么样的服务器，服务器上有多大的空间，有哪些服务器等信息，都可以统称为Metadata（元数据），可以使用一个专门的服务器来存储，也就是Master节点，可以称为NameNode
那么存储数据的服务器就叫DataNode。
然后还需要再提供一个Client，它可以查询NameNode，获得文件块存放在哪些服务器上。其他的应用程序可以先访问这个客户端，然后有这个客户端来获得相应的信息。
那么如果某个DataNode挂了或者某个DataNode的磁盘空间不足，一定要通知NameNode，所以需要DataNode与NameNode维持一条心跳线，也就是和的需要为他们设计一套通信协议。
分布式系统就是这样，机器坏了，网断了，都就很大的挑战，需要在普通的机器上实现高可靠性是一件很难的事情。
接下来就是更细化的流程
读过程
要想读一个文件，最容易想到的流程是，客户端把文件名和路径告诉NameNode，然后让它返回所有的数据。但是这样存在的最大的问题是，所有的数据流都要经过NameNode，那么这个节点一定会成为瓶颈的。
如果是多个客户端并发访问，当数据量到了TB甚至PB级的时候，不堪设想。
那么可以读取文件的时候，NameNode只需要返回文件的分块以及分块所在的DataNode，这样客户端就可以选择一个DataNode来读取文件呢。
但是一个分块会存三份，那么选哪一份呢？
当然是选择最近的呢？那么怎么定义距离呢？
客户端与DataNode是一个机器，距离为0
客户端与DataNode是同一个机架的不同机器，距离为2
客户端与DataNode是同一个数据中心的不同机架，距离为4 。
所以程序难度提高了好几个数量级
写入文件
写入文件的流程也类似，NameNode会找到可以写数据的三个DataNode，然后把信息返回给客户端，由客户端向这三个DataNode发起写操作。
不过，如果有10G的文件，难道让客户端向DataNode写3次吗？当然不，可以把三个DataNode组成一个PipeLine，数据只需要发给第一个DataNode，然后它会自动备份给第二个节点，然后是第三个节点。
所以说客户端其实只发出了一次写请求，然后后端的数据复制由DataNode合作完成。
这个分布式文件系统就叫Hadoop Distributed File System，HDFS，这样就可以使用廉价的X86服务器存储海量日志。
那么我们当然可以写个程序来读取这些文件，统计各种各样的用户访问呢？但是这些程序需要放在哪里呢？如果是只是放到HDFS之外的某台机器上处理，面对100T的数据，处理得非常慢，所以可以把计算架构也做成分布式的，并且让计算程序尽可能的靠近数据，这样就快多了。这就是MapReduce
