E-MapReduce:Use the transparent caching feature of JindoCache to accelerate access to OSS

Como funciona

O JindoCache organiza o comportamento de cache em CacheSets. Cada CacheSet associa uma política de cache a um prefixo de caminho do OSS: todos os dados lidos nesse prefixo são armazenados em cache conforme a política definida. Configure vários CacheSets para aplicar políticas diferentes a conjuntos de dados distintos.

Após configurar um CacheSet e definir fs.xengine=jindocache no Hadoop, todos os jobs que acessam os caminhos do OSS abrangidos passam a usar o cache automaticamente. Os jobs não precisam chamar nenhuma API de cache, pois o processo é totalmente transparente.

Pré-requisitos

Antes de começar, verifique se você tem:

• Um cluster EMR com o JindoCache ativado (selecionado durante a criação do cluster). Para mais detalhes, consulte Criar um cluster.

• Uma instância do OSS ativada. Para mais detalhes, consulte Ativar o OSS.

Observações de uso

• O OSS armazena arquivos como objetos. Os termos "arquivo" e "objeto" referem-se aos mesmos dados quando o contexto envolve o OSS.

• Se metaPolicy estiver definido como ONCE, o JindoCache lê os metadados do OSS apenas uma vez e os armazena em cache localmente. Caso os dados subjacentes no OSS mudem após essa leitura inicial, os jobs poderão ler metadados desatualizados até a atualização do cache. Utilize ALWAYS se seus dados mudarem com frequência e for necessária consistência forte.

• O cache transparente oferece maior benefício para cargas de trabalho com muitas leituras, nas quais os mesmos dados são acessados várias vezes. Cargas intensivas em escrita, que raramente releem os mesmos dados, obtêm pouco ganho com o uso de cache.

Configurar políticas de cache

1. Faça login no seu cluster. Para mais detalhes, consulte Fazer login em um cluster.

2. Crie um arquivo cacheset.xml. O exemplo a seguir armazena o arquivo no diretório /path.

   <?xml version="1.0" encoding="UTF-8"?>
   <cachesets>
       <cacheset>
           <name>name1</name>
           <path>oss://emr-test/dir1</path>
           <cacheStrategy>DISTRIBUTED</cacheStrategy>
           <metaPolicy>
               <type>ALWAYS</type>
           </metaPolicy>
           <readPolicy>CACHE_ASIDE</readPolicy>
           <writePolicy>WRITE_AROUND</writePolicy>
       </cacheset>
       <cacheset>
           <name>name2</name>
           <path>oss://emr-test/dir2</path>
           <cacheStrategy>DHT</cacheStrategy>
           <metaPolicy>
               <type>ONCE</type>
           </metaPolicy>
           <readPolicy>CACHE_ASIDE</readPolicy>
           <writePolicy>WRITE_AROUND</writePolicy>
       </cacheset>
   </cachesets>

   A tabela a seguir descreve os parâmetros.

   Parâmetro	Descrição	Exemplo
   name	Nome exclusivo para o CacheSet. Se já existir um CacheSet com o mesmo nome, a configuração dele será substituída.	name1
   path	Prefixo de caminho do OSS abrangido por este CacheSet. A política se aplica a todos os objetos dentro desse caminho.	oss://emr-test/dir1
   cacheStrategy	Estratégia de distribuição do cache. DISTRIBUTED: uso geral, adequada para a maioria das cargas de trabalho. DHT (tabela hash distribuída): otimizada para arquivos pequenos e somente leitura.	DISTRIBUTED
   Tipo de metaPolicy	Forma como o JindoCache trata os metadados dos objetos. ALWAYS: os metadados são sempre lidos do OSS, garantindo consistência forte, mas com maior latência. ONCE: os metadados são lidos do OSS apenas uma vez e armazenados em cache localmente, reduzindo a latência, mas podendo resultar em leituras desatualizadas se os dados do OSS forem alterados. Se cacheStrategy for DHT, defina este valor como ONCE.	ALWAYS
   readPolicy	Estratégia de leitura. Deve ser CACHE_ASIDE: as leituras são atendidas pelo cache quando disponíveis e buscadas no OSS em caso de falta no cache.	CACHE_ASIDE
   writePolicy	Estratégia de escrita. WRITE_AROUND: as escritas vão diretamente para o OSS, ignorando o cache — use para dados gravados uma única vez e raramente relidos. WRITE_THROUGH: as escritas vão simultaneamente para o cache e para o OSS — use quando for necessária consistência do cache com uma latência de escrita ligeiramente maior. CACHE_ONLY: as escritas vão apenas para o cache e não são persistidas no OSS; exige que metaPolicy esteja definido como ONCE.	WRITE_AROUND

3. Atualize o JindoCache com a nova configuração do CacheSet.

   jindocache -refreshCacheSet -path /path/cacheset.xml

   Se o comando for executado com êxito, a saída conterá Successfully refresh cacheset !!!. Para obter a lista completa de comandos do JindoCache, consulte Notas de uso da CLI do JindoCache.

4. Verifique se os CacheSets foram registrados.

   jindocache -listCacheSet

Ativar o cache transparente no Hadoop

Defina o item de configuração fs.xengine no Hadoop-Common para que o JindoCache intercepte as solicitações de leitura do OSS.

No console do EMR, acesse a página de serviço do Hadoop-Common, clique em Configure e, em seguida, clique em core-site.xml. Adicione ou atualize o seguinte item de configuração. Para obter detalhes sobre como gerenciar itens de configuração, consulte Gerenciar itens de configuração.

Essa configuração entra em vigor imediatamente, sem necessidade de reiniciar o JindoCache.

Após salvar a configuração, todos os jobs que acessam caminhos do OSS abrangidos pelos seus CacheSets usarão automaticamente o cache nas leituras subsequentes.

Perguntas frequentes

Próximos passos

• Notas de uso da CLI do JindoCache

• Gerenciar itens de configuração