一、概述RPC 协议是使用 Hadoop RPC 框架的第一步,HDFS 为各个节点之间抽象了不同的 RPC 协议，例如 ClientProtocol 抽象了客户端与名字节点之间的通信协议，HDFS 客户端调用 ClientProtocol.rename() 方法，Namenode 服务器就会更改指定 HDFS 文件的文件名。而 DatanodeProtocol 则抽象了数据节点与名字节点之间的通信协议。 1.1. 协议栈对于 HDFS 中的所有 RPC 协议，都会存在一个如图所示的协议栈: 对于 ClientProtocol，存在对应的支持序列化的接口 ClientNamenodeProtocolPB，同时还存在 ClientNamenodeProtocolTranslatorPB 以及 ClientNamenodeProtocolServerSideTranslatorPB 两个类用于进行协议适配 二、实现2.1. ClientProtocol 协议ClientProtocol 协议定义了 HDFS 客户端与 Namenode 交互的所有接口方法（例如 rename() ...

DFSClient 会获取一个 ClientProtocolPB 协议的代理对象，并在这个代理对象上调用 RPC 方法，代理对象会调用 RPC.Client.call() 方法将序列化之后的 RPC 请求发送到服务器。 一、概述 二、请求程序DFSClient，YarnClient，DFSAdmin 等等，对外暴露接口调用，内部调用下层接口实现功能。 DFSClient 是一个实现了分布式文件系统客户端功能的类，是用户使用 HDFS 各项功能的起点。DFSClient 会连接到 HDFS,对外提供管理文件／目录、读写文件以及管理与配置 HDFS 系统等功能。 DFSClient 会持有一个 ClientProtocol 对象向 Namenode 发送请求～ namenode 字段保存了一个实现了 ClientProtocol 接口的对象，DFSClient 通过 ProxyInfo 类来获取这个对象的引用，而这个 ProxyInfo 对象则是通过调用 NameNodeProxies.createProxy() 方法产生的。 三、Stub 程序3.1. 协议层不同的请求本质上是 ...

