Apache Flink

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 序 转眼之间2019年就要过去了，又是到了写总结的时候了。 盘点 去年定了要深入研究流式计算及系统架构，现在看来，流式计算只粗略看了点flink，系统架构方面貌似也没有太多的长进，文章也写的越来越像流水账了，感觉有点惭愧。 展望 新的一年在新技术方面要研究容器化，在基础方面也得巩固一下linux、network等，最后在架构领域方面也要有新的长进。 文章导航 flink 聊聊flink的window操作 聊聊flink的Tumbling Window 聊聊flink的Sliding Window 聊聊flink的Session Window 聊聊flink的Global Window 聊聊flink的Triggers 聊聊flink的Evictors 聊聊flink的Allowed Lateness 聊聊flink的consecutive windowed operations 聊聊flink DataStream的join操作 聊聊flink KeyedStream的intervalJoin操作 聊聊flink DataStream的window coGroup操作 聊聊flink DataStream的connect操作 聊聊flink DataStream的split操作 聊聊flink

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 简介： 本文将介绍携程实时智能异常检测平台——Prophet。到目前为止，Prophet 基本覆盖了携程所有业务线，监控指标的数量达到 10K+，覆盖了携程所有订单、支付等重要的业务指标。Prophet 将时间序列的数据作为数据输入，以监控平台作为接入对象，以智能告警实现异常的告警功能，并基于 Flink 实时计算引擎来实现异常的实时预警，提供一站式异常检测解决方案。 作者：潘国庆@携程 一、背景介绍 1.规则告警带来的问题 大部分监控平台是基于规则告警实现监控指标的预警。规则告警一般基于统计学，如某个指标同比、环比连续上升或下降到一定阈值进行告警。规则告警需要用户较为熟悉业务指标的形态，从而较为准确的配置告警阈值，这样带来的问题是配置规则告警非常繁琐、告警效果也比较差，需要大量人力物力来维护规则告警。 当一个告警产生时，也需要耗费许多人力验证告警是否正确并确认是否需要重新调整阈值。在携程，规则告警还涉及了其它问题，比如携程仅公司级别的监控平台就有三个，每个业务部门还会根据自己的业务需求或业务场景构建自己的监控平台。携程内部有十几个不同规模的监控平台，在每一个监控平台都配置监控指标，对于用户是非常繁琐的。 二、Prophet 针对规则告警存在的以上几种问题，携程构建了自己的实时智能异常检测平台——

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> Kuiper 团队宣布发布 Kuiper 0.1。Kuiper 0.1 可以从这里下载 。 EMQ X Kuiper 是 Golang 实现的轻量级物联网边缘分析、流式处理开源软件，可以运行在各类资源受限的边缘设备上。Kuiper 设计的一个主要目标就是将在云端运行的实时流式计算框架（比如 Apache Spark ， Apache Storm 和 Apache Flink 等）迁移到边缘端。Kuiper 参考了上述云端流式处理项目的架构与实现，结合边缘流式数据处理的特点，采用了编写基于 源 (Source) ， SQL (业务逻辑处理) , 目标 (Sink) 的规则引擎来实现边缘端的流式数据处理。 网址： https://www.emqx.io/products/kuiper Github仓库： https://github.com/emqx/kuiper 概览 功能 性能优化 提供了针对 Kuiper 规则设置并发度的配置选项，在不同的场景下可以对其优化 在 source 里的 concurrency 设置：设置运行的协程数，默认值为1。如果设置协程数大于1，必须使用共享订阅模式。 在 sink 里的 concurrency 设置：设置运行的线程数。该参数值大于1时，消息发出的顺序可能无法保证。 在

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 一、美团点评实时计算演进 美团点评实时计算演进历程 在 2016 年，美团点评就已经基于 Storm 实时计算引擎实现了初步的平台化。2017 年初，我们引入了 Spark Streaming 用于特定场景的支持，主要是在数据同步场景方面的尝试。在 2017 年底，美团点评实时计算平台引入了 Flink。相比于 Storm 和 Spark Streaming，Flink 在很多方面都具有优势。这个阶段我们进行了深度的平台化，主要关注点是安全、稳定和易用。从 19 年开始，我们致力于建设包括实时数仓、机器学习等特定场景的解决方案来为业务提供更好的支持。 实时计算平台 目前，美团点评的实时计算平台日活跃作业数量为万级，高峰时作业处理的消息量达到每秒 1.5 亿条，而机器规模也已经达到了几千台，并且有几千位用户正在使用实时计算服务。 实时计算平台架构 如下图所示的是美团点评实时计算平台的架构。 最底层是 收集层 ，这一层负责收集用户的实时数据，包括 Binlog、后端服务日志以及 IoT 数据，经过日志收集团队和 DB 收集团队的处理，数据将会被收集到 Kafka 中。这些数据不只是参与实时计算，也会参与离线计算。 收集层之上是 存储层 ，这一层除了使用 Kafka 做消息通道之外，还会基于 HDFS

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> Apache Flink是什么？ 在当代数据量激增的时代，各种业务场景都有大量的业务数据产生，对于这些不断产生的数据应该如何进行有效的处理，成为当下大多数公司所面临的问题。随着雅虎对hadoop的开源，越来越多的大数据处理技术开始涌入人们的视线，例如目前比较流行的大数据处理引擎Apache Spark,基本上已经取代了MapReduce成为当前大数据处理的标准。但是随着数据的不断增长，新技术的不断发展，人们逐渐意识到对实时数据处理的重要性。相对于传统的数据处理模式，流式数据处理有着更高的处理效率和成本控制能力。Flink 就是近年来在开源社区不断发展的技术中的能够同时支持高吞吐、低延迟、高性能的分布式处理框架。 https://img2018.cnblogs.com/blog/1089984/201911/1089984-20191118101924177-357668057.jpg 数据架构的演变 https://img2018.cnblogs.com/blog/1089984/201911/1089984-20191118101924451-1484200707.jpg 如图所示，传统的单体数据架构最大的特点便是 集中式数据存储，大多数将架构分为计算层和存储层。 单体架构的初期效率很高，但是随着时间的推移

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 双11大屏 每年天猫双十一购物节，都会有一块巨大的实时作战大屏，展现当前的销售情况。 这种炫酷的页面背后，其实有着非常强大的技术支撑，而这种场景其实就是实时报表分析。 实时报表分析是近年来很多公司采用的报表统计方案之一，其中最主要的应用就是实时大屏展示。利用流式计算实时得出结果直接被推送到前端应用，实时显示出重要指标的变换情况。最典型的案例便是淘宝双十一活动，每年双十一购物节，除疯狂购物外，最引人注目的就是双十一大屏不停跳跃的成交总额。在整个计算链路中包括从天猫交易下单购买到数据采集，数据计算，数据校验，最终落到双十一大屏上展示的全链路时间压缩在5秒以内，顶峰计算性能高达数三十万笔订单/秒，通过多条链路流计算备份确保万无一失。 而在其他行业，企业也在构建自己的实时报表系统，让企业能够依托于自身的业务数据，快速提取出更多的数据价值，从而更好的服务于企业运行过程中。 而这种高性能，高可用的准确的流处理框架就非Flink莫属了。 Apache Flink是什么？ ​ 在当代数据量激增的时代，各种业务场景都有大量的业务数据产生，对于这些不断产生的数据应该如何进行有效的处理，成为当下大多数公司所面临的问题。Apache Flink 是一个开源的分布式，高性能，高可用，准确的流处理框架。支持实时流处理和批处理 。

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 一、背景介绍 1.规则告警带来的问题 大部分监控平台是基于规则告警实现监控指标的预警。规则告警一般基于统计学，如某个指标同比、环比连续上升或下降到一定阈值进行告警。规则告警需要用户较为熟悉业务指标的形态，从而才能较为准确的配置告警阈值，这样带来的问题是配置规则告警非常繁琐、告警效果也比较差，需要大量人力物力来维护规则告警。当一个告警产生时，也需要耗费许多人力验证告警是否正确并确认是否需要重新调整阈值。在携程，规则告警还涉及了其它问题，比如携程光公司级别的监控平台就有三个，每个业务部门还会根据自己的业务需求或业务场景构建自己的监控平台。携程内部有十几个不同规模的监控平台，在每一个监控平台都配置监控指标对于用户是非常繁琐的。 二、Prophet 针对规则告警存在的以上几种问题，携程构建了自己的实时智能异常检测平台——Prophet。携程构建Prophet的灵感源于FaceBook的Prophet，但实现上有别于FaceBook的Prophet。 1.一站式异常检测解决方案 首先，Prophet以时间序列类型的数据作为数据输入。其次，Prophet以监控平台作为接入对象，以去规则化为目标。基于深度学习算法实现异常的智能检测，基于实时计算引擎实现异常的实时检测，提供了统一的异常检测解决方案。 2.Prophet系统架构

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 分析痛点 笔者线上有一个 Flink 任务消费 Kafka 数据，将数据转换后，在 Flink 的 Sink 算子内部调用第三方 api 将数据上报到第三方的数据分析平台。这里使用批量同步 api，即：每 50 条数据请求一次第三方接口，可以通过批量 api 来提高请求效率。由于调用的外网接口，所以每次调用 api 比较耗时。假如批次大小为 50，且请求接口的平均响应时间为 50ms，使用同步 api，因此第一次请求响应以后才会发起第二次请求。请求示意图如下所示： 平均下来，每 50 ms 向第三方服务器发送 50 条数据，也就是每个并行度 1 秒钟处理 1000 条数据。假设当前业务数据量为每秒 10 万条数据，那么 Flink Sink 算子的并行度需要设置为 100 才能正常处理线上数据。从 Flink 资源分配来讲，100 个并行度需要申请 100 颗 CPU，因此当前 Flink 任务需要占用集群中 100 颗 CPU 以及不少的内存资源。请问此时 Flink Sink 算子的 CPU 或者内存压力大吗？ 上述请求示意图可以看出 Flink 任务发出请求到响应这 50ms 期间，Flink Sink 算子只是在 wait，并没有实质性的工作。因此，CPU 使用率肯定很低，当前任务的瓶颈明显在网络 IO

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 来源： oschina 链接： https://my.oschina.net/u/3677987/blog/3147168

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 8月22日，Apache Flink 1.9.0 版本正式发布，这也是阿里内部版本 Blink 合并入 Flink 后的首次版本发布。此次版本更新带来的重大功能包括批处理作业的批式恢复，以及 Table API 和 SQL 的基于 Blink 的新查询引擎（预览版）。同时，这一版本还推出了 State Processor API，这是社区最迫切需求的功能之一，该 API 使用户能够用 Flink DataSet 作业灵活地读写保存点。此外，Flink 1.9 还包括一个重新设计的 WebUI 和新的 Python Table API （预览版）以及与 Apache Hive 生态系统的集成（预览版）。 Apache Flink 项目的目标是开发一个流式处理系统，以统一和支持多种形式的实时和离线数据处理应用程序以及事件驱动的应用程序。在此版本中，我们在这方面取得了巨大的进步，将 Flink 的流处理和批处理能力集成在了统一的运行时之上。 本文将描述所有主要的新功能、改进、重要变化、以及未来的发展计划。有关更多详细信息，请查看 完整版变更日志 。 Flink 1.9 版本的二进制分发和源文件可以通过 Flink 项目的 下载页面 以及 文档页面 获得。 Flink 1.9 与之前 1.x 版本的 @Public