乐趣区

关于大数据:Alluxio-源码完整解析-你不知道的开源数据编排系统下篇

回顾

在《Alluxio- 源码解析 - 上》次要讲述了 Alluxio 本地环境搭建,源码我的项目构造,服务过程的启动流程和服务间 RPC 调用。

本篇将在上篇的根底上,持续为大家讲述 Alluxio 中重点类详解,Alluxio 中 Block 底层读写流程,Alluxio Client 调用流程和 Alluxio 内置的轻量级调度框架。

Part 1 重点类讲述

1.1 Journaled

Journaled 接口定义可被 Journaled 长久化保护的通用办法,通过 JournalEntryIterable#getJournalEntryIterator 获取 Journal 元素遍历信息,该接口提供默认 checkpoint 办法。Journaled 接口继承 Checkpointed、JournalEntryIterable,定义的办法包含:

  • getJournalEntryIterator:获取 Journal 所有元素;
  • getCheckpointName:获取 checkpoint class 类名称;
  • writeToCheckpoint:长久化写入所有状态的 checkpoint;
  • restoreFromCheckpoint:checkpoint 复原;
  • processJournalEntry:解决指定的 Journal 元素,Journal 解决外围办法;
  • resetState:重置 Journal 状态;
  • applyAndJournal:对 Journal 元素执行和利用 Journal 操作。

1.2 UnderFileSystem

Alluxio 治理和适配数据在底层各个存储系统执行操作,实现 UnderFileSystem 接口的底层存储能够作为 Alluxio 的非法 UFS。

1.2.1. 类图

UnderFileSystem 的类图如下所示,次要由抽象类 BaseUnderFileSystem 实现,而 BaseUnderFileSystem 下次要分为两大类:

  • ConsistentUnderFileSystem:具备一致性的 UFS 实现,次要包含:LocalUnderFileSystem、HdfsUnderFileSystem、CephFSUnderFileSystem 等;
  • ObjectUnderFileSystem:对象存储 UFS 实现,次要包含:S3AUnderFileSystem、COSUnderFileSystem、OSSUnderFileSystem 等。

1.2.2. 接口办法

在 UnderFileSystem 中有两类接口 API:

  • 存储系统通用操作,如:创立 / 删除文件,文件重命名;
  • 解决数据长久化最终一致性的操作(eventual consistency),如:解决当 AlluxioMaster 保护元数据胜利时,但执行 UFS 操作失败的问题。

1.2.2.1. 存储系统操作

  • create:指定 path 门路,在 UFS 中创立数据文件(父目录不存在会主动创立),可通过 CreateOptions 设置创立文件的用户组和 ACL 策略;
  • deleteDirectory:删除指定目录,可通过 DeleteOptions 设置删除的策略和遍历形式;
  • deleteFile:删除指定文件;
  • getDirectoryStatus:获取 UFS 指定目录状态,需传入已存在的目录文件;
  • getFileStatus:获取 UFS 指定文件状态;
  • getStatus:获取 UFS 状态,可指定目录或文件;
  • isDirectory:判断指定门路在 UFS 是否是目录;
  • open:关上 UFS 上指定文件,可通过 OpenOptions 设置文件关上参数;
  • renameDirectory:UFS 上指定目录重命名;
  • renameFile:UFS 上指定文件重命名;
  • exists:判断指定的文件或目录是否存在;
  • getAclPair:获取 UFS 的 ACL 策略;
  • getBlockSizeByte:获取指定目录下 UFS 的每个 Block 文件大小,单位 bytes;
  • getFileLocations:获取指定门路在 UFS 关联的存储 Location 列表;
  • getFingerprint:计算并获取指定门路的文件标识 (指纹),文件标识(指纹) 的计算必须是确定且不可变的;
  • getOperationMode:获取底层 UFS 的操作模式,Alluxio 的底层存储能够由多种类型 UFS 组成,该办法用来确定底层 UFS 的操作模式,例子:底层 UFS 为:hdfs://ns1/,hdfs://ns2/,则返回后果:{hdfs://ns1/:NO_ACCESS,hdfs://ns2/:READ_WRITE};
  • getPhysicalStores:获取所有 UFS 类型,包含数据结构和对应权限 getSpace:
  • 通过制订 SpaceType 获取 UFS 中指定门路的存储空间信息,SpaceType 包含:SPACE_TOTAL、SPACE_FREE、SPACE_USED;
  • getUnderFSType:获取 UFS 类型,如 hdfs;
  • isFile:判断文件文件在 UFS 是否存在;
  • isObjectStorage:判断 UFS 是否是对象存储;
  • isSeekable:判断 UFS 是否反对搜寻;
  • listStatus:指定 UFS 门路下的文件状态列表,该列表不保障程序,可通过 ListOptions 设置是否反对遍历;
  • mkdirs:在 UFS 上创立指定目录,可通过 MkdirsOptions 设置目录创立规定,如 ACL 和递归父目录创立;
  • setAclEntries:指定门路,设置 UFS 的 ALC 策略汇合;
  • setMode:指定门路,设置 UFS ALC Mode,如 0777;
  • setOwner:指定门路,设置 UFS ALC 的 user 和 group;
  • supportsFlush:判断 UFS 是否反对文件 Flush;
  • supportsActiveSync:判断 UFS 是否反对 ActiveSync(拜访外部文件共享),ActiveSync 相干的接口包含:getActiveSyncInfo、startSync、stopSync、startActiveSyncPolling、stopActiveSyncPolling。

