Análise completa do código-fonte do Alluxio | Sistema de orquestração de dados de código aberto que você não conhece (Parte 2)

Reveja

Em "Alluxio - Source Code Analysis - Part 1", descreve principalmente a construção do ambiente local do Alluxio, a estrutura do projeto de código fonte, o processo de inicialização do processo de serviço e a chamada RPC entre serviços.

Este artigo continuará a descrever as principais classes do Alluxio com base no artigo anterior, o processo de leitura e gravação subjacente do Block in Alluxio, o processo de chamada do Alluxio Client e a estrutura de agendamento leve construída no Alluxio.

Descrição da classe chave da Parte 1

1.1**** Registrado

A interface Journaled define um método comum que pode ser mantido persistentemente por Journaled e obtém as informações de passagem dos elementos Journal por meio de JournalEntryIterable#getJournalEntryIterator . Essa interface fornece o método de ponto de verificação padrão. A interface Journaled herda Checkpointed e JournalEntryIterable, e os métodos definidos incluem:
getJournalEntryIterator: Obter todos os elementos de Journal;

getCheckpointName: obtém o nome da classe de checkpoint;

writeToCheckpoint: grava persistentemente o ponto de verificação de todos os estados;

restoreFromCheckpoint: recuperação de ponto de verificação;

processJournalEntry : Processa o elemento Journal especificado, o método principal de processamento do Journal ;

resetState: redefine o estado do Diário;

applyAndJournal: Executa e aplica operações do Diário aos elementos do Diário.

1.2****UnderFileSystem

Alluxio gerencia e adapta dados para realizar operações nos sistemas de armazenamento subjacentes.O armazenamento subjacente que implementa a interface UnderFileSystem pode ser usado como UFS legal do Alluxio.

1.2.1. Diagrama de Classes

O diagrama de classes de UnderFileSystem é mostrado abaixo, que é implementado principalmente pela classe abstrata BaseUnderFileSystem e BaseUnderFileSystem é dividido principalmente em duas categorias:

ConsistentUnderFileSystem : Implementação consistente de UFS, incluindo: LocalUnderFileSystem, HdfsUnderFileSystem, CephFSunderFileSystem, etc.;

ObjectUnderFileSystem : Implementação UFS de armazenamento de objetos, incluindo principalmente: S3AUnderFileSystem, COSunderFileSystem, OSUnderFileSystem, etc.

1.2.2. Métodos de interface

Existem dois tipos de APIs de interface no UnderFileSystem:
operações comuns do sistema de armazenamento, como: criar/excluir arquivos, renomear arquivos;

Lidar com a consistência eventual de persistência de dados, como: Resolver o problema de que quando AlluxioMaster mantém metadados com sucesso, a operação UFS falha.

1.2.2.1. Operação do sistema de armazenamento
criar: especifique o caminho do caminho, crie um arquivo de dados em UFS (o diretório pai não existe, ele será criado automaticamente), você pode definir o grupo de usuários e a política de ACL para criar o arquivo através de CreateOptions ;

deleteDirectory: Para excluir o diretório especificado, a estratégia de exclusão e o método de travessia podem ser definidos por meio de DeleteOptions;

deleteFile: exclua o arquivo especificado;

getDirectoryStatus: Para obter o status do diretório UFS especificado, você precisa passar o arquivo de diretório existente;

getFileStatus: obtém o status do arquivo especificado pelo UFS;

getStatus: Obtém o status UFS, você pode especificar um diretório ou arquivo;

isDirectory: Determine se o caminho especificado é um diretório no UFS;

open: abre o arquivo especificado no UFS e define os parâmetros de abertura do arquivo através de OpenOptions;

renameDirectory: renomeie o diretório especificado no UFS;

renameFile: Renomeie o arquivo especificado no UFS;

existe: Determine se o arquivo ou diretório especificado existe;

getAclPair: Obtenha a política de ACL do UFS;

getBlockSizeByte: obtém o tamanho de cada arquivo Block do UFS no diretório especificado, em bytes;

getFileLocations: obtém a lista de locais de armazenamento associados ao UFS para o caminho especificado;

getFingerprint: Calcula e obtém o ID do arquivo (fingerprint) do caminho especificado.O cálculo do ID do arquivo (fingerprint) deve ser determinístico e imutável;

getOperationMode: obtém o modo de operação do UFS subjacente. O armazenamento subjacente do Alluxio pode ser composto por vários tipos de UFS. Este método é usado para determinar o modo de operação do UFS subjacente. Por exemplo, o UFS subjacente é: hdfs:/ /ns1/, hdfs://ns2 /, o resultado é retornado: {hdfs://ns1/:NO_ACCESS,hdfs://ns2/:READ_WRITE};

getPhysicalStores: Obtenha todos os tipos de UFS, incluindo estruturas de dados e permissões correspondentes

getSpace: Obtenha as informações de espaço de armazenamento do caminho especificado no UFS especificando SpaceType, SpaceType inclui: SPACE_TOTAL, SPACE_FREE, SPACE_USED;

