大家好：
我在flink1.12.1上，通过SQL
API测试upsertKafka，使用hdfs保存checkpoint数据，每30分钟进行一次checkpoint。kafka消息key和value均使用json格式。
持续写入300w不同主键的数据，checkpoint大小持续增加，最终生成save point时，大小接近300M。
请问UpsertKafka模式下，state中是否会一直保存所有的key？未被访问的key是否会被清空呢？
大家好：
我在flink1.12.1上，通过SQL
API测试upsertKafka，使用hdfs保存checkpoint数据，每30分钟进行一次checkpoint。kafka消息key和value均使用json格式。
持续写入300w不同主键的数据，checkpoint大小持续增加，最终生成save point时，大小接近300M。
请问UpsertKafka模式下，state中是否会一直保存所有的key？未被访问的key是否会被清空呢？
实时数仓落地建议先动手做一两个场景真实应用起来，见过好几个项目一开始目标定得过大，实时数仓、流批一体、数据管控啥的都规划进去，结果项目陷入无尽的扯皮，架构设计也如空中楼阁。
实践过程中不要太过于向已有数仓分层模型靠拢，从源系统直接拼接宽表到dws层就足以应付大部分需求了。下游应用再用MPP来满足业务层的实时聚合、BI需求。
等立了几个烟囱，自己项目的实时数仓怎么做也基本有了思路
维表更新后要刷新历史的事实表吗？这个用flink来做的话，几乎不太可能实现，尤其是涉及到多个维表，相当于每次维表又更新了，就要从整个历史数据里面找到关联的数据，重新写入。不管是状态存储，还是更新数据量，需要的资源都太高，无法处理。
在我们目前的实时宽表应用里面，实时表部分一般都是流水类的，取到的维表信息，就应该是业务事实发生时的数据。
维表更新后刷新事实的，一般都是夜间批量再更新。如果有强实时更新需求的，只能在查询时再关联维表取最新值
王旭 于2024年6月16日周日 21:20写道：
> 互相交流哈，我们也在做类似的改造
> 1.不确定需要关联几张维表的话，是否可以直接都关联了，然后
lookup join可以关联多张维表，但是维表的更新不会触发历史数据刷新。
多维表关联的时候，需要考虑多次关联导致的延迟，以及查询tps对维表数据库的压力。
斗鱼 <1227581...@qq.com.invalid> 于2024年6月19日周三 23:12写道：
> 好的，感谢大佬的回复，之前有了解到Flink的Lookup join好像可以实现类似逻辑，只是不知道Lookup join会不会支持多张动态维度表呢？
>
>
> 斗鱼
> 1227581...@qq.com
>
>
>
>
>
>
>
>
> -- 原始邮件
flink在写入时需要所有DDL中定义的字段都必须被同时写入，不支持sql中只使用部分字段。
如果你确定只需写入部分数据，在DDL中只定义你用到的部分
zboyu0104 于2024年6月14日周五 15:43写道：
> 怎么退订
> from 阿里邮箱
> iPhone--
> 发件人：谢县东
> 日 期：2024年06月06日 16:07:05
> 收件人：
> 主 题：使用hbase连接器插入数据，一个列族下有多列时如何只更新其中一列
>
> 各位好：
通过yarn提交时，提交成功后，yarn client会返回 application master的地址和端口，从返回信息里面获取就可以
wjw_bigdata 于2024年8月1日周四 14:24写道：
> 退订
>
>
>
>
>
>
> 回复的原邮件
> | 发件人 | Lei Wang |
> | 发送日期 | 2024年8月1日 14:08 |
> | 收件人 | |
> | 主题 | Re: flink on yarn 模式，在jar任务中，怎么获取rest port |
> 在 flink-conf.yaml 中可以指定 rest.port， 可指定
修改下游的sink connector，在execute的时候把-D、-U的record去掉
Flink：1.12.1
Flink-connector： 2.2
Hbase： 2.1.0 + CDH6.3.2
现象：如果hbase列族设置了TTL，当某一rowkey写入数据，到达过期时间，列族会被hbase标记为删除。
后续如果有相同key的数据过来，flink无法将数据写入到hbase中，查询hbase中列族一直为空。
执行的过程大致如下：
创建Hbase表，test, 两个列族 cf1 , TTL 60, cf2, TTL 120，
数据TTL分别为1分钟，2分钟。
使用sql写入数据至表中
insert into test
select
'rowkey',
ROW('123
FLink：1.12.1
源： kafka
create table dev_log (
devid,
ip,
op_ts
) with (
connector = kafka
)
sink： Hbase connect 2.2
目前用flink sql的hop window开发一个指标，统计近24小时的设备关联ip数。设置30min一次checkpoint，超时时间30min。
执行SQL如下
insert into h_table
select
devid as rowkey
row(hop_end, ip_cnt)
from (
select
devid,
cp 被 back
> pressure 也有可能导致 cp 超时。开启 mini batch 可以加快 window 的运算速度，但这么长时间而且这么频繁的 window
> 目前确实没有什么很好的优化方法，仍然建议扩大并发以分担计算以及 cp 的压力。
>
> xiaohui zhang 于2021年9月18日周六 上午9:54写道：
>
> > FLink：1.12.1
> >
> > 源： kafka
> > create table dev_log (
> > devid,
> > ip,
>
* Fink版本： 1.16
* 部署：docker集群， 2个jm，3个tm高可用
* HADOOP： CDP7集群，启用kerberos
* Flink配置：在conf/fink-conf.yml中添加security相关参数
security.kerberos.login.use-ticket-cache: true
security.kerberos.login.keytab: /opt/flink/flink.keytab
security.kerberos.login.principal: *fl...@hadoop.com *
* 现象：
flink集群可以
这种join写法会随时更新里面每一个字段，最终产出结果的业务含义是什么呢？
如果是取每个vehicle_code对应的最新统计指标值，是否可以用支持partial update的存储，用多个单独的sql直接写入目前就可以了
周先明 于2023年8月4日周五 11:01写道：
> Regular Join 默认把数据都存储在State中，通常会结合TTL来进行优化
>
> guanyq 于2023年8月3日周四 15:59写道：
>
> > 请问下多个表关联，这种flink sql如何优化呢，直接关联优点跑不动RuntimeExecutionMode.STREAMING 模式
> >
13 matches
Mail list logo