1.2.2.2. 最终一致性操作

  • createNonexistingFile:创立不存在的文件,若文件存在,则退出;
  • deleteExistingDirectory:删除指定目录;
  • deleteExistingFile:删除指定文件;
  • getExistingDirectoryStatus:获取 UFS 指定目录状态;
  • getExistingFileStatus:获取 UFS 指定文件状态;
  • getExistingStatus:获取 UFS 状态,可指定目录或文件;
  • isExistingDirectory:判断指定门路在 UFS 是否是目录;
  • openExistingFile:关上 UFS 上指定文件,可通过 OpenOptions 设置文件关上参数;
  • renameRenamableDirectory:UFS 上指定目录重命名;
  • renameRenamableFile:UFS 上指定文件重命名。

1.2.2.3. 其余操作

  • cleanup:当数据文件创建时没有失常的胜利完结或被摈弃解决,则对底层 UFS 清理;
  • connectFromMaster:指定 AlluxioMaster 主机地址,建设指定 Master 与 UFS 连贯;
  • connectFromWorker:指定 AlluxioWorker 主机地址,建设指定 Worker 与 UFS 连贯;
  • resolveUri:给定 Alluxio 根底 URI 和门路,返回拼装后的 Alluxio 门路。

1.3 UfsManager

Alluxio 中对底层 UFS(Under FileSystem)治理操作的通用对立接口类定义,定义的接口办法包含:

  • addMount:UFS 挂载到 Alluxio,该办法仅针对 Alluxio 解决,不对底层 UFS 操作;
  • removeMount:移除 Alluxio 中的 UFS 挂载;
  • get:依据 mountId 获取挂载的 UFS 信息;
  • getRoot:获取 Alluxio 上挂载的根目录信息;
  • getJournal:获取 Journal 的 Location 地址;

其中 AbstractUfsManager 抽象类对 UFS 治理接口进行根本实现。

1.3.1. UfsClient

保护底层 UFS 的 Client 连贯信息和其余相干 UFS 的形容信息,基于 UfsClient 实现 Alluxio 对 UnderFileSystem 的操作。

1.4 BlockClient

BlockClient 抽象类定义调用方对 Block 根本的读写操作,其类图示意如下,次要包含:BlockWriter、BlockReader。

读写 Block 的定义的办法类:

1.5 DefaultFileSystemMasterMaster

服务保护所有 FileSystem(文件系统)元数据变更的治理操作,DefaultFileSystemMaster 外部基于 InodeTree 保护文件系统构造,并将 InodeTree 长久化到日志文件(journal);除此之外,其外部保护多个治理操作,如:InodeLockManager、MasterUfsManager、MountTable 等;备注:DefaultFil1.5. DefaultFileSystemMastereSystemMaster 的启动 start 办法详情后面所述内容。

1.5.1. 接口办法

