问题一：flinkcdc 社区的钉钉群满了。还有其他的可以加入吗谢谢
如题。想进入学习一下
参考答案：
可以考虑加入Flink CDC社区的其他在线交流平台。以下是一些建议：
- GitHub：Flink CDC项目在GitHub上有官方的仓库，您可以通过关注该项目来获取最新的动态和参与讨论。同时，也可以在GitHub上找到相关的Issue讨论和Pull Request，这是与社区成员交流技术问题的好方式。
- 邮件列表：很多开源项目都会有邮件列表，用于发布通知和讨论技术问题。您可以订阅Flink CDC的邮件列表，这样可以及时收到社区的最新信息。
- 论坛：一些技术论坛可能会有Flink CDC的讨论区或者专栏，您可以在这些论坛上提问和分享经验。
- 技术博客和文章：关注那些专注于Flink CDC的技术博客和文章，通常作者会在文章中提供联系方式或留言板块，供读者提问和交流。
- 社交媒体：在LinkedIn、Twitter等社交媒体上关注Flink CDC社区的官方账号，这些平台有时会发布关于社区活动的信息。
- 技术会议和Meetup：参加与Flink CDC相关的技术会议、Meetup活动，这些活动是与社区成员面对面交流的好机会。
- 官方网站和资源：访问Flink CDC的官方网站，查看是否有其他资源或者指引可以帮助您更好地了解和使用Flink CDC。
总之，通过上述途径，您应该能够找到适合您学习和交流的平台。同时，保持对社区动态的关注，也许未来会有新的钉钉群开放。
关于本问题的更多回答可点击进行查看：
https://developer.aliyun.com/ask/602428
问题二：flinkcdc3.0是否支持全量的checkpoint？
flinkcdc3.0是否支持全量的checkpoint？
参考答案：
支持的。
关于本问题的更多回答可点击进行查看：
https://developer.aliyun.com/ask/602312
问题三：Flink这种场景中的，第四步将 状态存储从内存换成rockdbs之后，还能扛得住吗？
第一层1个 flink sql 任务是将所有跟订单id有关的业务表 进行 10s的窗口去重获取到订单id； 第二层7个 flink sql任务，根据订单id分别查询对应的表，获取到宽表所需要的对应字段，分别发往下游的kafka中，第三层1个 flink sql任务，都是消费上面的kafka, 分别对7种主题的订单数据进行row_number()获取对应的 最新的订单主题数据，然后group by打宽到订单维度的 大宽表，将宽表落到clickhosue 并发送到kafka ;第四层 3个flink sql任务，对上游大宽表对应的 kafka消息 的 订单数据进行row_number()获取对应的 最新的订单宽表数据，按照天，周，月进行聚合，聚合表落到clickhouse表； Flink这种场景中的，第四步将 状态存储从内存换成rockdbs之后，还能扛得住吗？
参考答案：
压力会比较大，你用的云产品吗？云上gemini表现会好一些。
关于本问题的更多回答可点击进行查看：
https://developer.aliyun.com/ask/601803
问题四：flink的状态后端用rockdbs性能怎么样？我目前用内存做状态存储，到我状态太大了，上百G了。
flink的状态后端用rockdbs性能怎么样？我目前用内存做状态存储，到我状态太大了，上百G了。
参考答案：
开源默认就是rocksdb，云上是Gemini。
关于本问题的更多回答可点击进行查看：
https://developer.aliyun.com/ask/601802
问题五：在Flink什么是打宽DWD层?
在Flink什么是打宽DWD层?
参考答案：
打宽DWD层是数据仓库设计中的一个概念，在实时计算Flink产品交流群的“里程碑0 demo”文档中，它指的是将原始明细数据表（如orders和orders_pay）通过JOIN操作与维度表（如product_catalog）进行关联，形成一个包含更多业务信息的宽表，即dwd_orders。这个过程能够在一个表中整合多个表的相关信息，便于后续的分析和计算，同时也为减少JOIN操作、提高查询效率在物理层面上做了优化。在本例中，“打宽”是指增加了如order_product_catalog_name等额外维度字段到订单的明细表中，使得该表能够支持更丰富的业务查询和实时指标计算需求。
关于本问题的更多回答可点击进行查看：
