Apache Flink

先跟大家分享一个好消息！即日起，Apache Flink 社区微信公众号 Ververica 正式更名为 Flink 中文社区 并由 Apache Flink PMC 成员进行维护，是国内唯一的 Flink 社区官方微信公众号，详细信息请见次条「声明」。 在去年的一年中，Flink 中文社区共发布文章 144 篇，通过提供 Flink 技术原理剖析、上手实操、多场景下的最佳实践以及社区的最新资讯等帮助大家更好的理解、使用 Flink。 同时，我们也发现当前社区除文章、直播教程、Meetup 外还缺少一个清晰的图谱让大家了解 Flink 完整的技术体系与学习路径。因此，社区整理了这样一份知识图谱，由 Apache Flink Committer 执笔，四位 PMC 成员审核，将 Flink 9 大技术版块详细拆分，突出重点内容并搭配全面的学习素材。看完这份图谱，才算真的搞懂 Flink！ ▽ Flink 知识图谱概览 ▽ 如何获取？ 关注「Flink 中文社区」微信公众号，后台回复关键字“图谱”即可下载 PDF 版本，内含大量补充链接，一键点击即可查看相关素材！ 最实用的知识图谱 1.内容全面 ，将 Flink 所涉及的技术内容划分为 9 大版块，每部分内容进行详细分解，并提供学习路径及深入了解的学习素材。 Streaming Processing Concepts(common

在 Flink 社区中，最常被问到的问题之一是：在从开发到生产上线的过程中如何确定集群的大小。这个问题的标准答案显然是“视情况而定”，但这并非一个有用的答案。本文概述了一系列的相关问题，通过回答这些问题，或许你能得出一些数字作为指导和参考。 计算并建立一个基线 第一步是仔细考虑应用程序的运维指标，以达到所需资源的基线。 需要考虑的关键指标是： 每秒记录数和每条记录的大小 已有的不同键（key）的数量和每个键对应的状态大小 状态更新的次数和状态后端的访问模式 最后，一个更实际的问题是与客户之间围绕停机时间、延迟和最大吞吐量的服务级别协议（sla），因为这些直接影响容量规划。 接下来，根据预算，看看有什么可用的资源。例如： 网络容量 ，同时把使用网络的外部服务也纳入考虑，如 Kafka、HDFS 等。 磁盘带宽 ，如果您依赖于基于磁盘的状态后端，如 RocksDB（并考虑其他磁盘使用，如 Kafka 或 HDFS） 可用的机器数量、CPU 和内存 基于所有这些因素，现在可以为正常运行构建一个基线，外加一个资源缓冲量用于恢复追赶或处理负载尖峰。建议您在建立基线时也考虑检查点期间（checkpointing）使用的资源情况。 示例：数据说明 当前在假设的集群上计划作业部署，将建立资源使用基线的过程可视化。这些数字是粗略的值，它们并不全面——在文章的最后将进一步说明在进行计算过程中遗漏的部分

在消息系统中，消息的生成和消费通常支持三种模式： at-most-once，at-least-once 和 exactly-once。 这几种模式的区别主要在于当系统发生错误的时候，系统表现何种行为。前两种模式，非常容易理解，出错后不处理或者不停重试直到成功为止，对于exactly-once的模式，系统在出错的时候，则需要进行特殊处理来保证一条消息只被处理一次。 发生错误的场景 上图是常见的消息系统（如Kafka/Plusar/sls loghub等）的架构，消息（message）由生产者(Producer)发送至消息系统的接收者（Broker），Broker将Message持久化到特定分区(Partition)后，供消费者（Consumer）进行消费。在这个过程中，任意阶段都可能出错。 Broker 错误：Broker作为系统的主要组成部分，负责数据的接收和读取，当单个broker fail的时候，不同的系统表现行为也不同，可能会重新选举Leader或进行broker的failover，在这个过程中，消息的读写可能发生失败 Producer到Broker RPC错误 ： Producer将数据发送至Broker后，需要收到Broker的ack才能确定消息写入成功，在Broker出错，或Producer到Broker网络异常等情况下，Producer可能无法收到ack信息，这时

小米业务线众多，从信息流，电商，广告到金融等覆盖了众多领域，小米流式平台为小米集团各业务提供一体化的流式数据解决方案，主要包括数据采集，数据集成和流式计算三个模块。目前每天数据量达到 1.2 万亿条，实时同步任务 1.5 万，实时计算的数据 1 万亿条。 伴随着小米业务的发展，流式平台也经历三次大升级改造，满足了众多业务的各种需求。最新的一次迭代基于 Apache Flink，对于流式平台内部模块进行了彻底的重构，同时小米各业务也在由 Spark Streaming 逐步切换到 Flink。 背景介绍 小米流式平台的愿景是为小米所有的业务线提供流式数据的一体化、平台化解决方案。具体来讲包括以下三个方面： 流式数据存储 ：流式数据存储指的是消息队列，小米开发了一套自己的消息队列，其类似于 Apache kafka，但它有自己的特点，小米流式平台提供消息队列的存储功能； 流式数据接入和转储 ：有了消息队列来做流式数据的缓存区之后，继而需要提供流式数据接入和转储的功能； 流式数据处理 ：指的是平台基于 Flink、Spark Streaming 和 Storm 等计算引擎对流式数据进行处理的过程。 下图展示了流式平台的整体架构。从左到右第一列橙色部分是数据源，包含两部分，即 User 和 Database。 User 指的是用户各种各样的埋点数据，如用户 APP 和 WebServer

新特性及优化 内存管理及配置优化 Flink 目前的 TaskExecutor 内存模型存在着一些缺陷，导致优化资源利用率比较困难，例如： 流和批处理内存占用的配置模型不同； 流处理中的 RocksDB state backend 需要依赖用户进行复杂的配置。 为了让内存配置变的对于用户更加清晰、直观，Flink 1.10 对 TaskExecutor 的内存模型和配置逻辑进行了较大的改动 （FLIP-49 [7]）。这些改动使得 Flink 能够更好地适配所有部署环境（例如 Kubernetes, Yarn, Mesos），让用户能够更加严格的控制其内存开销。 ■ Managed 内存扩展 Managed 内存的范围有所扩展，还涵盖了 RocksDB state backend 使用的内存。尽管批处理作业既可以使用堆内内存也可以使用堆外内存，使用 RocksDB state backend 的流处理作业却只能利用堆外内存。因此为了让用户执行流和批处理作业时无需更改集群的配置，我们规定从现在起 managed 内存只能在堆外。 ■ 简化 RocksDB 配置 此前，配置像 RocksDB 这样的堆外 state backend 需要进行大量的手动调试，例如减小 JVM 堆空间、设置 Flink 使用堆外内存等。现在，Flink 的开箱配置即可支持这一切，且只需要简单地改变

flink是当下火热流行的大数据框架，支持高吞吐、低延迟、高性能，自带时间事件，支持有状态计算和窗口操作，支持任务重启从最终计算点开始不必重新运行整个任务。 说完flink特点，开始搭建windows下开发的环境，运行环境如下： 系统：windows10 jdk版本：oracle jdk1.8，最低1.8 scala：2.11.12，2.11是大部分软件的开发版本，适应性强，且比较新。 maven：3.3.3，最低要求3.1 flink：1.9.1 开发工具：idea 2019.3.1 jdk、scala、maven安装方式，自行百度，不在赘述，win+r，可查看到版本接口。 准备好基础环境，进入正题。 1、安装flink 下载地址：https://flink.apache.org/downloads.html#apache-flink-191 选择对应版本，下载即可，下载后的安装包是tgz压缩文件，直接解压到安装路径。 双击运行bin目录下start-cluster.bat文件，flink启动，可以http://localhost:8081看到flink运行页面。 2、创建项目 打开idea，选择File --> New --> Project ，选择mave直接next。 输入项目名和项目路径，点击finish即可。 修改pom.xml指定flink相关配置，内容如下：

维表JOIN-绕不过去的业务场景 在Flink 流处理过程中，经常需要和外部系统进行交互，用维度表补全事实表中的字段。 例如：在电商场景中，需要一个商品的skuid去关联商品的一些属性，例如商品所属行业、商品的生产厂家、生产厂家的一些情况； 在物流场景中，知道包裹id，需要去关联包裹的行业属性、发货信息、收货信息等等。 默认情况下，在Flink的MapFunction中，单个并行只能用同步方式去交互: 将请求发送到外部存储，IO阻塞，等待请求返回，然后继续发送下一个请求。这种同步交互的方式往往在网络等待上就耗费了大量时间。为了提高处理效率，可以增加MapFunction的并行度，但增加并行度就意味着更多的资源，并不是一种非常好的解决方式。 Async I/O异步非阻塞请求 Flink 在1.2中引入了Async I/O，在异步模式下，将IO操作异步化，单个并行可以连续发送多个请求，哪个请求先返回就先处理，从而在连续的请求间不需要阻塞式等待，大大提高了流处理效率。 Async I/O 是阿里巴巴贡献给社区的一个呼声非常高的特性，解决与外部系统交互时网络延迟成为了系统瓶颈的问题。 图中棕色的长条表示等待时间，可以发现网络等待时间极大地阻碍了吞吐和延迟。为了解决同步访问的问题，异步模式可以并发地处理多个请求和回复。也就是说，你可以连续地向数据库发送用户a、b、c等的请求，与此同时

查看日志文件： 2020-01-20 09:31:08,758 ERROR org.apache.flink.runtime.entrypoint.ClusterEntrypoint - Could not start cluster entrypoint StandaloneSessionClusterEntrypoint. org.apache.flink.runtime.entrypoint.ClusterEntrypointException: Failed to initialize the cluster entrypoint StandaloneSessionClusterEntrypoint. at org.apache.flink.runtime.entrypoint.ClusterEntrypoint.startCluster(ClusterEntrypoint.java:182) at org.apache.flink.runtime.entrypoint.ClusterEntrypoint.runClusterEntrypoint(ClusterEntrypoint.java:501) at org.apache.flink.runtime.entrypoint.StandaloneSessionClusterEntrypoint.main

前几天，Flink官方release了Flink1.10版本，这个版本有很多改动。比如： Flink 1.10 同时还标志着对 Blink的整合宣告完成，随着对 Hive 的生产级别集成及对 TPC-DS 的全面覆盖，Flink 在增强流式 SQL 处理能力的同时也具备了成熟的批处理能力。本篇博客将对此次版本升级中的主要新特性及优化、值得注意的重要变化以及使用新版本的预期效果逐一进行介绍。 其中最重要的一个特性之一是：推出了生产可用的 Hive 集成。 Flink 1.9 中推出了预览版的 Hive 集成。该版本允许用户使用 SQL DDL 将 Flink 特有的元数据持久化到 Hive Metastore、调用 Hive 中定义的 UDF 以及读、写 Hive 中的表。Flink 1.10 进一步开发和完善了这一特性，带来了全面兼容 Hive 主要版本的生产可用的 Hive 集成。 笔者就遇到的几个问题，归类总结如下，如果你在生产环境遇到，那么可能带来一些启示： 架构设计 Flink在创建运行环境时会同时创建一个CatalogManager，这个CatalogManager就是用来管理不同的Catalog实例，我们的Flink运行环境就是通过这个访问Hive： 官网给出的例子如下： EnvironmentSettings settings =

作者 | 徐迪、陈俊、敖小剑、宋进超 业界要闻 Apache Flink 1.10.0 发布 作为 Flink 社区迄今为止规模最大的一次版本升级，Flink 1.10 容纳了超过 200 位贡献者对超过 1200 个 issue 的开发实现，包含对 Flink 作业的整体性能及稳定性的显著优化、对原生 Kubernetes 的初步集成（beta 版本）以及对 Python 支持（PyFlink）的重大优化。 Linkerd 2.7 发布 此版本以安全为主题，主要更新亮点包括增加了将 Linkerd 的交叉 TLS 基础与外部证书发行商（如 Vault、cert-manager）集成的支持，改进了 GitOps 工作流，并使其易于自动轮换 TLS 凭据；还改进了 dashboard 的性能，提高了 Helm 图表的可用性。 上游重要进展 Kubernets 1.18 分支本周二正式创建了，code freeze 在 3 月 5 号； graduate PodTopologySpread to beta feature gate PodTopologySpread 升级到 beta 版本。 Provide OIDC discovery for service account token issuer 引入了新的 token issuer，符合 OIDC(OpenID Connect)