基于Flume设计实现分层日志收集系统有什么好处?【大数据技术】

基于Flume设计实现分层日志收集系统，到底有什么好处呢?我们可以先看一下，如果不分层，会带来哪些问题：

如果需要通过Kafka去缓冲上游基于Flume收集而构建的日志流，对于数据平台内部服务器产生的数据还好，但是如果日志数据是跨业务组，甚至是跨部门，那么就需要将Kafka相关信息暴露给外部，这样对Kafka的访问便不是数据平台内部可控的。

如果是外部日志进入平台内部HDFS，这样如果需要对Hadoop系统进行升级或例行维护，这种直连的方式会影响到上游部署Flume的日志流的始端日志收集服务。

如果数据平台内部某些系统，如Kafka集群、HDFS集群所在节点的机房位置变更，数据迁移，会使得依赖日志数据的外部系统受到不同程度的影响，外部系统需要相关开发或运维人员参与进来。

由于收集日志的数据源端可能是外部一些服务器(多个单个的节点)，一些业务集群(相互协作的多节点组)，也可能是内部一些提供收集服务的服务节点，这些所有的服务器上部署的Flume Agent都处于一层中，比较难于分组管理。

由于所有数据源端Flume Agent收集的日志进入数据平台的时候，没有一个统一的类似总线的组件，很难因为某些业务扩展而独立地去升级数据平台内部的接收层服务节点，可能为了升级数据平台内部某个系统或服务而导致影响了其他的接收层服务节点。【推荐了解大数据培训课程】

通过下图我们可以看出，这种单层日志收集系统设计，存在太多的问题，而且系统或服务越多导致整个日志收集系统越难以控制：

上图中，无论是外部还是内部，只要部署了Flume Agent的节点，都直接同内部的Kafka集群和Hadoop集群相连，所以在数据平台内部只能尽量保持Kafka和Hadoop集群正常稳定运行，也要为外部日志收集Flume Agent的数据流量的陡增和异常变化做好防控准备。再者，如需停机维护或者升级某一个集群，可能都需要通知外部所有Flume Agent所在节点的业务方，做好应对(停机)准备。

接着看，如果我们基于Flume使用分层的方式来设计日志收集系统，又有哪些优势，如下图所示：

上图中，Flume日志收集系统采用两层架构设计：第一层(L1)是日志收集层，第二层(L2)是数据平台缓冲层(汇聚层)。通过这种方式，使得日志收集系统有如下特点：

针对数据平台外部的业务系统，根据需要分析的数据业务类型进行分组，属于同一种类型的业务日志，在数据平台前端增加了一个Flume汇聚层节点组，该组节点只影响到它对应的L1层的业务数据

如果Hadoop集群、Kafka需要停机维护或升级，对外部L1层Flume Agent没有影响，只需要在L2层做好数据的接收与缓冲即可，待维护或升级结束，继续将L2层缓存的数据导入到数据存储系统

如果外部某个类型的业务日志数据节点需要扩容，直接在L1层将数据流指向数据平台内部与之相对应的L2层Flume Agent节点组即可，能够对外部因业务变化发生的新增日志收集需求，进行快速地响应和部署

对于数据平台内部，因为收集日志的节点非常可控，可以直接通过L1层Flume Agent使日志数据流入HDFS或Kafka，当然为了架构统一和管理，最好也是通过L2层Flume Agent节点组来汇聚/缓冲L1层Flume Agent收集的日志数据

通过上面分析可见，分层无非是为了使的日志数据源节点的Flume Agent服务与数据平台的存储系统(Kafka/HDFS)进行解耦，同时能够更好地对同类型业务多节点的日志流进行一个聚合操作，并分离开独立管理。另外，可以根据实际业务需要，适当增加Flume系统分层，满足日志流数据的汇聚需要。

应用整体架构

我们看一下，Flume日志收集系统，在我们这个示例应用中处于一个什么位置，我简单画了一下图，加了一些有关数据处理和分析的节点/组件，如下图所示：

这里，简单了解一下上图即可，由于日志收集在整个应用系统中是很重要的一个环节，所以必须保证日志收集系统设计的可靠、可用、灵活、稳定，通过上面在日志收集系统收集日志之后，数据平台所做的大量分析处理，来凸显日志收集系统的重要性，这里其他内容不做过多说明。