日志采集系统flume和kafka有什么区别及联系,它们分别在什么时候使用,什么时候又可以结合?

日志采集系统flume和kafka有什么区别及联系,它们分别在什么时候使用,什么时候又可以结合?日志采集系统flume和kafka有什么区别及联系,它们分别在什么时候使用,什么时候又可以结合?观点一:简言之:这两个差别很大,使用场景区别也很大。先说flume:日志采集。线上数据一般主要是落地文件或者通过socket传输给另外一个系统。这种情况下,你很难推动线上应用或服务去修改接口,直接向kafka里写数据。这时候你可能就需要flume这样的系统帮你去做传输。对于数量级别,做过单机upd的fl…

大家好,又见面了,我是你们的朋友全栈君。

日志采集系统flume和kafka有什么区别及联系,它们分别在什么时候使用,什么时候又可以结合?

观点一:
简言之:这两个差别很大,使用场景区别也很大。
先说flume:
日志采集。线上数据一般主要是落地文件或者通过socket传输给另外一个系统。这种情况下,你很难推动线上应用或服务去修改接口,直接向kafka里写数据。这时候你可能就需要flume这样的系统帮你去做传输。
对于数量级别,做过单机upd的flume source的配置,100+M/s数据量,10w qps flume就开始大量丢包。因此我们在搭建系统时,抛弃了flume,自己研发了一套传输系统。但flume设计的source-channel-sink模式还是比较好的,我们在开发系统时无耻的也抄袭了这种方式。

Kafka:
我个人觉得kafka更应该定位为中间件系统。开发这个东西目的也是这个初衷。可以理解为一个cache系统。你甚至可以把它理解为一个广义意义的数据库,里面可以存放一定时间的数据。kafka设计使用了硬盘append方式,获得了非常好的效果。
我觉得这是kafka最大的亮点。不同系统之间融合往往数据生产/消费速率不同,这时候你可以在这些系统之间加上kafka。例如线上数据需要入HDFS,线上数据生产快且具有突发性,如果直接上HDFS(kafka-consumer)可能会使得高峰时间hdfs数据写失败,这种情况你可以把数据先写到kafka,然后从kafka导入到hdfs上。印象中LinkedIn公司有这么用。

业界比较典型的一中用法是:
线上数据 -> flume -> kafka -> hdfs -> MR离线计算 或者:
线上数据 -> flume -> kafka -> storm

观点二:
Flume和Kafka本身是很相似的系统,都能无压力传输很大的数据量。

细节上他们当然有很多不同,但是总结下来,如果你纠结到底是用Kafka还是Flume:
1. Kafka是pull based, 如果你有很多下游的Data Consumer,用Kafka;
2. Kafka有Replication,Flume没有,如果要求很高的容错性(Data High Availability),选kafka;
3. 需要更好的Hadoop类产品接口,例如HDFS,HBase等,用Flume。

当然,这两个区别就让人自然而然的想到整合两者,这样既可拥有Kafka的容错能力,和Flume的多种接口,例如
Events —>Flume —> Kafka —> Flume —> Storage System (Hadoop Cluster)
当然,坏处就是你需要开发维护多个系统… 

前一段似乎看到Cloudera提出过一款Flafka的app,说的就是这两款产品的整合,有兴趣可以去搜搜。

观点三:
我偏爱Flume,因为架构简单,依赖少。
但是同样的,功能也简单,但是够灵活。
它的定位是数据通道,不是消息队列。

Flume和Kafka应该结合来使用,Flume作为日志收集端,Kafka作为日志消费端。
flume:日志采集系统
kafka:消息中间件
也用过楼上说的组合:
log->flume->kafka->hdfs(solr)

Flume的Source-Channel-Sink模型,非常适合作为日志收集的模型。你可以想一下,如果你来做一个日志收集的Agent,如果做能尽量保证日志数据的传输成功率,应对服务端的各种异常情况,以及如何灵活的接入各种不同的日志类型。
Kafka就不必多说了,生产者消费者模型,看你怎么去构建日志消费的下游了。有了消息队列作为中间件,消费的下游和上游可以完美的解耦。

