Re:flink sql

2023-03-02 文章 17610775726 
Hi



可以通过设置 pipeline.operator-chaining = false 来实现。


Best
JasonLee


 Replied Message 
| From | 小昌同学 |
| Date | 03/3/2023 15:50 |
| To | user-zh |
| Subject | flink sql |
各位大佬，请教一下如何使用flink sql实现DataStreaming的disableOperatorChaining功能


| |
小昌同学
|
|
ccc0606fight...@163.com
|

flink sql

2023-03-02 文章 小昌同学 
各位大佬，请教一下如何使用flink sql实现DataStreaming的disableOperatorChaining功能


| |
小昌同学
|
|
ccc0606fight...@163.com
|

回复： Flink内存问题

2023-03-02 文章 吴先生 
感谢，我看下


| |
吴先生
|
|
15951914...@163.com
|
 回复的原邮件 
| 发件人 | Weihua Hu |
| 发送日期 | 2023年3月3日 10:37 |
| 收件人 |  |
| 主题 | Re: Flink内存问题 |
Hi,

针对问题 2， 可以增加下列环境变量来排除 Glibc 的问题，详情可以参考[1]

containerized.master.env.MALLOC_ARENA_MAX: 1

containerized.taskmanager.env.MALLOC_ARENA_MAX: 1

[1]
https://nightlies.apache.org/flink/flink-docs-master/docs/deployment/memory/mem_trouble/

Best,
Weihua


On Thu, Mar 2, 2023 at 8:10 PM 吴先生 <15951914...@163.com> wrote:

Hi,
目前分析问题应该在堆外，大概率是managed和overhead这两部分，这两部分的内存分配比例都是默认配置，通过网上的相关资料来看有两种解决方案：
1、调大managed和overhead这两块的内存比例，
问题：调整多大合适？是否调整之后还会持续增长
2、还有另一种说法是glibc内存分配器有个64M的问题引起（这里可有深入研究），替换为jemalloc可避免
问题：有具体的知道方案吗


| |
吴先生
|
|
15951914...@163.com
|
 回复的原邮件 
| 发件人 | Shammon FY |
| 发送日期 | 2023年3月2日 19:24 |
| 收件人 |  |
| 主题 | Re: Flink内存问题 |
Hi


如果有搜集metrics，可以根据metrics查看一下是哪部分内存上涨导致container被kill掉；然后将上涨比较快的container内存dump一下，查看具体是哪些对象占用内存比较多

Best,
Shammon


On Thu, Mar 2, 2023 at 7:14 PM 吴先生 <15951914...@163.com> wrote:

Hi，
Flink版本：1.12
部署模式：on yarn per-job
开发方式：DataStream Api
状态后端：RocksDB
Job逻辑为一个15分钟的窗口计算，任务在运行一段时间后会出现内存使用超限，container被yarn
kill的现象，目前有不少任务都会存在类似问题：
Closing TaskExecutor connection container_e02_1654567136606_1034_01_12
because: [2023-03-02 08:12:44.794]Container
[pid=11455,containerID=container_e02_1654567136606_1034_01_12] is
running 745472B beyond the 'PHYSICAL' memory limit. Current usage: 8.0 GB
of 8 GB physical memory used; 10.0 GB of 40 GB virtual memory used. Killing
container.
请问：
该如何排查及优化


| |
吴先生
|
|
15951914...@163.com
|

Re:flink sql jdbc connector是否支持多流拼接？

2023-03-02 文章 程龙 
这种情况下有两种方式可以处理
1>  注册表-使用join方式直接拼接成大宽表写入
2>  每个任务-直接写入下游数据 ，每个任务只更新自己的字段即可(因为主键相同)



















在 2023-03-02 20:59:59，"casel.chen"  写道：
>flink sql jdbc connector是否支持多流拼接？
>业务上存在基于主键打宽场景，即多个流有相同的主键字段，除此之前其他字段没有重叠，现在想打成一张大宽表写入mysql/oracle这些关系数据库。
>每条流更新大宽表的一部分字段。

Re: flink sql接cdc数据源关联维表写入下游数据库发现漏数据

2023-03-02 文章 Shengkai Fang 
听上去像是数据乱序了。可以看看这个文档对应的解决下[1]

[1]
https://nightlies.apache.org/flink/flink-docs-master/docs/dev/table/concepts/determinism/

