大数据框架复习-zookeeper+flume
zookeeper的选举机制
- 半数机制,超过半数的投票通过,即通过。
- 在集群正常工作之前,myid 小的服务器给 myid 大的服务器投票,直到集群正常工作,选出 Leader;
- 选出 Leader 之后,之前的服务器状态由 Looking 改变为 Following,以后的服务器都是 Follower
- 第一次启动选举规则:投票过半数时,服务器id大的胜出;
- 第二次启动选举机制:
- EPOCH(每个Leader任期的代号)大的直接胜出;
- EPOCH相同,事务id大的胜出;
- 事务id相同,服务器id大的胜出;
zookeeper安装多少合适?
- 安装奇数台;
- 生产经验:10台服务器3台zk;
- 台数多:好处:提高可靠性;坏处:通信延迟变大;
flume组成,Put事务,Take事务
- Taildir Source:断点续传、多目录。Flume1.6以前需要自己自定义Source记录每次读取文件位置,实现断点续传;
- File Channel:数据存储在磁盘,宕机数据可以保存。但是传输速率慢。适合对数据传输可靠性要求高的场景,比如,金融行业;
- Memory Channel:数据存储在内存中,宕机数据丢失。传输速率快。适合对数据传输可靠性要求不高的场景,比如,普通的日志数据。
- Kafka Channel:减少了Flume的Sink阶段,提高了传输效率;
- Source到Channel是Put事务; Channel到Sink是Take事务
flume拦截器
- 自定义拦截器的步骤
- 实现 Interceptor
- 重写4个方法
initialize
初始化;public Event intercept(Event event)
处理单个Eventpublic List<Event> intercept(List<Event> events)
处理多个Event,在这个方法中调用Event intercept(Event event)- close 方法
- 静态内部类,实现Interceptor.Builder;
- 注:静态内部类的作用:如在进行代码程序测试的时候,如果在每一个Java源文件中都设置一个主方法(主方法是某个应用程序的入口,必须具有),那么会出现很多额外的代码。而且最主要的是这段主程序的代码对于Java文件来说,只是一个形式,其本身并不需要这种主方法。但是少了这个主方法又是万万不行的。在这种情况下,就可以将主方法写入到静态内部类中,从而不用为每个Java源文件都设置一个类似的主方法。这对于代码测试是非常有用的。在一些中大型的应用程序开发中,则是一个常用的技术手段。
flume采集的数据会丢失吗
- 根据 Flume 的架构原理,Flume 是不可能丢失数据的,其内部有完善的事务机制;
- Source 到 Channel 是事务性的,Channel 到 Sink 是事务性的,因此这两个环节不会出现数据的丢失,唯一可能丢失数据的情况是 Channel 采用 memoryChannel,agent 宕机导致数据丢失,或者 Channel 存储数据已满,导致 Source 不再写入,未写入的数据丢失。
- Flume 不会丢失数据,但是有可能造成数据的重复,例如数据已经成功由 Sink 发出, 但是没有接收到响应,Sink 会再次发送数据,此时可能会导致数据的重复;
flume的hdfs sink小文件处理
- HDFS存入大量小文件,有什么影响?
- 元数据层面:每个小文件都有一份元数据,其中包括文件路径,文件名,所有者,所属组,权限,创建时间等,这些信息都保存在Namenode内存中。所以小文件过多,会占用Namenode服务器大量内存,影响Namenode性能和使用寿命
- **计算层面:**默认情况下MR会对每个小文件启用一个Map任务计算,非常影响计算性能。同时也影响磁盘寻址时间
- HDFS小文件处理
- 官方默认的这三个参数配置写入HDFS后会产生小文件,
hdfs.rollInterval
、hdfs.rollSize
、hdfs.rollCount
- 基于以上
hdfs.rollInterval=3600
,hdfs.rollSize=134217728
,hdfs.rollCount =0
,hdfs.roundValue=10
,hdfs.roundUnit= second
几个参数综合作用,效果如下:- tmp文件在达到128M时会滚动生成正式文件
- tmp文件创建超10秒时会滚动生成正式文件
部分资料来自五分钟学大数据、尚硅谷