Apache Flink

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 随着大数据 2.0 时代悄然到来，大数据从简单的批处理扩展到了实时处理、流处理、交互式查询和机器学习应用。近年来涌现出诸多大数据应用组件，如 HBase、Hive、Kafka、Spark、Flink 等。开发者经常要用到不同的技术、框架、API、开发语言和 SDK 来应对复杂应用的开发，这大大增加了选择合适工具和框架的难度，开发者想要将所有的大数据组件熟练运用几乎是一项不可能完成的任务。 面对这种情况，Google 在 2016 年 2 月宣布将大数据流水线产品（Google DataFlow）贡献给 Apache 基金会孵化，2017 年 1 月 Apache 对外宣布开源 Apache Beam，2017 年 5 月迎来了它的第一个稳定版本 2.0.0。在国内，大部分开发者对于 Beam 还缺乏了解，社区中文资料也比较少。InfoQ 期望通过 **Apache Beam 实战指南系列文章** 推动 Apache Beam 在国内的普及。 一．概述 大数据发展趋势从普通的大数据，发展成AI大数据，再到下一代号称万亿市场的lOT大数据。技术也随着时代的变化而变化，从Hadoop的批处理，到Spark Streaming，以及流批处理的Flink的出现，整个大数据架构也在逐渐演化。 Apache

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 一、尽量在业务上和技术上避免分布式事务 显而易见，微服务架构十分的流行，特别是对于电商领域来说。他的优点就不多说了，但是随着集群机器的增加，集群的规模也越来越大，随着集群搭载的服务规模也越来越大，导致事务的处理也就越来越复杂，有可能一个事务涉及到n多个服务，可想而知就算再优良的方案也很难处理这么复杂的事务，与其硬着头皮牺牲性能和可靠性，还不如改变业务，再结合技术对事务进行分割，将复杂的事务简单化，将简单的事务消化化。 二、两段式提交（2PC），XA/JTA已经实现了 在分布式系统中，每个节点虽然可以知晓自己的操作是成功或者失败，却无法知道其他节点的操作的成功或失败。当一个事务跨越多个节点时，为了保持事务的ACID特性，需要引入一个作为协调者的组件来统一掌控所有节点（参与者）的操作结果并最终指示这些节点是否需要把操作结果进行真正的提交。算法步骤如下： 第一阶段： 1、协调者会问所有的参与者，是否可以执行提交操作。 2、各个参与者开始事务执行的准备工作，如：为资源上锁，预留资源。 3、参与者响应协调者，如果事务的准备工作成功，则回应“可以提交”，否则回应“拒绝提交”。 第二阶段： 1、如果所有的参与者都回应“可以提交”。那么协调者向所有的参与者发送“正式提交”的命令。参与者完成正式提交并释放所有资源，然后回应“完成

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 前言 之前文章 《从0到1学习Flink》—— Flink 写入数据到 ElasticSearch 写了如何将 Kafka 中的数据存储到 ElasticSearch 中，里面其实就已经用到了 Flink 自带的 Kafka source connector（FlinkKafkaConsumer）。存入到 ES 只是其中一种情况，那么如果我们有多个地方需要这份通过 Flink 转换后的数据，是不是又要我们继续写个 sink 的插件呢？确实，所以 Flink 里面就默认支持了不少 sink，比如也支持 Kafka sink connector（FlinkKafkaProducer），那么这篇文章我们就讲讲如何将数据写入到 Kafka。 准备 添加依赖 Flink 里面支持 Kafka 0.8、0.9、0.10、0.11 ，以后有时间可以分析下源码的实现。 这里我们需要安装下 Kafka，请对应添加对应的 Flink Kafka connector 依赖的版本，这里我们使用的是 0.11 版本： 1 2 3 4 5 <dependency> <groupId>org.apache.flink</groupId> <artifactId>flink-connector-kafka-0.11_2.11<

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 使用 Flink 编写处理逻辑时，新手总是容易被林林总总的概念所混淆： 为什么 Flink 有那么多的类型声明方式？ BasicTypeInfo.STRING_TYPE_INFO、Types.STRING 、Types.STRING() 有何区别？ TypeInfoFactory 又是什么？ TypeInformation.of 和 TypeHint 是如何使用的呢？ 接下来本文将逐步解密 Flink 的类型和序列化机制。 Flink 的类型分类 图 1：Flink 类型分类 Flink 的类型系统源码位于 org.apache.flink.api.common.typeinfo 包，让我们对图 1 深入追踪，看一下类的继承关系图： 图 2：TypeInformation 类继承关系图 可以看到，图 1 和 图 2 是一一对应的，TypeInformation 类是描述一切类型的公共基类，它和它的所有子类必须可序列化（Serializable），因为类型信息将会伴随 Flink 的作业提交，被传递给每个执行节点。 由于 Flink 自己管理内存，采用了一种非常紧凑的存储格式（见 官方博文 ），因而类型信息在整个数据处理流程中属于至关重要的元数据。 TypeExtractror 类型提取 Flink

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 摘要： 如今，大数据领域的开源框架（Hadoop，Spark，Storm）都使用的 JVM，当然也包括 Flink。基于 JVM 的数据分析引擎都需要面对将大量数据存到内存中，这就不得不面对 JVM 存在的几个问题： 1. Java 对象存储密度低。一个只包含 boolean 属性的对象占用了16个字节内存：对象头占了8个，boolean 属性占了1个，对齐填充占了7个。而实际上只需要一个bit（1 如今，大数据领域的开源框架（Hadoop，Spark，Storm）都使用的 JVM，当然也包括 Flink。基于 JVM 的数据分析引擎都需要面对将大量数据存到内存中，这就不得不面对 JVM 存在的几个问题： Java 对象存储密度低。一个只包含 boolean 属性的对象占用了16个字节内存：对象头占了8个，boolean 属性占了1个，对齐填充占了7个。而实际上只需要一个bit（1/8字节）就够了。 Full GC 会极大地影响性能，尤其是为了处理更大数据而开了很大内存空间的JVM来说，GC 会达到秒级甚至分钟级。 OOM 问题影响稳定性。OutOfMemoryError是分布式计算框架经常会遇到的问题，当JVM中所有对象大小超过分配给JVM的内存大小时，就会发生OutOfMemoryError错误

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> Windows为每一个进程都安排了一个EPROCESS的结构用于维护每一个进程，当然EPROCESS是属于内核管理的，所以只有ring0层的程序才可以访问这个结构，下面我们来看一下EPROCESS的结构是怎样的。 kd> dt _eprocess ntdll!_EPROCESS +0x000 Pcb : _KPROCESS +0x06c ProcessLock : _EX_PUSH_LOCK +0x070 CreateTime : _LARGE_INTEGER +0x078 ExitTime : _LARGE_INTEGER +0x080 RundownProtect : _EX_RUNDOWN_REF +0x084 UniqueProcessId : Ptr32 Void +0x088 ActiveProcessLinks : _LIST_ENTRY +0x090 QuotaUsage : [3] Uint4B +0x09c QuotaPeak : [3] Uint4B +0x0a8 CommitCharge : Uint4B +0x0ac PeakVirtualSize : Uint4B +0x0b0 VirtualSize : Uint4B +0x0b4 SessionProcessLinks :

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 序 本文主要研究一下flink的NetworkBufferPool BufferPoolFactory flink-release-1.7.2/flink-runtime/src/main/java/org/apache/flink/runtime/io/network/buffer/BufferPoolFactory.java public interface BufferPoolFactory { /** * Tries to create a buffer pool, which is guaranteed to provide at least the number of required * buffers. * * <p>The buffer pool is of dynamic size with at least <tt>numRequiredBuffers</tt> buffers. * * @param numRequiredBuffers * minimum number of network buffers in this pool * @param maxUsedBuffers * maximum number of network buffers this pool offers *

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 同事提供的flink项目，在他那边执行可以，在我这边报奇怪的错误，而且mq的source也没触发，报的错如下： java.lang.RuntimeException: Buffer pool is destroyed. at org.apache.flink.streaming.runtime.io.RecordWriterOutput.pushToRecordWriter(RecordWriterOutput.java:110) ~[flink-streaming-java_2.11-1.8.1.jar:1.8.1] at org.apache.flink.streaming.runtime.io.RecordWriterOutput.collect(RecordWriterOutput.java:89) ~[flink-streaming-java_2.11-1.8.1.jar:1.8.1] at org.apache.flink.streaming.runtime.io.RecordWriterOutput.collect(RecordWriterOutput.java:45) ~[flink-streaming-java_2.11-1.8.1.jar:1.8.1] at org.apache.flink

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> flink是一款开源的大数据流式处理框架，他可以同时批处理和流处理，具有容错性、高吞吐、低延迟等优势，本文简述flink在windows和linux中安装步骤，和示例程序的运行，包括本地调试环境，集群环境。另外介绍Flink的开发工程的构建。 首先要想运行Flink，我们需要下载并解压Flink的二进制包，下载地址如下： https://flink.apache.org/downloads.html 我们可以选择Flink与Scala结合版本，这里我们选择最新的1.9版本 Apache Flink 1.9.0 for Scala 2.12 进行下载。 下载成功后，在windows系统中可以通过Windows的bat文件或者Cygwin来运行Flink。 在linux系统中分为单机，集群和Hadoop等多种情况。 通过Windows的bat文件运行 首先启动cmd命令行窗口，进入flink文件夹，运行bin目录下的 start-cluster.bat 注意：运行flink需要java环境，请确保系统已经配置java环境变量。 $ cd flink $ cd bin $ start-cluster.bat Starting a local cluster with one JobManager process

1、基本组件栈 了解Spark的朋友会发现Flink的架构和Spark是非常类似的，在整个软件架构体系中，同样遵循着分层的架构设计理念，在降低系统耦合度的同时，也为上层用户构建Flink应用提供了丰富且友好的接口。 Flink分为架构分为三层，由上往下依次是API&Libraries层、Runtime核心层以及物理部署层 ​ API&Libraries层 作为分布式数据处理框架，Flink同时提供了支撑计算和批计算的接口，同时在此基础上抽象出不同的应用类型的组件库，如基于流处理的CEP(复杂事件处理库)、SQL&Table库和基于批处理的FlinkML(机器学习库)等、Gelly(图处理库)等。API层包括构建流计算应用的DataStream API和批计算应用的DataSet API，两者都提供给用户丰富的数据处理高级API，例如Map、FlatMap操作等，同时也提供比较低级的Process Function API，用户可以直接操作状态和时间等底层数据。 　　 Runtime核心层 　　该层主要负责对上层不同接口提供基础服务，也是Flink分布式计算框架的核心实现层，支持分布式Stream作业的执行、JobGraph到ExecutionGraph的映射转换、任务调度等。将DataSteam和DataSet转成统一的可执行的Task Operator