getUnderFSType: obtém o tipo UFS, como hdfs;

isFile: determina se o arquivo existe no UFS;

isObjectStorage: Determine se o UFS é um armazenamento de objetos;

isSeekable: Determine se o UFS suporta pesquisa;

listStatus: especifica a lista de status do arquivo sob o caminho UFS. A lista não garante a ordem. Você pode definir se deve suportar travessia por meio de ListOptions;

mkdirs: cria um diretório especificado no UFS. Você pode definir regras de criação de diretórios por meio de MkdirsOptions, como ACL e criação de diretório pai recursivo;

setAclEntries: Especifique o caminho e defina o conjunto de políticas ALC do UFS;

setMode: especifique o caminho, defina o modo UFS ALC, como 0777;

setOwner: Especifique o caminho e defina o usuário e grupo do UFS ALC;

supportFlush: Determina se o UFS suporta o arquivo Flush;

supportActiveSync: Determina se o UFS oferece suporte ao ActiveSync (acesso ao compartilhamento interno de arquivos) As interfaces relacionadas ao ActiveSync incluem: getActiveSyncInfo, startSync, stopSync, startActiveSyncPolling, stopActiveSyncPolling.

1.2.2.2 A operação de consistência eventual
createNonexistingFile: cria um arquivo que não existe e sai se o arquivo existir;

deleteExistingDirectory: exclua o diretório especificado;

deleteExistingFile: exclui o arquivo especificado;

getExistingDirectoryStatus: obtém o status do diretório especificado pelo UFS;

getExistingFileStatus: obtém o status do arquivo especificado pelo UFS;

getExistingStatus: Obtenha o status UFS, você pode especificar um diretório ou arquivo;

isExistingDirectory: Determine se o caminho especificado é um diretório no UFS;

openExistingFile: Para abrir o arquivo especificado no UFS, você pode definir os parâmetros de abertura do arquivo através de OpenOptions;

renameRenamableDirectory: renomeie o diretório especificado no UFS;

renameRenamableFile: renomeie o arquivo especificado no UFS.

1.2.2.3
Limpeza de outras operações: quando o arquivo de dados é criado sem um final bem-sucedido normal ou é descartado, o UFS subjacente é limpo;

connectFromMaster: Especifique o endereço do host do AlluxioMaster para estabelecer uma conexão entre o Master especificado e o UFS;

connectFromWorker: Especifique o endereço do host do AlluxioWorker para estabelecer uma conexão entre o Worker especificado e o UFS;

resolveUri: Dado o URI e o caminho base do Alluxio, retorne o caminho do Alluxio montado.

1.3 UfsManager

A definição geral de classe de interface unificada para a operação de gerenciamento do UFS subjacente (Under FileSystem) no Alluxio. Os métodos de interface definidos incluem:
addMount: UFS é montado no Alluxio, este método é apenas para processamento do Alluxio, não para a operação UFS subjacente;

removeMount: remove a montagem UFS no Alluxio;

get: Obtém as informações UFS montadas de acordo com mountId;

getRoot: Obtém as informações do diretório raiz montadas no Alluxio;

getJournal: Obtém o endereço do Local do Diário;

A classe abstrata AbstractUfsManager basicamente implementa a interface de gerenciamento UFS.

1.3.1 O UfsClient
mantém as informações de conexão do cliente do UFS subjacente e outras informações de descrição do UFS relacionadas e implementa as operações do Alluxio no UnderFileSystem com base no UfsClient.
1.4 BlockClient

A classe abstrata BlockClient define as operações básicas de leitura e escrita do chamador para o Block .O diagrama de classes é o seguinte, incluindo principalmente: BlockWriter, BlockReader .

A classe de método para ler e gravar definições de bloco:
1.5 DefaultFileSystemMaster

O serviço Master mantém as operações de gerenciamento de todas as alterações de metadados do FileSystem (sistema de arquivos). Tais como: InodeLockManager, MasterUfsManager, MountTable, etc.;
Nota : DefaultFil1.5.Os detalhes do método de início de DefaultFileSystemMastereSystemMaster estão descritos acima.

1.5.1. Métodos de Interface

A interface FileSystemMaster define o método de operação para FS no mestre.DefaultFileSystemMaster herda FileSystemMaster e seus métodos de interface incluem principalmente:
cleanupUfs: limpa periodicamente o UFS subjacente;

getFileId: obtém o ID do arquivo com base no URI do caminho do Alluxio. Se o arquivo não estiver armazenado em cache no Alluxio, chame UFS para obtê-lo;

getFileInfo: Obtenha detalhes do arquivo com base no ID do arquivo. Esta interface é aberta apenas para serviços internos, não diretamente para usuários;

getPersistenceState: obtém o estado persistente do arquivo de acordo com o ID do arquivo;

listStatus: Especifique o caminho do Alluxio para obter a lista de status do arquivo;

checkAccess: Verifica as permissões do caminho do Alluxio especificado;

checkConsistency: Verifica a consistência dos dados do arquivo do caminho do Alluxio especificado;