概述:
       (1)kafka和flume都是日志系统。kafka是分布式消息中间件,自带存储,提供push和pull存取数据功能。flume分为agent(数据采集器),collector(数据简单处理和写入),storage(存储器)三部分,每一部分都是可以定制的。比如agent采用RPC(Thrift-RPC)、text(文件)等,storage指定用hdfs做。
       (2)kafka做日志缓存应该是更为合适的,但是 flume的数据采集部分做的很好,可以定制很多数据源,减少开发量。所以比较流行flume+kafka模式,如果为了利用flume写hdfs的能力,也可以采用kafka+flume的方式。

采集层 主要可以使用Flume, Kafka两种技术。
Flume:Flume 是管道流方式,提供了很多的默认实现,让用户通过参数部署,及扩展API.
Kafka:Kafka是一个可持久化的分布式的消息队列。
  • Kafka 是一个非常通用的系统。你可以有许多生产者和很多的消费者共享多个主题Topics。相比之下,Flume是一个专用工具被设计为旨在往HDFS,HBase发送数据。它对HDFS有特殊的优化,并且集成了Hadoop的安全特性。所以,Cloudera 建议如果数据被多个系统消费的话,使用kafka;如果数据被设计给Hadoop使用,使用Flume。
  • 正如你们所知Flume内置很多的source和sink组件。然而,Kafka明显有一个更小的生产消费者生态系统,并且Kafka的社区支持不好。希望将来这种情况会得到改善,但是目前:使用Kafka意味着你准备好了编写你自己的生产者和消费者代码。如果已经存在的Flume Sources和Sinks满足你的需求,并且你更喜欢不需要任何开发的系统,请使用Flume。
  • Flume可以使用拦截器实时处理数据。这些对数据屏蔽或者过量是很有用的。Kafka需要外部的流处理系统才能做到。
  • Kafka和Flume都是可靠的系统,通过适当的配置能保证零数据丢失。然而,Flume不支持副本事件。于是,如果Flume代理的一个节点奔溃了,即使使用了可靠的文件管道方式,你也将丢失这些事件直到你恢复这些磁盘。如果你需要一个高可靠行的管道,那么使用Kafka是个更好的选择。
  • Flume和Kafka可以很好地结合起来使用。如果你的设计需要从Kafka到Hadoop的流数据,使用Flume代理并配置Kafka的Source读取数据也是可行的:你没有必要实现自己的消费者。你可以直接利用Flume与HDFS及HBase的结合的所有好处。你可以使用Cloudera Manager对消费者的监控,并且你甚至可以添加拦截器进行一些流处理。
Flume和Kafka可以结合起来使用。通常会使用Flume + Kafka的方式。其实如果为了利用Flume已有的写HDFS功能,也可以使用Kafka + Flume的方式。
其他:
  今天开会讨论日志处理为什么要同时使用Flume和Kafka,是否可以只用Kafka 不使用Flume?当时想到的就只用Flume的接口多,不管是输入接口(socket 和 文件)以及输出接口(Kafka/HDFS/HBase等)。
   考虑单一应用场景,从简化系统的角度考虑,在满足应用需求的情况下可能只使用一个比较好。但是考虑到现有系统业务发展,为了后面的灵活扩展,在先用系统设计时留有一定的扩展性感觉更重要,可能使用Flume+kafka架构相对只使用Kafka会多占用1-2台机器做Flume日志采集,但是为了方便以后日志数据处理方式的扩展,可以采用Flume+kafka架构。
  
Flume :管道 —-个人认为比较适合有多个生产者场景,或者有写入Hbase、HDFS和kafka需求的场景。
  Kafka :消息队列—–由于Kafka是Pull模式,因此适合有多个消费者的场景
  目前应用场景,一台日志转发机负责产生日志。后端需要通过Strom消费日志信息,建议可以设置成log–>Kafka->storm.如果以后有写入Hbase或者HDFS的需求可以,在Kafka后面再接上storm,或者在日志转发机上直接日志落地,由Flume去读取日志消息。

