gin has it's own class loader. The reason behind that is
> to avoid dependency collision with Flink's main class loader.
>
> I think if the mentioned change works when it's added as normal lib and
> not as a plugin then the code can be merged to main as-is.
>
> G
>
>
>
deps with conflicting services or add
> ServicesResourceTransformer
> to your maven project.
>
> G
>
>
> On Wed, Jun 26, 2024 at 10:16 AM Xiao Xu wrote:
>
>> Hi, all
>>
>> I try to use Flink to write Azure Blob Storage which called ADLS, I put
Hi, all
I try to use Flink to write Azure Blob Storage which called ADLS, I put the
flink-azure-fs-hadoop jar in plugins directory and when I start my write
job it shows:
Caused by: org.apache.hadoop.fs.UnsupportedFileSystemException: No
FileSystem for scheme "file"
at
flink 是不会保留数据的, 数据都是落盘在 kafka 里, flink 根据 offset 去读 kafka 里的数据, 可以设置 kafka
里留存的时间
marble.zh...@coinflex.com.INVALID
于2020年10月14日周三 下午4:37写道：
> 你好， 用kafka table
>
> connector接过来的数据，在flink这边会保留多久，在参数列表里没有看到有这个设置，如果保留太久，内存会撑暴，比如我只想保留半个小时，之前的数据可以清除。
>
>
>
> --
> Sent from:
建议先确认下瓶颈是不是 kafka sink, 一般来说 kafka 网卡打满都不会到瓶颈的, 猜测有可能其他逻辑导致的瓶颈
hailongwang <18868816...@163.com> 于2020年10月13日周二 下午10:22写道：
>
>
> Hi xyq，
> 1. 可以确认下下游 kakfa 6个分区写入数据量都是均匀的吗，看下 Partitioner 有没有设置好。
> 2. 还有 11000 条的数据量大小有多少呢，有没有存在 flink 集群 与 kafka 集群
> 跨机房的限制。（在我们内部多个机房，其中延迟比较大的机房的速率只有 3M/s 单并发）
>
plan visualizer 应该是 stream graph, 不是一个图吧
Paul Lam 于2020年10月13日周二 下午9:23写道：
> Hi,
>
> 可以利用 Flink 的 plan visualizer，见[1]
>
> 1.
>
> https://ci.apache.org/projects/flink/flink-docs-stable/dev/execution_plans.html
>
> Best,
> Paul Lam
>
> hailongwang <18868816...@163.com> 于2020年10月12日周一 下午11:38写道：
Hi, 据我所知没有限流的功能，最简单的是设置下任务的并行度
me 于 2020年9月27日周日 下午5:45写道：
> flink版本1.11
> flink连接kafka使用的是 flink addSource特性
>
>
> 原始邮件
> 发件人: me
> 收件人: user-zh
> 发送时间: 2020年9月27日(周日) 17:22
> 主题: 当kafka有大量数据积压并且flink冷启动，flink端读取kafka有没有限流的参数？
>
>
> 当kafka有大量数据积压并且flink冷启动，flink端读取kafka有没有限流的参数？
>
直接扣命令行里提交任务的代码,
https://ci.apache.org/projects/flink/flink-docs-stable/ops/cli.html, 这边都是
java 实现的, 转到 spring boot 没啥难度
xiao cai 于2020年9月25日周五 下午5:28写道：
> Hi zilong:
>
> 这种方式我考虑过，个人认为平台层面如果有业务逻辑的侵入，会影响后续的升级。所以我们是在标注输出中正则匹配出jobId和applicationId。你了解YarnClusterDescripto吗？之前社区看到有人用这个提交的。
>
>
> 原始邮件
两个方法
1. kafka 里面可以 keyby, partition 里面都是有序的, 所以每个用户处理都是有序的
2. 就是你说的在 flink 里面做乱序处理
宁吉浩 于2020年9月4日周五 下午5:56写道：
> 我也遇到了和你一样的问题，也是两条数据有因果关系，必须有严格的先后顺序，我这边的业务不像银行那么严格；
> 我的解决办法是把迟到数据丢弃，然后进行业务计算；
> 另起一个程序把数据缓存在内存里，对数据排序，然后再度修正计算；
> 之前的实时+离线数仓用的办法，代码开发一次，但还要跑两次；
>
>
>
accumulator 是聚合后的指标, metics 里是底层的指标, 据我所知没有办法打到监控里面
Yun Tang 于2020年8月28日周五 下午2:37写道：
> Hi
>
> 没有名为 accumulator 的metrics类型数据，目前只有Counters, Gauges, Histograms 和 Meters
> [1] 这四种，如果你想要用累积型metrics，可以考虑counters
>
> [1]
>
10 matches
Mail list logo
