作为分布式系统，尤其是对延迟敏感的实时计算引擎，Apache Flink 需要有强大的容错机制，以确保在出现机器故障或网络分区等不可预知的问题时可以快速自动恢复并依旧能产生准确的计算结果。事实上，Flink 有一套先进的快照机制来持久化作业状态[1]，确保中间数据不会丢失，这通常需要和错误恢复机制（作业重启策略或 failover 策略）配合使用。在遇到错误时，Flink 作业会根据重启策略自动重启并从最近一个成功的快照（checkpoint）恢复状态。合适的重启策略可以减少作业不可用时间和避免人工介入处理故障的运维成本，因此对于 Flink 作业稳定性来说有着举足轻重的作用。下文就将详细解读 Flink 的错误恢复机制。
Flink 非 JVM 语言支持计划
众所周知，Apache Flink 是基于 JVM 语言开发的，所以提供的运行环境和编程 API 都是 JVM 语言（目前 Flink Python API 是用 Jython 实现的，因此也算 JVM 语言）。然而基于 JVM 开发的计算引擎普遍会遇到的一个问题是，做数据分析或机器学习的用户通常主要使用更声明式的语言，比如 Python 或者 R。因此为了支持多语言，尤其是非 JVM 语言，分布式计算领域业界在计算引擎的语言可移植性上做了不少的努力，其中比较出名的项目包括 SparkR、PySpark 和 Apache Beam。而目前 Apache Flink 社区也计划推进多语言支持，其中将优先支持 Python，下文将详细解析实现的关键点及具体方案。
Flink State As Database
有状态的计算作为容错以及数据一致性的保证，是当今实时计算必不可少的特性之一，流行的实时计算引擎包括 Google Dataflow、Flink、Spark (Structure) Streaming、Kafka Streams 都分别提供对内置 State 的支持。State 的引入使得实时应用可以不依赖外部数据库来存储元数据及中间数据，部分情况下甚至可以直接用 State 存储结果数据，这让业界不禁思考: State 和 Database 是何种关系？有没有可能用 State 来代替数据库呢？
Flink 1.8 Release 解读
在距离上个 feature 版本发布近四个月之后， 近日 Apache Flink 发布了 1.8 版本。该版本处理了 420 个 issue，其中新 feature 及改进主要集中在 State、Connector 和 Table API 三者上，并 fix 了一些在生产部署中较为常见的问题。下文将选取一些笔者认为重要的新特性、improvement 和 bugfix 进行解读，详细的改动请参照 release notes [1]。
Flink 网络传输优化技术
作为工业级的流计算框架，Flink 被设计为可以每天处理 TB 甚至 PB 级别的数据，所以如何高吞吐低延迟并且可靠地在算子间传输数据是一个非常重要的课题。此外，Flink 的数据传输还需要支持框架本身的特性，例如反压和用于测量延迟的 latency marker。在社区不断的迭代中，Flink 逐渐积累了一套值得研究的网络栈（Network Stack），本文将详细介绍 Flink Network Stack 的实现细节以及关键的优化技术。
什么是 Flink State Evolution?
State Evolution 是 Apache Flink （下简称 Flink）1.7 版本引入的新特性，目的是为用户提供迭代或修改 State 的方法，以适应长期运行的作业的版本迭代需求，比如迁移 State 到不同的序列化框架，或者对 State 的数据结构进行改变，甚至直接对 State 的内容进行修改。该特性对于企业级应用来说有着重大的意义。
作为 Statefull 计算框架，Flink 作业的状态通常用 State API 来保存而不是存在的数据库等外部存储，这样在获得更好的一致性和数据本地性的同时，也牺牲了使用数据库的灵活性和可访问性。State 以序列化的形式（Savepoint/Checkpoint）存在，对于很多不熟悉 Flink 序列化的用户来说相当于黑盒子，难以验证其中的数据正确性，更不用说修改其数据结构或者序列化格式，而 State Evolution 则是 Flink 在 State 管理上的一次很好的探索。
深入理解流计算中的 Watermark
近年来流计算技术发展迅猛，甚至有后来居上一统原本批处理主导的分布式计算之势，其中 Watermark 机制作为流计算结果准确性和延迟的桥梁扮演着不可或缺的角色。然而由于缺乏高质量的学习资源加上计算 Watermark 确实不是一件容易的事情，不少有着批处理计算背景的用户在流计算作业的开发中可能并不理解 Watermark 的重要意义，从而多走了很多弯路。为此，本文将基于笔者的学习积累和开发经验，谈谈个人对 Watermark 的理解，希望起到抛砖引玉的作用。
Flink on YARN Security 浅析(Flink Part)
在上篇关于 YARN 系统 Security 的博客，我们解析了通过 YARN 提供的 Security API，Application 已经在 RM 注册并且可以顺利地申请到 container，但 YARN 对 container 后续的凭证刷新（reacquire）并不能作用到已经在运行的 Application 进程，因此对于长期运行的 Application 而言要开发者自己实现认证和后续凭证刷新的逻辑。本文将接着分析 Flink 如何在申请到的 container 启动 jobmanger 和 taskmanager 并完成认证，也就是 Flink Application 自身的认证，以及后续的凭证刷新方法，最后再讲述最近社区对于 Flink on YARN Security 改进提案。
Flink on YARN Security 浅析 (YARN Part)
自我们将作业迁移到 Kerberized 的 YARN 新集群后，运行中的作业有一定几率出现出现认证失败，其中失败有 AMRMToken 过期导致 AM 无法与 RM 通信而被 kill 掉和 AM 申请的新 container 启动时报缺少 credential 两种表现。出现了这个问题后只能重启作业解决，这严重影响了平台的稳定性，因此笔者前后投入了接近两周的时间去研究这个问题，最后定位到问题在于 RM 刷新 viewfs token 时只会刷新第一个挂载的 FS 的 token。另一方面，笔者对于 YARN Security 和 Flink 与 YARN 在安全机制上的集成已经有了一定的积累，所以先记录并分享出来，以便后续有需要时检索（retrive）和与其他同学讨论交流。
Flink 1.7 Release 解读
自 feature freezed 以后经过近一个月的努力，Flink 社区在十一月的最后一天终于发布 Flink 1.7.0 版本。该版本处理了 420 个 issue，其中新特性或者改进主要集中在 SQL 和 State 两个模块上，另外从 1.7 开始更多的 API （包括 REST、State 还有正在讨论的 runtime）会考虑版本兼容性，以便用户更重度地依赖 Flink 做上层的开发。