当前最著名的交互式编程环境莫属Jupyter Notebook了，程序员可以启动一个交互的Session，在这Session中编写代码、执行程序、获取结果，所见即所得。
黄鹏，微博广告实时数据开发工程师，负责法拉第实验平台数据开发、实时数据关联平台、实时算法特征数据计算、实时数据仓库、实时数据清洗组件开发工作。
Flink具有先进的架构理念，拥有诸多的优秀特性以及完善的编程接口，Flink的优势有以下几点：
本篇翻译自论文：Lightweight Asynchronous Snapshots for Distributed Dataflows，Flink的容错快照模型即来源于该论文。原文地址：https://arxiv.org/pdf/1506.08603.pdf
flink 通过实现了 Google Dataflow 流式计算模型实现了高吞吐、低延迟、高性能兼具实时流式计算框架。
在 Flink 的框架中，进行有状态的计算是 Flink 最重要的特性之一。所谓的状态，其实指的是 Flink 程序的中间计算结果。Flink 支持了不同类型的状态，并且针对状态的持久化还提供了专门的机制和状态管理器。
实时处理里消息的仅一次处理是大家关注的重点吧，前面浪尖分享过一篇对比spark streaming 和 flink的文章 <Spark Streaming VS Flink>，里面讲到了如何用spark streaming实现仅一次处理及flink是实现仅一次处理的。本文主要是想详细阐述一下flink结合kafka 0.11的仅一次处理语义。
上图的Flink示例程序对一个数据流做简单处理，整个过程包括了输入（Source）、转换（Transformation）和输出（Sink）。程序由多个DataStream API组成，这些API，又被称为算子 （Operator），共同组成了逻辑视角。在实际执行过程中，逻辑视角会被计算引擎翻译成可并行的物理视角。
导读：本文将告诉你Flink是什么，以及为什么Flink会成为下一代大数据处理框架的标准。
在伴鱼发展早期，出现了一系列实时性相关的需求，比如算法工程师期望可以拿到用户的实时特征数据做实时推荐，产品经理希望数据方可以提供实时指标看板做实时运营分析。这个阶段中台数据开发工程师主要是基于「Spark」实时计算引擎开发作业来满足业务方提出的需求。然而，这类作业并没有统一的平台进行管理，任务的开发形式、提交方式、可用性保障等也完全因人而异。 伴随着业务的加速发展，越来越多的实时场景涌现出来，对实时作业的开发效率和质量保障提出了更高的要求。为此，我们从去年开始着手打造伴鱼公司级的实时计算平台，平台代号「Pa
分布式有状态流处理支持在云中部署和执行大规模连续计算，主要针对低延迟和高吞吐量。这种模式的一个最根本的挑战就是在可能的失败情况下提供处理保证。现有方法依赖于可用于故障恢复的周期性全局状态快照。这些方法有两个主要缺点。首先，他们经常拖延影响数据摄取的整体计算过程。其次，持久化存储所有传输中的记录以及算子状态，这会导致比所需的快照要更大。
checkpoint机制是Flink可靠性的基石，可以保证Flink集群在某个算子因为某些原因(如 异常退出)出现故障时，能够将整个应用流图的状态恢复到故障之前的某一状态，保 证应用流图状态的一致性。Flink的checkpoint机制原理来自“Chandy-Lamport algorithm”算法。
在Flink状态管理详解这篇文章中，我们介绍了Flink的状态都是基于本地的，而Flink又是一个部署在多节点的分布式引擎，分布式系统经常出现进程被杀、节点宕机或网络中断等问题，那么本地的状态在遇到故障时如何保证不丢呢？Flink定期保存状态数据到存储上，故障发生后从之前的备份中恢复，整个被称为Checkpoint机制，它为Flink提供了Exactly-Once的投递保障。本文将介绍Flink的Checkpoint机制的原理。本文会使用多个概念：快照（Snapshot）、分布式快照（Distributed Snapshot）、检查点（Checkpoint）等，这些概念均指的是Flink的Checkpoint机制，读者可以将这些概念等同看待。
Apache Flink 是一个框架和分布式处理引擎，用于在无边界和有边界数据流上进行有状态的计算。Flink 能在所有常见集群环境中运行，并能以内存速度和任意规模进行计算。
Flink 是一个框架和分布式处理引擎，用于在无边界和有边界数据流上进行有状态的计算。Flink能在所有常见集群环境中运行，并能以内存速度和任意规模进行计算。使用官网的语句来介绍， Flink 就是 “Stateful Computations over Data Streams”。
在当代数据量激增的时代，各种业务场景都有大量的业务数据产生，对于这些不断产生的数据应该如何进行有效的处理，成为当下大多数公司所面临的问题。随着雅虎对hadoop的开源，越来越多的大数据处理技术开始涌入人们的视线，例如目前比较流行的大数据处理引擎Apache Spark,基本上已经取代了MapReduce成为当前大数据处理的标准。但是随着数据的不断增长，新技术的不断发展，人们逐渐意识到对实时数据处理的重要性。相对于传统的数据处理模式，流式数据处理有着更高的处理效率和成本控制能力。Flink 就是近年来在开源社区不断发展的技术中的能够同时支持高吞吐、低延迟、高性能的分布式处理框架。
基于Standalone或者Yarn模式提交Flink任务后，当任务执行失败、取消或者完成后，可以在WebUI中查看对应任务的统计信息，这些统计信息在生产环境中对我们来说非常重要，可以知道一个任务异常挂掉前发生了什么，便于定位问题。
之前有想过系统地来一番flink源码分析系列，谁曾想工作中需要完成的需求有些多，完整的flink源码分析系列只能一再往后拖了。之前公众号后台有想学习flink的朋友留言想看更多学习flink的资料，现在先发一些之前收藏的关于flink相关的文章，其中大多翻译自flink社区，希望能给大家带来一些帮助。本文[1]主要围绕flink任务的生命周期展开。
Flink四大基石分别是：Time （时间）、Window（窗口）、State （状态）、Checkpoint（检查点）。
Flink是使用Kafka链接计算任务,利用kafka的exactly once实现流计算的不重不丢,而Kafka 的 Exactly Once 语义是通过它的事务和生产幂等两个特性来共同实现的
场景描述：本文由小米的王加胜同学分享，文章介绍了 Apache Flink 在小米的发展，从 Spark Streaming 迁移到 Flink ，在调度计算与调度数据、Mini batch 与 streaming、数据序列化等方面对比了 Spark Streaming 和 Flink 的一些区别。
本文转载Flink官方社区文章：一张图轻松掌握 Flink on YARN 基础架构与启动流程
本系列文章来自云栖社区，对Flink的解析兼具广度和深度，适合对Flink有一定研究的同学学习。
无界数据是持续产生的数据，所以必须持续的处理无界数据流。因为输入是无限的，没有终止时间。处理无界数据通常要求以特定顺序获取，以便判断事件是否完整、有无遗漏。
要想熟练掌握一个大数据框架，仅仅是学习一些网络上的样例程序是远远不够的，我们必须系统地了解它背后的设计和运行原理。
Flink 作为新一代基于事件流的、真正意义上的流批一体的大数据处理引擎，正在逐渐得到广大开发者们的青睐。就从我自身的视角看，最近也是在数据团队把一些原本由 Flume、SparkStreaming、Storm 编写的流式作业往 Flink 迁移，它们之间的优劣对比本篇暂不讨论。
默认情况下，每个Flink集群只有一个JobManager，这将导致单点故障（SPOF，single point of failure），如果这个JobManager挂了，则不能提交新的任务，并且运行中的程序也会失败，这是我们可以对JobManager做高可用（High Availability，简称HA），JobManager HA集群当Active JobManager节点挂掉后可以切换其他Standby JobManager成为主节点，从而避免单点故障。用户可以在Standalone、Flink on Yarn、Flink on K8s集群模式下配置Flink集群HA,Flink on K8s集群模式下的HA将单独在K8s里介绍。
2019年4月1-2日，Flink Forward 2019 San Francisco会议在旧金山召开。Flink Forward会议邀请了来自Google, Uber, Netflix和Alibaba等公司在实时计算领域的顶尖专家和一线实践者，深入讨论了Flink社区的最新进展和发展趋势，以及Flink在业界的应用实践。随着近年来对Flink技术的广泛应用以及对Flink社区的活跃贡献，腾讯也受邀参加了会议并以主题Developing and Operating Real-Time Applications at Tencent介绍了腾讯大数据在实时计算平台建设上的工作。
本次培训主要专注在四个重要的概念：连续处理流数据，事件时间，有状态的流处理和状态快照。
本文来自9月1日在成都举行的Apache Flink China Meetup，分享来自于云邪。
Flink 是 stateful 计算引擎，不同于 Storm。在 Storm 这类无状态计算引擎中，并行的任务实例（通常一个任务实例运行在一个线程中）是不存储计算状态的，即使有一些运行时的程序元信息也是放在了像 ZooKeeper 这种第三方的高可用分布式协调者介质中。怎么理解这里的“无状态”呢？可以理解为流中的每个元素流过每个任务实例时，任务实例不会将此次处理的一些信息带到下一次处理元素中，即任务实例所在的线程是不存在记忆的。Flink 则相反，但是为了实现 stateful 需要付出非常大的代价，尤其是在分布式环境中，还要保证状态的全局一致性。就是说分布式在各个并行度线程中的任务实例所保存的状态必须是针对某个一致的语义平面上建立的，否则就无法保证在分布式环境中遇到故障后重启时恢复状态后的程序一致性了。
在TiDB中（TiDB是一个分布式SQL数据库，其存储引擎TiKV是一个分布式的key-value存储引擎），TiKV使用了RocksDB作为其底层存储引擎，利用RocksDB提供的键值存储与读写功能，以及LSM-tree架构来实现数据的持久化和高效读写。
在 Shopify 中，我们将Apache Flink作为标准的有状态流媒体引擎，为我们的BFCM Live Map等各种用例提供支持。我们的 Flink 应用程序部署在利用Google Kubernetes Engine的 Kubernetes 环境中。我们的集群采用配置使用高可用性模式，配置任务管理为故障点。我们还为我们使用状态保存器作为我们使用的检查点和点写入谷歌云存储（GCS）。
在本节中，我们将解释 解释器（Interpreter）、解释器组和解释器设置在 Zeppelin 中的作用。 Zeppelin 解释器的概念允许将任何语言或数据处理后端插入 Zeppelin。 目前，Zeppelin 支持 Scala、Python、Flink、Spark SQL、Hive、JDBC、Markdown、Shell 等多种解释器。
在使用Flink进行数据的处理的时候，一个必要步骤就是需要将计算的结果进行存储或导出，Flink中这个过程称为Sink，官方我们提供了常用的几种Sink Connector，例如:
day05_Flink容错机制 今日目标 Flink容错机制之Checkpoint Flink容错机制之重启策略 存储介质StateBackend Checkpoint 配置方式 状态恢复和重启策略 Savepoint手动重启并恢复 并行度设置 Flink状态管理 状态就是基于 key 或者 算子 operator 的中间结果 Flink state 分为两种 ： Managed state - 托管状态 ， Raw state - 原始状态 Managed state 分为 两种： k
Flink 在1.4.0 版本引入『exactly-once』并号称支持『End-to-End Exactly-Once』“端到端的精确一次”语义。
Apache Flink® - Stateful Computations over Data Streams
Hadoop 3.x版本是Hadoop版本中的下一个重要里程碑。关于Hadoop 3.x在Hadoop 2.x基础上增强了哪些功能，很多人都在考虑这个问题。因此，在本文中，我们将介绍Hadoop3中的新增功能以及它与旧版本的区别。
转载自:https://dwz.cn/xrMCqbk5 摘要： 实际问题 在流计算场景中，数据会源源不断的流入Apache Flink系统，每条数据进入Ap
我们在Flink重点难点：状态(Checkpoint和Savepoint)容错与两阶段提交一文中对Flink的Checkpoint做过详细的介绍。
一般指一个具体的Operator的状态(operator的状态表示一些算子在运行的过程中会产生的一些历史结果,如前面的maxBy底层会维护当前的最大值,也就是会维护一个keyedOperator,这个State里面存放就是maxBy这个Operator中的最大值)
摘要：实际问题 在流计算场景中，数据会源源不断的流入Apache Flink系统，每条数据进入Apache Flink系统都会触发计算。如果我们想进行一个Count聚合计算，那么每次触发计算是将历史上所有流入的数据重新新计算一次，还是每次计算都是在上一次计算结果之上进行增量计算呢？答案是肯定的，Apache Flink是基于上一次的计算结果进行增量计算的。
随着业务的高速发展和实时计算的迭代，业务对实时计算的需求越来越多，对实时任务的稳定性要求也越来越高。对实时计算平台而言，底层调度系统及计算引擎的稳定性、高可用性就变的十分重要。本文主要围绕作业帮实时计算平台底层调度系统，从背景现状、目标与挑战、方案设计以及未来规划等几方面来展开。
对于很多做离线或者实时数仓的小伙伴来说，我先问几个问题，看看小伙伴萌能回答上来吗？
如图1-1所示，传统单体数据架构（Monolithic Architecture）最大的特点便是集中式数据存储，企业内部可能有诸多的系统，例如Web业务系统、订单系统、CRM系统、ERP系统、监控系统等，这些系统的事务性数据主要基于集中式的关系性数据库（DBMS）实现存储，大多数将架构分为计算层和存储层。
Cloudera流分析（CSA）提供由Apache Flink支持的实时流处理和流分析。在CDP上的Flink提供了具有低延迟的灵活流解决方案，可以扩展到较大的吞吐量和状态。除Flink之外，CSA还包括SQL Stream Builder，可使用对数据流的SQL查询来提供数据分析经验。
领取专属 10元无门槛券
手把手带您无忧上云
