Apache Flink

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 8月22日，Apache Flink 1.9.0 正式发布，早在今年1月，阿里便宣布将内部过去几年打磨的大数据处理引擎Blink进行开源并向 Apache Flink 贡献代码。当前 Flink 1.9.0是阿里内部版本 Blink 合并入 Flink 后的首次发版，修改代码150万行，此次发版不仅在结构上有重大变更，在功能特性上也更加强大与完善。本文将为大家介绍 Flink 1.9.0 有哪些重大变更与新增功能特性。 在此先简单回顾一下阿里巴巴 Blink 开源的部分要点： Blink 开源的内容主要是阿里巴巴基于开源 Flink 引擎，依托集团内部业务，在流计算和批处理上积累的大量新功能、性能优化、稳定性提升等核心代码 Blink 以分支的形式开源，即开源后会成为 Apache Flink 项目下的一个分支。 Blink 开源的目标不是希望成为另一个活跃的项目，而是将 Flink 做的更好。通过开源的方式让大家了解所有 Blink 的实现细节，提高 Blink 功能merge进入 Flink 的效率，与社区协作更高效。 半年的时间过去了，随着 Flink 1.9.0 版本的发布，在此我们可以骄傲的宣布：Blink 团队已经实现了之前的诺言！尽管不是所有功能都顺利 merge 回了社区

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 过去无论您是在生产中使用，还是调研Apache Flink，估计您总是会问这样一个问题：我该如何访问和更新Flink保存点（savepoint）中保存的state？不用再询问了，Apache Flink 1.9.0引入了状态处理器（ State Processor ）API，它是基于DataSet API的强大扩展，允许读取，写入和修改Flink的保存点和检查点（checkpoint）中的状态。 在这篇文章中，我们将解释为什么此功能对Flink来说很重要，以及该功能的用途和用法。最后，我们将讨论状态处理器API的未来规划，以保持与Flink批流统一的未来整体规划一致。 截止到Apache Flink 1.9的状态流处理现状 几乎所有复杂的流处理应用程序都是有状态的，其中大多数都是设计为运行数月甚至数年。随着时间的推移，这些作业积累了很多有价值的状态，如果由于故障而丢失，这些状态的重建将变得代价很高甚至是不可能的。为了保证应用程序状态的一致性和持久性，Flink从一开始就设计了一套复杂巧妙的检查点和恢复机制。在每一个版本中，Flink社区都添加了越来越多与状态相关的特性，以提高检查点执行和恢复的速度、改进应用程序的维护和管理。 然而，Flink用户经常会提出能够“从外部”访问应用程序的状态的需求

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 背景 消息报表主要用于统计消息任务的下发情况。比如，单条推送消息下发APP用户总量有多少，成功推送到手机的数量有多少，又有多少APP用户点击了弹窗通知并打开APP等。通过消息报表，我们可以很直观地看到消息推送的流转情况、消息下发到达成功率、用户对消息的点击情况等。 个推在提供消息推送服务时，为了更好地了解每天的推送情况，会从不同的维度进行数据统计，生成消息报表。个推每天下发的消息推送数巨大，可以达到数百亿级别，原本我们采用的离线统计系统已不能满足业务需求。随着业务能力的不断提升，我们选择了Flink作为数据处理引擎，以满足对海量消息推送数据的实时统计。 本文将主要阐述选择Flink的原因、Flink的重要特性以及优化后的实时计算方法。 离线计算平台架构 在消息报表系统的初期，我们采用的是离线计算的方式，主要采用spark作为计算引擎，原始数据存放在HDFS中，聚合数据存放在Solr、Hbase和Mysql中： 查询的时候，先根据筛选条件，查询的维度主要有三个： appId 下发时间 taskGroupName 根据不同维度可以查询到taskId的列表，然后根据task查询hbase获取相应的结果，获取下发、展示和点击相应的指标数据。在我们考虑将其改造为实时统计时，会存在着一系列的难点： 原始数据体量巨大

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> API接口访问频次限制 / 网站恶意爬虫限制 / 网站恶意访问限制 方案 采用多级拦截,后置拦截的方式体系化解决 1 分层拦截 1.1 第一层 商业web应用防火墙(WAF) 直接用商业服务 传统的F5硬件,不过现在用的很少了 云时代就用云时代的产品,典型代表 阿里云 web应用防火墙 1.2 第二层 API 网关(API Gateway)层 API 网关(API Gateway) kong为代表的开源 API 网关 实现 openresty + lua 自实现 windows平台 安全狗、云锁 实现 1.3 第三层 应用层 用Redis内置lua脚本 redis是块砖,哪里需要哪里搬 redis内置了lua引擎,2.6版本后你可以编写一段lua脚本,完成逻辑判断流程 常见的有对某维度计数器法 对某维度令牌桶法 维度的概念比如就是IP或者IP+模块等, 多个字段合并成一个维度 本方案满足绝大多数应用层的限流需求 当然也可以自己用应用层程序实现,前提是redis+lua满足不了你的需求 2 后置拦截 基本的套路其实很简单,从日志这里计算出恶意IP,恶意用户,再给其他系统用 分控的基本思想也是这样的 已经在用ELK日志系统:可以用ES中定时查询高频IP,送入WAF做拦截 已经在用流计算系统

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> Zepplin是一个很有意思的笔记本，支持众多interpreter，包括Flink。在网上找了很多资料，发现直接使用二进制包，或者从源码编译，均无法向Flink 1.7.1提交作业。0.81和0.9.0-SNAPHOST都试过。跟同事咨询了一下，找到一个Zeppelin+Blink的镜像，体验特别好。 $ docker run -d -p 8085:8085 -p 8091:8091 zjffdu/zeppelin-blink:latest <java:1.8> Unable to find image 'zjffdu/zeppelin-blink:latest' locally latest: Pulling from zjffdu/zeppelin-blink 7b722c1070cd: Already exists 5fbf74db61f1: Already exists ed41cb72e5c9: Already exists 7ea47a67709e: Already exists a3e223183687: Downloading [=========> ] 26.18MB/131.6MB a3e223183687: Downloading [===========> ] 30.42MB/131

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 前言 之前写了不少 Flink 文章了，也有不少 demo，但是文章写的时候都是在本地直接运行 Main 类的 main 方法，其实 Flink 是支持在 UI 上上传 Flink Job 的 jar 包，然后运行得。最开始在第一篇 《从0到1学习Flink》—— Mac 上搭建 Flink 1.6.0 环境并构建运行简单程序入门 中其实提到过了 Flink 自带的 UI 界面，今天我们就来看看如何将我们的项目打包在这里发布运行。 准备 编译打包 项目代码就拿我之前的文章 《从0到1学习Flink》—— Flink 写入数据到 ElasticSearch 吧，代码地址是在 GitHub 仓库地址： https://github.com/zhisheng17/flink-learning/tree/master/flink-learning-connectors/flink-learning-connectors-es6 ，如果感兴趣的可以直接拿来打包试试水。 我们在整个项目 （flink-learning）pom.xml 所在文件夹执行以下命令打包： 1 mvn clean install 然后你会发现在 flink-learning-connectors-es6 的 target 目录下有 flink

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 前言 前面 FLink 的文章中我们已经介绍了说 Flink 已经有很多自带的 Connector。 1、 《从0到1学习Flink》—— Data Source 介绍 2、 《从0到1学习Flink》—— Data Sink 介绍 其中包括了 Source 和 Sink 的，后面我也讲了下如何自定义自己的 Source 和 Sink。 那么今天要做的事情是啥呢？就是介绍一下 Flink 自带的 ElasticSearch Connector，我们今天就用他来做 Sink，将 Kafka 中的数据经过 Flink 处理后然后存储到 ElasticSearch。 准备 安装 ElasticSearch，这里就忽略，自己找我以前的文章，建议安装 ElasticSearch 6.0 版本以上的，毕竟要跟上时代的节奏。 下面就讲解一下生产环境中如何使用 Elasticsearch Sink 以及一些注意点，及其内部实现机制。 Elasticsearch Sink 添加依赖 1 2 3 4 5 <dependency> <groupId>org.apache.flink</groupId> <artifactId>flink-connector-elasticsearch6_${scala.binary.version}

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> flink是一款开源的大数据流式处理框架，他可以同时批处理和流处理，具有容错性、高吞吐、低延迟等优势，本文简述flink的编程模型。 数据集类型： 无穷数据集：无穷的持续集成的数据集合 有界数据集：有限不会改变的数据集合 常见的无穷数据集有： 用户与客户端的实时交互数据 应用实时产生的日志 金融市场的实时交易记录 … 数据运算模型有哪些呢？ 流式：只要数据一直在生产，计算就持续地运行 批处理：在预先定义的时间内运行计算，当完成时候释放计算机资源 Flink它可以处理有界的数据集，也可以处理无界的数据集，它可以流式的处理数据，也可以批量的处理数据。 Flink是什么？ 从下至上： 1、部署：Flink 支持本地运行、能在独立集群或者在被 YARN 或 Mesos 管理的集群上运行， 也能部署在云上。 2、运行：Flink 的核心是分布式流式数据引擎，意味着数据以一次一个事件的形式被处理。 3、API：DataStream、DataSet、Table、SQL API。 4、扩展库：Flink 还包括用于复杂事件处理，机器学习，图形处理和 Apache Storm 兼容性的专用代码库。 Flink 数据流编程模型 抽象级别 Flink提供了不同的抽象级别以开发流式或者批处理应用 最底层提供了有状态流

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 手淘推荐简介 手淘推荐的快速发展源于2014年阿里“All in 无线”战略的提出。在无线时代，手机屏幕变小，用户无法同时浏览多个视窗，交互变得困难，在这样的情况下，手淘借助个性化推荐来提升用户在无线端的浏览效率。经过近几年的发展，推荐已经成为手淘上面最大的流量入口，每天服务数亿用户，成交量仅次于搜索，成为了手淘成交量第二大入口。 今天的推荐不仅仅包含商品，还包含了直播、店铺、品牌、UGC，PGC等，手淘整体的推荐物种十分丰富，目前手淘的整体推荐场景有上百个。推荐与搜索不同，搜索中用户可以主动表达需求，推荐很少和用户主动互动，或者和用户互动的是后台的算法模型，所以推荐从诞生开始就是大数据+AI的产品。 手淘推荐特点 相比于其他推荐产品，手淘推荐也有自身的如下特点： 1. 购物决策周期 ：手淘推荐的主要价值是挖掘用户潜在需求和帮助用户购买决策，用户的购物决策周期比较长，需要经历需求发现,信息获取，商品对比和下单决策的过程，电商推荐系统需要根据用户购物状态来做出推荐决策。 2. 时效性 ：我们一生会在淘宝购买很多东西，但是这些需求通常是低频和只在很短的时间窗口有效，比如手机1~2才买一次但决策周期只有几小时到几天，因此需要非常强的时效性，需要快速地感知和捕获用户的实时兴趣和探索未知需求,因此

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 作者：孙金城（金竹） 我们知道 PyFlink 是在 Apache Flink 1.9 版新增的，那么在 Apache Flink 1.10 中 Python UDF 功能支持的速度是否能够满足用户的急切需求呢？ Python UDF 的发展趋势 直观的判断，PyFlink Python UDF 的功能也可以如上图一样能够迅速从幼苗变成大树，为啥有此判断，请继续往下看… Flink on Beam 我们都知道有 Beam on Flink 的场景，就是 Beam 支持多种 Runner，也就是说 Beam SDK 编写的 Job 可以运行在 Flink 之上。如下图所示： 上面这图是 Beam Portability Framework 的架构图，他描述了 Beam 如何支持多语言，如何支持多 Runner，单独说 Apache Flink 的时候我们就可以说是 Beam on Flink，那么怎么解释 Flink on Beam 呢？ 在 Apache Flink 1.10 中我们所说的 Flink on Beam 更精确的说是 PyFlink on Beam Portability Framework。我们看一下简单的架构图，如下： Beam Portability Framework