flume

flume篇3：flume把json数据写入carbondata(flume-carbondata-sink) 对应非json数据同样适用，可以把非json数据通过拦截器拼接成一个以 ,分隔的string，然后send出去，这样也是ok的 废话不多说，直接上干货 一、 自定义拦截器： 1 拦截器要求：新建一个新的工程，单独打包，保证每个flume的的拦截器都是单独的一个工程打的包，这样保证每次对拦截器修改的时候不影响其他flume业务 < properties > < project . build . sourceEncoding > UTF - 8 < / project . build . sourceEncoding > < maven . compiler . source > 1.7 < / maven . compiler . source > < maven . compiler . target > 1.7 < / maven . compiler . target > < scala . version > 2.10 .4 < / scala . version > < flume . version > 1.8 .0 < / flume . version > < / properties > < dependencies > < dependency > <

目录 一、概述 二、一个通用的数据采集模型 三、Logstash 四、Flume 1、Flume OG 1、Flume NG 五、对比 一、概述 在某个Logstash的场景下，我产生了为什么不能用Flume代替Logstash的疑问，因此查阅了不少材料在这里总结，大部分都是前人的工作经验下，加了一些我自己的思考在里面，希望对大家有帮助。 大数据的数据采集工作是大数据技术中非常重要、基础的部分，数据不会平白无故地跑到你的数据平台软件中，你得用什么东西把它从现有的设备（比如服务器，路由器、交换机、防火墙、数据库等）采集过来，再传输到你的平台中，然后才会有后面更加复杂高难度的处理技术。 目前，Flume和Logstash是比较主流的数据采集工具（主要用于日志采集），但是很多人还不太明白两者的区别，特别是对用户来说，具体场景使用合适的采集工具，可以大大提高效率和可靠性，并降低资源成本。 我们先来看Logstash，然后看Flume 二、一个通用的数据采集模型 普适环境的数据采集 其中，数据采集和存储是必要的环节，其他并不一定需要。是不是很简单？本来编程其实就是模块化的东西，没有那么难。但是这毕竟只是一个粗略的通用模型，不同开源社区或者商业厂家开发的时候都会有自己的考虑和目的。我们在本文要讨论的Flume和Logstash原则上都属于数据采集这个范畴

背景 日志，角色不同，出发点和认识的角度也不同 RD使用日志，首先是为了调试程序，当程序上线后，日志是为了记录err和trace。 PM可以通过日志分析，可以得出业务指标相关的统计情况。 日志的作用大致有三：异常、trace、统计。 日志使用的痛点 使用日志时大部分的场景或特点如下： 1.日志为纯文本，即可读。 2.日志分散在各个机器上，或者同步到某一台机器。 3.某某发现一个问题，让某某去查log。 这里有几个问题，或者说提高点 1.文本冗余度太大，浪费资源，如果转换为二进制，预估有5倍的收益。 2.日志分散，查找效率低，即使集中，在没有具体时间点情况下，扫描日志会很慢。 3.日志分析难度大，谁写的日志谁来查，查到和肉眼找到还差一步... 目标 所以，我们可以设计这样一个日志系统 1.支持海量数据的日志存储（TB二进制） 2.日志二进制、结构化 3.查询速度快，难度低 设计 读写日志 日志查询过程经分解和总结共性后，几乎是下边三种情况 1.K-V查询，比如基于某个消息ID，查询一条记录。 2.集合查询，比如查询某个用户的消息记录。 3.集合range查询，比如查询某个用户0点到1点消息记录。 那么，ssdb是非常适合这三个需求的。 日志系统具有写多读少的特定，再基于磁盘存储的业界主流方案，LSM是适合的， 而SSDB的存储依赖的leveldb正好属于LSM系。 日志二进制

大数据由一系列技术组成，那他们之间的关系是怎么组成的ne，请看下图： hadoop主要做了文件存储系统和提供了一个相对比较弱的mr处理数据的方案 hive是在mr和文件存储系统上面做的升级。 sprak+hbase+hadoop主要解决的是hadoop实时处理数据比较弱的问题 来源： https://www.cnblogs.com/jueshixingkong/p/12004671.html