Apache Flink China是经过Apache Flink官方授权的中文社区。是旨在向国内宣传和普及Flink相关技术,输出技术博文、译作、资讯等内容,推动国内大数据技术发展的开源社区。
7 月 6 日,Apache Flink Meetup 再度回归魔都,来自阿里巴巴、网易的 Flink 技术专家联合 Apache RocketMQ 社区大咖来一场 Flink 与 RocketMQ 的邂逅,看看 Apache RocketMQ × Apache Flink 会碰撞出怎样的火花。
本文翻译自 streaml.io 网站上的一篇博文:“Exactly once is NOT exactly the same” ,分析了流计算系统中常说的『Exactly Once』特性,主要观点是:『精确一次』并不保证是完全一样。
1. Apache Flink 应用程序中的 Exactly-Once 语义 2. Flink 应用程序端到端的 Exactly-Once 语义 3. 示例 Flink 应用程序启动预提交阶段 4. 在 Flink 中实现两阶段提交 Operator 5. 总结
本文将为大家介绍 Apache Flink 在爱奇艺的生产与实践过程。你可以借此了解到爱奇艺引入 Apache Flink 的背景与挑战,以及平台构建化流程。
为了让大家更全面地了解 Apache Flink 背后的技术以及应用实践,今天,我们首次免费公开 Apache Flink 系列视频课程。
> 作者:晨笙、缘桥 菜鸟供应链业务链路长、节点多、实体多,使得技术团队在建设供应链实时数仓的过程中,面临着诸多挑战,如:如何实现实时变Key统计?如何实现实时超时统计?如何进行有效地资源优化?如何提升多实时流关联效率?如何提升实时作业的开发效率? 而 Blink 能否解决这些问题?下面一起来深入了解。 ## 背景 菜鸟从2017年4月开始探索 Blink(即 Apache
Apache Flink Community China Meetup,关于大数据、实时计算、流计算、批处理等。邀请到Apache Flink PMC和Airbnb、阿里巴巴多位 Apache Flink Committer 现场分享。
本文整理自 2019 年 4 月 13 日在深圳举行的 Flink Meetup 会议,分享嘉宾张俊,目前担任 OPPO 大数据平台研发负责人,也是 Apache Flink contributor。
本文整理自 Flink 创始公司 Ververica 联合创始人兼 CTO - Stephan 在 Flink Forward China 2018 上的演讲《Stream Processing takes on Everything》。
本文根据AI前线在12月20日 Flink Forward China 峰会上对阿里巴巴计算平台事业部研究员蒋晓伟(花名量仔)进行的独家专访整理。 > 今年,实时流计算技术开始步入主流,各大厂都在不遗余力地试用新的流计算框架,实时流计算引擎和 API 诸如 Spark Streaming、Kafka Streaming、Beam 和 Flink 持续火爆。阿里巴巴自 2015 年开始改进
12月20日,北京国家会议中心。Flink Forward China 2018 强势来袭~
Apache Flink China Meetup北京站来啦~
为进一步提升Apache Flink在国内的技术影响力,实时计算组运营团队在过去两个月的时间里,对Flink China社区持续进行品牌包装与推广,现将运营效果通过生态建设 / 活动运营 / 问卷调研 / 社区共建 / 内容输出 / 运营计划 六个方面展示。
成阳:
blink内部版本使用hadoop 3.0版本的client,从而能使用到一些yarn 3.x才有功能(比如placement constraint)。
但如果使用hadoop 3.0特有的api后,会导致flink在低版本的hadoop集群中不能正常运行。
目前大部分yarn用户还是以hadoop 2.6为主,所以目前blink开源版对于hadoop的依赖是2.6及以上版本的。
如果flink用户不需要hadoop 3.0特有的api的话,编译flink时用hadoop 2.6版本即可。
我们已经测试过基于hadoop 2.6.5的flink能够正常运行在hadoop 3.x的集群中。
邱从贤:用 RocksDBStateBackend 时出现了这个错误
追问:incremental 模式 这个没有,用的是 RocksDBStateBackend 他就是增量哈
![4](https://yqfile.alicdn.com/e66112b6d4109a020a299af421eda60a431b7ce0.png)
邱从贤:那需要看下哪个 task 超时了,然后看下日志找找看为啥超时了
追问:这个是错误日志,问了问度娘说:因为Mapred多个task操作同一个文件,一个task完成后删掉文件导致。 查看了下 dfs.datanode.max.xcievers 为 4096,难道这个值还是小了嘛
![5](https://yqfile.alicdn.com/e6d4f6acc722b153e19e9e45c30991404339ed66.png)
茶干:你这个错误实际上是expire 的checkpoint清理导致的task failover,root cause还是为啥你的checkpoint会超时,相关错误汇报可以参考 FLINK-10615和FLINK-10930
无题:
你看看 hdfs 那边的日志,我遇到的时候,是虚拟内存太底,导致不成功。
澄水:
false表示是撤回消息,true是插入或更新消息,这条query包含agg操作,从93->94需要先把93的结果撤回,然后发送更新结果94
这控制台的已经是输出数据了,不用你控制
在享受到流式处理优势的同时不会以牺牲吞吐位代价,首先checkpoint是增量异步的,overhead比较小对正常数据处理的影响很小,网络层的shuffle是以buffer为单位进行的,相当于micro batch吞吐很好,相比batch模式,下游提前启动了参与拉数据和处理,所以整体性能上会更好,除了资源占用会更多一些
绝顶:
可以看一下FFC上蒋晓伟研究员讲的keynote,上面有tpc-ds和spark的对比数据
https://files.alicdn.com/tpsservice/62fa5ebcd23ea0b8a956f2a06197b57a.pdf
智笙:可以把gc日志打出来分析下
墨简:堆内ok的话 堆外呢 有没有jni直接走malloc,new一类的