completeFile: fecha/termina o caminho especificado do Alluxio, após o fechamento, o arquivo não é gravável;

createFile: Cria um arquivo FileInfo baseado no caminho do arquivo Alluxio especificado;

getNewBlockIdForFile: Especifique o caminho do arquivo Alluxio para obter o ID do bloco do próximo arquivo de bloco a ser operado;

getMountPointInfoSummary: Obtenha as informações do instantâneo do caminho de montagem no Alluxio;

getDisplayMountPointInfo: Obtenha as informações de montagem exibidas pelos usuários do Alluxio;

delete: exclua a meta-informação do arquivo do caminho do Alluxio especificado;

getFileBlockInfoList: obtém todas as informações da lista de bloqueios no caminho do Alluxio especificado;

getInAlluxioFiles: Obtém todos os caminhos da lista de arquivos no Alluxio;

getInMemoryFiles: Obtém o caminho de todos os arquivos armazenados em cache na memória do Alluxio;

createDirectory: Cria o diretório correspondente ao Alluxio e retorna o ID do diretório;

renomear: Mudanças de metadados para operações de renomeação de arquivos no Alluxio;

free: No diretório Alluxio designado, libere todas as informações do arquivo de bloco armazenadas em cache pelo alluxio e suporte a liberação de arquivos atravessados ​​no diretório;

getPath: obtém o caminho do URI do Alluxio de acordo com o FileId especificado;

getPinIdList: obtém a lista de ids de inode fixa;

getUfsAddress: obtém o endereço UFS exigido pelo mestre;

getUfsInfo: Obtenha as informações UFS correspondentes de acordo com o ID de montagem;

getLostFiles: obtém a lista de arquivos perdidos pelo nó do trabalhador;

mount: A operação principal é montar o caminho UFS no caminho especificado pelo Alluxio;

unmount: Desmonte o UFS no caminho do Alluxio especificado;

updateMount: atualiza as informações de montagem do caminho do Alluxio especificado;

setAcl: Defina a ACL do caminho do Alluxio;

updateUfsMode: defina o modo UFS subjacente;

validateInodeBlocks: Verifique se as informações do bloco de inode estão completas;

workerHeartbeat: Especifique o ID do trabalhador e notifique o trabalhador correspondente para armazenar e persistir os arquivos;

getWorkerInfoList: Obtenha uma lista de todas as informações do nó do trabalhador;

getTimeSeries: Obtenha as informações de versão de tempo do armazenamento de metadados no mestre alluxio;

1.6 DefaultBlockWorker
1.6.1. Interface

O Worker Server implementa a classe de interface para operações de gerenciamento de bloco: BlockWorker, e seus métodos de interface incluem principalmente:
getWorkerId: Obter o ID do trabalhador;

abortBlock: descarta o arquivo de bloco criado temporariamente na sessão;

accessBlock: acessa as informações do bloco na sessão e id do bloco especificados, este método pode ser acessado quando o cache do bloco for liberado;

commitBlock: Envia o bloco para o espaço de gerenciamento do Alluxio. O bloco a ser submetido deve ser temporário. Antes do bloco ser submetido com sucesso, o bloco não suporta acesso de leitura e escrita;

commitBlockInUfs: Submete o bloco ao UFS para persistência;

createBlock: Cria um bloco no espaço de gerenciamento do Alluxio, o bloco pode ser escrito com base na classe BlockWriter, que é temporária até que o bloco seja submetido;

getTempBlockMeta: Obtenha metadados de bloco temporários;

createBlockWriter: Cria BlockWriter com base na sessão e id de bloco para operações de gravação de bloco;

getReport: Obtém o relatório da pulsação periódica entre o trabalhador e o mestre;

getStoreMeta: Obtenha as informações de metadados de todo o armazenamento do bloco, incluindo o mapeamento de cada diretório de armazenamento no bloco e a capacidade de cada camada de armazenamento;

getStoreMetaFull: Semelhante a getStoreMeta, mas inclui a lista de blockIds completa, que é mais cara de se obter;

getVolatileBlockMeta: obtém informações de metadados de bloco de acordo com o blockId especificado;

lockBlock: bloqueia o bloco;

moveBlock: move o bloco do local de armazenamento atual para o local de destino; atualmente, apenas movimentos de armazenamento hierárquicos são suportados;

moveBlockToMedium: o bloco move e especifica o tipo de meio de armazenamento correspondente (MediumType);

createBlockReader: Cria BlockReader para operação de leitura de bloco, que pode ler Alluxio Block e UFS Block;

createUfsBlockReader: Crie um BlockReader para operações de leitura de bloco UFS;

removeBlock: remove Block do espaço de gerenciamento do Allxuio;

requestSpace: Obtenha espaço de armazenamento para o bloco especificado, que deve ser um bloco temporário;

unlockBlock: remove a operação de bloqueio no bloco;

asyncCache: Envie solicitações de cache assíncronas para gerenciamento de cache assíncrono;

updatePinList: atualiza a lista de pinos ocupada pelo armazenamento de bloco subjacente;