一、概述那么，当请求到达服务器端之后，服务器端是如何响应的呢🤔️～ 获取了 BlockingService 对象后，ProtoBufRpcInvoker 利用调用信息中的调用方法信息(在这个例子中是 rename）和调用参数对象(RenameRequestProto)调用 BlockingService.callBlockingMethod() 方法响应 RPC 请求。 NameNodeRpcServer 初始化 引用本站文章 Hadoop-组件-HDFS-源码学习-RPC 通信服务-NameNodeRpcServer 初始化 Joker 二、传输层 ServerServer 对象用于监听并响应来自 RPC 客户端的请求。例如对于 Namenode，它会构造两个 Server 对象分别响应来自 HDFS 客户端和 Datanode 的 RPC 请 ...

一、概述客户端的请求会经过路由层，通过路由层内部的规则去匹配对应的 provider 服务～ 二、实现2.1. 客户端Hadoop RPC 巧妙地使用了 Java 动态代理机制，ClientNamenodeProtocolTranslatorPB 持有的 ClientNamenodeProtocolPB 对象其实是通过 Java动态代理机制获取的一个 ClientNamenodeProtocolPB 接口的代理对象，调用 RPC.getProtocolProxy() 方法获取，这个代理对象内部封装了一个 ProtobufRpcEngine.Invoker对象。对 ClientNamenodeProtocolPB 接口的调用都会由这个 Invoker 对象的 invoke()方法代理。 Invoker.invoke() 方法会首先构造一个描述 RPC 调用信息的对象 RequestHeaderProto，记录了客户端在什么协议上调用了什么方法(在 ClientProtocol 协议上调用了 rename 方法) 1RequestHeaderProto rpcRequestHead ...

一、概述Hadoop 作为分布式存储系统，各个节点之间的通信和交互是必不可少的，需要实现一套节点间的通信交互机制。RPC(Remote Procedure CallProtocol，远程过程调用协议)允许本地程序像调用本地方法一样调用远程机器上应用程序提供的服务，所以 Hadoop 实现了一套自己的 RPC 框架。Hadoop RPC 框架并没有使用 JDK 自带的 RMI (Remote Method Invocation,远程方法调用)，而是基于 IPC (Inter-Process Communications，进程间通信)模型实现了一套高效的轻量级 RPC 框架，这套 RPC 框架底层采用了 JavaNIO、 Java 动态代理以及 protobuf 等基础技术。 二、Hadoop RPC 架构2.1. 客户端 请求程序 请求程序会像调用本地方法一样调用客户端 Stub 程序，然后接收 Stub 程序返回的响应信息。 DFSClient 是一个实现了分布式文件系统客户端功能的类，是用户使用 HDFS 各项功能的起点。DFSClient 会连接到 HDFS,对外提供管理文件／目录 ...

JobManager 根据 JobGragh 生成 ExecutionGragh, ExecutionGragh 是 JobGragh 的并行化版本，是调度层最核心的数据结构。来到 ExecutionGraph 构建源码分析～，有点难～～～ 一、概述JobManager 根据 JobGragh 生成ExecutionGragh, ExecutionGragh是JobGragh的并行化版本，是调度层最核心的数据结构，每个 ExecutionGraph 都有一个与其相关联的作业状态。此作业状态指示作业执行的当前状态 ExecutionJobVertex 和 JobGraph 中的 JobVertex一一对应。每一个 ExecutionJobVertex 都有和并发度一样多的 ExecutionVertex。 ExecutionVertex 表示 ExecutionJobVertex 的其中一个并发子任务，输入是ExecutionEdge，输出是 IntermediateResultPartition。 IntermediateResult 和JobGraph中的Inte ...

JobGraph 数据结构在本质上是将节点和中间结果集相连得到有向无环图。JobGraph 是客户端和运行时之间进行作业提交使用的统一数据结构，不管是流式 (StreamGraph) 还是批量 (OptimizerPlan)，最终都会转换成集群接受的 JobGraph 数据结构。 一、概述StreamGraph 经过优化后生成了 JobGraph，提交给 JobManager 的数据结构它包含的主要抽象概念有： Jobvertex 经过优化后符合条件的多个 StreamNode 可能会 chain 在一起生成一个 Jobvertex, 即一个 JobVertex 包含一个或多个 operator, JobVertex 的输入是 JobEdge，输出是 IntermediateDataSet。 IntermediateDataSet 表示 JobVertex 的输出，即经过 operator 处理产生的数据集。producer 是 Jobvertex, consumer 是 JobEdge JobEdge 代表了job graph中的一条数据传输通道。sour ...

一、概述Apache Flink 是一个针对无界和有界数据流进行有状态计算的框架。Flink 自底向上在不同的抽象级别提供了多种 API，并且针对常见的使用场景开发了专用的扩展库，能在所有常见集群环境中运行，并能以内存速度和任意规模进行计算。 二、学习笔记 引用本站文章 Flink-理论笔记系列 Joker 三、源码学习 引用本站文章 Flink-源码学习系列 Joker 四、大厂分享 引用本站文章 ...

根据用户通过 Stream API 编写的代码，从 Source 节点开始，每一次 transform 生成一个 StreamNode，两个 StreamNode 通过 StreamEdge 连接在一起,形成 DAG StreamNode 用来代表 operator 的类，并具有所有相关的属性，如并发度、入边和出边等。 StreamEdge表示连接两个StreamNode的边。 当客户端调用 StreamExecution Environment.execute() 方法执行应用程序代码时，就会通过 StreamExecutionEnvironment 中提供的方法生成StreamGraph 对象。StreamGraph 结构描述了作业的逻辑拓扑结构，并以有向无环图的形式描述作业中算子之间的上下游连接关系。下面来看StreamGraph的底层实现及构建过程～～～ 一、概述StreamGraph 结构是由 StreamGraphGenerator 通过 Transformation 集合转换而来的，StreamGraph 实现了Pipeline的接口，且通过有向无环图的结 ...

一个 Flink 流式作业，从 Client 提交到 Flink 集群，到最后执行，总共会经历四种不同的状态。总的来说： Client 首先根据用户编写的代码生成 StreamGraph，然后把 StreamGraph 构建成 JobGraph 提 交给 Flink 集群主节点 然后启动的 JobMaster 在接收到 JobGraph 后，会对其进行并行化生成 ExecutionGraph 后调度 启动 StreamTask 执行。 StreamTask 并行化的运行在 Flink 集群，就是最终的物理执行图状态结构。 一、概述Flink 中的执行图可以分成四层：StreamGraph ==> JobGraph ==> ExecutionGraph ==> 物理执行图。 StreamGraph 根据用户通过 Stream API 编写的代码生成的最初的图。用来表示程序的拓扑结构。 JobGraph StreamGraph 经过优化后生成了 JobGraph，提交给 JobManager 的数据结构。主要的优化为，将多个符合条件的节点 chain 在一起 ...