FileSystemMaster 接口定义 master 中针对 FS 的操作方法,DefaultFileSystemMaster 继承 FileSystemMaster,其接口办法次要包含:

  • cleanupUfs:周期性清理底层 UFS;
  • getFileId:基于 Alluxio 门路 URI 获取文件 ID,若文件不缓存 Alluxio,则调用 UFS 获取;
  • getFileInfo:依据文件 ID 获取文件详情,该接口仅对外部服务凋谢,不对用户间接凋谢;
  • getPersistenceState:依据文件 ID,获取该文件的长久化状态;
  • listStatus:指定 Alluxio 门路,获取文件状态列表;
  • checkAccess:校验指定 Alluxio 门路的权限;
  • checkConsistency:校验指定 Alluxio 门路的文件数据一致性;
  • completeFile:敞开 / 完结指定 Alluxio 门路,敞开后,则该文件不可写;
  • createFile:基于指定 Alluxio 文件门路,创立文件 FileInfo;
  • getNewBlockIdForFile:指定 Alluxio 文件门路,获取下个待操作 Block 文件的 Block ID;
  • getMountPointInfoSummary:获取 Alluxio 中 mount(挂载)门路的快照信息;
  • getDisplayMountPointInfo:获取 Alluxio 用户展现的 Mount 信息;
  • delete:删除指定 Alluxio 门路的文件元信息;
  • getFileBlockInfoList:获取指定 Alluxio 门路下的所有 Block 列表信息;
  • getInAlluxioFiles:获取 Alluxio 中所有的文件列表门路;
  • getInMemoryFiles:获取 Alluxio 中所有缓存在内存的文件列表门路;
  • createDirectory:创立 Alluxio 对应的目录,并返回目录 ID;
  • rename:Alluxio 中文件重命名操作的元数据变更;
  • free:指定 Alluxio 目录下,开释所有 alluxio 缓存的 block 文件信息,反对目录下遍历的文件开释;
  • getPath:依据指定 FileId 获取 Alluxio URI 门路;
  • getPinIdList:获取被固定的 inode id 列表;
  • getUfsAddress:获取 master 所需的 UFS 地址;
  • getUfsInfo:依据挂载 ID 获取对应 UFS 信息;
  • getLostFiles:获取 worker 节点失落的文件列表;
  • mount:外围操作,将 UFS 门路挂载在 Alluxio 指定门路;
  • unmount:勾销指定 Alluxio 门路上的 UFS 挂载;
  • updateMount:更新指定 Alluxio 门路挂载信息;
  • setAcl:设置 Alluxio 门路 ACL;
  • updateUfsMode:设置底层 UFS Mode;
  • validateInodeBlocks:验证 inode block 信息是否具备完整性;
  • workerHeartbeat:指定 worker ID,告诉对应 worker 进行文件的存储长久化;
  • getWorkerInfoList:获取所有 worker 节点信息列表;
  • getTimeSeries:获取 alluxio master 中元数据存储的工夫版本信息;

1.6 DefaultBlockWorker

1.6.1. 接口

Worker Server 针对 Block 的治理操作,实现接口类:BlockWorker,其接口办法次要包含:

  • getWorkerId:获取 worker id;
  • abortBlock:抛弃 session 中长期创立的 block 文件;
  • accessBlock:拜访指定 session 和 block id 下的 block 信息,该办法可能会在 block 缓存开释被拜访;
  • commitBlock:提交 block 到 Alluxio 的治理空间,待提交的 block 必须是长期的,当 block 提交胜利之前,block 是不反对读写访问;
  • commitBlockInUfs:将 block 提交到 UFS 长久化;
  • createBlock:在 Alluxio 治理空间创立 block,基于 BlockWriter 类可对 block 进行写操作,在 block commit 提交之前都是长期的;
  • getTempBlockMeta:获取长期 block 元数据;
  • createBlockWriter:基于 session 和 block id 创立 BlockWriter,用于 block 的写操作;
  • getReport:获取 worker 与 master 周期性心跳的报告;
  • getStoreMeta:获取整个 block 存储的元数据信息,包含 block 中每个存储目录映射和每层存储的容量状况;
  • getStoreMetaFull:与 getStoreMeta 类似,但包含残缺的 blockId 列表,获取代价更高;getVolatileBlockMeta:依据指定 blockId 获取 block 元数据信息;
  • lockBlock:对 block 进行加锁操作;
  • moveBlock:将 block 从以后存储 Location 挪动到指标 Location;
  • 以后仅反对分层存储挪动;
  • moveBlockToMedium:block 挪动并指定对应的存储介质类型(MediumType);
  • createBlockReader:创立 BlockReader 进行 Block 读操作,可读取 Alluxio Block 和 UFS Block;createUfsBlockReader:创立 BlockReader 进行 UFS Block 读操作;
  • removeBlock:从 Allxuio 治理空间移除 Block;
  • requestSpace:为指定 block 获取存储空间,该 block 必须为长期 block;unlockBlock:对 block 去除锁操作;
  • asyncCache:提交异步缓存申请进行异步的缓存治理;
  • updatePinList:更新底层 block 存储占用的 pin 列表;getFileInfo:基于指定 file id 获取文件信息。

