Flink 核心

虽然开源框架比较多，但是假如把自己想象成开源开发者，设想自己在原碰到这个需求时需要自己造轮子，那么自己会怎么写呢？这样思考后再去学习开源框架可能就没那么困难了。开源框架虽然给业务开发带来了便利，但是独立思考和编码能力也不能被它带走。此为记。

话接上篇，当大流量进来时需要开多线程还是多进程来并行计算呢，当然对于运行在集群上的分布式系统，多进程是必须的，进程里面开多线程也是必然的。

但是多线程里需要怎么分工呢？沿用source - cal - sink 模式，如果这一条线就在一个线程里跑，则可以起n个线程，并行度就是n了，这里cal过程里面又可以细分为很多步骤，如果中间某一步骤，比如groupByKey 比较慢的话，那么每个线程都会被阻塞在这一步，当然可以多起一些线程来解决这个问题，先不说线程能启多少，这样做肯定不是最优的，flink则采取了另外一种办法，将cal流程按算子分解，每个算子都可以运行在单独的线程里，这些线程构成了线程池，每个线程池运行在一个槽里面。这样就可以把执行慢的步骤多开几个线程来执行，执行快的算子就不用那么多线程来执行，这样能更好地利用计算资源。对于可以连续计算的算子，还将它们放在了一个线程中执行，这样来减少线程切换、序列化反序列化的开销。

前面说到肯定是要用多进程的，若是source-cal-sink在同一个线程中的话，只需要一类进程就好了，但是flink将cal步骤划分成可以在线程中单独执行的部分，那么肯定就需要一个角色来执行这个切分的任务了，这个切分任务的角色就是JobManager了。flink中这些被切分好的任务就叫做task，至于这个切分的过程后续再细说。

除了在同一个进程中开多线程来处理数据，也在不同节点起多个进程来执行任务，在不同的任务（线程）间的数据传输也是需要考虑的，既然是流处理，来一条处理一条，那么就没必要使用netty了，akka模型就可以搞定。然后再用分布式阻塞队列作为数据收发载体，就可以提供任务间的反压能力了（讲到这里就想到了spark streaming的反压机制，毕竟自动化出身，看到PID算法就鸡冻，spark streaming在接受数据时，利用任务的结束时间、处理时长和处理条数根据PID算法算出的速率来控制数据接受速度）。

除了像流水一样的数据来一条处理一条外，还回碰到一种需求就是统计一下过去某段时间里的某某指标值，这需要怎么做呢。如果是自己开发的话，像我这样的代码能力估计只能是继续码代码了，用一个func再设置一个开关，传入时间周期值和需要的统计量，这样做的问题是某个时间周期和某个指标值这两个需求都是比较宽泛的，如果再稍微改一下，比如，每天某一个时间点统计等等，这样每次改动都要改动很多代码，显然比较挫。flink用一个窗口就解决了这个问题，elegant。而且窗口也分滑动和滚动窗口以及会话窗口，再结合时间类型就搞定了这个需求，甚至连在时间上乱序进入flink的数据流对统计造成影响的问题都用watermark解决了。

大数据计算时无法避开的就是数据倾斜，从mr到spark再到flink都是不怕量大，就怕倾斜。倾斜一般是两种情况导致，一是业务上的热点key，比如北上广的订单量远大于西部地区，这种情况可以用加盐打散的方式处理，先打散再聚集的两阶段聚合。一种是技术上选择了不恰当的key来做keyBy/groupBy的操作，这种情况可以用随机分片的方式二次聚合来解决，如统计pv

select date,
       type,
       sum(pv) as pv
from(
  select
        date,
        type,
        sum(count) as pv
  from table
        group by
        date,
        type,
        floor(rand()*100) --随机打散成100份 
    )
    group by 
    date,
    type;

对于flink而言，常用的是kafka作为数据source，这样上下游不一致的话也容易造成数据倾斜，flink提供了多种重分区策略，可以用来实现全局负载均衡。

07 /