Apache Flink

1. 什么是Flink? 官网的定义如下: Apache Flink is a framework and distributed processing engine for stateful computations over unbounded and bounded data streams. Flink has been designed to run in all common cluster environments , perform computations at in-memory speed and at any scale. 从官网的定义我们可以看出 1. 首先，它是一个分布式处理引擎和框架 2. 其次，它进行有状态的计算，针对有界和无界的数据流式计算 这里有几点我想详细解释一下： 2-1) 什么叫有界和无界数据? 有界数据集：有限不会改变的数据集合 无界数据(无穷数据集): 无穷的持续集成的数据集合 那么那些常见的无穷数据集有哪些呢？ 用户与客户端的实时交互数据(用户行为) 应用实时产生的日志 金融市场的实时交易记录 2-2) 什么是流式计算？ 说到流式计算我们就不得不提一下批处理计算，因为它们是不同的东西。 批处理：在预先定义的时间内运行计算，当完成时释放计算机资源 流式：只要数据一直在产生，计算就持续地进行 3.

前言背景 算法优化改版有大需求要上线，在线特征dump数据逐步放量，最终达到现有Kafka集群5倍的流量，预计峰值达到万兆网卡80%左右(集群有几十个物理节点，有几PB的容量，网卡峰值流出流量会达到800MB左右/sec、写入消息QPS为100w+ msgs/sec)。上下游服务需要做扩容评估，提前做好容量规划，保障服务持续稳定运行 L3层 dump特征 @xxx 1.依赖文章特征公共服务 2.依赖用户特征公共服务 前期可以一起共建 评估dump特征数据量 @xxx kafka新增Topic接收dump数据，评估kafka是否需要扩容 @xxx 新增拼接数据流支撑dump特征，需要评估新增机器 @xxx 经过对Kafka集群软硬件资源及利用率综合分析与评估，决定不扩容机器，完全可以应对流量扩大5倍的性能挑战 流量灰度时间表 2020-02-21放量进度 流量灰度10% 2020-02-24放量进度 流量灰度30% 2020-03-02放量进度 流量灰度50% 2020-03-02放量进度 流量灰度70% 2020-03-03放量进度 流量灰度85% 2020-03-05放量进度 流量灰度100% 优化纪实 预先优化在topics创建的情况下，没有流量时做的优化工作 本次在线特征dump放量topics列表如下： onlinefeedback indata_str

3 月，跳不动了？>>> 原文链接： https://flink.apache.org/2019/05/19/state-ttl.html 对于许多状态流式计算程序来说，一个常见的需求是自动清理应用程序的状态（state），以便有效地控制状态大小，或者控制程序访问状态的有效时间（例如受限于诸如GDPR等法律条规）。Apache Flink 自 1.6.0 版本引入了状态的生存时间（time-to-live，TTL）功能，使得应用程序的状态清理和有效的状态大小管理成为可能。 在本文中，我们将讨论引入状态生存时间特性的动机并讨论其相关用例。此外，我们还将演示如何使用和配置该特性。同时，我们将会解释 Flink 如何借用状态生存时间特性在内部管理状态，并对 Flink 1.8.0 中该功能引入的相关新特性进行一些展示。本文章最后对未来的改进和扩展作了展望。 状态的暂时性 有两个主要原因可以解释为什么状态只应该维持有限的时间。先设想一个 Flink 应用程序，它接收用户登录事件流，并为每个用户存储上一次登录时的相关事件信息和时间戳，以改善高频访问用户的体验。 控制状态的大小。 状态生存时间特性的主要使用场景，就是能够有效地管理不断增长的状态大小。通常情况下，数据只需要暂时保存，例如用户处在一次网络连接会话中。当用户访问事件结束时，我们实际上就没有必要保存该用户的状态

3 月，跳不动了？>>> 本文描述了一些配置选项，这些选项将帮助您有效地管理规划 Apache Flink 中 RocksDB state backend 的内存大小。在前面的文章[1]中，我们描述了 Flink 中支持的可选 state backend 选项，本文将介绍跟 Flink 相关的一些 RocksDB 操作，并讨论一些提高资源利用率的重要配置。 Tips ：从 Flink 1.10 开始，Flink 自动管理 RocksDB 的内存，详细介绍如下： https://ci.apache.org/projects/flink/flink-docs-release-1.10/ops/state/state_backends.html#memory-management RocksDB 的状态后端 在深入了解配置参数之前，先回顾一下在 Apache Flink 中如何使用 RocksDB 来进行状态管理。当选择 RocksDB 作为状态后端时，状态将作为序列化字节串存在于堆外内存（off-heap) 存储或本地磁盘中。 RocksDB 是一个以日志合并树( LSM 树）作为索引结构的 KV 存储引擎。当用于在 Flink 中存储 kv 状态时，键由 的序列化字节串组成，而值由状态的序列化字节组成。每次注册 kv 状态时，它都会映射到列族（column-family）

3 月，跳不动了？>>> session cluster和per job 因为是源码分析，所以会分为服务端和客户端两个部分的代码分析，下面我先看服务端<br/> session cluster模式是类似standalone，先去向yarn申请好资源，然后供业务方提交，主要的入口类是YarnSessionClusterEntrypoint(这里指的是服务端的入口)<br/> <br/> 从上图可以看出来，startCluster()方法前后是两个分界线,startCluster之前是获取配置，之后是进行集群相关的创建，包括haService/blobServer/heartBeatService/resourceManger/webMonitorEndpoint。<br/> 这里有一点是需要说明的是有关executionGraphStore， 这里实际有两种，1.将可执行图放在内存中，2.将可执行图持久化到文件。<br/> yarn session：将executionGraph持久化到文件<br/> per job：将executionGraph持久化到文件<br/> 对于per job模式是每个任务对应一个集群，其实就是将上图中的YarnSessionClusterEntrypoint改成YarnJobClusterEntrypoint，其它流程基本一致

