记一次Flink写入文件系统超时的方案协商

语落心生
1,302 阅读4分钟

cosn腾讯云自己封装的sdk

  • 项目的架构
    数据采集分发系统
    上游解析mysql的数据，采集到中继kafka 从中继kafka分发到下游kafka以及入cosn
    分发程序和入库程序都是flink任务

cosn架构图.jpg

  • 事情经过 当我们的每个分块文件上传到cgi后端的时候 可不可以做下慢调用降级呢 一旦cosn分块文件上传失败,异常会在TaskManager中抛出上传失败的异常 直到连接保持的时间过期

  • StreamingFileSink的底层原理是什么

    简介: flink 1.12 doc : ci.apache.org/projects/fl…

    • Flink流式写入文件系统，有两个方式BucketingSink以及StreamingFileSink。 迭代历史: StreamingFileSink是在BucketingSink之后推出的。 主要区别在StreamingFileSink可以用于故障恢复， 保证exactly-once，但是要求hadoop版本必须在2.7以上， 因为用到了hdfs的truncate方法。

    我们按照小时级别写入cosn的bucket

    • 写入数据流程
    1.使用FSDataOutputStream将数据写入缓冲区，放在内存中
2.每次做checkpoint的时候，会flush缓存区的数据，以及将pending
(已经完成的文件，但未被checkpoint记录，
可以通过sink,setPedningSuffix)结尾的文件，记录下来
3.每60s可以通过InactiveBucketCheckInterval去设置检测
    - 1.如果一个文件的FSDataOutputStream在60秒内
(可以通过sink.setInactiveBucketThreshold(60 * 1000L);去设置)，
都没有接受的数据，就会被认为是不活跃的bucket（可以认为是文件），
那么就会flush然后关闭该文件。
    - 2.在processingTimeServie中注册了当前时间 + 
 inactiveBucketCheckInterval
（60秒不写入时间），
    - 3. onProcessingTime方法去时时刻刻的判断是否满足60秒不写入

4..flink内部封装了一个
Map<String, BucketState<T>> bucketStates = new HashMap<>();  
用来记录当前正在使用的文件，key是文件的路径，
BucketState内部封装了该文件的所有信息:
- 创建时间，
- 最后一次写入时间(这里的写入指的是写入缓存区的时间，不是flush的时间)
- 文件大小
- 当前文件是打开还是关闭
- 写缓冲区的方法
5.每次flink要对文件进行操作的时候，都会从这里拿到文件的封装对象
当程序被cancel的时候，当前正在操作的文件，
会被flush，关闭。然后将文件的后缀名从in-progress改为pending。
这个前后缀都能设置，但如果没有什么特殊需求，默认即可。
这里拿文件，即第四步的bucketStates这个map。
它在close方法中，会去遍历这个map，去做上述的操作。
    • 腾讯云cosn团队建议我们使用最新的版本 配置一个经验值来写入cosn的等待时间更长

    但是因为之前做后端的原因 觉得是否应该参考sentinel设置一个合理的慢调用临界RT,让我们自己来预估流量高峰，并配置RT呢？

    讨论如下:

2021-05-02-01.jpg

mmexport1624673203113.jpg

cosn团队反馈:

cos相关的背景及关系：
cos sdk封装http接口，hadoop cos（cosn）封装cos api提供hadoop 文件系统接口。
hadoopcos会针对上层http 返回码进行http接口层的重试。
cos sdk则会针对所有httpclient io异常（网络异常）进行内部重试。

现象：
也就是说cosn分块上传（一次api调用）失败后会进行重试直到重试次数耗尽才会向上层抛出异常（指数退避重试）。
在后端正常的情况下：信令类的请求秒级内都能保证，数据流部分的请求跟网络质量相关。

结论：
这个RT的无非是重试策略的问题，在分钟级网络波动的情况下跟重试效果是一样的，
而且数据流方面tcp已经有拥塞控制慢启动等措施了。
当然了如果网络长期不稳定那重试和RT都不是解决问题的根本方法

短时间内效果应该是一样的。
而且都是流式的上传和下载，他可能响应的很快但传的很慢，
感觉RT这种策略可能不适合数据流式的重试。

我:

响应很快传的很慢是指

对于传统后端上传下载而言
1.这边一个分块文件对应一个线程，分块文件的后缀以线程名结尾 
2.下次线程开始执行的时候去找对应后缀的分块文件。这之间会有一个时间间隔是么

对于流式数据上传下载而言
1.他可能涉及到checkpoint的检查点线程切换。所以会出现task线程和checkpoint线程之间的切换，所造成的传输延迟对么

cosn团队

响应指建立连接或第一次传输数据，传输则指建立连接后的传输数据（分多次send）
至于上层用多少个线程按什么策略传都是上层的玩法，当然目的肯定是尽可能的利用资源增加吞吐。

Continue...QwQ

avatar
文章
阅读
粉丝