小米从 2019 年开始引入 Flink 并处理实时计算相关的需求，从第一个接入的版本 1.7 到最新的 1.14，累计已升级更新了 6 个大的版本，目前已接入包括数据采集、信息流广告、搜索推荐、用户画像、金融等在内的全集团所有业务线的 3000+ 任务，日均处理 10 万亿 + 的消息，并在国内外搭建了 10+ 集群。
随着 Flink k8s 化以及实时集群迁移完成，有赞越来越多的 Flink 实时任务运行在 K8s 集群上，Flink k8s 化提升了实时集群在大促时弹性扩缩容能力，更好的降低大促期间机器扩缩容的成本。同时，由于 K8s 在公司内部有专门的团队进行维护，Flink k8s 化也能够更好的减低公司的运维成本。
Flink 因为其可靠性和易用性，已经成为当前最流行的流处理框架之一，在流计算领域占据了主导地位。早在 18 年知乎就引入了 Flink，发展到现在，Flink 已经成为知乎内部最重要的组件之一，积累了 4000 多个 Flink 实时任务，每天处理 PB 级的数据。
摘要：本文整理自 Shopee 研发专家李明昆，在 Flink Forward Asia 2022 流批一体专场的分享。本篇内容主要分为四个部分：
大家好，我是来自腾讯大数据团队的杨华（vinoyang），很高兴能够参加这次北京的 QCon，有机会跟大家分享一下腾讯实时流计算平台的演进与这个过程中我们的一些实践经验。
摘要：本文由快手实时计算负责人董亭亭分享，主要介绍快手基于 Flink 的持续优化与实践的介绍。内容包括：
摘要：本文整理自大健云仓基础架构负责人、Flink CDC Maintainer 龚中强在 5 月 21 日 Flink CDC Meetup 的演讲。主要内容包括：
在上一篇《零基础学Flink：实时热销榜Top5（案例）》文档中我们介绍了如何计算实时热销榜。在案例的最后TopNHot类中，我们使用了状态类。
在 Flink 作业中，无论是 SQL 还是 JAR 模式，常常会直接或者间接地使用到状态（State）。当 Flink 进行快照时，用户定义的这些状态数据可以被保存在状态点中，以供后续的崩溃恢复。 Flink 的状态分为 Operator State 和 Keyed State，而 Keyed State 又可以分为 ValueState、MapState、ListState、AggregatingState、MergingState、ReducingState 等多种类型。此外，这些林林总总的状态又有
1.UDF: 自定义标量函数(User Defined Scalar Function)。一行输入一行输出。2.UDAF: 自定义聚合函数。多行输入一行输出。3.UDTF: 自定义表函数。一行输入多行输出或一列输入多列输出。
Flink Forward Asia 2020 三天的分享已经结束，在这次分享上，自己也收获到了很多。这里写一篇文章来记录下自己这次的收获和总结，从个人的视角以及理解，和大家一起分享下，当然，如果有理解错误的地方，也欢迎大家指出。
我们知道在流计算场景中，数据是源源不断的流入的，数据流永远不会结束，那么计算就永远不会结束，如果计算永远不会结束的话，那么计算结果何时输出呢？本篇将介绍Apache Flink利用持续查询来对流计算结果进行持续输出的实现原理。
摘要：实际问题 我们知道在流计算场景中，数据是源源不断的流入的，数据流永远不会结束，那么计算就永远不会结束，如果计算永远不会结束的话，那么计算结果何时输出呢？本篇将介绍Apache Flink利用持续查询来对流计算结果进行持续输出的实现原理。
5万人关注的大数据成神之路，不来了解一下吗？ 5万人关注的大数据成神之路，真的不来了解一下吗？ 5万人关注的大数据成神之路，确定真的不来了解一下吗？ 欢迎您关注《大数据成神之路》 📷 Flink跟其他
Flink在1.11版本新增了一种部署模式，目前支持三种：Session 模式、Per job 模式、Application 模式，这三种模式主要在集群管理、资源隔离、用户main方法执行位置几个方面有所不同。
这几年大数据的飞速发展，出现了很多热门的开源社区，其中著名的有 Hadoop、Storm，以及后来的 Spark，他们都有着各自专注的应用场景。Spark 掀开了内存计算的先河，也以内存为赌注，赢得了内存计算的飞速发展。Spark 的火热或多或少的掩盖了其他分布式计算的系统身影。就像 Flink，也就在这个时候默默的发展着。
[Apache Flink]2017年12月发布的1.4.0版本开始，为流计算引入里程碑特性：TwoPhaseCommitSinkFunction。它提取了两阶段提交协议的通用逻辑，使得通过Flink来构建端到端的Exactly-Once程序成为可能。同时支持：
戳更多文章： 1-Flink入门 2-本地环境搭建&构建第一个Flink应用 3-DataSet API 4-DataSteam API 5-集群部署 6-分布式缓存 7-重启策略 8-Flink中的
在 Flink 作业中，无论是 SQL 还是 JAR 模式，常常会直接或者间接地使用到状态（State）。当 Flink 进行快照时，用户定义的这些状态数据可以被保存在状态点中，以供后续的崩溃恢复。
实时处理里消息的仅一次处理是大家关注的重点吧，前面浪尖分享过一篇对比spark streaming 和 flink的文章 <Spark Streaming VS Flink>，里面讲到了如何用spark streaming实现仅一次处理及flink是实现仅一次处理的。本文主要是想详细阐述一下flink结合kafka 0.11的仅一次处理语义。
更好地提高效率一直以来是袋鼠云数栈产品的主要目标之一。当前数栈客户的实时任务都是基于 Per-Job 模式运行的，客户在进行一些任务参数的修改之后，只能先取消当前任务，再选择 CheckPoint 恢复或者重新运行，整个过程需要3-5分钟，比较浪费时间。为了达到提高效率的目的，我们针对 Per-Job 任务的整体流程分析，进行了相关探索。
Flink Forward，给了我一个绝佳的机会，向全球 Apache Flink 社区介绍微博如何使用 Apache Flink 在我们的平台上运行实时数据处理和机器学习。在以下各节中，我将向您介绍微博，并将描述我们的机器学习平台的体系结构以及我们如何使用Apache Flink开发实时机器学习管道。最后，我将解释我们如何计划在微博上扩展 Flink 的用途，并简要了解我们在组织中使用开源技术的经验。
转载自:https://dwz.cn/xrMCqbk5 摘要： 实际问题 在流计算场景中，数据会源源不断的流入Apache Flink系统，每条数据进入Ap
[ 导读 ] 8月22日，Apache Flink 1.9.0 正式发布。早在今年1月，阿里便宣布将内部过去几年打磨的大数据处理引擎Blink进行开源并向 Apache Flink 贡献代码。此次版本在结构上有重大变更，修改代码达150万行，接下来，我们一起梳理 Flink 1.9.0 中非常值得关注的重要功能与特性。
摘要：实际问题 在流计算场景中，数据会源源不断的流入Apache Flink系统，每条数据进入Apache Flink系统都会触发计算。如果我们想进行一个Count聚合计算，那么每次触发计算是将历史上所有流入的数据重新新计算一次，还是每次计算都是在上一次计算结果之上进行增量计算呢？答案是肯定的，Apache Flink是基于上一次的计算结果进行增量计算的。
这篇文章改编自2017年柏林Flink Forward上Piotr Nowojski的演讲。你可以在Flink Forward Berlin网站上找到幻灯片和演示文稿。
在 Flink 1.12.0 版本中对 UI 进行了改进,在 TM 的页面增加了一个内存模型图,清楚的显示了每个区域的内存配置以及使用情况.
2010年，由Volker Markl（德国研究基金会——DFG资助）领导的研究项目“平流层：云上的信息管理”作为柏林工业大学、柏林洪堡大学和波茨坦Hasso-Plattner-Institut的合作项目启动。Flink从平流层分布式执行引擎的一个分支开始，并于2014年3月成为Apache孵化器项目。2014年12月，Flink被接受为Apache顶级项目。
自 Flink 开源以来，越来越多的开发者加入了 Flink 社区。仅仅 2019 年，Flink 在 GitHub 上的 Star 数量翻了一倍，Contributor 数量也呈现出持续增长的态势。而它目前在 GitHub 上的访问量，也位居 Apache 项目中前三，是 Apache 基金会中最为活跃的项目之一。
作者 | 郑思宇 “Flink 已经成为全球范围内实时流计算的事实标准。”用这句话来描绘 Flink 在当前大数据技术领域的地位并不为过。 虽然大数据领域的技术和潮流方向在不断发生改变，但是 Flink 一直处于核心驱动的位置。从流式计算引擎的兴起，到流批一体在企业内部的落地，再到为实现端到端全链路的实时化分析能力而走向舞台中央的流式数仓，Flink 均在其中扮演着重要的角色。 以上每个过程的推进和实现都并不容易，Flink 到底是如何做到的？其背后的推动力是什么？凭什么受到全球企业和开发者的青睐？带着这
HBase的设计思想主要是LSM。参见【Flink】第十四篇：LSM-Tree一般性总结。而LSM存储引擎的主要设计思想就是不断的将内存的有序存储结构flush到磁盘，这时候会在磁盘形成一个个的小的文件，如果每次都去做新文件和旧文件的合并，这显然是没必要，并且低效的。
Apache Flink 的命脉 "命脉" 即生命与血脉，常喻极为重要的事物。系列的首篇，首篇的首段不聊Apache Flink的历史，不聊Apache Flink的架构，不聊Apache Flink的功能特性，我们用一句话聊聊什么是 Apache Flink 的命脉？我的答案是：Apache Flink 是以"批是流的特例"的认知进行系统设计的。
在 Flink 1.4 版本之前，精准一次处理只限于 Flink 应用内，也就是所有的 Operator 完全由 Flink 状态保存并管理的才能实现精确一次处理。但 Flink 处理完数据后大多需要将结果发送到外部系统，比如 Sink 到 Kafka 中，这个过程中 Flink 并不保证精准一次处理。
Flink 是 stateful 计算引擎，不同于 Storm。在 Storm 这类无状态计算引擎中，并行的任务实例（通常一个任务实例运行在一个线程中）是不存储计算状态的，即使有一些运行时的程序元信息也是放在了像 ZooKeeper 这种第三方的高可用分布式协调者介质中。怎么理解这里的“无状态”呢？可以理解为流中的每个元素流过每个任务实例时，任务实例不会将此次处理的一些信息带到下一次处理元素中，即任务实例所在的线程是不存在记忆的。Flink 则相反，但是为了实现 stateful 需要付出非常大的代价，尤其是在分布式环境中，还要保证状态的全局一致性。就是说分布式在各个并行度线程中的任务实例所保存的状态必须是针对某个一致的语义平面上建立的，否则就无法保证在分布式环境中遇到故障后重启时恢复状态后的程序一致性了。
本节介绍如何在Flink中配置程序的并行执行。FLink程序由多个任务（转换/操作符、数据源和sinks）组成。任务被分成多个并行实例来执行，每个并行实例处理任务的输入数据的子集。任务的并行实例的数量称之为并行性。
本文来自9月1日在成都举行的Apache Flink China Meetup，分享来自于云邪。
Flink自1.4.0开始实现exactly-once的数据保证，即在任何情况下都能保证数据对应用产生的效果只有一次，不会多也不会少。
在当前数据量激增的时代，各种业务场景都有大量的业务数据产生，对于这些不断产生的数据应该如何进行有效的处理，成为当下大多数公司所面临的问题。目前比较流行的大数据处理引擎Apache Spark，基本上已经取代了MapReduce成为当前大数据处理的标准。随着数据的不断增长，人们逐渐意识到对实时数据处理的重要性。相对传统数据处理模式，流式数据处理有着更高的处理效率和成本控制要求。Apache Spark 不仅支持批数据计算还支持流式数据计算，但是SparkStreaming在底层架构、数据抽象等方面采用了批量计算的概念，其流计算的本质还是批（微批）计算。
近日，由 TiDB 社区主办，专属于全球开发者与技术爱好者的顶级挑战赛事——TiDB Hackathon 2020 比赛圆满落幕。今年是 TiDB Hackathon 第四次举办，参赛队伍规模创历届之最，共有 45 支来自全球各地的队伍报名，首次实现全球联动。经过 2 天时间的极限挑战， 大赛涌现出不少令人激动的项目。为了让更多小伙伴了解这些参赛团队背后的故事， 我们开启了 TiDB Hackathon 2020 优秀项目分享系列，本篇文章将介绍 TiFlink 团队赛前幕后的精彩故事。
1、Apache Flink 在滴滴的背景 2、Apache Flink 在滴滴的平台化 3、Apache Flink 在滴滴的生产实践 4、Stream SQL 5、展望规划
"Flink SQL UDF不应有状态" 这个技术细节可能有些朋友已经知道了。但是为什么不应该有状态呢？这个恐怕大家就不甚清楚了。本文就带你一起从这个问题点入手，看看Flink SQL究竟是怎么处理UDF，怎么生成对应的SQL代码。
剩喜漫天飞玉蝶，不嫌幽谷阻黄莺。2020 年是不寻常的一年，Flink 也在这一年迎来了新纪元。
摘要：Dinky 0.5 已发布，它将重新定义 Apache Flink 的开发运维，让其如虎添翼，拭目以待。内容包括：
Spark Streaming 运行时的角色(standalone 模式)主要有：
Flink 在1.4.0 版本引入『exactly-once』并号称支持『End-to-End Exactly-Once』“端到端的精确一次”语义。
Flink 1.12 版本在 20 年 12 月已经正式 Release，目前我们的 Flink SQL 作业的 Flink 引擎版本还是 1.10，本文主要用以评估 Flink 1.10 升级到 1.12 整体所能带来的预期收益，同时结合所需投入的成本，决定是否需要升级 Flink SQL 引擎版本到 1.12。本次升级所评估的收益包含 1.11 和 1.12 版本所带来的收益，如有理解错误，欢迎指出，一起交流。
本文作者：BYD信息中心-数据中心管理部-董睿 这里打一个小广告，手动狗头 比亚迪西安研发中心（与深圳协同办公），base西安。招聘大数据平台运维方向工程师，实时计算方向工程师，感兴趣的小伙伴请投递简历至dong.rui@byd.com 1.文档编写目的 Prometheus 是一款基于时序数据库的开源监控告警系统，Prometheus的基本原理是通过HTTP协议周期性抓取被监控组件的状态，任意组件只要提供对应的HTTP接口就可以接入监控。Grafana是一款采用 Go语言编写的开源应用，是一个跨平台的开源
领取专属 10元无门槛券
手把手带您无忧上云
