darkness0604的博客

背景其实，以前编写flink代码的时候，模式比较固定，不管你中间过程如何花里胡哨，开头总要有一个获取上下文环境，最后总要有一个：env.execute()，之前只是知道这个方法，会在job提交的时候，用于获取job的计算流程图，但是我一直很好奇，到底是什么时机生成的呢？源码剖析创建JobGraph我们知道，提交任务的时候，是要有一步获取Job的JobGraph的： /** * Creates a {@link JobGraph} with a specified {@link Job

前言背景在公司里做实时计算开发,之前大部分job都采用的是基于java的streaming编程方式进行的,这样的好处很明显:足够灵活,可以应对各种复杂的实时分析场景,但缺点也很明显:上手存在门槛,需要懂code,如果是一个逻辑简单的计算需求,用code整体编写起来的方式,会让整个流程也略显笨重…于是我开始想,目前的公司流式开发的流程也趋于稳定了,而对于后续接近来的需求,如果可以用SQL解决,就尽可能用SQL解决,这样无论是从开发成本或者是未来如果版本升级造成的迁移成本都会有一个明显的降低。而如果单纯通

背景最近接到一个需求，算是一个比较常见的需求，我们公司的业务会涉及到直播，因此直播自然避免不了高并发的房间内发消息，因此业务端给出的需求就是：实时得为业务端提供近10s内的每个房间的消息总数TOP20， 业务端会根据TOP前几进行相应的限流的一系列操作。思考其实接到这个需求，我的思考实现方式是这样的：1、先求出每个房间的近10s的消息总数2、将第一步得到的每个房间的近10s的消息总数进行汇总，排序，从而得出最终结果： 近10s内，消息数TOP10的房间是哪些可以看到上面的每一步，都对应一个时间范

背景公司内的flink集群跑了挺长一段时间了，一直也没有对其进行一个比较完整的监控，最近打算着手做这件事情，经过网上的调研，目前公司采用的部署模式是per-job模式，最终选用了基于prometheus，把job指标推送到中间网关的pushgateway上面，然后prometheus去抓取pushgateway上面的信息，从而实现对flink做性能监控，最后通过Grafana进行展示。问题在接入过程中，发现了一个问题： 我感觉prometheus的机制有点蠢！！！为啥这么说？pushgateway

java中的lambda可以序列化吗？这个问题之前一直也没想过，其实主要也是之前从来没有遇到过需要序列化它的情景，直到。。。我在开发flink作业的时候，因为一些需求，需要传入一个自定义的过滤器，而自然而然就直接使用这种lambda写一通函数式编程又爽又好用，但启动后确是：直接一手序列化报错给我整懵逼了， 恩？ 原来lambda是不能序列化的吗，一般来说，一个普通的实体类，只需要给类实现一个Serializable的接口标明，就可以参与序列化了，但这种lambda怎么给接口呀？但是我脑海中突然闪