主流大数据采集平台架构对比分析.docx 17页

主流大数据采集平台架构对比分析任何完整的大数据平台，一般包括以下的几个过程：数据采集–>数据存储–>数据处理–>数据展现(可视化，报表和监控)。其中，「数据采集」是所有数据系统必不可少的，随着大数据越来越被重视，「数据采集」的挑战也变的尤为突出。这其中包括：数据源多种多样 数据量大 变化快 如何保证数据采集的可靠性的性能 如何避免重复数据 如何保证数据的质量今天我们也来看看主流的几个数据采集平台，重点关注它们是如何做到高可靠，高性能和高扩展。Apache FlumeFlume 是 Apache 旗下的一款开源、高可靠、高扩展、容易管理、支持客户扩展的数据采集系统。 Flume 使用 JRuby 来构建，所以依赖 Java 运行环境。Flume 最初是由 Cloudera 的工程师设计，用于合并日志数据的系统，后来逐渐发展用于处理流数据事件。Flume 设计成一个分布式的管道架构，可以看作在数据源和目的地之间有一个 Agent 的网络，支持数据路由。每一个 agent 都由 Source，Channel 和 Sink 组成。SourceSource 负责接收输入数据，并将数据写入管道。它支持 HTTP、JMS、RPC、NetCat、Exec、Spooling Directory。其中 Spooling 支持监视一个目录或者文件，解析其中新生成的事件。ChannelChannel 存储，缓存从 source 到 Sink 的中间数据。可使用不同的配置来做 Channel，例如内存、文件、JDBC等。使用内存性能高但不持久，有可能丢数据。使用文件更可靠，但性能不如内存。SinkSink 负责从管道中读出数据并发给下一个 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。FluentdFluentd 是另一个开源数据收集框架。它使用 C/Ruby 开发，用 JSON 文件来统一日志数据。它的可插拔架构，支持各种不同种类和格式的数据源和数据输出。它同时也提供高可靠和很好的扩展性。Treasure Data, Inc 对该产品提供支持和维护。Fluentd 的部署和 Flume 非常相似：其 Input/Buffer/Output 非常类似于 Flume 的 Source/Channel/Sink。InputInput 负责接收数据或者主动抓取数据。支持 syslog、http、file tail 等。BufferBuffer 负责数据获取的性能和可靠性，也有文件或内存等不同类型的 Buffer 可以配置。OutputOutput 负责输出数据到目的地，例如文件、AWS S3 或者其它的 Fluentd。Fluentd 的配置非常方便，如下图：Fluentd 的技术栈如下图：FLuentd 和其插件都是由 Ruby 开发，MessgaePack 提供了 JSON 的序列化和异步的并行通信 RPC 机制。FLuentd 的扩展性非常好，客户可以自己定制 (Ruby)Input/Buffer/Output。Fluentd 从各方面看都很像 Flume，区别是使用 Ruby 开发，F

开始查重