A escolha da região e do armazenamento está entre as decisões mais importantes antes de criar um cluster E-MapReduce (EMR). A região correta elimina custos de transferência entre regiões e reduz a latência. Já a arquitetura de armazenamento adequada define como o cluster escala, qual será o custo e se os dados persistirão após o encerramento do cluster.
Selecione uma região
Implante seu cluster EMR na mesma região onde seus dados estão armazenados. Por exemplo, se os dados de source estiverem em um bucket do Object Storage Service (OSS) ou em uma instância do ApsaraDB RDS em China (Shanghai), crie o cluster também em China (Shanghai). Caso precise gravar saídas no OSS, crie o bucket de destino nessa mesma região. Manter o cluster e os dados no mesmo local evita tarifas de transferência entre regiões e diminui a latência.
Além da localidade dos dados, leve em conta os fatores abaixo ao escolher a região.
Fator | O que verificar |
Disponibilidade do service EMR | Verifique se o EMR está disponível na região desejada. Alguns serviços, como OSS-HDFS e Data Lake Formation (DLF), não existem em todas as regiões. Tipos de instância com SSDs locais também variam conforme a região. |
Preços de instâncias ECS | Os valores das instâncias do Elastic Compute Service (ECS) mudam conforme a região. Consulte a Calculadora de Preços do ECS para comparar custos antes de tomar uma decisão. |
Topologia de serviços | Posicione o EMR na mesma região dos serviços dependentes — como vpc, slb e bancos de dados — para evitar taxas de operação entre regiões. Em cenários de cloud híbrida, escolha a região mais próxima do ponto de acesso do seu data center. |
Regiões suportadas
|
Área geográfica |
Regiões |
|
Ásia-Pacífico - China |
China (Hangzhou), China (Shanghai), China (Qingdao), China (Beijing), China (Zhangjiakou), China (Hohhot), China (Ulanqab), China (Shenzhen), China (Chengdu), China (Hong Kong) |
|
Ásia-Pacífico - Outras |
Japan (Tokyo), Singapore, Malaysia (Kuala Lumpur), Indonesia (Jakarta) |
|
Europa e Américas |
Germany (Frankfurt), UK (London), US (Silicon Valley), US (Virginia) |
|
Oriente Médio |
UAE (Dubai) |
Planeje o armazenamento
Escolha uma arquitetura de armazenamento
O EMR oferece duas arquiteturas de armazenamento: separação de computação e armazenamento, e integração de computação e armazenamento.
O HDFS é efêmero. Todos os dados armazenados nele são excluídos permanentemente quando o cluster EMR é liberado. Se utilizar o HDFS, faça backup dos dados críticos no OSS ou OSS-HDFS antes de liberar o cluster.
Separação de computação e armazenamento (OSS-HDFS ou OSS) | Integração de computação e armazenamento (HDFS) | |
Cenário ideal | Arquitetura de data lake; análise de dados frios | Necessidade de leituras e gravações de baixa latência |
Persistência de dados | Os dados permanecem após a liberação do cluster | Os dados são excluídos quando o cluster é liberado |
Durabilidade dos dados | 99,9999999999% (doze noves) | Baseia-se no mecanismo de réplicas; sem recuperação de desastres entre regiões |
Confiabilidade dos dados | O OSS suporta armazenamento localmente redundante (LRS) e armazenamento redundante por zona (ZRS), garantindo alta confiabilidade entre zonas | Três réplicas para discos locais, duas réplicas para discos em nuvem; as réplicas ficam restritas ao cluster |
Dimensionamento | Adicione nós de computação (CNs) independentemente, sem alterar o armazenamento | Computação e armazenamento devem escalar juntos; a remoção de nós é sequencial e exige rebalanceamento |
Custo de armazenamento | 0,0170 USD/GB/Mês (armazenamento Standard do OSS). O OSS-HDFS também gera dados auxiliares, o que incorre em additional OSS storage fees. Consulte OSS billing. | 0,051 USD/GiB/Mês Consulte EBS block storage billing e ECS pricing. |
O&M | Os CNs não mantêm estado e podem ser substituídos rapidamente; a capacidade de armazenamento expande sem ajustes manuais no cluster | Falhas em DataNodes exigem rebalanceamento manual; redimensionar o cluster requer intervenção manual |
Acesso |
| Cluster HA: |
Escolha o tipo de disco
Cada nó de um cluster EMR possui um disco de sistema e, opcionalmente, um ou mais discos de dados.
|
Disco |
Finalidade |
Tipos suportados |
|
Disco de sistema |
Instala o sistema operacional; não armazena dados de negócios |
Apenas discos em nuvem |
|
Disco de dados |
Armazena dados, logs locais e dados de shuffle |
Discos em nuvem e discos locais |
Para uma mesma capacidade de armazenamento, configure vários discos de dados melhora a disponibilidade do service. Com múltiplos discos, serviços específicos conseguem oferecer tolerância a falhas, mantendo a funcionalidade geral dos discos de dados mesmo se um deles falhar.
Discos em nuvem
Os discos em nuvem utilizam um mecanismo de tripla cópia distribuída e oferecem 99,9999999% (nove noves) de confiabilidade de dados. O EMR suporta três tipos de discos em nuvem.
|
Tipo de disco |
Latência |
IOPS e throughput |
Indicado para |
|
0,2 ms |
Alto; suporta níveis de desempenho PL0 a PL3. Consulte ESSDs. |
Cargas sensíveis à latência ou intensivas em I/O: bancos de dados OLTP de grande escala, bancos NoSQL, Elasticsearch |
|
|
SSD Standard |
0,5–2 ms |
Relativamente alto |
Aplicações intensivas em I/O; bancos de dados relacionais e NoSQL de pequeno e médio porte |
|
Disco Ultra |
1–3 ms |
Médio |
Ambientes de desenvolvimento e teste; discos de sistema |
Para uma comparação detalhada de desempenho entre discos em nuvem e discos locais, consulte Block storage performance.
Discos locais
Local disks são conectados fisicamente ao servidor host e proporcionam latência extremamente baixa e alto throughput para armazenamento de dados em grande escala.
No console EMR, os discos locais são anexados quando você defina o Type do grupo de nós como Big Data ou Local SSD.
Discos locais são suportados apenas em nós core e task, não em nós master.
Dados em discos locais podem ser perdidos em caso de falha de hardware no host. Configure uma política de backup ao usar discos locais para dados de negócios.
Avalie a capacidade de armazenamento
Após definir a arquitetura de armazenamento, estime a capacidade de disco necessária com base no volume de dados e na tendência de crescimento. Planeje para cobrir pelo menos seis meses de expansão dos dados.
|
Tipo de dado |
Descrição |
Cálculo |
|
Dados brutos |
Dados gerados diretamente pelo seu negócio, como logs |
Espaço necessário = volume de dados brutos |
|
Dados intermediários |
Dados temporários gerados durante o processamento, como resultados de ETL |
Espaço necessário = volume de dados brutos × 1,5 (ajuste conforme a complexidade da carga) |
|
Dados de resultado |
Saída final que deve ser retida |
Espaço necessário = volume de dados brutos × 10%–50% (ajuste conforme os requisitos de retenção) |
Integração de computação e armazenamento (HDFS): Adicione a sobrecarga das réplicas ao total. O HDFS usa, por padrão, três réplicas para discos locais e duas réplicas para discos em nuvem.
Separação de computação e armazenamento (OSS-HDFS ou OSS): Os discos de dados precisam acomodar apenas resultados temporários de computação, logs locais e dados de shuffle. Os dados de negócios ficam armazenados de forma durável no OSS.