getFileInfo: obtém informações do arquivo com base no ID do arquivo especificado.

1.6.2. TieredBlockStore

BlockStore define a interface de armazenamento de blocos para gerenciar o armazenamento de blocos local. O objetivo principal da interface é implementar as classes de método definidas em BlockWorker . A interface é a seguinte:
TieredBlockStore é a classe de implementação de BlockStore, que implementa o ponto de função principal em Alluxio: armazenamento em camadas, permite que os objetos de armazenamento correspondentes executem o gerenciamento de armazenamento hierárquico com base no formato de bloco e expõe APIs para gerenciamento de bloco. O algoritmo de alocação integrado no TieredBlockStore determina o acesso de novos blocos e a liberação de blocos antigos e mantém informações de metadados, como status de armazenamento hierárquico e gerenciamento de bloqueio de leitura/gravação de bloco com base no BlockMetadataManager.

TieredBlockStore é thread-safe e todas as operações em nível de bloco precisam chamar BlockLockManager para obter o bloqueio de leitura/gravação correspondente, garantindo que as operações de metadados e operações de E/S no bloco sejam thread-safe. Qualquer operação de metadados de bloco requer um bloqueio de leitura e gravação ReentrantReadWriteLock baseado em BlockMetadataManager para obter metadados.

A interface Allocator define a estratégia de alocação para gerenciamento de dados no Alluxio. O método da interface é: alocaBlockWithView. Atualmente, existem três classes de implementação:

RoundRobinAllocator: com base na alocação de treinamento round-robin, a alocação começa na camada mais alta por padrão. Quando o espaço de armazenamento da camada mais alta é insuficiente, ela irá para a próxima camada. Essa estratégia de alocação não suporta camadas de armazenamento específicas.

MaxFreeAllocator: O espaço máximo restante alocado para o armazenamento. Quando nenhuma camada de armazenamento específica é especificada, a alocação começa a partir da camada mais alta por padrão;

GreedyAllocator: Retorna a primeira camada de espaço de armazenamento que satisfaz o tamanho do bloco de armazenamento, que é uma classe de exemplo de alocação de armazenamento;

O BlockStoreLocation define o endereço de localização e as informações hierárquicas do bloco de armazenamento e descreve três dimensões de armazenamento: o alias da camada de armazenamento, o endereço do diretório da camada de armazenamento correspondente e as informações de mídia da camada de armazenamento.

1.6.2.1. createBlock
cria um bloco temporário baseado no algoritmo de alocação de blocos quando há espaço livre (espaço); especial: a criação de um bloco não acionará a destruição e liberação de outros blocos, obtenha informações de metadados de bloco somente leitura através de BlockMetadataAllocatorView , e agende para Allocator Forneça a fonte de dados, Allocator retorna o objeto StorageDirView e cria TempBlockMeta e o gerencia através do BlockMetadataManager após alocação e agendamento . Os metadados após a alocação de armazenamento persistirão no arquivo de metadados Block com base no método createBlockFile.
A interface Allocator define a estratégia de alocação para gerenciamento de dados no Alluxio. O método da interface é: alocaBlockWithView. Atualmente, existem três classes de implementação:

RoundRobinAllocator: Com base na alocação round-robin round-robin, a alocação começa na camada mais alta por padrão. Quando o espaço de armazenamento da camada mais alta é insuficiente, ele irá para a próxima camada. Esta estratégia de alocação não suporta o armazenamento específico camada especificada.

MaxFreeAllocator: O espaço máximo restante alocado para o armazenamento. Quando nenhuma camada de armazenamento específica é especificada, a alocação começa a partir da camada mais alta por padrão;

GreedyAllocator: Retorna a primeira camada de espaço de armazenamento que satisfaz o tamanho do bloco de armazenamento, que é uma classe de exemplo de alocação de armazenamento;

O BlockStoreLocation define o endereço de localização e as informações hierárquicas do bloco de armazenamento e descreve três dimensões de armazenamento: o alias da camada de armazenamento, o endereço do diretório da camada de armazenamento correspondente e as informações de mídia da camada de armazenamento.

1.6.2.2 O
método de sincronização freeSpace executa o espaço de armazenamento do cache do bloco para excluir e liberar imediatamente, e a criação de um novo bloco só pode ser suportada após a conclusão da operação de liberação de espaço de todas as camadas de armazenamento. Obtenha as informações do bloco removível no armazenamento de blocos de acordo com BlockMetadataEvictorView. Determine se o armazenamento em cache atual satisfaz o espaço mínimo contínuo e o espaço mínimo disponível. Se ambos forem satisfeitos, a operação de limpeza de espaço subsequente não será executada; caso contrário, percorra as informações do bloco para determinar se ele pode ser limpo e se pode ser limpo, exclua o bloco correspondente Para arquivos e metadados, as operações de liberação de bloco são sincronizadas por meio do ouvinte de eventos BlockStoreEventListener.
BlockStoreEventListener escuta o evento trigger do fim bem sucedido da mudança de metadados no BlockStore, incluindo principalmente classes de métodos de interface:
onAccessBlock: trigger de evento Access Block;

