日志分析

比如说现在给你一个活：日志分析，一个日志大概有几十兆，而且每一行都很类似，比如

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功能了。

image.png

分布式

问题就是如今互联网发展太快，用户量访问暴增，日志量大大增加，每小时都能产生好几个G，所以数据库根本就放不下了，甚至说Web服务器也放不下了。

一台机器，一个硬盘，读取速度是75M/s，那么需要10天才能读完100T的内容。

但是如果有100个硬盘，并行读取的速度可达75G/s，几十分钟就可以把100T的数据读出来了。

所以可以使用分布式存储的方法。

image.png

但是分布式不是简单的添加机器，

• 当机器的硬盘坏了怎么办？

• 热门文件怎么办

• 如果访问量特别大，能不能分散到其他的机器上？

那么怎么解决呢：

• 为了高可靠性，我们可以做备份，把每个文件都存三个备份，这样坏的可能性就降低了。

• 日志虽然没有热门文件，但是考虑一下通用性，可以让分布式文件系统处理别的东西吧。

  我们可以把文件切分成小块，然后分散到各个机器上。备份的时候，把每个小块都备份三份即可。

  
  image.png

  这样就不会影响热门文件的读取了。

  不过既然分块了，那么客户端读取岂不是变得更麻烦呢？如果由客户端来保存每个块存放在哪一个主机上，岂不是很烦人？

  所以还可以再做抽象，分布式文件系统可以提供一个抽象层，让文件分块对客户端保持透明，客户端不需要知道文件是怎么分块的，也不需要知道分块是存放在什么样的服务器上的，他只需要知道一个文件的路径/logs/log1，然后就可以读写了，里面的细节自有分布式文件系统来处理。

image.png

这样提供一个中间层，就可以为客户端提供一个简单的视图，尽可能让他们像访问本地文件一样来使用这个分布式文件系统呢。

这种分布式文件系统存在一个问题，就是只适合在文件末尾不断的追加，如果想随机地读写，则比较麻烦。

所以这种系统最合适一次写入，多次读取的场景。

架构图

我们之前说过，客户端不可能保存数据块与服务器之间的对应关系，那么文件分成了哪些块，保存在什么样的服务器，服务器上有多大的空间，有哪些服务器等信息，都可以统称为Metadata（元数据），可以使用一个专门的服务器来存储，也就是Master节点，可以称为NameNode

image.png

那么存储数据的服务器就叫DataNode。

然后还需要再提供一个Client，它可以查询NameNode，获得文件块存放在哪些服务器上。其他的应用程序可以先访问这个客户端，然后有这个客户端来获得相应的信息。

那么如果某个DataNode挂了或者某个DataNode的磁盘空间不足，一定要通知NameNode，所以需要DataNode与NameNode维持一条心跳线，也就是和的需要为他们设计一套通信协议。

分布式系统就是这样，机器坏了，网断了，都就很大的挑战，需要在普通的机器上实现高可靠性是一件很难的事情。

接下来就是更细化的流程

读过程

要想读一个文件，最容易想到的流程是，客户端把文件名和路径告诉NameNode，然后让它返回所有的数据。但是这样存在的最大的问题是，所有的数据流都要经过NameNode，那么这个节点一定会成为瓶颈的。

如果是多个客户端并发访问，当数据量到了TB甚至PB级的时候，不堪设想。

那么可以读取文件的时候，NameNode只需要返回文件的分块以及分块所在的DataNode，这样客户端就可以选择一个DataNode来读取文件呢。

但是一个分块会存三份，那么选哪一份呢？

当然是选择最近的呢？那么怎么定义距离呢？

• 客户端与DataNode是一个机器，距离为0

• 客户端与DataNode是同一个机架的不同机器，距离为2

• 客户端与DataNode是同一个数据中心的不同机架，距离为4 。

所以程序难度提高了好几个数量级

image.png

写入文件

写入文件的流程也类似，NameNode会找到可以写数据的三个DataNode，然后把信息返回给客户端，由客户端向这三个DataNode发起写操作。

不过，如果有10G的文件，难道让客户端向DataNode写3次吗？当然不，可以把三个DataNode组成一个PipeLine，数据只需要发给第一个DataNode，然后它会自动备份给第二个节点，然后是第三个节点。

image.png

所以说客户端其实只发出了一次写请求，然后后端的数据复制由DataNode合作完成。

这个分布式文件系统就叫Hadoop Distributed File System，HDFS，这样就可以使用廉价的X86服务器存储海量日志。

那么我们当然可以写个程序来读取这些文件，统计各种各样的用户访问呢？但是这些程序需要放在哪里呢？如果是只是放到HDFS之外的某台机器上处理，面对100T的数据，处理得非常慢，所以可以把计算架构也做成分布式的，并且让计算程序尽可能的靠近数据，这样就快多了。这就是MapReduce