flink kafka flume 从开发到部署遇到的问题及解决方案

最近遇到了比较多的中间件的环境问题整理了些注意事项

 

1. 启动顺序 zookeeper -> kafka ->  flink - > flink提交的job ->flume
2. kafka的快照保存时间的设置

     log.retention.hours=168(sever.properties)设置时间长很浪费资源

1. flink任务提交前kafka保存的数据并不会被flink消费
2. 对于常见的反压问题flink本身都能解决
3. flink批处理定时要先启动定时执行flink任务提交再启动flink集群
4. 因为flink的容错机制，在ES消费flink的时候如果某条数据不能被消费flink会反复的尝试去做（当然我们可以设置尝试次数）回到那个checkpoint找到当时的快照重复再重复所以对脏数据的提前识别处理很重要(比如限定长度，字段类型判断)
5. flink代码的checkstyle很重要，被flink客户端查出来job会无法提交
6. 传统Flink  jar的执行离不开flink的客户端用nohup，setsid起不来
7. 用flink jdk至少要1.8.2以上的版本，最合适的IDE是idea
8. Flume的后台启动 推荐用setsid而不是nohup
9. flume的启动命令多种多样推荐用下面的（flume-ng agent -n agent -c conf -f conf\flume-conf.properties.template -property  "flume.root.logger=INFO,console"）带着 -c有日志
10.  Flume采集默认的编码方式是UTF-8 但是配置里还得写，如果报错请用GBK(主要看文件编码方式)
11. flume存在copy延迟会抛异常，遇到这样的问题创建个临时目录放文件然后用mv迁移到flume采集目录
12. fume可以内置jdk 在它的env.sh中
13. kafka不能重复消费在于它的offset机制别去删它的日志那都是hash存的快照
14. kafka的partitions能让并行跑起来，但是会遇到数据的有序性问题，kafka的时序机制能解决所以kafka的partitions可以设大点
15. flume的故障转移和负载均衡适用于文件类型少的单个文件大的情况。如果文件类型太多可能因为开的通道太多耗尽内存
16. flume的故障转移实质就是把有问题的放在冷却池冷却下让别人替它干活适用于三台以上的机器
17. kafka依赖于zookeeper的调度
18. flink的算子 map, reduce, filter和java8流式操作基本一样，所以flink代码可以多写点匿名内部类，flink很适配lambda
19. flink的tableAPI支持 SUM COUNT AVG等传统关系库的函数