onAbortBlock: Acionado pela limpeza e liberação de eventos temporários do Block;

onCommitBlock: O evento BlockStoreLocation é acionado quando um bloco temporário é submetido e associado às informações de armazenamento do bloco;

onMoveBlockByClient: Acionado pelo evento BlockStoreLocation do Bloco de movimentação do Cliente;

onMoveBlockByWorker: Acionado pelo evento BlockStoreLocation baseado na movimentação do Worker Block;

onRemoveBlockByClient: acionado pelo evento BlockStoreLocation que remove e libera o Bloco baseado no Cliente;

onRemoveBlock: Remove e libera o evento Block acionado;

onBlockLost: Evento de perda de bloco acionado;

onStorageLost: Acionado pelo evento de perda do diretório de armazenamento.
1.7 Definição do Plano

A definição do plano de execução do trabalho do sistema de ângulo leve integrado no Alluxio tem duas partes principais, 1. PlanDefinition# selectExecutors : Este método é chamado no nó Master para selecionar o AlluxioJobWorker que executa a tarefa, 2. PlanDefinition# runTask : em o JobWorker Execute o agendamento de trabalho especificado. As principais implementações de definição de tarefa incluídas no PlanDefinition são:

MoveDefinition: aciona a operação de movimentação de bloco
no nível de verificação FileSystemMaster;ReplicateDefinition: aciona a operação de cópia de bloco no nível de verificação FileSystemMaster;

EvictDefinition: Aciona a operação de liberação do bloco no nível de verificação do FileSystemMaster;

PersistDefinition: Persiste o armazenamento em cache do Alluxio Block para o UFS subjacente;

CompactDefinition: Compacta os arquivos de dados das tabelas estruturadas no diretório especificado;

MigrateDefinition: Movimento de bloco, blocos de origem e destino podem ser montados em diferentes nós UFS;

LoadDefinition: Implemente a operação Load de um arquivo Block simples.
1.7.1. Gerenciador Executor de Tarefas

Gerencie o executor de tarefas JobWorker. A tarefa de execução real chama TaskExecutor#run através do pool de threads , e a camada inferior de TaskExecutor#run é realizada por meio de PlanDefinition#runTask ; ao mesmo tempo, o TaskExecutorManager também gerencia a capacidade de execução da tarefa e o gerenciamento do ciclo de vida da tarefa, como: obter o pool de threads de execução, executar o limite atual/liberar o limite atual nas tarefas e iniciar e parar as tarefas.

Parte 2 Bloqueie as operações de leitura e gravação

2.1 Operação de leitura

O processo geral da operação de leitura do cliente fornecido pelo serviço BlockWorker RPC é o seguinte:
O método BlockWorkerClientServiceHandler.readBlock define a leitura do bloco e o parâmetro de solicitação StreamObserverresponseObserver é criado por padrão para criar um CallStreamObserver; se a cópia zero for suportada, use DataMessageServerStreamObserver

Crie BlockReadHandler com base em CallStreamObserver e chame BlockReadHandler#onReady para iniciar a leitura de dados e crie a execução de thread DataReader com base no envio do pool de threads;

DataReader é uma classe de thread usada pelo Alluxio para leitura de dados de E/S. Ela encapsula a lógica principal da operação de leitura do Alluxio.(1) Obtenha o fluxo de entrada de dados do Alluxio DataBuffer, (2) Chame CallStreamObserver.onNext para acionar e monitorar a leitura do fluxo de dados;

A obtenção do DataBuffer pelo DataReader é a lógica central de todo o processo de leitura, determinando a fonte de leitura dos dados: Local, UFS e se deve realizar movimento de bloco para obter leitura em curto-circuito;

• Crie e abra Block, se a solicitação precisar ser acelerada (promote=true), então opere BlockWorker.moveBlock para mover o Block para um nível mais alto de armazenamento;

• Chame DefaultBlockWorker#createBlockReader para criar um BlockReader, determine se o Worker local pode acessá-lo diretamente e retorne LocalFileBlockReader se ele suportar; se estiver em UFS, chame UnderFileSystemBlockReader;

• Chame BlockReader.transferTo para ler os dados e encapsule a E/S como NettyDataBuffer para retornar.
  
  2.1.1 UnderFileSystemBlockReader A
  classe UnderFileSystemBlockReader implementa a leitura direta do UFS e armazena em cache as informações lidas no bloco Worker lido. O processo geral é o seguinte:

UfsInputStreamCache.acquire obtém o fluxo de entrada InputStream de acordo com ufs, path e blockId. Se o InputStream é obtido diretamente no cache, caso não exista, obtém o fluxo de entrada do arquivo InputStream do UFS subjacente de acordo com ufs.openExistingFile;

Obtenha e atualize o BlockWriter, determine se existe um Block correspondente, se não houver, chame BlockStore.createBlock para criar um novo Block temporário e retorne o BlockWriter correspondente;