3 月，跳不动了？>>> flink yarn flink on yarn有两种模式，分别是session cluster和per job #####session cluster session cluster是一个long running的模式，先拉起一个flink集群，然后大家向这个集群提交任务 集群启动的脚本如下 bin/yarn-session.sh -n4 -jm1024 -tm 4096 -s 2 任务运行模式 同步和异步 主要体现命令的区别在如下 同步 bin/flink run -c mainClass /path/to/user/jar 异步 bin/flink run -d -c mainClass /path/to/user/jar per job per job，是每个任务对应一个集群，每次提交的时候会单独拉一个集群起来，任务run的命令如下 同步 bin/flink run -m yarn-cluster -d -c mainClass /path/to/user/jar 异步 bin/flink run -d -m yarn-cluster -d -c mainClass /path/to/user/jar 来源： oschina 链接： https://my.oschina.net/u/1262062/blog/3210456

3 月，跳不动了？>>> 　　原文链接： 一文弄懂Flink基础理论 　　Flink分布式程序包含2个主要的进程：JobManager和TaskManager.当程序运行时，不同的进程就会参与其中，包括Jobmanager、TaskManager和JobClient。 　　当 Flink 集群启动后，首先会启动一个 JobManger 和一个或多个的 TaskManager。由 Client 提交任务给 JobManager，JobManager 再调度任务到各个 TaskManager 去执行，然后 TaskManager 将心跳和统计信息汇报给 JobManager。TaskManager 之间以流的形式进行数据的传输。上述三者均为独立的 JVM 进程。 JobManager Master进程，负责Job的管理和资源的协调。包括任务调度，检查点管理，失败恢复等。 当然，对于集群HA模式，可以同时多个master进程，其中一个作为leader，其他作为standby。当leader失败时，会选出一个standby的master作为新的leader（通过zookeeper实现leader选举）。 JobManager包含了3个重要的组件： ###（1）Actor系统 Flink内部使用Akka模型作为JobManager和TaskManager之间的通信机制。

3 月，跳不动了？>>> 1.三台机器 配置免密登录,主机名环境 jdk1.8 一主两从 2.tar -zxvf ........... cd conf vi flink-conf.yaml jobmanager.rpc.address: hadoop1 vi slaves hadoop2 hadoop3 3.拷贝修改的文件 scp -rq flink-1.6.1 hadoop2:$PWD scp -rq flink-1.6.1 hadoop3:$PWD 4.启动 bin/start-cluster.sh 5.单个启动 bin/jobmanager.sh start 主节点 bin/taskmanager.sh start 从节点 汇报心跳 来源： oschina 链接： https://my.oschina.net/wyn365/blog/3208825

3 月，跳不动了？>>> 　　原文链接： 一文弄懂Flink基础理论 　　Flink分布式程序包含2个主要的进程：JobManager和TaskManager.当程序运行时，不同的进程就会参与其中，包括Jobmanager、TaskManager和JobClient。 　　当 Flink 集群启动后，首先会启动一个 JobManger 和一个或多个的 TaskManager。由 Client 提交任务给 JobManager，JobManager 再调度任务到各个 TaskManager 去执行，然后 TaskManager 将心跳和统计信息汇报给 JobManager。TaskManager 之间以流的形式进行数据的传输。上述三者均为独立的 JVM 进程。 JobManager Master进程，负责Job的管理和资源的协调。包括任务调度，检查点管理，失败恢复等。 当然，对于集群HA模式，可以同时多个master进程，其中一个作为leader，其他作为standby。当leader失败时，会选出一个standby的master作为新的leader（通过zookeeper实现leader选举）。 JobManager包含了3个重要的组件： ###（1）Actor系统 Flink内部使用Akka模型作为JobManager和TaskManager之间的通信机制。

近年来，随着IT技术与大数据、机器学习、算法方向的不断发展，越来越多的企业都意识到了数据存在的价值，将数据作为自身宝贵的资产进行管理，利用大数据和机器学习能力去挖掘、识别、利用数据资产。 近年来，随着IT技术与大数据、机器学习、算法方向的不断发展，越来越多的企业都意识到了数据存在的价值，将数据作为自身宝贵的资产进行管理，利用大数据和机器学习能力去挖掘、识别、利用数据资产。 如果缺乏有效的数据整体架构设计或者部分能力缺失，会导致业务层难以直接利用大数据大数据，大数据和业务产生了巨大的鸿沟，这道鸿沟的出现导致企业在使用大数据的过程中出现数据不可知、需求难实现、数据难共享等一系列问题，本文介绍了一些数据平台设计思路来帮助业务减少数据开发中的痛点和难点。 我调研了10家公司，写出了这篇文章。 一、大数据技术栈 大数据整体流程涉及很多模块，每一个模块都比较复杂，下图列出这些模块和组件以及他们的功能特性，后续会有专题去详细介绍相关模块领域知识，例如数据采集、数据传输、实时计算、离线计算、大数据储存等相关模块。 二、lambda架构和kappa架构 目前基本上所有的大数据架构都是基于lambda和kappa架构，不同公司在这两个架构模式上设计出符合该公司的数据体系架构。lambda 架构使开发人员能够构建大规模分布式数据处理系统。 它具有很好的灵活性和可扩展性