flink

# 1 相关博文汇总（持续更新...） https://blog.csdn.net/TXBSW/article/details/84553311 https://blog.csdn.net/yyoc97/article/details/82560926 # 2 github相关开源代码 Scala版本： https://github.com/LinMingQiang/flink-learn/ Java版本： https://github.com/duhanmin/kafka-flink-hbase # 3 详解Hbase及各大公司案例 https://blog.csdn.net/u010834071/article/details/103702898 https://yq.aliyun.com/articles/739650?spm=a2c4e.11153940.0.0.2ee39a48jiKWAo # 4 Flink汉化版API https://ci.apache.org/projects/flink/flink-docs-release-1.9/zh/ops/jobmanager_high_availability.html # 5 云栖大会 https://yunqi.youku.com/2019/hangzhou/review?spm=a2c4e.11165380

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

文章目录 what Parallelism Slot ? Slot 和 Parallelism 的关系 1.Slot 是指 TaskManager 最大能并发执行的能力 2.parallelism 是指 TaskManager 实际使用的并发能力 总结 what Parallelism Slot ? parallelism 是并行的意思 slot 槽位的意思 先来看一张Flink官网中一张经典图 图中 TaskManager 是从 JobManager 处接收需要部署的 Task，任务能配置的最大并行度由 TaskManager 上可用的 Slot决定 Slot 和 Parallelism 的关系 1.Slot 是指 TaskManager 最大能并发执行的能力 Flink 配置文件中设置的一个 TaskManager 默认的Slot 是 1， taskmanager.numberOfTaskSlots: 1 该参数可以根据实际情况做一定的修改。 如上图，如果设置的单个 TaskManager 的 Slot 个数为 3，启动 3 个 TaskManager 后，那么就一共有 9 个 Slot 2.parallelism 是指 TaskManager 实际使用的并发能力 如果在你的 Flink Job 里面不设置任何 parallelism 的话，那么它也会有一个默认的

Flink学习-DataStream-KafkaConnector 摘要 本文主要介绍Flink1.9中的DataStream之KafkaConnector，大部分内容翻译、整理自官网。以后有实际demo会更新。 可参考 kafka-connector 如果关注Table API & SQL中的KafkaConnector，请参考 Flink学习3-API介绍-SQL 1 Maven依赖 FlinkKafkaConnector版本很多，如果使用的Kafka版本0.11以前的版本就必须仔细核对使用的包的版本，而在0.11开始可以使用统一KafkaConnectorApi，会使用该Flink版本发布时的最新Kafka版本，用法如下： < dependency > < groupId > org.apache.flink </ groupId > < artifactId > flink-connector-kafka_2.11 </ artifactId > < version > 1.11-SNAPSHOT </ version > </ dependency > 2 KafkaConsumer 2.1 KafkaConsumer构建 创建一个KafkaConsumer例子： // 1. get streaming runtime val env :

一、Flink版本 flink-1.6.1-bin-hadoop26-scala_2.11 二、Flink任务打包 笔者将写好的flink计算任务代码发到服务器(ubuntu16.04)，在服务器端进行任务的打包 1、将项目工程导入服务器中（mac下） scp -r flink-project root@服务器ip:/wingcloud4/ 2、将flink源码下的tools文件导入到服务器根目录下 读者可以去github自行下载tools文件，在如下位置 然后先进入flink-master再执行命令将tools导入到服务器根目录，命令如下 scp -r tools root@服务器ip:/ 3、在服务器下预先装好maven 因为笔者flink-project这个文件下多个服务，所以笔者需要将flink计算服务打包 4、将flink-project下的flink计算服务进行打包 ps：当然，这里读者按照自己的项目来决定即可 进入后，执行一下打包命令，因为计算服务中有许多测试代码，maven的checkstyle会检查导致失败，所以加上-Dcheckstyle.skip=true可以跳过此类失败，如果有其他服务(例如公共服务被计算服务使用到的话，记得在公共服务目录下进行 mvn clean install打包下) mvn clean assembly:assembly