Leia o arquivo de acordo com o fluxo de entrada InputStream obtido na primeira etapa e o parâmetro offset, e os dados lidos: (1) Gravar o Worker correspondente no cache do Block através do BlockWriter; (2) Retornar ao chamador para ler o em formação.
Observações:
LocalFileBlockReader: leia as informações do arquivo de texto com base nas operações de E/S do método FileChannel.map

RemoteBlockReader: baseado na leitura do trabalhador remoto (trabalhador não local), atualmente não suportado;

DelegatingBlockReader julga e seleciona a classe de implementação BlockReader para usar de acordo com diferentes cenários de uso.

2.1.2. ShortCircuitBlockReadHandler

A classe ShortCircuitBlockReadHandler é uma implementação de serviço RPC que fornece recursos de leitura de curto-circuito. Primeiro, o StreamObserver do Grpc (modo observador), uma chamada onNext descreve uma mensagem lida e o processo geral de execução:

Obtenha se a leitura acelerada deve ser realizada de acordo com OpenLocalBlockRequest. Se acelerado (promote=true), chame BlockWorker.moveBlock para mover o armazenamento para camadas de armazenamento superiores;

Chame BlockWorker.lockBlock para obter o bloqueio da operação de leitura e gravação do bloco e, finalmente, BlockWorker.accessBlock para obter o bloco de acesso

2.2 Operação
de gravação A operação de gravação do cliente fornecida pelo serviço BlockWorker RPC, o processo geral é o seguinte:
O método BlockWorkerClientServiceHandler.writeBlock define a gravação do bloco, e o parâmetro de solicitação StreamObserverresponseObserver é criado por padrão para criar CallStreamObserver; se a cópia zero for suportada, BlockWorkerClientServiceHandler é usado;

Crie um DelegationWriteHandler baseado em CallStreamObserver e chame DelegationWriteHandler#onCancel para fechar a operação de gravação de dados; chame o método onNext para monitorar a operação de gravação de fluxo de dados;

DelegationWriteHandler obtém a classe de implementação AbstractWriteHandler correspondente de acordo com o tipo de comando de solicitação:

• ALLUXIO_BLOCK: BlockWriteHandler, os dados são gravados apenas no Alluxio Block, e as operações de gravação são implementadas com base no BlockWriter;

• UFS_FILE: UfsFileWriteHandler, os dados são gravados apenas no UFS, os arquivos de diretório são criados com base no UFS Client e as operações de E/S são executadas;

• UFS_FALLBACK_BLOCK: UfsFallbackBlockWriteHandler, primeiro escreva Alluxio Block baseado em BlockWriteHandler e depois escreva UFS; A
  relação de classe abstrata AbstractWriteHandler é a seguinte:
  2.2.1 LocalFileBlockWriter

Chame FileChannel.map com base nas informações do arquivo de bloco gravadas pelo Worker local

2.2.2. ShortCircuitBlockWriteHandler

ShortCircuitBlockWriterHandler implementa a capacidade de criar um bloco local para leitura de curto-circuito. Com base na chamada onNext, o processo geral de execução é o seguinte:

Se você solicitar apenas recursos de espaço, obtenha os recursos de espaço solicitados criados pelo Block com base em BlockWorker.requestSpace;

Para criar um bloco temporário, chame BlockWorker.createBlock para criar um bloco e retornar o caminho do bloco correspondente.

Parte 3 Gerenciamento de catálogo

O AlluxioCatalog gerencia os objetos do catálogo no Alluxio, encapsula e mantém as informações do banco de dados registradas no Alluxio e informações de metadados como Tabela em cada banco de dados. Os métodos básicos são os seguintes, incluindo: obtenção de informações do banco de dados, sincronização de metadados do banco de dados, operações de vinculação do banco de dados, configuração/desvinculação.
attachDatabase: mantém as informações de metadados db vinculadas na memória e persiste-as de forma síncrona no Journal;

syncDatabase: As informações mais recentes do banco de dados de metadados serão obtidas com base no udb subjacente. Por exemplo, o Hive chamará o método de interface do cliente HMS IMetaStoreClient#getDatabase para obter informações do banco de dados.

Parte 4 Operação do Cliente

4.1 Cliente

A interface Client define abstratamente a operação do Client no Alluxio, suas classes de herança e implementação são as seguintes, encapsulando a interface RPC para conexão com cada componente:

FileSystemMasterClient: encapsula chamadas RPC relacionadas a FileSystemMasterClientServiceHandler para operações de gerenciamento de metadados

BlockMasterClient: Encapsula chamadas RPC relacionadas ao BlockMasterClientServiceHandler para realizar operações de gerenciamento de bloco

TableMasterClient: encapsula chamadas RPC relacionadas a TableMasterClientServiceHandler para operações de gerenciamento do Alluxio Table Catalog

MetaMasterClient: Encapsula chamadas RPC relacionadas ao MetaMasterClientServiceHandler

MetaMasterConfigClient: encapsula chamadas RPC relacionadas ao MetaMasterConfigurationServiceHandler

