Apache Flink

去年 11 月的 Flink Forward Asia 2019（以下简称 FFA） 上 Flink 社区提出了未来发展的几个主要方向，其中之一就是拥抱 AI [1]。实际上，近年来 AI 持续火热，各种计算框架、模型和算法层出不穷，从某种角度上来说，这个赛道已经有些拥挤了。在这种情况下， Flink 将怎样拥抱 AI，又会为用户带来什么新的价值？Flink AI 的优劣势分别在哪里？本文将通过对这些问题的讨论来分析 Flink AI 的发展方向。 Lambda 架构，流批统一和 AI 实时化 Flink 在 AI 中的价值其实和大数据中 Lambda 架构[2]和流批统一这两个概念有关系，Flink 为大数据实时化带来的价值也将同样使 AI 受益。 不妨让我们简单回顾一下大数据的发展过程。从 Google 奠基性的“三架马车” 3[5] 论文发表后的很长一段时间内，大数据的发展主线上都只有批计算的身影。后来随着大家认识到数据时效性的重要作用，Twitter 开源的流计算引擎 Storm [6] 红极一时，各种流计算引擎也纷纷登场，其中也包括了 Flink。由于成本、计算准确性和容错性等方面的考虑，各家企业纷纷使用起了被称为 Lambda 架构的解决方案，在同一个架构下融合批计算和流计算，以便在成本，容错和数据时效性之间达到一个平衡。 Lambda

千呼万唤始出来，在 Kubernetes 如火如荼的今天，Flink 社区终于在 1.10 版本提供了对 Kubernetes 的原生支持，也就是 Native Kubernetes Integration 。不过还只是Beta版本，预计会在 1.11 版本里面提供完整的支持。 我们知道，在 Flink 1.9 以及之前的版本里面，如果要在 Kubernetes 上运行 Flink 任务是需要事先指定好需要的 TaskManager(TM) 的个数以及CPU和内存的。这样的问题是：大多数情况下，你在任务启动前根本无法精确的预估这个任务需要多少个TM。如果指定的TM多了，会导致资源浪费；如果指定的TM个数少了，会导致任务调度不起来。本质原因是在 Kubernetes 上运行的 Flink 任务并没有直接向 Kubernetes 集群去申请资源。 Flink 在 1.10 版本完成了 Active Kubernetes Integration 的第一阶段，支持了 session clusters。后续的第二阶段会提供更完整的支持，如支持 per-job 任务提交，以及基于原生 Kubernetes API 的高可用，支持更多的 Kubernetes 参数如 toleration, label 和 node selector 等。 Active Kubernetes

摘要：本文由 bilibili 大数据实时平台负责人郑志升分享，基于对 bilibili 实时计算的痛点分析，详细介绍了 bilibili Saber 实时计算平台架构与实践。本次分享主要围绕以下四个方面： 一、实时计算的痛点 二、Saber 的平台演进 三、结合 AI 的案例实践 四、未来的发展与思考 重要：点击「 PPT 」可下载 Flink Forward Asia 大会全部PPT。 一、实时计算的痛点 1.痛点 各个业务部门进行业务研发时都有实时计算的需求。早期，在没有平台体系做支撑时开发工作难度较大，由于不同业务部门的语言种类和体系不同，导致管理和维护非常困难。其次，bilibili 有很多关于用户增长、渠道投放的分析等 BI 分析任务。而且还需要对实时数仓的实时数据进行清洗。此外，bilibili 作为一个内容导向的视频网站，AI 推荐场景下的实时计算需求也比较强烈。 2.痛点共性 开发门槛高 ：基于底层实时引擎做开发，需要关注的东西较多。包括环境配置、语言基础，而编码过程中还需要考虑数据的可靠性、代码的质量等。其次，市场实时引擎种类多样，用户选择有一定困难。 运维成本高 ：运维成本主要体现在两方面。首先是作业稳定性差。早期团队有 Spark 集群、YARN 集群，导致作业稳定性差，容错等方面难以管理。其次，缺乏统一的监控告警体系，业务团队需要重复工作，如计算延时、断流

