第一部分讨论如何大规模执行checkpoint。 最后一部分解释了一些关于规划要使用多少资源的最佳实践。
Flink 中的每个函数和操作符都可以是有状态的（请参阅使用状态了解详细信息）。有状态函数在处理单个元素/事件时存储数据。
无界数据是持续产生的数据，所以必须持续的处理无界数据流。因为输入是无限的，没有终止时间。处理无界数据通常要求以特定顺序获取，以便判断事件是否完整、有无遗漏。
在本文中，我们将深入探讨Flink新颖的检查点机制是如何工作的，以及它是如何取代旧架构以实现流容错和恢复。我们在各种类型的流处理应用程序上对Flink性能进行测试，并通过在Apache Storm（一种广泛使用的低延迟流处理器）上运行相同的实验来进行对比。
虽然数据流中的许多操作一次只查看一个单独的事件（例如事件解析器），但有些操作会记住跨多个事件的信息（例如窗口操作符）。 这些操作称为有状态的。
Flink内置了一些基本数据源和接收器，并且始终可用。该预定义的数据源包括文件，目录和插socket，并从集合和迭代器摄取数据。该预定义的数据接收器支持写入文件和标准输入输出及socket。
Flink文档：https://ci.apache.org/projects/flink/flink-docs-release-1.12/
Apache Flink提供了一个容错机制来持续恢复数据流应用程序的状态。该机制确保即使在出现故障的情况下，程序的状态也将最终反映每条记录来自数据流严格一次exactly once。 请注意，有一个开关可以降级为保证至少一次(least once)（如下所述）。
第 1 章 为何选择 Flink 许多情况下，人们希望用低延迟或者实时的流处理来获得数据的高时效性，前提是流处理本身是准确且高效的 优秀的流处理技术可以容错，而且能保证exactlyonce2 Storm提供了低延迟的流处理，但是它为实时性付出了一些代价：很难实现高吞吐，并且其正确性没能达到通常所需的水平。换句话说，它并不能保证exactlyonce；即便是它能够保证的正确性级别，其开销也相当大 图12：Flink的一个优势是，它拥有诸多重要的流式计算功能。其他项目为了实现这些功能，都不得不付出代价。比如，
这篇文章改编自2017年柏林Flink Forward上Piotr Nowojski的演讲。你可以在Flink Forward Berlin网站上找到幻灯片和演示文稿。
状态可以存储在Java的堆内或堆外。根据你的状态终端，Flink 也可以管理应用程序的状态，这意味着 Flink 可以处理内存管理（可能会溢出到磁盘，如果有必要），以允许应用程序存储非常大的状态。默认情况下，配置文件 flink-conf.yaml 为所有Flink作业决定其状态终端。
为简化和加速故障排查，Pinterest 流处理平台团队基于 Flink 构建并推出了称为 Dr. Squirrel 的诊断工具，揭示并聚合任务状态，洞悉根本致因，提供解决问题的可操作过程。自发布以来，该工具显著提升了开发人员和平台团队的工作效率。
在我们开发Flink应用时，许多有状态流应用程序的一个常见要求是自动清理应用程序状态以有效管理状态大小，或控制应用程序状态的访问时间。 TTL(Time To Live)功能在Flink 1.6.0中开始启动，并在Apache Flink中启用了应用程序状态清理和高效的状态大小管理。
流式计算分为无状态和有状态两种情况。无状态计算观察每个独立的事件，Storm就是无状态的计算框架，每一条消息来了以后和前后都没有关系，一条是一条。比如我们接收电力系统传感器的数据，当电压超过240v就报警，这就是无状态的数据。但是如果我们需要同时判断多个电压，比如三相电路，我们判断三相电都高于某个值，那么就需要将状态保存，计算。因为这三条记录是分别发送过来的。
在这篇文章中我们将结合例子逐步讲解 Flink 是如何与 Kafka 工作来确保将 Kafka Topic 中的消息以 Exactly-Once 语义处理。
Storm需要自己实现有状态的计算，比如借助于自定义的内存变量或者redis等系统，保证低延迟的情况下自己去判断实现有状态的计算，但是Flink就不需要这样，而且作为新一代的流处理系统，Flink非常重视。
这篇文章是系列文章的第一篇，数据工匠团队会在这里为大家展示一些Apache Flink的核心功能。
检查点通过恢复状态和对应流位置来实现 Flink 状态容错，从而为应用程序提供与无故障执行相同的语义。
在 Flink 社区中，最常被问到的问题之一是：在从开发到生产上线的过程中如何确定集群的大小。这个问题的标准答案显然是“视情况而定”，但这并非一个有用的答案。本文概述了一系列的相关问题，通过回答这些问题，或许你能得出一些数字作为指导和参考。
◆ 简介 虽然大多数人都熟悉Uber，但并非所有人都熟悉优步货运, 自2016年以来一直致力于提供一个平台，将托运人与承运人无缝连接。我们正在简化卡车运输公司的生活，为承运人提供一个平台，使其能够浏览所有可用的货运机会，并通过点击一个按钮进行预订，同时使履行过程更加可扩展和高效。 为托运人提供可靠的服务是优步货运获得他们信任的关键。由于承运人的表现可能会大大影响货运公司服务的可靠性，我们需要对承运人透明，让他们知道我们对他们负责的程度，让他们清楚地了解他们的表现，如果需要，他们可以在哪些方面改进。 为了实现
场景描述：本文将介绍如何使用 Flink 开发实时 ETL 程序，并介绍 Flink 是如何保证其 Exactly-once 语义的。
来自Flink Forward Berlin 2017的最受欢迎的会议是Robert Metzger的“坚持下去：如何可靠，高效地操作Apache Flink”。 Robert所涉及的主题之一是如何粗略地确定Apache Flink集群的大小。 Flink Forward的与会者提到他的群集大小调整指南对他们有帮助，因此我们将他的谈话部分转换为博客文章。 请享用！
这篇文章我们将深入探讨有状态流处理，更确切地说是 Flink 中可用的不同状态后端。在以下部分，我们将介绍 Flink 的3个状态后端，它们的局限性以及根据具体案例需求选择最合适的状态后端。
场景描述：Flink本身为了保证其高可用的特性，以及保证作用的Exactly Once的快速恢复，进而提供了一套强大的Checkpoint机制。这个机制在原理是什么？有哪些需要注意的呢？
Flink四大基石分别是：Time （时间）、Window（窗口）、State （状态）、Checkpoint（检查点）。
Apache Flink是一种快速、可靠、可扩展的开源流处理框架，被广泛应用于大数据领域。本文将介绍Apache Flink的实战运用，包括其核心概念、架构设计以及基于Flink进行大数据流处理的具体示例。通过代码实现的案例，读者将深入了解如何使用Apache Flink解决真实世界中的大数据处理问题。
虽然数据流中的许多操作一次只查看一个单独的事件（例如事件解析器），但某些操作会记住多个事件的信息（例如窗口算子）。 这些操作称为有状态的(stateful)。
状态在 Flink 中叫作 State,用来保存中间计算结果或者缓存数据。根据是否需要保存中间结果，分为无状态计算和有状态计算。对于流计算而言，时间持续不断地产生，如果每次计算都是相互独立的，不依赖于上下游的事件，则是无状态计算。如果计算需要依赖于之前或者后续的事件，则是有状态计算。State 是实现有状态计算的下的 Exactly-Once 的基础。
我们在思考流处理问题上花了很多时间，更酷的是，我们也花了很多时间帮助其他人认识流处理，以及如何在他们的组织里应用流处理来解决数据问题。
Cloudera流分析（CSA）提供由Apache Flink支持的实时流处理和流分析。在CDP上的Flink提供了具有低延迟的灵活流解决方案，可以扩展到较大的吞吐量和状态。除Flink之外，CSA还包括SQL Stream Builder，可使用对数据流的SQL查询来提供数据分析经验。
这篇文章阐述了 Flink 应用程序达到生产状态所必须的配置步骤。在以下部分中，我们概述了在 Flink 作业达到生产状态之前技术领导、DevOps、工程师们需要仔细考虑的重要配置参数。Flink 为大多数配置选项都提供了开箱即用的默认选项，在许多情况下它们是POC阶段（概念验证）或探索 Flink 不同 API 和抽象的很好的起点。
有状态的函数和算子在处理单个元素/事件时存储数据，使得状态state成为任何精细操作的关键构件。
本文重点介绍开发人员在有状态流处理应用中使用 Flink 的 Keyed State 的函数或算子评估性能时应牢记的3个重要因素。
过去无论是在生产中使用，还是调研 Apache Flink，总会遇到一个问题：如何访问和更新 Flink 保存点（savepoint）中保存的 state？Apache Flink 1.9 引入了状态处理器（State Processor）API，它是基于 DataSet API 的强大扩展，允许读取，写入和修改 Flink 的保存点和检查点（checkpoint）中的状态。
在上一篇文章「checkpoint【1】」中，我们讨论过在2PC过程的每个阶段出现故障时Flink的处理方式：
5万人关注的大数据成神之路，不来了解一下吗？ 5万人关注的大数据成神之路，真的不来了解一下吗？ 5万人关注的大数据成神之路，确定真的不来了解一下吗？ 欢迎您关注《大数据成神之路》 📷 Flink跟其他
Flink 1.5.0 是 1.x.y 系列的第六个主要版本。与往常一样，它兼容之前 1.x.y 版本中使用 @Public 注解标注过的 API。
Apache Flink是一个框架和分布式处理引擎，用于对无界和有界数据流进行状态计算。 Flink设计为在所有常见的集群环境中运行，以内存速度和任何规模执行计算。
在 Shopify 中，我们将Apache Flink作为标准的有状态流媒体引擎，为我们的BFCM Live Map等各种用例提供支持。我们的 Flink 应用程序部署在利用Google Kubernetes Engine的 Kubernetes 环境中。我们的集群采用配置使用高可用性模式，配置任务管理为故障点。我们还为我们使用状态保存器作为我们使用的检查点和点写入谷歌云存储（GCS）。
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
很多有状态流应用程序的常见需求是能够控制应用程序状态的访问时长以及何时删除它。这篇文章介绍了在 1.6.0 版本添加到 Flink 的状态生命周期时间（TTL）功能。
Flink 故障恢复机制的核心，就是应用状态的一致性检查点，有状态流应用的一致检查点，其实就是所有任务的状态，在某个时间点的一份拷贝（一份快照）；这个时间点，应该是所有任务都恰好处理完一个相同的输入数据的时刻。在执行流应用程序期间，Flink 会定期保存状态的一致检查点，如果发生故障， Flink 将会使用最近的检查点来一致恢复应用程序的状态，并。重新启动处理流程。
之前所介绍的流处理API，无论是基本的转换、聚合，还是更为复杂的窗口操作，其实都是基于DataStream进行转换的；所以可以统称为DataStream API，这也是Flink编程的核心。而我们知道，为了让代码有更强大的表现力和易用性，Flink本身提供了多层API，DataStream API只是中间的一环，如图所示：
流处理应用程序通常是有状态的，“记住”已处理事件的信息，并使用它来影响进一步的事件处理。在Flink中，记忆的信息（即状态）被本地存储在配置的状态后端中。为了防止发生故障时丢失数据，状态后端会定期将其内容快照保存到预先配置的持久性存储中。该RocksDB[1]状态后端（即RocksDBStateBackend）是Flink中的三个内置状态后端之一。这篇博客文章将指导您了解使用RocksDB管理应用程序状态的好处，解释何时以及如何使用它，以及清除一些常见的误解。话虽如此，这不是一篇说明RocksDB如何深入工作或如何进行高级故障排除和性能调整的博客文章；如果您需要任何有关这些主题的帮助，可以联系Flink用户邮件列表[2]。
在 Apache Flink 1.5.0 中引入了广播状态（Broadcast State）。本文将描述什么是广播状态模式，广播状态与其他的 Operator State 有什么区别，最后说明一下在 Flink 中使用该功能时需要考虑的一些重要注意事项。
一，抽象层次 Flink提供不同级别的抽象来开发流/批处理应用程序。 1，stateful streaming 最底层。它通过Process Function嵌入到DataStream API中。它允
在大数据技术发展历程当中，Flink框架可以说是新一轮的热点技术框架，主打流批一体的计算模式，成为更适应当下需求的技术框架，因此再也技术领域得到更多的重视。今天的大数据入门分享，我们主要来讲讲Flink框架的状态编程与容错机制。
(1) 最低级别的抽象只是提供有状态的数据流。通过Process Function集成到DataStream API中。它允许用户不受限制的处理来自一个或多个数据流的事件，并可以使用一致的容错状态(consistent fault tolerant state)。另外，用户可以注册事件时间和处理时间的回调函数，允许程序实现复杂的计算。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
即时通信 IM
对象存储