目录 前言： 1、连续事件处理的目标 2、流处理技术的演变 Lambda 架构概述：优势和局限性 3、初探Flink 批处理与流处理 4、为什么选择Flink 前言： 我们渴望按照流的方式处理数据，但要做好很困难；随着大规模数据在各行各业中出现，难度越来越大。这是一个属于物理学范畴的难题：在大型 分布式系统中，数据一致性和对事件发生顺序的理解必然都是有限的。伴随着方法和技术的演化，我们尽可能使这种局限性不危及商业目标和运营目标。 在这样的背景下， Apache Flink （以下简称 Flink ）应运而生。作为在公共社 区中诞生的开源软件，Flink 为大容量数据提供流处理，并用同一种技术实现批处理。 1、连续事件处理的目标 能够以非常低的延迟处理数据，这并不是流处理的唯一优势。人们希望流 处理不仅做到低延迟和高吞吐，还可以处理中断。优秀的流处理技术应该 能使系统在崩溃之后重新启动，并且产出准确的结果；换句话说，优秀的 流处理技术可以容错，而且能保证 exactly-once 2 。 与此同时，获得这种程度的容错性所采用的技术还需要在没有数据错误的 情况下不产生太大的开销。这种技术需要能够基于事件发生的时间（而不是随意地设置处理间隔）来保证按照正确的顺序跟踪事件。对于开发人员而言，不论是写代码还是修正错误，系统都要容易操作和维护。同样重要的是

一、Checkpoints检查点机制 Flink中基于异步轻量级的分布式快照技术提供了Checkpoints容错机制。快照产生过程非常轻量，高频率创建对Flink任务性能影响相对较小。 Checkpoint配置信息： （1）Checkpoint开启和时间间隔指定 开启检查点并指定检查点时间间隔为1000ms，如果状态比较大，建议适当增加该值 env.enableCheckpointing(1000); （2）设置状态存储后端，支持内存、文件系统和 RocksDB。这里选择文件系统 env.setStateBackend(new FsStateBackend(path)); （3）exactly-once和at-least-once语义选择 可以选择exactly-once语义保证整个应用内端到端的数据一致性，这种情况适合于数据要求比较高，不允许出现丢数据或者数据重复，同时，Flink的性能相对较弱，而at-least-once语义更合适于时延和吞吐量要求非常高但对数据的一致性要求不高的场景。默认情况下使用的是exactly-once模式。 env.getCheckpointConfig().setCheckpointingMode(CheckpointingMode.EXACTLY_ONCE); （4）Checkpoint超时时间

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

本文由贝壳找房的资深工程师刘力云将带来Apache Flink技术在贝壳找房业务中的应用，通过企业开发的实时计算平台案例的分享帮助用户了解Apache Flink的技术特性与应用场景。 **摘要：**Apache Flink 是一个分布式大数据处理引擎，可对有限数据流和无限数据流进行有状态计算。本文由贝壳找房的资深工程师刘力云将带来Apache Flink技术在贝壳找房业务中的应用，通过企业开发的实时计算平台案例的分享帮助用户了解Apache Flink的技术特性与应用场景。 业务规模及演进 下图为贝壳找房的业务场景示意图。最上层为贝壳找房公司最为主体的四大业务：二手房交易、新房交易、租赁业务及装修业务。四大业务运营将产生图示中间部分的四大数据即楼盘字典、交易数据、用户行为日志与后端服务日志。图示最下部分代表公司实时数据采集、实时数据计算的业务模块，本文中的案例将重点介绍数据实时计算部分的设计、实现及应用内容。 发展历程 在2018年初，随着公司埋点治理规范的推进，我们建设了DP实时数据总线，统一承接各种埋点数据流的标准化处理，并对外提供清洗后的实时数据。随着维护的实时任务增加，面临着实时数据流稳定性以及任务管理方面的挑战，于是贝壳大数据部着手研发了Hermes实时计算平台，提供统一的实时任务管理平台。 在2018年10月，我们推出了SQL V1编辑器来方便用户开发实时计算任务

分布式缓存 Flink提供了一个分布式缓存，类似于hadoop，可以使用户在并行函数中很方便的读取本地文件，并把它放在taskmanager节点中，防止task重复拉取。此缓存的工作机制如下：程序注册一个文件或者目录(本地或者远程文件系统，例如hdfs或者s3)，通过ExecutionEnvironment注册缓存文件并为它起一个名称。 当程序执行，Flink自动将文件或者目录复制到所有taskmanager节点的本地文件系统，仅会执行一次。用户可以通过这个指定的名称查找文件或者目录，然后从taskmanager节点的本地文件系统访问它。 其实分布式缓存就相当于spark的广播,把一个变量广播到所有的executor上,也可以看做是Flink的广播流,只不过这里广播的是一个文件. 示例 Step 1 : 注册一个文件,可以使用hdfs上的文件 也可以是本地文件进行测试 Step 2 : 使用文件 注意： 在用户函数中访问缓存文件或者目录(这里是一个map函数)。这个函数必须继承RichFunction,因为它需要使用RuntimeContext读取数据: java分布式缓存代码如下： /** * <p/> DataSet 分布式缓存 </li> * <li>@author: li.pan</li> * <li>Date: 2019/12/29 16:10 下午</li> * <li