1.6.2. TieredBlockStore

BlockStore 定义 block 的存储接口,用于治理本地 block 存储,其接口外围目标:具体实现 BlockWorker 中定义的办法类,接口如下:

TieredBlockStore 是 BlockStore 的实现类,实现了 Alluxio 中外围性能点:分层存储,使得对应的存储对象可基于 block 模式进行分层存储管理,并对外裸露提供 API 进行 block 治理。TieredBlockStore 中内置调配算法确定新 block 的存取和旧 block 的开释,基于 BlockMetadataManager 保护分层存储状态、block 读写锁治理等元数据信息。

TieredBlockStore 是线程平安的,所有基于 block 级别的操作都须要调用 BlockLockManager 来获取对应的读写锁,保障该 block 下的元数据操作和 I / O 操作是线程平安的。任何 block 的元数据操作都须要基于 BlockMetadataManager 来获取元数据的 ReentrantReadWriteLock 读写锁。

Allocator 接口定义 Alluxio 中数据管理的调配策略,接口办法:allocateBlockWithView,目前外部有三种实现类:

  • RoundRobinAllocator:基于 round-robin 轮训调配,默认从最高层开始调配,当最高层存储空间有余则会到下一层,该调配策略不反对指定存储具体的分层。
  • MaxFreeAllocator:调配到存储中最大残余空间,当没有指定具体存储分层,默认从最高层开始调配;
  • GreedyAllocator:返回满足存储 block 大小的第一层存储空间,是存储调配的示例类;

其中 BlockStoreLocation 定义存储 block 的 location 地址和分层信息,形容了三个存储维度:存储层别名、对应存储层目录地址,存储层介质信息。

1.6.2.1. createBlock

当存在可用空间 (space) 时,基于 block 调配算法创立长期 block;特地的:创立 block 不会触发其余 block 的销毁开释,通过 BlockMetadataAllocatorView 获取只读的 Block 元数据信息,为 Allocator 调度提供数据起源,Allocator 调配调度后返回 StorageDirView 对象并创立 TempBlockMeta 并通过 BlockMetadataManager 治理。存储调配后的元数据会基于 createBlockFile 办法长久化到 Block 元文件。

Allocator 接口定义 Alluxio 中数据管理的调配策略,接口办法:allocateBlockWithView,目前外部有三种实现类:

RoundRobinAllocator:基于 round-robin 轮询调配,默认从最高层开始调配,当最高层存储空间有余则会到下一层,该调配策略不反对指定存储具体的分层。
MaxFreeAllocator:调配到存储中最大残余空间,当没有指定具体存储分层,默认从最高层开始调配;
GreedyAllocator:返回满足存储 block 大小的第一层存储空间,是存储调配的示例类;

其中 BlockStoreLocation 定义存储 block 的 location 地址和分层信息,形容了三个存储维度:存储层别名、对应存储层目录地址,存储层介质信息。

1.6.2.2. freeSpace

同步办法执行 Block 缓存存储空间执行立即删除开释,当所有存储分层的空间开释操作完结后能力反对新 Block 创立。依据 BlockMetadataEvictorView 获取 Block 存储中可移除的 Block 信息。判断以后缓存存储中是否满足最小间断空间和最小可用空间,若同时满足,则不进行后续空间清理操作;若不满足,则遍历 Block 信息,判断是否可清理,若能够清理,则删除对应的 Block 文件及元数据,通过 BlockStoreEventListener 事件监听器同步 Block 开释操作。