JobMasterClient: Encapsula as chamadas RPC relacionadas de JobMasterClientServiceHandler para chamar Alluxio Job

;

A classe de interface de operação do sistema de arquivos definida em Client é usada para gerenciamento de metadados e gerenciamento de dados.Os usuários podem estender o comportamento de operação do arquivo Client de acordo com sua classe de implementação BaseFileSystem.
Os métodos de interface definidos no FileSystem incluem principalmente as seguintes categorias:
checkAccess: Verifique as permissões de caminho especificadas;

createDirectory: Cria um diretório de arquivos baseado em AlluxioURI;

createFile: Cria um arquivo de dados baseado em AlluxioURI;

delete: exclua o arquivo/diretório especificado com base no AlluxioURI;

existe: Determina se o arquivo/diretório especificado existe com base no AlluxioURI;

free: Libera espaço no Alluxio baseado no AlluxioURI, mas não exclui arquivos de dados UFS;

listStatus: Lista as informações do arquivo/diretório AlluxioURI;

mount/updateMount/unmount: monta/atualiza/desmonta o diretório AlluxioURI especificado;

openFile: abre e lê o fluxo de entrada do arquivo AlluxioURI;

persist: persiste de forma assíncrona os dados armazenados em cache no Alluxio para o UFS subjacente;

renomear: renomear arquivo Alluxio.

4.1.2. FileSystemContext

Mantém as informações de contexto das operações do sistema de arquivos do Alluxio com base no Cliente. Normalmente, um processo Client JVM usará o mesmo FileSystem para se conectar ao Alluxio, então os objetos Cliente serão compartilhados entre diferentes threads. O FileSystemContext é criado apenas quando o usuário precisa de configuração e autenticação personalizadas. O cliente thread-shared manterá um espaço de thread independente para o FileSystemContext. O thread FileSystemContext não é compartilhado (thread security), o que aumentará o uso de recursos da conexão do cliente Portanto, quando o usuário interromper a operação do Alluxio Após isso, é necessário fechar o FileSystemContext para liberar recursos.

4.1.3. FileInStream/FileOutStream

Os fluxos de entrada/saída baseados nas operações do arquivo Alluxio são definidos no cliente da seguinte forma:

Fluxo de saída: AlluxioFileOutStream, gravação de fluxo de saída Alluxio, operação subjacente BlockOutStream

Fluxo de entrada: AlluxioFileInStream: Alluxio input stream lendo, encapsulando a leitura de dados do nó local/remoto, ou diretamente baseado no UFS subjacente; operações subjacentes BlockInStream, LocalCacheFileInStream, AlluxioHdfsInputStream

4.2
As funções do AbstractShell Client podem fornecer operações externas através do Shell, AbstractShell abstract class Define As operações de comando do shell no Alluxio e suas subclasses herdadas incluem:
FileSystemShell: classe de entrada de operação de arquivo do Shell do Alluxio;

FileSystemAdminShell: operações de gerenciamento do sistema de arquivos Alluxio;

CollectInfo: comando para coletar informações de todos os nós Woker no Alluxio;

TableShell: operações de gerenciamento de tabelas Alluxio;

JobShell: Alluxio executa operações de gerenciamento de tarefas.
4.2.1. Comando Cat

Tomando o CatCommand como exemplo, o processo geral de leitura de arquivos pelo Alluxio Client é brevemente descrito a seguir:

FileSystemShell recebe comandos shell, executa "cat" para abrir arquivos, chama o comando CatCommand.run, comandos shell suportam diretórios regulares e multidiretórios e executam a operação runPlainPath implementada de forma personalizada para cada diretório especificado;

O método CatCommand#runPlainPath julga o tipo de arquivo através de getStatus. Se for um diretório, ele sai. Se for um arquivo, ele abre o arquivo baseado no FileSystem para obter o objeto de fluxo de entrada do cliente FileInStream(AlluxioFileInStream);

Leia o conteúdo do arquivo com base no AlluxioFileInStream#read, o URIStatus mantém as informações do instantâneo do diretório e dos metadados do arquivo no Alluxio, obtém as informações do bloco correspondentes a um arquivo do Alluxio especificado com base no URIStatus e obtém o BlockInStream (stream de entrada do bloco) através das informações do bloco mantidas no cliente AlluxioBlockStore ;

A operação de leitura de fluxo de entrada é chamada com base em BlockInStream, e a interface de leitura de dados baseada em bloco subjacente DataReader é implementada e a operação de leitura de bloco com base nos detalhes do bloco de leitura de DataReader da seguinte forma.
4.2.2. Comando de toque

Tomando o TouchCommand como exemplo, o processo geral de escrita de arquivos pelo Alluxio Client é brevemente descrito a seguir:

FileSystemShell recebe comandos shell, executa "touch" para abrir arquivos, chama o comando TouchCommand.run, comandos shell suportam diretórios regulares e multidiretórios e executam a operação runPlainPath implementada de forma personalizada para cada diretório especificado;

O método TouchCommand#runPlainPath chama FileSystem.createFile para criar o arquivo e fecha a conexão quando terminar;

