任何完整的大数据平台，一般包括以下的几个过程：数据采集–>数据存储–>数据处理–>数据展现(可视化，报表和监控)。
其中，「数据采集」是所有数据系统必不可少的，随着大数据越来越被重视，「数据采集」的挑战也变的尤为突出。这其中包括：
- 数据源多种多样
- 数据量大
- 变化快
- 如何保证数据采集的可靠性的性能
- 如何避免重复数据
- 如何保证数据的质量
今天我们也来看看主流的几个数据采集平台，重点关注它们是如何做到高可靠，高性能和高扩展。
Apache Flume
Flume 是 Apache 旗下的一款开源、高可靠、高扩展、容易管理、支持客户扩展的数据采集系统。 Flume 使用 JRuby 来构建，所以依赖 Java 运行环境。
Flume 最初是由 Cloudera 的工程师设计，用于合并日志数据的系统，后来逐渐发展用于处理流数据事件。
Flume 设计成一个分布式的管道架构，可以看作在数据源和目的地之间有一个 Agent 的网络，支持数据路由。
每一个 agent 都由 Source，Channel 和 Sink 组成。
Source
Source 负责接收输入数据，并将数据写入管道。它支持 HTTP、JMS、RPC、NetCat、Exec、Spooling Directory。其中 Spooling 支持监视一个目录或者文件，解析其中新生成的事件。
Channel
Channel 存储，缓存从 source 到 Sink 的中间数据。可使用不同的配置来做 Channel，例如内存、文件、JDBC等。使用内存性能高但不持久，有可能丢数据。使用文件更可靠，但性能不如内存。
Sink
Sink 负责从管道中读出数据并发给下一个 Agent 或者最终的目的地。它支持的不同目的地种类包括：HDFS、HBASE、Solr、ElasticSearch、File、Logger 或者其它的 Flume Agent。
Flume 在 source 和 sink 端都使用了 transaction 机制保证在数据传输中没有数据丢失。
Source 上的数据可以复制到不同的通道上。每一个 Channel 也可以连接不同数量的 Sink。这样连接不同配置的 Agent 就可以组成一个复杂的数据收集网络。通过对 agent 的配置，可以组成一个路由复杂的数据传输网络。
配置如上图所示。Flume 支持设置 sink 的 Failover 和 Load Balance，这样就可以保证，即使有一个 agent 失效的情况下，整个系统仍能正常收集数据。
Flume 中传输的内容定义为事件(Event)，事件由 Headers(包含元数据，Meta Data)和 Payload 组成。
它提供 SDK，可以支持用户定制开发。
其客户端负责在事件产生的源头把事件发送给 Flume 的 Agent。客户端通常和产生数据源的应用在同一个进程空间。
常见的 Flume 客户端有 Avro、log4J、syslog 和 HTTP Post。另外 ExecSource 支持指定一个本地进程的输出作为 Flume 的输入。
当然很有可能，以上的这些客户端都不能满足需求，用户可以定制的客户端，和已有的 FLume 的 Source 进行通信，或者定制实现一种新的 Source 类型。
同时，用户可以使用 Flume 的 SDK 定制 Source 和 Sink。不过它似乎不支持定制的 Channel。
Fluentd
Fluentd 是另一个开源数据收集框架。它使用 C/Ruby 开发，用 JSON 文件来统一日志数据。它的可插拔架构，支持各种不同种类和格式的数据源和数据输出。
它同时也提供高可靠和很好的扩展性。Treasure Data, Inc 对该产品提供支持和维护。
Fluentd 的部署和 Flume 非常相似：
其 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 机制。
FLuentd 的扩展性非常好，客户可以自己定制 (Ruby)Input/Buffer/Output。
Fluentd 从各方面看都很像 Flume，区别是使用 Ruby 开发，Footprint 会小一些，但是也带来了跨平台的问题，并不能支持 Windows 平台。
采用 JSON 统一数据/日志格式也是它的另一个特点。相对于 Flumed，配置也简单一些。
Logstash
Logstash 是著名的开源数据栈 ELK (ElasticSearch, Logstash, Kibana) 中的那个 L。
它用 JRuby 开发，所有运行时依赖 JVM。
Logstash 的部署架构如下图，当然这只是一种部署的选项。
一个典型的 Logstash 配置如下，包括了 Input、filter、Output 的设置。
几乎在大部分的情况下，ELK 作为一个栈是被同时使用的。所以当你的数据系统使用 ElasticSearch 的情况下，logstash 是首选。
Chukwa
Apache Chukwa 是 apache 旗下另一个开源的数据收集平台，它远没有其他几个有名。
Chukwa 基于 Hadoop 的 HDFS 和 Map Reduce 来构建(显而易见，它用Java来实现)，提供扩展性和可靠性。它同时提供对数据的展示、分析和监视。奇怪的是，它的上一次 github 更新是7年前，可见该项目应该已经不活跃了。
Chukwa 的部署架构如下：
Chukwa 的主要单元有：Agent、Collector、DataSink、ArchiveBuilder、Demux 等等，看上去相当复杂。由于该项目已经不活跃，我们就不细看了。
Scribe
Scribe 是 Facebook 开发的数据(日志)收集系统。已经多年不维护，同样的，就不多说了。
Splunk Forwarder
在商业化的大数据平台产品中，Splunk 提供完整的数据采集、数据存储、数据分析和处理，以及数据展现的能力。
它是一个分布式的机器数据平台，主要有三个角色：
Search Head 负责数据的搜索和处理，提供搜索时的信息抽取。
Indexer 负责数据的存储和索引 Forwarder，负责数据的收集、清洗、变形，并发送给 Indexer 。
Splunk 内置了对 Syslog、TCP/UDP、Spooling 的支持，同时，用户可以通过开发 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 很快会开发出更好的数据收集的解决方案。
————————————————
版权声明：本文为CSDN博主「o.o沧海一粟」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/weixin_43892898/article/details/89135175