BlockStoreEventListener 监听 BlockStore 中元数据变动胜利完结的触发事件,次要包含的接口办法类:

  • onAccessBlock:拜访 Block 事件触发;
  • onAbortBlock:清理和开释长期 Block 事件触发;
  • onCommitBlock:提交长期 Block 并关联 Block 的存储信息 BlockStoreLocation 事件触发;
  • onMoveBlockByClient:基于 Client 挪动 Block 的 BlockStoreLocation 事件触发;
  • onMoveBlockByWorker:基于 Worker 挪动 Block 的 BlockStoreLocation 事件触发;
  • onRemoveBlockByClient:基于 Client 移除并开释 Block 的 BlockStoreLocation 事件触发;
  • onRemoveBlock:移除并开释 Block 事件触发;onBlockLost:Block 失落 事件触发;
  • onStorageLost:存储目录失落 事件触发。

1.7 PlanDefinition

Alluxio 中内置轻量级角度零碎的 Job 执行打算定义,有两个外围局部,1. PlanDefinition#selectExecutors:该办法在 Master 节点调用,用于抉择执行工作的 AlluxioJobWorker,2.PlanDefinition#runTask:在 JobWorker 中运行指定作业打算。PlanDefinition 次要包含的作业定义实现有:

MoveDefinition:在 FileSystemMaster 校验层级上触发 Block 的挪动操作;

  • ReplicateDefinition:在 FileSystemMaster 校验层级上触发 Block 的复制操作;
  • EvictDefinition:在 FileSystemMaster 校验层级上触发 Block 开释操作;
  • PersistDefinition:将 Alluxio Block 缓存存储长久化到底层 UFS;
  • CompactDefinition:在指定目录降落结构化表的数据文件进行压缩;
  • MigrateDefinition:Block 挪动,源和指标 Block 能够挂载在不同的 UFS 节点;
  • LoadDefinition:实现简略的 Block 文件的 Load 操作。

1.7.1. TaskExecutorManager

治理 JobWorker Task 执行器,真正的执行工作通过线程池调用 TaskExecutor#run,而 TaskExecutor#run 底层通过 PlanDefinition#runTask 实现;同时 TaskExecutorManager 外部也治理 Task 的执行容量和 Task 生命周期治理,如:获取执行的线程池,对工作执行限流 / 解除限流,工作启停。

Part 2 Block 读写操作

2.1 读操作

BlockWorker RPC 服务提供的客户端的读操作,大抵流程如下:

  • BlockWorkerClientServiceHandler.readBlock 办法定义 Block 读取,默认创立申请参数 StreamObserverresponseObserver 创立 CallStreamObserver;若反对零拷贝,则应用 DataMessageServerStreamObserver
  • 基于 CallStreamObserver 创立 BlockReadHandler,并调用 BlockReadHandler#onReady 开启数据读取,基于线程池提交创立 DataReader 线程执行;
  • DataReader 是 Alluxio 用于 I / O 数据读取的线程类,封装了外围的 Alluxio 读操作逻辑,(1). 获取 Alluxio 数据输出流 DataBuffer;(2)调用 CallStreamObserver.onNext 触发和监听数据流读取;
  • DataReader 获取 DataBuffer 是整个读取解决的外围逻辑,判断数据读取起源:Local、UFS,是否进行 Block 挪动实现短路读;
  • 创立关上 Block,若申请须要减速 (promote=true) 则操作 BlockWorker.moveBlock,将 Block 挪动到存储更高层;
  • 调用 DefaultBlockWorker#createBlockReader 创立 BlockReader,判断本地 Worker 是否能够间接拜访,若反对则返回 LocalFileBlockReader;若为 UFS 中,则调用 UnderFileSystemBlockReader;- 调用 BlockReader.transferTo 读取数据,并将 I / O 封装为 NettyDataBuffer 返回。

2.1.1. UnderFileSystemBlockReaderUnderFileSystemBlockReader 类实现间接从 UFS 读取并将读取的信息缓存到读取的 Worker Block 中,大抵流程如下:

  • UfsInputStreamCache.acquire 依据 ufs、门路、blockId 获取输出流 InputStream,若 InputStream 在缓存中间接获取,若不存在,则依据 ufs.openExistingFile 获取底层 UFS 的文件输出流 InputStream;
  • 获取并更新 BlockWriter,判断是否存在有对应 Block 存在,不存在则调用 BlockStore.createBlock 新建长期 Block,并返回对应 BlockWriter;
  • 依据第一步骤获取的输出流 InputStream 和参数 offset 读取文件,读取的数据:(1). 通过 BlockWriter 写入 Block 缓存对应 Worker;(2). 返回调用方读取信息。