事件时间与水印 所谓事件时间，就是Flink DataStream中的数据元素自身带有的、在其实际发生时记录的时间戳，具有业务含义，并与系统时间独立。很显然，由于外部系统产生的数据往往不能及时、按序到达Flink系统，所以事件时间比处理时间有更强的不可预测性。为了能够准确地表达事件时间的处理进度，就必须用到水印。 Flink水印的本质是DataStream中的一种特殊元素，每个水印都携带有一个时间戳。当时间戳为T的水印出现时，表示事件时间t <= T的数据都已经到达，即水印后面应该只能流入事件时间t > T的数据。也就是说，水印是Flink判断迟到数据的标准，同时也是窗口触发的标记。 为了形象地说明水印的作用，参考一下下面的图，是一个乱序的基于事件时间的数据流示例。 https://www.ververica.com/blog/how-apache-flink-enables-new-streaming-applications-part-1 图中的方框就是数据元素，其中的数字表示事件时间，W(x)就表示时间戳是x的水印，并有长度为4个时间单位的滚动窗口。假设时间单位为秒，可见事件时间为2、3、1s的元素都会进入区间为[1s, 4s]的窗口，而事件时间为7s的元素会进入区间为[5s, 8s]的窗口。当水印W(4)到达时，表示已经没有t <= 4s的元素了，[1s, 4s

最近这段时间一直在忙新集群迁移，上了最新的cdh6.3.0 于是Flink 提交遇到了许多的问题，还好有cloudera License 有了原厂的帮助和社区的伙伴，问题解决起来快了不少。 集群具体情况是 CDH6.3.0+Flink1.8.1,整个数据平台全部组件都上了kerberos和ldap因为要过认证，所以任务提交方法我们选择统一Oozie提交任务，并且因为kerberos认证，还需要Flink perjob 需要单独的keytab，才能细粒度的控制权限，因为我们现在部门之间计算资源的划分是通过yarn资源队列，但是现在Flink支持的不是很好，目前只能在配置文件中配置一个keytab，job启动都去这个拉这个keytab复制到自己的contain里面，但是Flink第一提交方式还是希望能够通过oozie提交job，由于oozie没有天生支持Flink提交，所以只能选择oozie shell action 的方式提交job。 在Flink搭建好以后开始提交任务，用oozie shell提交： #！/bin/bash flink run -m yarn-cluster flinktest.jar 马上 Duang ！ flink command not find 改成命令绝对路径以后，还是 Duang！ org.apache.flink.client.deployment

Apache Flink社区宣布Flink 1.10.0正式发布！ 本次Release版本修复1.2K个问题，对Flink作业的整体性能和稳定性做了重大改进，同时增加了对K8S，Python的支持。 这个版本标志着与Blink集成的完成，并且强化了流式SQL与Hive的集成，本文将详细介绍新功能和主要的改进。 一、内存管理优化 原有TaskExecutor 有一些缺点： 流处理和批处理用了不同的配置模型； 流处理的堆外配置RocksDB复杂，需要用户配置； 为了使内存管理更明确直观，Flink 1.10对TaskExecutor内存模型和配置做了重大改进，这个更改使FLink更适合于各种部署环境：K8S，Yarn，Mesos。 这种更改统一了入口点，使得下游框架比如zeppelin的编程更加容易。 二、集成Kubernetes 这对于想要在容器中使用Flink的用户是一个非常好的消息。 在Flink1.10中推出了 Active Kubernetes集成 Flink的ResourceManager（ K8sResMngr ）与Kubernetes进行本地通信以按需分配新的Pod，类似于Flink的Yarn和Mesos集成。用户还可以利用命名空间为聚合资源消耗有限的多租户环境启动Flink集群。事先配置具有足够权限的RBAC角色和服务帐户。

