大数据系统数据采集产品的架构分析

任何完整的大数据平台，通常包括如下的几个过程：

1. 数据采集

2. 数据存储

3. 数据处理

4. 数据展示（可视化，报表和监控）

其中，数据采集是全部数据系统必不可少的，随着大数据愈来愈被重视，数据采集的挑战也变的尤其突出。这其中包括：

• 数据源多种多样

• 数据量大，变化快

• 如何保证数据采集的可靠性的性能

• 如何避免重复数据

• 如何保证数据的质量

咱们今天就来看看当前可用的一些数据采集的产品，重点关注一些它们是如何作到高可靠，高性能和高扩展。

Apache Flume

Flume 是Apache旗下，开源，高可靠，高扩展，容易管理，支持客户扩展的数据采集系统。 Flume使用JRuby来构建，因此依赖Java运行环境。

Flume最初是由Cloudera的工程师设计用于合并日志数据的系统，后来逐渐发展用于处理流数据事件。

Flume设计成一个分布式的管道架构，能够看做在数据源和目的地之间有一个Agent的网络，支持数据路由。

每个agent都由Source，Channel和Sink组成。

• Source

  Source负责接收输入数据，并将数据写入管道。Flume的Source支持HTTP，JMS，RPC，NetCat，Exec，Spooling Directory。其中Spooling支持监视一个目录或者文件，解析其中新生成的事件。

• Channel

  Channel 存储，缓存从source到Sink的中间数据。可以使用不一样的配置来作Channel，例如内存，文件，JDBC等。使用内存性能高但不持久，有可能丢数据。使用文件更可靠，但性能不如内存。

• Sink

  Sink负责从管道中读出数据并发给下一个Agent或者最终的目的地。Sink支持的不一样目的地种类包括：HDFS，HBASE，Solr，ElasticSearch，File，Logger或者其它的Flume Agent

Flume在source和sink端都使用了transaction机制保证在数据传输中没有数据丢失。

Source上的数据能够复制到不一样的通道上。每个Channel也能够链接不一样数量的Sink。这样链接不一样配置的Agent就能够组成一个复杂的数据收集网络。经过对agent的配置，能够组成一个路由复杂的数据传输网络。

配置如上图所示的agent结构，Flume支持设置sink的Failover和Load Balance，这样就能够保证即便有一个agent失效的状况下，整个系统仍能正常收集数据。

Flume中传输的内容定义为事件（Event），事件由Headers（包含元数据，Meta Data）和Payload组成。

Flume提供SDK，能够支持用户定制开发：

Flume客户端负责在事件产生的源头把事件发送给Flume的Agent。客户端一般和产生数据源的应用在同一个进程空间。常见的Flume客户端有Avro，log4J，syslog和HTTP Post。另外ExecSource支持指定一个本地进程的输出做为Flume的输入。固然颇有可能，以上的这些客户端都不能知足需求，用户能够定制的客户端，和已有的FLume的Source进行通讯，或者定制实现一种新的Source类型。

同时，用户可使用Flume的SDK定制Source和Sink。彷佛不支持定制的Channel。

Fluentd

Fluentd （Github 地址）是另外一个开源的数据收集框架。Fluentd使用C/Ruby开发，使用JSON文件来统一日志数据。它的可插拔架构，支持各类不一样种类和格式的数据源和数据输出。最后它也同时提供了高可靠和很好的扩展性。Treasure Data, Inc对该产品提供支持和维护。

Fluentd的部署和Flume很是类似：

Fluentd的架构设计和Flume一模一样：

Fluentd的Input／Buffer／Output很是相似于Flume的Source／Channel／Sink。

• Input

  Input负责接收数据或者主动抓取数据。支持syslog，http，file tail等。

• Buffer

  Buffer负责数据获取的性能和可靠性，也有文件或内存等不一样类型的Buffer能够配置。

• Output

  Output负责输出数据到目的地例如文件，AWS S3或者其它的Fluentd。

Fluentd的配置很是方便，以下图：

Fluentd的技术栈以下图：