备注:

  • LocalFileBlockReader:基于 FileChannel.map 办法的 I / O 操作读取文本文件信息
  • RemoteBlockReader:基于远端的 Worker(非本地 Worker)读取,暂不反对;
  • DelegatingBlockReader 依据不同的应用场景,判断和抉择应用的 BlockReader 实现类。

2.1.2. ShortCircuitBlockReadHandler

ShortCircuitBlockReadHandler 类是 RPC 服务实现提供短路读能力,首先 Grpc 的 StreamObserver(观察者模式),一次 onNext 调用阐明一次音讯读取,大抵的执行流程:

  • 依据 OpenLocalBlockRequest 获取是否进行减速读取,若减速 (promote=true) 则调用 BlockWorker.moveBlock 将存储挪动更高层存储分层;
  • 调用 BlockWorker.lockBlock 获取 Block 的读写操作锁,最初 BlockWorker.accessBlock 获取拜访 Block

2.2 写操作

  • BlockWorker RPC 服务提供的客户端的写操作,大抵流程如下:
  • BlockWorkerClientServiceHandler.writeBlock 办法定义 Block 写入,默认创立申请参数 StreamObserverresponseObserver 创立 CallStreamObserver;若反对零拷贝,则应用 BlockWorkerClientServiceHandler;
  • 基于 CallStreamObserver 创立 DelegationWriteHandler,并调用 DelegationWriteHandler#onCancel 敞开数据写操作;调用 onNext 办法进行数据流监听写操作;
  • DelegationWriteHandler 依据申请 Command 类型获取对应的 AbstractWriteHandler 实现类:
  • ALLUXIO_BLOCK:BlockWriteHandler,数据仅写入 Alluxio Block,基于 BlockWriter 实现写操作;
  • UFS_FILE:UfsFileWriteHandler,数据仅写入 UFS,基于 UFS Client 创立目录文件并进行 I / O 操作;
  • UFS_FALLBACK_BLOCK:UfsFallbackBlockWriteHandler,先基于 BlockWriteHandler 写入 Alluxio Block 再写入 UFS;

AbstractWriteHandler 抽象类关系如下:

2.2.1. LocalFileBlockWriter

基于本地 Worker 写入 Block 文件信息,调用 FileChannel.map

2.2.2. ShortCircuitBlockWriteHandler

ShortCircuitBlockWriterHandler 实现短路读的创立本地 Block 能力,基于 onNext 调用,大抵执行流程:

若仅申请空间资源,则基于 BlockWorker.requestSpace 获取 Block 创立的申请空间资源;
若需创立长期 Block,则调用 BlockWorker.createBlock 创立 Block 并返回对应 Block 门路。

Part 3 Catalog 治理

AlluxioCatalog 进行 Alluxio 中 Catalog 治理对象,封装和保护了 Alluxio 中注册的 DB 信息及各个 DB 下的 Table 等元数据信息,其根本的办法操作如下,包含:获取数据库 db 信息,db 元数据同步,db 绑定 / 解绑等操作。

attachDatabase:将绑定的 db 元数据信息保护在内存中并同步长久化到 Journal 中;
syncDatabase:会基于底层 udb 获取最新元数据 database 信息,如 Hive 则调用 HMS 客户端接口办法 IMetaStoreClient#getDatabase 获取数据库信息。

Part 4 Client 操作

4.1 Client

Client 接口形象定义 Alluxio 中 Client 操作,其继承和实现类如下所示,封装了对接各个组件的 RPC 接口:

FileSystemMasterClient:封装 FileSystemMasterClientServiceHandler 相干 RPC 调用,进行元数据管理操作
BlockMasterClient:封装 BlockMasterClientServiceHandler 相干 RPC 调用,进行 Block 治理操作
TableMasterClient:封装 TableMasterClientServiceHandler 相干 RPC 调用,进行 Alluxio Table Catalog
治理操作 MetaMasterClient:封装 MetaMasterClientServiceHandler 相干 RPC 调用
MetaMasterConfigClient:封装 MetaMasterConfigurationServiceHandler 相干 RPC 调用
JobMasterClient:封装 JobMasterClientServiceHandler 相干 RPC 调用,进行 Alluxio Job 的调用操作;