Best,
Shengkai

casel.chen  于2023年3月1日周三 16:18写道：

> flink sql上游接kafka canal json topic消费mysql同步过来的变更，接着关联几张维表，最后写入下游数据库发现漏数据。
>
> 随后在写目标数据库中加了一些日志后发现同一主键的变更记录(前后发生间隔时间很短）被发送到了不同的TaskManager处理，导致新数据被旧数据覆盖，造成漏数据现象。
> 请问：
> 1. cdc数据源关联维表后会被分散到不同TaskManager吗？什么情况下会发生？
> 2. 如何解决这个问题？是需要在写目标表之前加一层窗口去重[1]吗？
>
>
> [1]
> https://nightlies.apache.org/flink/flink-docs-release-1.15/zh/docs/dev/table/sql/queries/window-deduplication/

Re: Flink内存问题

2023-03-02 文章 Weihua Hu 
Hi,

针对问题 2， 可以增加下列环境变量来排除 Glibc 的问题，详情可以参考[1]

containerized.master.env.MALLOC_ARENA_MAX: 1

containerized.taskmanager.env.MALLOC_ARENA_MAX: 1

[1]
https://nightlies.apache.org/flink/flink-docs-master/docs/deployment/memory/mem_trouble/

Best,
Weihua


On Thu, Mar 2, 2023 at 8:10 PM 吴先生 <15951914...@163.com> wrote:

> Hi,
> 目前分析问题应该在堆外，大概率是managed和overhead这两部分，这两部分的内存分配比例都是默认配置，通过网上的相关资料来看有两种解决方案：
> 1、调大managed和overhead这两块的内存比例，
> 问题：调整多大合适？是否调整之后还会持续增长
> 2、还有另一种说法是glibc内存分配器有个64M的问题引起（这里可有深入研究），替换为jemalloc可避免
> 问题：有具体的知道方案吗
>
>
> | |
> 吴先生
> |
> |
> 15951914...@163.com
> |
>  回复的原邮件 
> | 发件人 | Shammon FY |
> | 发送日期 | 2023年3月2日 19:24 |
> | 收件人 |  |
> | 主题 | Re: Flink内存问题 |
> Hi
>
>
> 如果有搜集metrics，可以根据metrics查看一下是哪部分内存上涨导致container被kill掉；然后将上涨比较快的container内存dump一下，查看具体是哪些对象占用内存比较多
>
> Best,
> Shammon
>
>
> On Thu, Mar 2, 2023 at 7:14 PM 吴先生 <15951914...@163.com> wrote:
>
> Hi，
> Flink版本：1.12
> 部署模式：on yarn per-job
> 开发方式：DataStream Api
> 状态后端：RocksDB
> Job逻辑为一个15分钟的窗口计算，任务在运行一段时间后会出现内存使用超限，container被yarn
> kill的现象，目前有不少任务都会存在类似问题：
> Closing TaskExecutor connection container_e02_1654567136606_1034_01_12
> because: [2023-03-02 08:12:44.794]Container
> [pid=11455,containerID=container_e02_1654567136606_1034_01_12] is
> running 745472B beyond the 'PHYSICAL' memory limit. Current usage: 8.0 GB
> of 8 GB physical memory used; 10.0 GB of 40 GB virtual memory used. Killing
> container.
> 请问：
> 该如何排查及优化
>
>
> | |
> 吴先生
> |
> |
> 15951914...@163.com
> |
>

Re: flink sql jdbc connector是否支持多流拼接？

2023-03-02 文章 Shengkai Fang 
hi. 手动使用 join 将多个流拼接起来？

Best,
Shengkai

casel.chen  于2023年3月2日周四 21:01写道：

> flink sql jdbc connector是否支持多流拼接？
> 业务上存在基于主键打宽场景，即多个流有相同的主键字段，除此之前其他字段没有重叠，现在想打成一张大宽表写入mysql/oracle这些关系数据库。
> 每条流更新大宽表的一部分字段。

Re: 退订

2023-03-02 文章 Vincent Woo 
Hi，退订请发送邮件到 user-zh-unsubscr...@flink.apache.org 



Best,
Vincent Woo

> 2023年3月3日 08:41，zhangjunjie  写道：
> 
> 退订
> 
>

退订

2023-03-02 文章 zhangjunjie 
退订

flink sql jdbc connector是否支持多流拼接？

2023-03-02 文章 casel.chen 
flink sql jdbc connector是否支持多流拼接？
业务上存在基于主键打宽场景，即多个流有相同的主键字段，除此之前其他字段没有重叠，现在想打成一张大宽表写入mysql/oracle这些关系数据库。
每条流更新大宽表的一部分字段。

回复： Flink内存问题

2023-03-02 文章 吴先生 
Hi,
目前分析问题应该在堆外，大概率是managed和overhead这两部分，这两部分的内存分配比例都是默认配置，通过网上的相关资料来看有两种解决方案：
1、调大managed和overhead这两块的内存比例，
问题：调整多大合适？是否调整之后还会持续增长
2、还有另一种说法是glibc内存分配器有个64M的问题引起（这里可有深入研究），替换为jemalloc可避免
问题：有具体的知道方案吗


| |
吴先生
|
|
15951914...@163.com
|
 回复的原邮件 
| 发件人 | Shammon FY |
| 发送日期 | 2023年3月2日 19:24 |
| 收件人 |  |
| 主题 | Re: Flink内存问题 |
Hi

如果有搜集metrics，可以根据metrics查看一下是哪部分内存上涨导致container被kill掉；然后将上涨比较快的container内存dump一下，查看具体是哪些对象占用内存比较多

Best,
Shammon


On Thu, Mar 2, 2023 at 7:14 PM 吴先生 <15951914...@163.com> wrote:

Hi，
Flink版本：1.12
部署模式：on yarn per-job
开发方式：DataStream Api
状态后端：RocksDB
Job逻辑为一个15分钟的窗口计算，任务在运行一段时间后会出现内存使用超限，container被yarn
kill的现象，目前有不少任务都会存在类似问题：
Closing TaskExecutor connection container_e02_1654567136606_1034_01_12
because: [2023-03-02 08:12:44.794]Container
[pid=11455,containerID=container_e02_1654567136606_1034_01_12] is
running 745472B beyond the 'PHYSICAL' memory limit. Current usage: 8.0 GB
of 8 GB physical memory used; 10.0 GB of 40 GB virtual memory used. Killing
container.
请问：
该如何排查及优化


| |
吴先生
|
|
15951914...@163.com
|

Re: Flink内存问题

2023-03-02 文章 Shammon FY 
Hi

如果有搜集metrics，可以根据metrics查看一下是哪部分内存上涨导致container被kill掉；然后将上涨比较快的container内存dump一下，查看具体是哪些对象占用内存比较多

Best,
Shammon


On Thu, Mar 2, 2023 at 7:14 PM 吴先生 <15951914...@163.com> wrote:

> Hi，
> Flink版本：1.12
> 部署模式：on yarn per-job
> 开发方式：DataStream Api
> 状态后端：RocksDB
> Job逻辑为一个15分钟的窗口计算，任务在运行一段时间后会出现内存使用超限，container被yarn
> kill的现象，目前有不少任务都会存在类似问题：
> Closing TaskExecutor connection container_e02_1654567136606_1034_01_12
> because: [2023-03-02 08:12:44.794]Container
> [pid=11455,containerID=container_e02_1654567136606_1034_01_12] is
> running 745472B beyond the 'PHYSICAL' memory limit. Current usage: 8.0 GB
> of 8 GB physical memory used; 10.0 GB of 40 GB virtual memory used. Killing
> container.
> 请问：
> 该如何排查及优化
>
>
> | |
> 吴先生
> |
> |
> 15951914...@163.com
> |

Flink内存问题

2023-03-02 文章 吴先生 
Hi，
Flink版本：1.12
部署模式：on yarn per-job
开发方式：DataStream Api
状态后端：RocksDB
Job逻辑为一个15分钟的窗口计算，任务在运行一段时间后会出现内存使用超限，container被yarn kill的现象，目前有不少任务都会存在类似问题：
Closing TaskExecutor connection container_e02_1654567136606_1034_01_12 
because: [2023-03-02 08:12:44.794]Container 
[pid=11455,containerID=container_e02_1654567136606_1034_01_12] is running 
745472B beyond the 'PHYSICAL' memory limit. Current usage: 8.0 GB of 8 GB 
physical memory used; 10.0 GB of 40 GB virtual memory used. Killing container.
请问：
该如何排查及优化


| |
吴先生
|
|
15951914...@163.com
|