今天介绍的这位好友是我们的群主【王知无】，从大数据到Java到Scala再到Python，他都略知一二。【文末有二维码】 2019年开始写大数据成神之路系列，包含Java基础、Haoop系列、Spark系列、Flink系列等等，目的是帮助那些大数据新手或者Java转行大数据的同学们快速掌握大数据知识。 2019年群主同学在公众号和Github更新了近200篇系列文章，还一对一的帮助了大概50名同学修改简历，简直是棒棒哒。其中有多名读者成功入职BAT等公司。 2020年他还打算在公众号更新【全套大数据面试题】，目的是帮助更多人学习进入大数据领域。 如果你也在学习大数据，学习Java，对算法感兴趣。那么赶紧看看他的 《大数据技术与架构，19年文章精选》 快点关注他的公众号吧！ 你也可以加他好友，备注【交流】，让他拉你进大数据交流群，关注大数据成神之路！ 声明：本号所有文章除特殊注明，都为原创，公众号读者拥有优先阅读权，未经作者本人允许不得转载，否则追究侵权责任。 关注我的公众号，后台回复【JAVAPDF】获取200页面试题！ 5万人关注的大数据成神之路，不来了解一下吗？ 5万人关注的大数据成神之路，真的不来了解一下吗？ 5万人关注的大数据成神之路，确定真的不来了解一下吗？ 欢迎您关注 《大数据成神之路》 来源： oschina 链接： https://my.oschina.net

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> Flink是什么？ Flink是一个框架，是一个用于有限（bounded）或者无限（unbounded）数据流上进行有状态计算的分布式处理引擎。 处理框架 Flink的软件栈如图一所示，其核心是distributed dataflow engine用于执行数据流处理程序。Flink运行时程序是一个通过有状态的算子连接的数据流的有向无环图（DAG），对上提供有限数据流的DataSet API和无限数据流的DataStream API。 如图二所示，Flink集群包含三类角色，client、JobManager和TaskManager。client将数据处理程序转换为DAG图并提交到JobManager。JobManager协调程序的执行，并跟踪每一个算子的状态以实现故障恢复。TaskManager从JobManager处接收需要部署的Task，负责具体数据处理程序的执行，一个TaskManager执行一个或者多个算子处理数据流，并将状态上报至JobManager。 这里的算子就是一个独立数据处理程序，常用的有map、flatmap、keyBY、sum、apply、reduce、window等。其中，map和flatMap的区别是map是一对一的映射，既一个输入对应一个输出。faltMap是一对多映射

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 在Flink中管理大量的状态--增量式的检查点的介绍 本文由 Flink 博客 翻译而来，为了叙述的可读性和流畅性，笔者做了少量的修改。 Apache Flink是为了“有状态”的处理流式数据建立的。那么，在流式计算程序中，状态的含义是什么？ 我在前面的 博客 中做了“状态”以及 “有状态的流式处理”的定义。这里回顾一下，状态指的是，在程序中，Operator将过去处理过的event信息保存在内存中， 这样可以在之后的处理中使用。 “状态”是一个基础的功能，使得在流式计算中复杂的用户使用场景成为可能。在 Flink 文档 中列举 了一些例子。 程序需要查找某些固定的模式的事件，“状态”保存了至今接收到的事件流。 程序需要每分钟做聚合操作，“状态”缓存等待聚合的数据 程序需要基于流式的数据进行模型训练，“状态”保存当前版本的模型参数。 但是，只有“状态”拥有容错能力，这样才能在生产环境使用。“容错性”意味着，即使有软件或者机器的故障，最终的计算结果也是精确的，没有数据丢失也没有重复处理。 Flink的容错特性非常强大，它不仅对软件和机器的负载很小，并且也提供了“端到端仅一次”的消息传递保证。 Flink程序容错机制的核心是检查点。Flink的检查点是一个全局的、异步的程序快照，它周期性的生成并送到持久化存储

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 简介 Flink本身为了保证其高可用的特性，以及保证作用的Exactly Once的快速恢复，进而提供了一套强大的Checkpoint机制。 Checkpoint机制是Flink可靠性的基石，可以保证Flink集群在某个算子因为某些原因(如异常退出)出现故障时，能够将整个应用流图的状态恢复到故障之前的某一状态，保 证应用流图状态的一致性。Flink的Checkpoint机制原理来自“Chandy-Lamport algorithm”算法 (分布式快照算法)。 Checkpoint的执行流程 每个需要checkpoint的应用在启动时，Flink的JobManager为其创建一个 CheckpointCoordinator，CheckpointCoordinator全权负责本应用的快照制作。 CheckpointCoordinator周期性的向该流应用的所有source算子发送barrier； 当某个source算子收到一个barrier时，便暂停数据处理过程，然后将自己的当前状 态制作成快照，并保存到指定的持久化存储中，最后向CheckpointCoordinator报告 自己快照制作情况，同时向自身所有下游算子广播该barrier，恢复数据处理； 下游算子收到barrier之后，会暂停自己的数据处理过程