4.1.1. FileSystem

Client 中定义的文件系统操作接口类,用于元数据管理和数据管理,用户可依据其实现类 BaseFileSystem 扩大 Client 文件操作行为。

FileSystem 中定义的接口办法次要包含以下几类:

  • checkAccess:查看指定门路权限;
  • createDirectory:基于 AlluxioURI 创立文件目录;
  • createFile:基于 AlluxioURI 创立数据文件;
  • delete:基于 AlluxioURI 删除指定文件 / 目录;
  • exists:基于 AlluxioURI 判断指定文件 / 目录是否存在;
  • free:基于 AlluxioURI 开释 Alluxio 空间,但不删除 UFS 数据文件了;
  • listStatus:列出 AlluxioURI 文件 / 目录信息;
  • mount/updateMount/unmount:挂载 / 更新 / 勾销挂载指定 AlluxioURI 目录;
  • openFile:关上并读取 AlluxioURI 文件输出流;
  • persist:将 Alluxio 中缓存的数据异步长久化底层 UFS;
  • rename:Alluxio 文件重命名。

4.1.2. FileSystemContext

保护 Alluxio 基于 Client 进行文件系统操作的上下文信息,通常的,一个 Client JVM 过程会应用同个 FileSystem 连贯 Alluxio,因而 Client 对象会在不同线程中共享。FileSystemContext 只有当用户须要个性化配置和认证时才被创立,线程共享的 Client 会针对 FileSystemContext 保护独立的线程空间,FileSystemContext 线程不共享 (线程平安) 会减少 Client 连贯的资源应用,因而当用户进行 Alluxio 操作后,须要敞开 FileSystemContext 开释资源。

4.1.3. FileInStream/FileOutStream

Client 中定义基于 Alluxio 文件操作的输出 / 输入流,如下所示:

  • 输入流:AlluxioFileOutStream,Alluxio 输入流写入,底层操作 BlockOutStream
  • 输出流:AlluxioFileInStream:Alluxio 输出流读取,封装了本地 / 远端节点数据读取,或者间接基于底层 UFS;底层操作 BlockInStream,LocalCacheFileInStream,AlluxioHdfsInputStream

4.2 AbstractShell

Client 的性能能够通过 Shell 对外提供操作,AbstractShell 抽象类定义 Alluxio 中 Shell 命令操作,其继承子类包含:

  • FileSystemShell:Alluxio Shell 文件操作入口类;
  • FileSystemAdminShell:Alluxio 文件系统治理操作;
  • CollectInfo:Alluxio 中从所有 Woker 节点采集信息命令;
  • TableShell:Alluxio 表治理操作;
  • JobShell:Alluxio 执行 job 治理操作。

4.2.1. CatCommand

以 CatCommand 为例,简述 Alluxio Client 进行文件读取的大抵流程如:

  • FileSystemShell 接管 shell 命令,执行 ”cat” 关上文件操作,调用 CatCommand.run 命令,shell 命令反对正则和多目录,对每个指定目录执行自定义实现的 runPlainPath 操作;
  • CatCommand#runPlainPath 办法通过 getStatus 判断文件类型,若为目录则退出,若为文件则基于 FileSystem 关上文件获取客户端输出流对象 FileInStream(AlluxioFileInStream);
  • 基于 AlluxioFileInStream#read 读取文件内容,URIStatus 保护 Alluxio 中目录和文件元数据快照信息,基于 URIStatus 获取指定 Alluxio 文件对应 Block 信息,通过 Client AlluxioBlockStore 中保护的 Block 信息获取 BlockInStream(Block 输出流);
  • 基于 BlockInStream 调用输出流读取操作,底层基于 Block 的数据读取接口 DataReader 实现,基于 DataReader 读取 Block 详情下述的 Block 读操作。

