写代码的阿甘_个人页

个人头像照片 写代码的阿甘
个人头像照片 个人头像照片
1
5
0

个人介绍

求知若饥 虚心若愚

擅长的技术

  • Java
  • flink
  • spark
  • SQL
获得更多能力
通用技术能力:
  • Java
    高级

    能力说明:

    精通JVM运行机制,包括类生命、内存模型、垃圾回收及JVM常见参数;能够熟练使用Runnable接口创建线程和使用ExecutorService并发执行任务、识别潜在的死锁线程问题;能够使用Synchronized关键字和atomic包控制线程的执行顺序,使用并行Fork/Join框架;能过开发使用原始版本函数式接口的代码。

    获取记录:

云产品技术能力:

暂时未有相关云产品技术能力~

阿里云技能认证

详细说明
暂无更多信息

2020年12月

  • 发表了文章 2020-12-03

    Flink 旁路输出(分流)

正在加载, 请稍后...
滑动查看更多
  • 回答了问题 2020-12-10

    flink key by 的粒度问题 ,key by 是否可以带业务 ?

    天啦,都没有大神来回答我吗!!!
    踩0 评论0
  • 提交了问题 2020-12-07

    flink key by 的粒度问题 ,key by 是否可以带业务 ?

  • 回答了问题 2020-12-07

    订单实时数据统计解决方案

    flink 消费 你们的kafka 来计算
    踩0 评论0
  • 回答了问题 2020-12-04

    flink 失败重启前提是必须开启checkpoint?#Flink

    是的, flink 失败重启是 内部恢复到 上一个 成功的 快照(checkpoint ), 当 task manager 因为运行时间很久或者 一些 网络波动挂掉之后,job manager 就会 根据上一次 checkpoint 进行恢复,这里 就有 exactly once 和 at least once 的区别, 前者flink在进行 checkpoint的时候就会 对齐 barrier ,比起后者是效率要低一些。 后者 效率高一些,但是需要 自己的 flink sink 的存储来做 幂等。
    踩0 评论0
  • 回答了问题 2020-12-03

    Flink keyby问题

    我们生产的时候,按照 业务 逻辑 比如 电商 店铺 进行key by 之后,进行 窗口 process 计算,我们发现 key by 的维度越细,任务就越不稳定,并且我们发现 每个 key 都有属于自己的process context ,这里就会造成很大的 flink 内部的内存占用,以及效率问题。 key by 的 逻辑很重要,尤其是 有使用状态后端 的场景 。 所以个人认为 key by 的列 最好是根据你 的任务的 并行度来进行设计 ,key by 的作用应该是对数据进行路由操作, 将数据均匀的发往 下游的 operator , 粒度不能太细,容易造成上面的问题,也不能太粗,容易数据倾斜。
    踩0 评论0
正在加载, 请稍后...
滑动查看更多
正在加载, 请稍后...
暂无更多信息