1、 maven大包涉及到长期的工程维护问题
现在官网提供的maven打包方式，直接把第三方包解开后按照目录方式存放
而不是维持maven depend on的标准的jar包方式（带版本）
现在这种方式不利于软件的项目长期管理，项目长期累月运行后，
随着人员变化以及版本升级，会带来很多版本兼容和识别的工程问题
期望flink在1.10.0的后续版本改进该问题，可能需要更改运行时的classloader
2、 维度数据通过RichXXXFunction的open重复加载，浪费存储空间的问题
假设启动一个任务并行度是1K，假设平均分配到10台计算主机计
应该是不会的。分配不到partition的source会标记为idle状态。
Sun.Zhu <17626017...@163.com> 于2020年4月20日周一 上午10:28写道：
> Hi,benchao，source并发度大于partition数的话，会导致不做checkpoint的问题吧
>
>
>
>
> | |
> Sun.Zhu
> |
> |
> 邮箱：17626017...@163.com
> |
>
> Signature is customized by Netease Mail Master
>
> 在2020年04月19日 22:43，人生若只如初见 写道：
Hi Kurt,
谢谢， 我了解过后如果有问题再请教
Best
Eleanore
On Sun, Apr 19, 2020 at 7:18 PM Kurt Young wrote:
> 可以看下这个jira：https://issues.apache.org/jira/browse/FLINK-14807
>
> Best,
> Kurt
>
>
> On Mon, Apr 20, 2020 at 7:07 AM Eleanore Jin
> wrote:
>
> > Hi，
> > 刚刚读到一篇关于Flink 在OLAP 上的使用案例 （
> >
> https://verve
Hi,benchao??source??partition??checkpoint
| |
Sun.Zhu
|
|
??17626017...@163.com
|
Signature is customized by Netease Mail Master
??2020??04??19?? 22:43 ??
??
-- --
??: "Bench
可以看下这个jira：https://issues.apache.org/jira/browse/FLINK-14807
Best,
Kurt
On Mon, Apr 20, 2020 at 7:07 AM Eleanore Jin wrote:
> Hi，
> 刚刚读到一篇关于Flink 在OLAP 上的使用案例 （
> https://ververica.cn/developers/olap-engine-performance-optimization-and-application-cases/），
> 其中一点提到了:
> [image: image.png]
> 这部分
Hi，
刚刚读到一篇关于Flink 在OLAP 上的使用案例 （
https://ververica.cn/developers/olap-engine-performance-optimization-and-application-cases/），
其中一点提到了:
[image: image.png]
这部分优化，源于 OLAP 的一个特性：OLAP 会将最终计算结果发给客户端，通过JobManager 转发给 Client。
想请问一下这一点是如何实现的： 通过JobManager 把结果转发给Client.
谢谢！
Eleanore
Hello~ 想再确认一下预期的行为：现在是希望后面重新写之后，用新写过的part-xx来覆盖之前生成的文件么~？
--
From:酷酷的浑蛋
Send Time:2020 Apr. 18 (Sat.) 20:32
To:user-zh
Subject:关于StreamingFileSink
我在用StreamingFileSink
往hdfs写数据的时候，如果任务停止了，从前面的某个checkpoint启动（不是最新checkpoint
hi，tison,jiacheng感谢解答，按照你说的又仔细看了一遍，确实如此，在实例化MailboxProcessor有把processInput当做参数传进去，在MailboxProcessor#runMailboxLoop中会去执行defaultAction方法
while (processMail(localMailbox)) {
mailboxDefaultAction.runDefaultAction(defaultActionContext); // lock is
acquired inside default action as needed
}
再次感谢
Best
??
-- --
??: "Benchao Li"
如果是这种情况，可以让你的source的并发度大于等于kafka partition的数量来避免一下。
Jark Wu 于2020年4月19日周日 下午8:22写道：
> Hi,
>
> 根据你描述的现象，以及提供的代码。我觉得原因应该是数据乱序导致的。
> 根据你的 Java 代码，数据的 event time 不是单调递增的，会有一定程度的乱序，这种乱序在作业正常运行时影响不大（watermark
> 能容忍 5s 乱序）.
> 但是在追数据时，由于 flink 目前还没有做到event time 对齐，所以会导致追数据时某些 partition 进度比某些 partition
>
??MailboxProcessorstreamtask??processInputMailboxDefaultAction??MailboxProcessorInputStatus
status =
inputProcessor.processInput();inputProcessor??StreamOneInputProcessor??InputStatus
status =
input.emitNext(output);input??StreamTaskNetwor
Hi,
根据你描述的现象，以及提供的代码。我觉得原因应该是数据乱序导致的。
根据你的 Java 代码，数据的 event time 不是单调递增的，会有一定程度的乱序，这种乱序在作业正常运行时影响不大（watermark
能容忍 5s 乱序）.
但是在追数据时，由于 flink 目前还没有做到event time 对齐，所以会导致追数据时某些 partition 进度比某些 partition
进度快很多的现象，
导致乱序程度拉大（如原先迟到最久的数据时4s，现在可能是10s），所以会导致丢弃的数据更多，也就造成了追数据时，统计值偏低的现象。
完美的解决方案还需要等 FLIP-27 的完
invokable 一般是 StreamTask 或者它的子类 StreamSourceTask，具体的 UDF 在 StreamTask
里，有几层包装。
MailBox 那些其实是一个简单的 EventLoop 实现，或者你理解为 Actor Model 的实现也行，可以参考这些名词的解释文章一一对应。
Best,
tison.
祝尚 <17626017...@163.com> 于2020年4月19日周日 下午5:43写道：
> Hi，all
> 在阅读1.10有关job执行过程相关源码时遇到一些疑问，我在看到Task#doRun()方法
> invokable.invoke(
Hi，all
在阅读1.10有关job执行过程相关源码时遇到一些疑问，我在看到Task#doRun()方法
invokable.invoke();具体执行过程应该在这个方法里吧？
进一步看了StreamTask#invoke()->runMailboxLoop();继续往下深入也没发现最终调用udf的入口
问题1：MailboxProcessor、Mailbox、Mail这些概念什么意思，什么作用？
然而在另一处实例化AbstractInvokable时，比如StreamTask构造函数里会调用processInput方法，这个就类似1.9之前的实现方式了
this.mailboxProc
14 matches
Mail list logo