4.2.2. TouchCommand

  • 以 TouchCommand 为例,简述 Alluxio Client 进行文件写入的大抵流程如:
  • FileSystemShell 接管 shell 命令,执行 ”touch” 关上文件操作,调用 TouchCommand.run 命令,shell 命令反对正则和多目录,对每个指定目录执行自定义实现的 runPlainPath 操作;
  • TouchCommand#runPlainPath 办法调用 FileSystem.createFile 创立文件并在完结后敞开该连贯;
  • FileSystem.createFile 的办法详解如下:
  • 基于 FileSystemMasterClient 获取 FileSystemMasterClientServiceHandler 近程的 RPC 连贯信息;
  • 基于 FileSystemMasterClient 调用 RPC 接口创立数据文件(createFile),将新建 Alluxio 文件元数据信息同步 Alluxio Master;
  • FileSystem 新建 Client 端的 Alluxio 文件输入流对象:AlluxioFileOutStream,其底层调用 Block 的 DataWriter 对象进行文件解决;
  • 输入流实现后,执行 AlluxioFileOutStream#close 办法,调用 FileSystemMasterClient#completeFile 判断是否已执行实现,最终基于 RPC 接口实现 completeFile;

Part 5 轻量级调度

Alluxio 外部基于 AlluxioJobMaster 和 AlluxioJobWoker 实现轻量级内置的 Alluxio 操作调度,Master 负责作业的调度治理,而 Worker 真正执行作业操作。

5.1 调度治理

由前文 AlluxioJobMaster 启动流程可知,AlluxioJobMaster 在启动时会触发 JobMaster Server 启动,JobMaster 外部保护执行打算 (plan) 的治理追踪器:PlanTracker,用于创立、移除、拜访工作作业汇合,每个作业都有对应的 PlanCoordinator 用于分布式作业执行协调。内部服务可通过 HTTP 和 RPC 形式调用 JobMaster.run 办法依据作业配置 (JobConfig) 启动并进行作业调度(同步 / 线程平安的)。JobConfig 定义作业配置接口,分为两类:PlanConfig(单作业执行)、WorkflowConfig(一组作业流执行)。

JobMaster 中作业调度治理的大抵流程如下:

  • 内部接口可调用 JobMaster.run 办法触发作业执行,以 Plan 作业类型为例,调用 PlanTracker 执行 run 办法;
  • PlanTracker 先校验并移除已实现的作业,并基于 PlanCoordinator 创立新的作业实例并启动该作业实例;
  • PlanCoordinator 作业启动流程:
  • 基于 JobConfig 获取对应的 PlanDefinition;
  • 依据可用的 Worker 列表和 PlanDefinition,调用 selectExecutors 办法获取待执行作业 Worker 列表;
  • 调用 CommandManager 提交作业,将作业及待执行作业 worker 列表信息保护在内存队列中;
  • 最初,Job Master 和 Job Worker 节点通过 RPC 心跳检测,下发具体的作业信息给 Worker 执行。

5.2 作业执行

由前文 AlluxioJobWorker 启动流程可知,AlluxioJobWorker 启动时会触发心跳检测线程 CommandHandlingExecutor,对接管到的作业执行调度解决,每个作业启动一个线程执行,作业执行大抵流程如下:

  • CommandHandlingExecutor 线程启动与 JobMaster 进行心跳检测,基于 JobMasterClient.heartbeat 办法获取所有的待执行作业列表;
  • 遍历待执行作业列表,从线程池调用 CommandHandler.run 线程类执行作业调度,包含的作业类型:启动、勾销、注册作业;
  • CommandHandler 启动作业会调用 TaskExecutorManager 执行作业,以 Future 执行 TaskExecutor 进行线程级别作业调度;TaskExecutor 真正执行作业调度:
  • 对应作业参数进行反序列化操作;
  • 依据 PlanDefinitionRegistry 获取执行 Job 的 PlanDefinition 并调动 runTask 执行作业;

以 PersistDefinition 为例,大抵阐明 Job Executor 操作,将 Alluxio Block 存储长久化到底层 UFS:

  • 获取 Alluxio 的数据存储 URI,读取对应的数据输出流 in;
  • 获取指定的 UFS 指标门路,依据 UfsClient 判断该门路是否存在,若不存在则创立,并基于 UnderFileSystem 创立输入流 out;
  • 依据 I / O 操作工具类,将数据从数据流拷贝输入流,长久化到 UFS。

想要获取更多乏味有料的【流动信息】【技术文章】【大咖观点】,请关注[[Alluxio 智库]](https://page.ma.scrmtech.com/…):

退出移动版