FLuentd和其插件都是由Ruby开发，MessgaePack提供了JSON的序列化和异步的并行通讯RPC机制。

Cool.io是基于libev的事件驱动框架。

FLuentd的扩展性很是好，客户能够本身定制（Ruby）Input／Buffer／Output。

Fluentd从各方面看都很像Flume，区别是使用Ruby开发，Footprint会小一些，可是也带来了跨平台的问题，并不能支持Windows平台。另外采用JSON统一数据／日志格式是它的另外一个特色。相对去Flumed，配置也相对简单一些。

Logstash

Logstash是著名的开源数据栈ELK（ElasticSearch，Logstash，Kibana）中的那个L。

Logstash用JRuby开发，全部运行时依赖JVM。

Logstash的部署架构以下图，固然这只是一种部署的选项。

一个典型的Logstash的配置以下，包括了Input，filter的Output的设置。

input {
  file {
    type => "apache-access"
    path => "/var/log/apache2/other_vhosts_access.log"
  }

  file {
    type => "apache-error"
    path => "/var/log/apache2/error.log"
  }
}

filter {
  grok {
    match => { "message" => "%{COMBINEDAPACHELOG}" }
  }
  date {
  match => [ "timestamp" , "dd/MMM/yyyy:HH:mm:ss Z" ]
  }
}

output {
  stdout { }
  redis {
    host => "192.168.1.200"
    data_type => "list"
    key => "logstash"
  }
}

几乎在大部分的状况下ELK做为一个栈是被同时使用的。全部当你的数据系统使用ElasticSearch的状况下，logstash是首选。

Chukwa

Apache Chukwa （github）是apache旗下另外一个开源的数据收集平台，它远没有其余几个有名。Chukwa基于Hadoop的HDFS和Map Reduce来构建（显而易见，它用Java来实现），提供扩展性和可靠性。Chukwa同时提供对数据的展现，分析和监视。很奇怪的是它的上一次github的更新事7年前。可见该项目应该已经不活跃了。

Chukwa的部署架构以下。

Chukwa的主要单元有：Agent，Collector，DataSink，ArchiveBuilder，Demux等等，看上去至关复杂。

因为该项目已经不活跃，咱们就不细看了。

Scribe

Scribe是Facebook开发的数据（日志）收集系统。已经多年不维护，一样的，就很少说了。

Splunk Forwarder

以上的全部系统都是开源的，在商业化的大数据平台产品中，Splunk提供完整的数据采金，数据存储，数据分析和处理，以及数据展示的能力。

Splunk是一个分布式的机器数据平台，主要有三个角色：

• Search Head负责数据的搜索和处理，提供搜索时的信息抽取。

• Indexer负责数据的存储和索引

• Forwarder，负责数据的收集，清洗，变形，并发送给Indexer
  

Splunk内置了对Syslog，TCP/UDP，Spooling的支持，同时，用户能够经过开发Script Input和Modular Input的方式来获取特定的数据。在Splunk提供的软件仓库里有不少成熟的数据采集应用，例如AWS，数据库（DBConnect）等等，能够方便的从云或者是数据库中获取数据进入Splunk的数据平台作分析。

这里要注意的是，Search Head和Indexer都支持Cluster的配置，也就是高可用，高扩展的，可是Splunk如今尚未针对Farwarder的Cluster的功能。也就是说若是有一台Farwarder的机器出了故障，数据收集也会随之中断，并不能把正在运行的数据采集任务Failover到其它的Farwarder上。

总结

咱们简单讨论了几种流行的数据收集平台，它们大都提供高可靠和高扩展的数据收集。大多平台都抽象出了输入，输出和中间的缓冲的架构。利用分布是的网络链接，大多数平台都能实现必定程度的扩展性和高可靠性。其中Flume，Fluentd是两个被使用较多的产品。若是你用ElasticSearch，Logstash也许是首选，由于ELK栈提供了很好的集成。Chukwa和Scribe因为项目的不活跃，不推荐使用。

Splunk做为一个优秀的商业产品，它的数据采集还存在必定的限制，相信Splunk很快会开发出更好的数据收集的解决方案。