O método de FileSystem.createFile é explicado em detalhes da seguinte forma:

• Obtenha informações de conexão RPC remota de FileSystemMasterClientServiceHandler com base em FileSystemMasterClient;

• Chame a interface RPC para criar um arquivo de dados (createFile) baseado no FileSystemMasterClient e sincronize as informações de metadados do arquivo Alluxio recém-criado com o Alluxio Master;

• FileSystem cria um novo objeto de fluxo de saída de arquivo Alluxio do lado do cliente: AlluxioFileOutStream, cuja camada inferior chama o objeto DataWriter do Block para processamento de arquivos;

• Após a conclusão do fluxo de saída, execute o método AlluxioFileOutStream#close, chame FileSystemMasterClient#completeFile para avaliar se a execução foi concluída e, finalmente, implemente completeFile com base na interface RPC;

Parte 5 Programação Leve

O Alluxio implementa internamente o agendamento de operações do Alluxio leve e integrado baseado no AlluxioJobMaster e no AlluxioJobWoker O Master é responsável pelo gerenciamento do agendamento de tarefas, enquanto o Worker realmente executa as operações de tarefas.

5.1 Gerenciamento de Agendamento

Como pode ser visto no processo de inicialização do AlluxioJobMaster anterior, o AlluxioJobMaster acionará a inicialização do Servidor JobMaster quando for inicializado. O JobMaster mantém internamente o rastreador de gerenciamento do plano de execução (plano): PlanTracker, que é usado para criar, remover e acessar tarefas Coleções de jobs Cada job tem um correspondente O PlanCoordinator é usado para coordenação de execução de jobs distribuídos. Os serviços externos podem chamar o método JobMaster.run por meio de HTTP e RPC para iniciar e agendar trabalhos (sincronizados/segmentados) de acordo com a configuração do trabalho (JobConfig). JobConfig define a interface de configuração do job, que é dividida em duas categorias: PlanConfig (execução de job único), WorkflowConfig (um grupo de execução de fluxo de job).

O processo geral de gerenciamento de agendamento de trabalho no JobMaster é o seguinte: A
interface externa pode chamar o método JobMaster.run para acionar a execução do trabalho.Tomando o tipo de trabalho Plan como exemplo, chame PlanTracker para executar o método run;

O PlanTracker verifica e remove primeiro os trabalhos concluídos, cria uma nova instância do trabalho com base no PlanCoordinator e inicia a instância do trabalho;

Processo de inicialização do trabalho do PlanCoordinator:

• Obtenha o PlanDefinition correspondente baseado em JobConfig;

• De acordo com a lista de Worker disponível e PlanDefinition, chame o método selectExecutors para obter a lista de Workers a serem executados;

• Chame o CommandManager para enviar o trabalho e mantenha o trabalho e as informações da lista de trabalho do trabalho a ser executado na fila de memória;

Por fim, os nós Job Master e Job Worker enviam informações de trabalho específicas ao Worker para execução por meio da detecção de pulsação RPC.

5.2 Execução do trabalho
Como pode ser visto no processo de inicialização do AlluxioJobWorker acima, quando o AlluxioJobWorker é iniciado, o thread de detecção de pulsação CommandHandlingExecutor será acionado para executar o processamento de agendamento nos trabalhos recebidos. Cada trabalho inicia um thread para execução. O processo geral de execução do trabalho é o seguinte:
o thread CommandHandlingExecutor inicia o heartbeat com JobMaster Detection, baseado no método JobMasterClient.heartbeat para obter uma lista de todos os trabalhos a serem executados;

Percorra a lista de trabalhos a serem executados e chame a classe de thread CommandHandler.run do pool de threads para executar o agendamento de trabalho, incluindo os tipos de trabalho: iniciar, cancelar e registrar trabalhos;

Quando CommandHandler inicia um trabalho, ele chamará TaskExecutorManager para executar o trabalho e executará TaskExecutor com Future para agendamento de trabalho em nível de thread;

O TaskExecutor realmente executa o agendamento de tarefas:

• Desserialize os parâmetros de trabalho correspondentes;

• Obtenha o PlanDefinition que executa o Job de acordo com o PlanDefinitionRegistry e mobilize o runTask para executar o job;
  
  tome PersistDefinition como exemplo, descreva aproximadamente a operação do Job Executor e persista o armazenamento do Alluxio Block para o UFS subjacente:
  Obtenha o URI de armazenamento de dados de Alluxio e leia o fluxo de entrada de dados correspondente;

Obtenha o caminho de destino UFS especificado, julgue se o caminho existe de acordo com UfsClient, crie-o se não existir e crie o fluxo de saída com base em UnderFileSystem;

De acordo com a classe da ferramenta de operação de E/S, os dados são copiados do fluxo de dados para o fluxo de saída e persistidos no UFS.

Para [informações do evento] [artigos técnicos] [grandes visualizações de café] mais interessantes e informativos, preste atenção em [Alluxio Think Tank] :

{{o.name}}

{{m.name}}