Kafka 与 Flume 很多功能确实是重复的。以下是评估两个系统的一些建议:
  • Kafka 是一个通用型系统。你可以有许多的生产者和消费者分享多个主题。相反地,Flume 被设计成特定用途的工作,特定地向 HDFS 和 HBase 发送出去。Flume 为了更好地为 HDFS 服务而做了特定的优化,并且与 Hadoop 的安全体系整合在了一起。基于这样的结论,Hadoop 开发商 Cloudera 推荐如果数据需要被多个应用程序消费的话,推荐使用 Kafka,如果数据只是面向 Hadoop 的,可以使用 Flume。
  • Flume 拥有许多配置的来源 (sources) 和存储池 (sinks)。然后,Kafka 拥有的是非常小的生产者和消费者环境体系,Kafka 社区并不是非常支持这样。如果你的数据来源已经确定,不需要额外的编码,那你可以使用 Flume 提供的 sources 和 sinks,反之,如果你需要准备自己的生产者和消费者,那你需要使用 Kafka。
  • Flume 可以在拦截器里面实时处理数据。这个特性对于过滤数据非常有用。Kafka 需要一个外部系统帮助处理数据。
  • 无论是 Kafka 或是 Flume,两个系统都可以保证不丢失数据。然后,Flume 不会复制事件。相应地,即使我们正在使用一个可以信赖的文件通道,如果 Flume agent 所在的这个节点宕机了,你会失去所有的事件访问能力直到你修复这个受损的节点。使用 Kafka 的管道特性不会有这样的问题。
  • Flume 和 Kafka 可以一起工作的。如果你需要把流式数据从 Kafka 转移到 Hadoop,可以使用 Flume 代理 (agent),将 kafka 当作一个来源 (source),这样可以从 Kafka 读取数据到 Hadoop。你不需要去开发自己的消费者,你可以使用 Flume 与 Hadoop、HBase 相结合的特性,使用 Cloudera Manager 平台监控消费者,并且通过增加过滤器的方式处理数据。
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。

发布者:全栈程序员-用户IM,转载请注明出处:https://javaforall.cn/152360.html原文链接:https://javaforall.cn

【正版授权,激活自己账号】: Jetbrains全家桶Ide使用,1年售后保障,每天仅需1毛

【官方授权 正版激活】: 官方授权 正版激活 支持Jetbrains家族下所有IDE 使用个人JB账号...

(0)


相关推荐

  • python标识符号_python标识符的组成元素

    python标识符号_python标识符的组成元素在Python里,标识符由字母、数字、下划线组成,但不能以数字开头。#Python中标识符区分大小写。#以下划线开头的标识符有特殊意义,以单下划线开头_foo的代表不能直接访问的类属性,需通过类提供的接口进行访问,不能用fromxxximport*而导入。##以双下划线开头的__foo代表类的私有成员,以双下划线开头和结尾的__foo__代表Python里特殊方法专用的标识,如__init__()代表类的构造函数。##Python可以同一行显示多.

  • html页面缩小导航栏隐藏,html – 导航栏缩放问题[通俗易懂]

    html页面缩小导航栏隐藏,html – 导航栏缩放问题[通俗易懂]我有一个问题,我的导航栏似乎与CSS中的.container缩放.现在,我是一个新手,但我已经尝试搞乱CSS中的值,但无济于事.这是HTML和CSS的代码:*{margin:0px;padding:0px;}body{font-family:verdana;background-image:url(images/bg2.jpg);max-width:100%;max-height:…

  • 小波去噪MATLAB代码「建议收藏」

    小波去噪MATLAB代码「建议收藏」本文基于北京交通大学陈后金教授的课件。我加以整理,若有冒犯还请谅解1利用MATLAB产生分解与重建滤波器组计算滤波器组的函数[Ld,Hd,Lr,Hr]=wfilters(‘wname’)Ld:分解低通滤波器h0[-n];Hd:分解高通滤波器h1[-n];Lr:分解低通滤波器h0[-n];Hr:分解高通滤波器h1[-n];wfname:小波名eg1:计算db2小波的四…

  • 数据结构

    数据结构数据结构

  • [LeetCode] Top K Frequent Elements 前K个高频元素

    [LeetCode] Top K Frequent Elements 前K个高频元素

  • 雷达系统导论_雷达信号处理基础第二版

    雷达系统导论_雷达信号处理基础第二版1.3.3接收机单个散射体的回波波形具有下面的形式:其中,幅度调制A(t)仅仅表示脉冲的包络。接收机处理的主要功能是将雷达信号中承载信息的部分变换到基带,目的是测量。接收机的信号被分到两个通道。为同相“I”通道,在这个通道中接收信号和振荡器(本振)的信号进行混频。这个混频产生了和频和差…

    2022年10月21日

发表回复

您的电子邮箱地址不会被公开。

关注全栈程序员社区公众号