flink

简介

刚接触flink时，本人还是个小萌新。对大数据概念望而生畏。而在入门之后，顿感轻松。所以在学习任何一门技术时，都要保持平稳的心态。

参考资料

《阿里巴巴flink干货合集》
https://flink.sojb.cn/
https://flink.apache.org/

为什么选择flink

简而言之，别人有的他都有，包罗万象。吹捧者众多，但是由于其存在的一些问题，一时无法解决，故后期又抛弃了flink，采用别的方式来实现分布式。

安装

git clone https://github.com/apache/flink.git
cd flink/
mvn clean package -DskipTests

集群搭建

集群包含两种manager：jobManager和taskManager。
JobManager负责协调flink系统，整个集群中只有1个在运行，一般需要配置为多机热备，用来调度task，协调检查点，协调失败时恢复等。
TaskManager则是执行并行程序的worker，集群启动后，可以动态添加TaskManager，每台机器上会开启1个TaskManager。
集群环境的搭建要注意，在不同机器上flink的安装目录要一致、包括flink自身的配置文件、应用要读取的外部配置文件、还有不同机器上的用户名（密码可以不同，启动集群时会在命令行中手动输入密码）。
具体集群环境搭建过程参考官网。

集群管理

可以通过图形界面进行操作，方便集群管理，但是该图形界面任何人都有权限关闭正在运行的程序，安全性极低，暂未深入了解flink的运营监控方式。
一种解决方法是前面再挂一层nginx做安全验证。

一些概念

节点

flink主要有三种节点需要编写：
Source：数据源，从redis或者其他数据库、消息队列中读取数据，产生数据流，输入到flink框架中
算子：处理数据流
Sink：水槽，用于将结果输出。

Slot（槽）

Slot（槽）是TaskManager资源粒度的划分，每个Slot都有自己独立的内存。所有Slot平均分配TaskManger的内存，比如TaskManager分配给Solt的内存为8G，两个Slot，每个Slot的内存为4G，四个Slot，每个Slot的内存为2G，值得注意的是，Slot仅划分内存，不涉及cpu的划分。同时Slot是Flink中的任务执行器（类似Storm中Executor），每个Slot可以运行多个task，而且一个task会以单独的线程来运行。Slot的个数就代表了一个Flink程序的最高并行度，简化了性能调优的过程，允许多个Task共享Slot。

Parallelism（并行度）

Parallelism（并行度）是模块启动时指定的，会占用一定的slot资源。但并不是一一对应的关系，程序内部能够例如可以编写一个包含10个节点的程序，但只分配1个并行度，这样程序也是能够运行的。并行度指的是并行能力，不与具体的节点挂钩。

状态原理

状态原理：数据会定期进行快照，当机器(节点)等失败时, 只需从最近的一份快照开始, 利用可重发的数据源重发一次数据即可, 当数据经过filter算子时, 全部重新算一次即可，根本不需要区分哪个数据被计算过，哪个数据没有被计算过。

window

window：flink中提供了window将流拆分为有限大小的“桶”，即将单个的数据集合起来再触发算子执行批量的操作。

keyby

keyby：flink通过keyby将流进行拆分，用来实现分布式多机并行，并且假如按照某些固定属性进行keyby，相同的属性会被固定到同一节点上，很明显这样容易造成压力不均衡，设计时要仔细考虑，假如没有进行keyby，则无法获得并行能力（似乎在无状态处理时，有轮询均衡的方式随机拆分）

集群配置

配置文件位于flink目录下的/build-target/conf目录

配置flink-conf.yaml

1. jobmanager.rpc.address：配置为job节点ip地址，集群中每台都配置一样
2. jobmanager.rpc.port：配置为job节点端口，集群中每台都配置一样
3. rest.port：配置为flink监控页面端口，需要外网访问，
4. taskmanager.host：配置为本机task节点ip地址，如测试环境有多个ip，则配置为集群中可以相互通信的ip
5. taskmanager.data.port：配置为本机task节点端口，可以通过该端口与集群中其他task节点通信，如若出现通信问题，可以检查防火墙
6. taskmanager.numberOfTaskSlots：配置为本机CPU数，假如本机还跑了其他模块程序，可以适当配置小一点
7. taskmanager.heap.size: 配置task最大使用内存，按项目情况，先设置10240m即可

配置log4j.properties

1. log4j.appender.file：配置为：org.apache.log4j.DailyRollingFileAppender
2. log4j.appender.file.DatePattern：配置为：’.'yyyy-MM-dd-HH
3. log4j.appender.file.file：配置为日志文件，示例：/Log/flink-edge/taskexecutor.log

集群启动

1. 在job节点机器上，flink目录下的/build-target/bin中启动其job节点以及task节点，命令为：./start-cluster.sh
2. 在其他task节点机器上，flink目录下的/build-target/bin中启动task节点，命令为：./taskmanager.sh start

经验之谈

source节点的编码，一般是一个死循环结构，在run方法中不断进行数据的获取，结构放到SourceContext中。

广播流是常常会遇到的一种场景，本人在项目中是拿来做作为控制用途的。

组合多种不同的流，借鉴storm中的设计，有共同的父类，算子中用instanceof判断数据类型，达到多种不同流作为输入的目的。

flink那些坑

1. 进程模型，java规范中禁止jni在同一进程中被两个不同的ClassLoader加载。假如项目是jni结合的，不同拓扑加载同一jni时，会出现冲突。即使停掉其中一个，也无法解决。必须在停掉拓扑的同时，调用卸载jni。
2. 有许多猝不及防的异常报错，多出现在序列化、高可用等关键场景。关闭拓扑卡死了，重启taskmanager无法正常恢复等等，让人不禁觉得，这门技术怎么那么难用？
3. 很多问题无法通过百度找到合理解答，要自己领悟其中奥妙。
4. 本人通过两个月时间，将一个成熟单模块项目改造成了flink分布式架构，而后发现团队成员包括我自己在内，根本无法忍受如此高深莫测的技术，棘手毛病接踵而至。终于在上线运行3个月后，换用了其他方式实现分布式架构。积累不足、资料匮乏的情况下，flink是一个及其不友好的架构。相对来说storm入门到写出一个稳定运行的项目相当快，而用flink，几个月的投入仍然提心吊胆。