Perguntas frequentes sobre o Amazon EMR

P: O que é o Amazon EMR?

Amazon EMR é a plataforma de big data em nuvem líder do setor para processamento de dados, análise interativa e machine learning que usa estruturas de código aberto, como Apache Spark, Apache Hive e Presto. Com o EMR, você pode executar análises em escala de petabytes por menos da metade do custo das soluções tradicionais locais e mais de 1,7 vezes mais rapidamente do que com o Apache Spark padrão.

P: Por que devo usar o Amazon EMR?

O Amazon EMR permite que você se concentre na transformação e análise de seus dados sem ter que se preocupar com a gestão da capacidade computacional ou aplicações de código aberto, além de ser econômico. Com o EMR, você pode provisionar instantaneamente a capacidade que desejar no Amazon EC2 e configurar regras de escalabilidade para gerenciar as mudanças na demanda de computação. Você pode configurar alertas do CloudWatch para receber notificações de mudanças em sua infraestrutura e tomar medidas imediatamente. Caso utilize Kubernetes, você também pode usar EMR para enviar suas workloads para clusters do Amazon EKS. Independentemente de utilizar EC2 ou EKS, você se beneficia do tempo de execução otimizado do EMR, que acelera sua análise e gera economia de tempo e dinheiro.

P: Como posso implantar e gerenciar o Amazon EMR?

Você pode implantar suas workloads em EMR usando Amazon EC2, Amazon Elastic Kubernetes Service (EKS) ou AWS Outposts nos locais. Você pode executar e gerenciar suas workloads com o console EMR, API, SDK ou CLI e orquestrá-los usando Amazon Managed Workflows for Apache Airflow (MWAA) ou AWS Step Functions. Para uma experiência interativa, utilize o EMR Studio ou SageMaker Studio.

P: Como posso começar a usar o Amazon EMR?

P: Onde posso encontrar exemplos de códigos?

Verifique o código de exemplo nestes artigos e tutoriais. Se você usa o EMR Studio, pode explorar os recursos usando um conjunto de exemplos de notebook.

P: Como desenvolvo um aplicativo de processamento de dados?

Você pode desenvolver, visualizar e depurar aplicações de ciência de dados e engenharia de dados escritos em R, Python, Scala e PySpark noAmazon EMR Studio. Você também pode desenvolver um trabalho de processamento de dados no computador, por exemplo, usando Eclipse, Spyder, PyCharm ou RStudio, e executá-lo no Amazon EMR. Além disso, é possível selecionar JupyterHub ou Zeppelin na configuração do software ao ativar um novo cluster e desenvolver sua aplicação no Amazon EMR com o uso de uma ou mais instâncias.

P: Qual é a vantagem de usar as ferramentas da linha de comando ou as APIs em vez do Console de Gerenciamento da AWS

As Ferramentas da linha de comando ou as APIs fornecem a capacidade de iniciar programaticamente e monitorar o andamento dos clusters em execução, criar uma funcionalidade personalizada adicional com relação aos clusters (como sequências com várias etapas de processamento, programação, fluxo de trabalho ou monitoramento) ou elaborar ferramentas ou aplicativos de valor agregado para outros clientes do Amazon EMR. Em contrapartida, o Console de Gerenciamento da AWS fornece uma interface gráfica fácil de usar para a inicialização e o monitoramento dos clusters diretamente com base em um navegador da web.

P: Posso adicionar etapas a um cluster que já esteja em execução?

Sim. Assim que o trabalho estiver em execução, também será possível adicionar mais etapas a ele por meio da API AddJobFlowSteps. A API AddJobFlowSteps adicionará novas etapas ao final da sequência atual de etapas. Talvez você queira usar esta API para implementar uma lógica condicional ao cluster ou para depuração.

P: Posso ser notificado quando o cluster for concluído?

Você pode cadastrar-se no Amazon SNS para que o cluster seja publicado no seu tópico SNS quando ele terminar. Você também pode ver o progresso do seu cluster no Console de gerenciamento da AWS, ou usar a linha de comando, o SDK ou as APIs para obter o status do cluster.

P: Posso terminar meu cluster quando as etapas terminarem?

Sim. Você pode terminar seu cluster automaticamente quando todos os seus passos terminarem, ligando a bandeira de terminação automática.

P: Quais versões de SO são compatíveis com o Amazon EMR?

O Amazon EMR 5.30.0, versões posteriores e a série Amazon EMR 6.x são baseados no Amazon Linux 2. Você também pode especificar uma AMI personalizada que cria com base no Amazon Linux 2. Dessa forma, você pode executar pré-configurações sofisticadas para praticamente qualquer aplicativo. Para obter mais informações, consulte Usar uma AMI personalizada.

P: O Amazon EMR é compatível com pacotes de software de terceiros?

Sim. Você pode usar Bootstrap Actions para instalar pacotes de software de terceiros em seu cluster. Também é possível fazer upload de executáveis compilados estatisticamente usando o mecanismo de cache distribuído do Hadoop. O EMR 6.x suporta o Hadoop 3, que permite que o YARN NodeManager lance contêineres diretamente ou no servidor do cluster EMR ou dentro de um contêiner Docker. Para saber mais, consulte a nossa documentação.

P: Quais ferramentas estão disponíveis para mim para depuração?

Há várias ferramentas que você pode usar para reunir informações sobre seu cluster para ajudar a determinar o que deu errado. Se você usa o Amazon EMR Studio, pode lançar ferramentas como Spark UI e YARN Timeline Service para simplificar a depuração. No Amazon EMR Console, você pode obter acesso off-cluster a interfaces de usuário de aplicações permanentes para Apache Spark, Tez UI e o servidor de linha do tempo YARN, várias interfaces de usuário de aplicações on-cluster e uma visão resumida do histórico de aplicações no console Amazon EMR para todas as aplicações YARN. Você também pode se conectar ao seu nó principal usando SSH e visualizar as instâncias do cluster por meio dessas interfaces da web. Para obter mais informações, consulte nossa documentação.

P: O que é o EMR Studio?

O EMR Studio é um ambiente de desenvolvimento integrado (IDE) que torna fácil para os cientistas e engenheiros de dados desenvolverem, visualizarem e depurarem aplicações de engenharia de dados e ciência de dados escritas em R, Python, Scala e PySpark.

É uma aplicação totalmente gerenciada com autenticação única, blocos de anotações Jupyter totalmente gerenciados, provisionamento de infraestrutura automatizado e a capacidade de depuração de trabalhos sem a necessidade de fazer login no Console ou cluster AWS. Cientistas e analistas de dados podem instalar kernels e bibliotecas personalizados, colaborar com colegas usando repositórios de código como GitHub e BitBucket ou executar blocos de anotações parametrizados como parte de fluxos de trabalho programados usando serviços de orquestração como o Apache Airflow, AWS Step Functions ou Amazon Managed Workflows para Apache Airflow. Você pode ler trabalhos de análise de orquestração nos blocos de anotações do Amazon EMR usando o Amazon MWAA para saber mais. Os kernels e aplicações do EMR Studio são executados em clusters do EMR de forma que você obtenha o benefício do processamento distribuído de dados usando a performance otimizada do tempo de execução do Amazon EMR para o Apache Spark. Os administradores podem configurar o EMR Studio para que os analistas possam executar seus aplicativos em clusters EMR existentes ou criar novos clusters usando modelos predefinidos da AWS CloudFormation para EMR.

P: O que posso fazer com o EMR Studio?

Com o EMR Studio, você pode fazer login diretamente nos blocos de anotações Jupyter totalmente gerenciados usando suas credenciais corporativas sem fazer login no console AWS, iniciar os blocos de anotações em segundos, entrar a bordo com os blocos de anotações de amostra e realizar sua exploração de dados. Você também pode personalizar o ambiente carregando kernels personalizados e bibliotecas python de blocos de anotações. Os kernels e aplicações do EMR Studio são executados em clusters do EMR de forma que você obtenha o benefício do processamento distribuído de dados usando a performance otimizada do tempo de execução do Amazon EMR para o Apache Spark. Você pode colaborar com os colegas compartilhando blocos de anotações via GitHub e outros repositórios. Você também pode executar blocos de anotações diretamente como integração contínua e pipelines de implantação. Você pode passar diferentes valores de parâmetros para um bloco de anotações. Você também pode ligar blocos de anotações e integrar blocos de anotações em fluxos de trabalho programados usando serviços de orquestração de fluxo de trabalho como o Apache Airflow. Além disso, você pode depurar clusters e trabalhos usando o menor número possível de cliques com interfaces de aplicações nativas como a Spark UI e o serviço YARN Timeline.

Q: Qual a diferença entre o EMR Studio e os Blocos de anotações do EMR?

Há cinco diferenças principais.

1. Não há necessidade de acessar o Console de gerenciamento da AWS para o EMR Studio. O EMR Studio é hospedado fora do Console de gerenciamento da AWS. Isso é útil se você não fornecer aos cientistas ou engenheiros de dados acesso ao Console de gerenciamento da AWS.
2. Você pode usar as credenciais empresariais de seu fornecedor de identidade usando o AWS IAM Identity Center (sucessor do AWS SSO) para fazer login no EMR Studio. 
3. O EMR Studio traz para você uma primeira experiência com blocos de anotações. Os kernels e aplicações do EMR Studio são executados em clusters do EMR de forma que você obtenha o benefício do processamento distribuído de dados usando a performance otimizada do tempo de execução do Amazon EMR para o Apache Spark. A execução do código em um cluster é tão simples quanto anexar o bloco de anotações a um cluster existente ou provisionar um novo.
   
4. O EMR Studio tem uma interface de usuário simplificada e abstrai as configurações de hardware. Por exemplo, você pode configurar os modelos de cluster uma vez e usar os modelos para iniciar novos clusters. 
5. O EMR Studio permite uma experiência de depuração simplificada para que você possa acessar as interfaces de usuário da aplicação nativa em um único lugar usando o menor número de cliques possível.

Q: Qual a diferença entre o EMR Studio e o SageMaker Studio?

Você pode usar o EMR Studio e o SageMaker Studio com o Amazon EMR. O EMR Studio fornece um ambiente de desenvolvimento integrado (IDE) que facilita o desenvolvimento, a visualização e a depuração de aplicações de engenharia e ciência de dados escritos em R, Python, Scala e PySpark. O Amazon SageMaker Studio fornece uma interface visual única baseada na Web em que você pode executar todas as etapas de desenvolvimento de machine learning. O SageMaker Studio fornece acesso, controle e visibilidade completos em cada etapa necessária para criar, treinar e implantar modelos. Você pode fazer upload de dados, criar novos blocos de anotações, treinar e ajustar modelos, alternar entre as etapas para ajustar experimentos, comparar resultados e implantar modelos na produção em um único local com rapidez, tornando-se muito mais produtivo. 

P: Como faço para começar a usar o EMR Studio?

Seu administrador deve primeiro configurar o EMR Studio. Quando você receber de seu administrador uma URL única de login para seu Estúdio Amazon EMR da Amazon, você poderá fazer o login diretamente no Estúdio usando suas credenciais corporativas.

P: Preciso fazer o login no Console de gerenciamento AWS para usar o EMR Studio?

Não. Depois que seu administrador configurar um EMR Studio e fornecer a URL de acesso ao Studio, sua equipe poderá fazer o login usando as credenciais corporativas. Não é preciso fazer login no Console de gerenciamento da AWS. Em um EMR Studio, sua equipe pode realizar tarefas e acessar recursos configurados por seu administrador.

P: Quais fornecedores de identidade são compatíveis com a experiência de login único no EMR Studio?

O AWS IAM Identity Center (sucessor do AWS SSO) é o provedor de serviços de logon único para o EMR Studio. Você encontra a lista de fornecedores de identidade compatíveis com o AWS IAM em nossa documentação.

P: O que é um WorkSpace no EMR Studio?

Workspaces ajudam você a organizar os Blocos de anotações Jupyter. Todos os blocos de anotações em um Workspace são salvos no mesmo local do Amazon S3 e funcionam no mesmo cluster. Você também pode ligar um repositório de código como um repositório GitHub a todos os blocos de anotações em um workspace. Você pode criar e configurar um Workspace antes de anexá-lo a um cluster, mas você deve se conectar a um cluster antes de executar um bloco de anotações.

P: No EMR Studio, posso criar um workspace ou abrir um workspace sem um cluster?

Sim, você pode criar ou abrir um workspace sem anexá-lo a um cluster. Somente quando for necessário executá-los, você deve conectá-los a um cluster. Os kernels e aplicações do EMR Studio são executados em clusters do EMR, de forma que você obtenha o benefício do processamento distribuído de dados usando a performance otimizada do tempo de execução do Amazon EMR para o Apache Spark.

P: Posso instalar bibliotecas personalizadas para usar no código do meu notebook?

Todas as consultas do Spark são executadas no cluster do EMR. Portanto, você precisa instalar todas as bibliotecas de runtime que seu aplicativo Spark usar no cluster. Você pode instalar facilmente bibliotecas com escopo de notebook em uma célula de notebook. Você também pode instalar kernels do Jupyter Notebook e bibliotecas Python em um nó principal do cluster dentro de uma célula do notebook ou enquanto estiver conectado usando SSH ao nó principal do cluster. Para obter mais informações, consulte a documentação. Além disso, você pode usar uma ação de bootstrap ou uma AMI personalizada para instalar as bibliotecas necessárias quando criar um cluster. Para obter mais informações, consulte Criar ações de bootstrap para instalar software adicional e Uso de uma AMI personalizada no Guia de gerenciamento do Amazon EMR.

P: Onde os notebooks são salvos?

O Workspace junto com os arquivos do notebook na área de trabalho são salvos automaticamente em intervalos regulares no formato de arquivo ipynb no local do Amazon S3 especificado durante a criação da área de trabalho. O arquivo do notebook tem o mesmo nome que seu notebook no Amazon EMR Studio.

P: Como faço para usar o controle de versão com meu notebook? Posso usar repositórios, como o GitHub?

Você pode associar repositórios baseados em Git aos Amazon EMR Studio notebooks para salvar seus notebooks em um ambiente com controle de versão.

P: No EMR Studio, em que recursos de computação posso executar os blocos de anotações?

Com o EMR Studio, você pode executar o código do bloco de anotações no Amazon EMR em execução no Amazon Elastic Compute Cloud (Amazon EC2) ou Amazon EMR no Amazon Elastic Kubernetes Service (Amazon EKS). Você pode anexar blocos de anotações a clusters existentes ou novos. Você pode criar clusters EMR de duas maneiras no EMR Studio: criar um cluster usando um modelo de cluster pré-configurado via AWS Service Catalog, criar um cluster especificando o nome do cluster, o número de instâncias e o tipo de instância.

P: Posso reimplantar um workspace com um recurso de computação diferente no EMR Studio?

Sim, você pode abrir seu workspace, escolher o ícone EMR Clusters à esquerda, apertar o botão Destacar, e então selecionar um cluster da lista suspensa Selecionar cluster, e apertar o botão Anexar.

P: Onde posso encontrar todos os meus workspaces no EMR Studio?

No EMR Studio, você pode escolher a aba Workspaces à esquerda e visualizar todos os workspaces criados por você e outros usuários na mesma conta AWS.

 P: Quais as políticas do IAM necessárias para o uso do EMR Studio?

Cada EMR Studio precisa de permissões para interoperar com outros serviços AWS. Para dar a seus EMR Studios as permissões necessárias, seus administradores precisam criar uma função de serviço EMR Studio com as políticas fornecidas. Também é necessário especificar uma função do usuário para o EMR Studio que define permissões de nível do Studio. Quando adicionam usuários e grupos do AWS IAM Identity Center (sucessor do AWS SSO) ao EMR Studio, eles podem atribuir uma política de sessão a um usuário ou grupo para aplicar os controles finos de permissão do site. As políticas de sessão ajudam os administradores a refinarem sem a necessidade de criar múltiplos perfis do IAM. Para mais informações sobre as políticas de sessão, consulte Políticas e permissões no Guia do usuário do AWS Identity and Access Management.

P: Existe alguma limitação nos clusters EMR aos quais posso anexar meu espaço de trabalho no EMR Studio?

Sim. Os clusters de alta disponibilidade (Multi-master), os clusters Kerberized e os clusters do AWS Lake Formation não são atualmente suportados.

P: Qual o custo do uso do Amazon EMR Studio?

O Amazon EMR Studio é fornecido sem custo adicional para você. Encargos aplicáveis para armazenamento do Amazon Simple Storage Service e para clusters do Amazon EMR se aplicam quando você usa o EMR Studio. Para obter mais informações sobre opções de preços e detalhes, consulte Preços do Amazon EMR.

P: O que são Notebooks EMR?

Recomendamos que os novos clientes usem o Amazon EMR Studio, não os EMR Notebooks. Os Notebooks EMR disponibilizam um ambiente gerenciado, baseado no Notebook Jupyter, que possibilita que cientistas de dados, analistas e desenvolvedores preparem e visualizem dados, desenvolvam aplicativos e executem análises interativas usando clusters do EMR. Embora recomendemos que novos clientes usem o EMR Studio, o EMR Notebooks é compatível.

P: O que posso fazer com Notebooks EMR?

Você pode usar Blocos de anotações do EMR para criar aplicativos Apache Spark e executar consultas interativas no seu cluster do EMR sem esforço. Vários usuários podem criar blocos de anotações sem servidor diretamente do console, conectá-los a um cluster do EMR existente ou fornecer um cluster diretamente do console e imediatamente começar a usar o Spark. É possível desconectar blocos de anotações e reconectá-los a novos clusters. Os notebooks são salvos automaticamente em buckets do S3 e você pode recuperar os notebooks salvos no console para reiniciar o trabalho. Notebooks EMR são fornecidos com as bibliotecas encontradas no repositório Anaconda, permitindo que você importe e use estas bibliotecas no código dos seus notebooks e as use para manipular dados e visualizar resultados. Além disso, os notebooks EMR possuem recursos integrados de monitoramento do Spark que você pode usar para monitorar o progresso dos seus trabalhos no Spark e depurar o código de dentro do notebook.

P: Como faço para começar a usar os Notebooks EMR?

Para começar a usar os Notebooks EMR, abra o console do EMR e selecione Notebooks no painel de navegação. A partir daí, selecione Criar Notebook, digite um nome para o notebook, selecione um cluster do EMR ou crie instantaneamente um novo, forneça uma função de serviço para o notebook usar e selecione um bucket do S3 onde você deseje salvar os arquivos do notebook e, a seguir, clique em Criar Notebook. Depois que o notebook mostrar o status Pronto, selecione Abrir para iniciar o editor do notebook.

P: Que versões do EMR são compatíveis com Notebooks EMR?

Os Notebooks EMR podem ser conectados a clusters do EMR que executarem a versão 5.18.0 ou posterior do EMR.

P: Qual o custo do uso de Blocos de anotações do EMR?

Blocos de anotações do EMR são fornecidos sem despesas adicionais a você. Você será cobrado na sua conta da maneira usual pelos clusters do EMR conectados. Você encontrará mais detalhes sobre a definição de preço do seu cluster acessando https://aws.amazon.com/emr/pricing/   

P: Como faço para colocar dados no Amazon S3?

O Amazon EMR oferece várias maneiras de obter dados em um cluster. A maneira mais comum é carregar os dados no Amazon S3 e usar os recursos embutidos do Amazon EMR para carregar os dados em seu cluster. Você pode usar o recurso de Cache distribuído do Hadoop para transferir arquivos de um sistema de arquivo distribuído para o sistema de arquivo local. Consulte a documentação para obter mais detalhes. Alternativamente, se você estiver migrando dados do local para a nuvem, você pode usar um dos serviços de migração de dados da AWS.

P: Como obtenho logs sobre clusters concluídos?

Os logs do sistema Hadoop, assim como logs de usuário, serão posicionados no bucket do Amazon S3 que você especifica ao criar um cluster. UIs de aplicação persistentes são executadas off-cluster, logs de servidores de tempo do Spark History Server, Tez UI e YARN estão disponíveis por 30 dias após o término de um aplicativo.

P: Você compacta logs?

Não. No momento, o Amazon EMR não compacta logs à medida que os transfere para o Amazon S3.

P: Posso carregar meus dados com base na Internet ou em outro local além do Amazon S3?

Sim. Você pode usar o AWS Direct Connect para estabelecer conexões de rede dedicadas das suas instalações para a AWS. Se você tiver grandes quantidades de dados, você pode usar AWS Import/Export. Para obter mais detalhes, consulte a documentação.

P: O Amazon EMR estima quanto tempo levará para que os dados de entrada sejam processados?

Não. Como cada cluster e dados de entrada são diferentes, não podemos estimar a duração do trabalho.

P: Quanto custa o Amazon EMR?

A definição de preço do Amazon EMR é simples e previsível: você paga uma taxa por segundo para cada segundo usado, com um mínimo de um minuto. Você pode estimar sua fatura usando a Calculadora de preço AWS. O uso de outros Amazon Web Services, incluindo Amazon EC2, é cobrado separadamente do Amazon EMR.

P: Quando o faturamento do uso que eu fizer do meu cluster Amazon EMR começa e termina?

A cobrança do Amazon EMR começa quando o cluster está pronto para executar as etapas. A cobrança do Amazon EMR termina quando você solicita o fechamento do cluster. Para mais detalhes sobre quando o Amazon EC2 começa e termina a cobrança, consulte a Perguntas frequentes sobre cobrança do Amazon EC2.

P: Onde posso monitorar o uso do Amazon EMR, Amazon EC2 e Amazon S3?

Você pode acompanhar o seu uso no Console de gerenciamento de cobrança e custos.

P: Como você calcula as horas de instâncias normalizadas exibidas no console?

No Console de Gerenciamento da AWS, cada cluster tem uma coluna Normalized Instance Hours que exibe o número aproximado de horas de computação usadas pelo cluster, arredondado para a hora mais próxima.

As horas de instâncias normalizadas são horas do período calculado com base no padrão de uso 1 hora de m1.small = período calculado normalizado de 1 hora. Você pode ver nossa documentação para ver uma lista de tamanhos diferentes dentro de uma família de instância, e o fator de normalização correspondente por hora.

Por exemplo, se você executar um cluster r3.8xlarge de 10 nós por uma hora, o número total de horas de instâncias normalizadas exibido no console será de 640 (10 (número de nós) x 64 (fator de normalização) x 1 (quantidade de horas da execução do cluster) = 640).

Trata-se de um número aproximado e não deve ser usado para fins de faturamento. Consulte o Billing & Cost Management Console para obter o uso faturável do Amazon EMR.

P: O Amazon EMR é compatível com instâncias sob demanda, spot e reservadas do Amazon EC2?

Sim. O Amazon EMR é perfeitamente compatível com instâncias sob demanda, spot e reservadas. Clique aqui para obter mais informações sobre Instâncias reservadas do Amazon EC2. Clique aqui para obter mais informações sobre Instâncias spot do Amazon EC2. Clique aqui para saber mais sobre as reservas de capacidade do Amazon EC2.

P: Os preços incluem impostos?

Salvo indicação em contrário, nossos preços excluem impostos e taxas aplicáveis, incluindo o IVA e o imposto sobre vendas aplicável. Para clientes com endereço de pagamento no Japão, o uso da AWS está sujeito ao imposto sobre consumo japonês. Saiba mais. 

P: Como impeço que outras pessoas visualizem os dados durante a execução do cluster?

O Amazon EMR inicia as instâncias em dois grupos de segurança do Amazon EC2, um para o principal e outro para os demais nós do cluster. O grupo de segurança mestre tem uma porta aberta para comunicação com o serviço. Ele também tem a porta SSH aberta para permitir que você aplique o SSH às instâncias, usando a chave especificada na inicialização. Os outros nós começam em um grupo de segurança separado, que permite a interação somente com a instância principal. Como padrão, ambos os grupos de segurança são configurados para não permitir o acesso de fontes externas, incluindo instâncias do Amazon EC2 pertencentes a outros clientes. Como esses grupos de segurança estão dentro da sua conta, é possível configurá-los usando as ferramentas padrão ou o painel do EC2. Clique aqui para obter mais informações sobre security groups do EC2. Além disso, você pode configurar o acesso público de bloqueio do Amazon EMR em cada região que você usa para evitar a criação de cluster se uma regra permitir o acesso público em qualquer porta que você não adicionar a uma lista de exceções.

P: Meus dados estão seguros?

O Amazon S3 fornece mecanismos de autenticação para assegurar que os dados armazenados estejam protegidos contra acesso não autorizado. A menos que o cliente que esteja fazendo o upload dos dados especifique em contrário, somente aquele cliente pode acessar os dados. Os clientes do Amazon EMR também podem optar por enviar dados para o Amazon S3 usando o protocolo HTTPS para uma transmissão segura. Além disso, o Amazon EMR sempre usa HTTPS para enviar dados entre o Amazon S3 e o Amazon EC2. Para uma segurança maior, os clientes poderão criptografar os dados de entrada antes de fazerem o upload desses dados para o Amazon S3 (usando qualquer ferramenta comum de criptografia de dados). Em seguida, eles precisam adicionar uma etapa de descriptografia ao início do seu cluster quando o Amazon EMR analisa os dados do Amazon S3.

P: É possível obter um histórico de todas as chamadas de API do EMR realizadas na minha conta para auditoria de segurança ou conformidade?

Sim. O AWS CloudTrail é um web service que registra as chamadas de APIs da AWS para a sua conta e envia os arquivos de log para você. O histórico de chamadas de APIs da AWS gerado pelo CloudTrail possibilita análises de segurança, rastreamento de alteração de recursos e auditoria de conformidade. Saiba mais sobre o CloudTrail na página de detalhes do AWS CloudTrail e ative-o no Console de Gerenciamento da AWS do CloudTrail.

P: Como posso controlar o que os usuários EMR podem acessar no Amazon S3?

Por padrão, os processos do aplicações do Amazon EMR usam perfis de instância do EC2 quando chamam outros serviços da AWS. Para clusters multilocatários, o Amazon EMR oferece três opções para gerenciar o acesso do usuário a dados do Amazon S3.

1. A integração com o AWS Lake Formation permite que você defina e gerencie políticas de autorização refinadas no AWS Lake Formation para acessar bancos de dados, tabelas e colunas no AWS Glue Data Catalog. Você pode aplicar as políticas de autorização em trabalhos enviados por meio dos blocos de anotações do Amazon EMR e do Apache Zeppelin para cargas de trabalho interativas do EMR Spark, além de enviar eventos de auditoria ao AWS CloudTrail. Ao habilitar essa integração, você também habilita o Single Sign-On federado em blocos de anotações do EMR ou Apache Zeppelin a partir de sistemas de identidade corporativos compatíveis com Security Assertion Markup Language (SAML) 2.0.
   
2. A integração nativa com o Apache Ranger permite configurar um servidor Apache Ranger novo ou existente para definir e gerenciar políticas de autorização refinadas para usuários acessarem bancos de dados, tabelas e colunas de dados do Amazon S3 por meio do Hive Metastore. O Apache Ranger é uma ferramenta de código aberto utilizada para habilitar, monitorar e gerenciar a segurança abrangente de dados em toda a plataforma Hadoop.
   
   Essa integração nativa permite definir três tipos de políticas de autorização no servidor Policy Admin do Apache Ranger. Você pode definir autorização de nível de tabela, coluna e linha para o Hive, autorização de nível de tabela e coluna para o Spark e autorização de nível de prefixo objeto para o Amazon S3. O Amazon EMR instala e configura automaticamente os plug-ins do Apache Ranger correspondentes no cluster. Esses plug-ins do Ranger são sincronizados com o servidor Policy Admin para políticas de autorização, aplicação do controle de acesso a dados e envio de eventos de auditoria para o Amazon CloudWatch Logs.
   
3. O Amazon EMR User Role Mapper permite utilizar as permissões do AWS IAM para gerenciar os acessos aos recursos da AWS. Você pode criar mapeamentos entre os usuários (ou grupos) e funções do IAM personalizadas. Um usuário ou grupo só pode acessar os dados permitidos pela função do IAM personalizada. No momento, esse recurso só está disponível por meio dos Laboratórios da AWS.

P: Como o Amazon EMR usa as zonas de disponibilidade?

O Amazon EMR inicia todos os nós para um determinado cluster na mesma zona de disponibilidade do Amazon EC2. A execução de um cluster na mesma zona aprimora a performance dos fluxos de trabalho. Como padrão, o Amazon EMR seleciona a zona de disponibilidade com a maioria dos recursos disponíveis nos quais o cluster será executado. Porém, é possível especificar outra zona de disponibilidade, se exigido. Você também tem a opção de otimizar sua alocação para instâncias sob demanda de menor preço, capacidade local ideal ou usar reservas de capacidade sob demanda.

P: Em quais regiões esse Amazon EMR está disponível?

Para ver uma lista das regiões da AWS com suporte no Amazon EMR, visite a tabela de regiões da AWS para toda a infraestrutura global da AWS.

P: O Amazon EMR é compatível com o AWS Local Zones?

O EMR é compatível com a execução de clusters na zona local de Los Angeles da AWS. Você pode usar o EMR na região Oeste dos EUA (Oregon) para executar clusters em sub-redes associadas à zona local de Los Angeles da AWS.

P: Qual região deve ser selecionada para execução dos meus clusters?

Ao criar um cluster, normalmente você deve selecionar a região onde os dados estão localizados.

P: Posso usar dados da UE em um cluster sendo executado na região dos EUA e vice-versa?

Sim. Se você transferir dados de uma região para outra, haverá a cobrança dos encargos de largura de banda. Para obter informações sobre definição de preço de largura de banda, acesse a seção de definição de preço na página de detalhes do EC2.

P: Qual é a diferença da região AWS GovCloud (EUA)?

A região AWS GovCloud (EUA) é destinada a agências e clientes do governo dos EUA. A região cumpre os requisitos do US ITAR. Na GovCloud, o EMR não oferece suporte a instâncias spot nem ao recurso de ativação de depuração. O Console de gerenciamento do EMR ainda não está disponível na GovCloud.

P: O que é um cluster do Amazon EMR?
Um cluster é um conjunto de instâncias do Amazon Elastic Compute Cloud (Amazon EC2). Cada instância do cluster é chamada de nó e possui uma função dentro do cluster, chamada de tipo de nó. O Amazon EMR também instala diferentes componentes de software em cada tipo de nó, conferindo a cada nó uma função em uma aplicação distribuída como o Apache Hadoop. Cada cluster tem um identificador exclusivo começando com "j-".

P: Quais são os tipos de nó em um cluster?
Um cluster Amazon EMR possui três tipos de nós:

1. Nó principal: um nó que gerencia o cluster executando componentes de software para coordenar a distribuição de dados e tarefas entre outros nós para processamento. O nó principal rastreia o status das tarefas e monitora a integridade do cluster. Cada cluster possui um nó principal e é possível criar um cluster de nó único com apenas o nó principal.
2. Nó central: um nó com componentes de software que executam tarefas e armazenam dados no Hadoop Distributed File System (HDFS) em seu cluster. Os clusters de vários nós possuem pelo menos um nó principal.
3. Nó de tarefa: um nó com componentes de software que apenas executa tarefas e não armazena dados no HDFS. Os nós de tarefas são opcionais.
   
   

P: O que é uma etapa de cluster?
Uma etapa do cluster é uma unidade de processamento definida pelo usuário, mapeando aproximadamente um algoritmo que manipula os dados. Uma etapa é um aplicativo Hadoop MapReduce implementado como um Java jar ou um programa de streaming escrito em Java, Ruby, Perl, Python, PHP, R ou C++. Por exemplo, para contar a frequência com a qual as palavras aparecem em um documento e exibi-las de modo classificado pela contagem, a primeira etapa seria um aplicativo MapReduce que conta as ocorrências de cada palavra e a segunda etapa seria um aplicativo MapReduce que classifica o resultado da primeira etapa com base nas contagens.

P: Quais são os diferentes estados do cluster?
INICIANDO - O cluster começa com a configuração de instâncias do EC2.
BOOTSTRAPPING − Há ações de bootstrap em execução no cluster.
RUNNING – Uma etapa do cluster que está em execução no momento.
WAITING – O cluster está ativo no momento, mas não há etapas para executar.
TERMINATING − O cluster está em desativação.
TERMINATED − O cluster foi encerrado sem erros.
TERMINATED_WITH_ERRORS − O cluster foi encerrado com erros.

P: Quais são os diferentes estados das etapas?
PENDING – A etapa está aguardando para ser executada.
RUNNING – A etapa está sendo executada no momento.
COMPLETED – A etapa foi concluída com êxito.
CANCELLED − A etapa foi cancelada antes da execução devido à falha de uma etapa anterior ou porque o cluster foi encerrado antes de executar.
FAILED – Houve falha da etapa durante a execução.

P: Como posso iniciar um cluster?
Você pode iniciar um cluster por meio do Console de Gerenciamento da AWS ao preencher um formulário simples de solicitação de cluster. No formulário de solicitação, especifique o nome do cluster, a localização no Amazon S3 dos dados de entrada, o aplicativo de processamento, a localização de saída dos dados desejados e o número e tipo de instâncias do Amazon EC2 que gostaria de usar. Também é possível especificar um local para armazenar arquivos de log do cluster e Chave SSH para efetuar login no cluster durante a execução. Além disso, pode-se iniciar um cluster usando a API RunJobFlow ou o comando “create” nas ferramentas da linha de comando. Para iniciar um cluster com EMR Studio, consulte a seção EMR Studio acima.

P: Como posso encerrar um cluster?
A qualquer momento você pode encerrar um cluster por meio do Console de Gerenciamento da AWS selecionando um cluster e clicando no botão "Terminate". Também é possível usar a API TerminateJobFlows. Se você encerrar um cluster em execução, os resultados que não tiverem persistido no Amazon S3 serão perdidos e todas as instâncias do Amazon EC2 serão desativadas.

P: O Amazon EMR é compatível com vários clusters simultâneos?
Você pode iniciar quantos clusters quiser. Ao começar, há um limite de 20 instâncias em todos os seus clusters. Se precisar de mais instâncias, preencha o formulário de solicitação de instâncias do Amazon EC2. No Amazon EC2, o limite já foi aumentado. O novo limite será aplicado aos clusters do Amazon EMR.

P: Como o Amazon EMR usa o Amazon EC2 e o Amazon S3?

Você pode fazer upload dos dados de entrada e de um aplicativo de processamento de dados no Amazon S3. O Amazon EMR inicia uma série de instâncias do Amazon EC2 que você especificou. O serviço inicia a execução do cluster ao obter os dados de entrada do Amazon S3 usando o protocolo S3 URI nas instâncias iniciadas do Amazon EC2. Assim que o cluster for concluído, o Amazon EMR transferirá os dados de saída para o Amazon S3, onde você poderá, então, recuperá-los ou usar como entrada em outro cluster.

P: Como é feita uma computação no Amazon EMR?

O Amazon EMR usa o mecanismo de processamento de dados do Hadoop para realizar computações implementadas no modelo de programação do MapReduce. O cliente implementa seu algoritmo em termos das funções map() e reduce(). O serviço começa com um número específico de clientes de instâncias do Amazon EC2, composto por um principal e vários outros nós. O Amazon EMR executa o software Hadoop nessas instâncias. O nó principal divide os dados de entrada em blocos e distribui o processamento dos blocos para os outros nós. Em seguida, cada nó executa a função de mapeamento nos dados que alocou, gerando dados intermediários. Então, os dados intermediários são classificados, particionados e enviados para processos que aplicam a função reducer a eles localmente nos nós. Finalmente, a saída das tarefas do reducer é coletada nos arquivos. Um único "cluster" poderá envolver uma sequência de etapas MapReduce.

P: Com quais tipos de instâncias do Amazon EC2 o Amazon EMR é compatível?

Consulte a página de definição de preço do EMR para obter detalhes sobre definição de preço e os tipos de instâncias disponíveis por região.

P: Quanto tempo levará para executar o cluster?

O período para executar o cluster dependerá de vários fatores, incluindo o tipo de cluster, a quantidade de dados inseridos e o número e tipo de instâncias do Amazon EC2 selecionados para o cluster.

P: Se o nó principal em um cluster for desativado, o Amazon EMR poderá recuperá-lo?

Sim. Agora, você pode executar um cluster do EMR (versão 5.23 ou superior) com três nós principais e oferecer alta disponibilidade a aplicativos como YARN Resource Manager, HDFS Name Node, Spark, Hive e Ganglia. Em caso de falha do nó principal em operação ou de processos críticos, como o Resource Manager ou o Name Node, o Amazon EMR executará automaticamente um failover para um nó principal em espera. Como o nó principal não é um possível ponto único de falha, você pode executar clusters do EMR de longa duração sem interrupções. Caso ocorra um failover, o Amazon EMR substituirá automaticamente o nó principal com falha por um novo nó principal com a mesma configuração e as mesmas ações de inicialização. 

P: Se outro nó for desativado em um cluster, o Amazon EMR poderá recuperá-lo?

Sim. O Amazon EMR é tolerante a falhas com relação a falhas de nó e continuará a execução do trabalho se um nó for desativado. Além disso, o Amazon EMR provisionará um novo nó quando um nó core falhar. No entanto, o Amazon EMR não substituirá nós se todos os nós do cluster falharem.

P: Posso executar o SSH nos nós do cluster?

Sim. É possível executar o SSH nos nós do cluster e executar comandos do Hadoop diretamente de lá. Se for necessário executar o SSH em um nó específico, primeiro é necessário executar o SSH no nó principal e, em seguida, fazê-lo no nó desejado.

P: Quais são as ações de Bootstrap do Amazon EMR?

O Bootstrap Actions é um recurso do Amazon EMR que fornece aos usuários uma forma de executar a configuração personalizada antes da execução do seu cluster. Ações de bootstrap podem ser usadas para instalar softwares ou configurar instâncias antes da execução do cluster. Você pode ler mais sobre essas ações no Guia do desenvolvedor do EMR.

P: Como posso usar ações de bootstrap?

É possível gravar um script do Bootstrap Action em qualquer idioma já instalado na instância do cluster, incluindo Bash, Perl, Python, Ruby, C++ ou Java. Há vários Bootstrap Actions pré-definidos disponíveis. Assim que o script for gravado, será necessário transferi-lo por upload para o Amazon S3 e fazer referência à sua localização ao iniciar um cluster. Consulte o Guia do desenvolvedor para obter detalhes sobre como usar o Bootstrap Actions.

P: Como configuro definições do Hadoop para o meu cluster?

A configuração padrão do Hadoop do EMR é apropriada para a maioria das cargas de trabalho. No entanto, com base nos requisitos e específicos de memória e processamento do cluster, talvez seja apropriado adaptar essas definições. Por exemplo, se as tarefas do cluster exigirem bastante memória, você poderá optar por usar menos tarefas por núcleo e reduzir o tamanho do heap do mecanismo de acompanhamento do trabalho. Para isso, um Bootstrap Action pré-definido está disponível para configurar o cluster na inicialização. Consulte o tópico sobre como Configurar ações de bootstrap exigem muita memória, no Guia do desenvolvedor, para obter detalhes de configuração e instruções de uso. Um bootstrap action pré-definido adicional está disponível, permitindo que você personalize as definições do cluster para qualquer valor selecionado. Consulte o tópico sobre como Configurar ações de bootstrap do Hadoop, no Guia do desenvolvedor, para obter instruções de uso.

P: Posso modificar o número de nós em um cluster em execução?

Sim. Os nós podem ser de dois tipos: (1) nós core, que hospedam dados persistentes usando Hadoop Distributed File System (HDFS) e executam tarefas do Hadoop e (2) nós de tarefa, que somente executam tarefas do Hadoop. Enquanto um cluster estiver sendo executado, você poderá aumentar o número de nós centrais e aumentar ou diminuir o número de nós de tarefa. Isso pode ser feito por meio da API, Java SDK ou do cliente da linha de comando. Consulte a seção Redimensionamento de clusters em execução, no Guia do desenvolvedor, para mais detalhes sobre como modificar o tamanho de um cluster em execução. Você também pode usar o Escalamento Gerenciado EMR.

P: Quando vou desejar usar nós centrais em vez de nós de tarefas?

Como nós centrais hospedam dados persistentes no HDFS e não podem ser removidos, os nós centrais devem ser reservados para a capacidade que é exigida até que o cluster seja concluído. Como os nós de tarefas podem ser adicionados ou removidos e não contêm HDFS, são ideais para a capacidade que é necessária apenas temporariamente. Você pode lançar frotas de exemplo de tarefas em Instâncias spot para aumentar a capacidade enquanto minimiza custos.

P: Por que eu desejaria modificar o número de nós escravos no cluster em execução?

Há vários cenários onde talvez você queira modificar o número de nós em um cluster em execução. Se o cluster estiver sendo executado com mais lentidão do que o esperado ou os requisitos de sincronismo forem alterados, você poderá aumentar o número de nós centrais para aumentar a performance do cluster. Se fases diferentes do cluster tiverem necessidades de capacidade diferentes, você poderá começar com um número pequeno de nós centrais e aumentar ou diminuir o número de nós de tarefas para atender aos requisitos de capacidade variáveis do cluster. Você também pode usar o Escalamento Gerenciado EMR.

P: Posso modificar automaticamente o número de nós entre as etapas do cluster?

Sim. Você poderá incluir uma etapa pré-definida no fluxo de trabalho que redimensiona automaticamente um cluster entre as etapas que são conhecidas por ter diferentes necessidades de capacidade. Como é assegurado que todas as etapas são executadas sequencialmente, isso permite definir o número de nós que serão executados em uma determinada etapa do cluster.

P: Como posso permitir que outros usuários de IAM acessem meu cluster?

Para criar um novo cluster que esteja visível para todos os usuários de IAM na ILC do EMR: Acrescente o sinalizador --visible-to-all-users ao criar o cluster. Por exemplo: elastic-mapreduce --create --visible-to-all-users. No Management Console, basta selecionar “Visible to all IAM Users”, no painel Advanced Options, do Assistente de criação de cluster.

Para tornar um cluster existente visível para todos os usuários do IAM, é necessário usar a ILC do EMR. Use --set-visible-to-all-users e especifique o identificador do cluster. Por exemplo: Elastic-mapreduce --set-visible-to-all-users true --jobflow j-xxxxxxx. Isso pode ser feito somente pelo autor do cluster.

Para saber mais, consulte a seção de Configuração de permissões de usuário do Guia do desenvolvedor do EMR.

P: Quais recursos do Amazon EMR é possível marcar com tags?

É possível adicionar tags a um cluster do Amazon EMR ativo. Um cluster de Amazon EMR consiste em instâncias do Amazon EC2, e um tag adicionado a um cluster de Amazon EMR será propagado para cada instância de Amazon EC2 ativa desse cluster. Não é possível adicionar, editar ou remover tags de clusters terminados ou instâncias de Amazon EC2 terminadas, que faziam parte de um cluster ativo.

P: A colocação de tag do Amazon EMR oferece suporte a permissões baseadas em recursos com usuários IAM?

Não, o Amazon EMR não oferece suporte a permissões baseadas em recursos por tag. No entanto, é importante notar que tags propagadas para instâncias de Amazon EC2 se comportam como tags normais do Amazon EC2. Portanto, uma política de IAM para Amazon EC2 atuará em tags propagadas do Amazon EMR se corresponderem às condições daquela política.

P: Quantas tags é possível adicionar a um recurso?

É possível adicionar até dez tags a um cluster do Amazon EMR.

P: As tags no meu cluster do Amazon EMR aparecem em cada instância do Amazon EC2 desse cluster? Se eu remover uma tag do meu cluster do Amazon EMR, essa tag será automaticamente removida de cada instância do EC2 associada?

Sim, o Amazon EMR propaga as tags adicionadas a um cluster às instâncias do EC2 subjacentes a esse cluster. Se adicionar uma tag a um cluster do Amazon EMR, ela aparecerá também em instâncias do Amazon EC2 relacionadas. Da mesma forma, se remover uma tag de um cluster do Amazon EMR, ela também será removida das instâncias do Amazon EC2 associadas. No entanto, se estiver usando políticas IAM para o Amazon EC2 e planeja usar a funcionalidade de colocação de tags do Amazon EMR, verifique se foi concedida a permissão para usar as APIs de colocação de tags do Amazon EC2: CreateTags e DeleteTags.

P: Como fazer os tags aparecerem na fatura para segmentar os custos?

Selecione as tags que você gostaria de usar no relatório de faturamento da AWS aqui. Então, para ver o custo dos recursos combinados, é possível organizar suas informações de cobrança com base em recursos que têm os mesmos valores de chave de tag.

P: Como ver quais instâncias do Amazon EC2 são parte de um cluster do Amazon EMR?

Uma instância do Amazon EC2 associada a um cluster do Amazon EMR terá duas tags de sistema:

• aws:elasticmapreduce:instance-group-role=CORE
  • Key = instance-group role ; Value = [CORE ou TASK];
• aws:elasticmapreduce:job-flow-id=j-12345678
  • Key = job-flow-id ; Value = [JobFlowID]

P: É possível editar tags diretamente nas instâncias do Amazon EC2?

Sim, é possível adicionar ou remover tags diretamente nas instâncias do Amazon EC2 que fazem parte de um cluster do Amazon EMR. No entanto, não é recomendado fazer isso porque o sistema de colocação de tags do Amazon EMR não sincronizará as alterações feitas diretamente em uma instância do Amazon EC2 associada. Recomenda-se que as etiquetas para clusters do Amazon EMR sejam adicionadas e removidas do console do Amazon EMR, da CLI ou da API para garantir que o cluster e suas instâncias associadas do Amazon EC2 tenham as etiquetas corretas.

P: O que é o Amazon EMR Serverless?

O Amazon EMR Serverless é uma nova opção de implantação no Amazon EMR que permite executar frameworks de big data, como o Apache Spark e o Apache Hive, sem configurar, gerenciar nem escalar clusters.

P: Quem pode usar o EMR Serverless?

Engenheiros de dados, analistas e cientistas podem usar o EMR Serverless para desenvolver aplicações usando frameworks de código aberto, como o Apache Spark e o Apache Hive. Eles podem usar esses frameworks para transformar dados, executar consultas SQL interativas e workloads de machine learning.

P: Como faço para começar a usar o EMR Serverless?

Você pode usar o EMR Studio, a AWS CLI ou APIs para enviar trabalhos, rastrear o status do trabalho e criar seus pipelines de dados para serem executados no EMR Serverless. Para começar a usar o EMR Studio, faça login no Console de Gerenciamento da AWS, navegue até Amazon EMR e, na categoria Analytics (Análise), selecione Amazon EMR Serverless. Siga as instruções do Console de Gerenciamento da AWS, navegue até o Amazon EMR na categoria Analytics (Análise) e selecione Amazon EMR Serverless. Siga as instruções do guia de conceitos básicos para criar sua aplicação do EMR Serverless e enviar trabalhos. Consulte a página Interacting with your application on the AWS CLI (Interagir com sua aplicação na AWS CLI) para iniciar suas aplicações e enviar trabalhos usando a CLI. Você também encontra exemplos do EMR Serverless e código de exemplo em nosso repositório do GitHub.

P: Que frameworks de código aberto são compatíveis com o EMR Serverless?

Atualmente, o EMR Serverless oferece suporte aos mecanismos Apache Spark e Apache Hive. Para obter suporte a outros frameworks, como Apache Presto ou Apache Flink, envie uma solicitação para [email protected].

P: Em quais regiões o EMR Sem Servidor está disponível?

O EMR Sem Servidor está disponível nas seguintes regiões da AWS: Ásia-Pacífico (Mumbai), Ásia-Pacífico (Seul), Ásia-Pacífico (Singapura), Ásia-Pacífico (Sydney), Ásia-Pacífico (Tóquio), Canadá (Central), Europa (Frankfurt), Europa (Irlanda), Europa (Londres), Europa (Paris), Europa (Estocolmo), América do Sul (São Paulo), Leste dos EUA (Norte da Virgínia), Leste dos EUA (Ohio), Oeste dos EUA (Norte da Califórnia) e Oeste dos EUA (Oregon).

P: Qual é a diferença entre o Amazon EMR Sem Servidor, o Amazon EMR no EC2, o Amazon EMR no AWS Outposts e o Amazon EMR no EKS?

O Amazon EMR oferece a opção de executar aplicações em clusters baseados no EC2, em clusters do EKS, no Outposts ou no Serverless. Os clusters do EMR no EC2 são perfeitos para clientes que precisam de controle e flexibilidade máximos ao executar aplicações. Com o EMR em clusters do EC2, os clientes podem escolher o tipo de instância do EC2 para atender às necessidades de performance específicas da aplicação, personalizar a AMI do Linux, personalizar a configuração da instância do EC2, personalizar e ampliar frameworks de código aberto e instalar outros softwares personalizados em instâncias de cluster. O Amazon EMR no EKS é perfeito para clientes que desejam padronizar no EKS para gerenciar clusters entre aplicações ou usar versões diferentes de um framework de código aberto no mesmo cluster. O Amazon EMR no AWS Outposts serve para clientes que desejam executar o EMR mais perto de seu datacenter, em um Outpost. O EMR Serverless é perfeito para clientes que desejam evitar o gerenciamento e a operação de clusters e preferem executar aplicações usando frameworks de código aberto.

P: Quais são algumas das diferenças nos recursos do EMR Serverless e do Amazon EMR no EC2?

P: Que versões do EMR são compatíveis com o EMR Serverless?

O EMR Serverless é compatível com rótulos de versão do EMR 6.6 e versões posteriores. Com o EMR Serverless, você obtém o mesmo tempo de execução do EMR com performance otimizada disponível em outras opções de implantação do EMR, que é 100% compatível com APIs de frameworks padrão de código aberto.

P: As cobranças pela capacidade pré-inicializada estão incluídas no BilledResourceUtilization?

O BilledResourceUtilization leva em consideração apenas a duração durante a qual a capacidade pré-inicializada foi utilizada para o trabalho e não leva em consideração nenhum tempo ocioso dessa capacidade.

P: Qual é a diferença entre BilledResourceUtilization e TotalResourceUtilization?

Se a duração do tempo de execução de um trabalhador for menor que 60 segundos, BilledResourceUtilization a contará como 60 segundos, enquanto TotalResourceUtilization a arredondará para o segundo mais próximo. Além disso, BilledResourceUtilization exclui 20 GB de armazenamento gratuito do cálculo.

P: O que é uma aplicação e como criá-la?

Com o Amazon EMR Serverless, você pode criar uma ou mais aplicações do EMR Serverless que usam frameworks de análise de código aberto. Para criar uma aplicação, é necessário especificar estes atributos: 1) a versão do Amazon EMR para a versão do framework de código aberto que deseja usar e 2) os mecanismos de análise específicos que você deseja que sua aplicação use, como o Apache Spark 3.1 ou o Apache Hive 3.0. Após criar uma aplicação, você pode começar a executar seus trabalhos de processamento de dados ou solicitações interativas para sua aplicação.

P: O que é um operador?

Uma aplicação do EMR Serverless usa operadores internamente para executar suas workloads. Quando um trabalho é enviado, o EMR Serverless calcula os recursos necessários para o trabalho e agenda os operadores. O EMR Serverless divide suas workloads em tarefas, provisiona e configura operadores com o framework de código aberto e os desativa quando o trabalho é concluído. O EMR Serverless aumenta e diminui verticalmente os operadores automaticamente, de acordo com a workload e o paralelismo necessários em cada etapa do trabalho, eliminando assim a necessidade de estimar o número de operadores necessários para executar suas workloads. O tamanho padrão desses operadores é baseado no tipo de aplicação e na versão do Amazon EMR. Você pode substituir esses tamanhos ao programar uma execução de trabalho.

P: Posso especificar o número mínimo e máximo de operadores que meus trabalhos podem usar?

Com o EMR Serverless, você pode especificar o número mínimo e máximo de operadores simultâneos e a configuração de vCPU e memória para operadores. Também é possível definir os limites máximos de capacidade dos recursos da aplicação para controlar os custos.

P: Quando devo criar várias aplicações?

Considere criar várias aplicações ao realizar qualquer uma destas ações:

1. Usar diferentes frameworks de código aberto
2. Usar diferentes versões de frameworks de código aberto para diferentes casos de uso
3. Realizar testes A/B ao atualizar de uma versão para outra
4. Manter ambientes lógicos separados para cenários de teste e produção
5. Fornecer ambientes lógicos separados para diferentes equipes com controles de custos independentes e rastreamento de uso
6. Separar aplicações de linhas de negócios diferentes

P: Posso alterar as propriedades padrão de uma aplicação do EMR Serverless depois de criá-la?

Sim, é possível modificar as propriedades da aplicação, como capacidade inicial, limites máximos de capacidade e configuração de rede usando o EMR Studio ou a chamada API/CLI update-application.

P: Quando devo criar uma aplicação com um grupo de operadores pré-inicializados?

Uma aplicação do EMR Serverless sem operadores pré-inicializados leva até 120 segundos para determinar os recursos necessários e provisioná-los. O EMR Serverless fornece um recurso opcional que mantém os operadores inicializados e prontos para responder em segundos, criando efetivamente um grupo de operadores de plantão para uma aplicação. Esse recurso é chamado de capacidade pré-inicializada e pode ser configurado para cada aplicação definindo o parâmetro de capacidade inicial da aplicação.

A capacidade pré-inicializada permite que os trabalhos sejam iniciados imediatamente, sendo ideal para a implementação de trabalhos urgentes. Você pode especificar o número de operadores que deseja pré-inicializar ao iniciar uma aplicação do EMR Serverless. Em seguida, quando os usuários enviam trabalhos, os operadores pré-inicializados podem ser usados para iniciar os trabalhos imediatamente. Se a tarefa necessitar de mais operadores do que você escolheu para pré-inicializar, o EMR Serverless adicionará automaticamente mais operadores (até o limite máximo simultâneo especificado). Após a conclusão do trabalho, o EMR Serverless volta automaticamente a manter os operadores pré-inicializados que você especificou. Os operadores são desligados automaticamente quando ficam ociosos por 15 minutos. Você pode alterar o tempo limite de inatividade padrão da aplicação usando a API updateApplication ou o EMR Studio.

P: Como enviar e gerenciar trabalhos no EMR Serverless?

Você pode enviar e gerenciar trabalhos do EMR Serverless usando o EMR Studio, o SDK, a CLI ou nossos conectores do Apache Airflow.

P: Como posso incluir dependências em trabalhos que desejo executar no EMR Serverless?

Para o PySpark, você pode empacotar as dependências do Python usando virtualenv e transferir o arquivo usando a opção --archives, que permite que seus operadores usem as dependências durante a execução do trabalho. Para Scala ou Java, você pode empacotar suas dependências como jars, carregá-las no Amazon S3 e transferi-las usando as opções --jars ou --packages com sua execução de trabalho do EMR Serverless.

P: As aplicações do EMR Serverless Spark e Hive oferecem suporte a funções definidas pelo usuário (UDFs)?

O EMR Serverless oferece suporte a UDFs baseadas em Java. Você pode empacotá-las como jars, carregá-las no S3 e usá-las em seus scripts do Spark ou do HiveQL.

P: A que configurações de operadores o EMR Serverless oferece suporte?

Para obter detalhes, consulte Supported Worker Configuration (Configuração de operadores com suporte).

P: Posso cancelar um trabalho do EMR Serverless caso ele esteja sendo executado por mais tempo do que o esperado?

Sim, é possível cancelar um trabalho do EMR Serverless em execução no EMR Studio ou chamando a API/CLI cancelJobRun.

P: Posso adicionar armazenamento extra aos operadores?

É possível adicionar armazenamento extra aos operadores no EMR Serverless selecionando a opção de armazenamento apropriada durante o envio do trabalho. O EMR Serverless oferece duas opções de armazenamento temporário:

• Armazenamento padrão: essa opção oferece 20 GB de armazenamento temporário por operador por padrão. Você pode personalizar essa capacidade durante o envio do trabalho e aumentar a capacidade de armazenamento de 20 GB para 200 GB por operador.
• Em disco otimizado para shuffle: essa opção fornece até 2 TB de armazenamento temporário por operador, otimizado para workloads com uso intenso de shuffle.

P: Onde posso encontrar códigos de exemplo?

Você encontra códigos de exemplo do EMR Serverless em nosso repositório do GitHub.

P: Quais são as opções de operadores disponíveis no EMR Serverless?

O EMR Serverless oferece duas opções para operadores: operadores sob demanda e operadores pré-inicializados.

Os operadores sob demanda são iniciados somente quando necessários para um trabalho e são liberados automaticamente quando o trabalho é concluído. Isso ajuda você a economizar custos, pagando somente pelos recursos que você usa e a evitar custos adicionais de capacidade ociosa. Operadores sob demanda ampliam ou diminuem sua aplicação com base na sua workload, para que você não precise se preocupar com o provisionamento excessivo ou insuficiente de recursos.

Os trabalhadores pré-inicializados são um recurso opcional em que você pode manter os trabalhadores prontos para responder em segundos. Isso cria efetivamente um grupo aquecido de trabalhadores para uma aplicação. Isso permite que os trabalhos sejam iniciados instantaneamente, tornando-os ideais para aplicações iterativas e trabalhos urgentes.

P: Posso configurar aplicações do EMR Serverless em várias zonas de disponibilidade (AZ)?

Sim, é possível configurar aplicações do EMR Serverless em várias AZs. O processo para configurar várias AZs depende do tipo de operador que você usa.

Ao usar somente operadores sob demanda, o EMR Serverless distribui trabalhos em várias AZs por padrão, mas cada tarefa é executada somente em uma AZ. Você pode escolher quais AZs usar associando sub-redes a essas AZs. Se uma AZ falhar, o EMR Serverless executará automaticamente seu trabalho em outra AZ íntegra.

Ao usar trabalhadores pré-inicializados, o EMR Serverless seleciona uma AZ íntegra nas sub-redes que você especifica. Os trabalhos são enviados nessa AZ até que você interrompa a aplicação. Se uma AZ ficar danificada, você poderá reiniciar a aplicação para mudar para outra AZ íntegra.

P: Posso me conectar a armazenamentos de dados em uma região diferente?

O EMR Serverless apenas pode acessar determinados recursos da AWS na mesma região quando configurado sem conectividade com a VPC. Consulte as considerações. Para acessar os recursos da AWS em uma região diferente ou em recursos fora da AWS, você precisará configurar o acesso à VPC e um gateway NAT para rotear os recursos da AWS para endpoints públicos.

P: Como monitorar as aplicações do Amazon EMR Serverless e as execuções de tarefas?

As métricas de nível de trabalho e de aplicação do Amazon EMR Serverless são publicadas a cada 30 segundos no Amazon CloudWatch.

P: Como inicio a interface de usuário do Spark e a interface de usuário do Tez com o EMR Serverless?

No EMR Studio, você pode selecionar um trabalho do EMR Serverless em execução ou concluído e clicar no botão Spark UI ou Tez UI para iniciá-los.

P: Posso acessar recursos em minha Amazon Virtual Private Cloud (VPC)?

Sim, você pode configurar aplicações do Amazon EMR Serverless para acessar recursos em sua própria VPC. Para saber mais, consulte a seção Configuring VPC access (Configurar acesso da VPC) da documentação. 

P: Que tipo de isolamento posso obter com uma aplicação do EMR Serverless?

Cada aplicação do EMR Serverless é isolada de outras aplicações e executada em uma Amazon VPC segura.

P: O que está mudando nas cotas de serviço do Amazon EMR Sem Servidor?
O Amazon EMR Sem Servidor está introduzindo uma nova cota de serviço chamada Max vCPUs simultâneas por conta. Essa cota baseada em vCPU permite que você defina o número máximo de vCPUs agregadas que suas aplicações podem escalar em uma região. As cotas existentes com base no trabalhador no nível da aplicação (máximo de operadores ativos) chegarão ao fim do suporte em 1º de fevereiro de 2023.

P: Onde posso visualizar e gerenciar a cota de vCPUs da minha conta?
Você pode visualizar, gerenciar e solicitar aumento de cota no console de gerenciamento do AWS Service Quotas. Para obter mais informações, consulte Requesting a Quota Increase (Solicitar um aumento de cota) no Guia do usuário do Service Quotas.

P: Qual é a diferença entre a cota de vCPUs no nível da conta e a propriedade maximumCapacity no nível da aplicação?
O EMR Sem Servidor oferece dois controles de custo: 1) A cota máxima de vCPUs simultâneas por conta é aplicada a todas as aplicações do EMR Sem Servidor em uma região da sua conta. 2) O parâmetro maximumCapacity limita a vCPU de uma aplicação específica do EMR Sem Servidor. Você deve usar a cota baseada em vCPU para limitar o máximo de vCPUs simultâneas usadas por todas as aplicações em uma região e a propriedade maximumCapacity para limitar os recursos usados por uma aplicação específica. Por ex. se você tiver cinco aplicações e cada uma puder escalar até 1.000 vCPUs, defina a propriedade maximumCapacity como 1.000 vCPUs para cada aplicação e configure a cota baseada em vCPU no nível da conta como 5 * 1.000 = 5.000 vCPUs.

P. Como saberei se alcancei minha cota de conta baseada em vCPU?
Se você exceder sua cota de vCPUs no nível da conta, o EMR Sem Servidor interromperá o provisionamento de nova capacidade. Se você tentar criar uma nova aplicação depois de exceder a cota, a criação da aplicação falhará com uma mensagem de erro “Application failed to create as you have exceeded the maximum concurrent vCPUs per account service quota. You can view and manage your service quota using AWS Service Quotas console” (Falha ao criar a aplicação porque você excedeu o máximo de vCPUs simultâneas por cota de serviço de conta. Você pode visualizar e gerenciar sua cota de serviços usando o console do AWS Service Quotas). Se você enviar um novo trabalho depois de exceder a cota, o trabalho falhará com uma mensagem de erro: “Job failed as you have exceeded the maximum concurrent vCPUs per account service quota. You can view and manage your service quota using AWS Service Quotas console” (O trabalho falhou porque você excedeu o máximo de vCPUs simultâneas por cota de serviços da conta. Você pode visualizar e gerenciar sua cota de serviços usando o console do AWS Service Quotas). Consulte a documentação para obter mais detalhes.

P: Como o Amazon EMR Serverless ajuda a economizar custos em implantações de big data?

O Amazon EMR Serverless pode ajudar você a economizar custos de três modos. Primeiro, não há sobrecarga operacional de gerenciamento, proteção e escala de clusters. Segundo, o EMR Serverless aumenta automaticamente a escala na vertical dos operadores em cada etapa do processamento de seu trabalho e a diminui quando necessário. Você é cobrado pelos recursos agregados de vCPU, memória e armazenamento usados a partir do momento em que um operador entra em execução até o momento em que termina. O tempo é arredondado para o segundo mais próximo, e o período mínimo é de um minuto. Por exemplo, seu trabalho pode exigir dez operadores nos primeiros dez minutos de processamento do trabalho e 50 operadores nos cinco minutos seguintes. Com a escala automática refinada, você incorre em custos de apenas dez operadores por dez minutos e 50 operadores por cinco minutos. Como resultado, você não precisa pagar por recursos subutilizados. Terceiro, o EMR Serverless inclui o tempo de execução otimizado para performance do Amazon EMR para o Apache Spark e o Apache Hive e o Presto. O tempo de execução do Amazon EMR é compatível com API e duas vezes mais rápido que os mecanismos de análise de código aberto padrão. Assim, seus trabalhos são executados mais rapidamente e incorrem em menos custos de computação.

P: O custo do EMR Serverless é comparável ao Amazon EMR em instâncias spot do EC2?

Depende de seu EMR atual ao utilizar o cluster do EC2. Se você executar clusters do EMR usando instâncias sob demanda do EC2, o EMR Serverless oferecerá um custo total de propriedade (TCO) menor, se a utilização do cluster atual for inferior a 70%. Se estiver usando os EC2 Savings Plans, o EMR Serverless oferecerá um TCO menor, se a utilização do cluster atual for inferior a 50%. E se você usar instâncias spot do EC2, o Amazon EMR no EC2 e o Amazon EMR no EKS ainda terão um custo-benefício melhor.

P: Os operadores pré-inicializados são cobrados mesmo após a conclusão dos trabalhos?

Sim, caso não interrompa os operadores após a conclusão de um trabalho, você incorrerá em cobranças relacionadas aos operadores pré-inicializados.

P: Com quem devo entrar em contato caso tenha dúvidas, comentários e solicitações de recursos?

Envie suas dúvidas e seu valioso feedback sobre o EMR Serverless para [email protected].

P: O que é Amazon EMR no Amazon EKS?
O Amazon EMR no Amazon EKS é um modelo de implantação do Amazon EMR que permite aos clientes processar facilmente e com boa relação custo-benefício grandes quantidades de dados. Ele utiliza estruturas analíticas hospedadas rodando no flexível serviço gerenciado Amazon EKS em contêineres, com a infraestrutura em escala web da Amazon Elastic Compute Cloud (Amazon EC2), AWS Fargate, e Amazon Simple Storage Service (Amazon S3).

P: Por que devo usar o Amazon EMR no Amazon EKS?
O Amazon EMR no Amazon EKS dissocia o trabalho de análise dos serviços e infraestrutura que estão processando o trabalho, utilizando uma abordagem baseada em contêineres. Você pode se concentrar mais no desenvolvimento de sua aplicação e menos na operação da infraestrutura, pois a EMR no EKS configura dinamicamente a infraestrutura com base nas dependências computacionais, de memória e de aplicação do trabalho. As equipes de infraestrutura podem gerenciar centralmente uma plataforma comum de computação para consolidar cargas de trabalho EMR com outras aplicações baseadas em contêineres. Múltiplas equipes, organizações ou unidades de negócios podem executar simultânea e independentemente seus processos analíticos na infraestrutura compartilhada, mantendo o isolamento possibilitado pelo Amazon EKS e AWS Identity and Access Management (IAM).

P: Quais são os benefícios para os usuários que já utilizam o Apache Spark no Amazon EKS?
Se você já executa o Apache Spark no Amazon EKS, pode obter todos os benefícios do Amazon EMR como provisionamento e escalonamento automáticos e a capacidade de usar as últimas versões totalmente gerenciadas de grandes estruturas analíticas de dados de código aberto. Você obtém um tempo de execução EMR otimizado para o Apache Spark com desempenho 3X mais rápido que o Apache Spark no EKS, uma experiência de ciência de dados sem servidor com EMR Studio e Apache Spark UI, controle de acesso a dados de granulação fina, e suporte para criptografia de dados.

P: Como esse serviço se relaciona/funciona com outros serviços da AWS?
O Amazon EKS fornece aos clientes uma experiência gerenciada para executar Kubernetes na AWS, permitindo adicionar capacidade de computação usando EKS Managed Node Groups ou usando AWS Fargate. A execução de trabalhos EMR no EKS pode acessar seus dados no Amazon S3 enquanto o monitoramento e o registro podem ser integrados com o Amazon CloudWatch. A AWS Identity and Access Management (IAM) permite o controle de acesso baseado em funções tanto para empregos quanto para serviços dependentes da AWS.

P: Como o Amazon EMR no Amazon EKS funciona?
Registre seu cluster do EKS com o Amazon EMR. Em seguida, envie seus trabalhos para a EMR usando o CLI, SDK ou EMR Studio. A EMR solicita ao programador Kubernetes no EKS que agende Pods. Para cada trabalho que você executa, a EMR no EKS cria um contêiner. O contêiner contém a imagem base do Amazon Linux 2 com atualizações de segurança, mais Apache Spark e dependências associadas para executar Spark, mais as dependências específicas de sua aplicação. Cada trabalho é executado em um pod. O Pod baixa este contêiner e começa a executá-lo. Se a imagem do contêiner foi previamente implantada no nó, então uma imagem em cache é utilizada e o download é contornado. Os contêineres sidecar, tais como os encaminhadores de logs ou métricas, podem ser colocados no pod. O Pod termina após o término do trabalho. Após o trabalho terminar, você ainda pode depurá-lo usando o Spark UI.

P: Que serviços de computação AWS posso usar com o Amazon EMR sobre EKS?
Você pode usar o Amazon EMR for EKS com ambas as instâncias do Amazon Elastic Compute Cloud (EC2) para suportar opções mais amplas de customização, ou o serviço AWS Fargate sem servidor para processar suas análises sem ter que fornecer ou gerenciar instâncias EC2. A disponibilidade de aplicações pode melhorar automaticamente espalhando seus trabalhos analíticos por várias Zonas de Disponibilidade AWS (AZs).

P: Como faço para começar a usar o EMR sobre EKS?
Para começar, registre seu cluster do Amazon EKS com Amazon EMR. Após o registro, faça referência a este registro na definição de seu trabalho (que inclui dependências de aplicação e parâmetros de estrutura), submetendo suas cargas de trabalho à EMR para execução. Com EMR sobre EKS, você pode usar diferentes estruturas, versões e configurações de código aberto para aplicações analíticas rodando no mesmo cluster do EKS. Para obter informações adicionais, consulte nossa documentação.

P: Posso usar a mesma liberação de EMR para clusters e aplicações de EMR em execução no EKS?

Sim, você pode usar a mesma liberação EMR para aplicativos que rodam em clusters EMR e aplicativos que rodam em EKS.

P: Como posso solucionar problemas de uma aplicação analítica?
Você pode usar o Amazon EMR Spark UI para diagnosticar e solucionar problemas de aplicações de Spark. Para todas as aplicações analíticas, a EMR fornece acesso aos detalhes da aplicação, registros associados e métricas por até 30 dias após a sua conclusão. Os trabalhos podem ser configurados individualmente para enviar logs para uma localização Amazon S3 ou Amazon CloudWatch.

P: Posso ver aplicativos EMR no EKS?
Sim, os aplicativos EMR aparecem no console EKS como trabalhos e implantações Kubernetes.

P: Posso isolar vários trabalhos ou aplicativos um do outro no mesmo cluster EKS?
Sim, Kubernetes fornece nativamente o isolamento do trabalho. Além disso, cada trabalho pode ser configurado para ser executado com seu próprio papel de execução para limitar quais recursos da AWS o trabalho pode acessar.

P: Como a EMR no EKS ajuda a reduzir custos?
A EMR no EKS reduz os custos, eliminando a necessidade de executar clusters dedicados. Você pode usar um cluster EKS comum e compartilhado para executar aplicações analíticas que requerem diferentes versões de grandes estruturas analíticas de dados de código aberto. Você também pode usar o mesmo cluster EKS para executar suas outras aplicações de contêineres não-EMR.

P: Como você cobra pelo EMR sobre EKS?
O preço do Amazon EMR sobre EKS é calculado com base na vCPU e nos recursos de memória solicitados para os pod(s) que estão executando seu trabalho a granularidade por minuto. Para obter informações sobre a definição de preço, consulte a página de definição de preço do Amazon EMR.

P: Quais são algumas das diferenças entre EMR no EKS e EMR no EC2?

P: O que é o AWS Outposts?

O AWS Outposts leva serviços, infraestrutura e modelos operacionais nativos da AWS a praticamente qualquer datacenter, espaço de co-location ou instalações no local. Usando o EMR no Outposts, você pode implantar, gerenciar e escalar clusters EMR no local da mesma forma que faria na nuvem.

P: Quando eu deveria usara o EMR no Outposts?

Se você tiver as implantações do Apache Hadoop no local e estiver com dificuldade de atingir as demandas de capacidade durante a utilização do pico, você pode usar o EMR no Outpost para aumentar sua capacidade de processamento sem ter que mover dados para as nuvens. O EMR no Outposts permite que você lance um novo cluster de EMR no local em minutos e conecta a conjuntos de dados existentes no armazenamento HDFS no local para atingir essa demanda e manter os SLAs.

Se você precisa processar dados que precisam permanecer no local por governança, conformidade ou outros motivos, você pode usar o EMR no Outposts para implantar e executar aplicativos como o Apache Hadoop e o Apache Spark no local, próximos dos seus dados. Isso reduz a necessidade de mover grandes quantidades de dados no local para a nuvem, reduzindo o tempo total necessário para processar esses dados.

Se você estiver migrando dados e cargas de trabalho do Apache Hadoop para a nuvem e quiser começar a usar o EMR antes da conclusão da migração, use o AWS Outposts para executar clusters do EMR que se conectam ao seu armazenamento HDFS existente no local. Você pode migrar seus dados gradualmente para o Amazon S3 como parte de uma evolução para uma arquitetura em nuvem.

P: Que versões do EMR são compatíveis com EMR no Outposts?

A versão mínima suportada pela Amazon EMR é a 5.28.0.

P: Quais aplicativos EMR etão disponíveis quando se usa o Outposts?

Todos os aplicativos na versão 5.28.0 do EMR e acima são suportados. Consulte nossas notas de release para ter uma lista completa dos aplicativos de EMR.

P: Que recursos do EMR são não compatíveis com EMR no Outposts?

• Instâncias de EC2 SPOT não estão disponíveis no AWS Outposts. Quando criar um cluster, você precisa escolher instâncias EC2 sob demanda.
• Um subconjunto de tipos de instância EC2 está disponível no AWS Outposts. Para uma lista dos tipos de instância suportadas com o EMR e Outposts, consulte nossa documentação.
• Quando adicionar volumes do Amazon EBS para as instâncias, apenas o tipo de armazenamento de SSD de uso geral (GP2) será suportado no AWS Outposts.

P: Eu posso usar clusters do EMR em um Outpost para ler dados dos meus clusters Apache Hadoop no local?

A carga de trabalho rodando no EMR em um Outpost pode ler e gravar dados em armazenamento HDFS existente, permitindo que você integre facilmente implantações do Apache Hadoop no local. Isso dá a capacidade de aumentar suas necessidades de processamento de dados usando o EMR sem a necessidade de migrar dados.

P: Posso escolher onde armazenar meus dados?

Quando um cluster EMR é lançado em um Outpost, todos os recursos de computação e armazenamento de dados são implantados em seu Outpost. Dados escritos localmente em cluster EMR são armazenados em volumes EBS locais em seu Outpost. Ferramentas como o Apache Hive, Apache Spark, Presto, e outros aplicativos EMR podem ser configurados para escrever dados localmente em um Outpost, para o sistema de arquivos externo como uma instalação HDFS ou para o Amazon S3. Usando o EMR no Outposts, você tem controle total sobre o armazenamento de seus dados no Amazon S3 ou localmente em seu Outpost.

P: Algum recurso do EMR precisa atualizar dados para o S3?

Quando estiver lançando o cluster EMR em um Outpost, você tem a opção de ativar registro. Quando o registro é ativado, registros de cluster são carregados no bucket do S3 que você especificar. Esses registros são usados para simplificar cluster de debug simples depois deles serem encerrados. Quando desativado, nenhum registro será carregado no S3.

P: O que acontece se eu extrapolar a recurso do meu Outpost?

Quando um cluster é lançado em um Outpost, o EMR tentará lançar o número e tipo de instâncias sob demanda do EC2 que vocês solicitaram. Se não houver recurso no Outpost, o EMR receberá um nota de recurso insuficiente. O EMR repetirá por um período de tempo e se nenhuma recurso for disponibilizado, o cluster falhará no lançamento. O mesmo processo se aplica quando redimensionando um cluster. Se houver capacidade insuficiente no Outpost para os tipos de instâncias requisitados, o EMR será incapaz de escalar o cluster. Você pode facilmente configurar alertas no Amazon CloudWatch para monitorar seu recurso de utilização no Outpost e receber alertas quando o recurso da instância está abaixo do limite desejado.

P: O que acontece se a conectividade de uma rede for interrompida entre meu Outpost e a AWS?

Se a conectividade de rede entre seu Outpost e a região AWS for perdida, seus clusters no Outposts continuará a rodar, mas haverá ações que você não será capaz de fazer até que a conectividade seja restaurada. Até que a conectividade seja restaurada, você não poderá criar novos clusters ou fazer novas ações com os clusters existentes. No caso de uma instância falhar, ela não será trocada automaticamente. Alem disso, ações como adicionar passos em um cluster ativo, checar o status de execução do passo e enviar métricas e eventos para o CloudWatch será atrasada até que a conectividade seja restaurada.

Nós recomendamos que você forneça uma conectividade de rede confiável e altamente disponível entre seu Outpost e a região da AWS. Se a conectividade de rede entre seu Outpost e a região AWS for perdida por mais do que algumas poucas horas, clusters que possuem a proteção contra encerramento ativado continuarão a rodar e os que possuem a proteção desativada poderão ser encerrados. Se a conectividade da rede será impactada devido a uma manutenção de rotina, recomendamos que a proteção contra encerramento seja ativada proativamente.

P: O que posso fazer agora que não era possível fazer antes?

A maioria das instâncias do EC2 têm capacidade de armazenamento fixa anexada à instância, conhecida como um "armazenamento de instâncias". Agora, é possível adicionar volumes do EBS às instâncias de um cluster do Amazon EMR, o que permite personalizar o armazenamento de uma instância. O recurso também permite executar clusters do Amazon EMR em famílias de instâncias somente EBS, como M4 e C4.

P: Quais são os benefícios da adição de volumes do EBS a uma instância executada no Amazon EMR?

A adição de volumes do EBS a uma instância é benéfica nos seguintes cenários:

1. Seus requisitos de processamento exigem uma grande quantidade de armazenamento HDFS (ou local), maior que a disponível atualmente na instância. Com o suporte aos volumes do EBS, você será capaz de personalizar a capacidade de armazenamento em uma instância de acordo com a capacidade computacional fornecida pela instância. A otimização do armazenamento em uma instância permite reduzir custos.
2. Você está executando em uma família de instâncias de uma geração anterior (como as famílias M1 e M2) e quer mudar para a família de instâncias da geração mais recente, mas enfrenta limitações no armazenamento disponível por nó nesses tipos de instância da próxima geração. Agora, é possível usar qualquer tipo de instância da nova geração e adicionar volumes do EBS para otimizar o armazenamento. Comparações internas indicam que você pode reduzir o custo e aumentar a performance mudando de uma família de instâncias de geração anterior (M1 ou M2) para uma família da nova geração (M4, C4 e R3). A equipe do Amazon EMR recomenda que você execute o aplicativo para chegar à conclusão correta.
3. Você quer usar ou migrar para as famílias somente EBS M4 e C4 da próxima geração.

P: Posso persistir dados em um volume do EBS após o encerramento de um cluster?

No momento, o Amazon EMR exclui os volumes no encerramento do cluster. Se você quiser persistir dados fora do ciclo de vida de um cluster, considere o uso do Amazon S3 como datastore.

P: Quais tipos de volumes do EBS posso anexar a uma instância?

O Amazon EMR permite usar tipos de volume do EBS diferentes: SSD de uso geral (GP2), magnético e de IOPS provisionadas (SSD).

P: O que acontece com os volumes do EBS quando o cluster é encerrado?

O Amazon EMR exclui os volumes no encerramento do cluster do EMR.

P: Posso usar um EBS com instâncias que já têm um armazenamento de instâncias?

Sim, você pode adicionar volumes do EBS a instâncias que já têm um armazenamento de instâncias.

P: Posso anexar um volume do EBS a um cluster em execução?

Não. No momento, somente é possível adicionar volumes do EBS ao iniciar um cluster.

P: Posso obter snapshots de volumes de um cluster?

A API do EBS permite obter snapshots de um cluster. No entanto, no momento o Amazon EMR não permite restaurar um snapshot.

P: Posso usar volumes do EBS criptografados?

Você pode criptografar o dispositivo raiz EBS e os volumes de armazenamento usando AWS KMS como seu principal provedor. Para mais informações, consulte Criptografia local de disco.

P: O que acontecerá se um volume anexado for removido de um cluster em execução?

A remoção de um volume anexado de um cluster em execução será tratada como uma falha de nó. O Amazon EMR substituirá o nó e o volume do EBS por outro nó e outro volume.

P: O que é o Apache Spark?

O Apache Spark^TM é um sistema de processamento distribuído de código aberto usado normalmente para workloads de big data. O sistema usa armazenamento em cache na memória e execução otimizada de consultas para oferecer consultas analíticas rápidas de dados de qualquer tamanho. O Amazon EMR é o melhor local para implantar o Apache Spark na nuvem porque combina a integração e os testes rigorosos das distribuições comerciais do Spark com a escala, simplicidade e economia da nuvem. O serviço permite executar clusters do Spark em minutos, sem necessidade de executar provisionamento de nós, configuração de clusters, configuração do Spark ou ajustes de clusters. O EMR apresenta o tempo de execução do Amazon EMR para o Apache Spark, um ambiente com tempo de execução de desempenho otimizado para o Apache Spark, disponível e ativado por padrão nos clusters do Amazon EMR. O tempo de execução do Amazon EMR para o Apache Spark pode ser até 3x mais rápido do que os clusters sem o tempo de execução EMR, e tem compatibilidade API de 100% com o Apache Spark padrão. Saiba mais sobre o Spark e sobre o Spark no Amazon EMR.

P: O que é o Presto?

O Presto é um mecanismo de consultas SQL distribuídas de código aberto, projetado desde o início para oferecer consultas analíticas rápidas de dados de qualquer tamanho. Com o Amazon EMR, você pode executar clusters do Presto em minutos, sem necessidade de executar provisionamento de nós, configuração de clusters, configuração do Presto ou ajustes de clusters. O EMR permite provisionar uma, centenas ou milhares de instâncias de computação em alguns minutos. O Presto tem dois projetos na comunidade - PrestoDB e PrestoSQL. O Amazon EMR suporta os dois projetos. Saiba mais sobre o Presto e sobre o Presto no Amazon EMR.

P: O que é o Apache Hive?

O Hive é um data warehouse e um pacote analítico de código aberto que é executado com base no Hadoop. O Hive é operado por uma linguagem baseada em SQL chamada Hive QL, que permite que os usuários estruturem, resumam e consultem fontes de dados armazenadas no Amazon S3. O Hive QL vai além do SQL padrão, adicionando suporte de primeira classe às funções mapear/reduzir e a tipos de dados complexos e extensíveis definidos pelo usuário, como Json e Thrift. Essa capacidade permite o processamento de fontes de dados complexas e até não estruturadas, como documentos de texto e arquivos de log. O Hive permite extensões do usuário por meio de funções definidas por este gravadas em Java e implantadas via armazenamento no Amazon S3. Você pode buscar saber mais sobre o Apache Hive aqui.

P: O que pode ser feito com o Hive sendo executado no Amazon EMR?

Usando o Hive com o Amazon EMR, é possível implementar aplicativos sofisticados de processamento de dados com uma linguagem familiar semelhante ao SQL e ferramentas fáceis de usar disponíveis com o Amazon EMR. Com o Amazon EMR, você pode transformar seus aplicativos Hive em um data warehouse confiável para executar tarefas como análises de dados, monitoramento e de inteligência corporativa.

P: Como o Hive diferencia-se dos sistemas RDBMS tradicionais?

Os sistemas RDBMS tradicionais fornecem semântica de transação e propriedades ACID. Eles também permitem que tabelas sejam indexadas e armazenadas em cache, de forma que pequenas quantidades de dados possam ser recuperadas com bastante rapidez. Eles fornecem uma atualização rápida de pequenas quantidades de dados e a imposição de restrições referenciais de integridade. Normalmente, eles são executados em uma única máquina grande e não fornecem suporte para a execução das funções mapear e reduzir na tabela, nem a ações em tipos de dados complexos definidos pelo usuário.

Em contrapartida, o Hive executa consultas semelhantes ao SQL usando MapReduce. Consequentemente, ele é otimizado para realizar digitalizações de tabelas completas ao ser executado em um cluster de máquinas e, portanto, é capaz de processar grandes quantidades de dados. O Hive fornece tabelas particionadas, que permitem a digitalização de uma partição de uma tabela, em vez de toda a tabela, se isso for apropriado para a consulta que está executando.

Os sistemas RDMS tradicionais são ideais para quando a semântica transacional e a integridade referencial forem exigidas, e pequenas atualizações frequentes forem desempenhadas. O Hive é ideal para o informe offline, a transformação e a análise de grandes conjuntos de dados; por exemplo, desempenhar a análise do fluxo de cliques em um site grande ou em um conjunto de sites.

Uma das práticas comuns é exportar dados dos sistemas RDBMS para o Amazon S3 onde a análise offline pode ser desempenhada usando fluxos de trabalho do Amazon EMR executando o Hive.

P: Como posso começar a usar o Hive em execução no Amazon EMR?

A melhor forma de começar é examinar nossa documentação escrita aqui.

P: Há novos recursos no Hive específicos para o Amazon EMR?

Sim. Consulte nossa documentação para obter mais detalhes:

• Você pode iniciar um cluster EMR com múltiplos nós mestres para suportar alta disponibilidade para o Apache Hive. Em caso de falha do nó principal em operação ou de processos críticos, como o Resource Manager ou o Name Node, o Amazon EMR executará automaticamente um failover para um nó principal em espera. Isto significa que você pode executar o Apache Hive em clusters EMR sem interrupção.
• O Amazon EMR permite que você defina o EMR Managed Scaling para os clusters Apache Hive para ajudá-lo a otimizar o uso de seus recursos. Com o EMR Managed Scaling, você pode automaticamente alterar o tamanho do seu cluster para melhor desempenho no menor custo possível. Com o EMR Managed Scaling, você especifica os limites mínimo e máximo de cálculo para seus clusters e o Amazon EMR automaticamente os adapta para melhor desempenho e utilização de recursos. O EMR Managed Scaling amostra continuamente as principais métricas associadas às cargas de trabalho em execução nos clusters.
• O Amazon EMR 6.0.0 adiciona suporte ao Hive LLAP, proporcionando uma velocidade média de desempenho de 2x sobre o EMR 5.29. Você pode saber mais aqui.
• O Amazon EMR também possibilita uma performance rápida em consultas complexas do Apache Hive. O EMR utiliza o Apache Tez por padrão, que é significativamente mais rápido do que o Apache MapReduce. O Apache MapReduce utiliza várias fases, de modo que uma consulta complexa do Apache Hive seria dividida em quatro ou cinco trabalhos. O Apache Tez é projetado para consultas mais complexas, de modo que o mesmo trabalho no Apache Tez funcionaria em um único trabalho, tornando-o significativamente mais rápido que o Apache MapReduce.
  
• Com o Amazon EMR, você tem a opção de deixar a metastore como local ou externalizá-la. O EMR oferece integração com o Catálogo de Dados da AWS Glue, Amazon Aurora, Amazon RDS e AWS Lake Formation. O Amazon EMR pode extrair informações diretamente do Glue ou Lake Formation para povoar a metáfora.
• Você pode carregar partições de tabelas automaticamente com base no Amazon S3. Anteriormente, para importar uma tabela particionada, você precisava de uma instrução de tabela de alteração separada para cada partição individual na tabela. O Amazon EMR agora inclui um novo tipo de instrução para a linguagem Hive: "alter table recover partitions". Essa instrução permite que você importe facilmente tabelas de forma simultânea em muitos clusters sem ter de manter um repositório de metadados compartilhado. Use esta funcionalidade para ler com base em tabelas nas quais processos externos estão depositando dados, por exemplo arquivos de log.
• Você pode gravar dados diretamente no Amazon S3. Ao gravar dados nas tabelas no Amazon S3, a versão do Hive instalada no Amazon EMR grava diretamente no Amazon S3 sem o uso de arquivos temporários. Isso gera um aumento considerável de performance, mas também significa que, do ponto de vista do Hive, o HDFS e o S3 têm comportamentos diferentes. Não será possível ler e gravar na mesma instrução na mesma tabela se a tabela estiver localizada no Amazon S3. Se você quiser atualizar uma tabela localizada no S3, então crie uma tabela temporária no sistema de arquivos do HDFS local do cluster, grave os resultados na tabela e, em seguida, copie-os no Amazon S3.
• Você pode acessar recursos localizados no Amazon S3. A versão do Hive instalada no Amazon EMR permite que você mencione recursos como scripts para operações personalizadas de mapeamento e redução, ou bibliotecas adicionais localizadas no Amazon S3 diretamente com base no script do Hive (por ex., adicionar jar s3://elasticmapreduce/samples/hive-ads/libs/jsonserde.jar).
  
  

P: Quais tipos de clusters do Hive são compatíveis?

Há dois tipos de clusters compatíveis com o Hive: Interativo e em lote. Em um modo interativo, um cliente pode iniciar um cluster e executar scripts do Hive interativamente, direto no nó principal. Normalmente, esse modo é usado para executar análises de dados ad hoc e para o desenvolvimento de aplicativos. No modo em lote, o script do Hive é armazenado no Amazon S3 e é mencionado no início do cluster. Em geral, o modo em lote é usado para execuções repetíveis, como a geração de relatórios.

P: Como posso iniciar um cluster do Hive?

Os clusters em lote e interativos podem ser iniciados com base no Console de Gerenciamento da AWS, no cliente de linha de comando do EMR ou em APIs. Consulte a seção Hive no guia de versões para obter mais detalhes sobre executar um cluster do Hive.

P: Quando devo usar o Hive em vez do PIG?

O Hive e o PIG oferecem linguagens de processamento de dados de alto nível com suporte para tipos de dados complexos para a operação em conjuntos de dados grandes. A linguagem do Hive é uma variante do SQL e, portanto, é mais acessível para pessoas já familiarizadas com SQL e bancos de dados relacionais. O Hive tem suporte para tabelas particionadas que permitem que os clusters do Amazon EMR extraiam somente a partição da tabela relevante para a consulta sendo executada, em vez de realizar uma digitalização completa da tabela. O PIG e o Hive têm otimização de planos de consulta. O PIG pode otimizar uma gama de scripts completos, enquanto as consultas do Hive são otimizadas no nível de instrução.

Em uma análise, a escolha pelo uso do Hive ou PIG dependerá dos requisitos exatos do domínio do aplicativo e das preferências dos implementadores e daqueles que gravam consultas.

P: Qual versão do Hive é compatível com o Amazon EMR?

Para a última versão do Hive no Amazon EMR, favor consultar a documentação.

P: Posso gravar em uma tabela com base em dois clusters simultaneamente

O Hive não oferece suporte à gravação simultânea das tabelas. Você deve evitar a gravação simultânea na mesma tabela ou a leitura de uma tabela enquanto estiver gravando nela. O Hive tem um comportamento não determinístico ao ler e gravar ao mesmo tempo, ou ao gravar e gravar ao mesmo tempo.

P: Posso compartilhar dados entre clusters?

Sim. Você pode ler dados no Amazon S3 dentro de um script do Hive ao contar com instruções 'create external table' no topo do script. É necessário criar uma instrução de tabela para cada recurso externo acessado.

P: Devo executar um cluster grande e compartilhá-lo entre muitos usuários ou muitos clusters menores?

O Amazon EMR fornece uma capacidade exclusiva para uso de ambos os métodos. Por um lado, um cluster grande poderá ser mais eficiente para o processamento de cargas de trabalho em lote regulares. Por outro lado, se você exigir consultas ad hoc ou cargas de trabalho que variem com o tempo, poderá optar por criar vários clusters separados, adaptados para fontes de dados de compartilhamento de tarefas específicas armazenadas no Amazon S3. Você pode usar o EMR Managed Scaling para otimizar o uso dos recursos.

P: Posso acessar um script ou recurso jar que esteja no sistema de arquivos local?

Não. É necessário fazer o upload do script ou jar no Amazon S3 ou no nó principal do cluster antes que ele possa ser referenciado. Para fazer o upload do Amazon S3, você pode usar ferramentas incluindo s3cmd, jets3t ou S3Organizer.

P: Posso executar um cluster persistente executando várias consultas Hive?

Sim. Execute um cluster em um modo de encerramento normal de forma que ele não seja encerrado entre as etapas do Hive. Para reduzir o risco da perda de dados, recomendamos a persistência periódica de todos os dados importantes no Amazon S3. Recomenda-se transferir regularmente seu trabalho para um novo cluster para testar a recuperação de falha do nó principal para o seu processo.

P: Vários usuários podem executar etapas do Hive nos mesmos dados de origem?

Sim. Os scripts do Hive executados por vários usuários em clusters separados poderão conter instruções criar tabelas externas para importar simultaneamente dados de origem que residem no Amazon S3.

P: Vários usuários podem executar consultas no mesmo cluster?

Sim. No modo em lote, as etapas são serializadas. Vários usuários podem adicionar etapas do Hive ao mesmo cluster, porém, as etapas serão executadas serialmente. No modo interativo, vários usuários podem ser conectados ao mesmo cluster e executar instruções do Hive simultaneamente.

P: Os dados podem ser compartilhados entre vários usuários do AWS?

Sim. Os dados podem ser compartilhados usando o mecanismo padrão de compartilhamento do Amazon S3 descrito aqui.

P: O Hive oferece suporte ao acesso com base no JDBC?

Sim. O Hive fornece a unidade JDBC, que pode ser usada para executar instruções do Hive de forma programada. Para iniciar um serviço do JDBC no cluster, é necessário transmitir um parâmetro opcional no cliente da linha de comando do Amazon EMR. Você também tem de estabelecer um túnel de SSH porque o grupo de segurança não permite conexões externas.

P: Qual é o procedimento para atualizar pacotes nas AMIs do EMR?

Na primeira inicialização, as AMIs do Amazon Linux para EMR se conectam aos repositórios yum da AMI do Amazon Linux para instalar atualizações de segurança. Quando você usa uma AMI personalizadas, pode desativar esse recurso. No entanto, não recomendamos essa ação por motivos de segurança.

P: Posso atualizar meus próprios pacotes nos clusters do EMR?

Sim. Você pode usar o Bootstrap Actions para instalar atualizações nos pacotes em seus clusters.

P: Posso processar dados do DynamoDB com o Hive?

Sim. Defina simplesmente uma tabela do Hive externa com base na sua tabela do DynamoDB. Você pode usar o Hive para analisar dados armazenados no DynamoDB e também carregar os resultados de volta no DynamoDB, ou arquivá-los no Amazon S3. Para obter mais informações, acesse nosso Guia do desenvolvedor.

P: O que é o Apache Hudi?

O Apache Hudi é uma estrutura de gerenciamento de dados de código aberto usada para simplificar o processamento incremental de dados e o desenvolvimento de pipelines de dados. O Apache Hudi lhe permite gerenciar dados de registro no Amazon S3 para simplificar o Change Data Capture (CDC) e o streaming de consumo de dados, além de fornecer uma estrutura para lidar com casos de uso de privacidade de dados exigindo atualizações e exclusões no nível de registro. Os conjuntos de dados gerenciados pelo Apache Hudi são armazenados no S3 por meio de formatos de armazenamento aberto, e as integrações com o Presto, o Apache Hive, o Apache Spark e o catálogo de dados do AWS Glue lhe oferecem acesso a dados atualizados quase em tempo real por meio de ferramentas conhecidas.

P: Quando devo usar o Apache Hudi?

O Apache Hudi lhe ajuda com casos de uso exigindo gerenciamento de dados no nível de registro no S3. Há cinco casos de uso comuns que se beneficiam de tais capacidades:

1. Cumprir leis de privacidade de dados que exigem que organizações removam dados do usuário, ou atualizem as preferências de usuários quando estes optam por alterar suas preferências sobre o uso de dados. O Apache Hudi lhe oferece a possibilidade de executar operações de inserção, atualização e exclusão em seus dados armazenados no S3, a partir de formatos de dados de código aberto, como Apache Parquet e Apache Avro.
2. Consumir streams de dados em tempo real e aplicar logs de change data capture de sistemas corporativos. Muitas organizações exigem que os dados do Enterprise Data Warehouses (EDW) e do Operational Data Stores (ODS) estejam disponíveis no Amazon S3 de forma que fiquem disponíveis para os mecanismos SQL, como Apache Hive e Presto, para processamento e análise de dados. O Apache Hudi simplifica a aplicação de logs de mudanças e oferece aos usuários acesso a dados praticamente em tempo real.
3. Reintegração de chegadas com atraso ou dados incorretos. Chegadas com atraso ou dados incorretos demandam a reintegração de dados, de forma que os conjuntos de dados existentes sejam atualizados para incorporar registros novos ou atualizados. O Apache Hudi permite que você faça “upsert” de registros em um conjunto de dados existente, assumindo que a estrutura irá inserir ou atualizar os registros vinculados à ela no conjunto de dados.
4. Rastreando alterações nos conjuntos de dados e fornecendo a capacidade de reverter alterações. Com o Apache Hudi, cada alteração em um conjunto de dados é rastreada como uma confirmação e pode ser facilmente revertida, permitindo que você encontre alterações específicas em um conjunto de dados e possa “desfazê-las”.
5. Simplificando o gerenciamento de arquivos no S3. Para garantir que os arquivos de dados sejam dimensionados de forma eficiente, os clientes precisam criar soluções personalizadas que monitorem e reescrevam muitos arquivos pequenos em uma quantidade menor de arquivos grandes. Com o Apache Hudi, os arquivos de dados no S3 são gerenciados e os usuários podem simplesmente configurar um tamanho de arquivo ótimo para armazenar seus dados e o Hudi então irá mesclar arquivos para estabelecer arquivos com tamanhos eficientes.
6. Escrita de deltas para um conjunto de dados Hudi alvo. Os conjuntos de dados Hudi podem ser puxados de forma incremental, o que significa que você pode obter TODAS e SOMENTE as linhas atualizadas e novas desde um tempo instantâneo especificado.

P: Como eu crio um conjunto de dados do Apache Hudi?

Os conjuntos de dados do Apache Hudi são criados por meio do Apache Spark. Criar um conjunto de dados é tão simples quanto compor um quadro de dados do Apache Spark. Os metadados para conjuntos de dados do Apache Hudi opcionalmente podem ser armazenados no catálogo de dados do AWS Glue ou no Hive metastore para simplificar a descoberta de dados e integrá-los com o Apache Hive e o Presto.

P: Como o Apache Hudi gerencia conjuntos de dados?

Ao criar um conjunto de dados com o Apache Hudi, você pode escolher que tipo de padrão de acesso aos dados implementar para que o conjunto seja otimizado de acordo. Para casos de uso de leitura pesada, você pode escolher a estratégia de gerenciamento de dados “cópia em gravação” para a otimização direcionada a leituras frequentes do conjunto de dados. Essa estratégia organiza dados usando formatos de armazenamento colunares e mescla dados existentes e novas atualizações, quando estas são gravadas. Para cargas de trabalho pesadas, o Apache Hudi usa a estratégia de gerenciamento de dados "Merge on Read" que organiza os dados usando uma combinação de formatos de armazenamento em colunas e linhas, onde as atualizações são anexadas a um arquivo em formato de armazenamento baseado em linhas, enquanto a fusão é realizada no momento da leitura para fornecer os resultados atualizados.

P: Como eu gravo em um conjunto de dados do Apache Hudi?

Alterações em conjuntos de dados do Apache Hudi são feitas por meio do Apache Spark. Com o Apache Spark, os conjuntos de dados do Apache Hudi são operados por meio da API do Spark DataSource, permitindo que você leia e grave dados. DataFrame contendo dados recentemente adicionados ou atualizações de dados existentes pode ser escrito usando a mesma API DataSource". Você também pode usar o utilitário Hudi DeltaStreamer.

P: Como eu leio a partir de um conjunto de dados do Apache Hudi?

Você pode ler os dados usando ou Apache Spark, Apache Hive, Presto, Amazon Redshift Spectrum ou Amazon Athena. Ao criar um conjunto de dados, você terá a opção de publicar os medadados desse conjunto de dados no catálogo de dados do AWS Glue Data Catalog ou no Hive metastore. Se você optar por publicar os metadados em um metastore, seu conjunto de dados terá uma aparência semelhante a uma tabela comum e você poderá consultá-lo usando o Apache Hive e o Presto.

P: Que considerações ou restrições devo ter em mente ao usar o Apache Hudi?

Para obter uma lista completa de considerações e restrições relativas ao uso do Apache Hudi no Amazon EMR, consulte a nossa documentação do Amazon EMR.

P: Como meus dados existentes funcionarão com o Apache Hudi?

Se você possui dados existentes e deseja gerenciá-los pelo Apache Hudi, você pode facilmente converter seus dados do Apache Parquet para conjuntos de dados do Apache Hudi por meio da ferramenta de importação fornecida pelo Apache Hudi no Amazon EMR, ou você pode usar o utilitário Hudi DeltaStreamer, ou usar o Apache Spark para regravar seus dados existentes como um conjunto de dados do Apache Hudi.

P: O que é o Impala?

O Impala é uma ferramenta de código aberto no ecossistema Hadoop para consulta ad hoc interativa que usa sintaxe SQL. Em vez de usar o MapReduce, ele utiliza um mecanismo de processamento maciçamente paralelo (MPP) semelhante ao encontrado em sistemas de gestão tradicional de banco de dados relacional (RDBMS). Com essa arquitetura, é possível consultar os dados nas tabelas HDFS ou HBase muito rapidamente e aproveitar a capacidade do Hadoop em processar tipos de dados diversos e fornecer o esquema em tempo de execução. Isto atribui o Impala à análise interativa e de baixa latência. Além disso, Impala usa o Hive Metastore para armazenar informações sobre os dados de entrada, incluindo os nomes de partição e tipos de dados. Também, o Impala no Amazon EMR requer AMIs executando Hadoop 2.x ou superior. Clique aqui para saber mais sobre o Impala.

P: O que pode ser feito com o Impala sendo executado no Amazon EMR?

Tão semelhante quanto usar o Hive com Amazon EMR, aproveitar o Impala com o Amazon EMR pode implementar aplicativos sofisticados de processamento de dados com sintaxe SQL. No entanto, o Impala é construído para executar mais rápido em certos casos de uso (veja abaixo). Com o Amazon EMR, é possível usar o Impala como um data warehouse confiável para executar tarefas como análise de dados, de monitoramento e de inteligência corporativa. Aqui estão três casos de uso:

• Use o Impala em vez do Hive em clusters de longa duração para executar consultas ad hoc. O Impala reduz consultas interativas para segundos, tornando-o uma excelente ferramenta para rápida investigação. É possível executar o Impala no mesmo cluster que os fluxos de trabalho de MapReduce de lote, usar Impala em um cluster de análise de longa duração com o Hive e o Pig ou criar um cluster especificamente sintonizado para consultas do Impala.
• Use o Impala em vez do Hive para trabalhos em ETL de lote em clusters transitórios do Amazon EMR. O Impala é mais rápido do que o Hive para muitas consultas, o que fornece melhor performance para essas cargas de trabalho. Tal como o Hive, o Impala usa SQL; portanto, as consultas podem ser facilmente modificadas do Hive para o Impala.
• Use o Impala junto com uma ferramenta de inteligência empresarial de um terceiro. Conecte um cliente ODBC ou driver JDBC com o cluster para usar o Impala como mecanismo para painéis e ferramentas poderosos de visualização.

Tanto os clusters interativos quanto em lote do Impala podem ser criados no Amazon EMR. Por exemplo, é possível ter um cluster do Amazon EMR de longa duração executando o Impala para consultas ad hoc interativas ou usar clusters transitórios do Impala para fluxos de trabalho ETL rápidos.

P: Qual é a diferença do Impala para os RDBMSs tradicionais?

Sistemas de banco de dados relacional tradicionais fornecem semântica de transação e atomicidade de banco de dados, consistência, isolamento e propriedades (ACID) de resiliência. Eles também permitem que as tabelas sejam indexadas e armazenadas em cache para que pequenas quantidades de dados possam ser recuperadas rapidamente, forneçam atualizações rápidas de pequenas quantidades de dados e para a imposição de restrições de integridade referencial. Normalmente, eles são executados em uma única máquina grande e não fornecem suporte para agir em tipos complexos de dados definidos pelo usuário. O Impala usa um sistema similar de consulta distribuída para aquela descoberta em RDBMSs, porém consulta os dados armazenados no HDFS e usa o Hive Metastore para armazenar informações sobre os dados de entrada. Tal como acontece com o Hive, o esquema para uma consulta é fornecido em tempo de execução, permitindo alterações de esquema com maior facilidade. Além disso, o Impala pode consultar uma variedade de tipos complexos de dados e executar as funções definidas pelo usuário. No entanto, porque o Impala processa dados na memória, é importante compreender as limitações de hardware do cluster e otimizar as consultas para obter a melhor performance.

P: Qual é a diferença do Impala para o Hive?

O Impala executa consultas SQL usando um mecanismo de processamento maciçamente paralelo (MPP), enquanto o Hive executa consultas SQL usando o MapReduce. O Impala evita sobrecargas do Hive em criar trabalhos no MapReduce, dando-lhe tempos de consulta mais rápidos do que o Hive. No entanto, o Impala usa recursos de memória significativos e a memória disponível do cluster coloca uma restrição na quantidade de memória que qualquer consulta possa consumir. O Hive não é limitado da mesma forma e pode processar com êxito conjuntos de dados maiores com o mesmo hardware. Geralmente, você deve usar o Impala para consultas rápidas, interativas, enquanto o Hive é melhor para cargas de trabalho ETL em grandes conjuntos de dados. O Impala é construído para a velocidade e é ótima para consulta ad hoc, mas requer uma quantidade significativa de memória para executar consultas caras ou processar conjuntos de dados muito grandes. Devido a essas limitações, o Hive é recomendado para cargas de trabalho em que a velocidade não é tão crucial quanto a conclusão. Clique aqui para visualizar alguns referenciais de desempenho entre o Impala e o Hive.

P: É possível usar o Hadoop 1?

Não, o Impala requer o Hadoop 2 e não será executado em um cluster com um AMI executando o Hadoop 1. x.

P: Que tipos de instância são necessários usar para o cluster do Impala?

Para a melhor experiência com o Impala, recomendamos o uso de instâncias de memória otimizadas para o seu cluster. No entanto, mostramos que existem ganhos de performance no Hive quando se usam também tipos de instância padrão. Sugerimos a leitura da seção sobre Testes de desempenho e otimização de consultas, no Guia do desenvolvedor do Amazon EMR, para melhor estimar os recursos de memória de que o cluster precisará com relação aos tipos de conjuntos de dados e de consultas. O tipo de compressão, as partições e a consulta real (número de junções, tamanho do resultado, etc.) são fatores importantes para determinar a necessidade de memória. Você pode usar o comando EXPLAIN para estimar a memória e outros recursos necessários para uma consulta do Impala.

P: O que acontece se a memória acabar em uma consulta?

Se memória acabar, as consultas falham e o daemon do Impala instalado no nó afetado é desligado. Em seguida, o Amazon EMR reinicia o daemon no nó para que o Impala esteja pronto para executar outra consulta. Seus dados no HDFS no nó permanecem disponíveis, porque somente o daemon em execução no nó é desligado, ao invés do nó inteiro em si. Para a análise ad-hoc com Impala, o tempo de consulta muitas vezes pode ser medido em segundos; portanto, se uma consulta falhar, é possível descobrir o problema rapidamente e será possível apresentar uma nova consulta em rápida sucessão.

P: O Impala oferece suporte a funções definidas pelo usuário?

Sim, o Impala oferece suporte a funções definidas pelo usuário (UDFs). Você pode gravar UDFs específicos do Impala no Java ou C++. Além disso, é possível modificar UDFs ou funções de agregação definidas pelo usuário criadas para o Hive para uso com o Impala. Para obter mais informações sobre as UDFs do Hive, clique aqui.

P: Onde são armazenados os dados para o Impala consultar?

O Impala consulta dados nas tabelas HDFS ou HBase.

P: É possível executar o Impala e o MapReduce ao mesmo tempo em um cluster?

Sim, é possível configurar um cluster de múltiplos usuários com o Impala e o MapReduce. No entanto, deve-se alocar recursos (memória, disco e CPU) para cada aplicativo usando o YARN no Hadoop 2.x. Os recursos alocados devem depender das necessidades de trabalhos que você pretende executar em cada aplicativo.

P: O Impala oferece suporte a drivers ODBC e JDBC?

O Impala usa drivers ODBC além de ser um grande mecanismo para ferramentas de terceiros conectados através do JDBC. Você pode baixar e instalar o driver JDBC do cliente Impala pelo link http://elasticmapreduce.s3.amazonaws.com/libs/impala/1.2.1/impala-jdbc-1.2.1.zip. Do computador cliente onde a ferramenta de inteligência empresarial está instalada, conecte o driver JDBC ao nó principal de um cluster de Impala usando SSH ou uma VPN na porta 21050. Para obter mais informações, consulte o tópico sobre como Abrir um túnel SSH para o nó mestre.

P: O que é o Apache Pig?

O Pig é um pacote analítico de código aberto executado com base no Hadoop. O Pig é operado por uma linguagem semelhante ao SQL chamada Pig Latin, que permite que os usuários estruturem, resumam e consultem fontes de dados armazenadas no Amazon S3. Assim como as operações semelhantes ao SQL, o Pig Latin também adiciona suporte de primeira classe para funções mapear/reduzir e tipos de dados complexos e extensíveis definidos pelo usuário. Essa capacidade permite o processamento de fontes de dados complexas e até não estruturadas, como documentos de texto e arquivos de log. O Pig permite extensões de usuário por meio de funções definidas por este gravadas no Java e implementadas via armazenamento no Amazon S3.

P: O que pode ser feito com o Pig sendo executado no Amazon EMR?

Usando o Pig com o Amazon EMR, você pode implementar aplicativos de processamento de dados sofisticados com uma linguagem familiar semelhante ao SQL e ferramentas fáceis de usar com o Amazon EMR. Com o Amazon EMR, você pode transformar os aplicativos Pig em um data warehouse confiável para executar tarefas como analítico de dados, de monitoramento e de inteligência corporativa.

P: Como posso começar a usar o Pig sendo executado no Amazon EMR?

A melhor forma de começar é examinar nossa documentação escrita aqui.

P: Há recursos novos no Pig específicos do Amazon EMR?

Sim. Há três novos recursos que tornam o Pig ainda mais robusto quando usado com o Amazon EMR, incluindo:

a/ Acesso a vários sistemas de arquivos. Como padrão, um trabalho do Pig pode acessar somente um sistema de arquivos remoto, seja um repositório do HDFS ou um bucket do S3, para dados de entrada, de saída e temporários. O EMR estendeu o Pig para que qualquer trabalho possa acessar quantos sistemas de arquivos desejar. Uma vantagem disso é que os dados temporários do trabalho são sempre armazenados no HDFS local, resultando em melhor performance.

b/ Carregamento de recursos do S3. O EMR estendeu o Pig de forma que JARs e scripts personalizados possam ser extraídos do sistema de arquivos do S3, por exemplo “REGISTER s3:///my-bucket/piggybank.jar”

c/ Função adicional Piggybank para processamento de String e DateTime.

P: Quais tipos de clusters do Pig são compatíveis?

Há dois tipos de cluster compatíveis com o Pig: Interativo e em lote. Em um modo interativo, um cliente pode iniciar um cluster e executar scripts do Pig interativamente, direto no nó principal. Normalmente, esse modo é usado para executar análises de dados ad hoc e para o desenvolvimento de aplicativos. No modo em lote, o script do Pig é armazenado no Amazon S3 e é mencionado no início do cluster. Em geral, o modo em lote é usado para execuções repetíveis, como a geração de relatórios.

P: Como posso iniciar um cluster do Pig?

Os clusters em lote e interativos podem ser iniciados com base no Console de Gerenciamento da AWS, no cliente de linha de comando do EMR ou em APIs.

P: Qual versão do Pig é compatível com o Amazon EMR?

O Amazon EMR oferece suporte a várias versões do Pig.

P: Posso gravar em um bucket do S3 com base em dois clusters simultaneamente

Sim, você pode gravar no mesmo bucket com base em dois clusters simultâneos.

P: Posso compartilhar dados de entrada no S3 entre clusters?

Sim, você pode ler os mesmos dados no S3 com base em dois clusters.

P: Os dados podem ser compartilhados entre vários usuários do AWS?

Sim. Os dados podem ser compartilhados usando o mecanismo padrão de compartilhamento do Amazon S3 descrito aqui: http://docs.amazonwebservices.com/AmazonS3/latest/index.html?S3_ACLs.html

P: Devo executar um cluster grande e compartilhá-lo entre muitos usuários ou muitos clusters menores?

O Amazon EMR fornece uma capacidade exclusiva para uso de ambos os métodos. Por um lado, um cluster grande poderá ser mais eficiente para o processamento de cargas de trabalho em lote regulares. Por outro lado, se você exigir consultas ad hoc ou cargas de trabalho que variem com o tempo, poderá optar por criar vários clusters separados, adaptados para fontes de dados de compartilhamento de tarefas específicas armazenadas no Amazon S3.

P: Posso acessar um script ou recurso jar que esteja no sistema de arquivos local?

Não. É necessário fazer o upload do script ou jar no Amazon S3 ou no nó principal do cluster antes que ele possa ser referenciado. Para fazer o upload do Amazon S3, você pode usar ferramentas incluindo s3cmd, jets3t ou S3Organizer.

P: Posso executar um cluster existente executando várias consultas Pig?

Sim. Execute um cluster em um modo de encerramento manual de forma que ele não encerre entre etapas do Pig. Para reduzir o risco da perda de dados, recomendamos a persistência periódica de todos os dados importantes no Amazon S3. Recomenda-se transferir regularmente seu trabalho para um novo cluster para testar o processamento quanto à recuperação de falhas do nó principal.

P: O Pig oferece suporte ao acesso com base no JDBC?

Não. O Pig não oferece suporte ao acesso por meio do JDBC. 

P: O que é o Apache HBase?

O HBase é um banco de dados de código aberto, não relacional e distribuído, modelado de acordo com o BigTable da Google. Foi desenvolvido como parte do projeto Hadoop da Apache Software Foundation e é executado com base no Hadoop Distributed File System (HDFS) para fornecer recursos similares aos da BigTable para Hadoop. O HBase disponibiliza uma maneira eficiente e tolerante a falhas de armazenar grandes quantidades de dados esparsos usando compactação e armazenamento baseado em colunas. Além disso, o HBase oferece consulta de dados rápida, pois os dados são armazenados na memória, em vez de no disco. O HBase é otimizado para operações de gravação sequencial, e é altamente eficiente para inserções, atualizações e exclusões em lote. O HBase funciona sem dificuldade com o Hadoop, compartilhando seu sistema de arquivos e servindo como entrada e saída direta para os trabalhos do Hadoop. O HBase também se integra ao Apache Hive, possibilitando consultas tipo SQL em tabelas HBase, junções com tabelas baseadas no Hive e suporte para Java Database Connectivity (JDBC). Você pode buscar saber mais sobre o Apache HBase aqui.

P: Há novos recursos no HBase específicos para o Amazon EMR?

Com o Amazon EMR, você pode usar o HBase no Amazon S3 para armazenar o diretório raiz e metadados de um cluster do HBase diretamente no Amazon S3 e criar réplicas lidas e snapshots. Para saber mais, consulte a nossa documentação.

P: Quais versões do HBase são compatíveis com o Amazon EMR?

Você pode ver as últimas versões HBase suportadas na Amazon EMR aqui.

P: O que o conector EMR para o Kinesis possibilita?

O conector possibilita que o EMR leia e consulte dados diretamente de streams do Kinesis. Agora você pode executar o processamento em lote de streams do Kinesis usando ferramentas já existentes do ecossistema do Hadoop como o Hive, Pig, MapReduce, Streaming do Hadoop e o Cascading.

P: O que o conector do EMR para o Kinesis possibilita que eu não podia fazer antes?

Ler e processar dados de um stream do Kinesis necessitaria que você escrevesse, implementasse e mantivesse aplicativos independentes de processamento de streams. Estes consomem tempo e esforço. Porém, com este conector, você pode começar a ler e analisar um stream do Kinesis escrevendo um simples script do Hive ou Pig. Isso significa que você pode analisar os streams do Kinesis usando SQL! Obviamente, outras ferramentas do ecossistema do Hadoop podem ser usadas também. Você não precisa desenvolver ou manter um novo conjunto de aplicativos de processamento.

P: Quem considerará útil esta funcionalidade?

Os seguintes tipos de usuários acharão esta integração útil:

• Usuários do Hadoop interessados em utilizar a extensa gama de ferramentas do ecossistema do Hadoop para analisar streams do Kinesis.
  
• Usuários do Kinesis que procuram uma forma fácil de começarem no processamento de streams e ETL de dados do Kinesis.
  
• Analistas de negócios e profissionais de TI que gostariam de executar análises diretas de dados em streams do Kinesis usando ferramentas familiares como o SQL (através do Hive) ou linguagens de script como o Pig.
  

P: Quais são alguns casos de uso para esta integração?

Estes são alguns casos de uso representativos possibilitados por esta integração:

• Análise de log de streaming: Você pode analisar logs web de streaming para gerar uma lista dos 10 maiores tipos de erros, em intervalos de minutos, por região, navegador e domínios de acesso.
  
• Fluxos de trabalho complexos de processamento de dados: Você pode juntar um stream do Kinesis a dados armazenados no S3, tabelas do Dynamo DB e HDFS. Você pode escrever consultas que unem dados de clickstream do Kinesis com informações de uma campanha de anúncios armazenadas em uma tabela do DynamoDB para identificar as categorias mais efetivas de anúncios exibidos em determinados websites.
  
• Consultas diretas: Você pode carregar periodicamente dados do Kinesis no HDFS e torná-lo disponível como uma tabela local do Impala para realizar consultas velozes, interativas e analíticas.
  

P: Qual versão da AMI do EMR eu preciso para poder usar o conector?

Você precisa usar a AMI do EMR nas versões 3.0.4 e superiores.

P: O conector é uma ferramenta separada?

Não, ele é um componente integrado da distribuição Hadoop da Amazon e está presente na AMI do EMR nas versões 3.0.4 e superiores. O cliente precisa apenas ativar um cluster com a AMI versão 3.0.4 ou superior para começar a usar este recurso.

P: Qual formato de dados é necessário para permitir que o EMR leia um stream do Kinesis?

A integração do EMR com o Kinesis não exige um tipo de dados específico. Você pode ler dados em qualquer formato. Registros individuais do Kinesis são apresentados ao Hadoop como registros comuns que podem ser lidos com qualquer estrutura de MapReduce do Hadoop. Estruturas individuais como o Hive, Pig e o Cascading têm componentes integrados que ajudam na serialização e desserialização, tornando fácil para os desenvolvedores consultarem dados em diversos formatos ser terem de implementar código próprio. Por exemplo, no Hive, os usuários podem ler dados de arquivos JSON, arquivos XML e arquivos SEQ especificando o Hive SerDe apropriado ao definirem a tabela. O Pig tem um componente similar chamado Loadfunc/Evalfunc, e o Cascading tem um componente similar chamado Tap. Os usuários do Hadoop podem aproveitar o amplo ecossistema de adaptadores do Hadoop sem terem de escrever código para formatos específicos. Você também pode implementar formatos customizados de desserialização para ler dados específicos de domínio em qualquer uma destas ferramentas.

P: Como analiso um stream do Kinesis usando o Hive no EMR?

Crie uma tabela que faz referência a um stream do Kinesis. Então, analise a tabela como com qualquer outra tabela no Hive. Veja a nossa página de tutoriais para obter mais detalhes.

P: Usando o Hive, como eu crio consultas que combinam dados de um stream do Kinesis com outra fonte de dados?

Primeiro, crie uma tabela que referencia um stream do Kinesis. Criada a tabela do Hive, você pode associá-la (join) com tabelas que apontam para outras fontes de dados como o Amazon S3, Amazon Dynamo DB e o HDFS. Efetivamente isto resulta na união de dados de um stream do Kinesis com outras fontes de dados.

P: Esta integração só é disponível para o Hive?

Não, você pode utilizar o Hive, Pig, MapReduce, Hadoop Streaming e o Cascading.

P: Como configuro tarefas agendadas para executarem em um stream do Kinesis?

O conector de entrada do EMR do Kinesis oferece recursos que ajudam a configurar e gerenciar tarefas agendadas periódicas em mecanismos tradicionais de agendamento como o Cron. Por exemplo, você pode desenvolver um script do Hive que executa a cada N minutos. Nos parâmetros de configuração de uma tarefa, você pode especificar um nome lógico para a tarefa. O nome lógico é um rótulo que informará o conector de entrada do EMR do Kinesis quais instâncias individuais da tarefa são membros do mesmo agendamento periódico. O nome lógico permite que o processo aproveite a iteratividade, o que é explicado a seguir.

Como o MapReduce é uma estrutura de processamento em lotes, para analisar um stream do Kinesis com o EMR o stream contínuo é dividido em lotes. Cada lote é chamado de uma iteração. Cada iteração recebe um número, começando com 0. Os limites de cada iteração são definidos por um número de início de sequência e um número de fim de sequência. As iterações são então processadas sequencialmente pelo EMR.

Na ocasião de falha de uma das tentativas, o conector de entrada do EMR do Kinesis tentará executar a iteração novamente, no contexto do nome lógico, a partir do número de início de sequência da iteração. Esta funcionalidade garante que sucessivas tentativas na mesma iteração terão precisamente os mesmos registros de entrada do stream do Kinesis que as tentativas anteriores. Isto garante o processamento idempotente (consistente) do stream do Kinesis.

Você pode especificar nomes lógicos e iterações como parâmetros de tempo de execução nas suas respectivas ferramentas do Hadoop. Por exemplo, na seção sobre “Execução de consultas com pontos de verificação” do tutorial, o exemplo de código demonstra uma consulta agendada do Hive que designa um nome lógico para a consulta e incrementa a iteração a cada execução consecutiva da tarefa.

Além disso, um script de exemplo de agendamento com o cron é fornecido nos tutoriais.

P: Onde os metadados para os nomes lógicos e iterações são armazenados?

Os metadados que permitem ao conector de entrada do EMR do Kinesis funcionar integrado a fluxos de trabalho periódicos agendados são armazenados no Amazon DynamoDB. Você deve provisionar uma tabela do Amazon Dynamo DB e especificá-la como um parâmetro de entrada na tarefa do Hadoop. É importante que você configure as IOPS apropriadas para a tabela para permitir esta integração. Verifique o tutorial de conceitos básicos para obter mais informações sobre a configuração da sua tabela do Amazon Dynamo DB.

P: O que acontece quando o processamento de uma iteração falha?

Os identificadores de iteração são valores fornecidos pelo usuário que são mapeados dentro de um limite específico (números de início e fim de sequência) em um stream do Kinesis. Os dados correspondentes a estes limites são carregados na fase Map da tarefa MapReduce. Esta fase é gerenciada pela estrutura e será automaticamente reexecutada (três vezes por padrão) no caso de uma falha na tarefa. Se todas as tentativas falharem, você ainda teria as opções de tentar novamente o processamento a partir do último limite de dados executado com sucesso ou limites anteriores de dados. Este comportamento é controlado com o fornecimento do parâmetro kinesis.checkpoint.iteration.no durante o processamento. Verifique o tutorial de conceitos básicos para obter mais informações sobre como esse valor é configurado para diferentes ferramentas do ecossistema do Hadoop.

P: Posso executar múltiplas consultas na mesma iteração?

Sim, você pode especificar uma iteração executada anteriormente configurando o parâmetro kinesis.checkpoint.iteration.no em cada processamento sucessivo. A implementação garante que as execuções sucessivas na mesma iteração terão precisamente os mesmos registros de entrada do stream do Kinesis que as execuções anteriores.

P: O que acontece se os registros em uma iteração expiram no stream do Kinesis?

Na ocasião do número de início de sequência e/ou o número de fim de sequência de uma iteração pertencerem a registros que estejam expirados no stream do Kinesis, a tarefa do Hadoop falhará. Você precisaria utilizar um nome lógico diferente para processar os dados do início do stream do Kinesis.

P: Posso enviar dados do EMR para um stream do Kinesis?

Não. O conector do EMR do Kinesis atualmente não dá suporte à escrita de dados de volta no stream do Kinesis.

P: O conector de entrada do EMR do Hadoop para o Kinesis permite o processamento contínuo do stream?

A estrutura de MapReduce do Hadoop é um sistema de processamento em lotes. Portanto, ele não oferece suporte a consultas contínuas. Porém, há um conjunto emergente de estruturas do ecossistema do Hadoop, como o Twitter Storm e o Spark Streaming, que permitem aos desenvolvedores criarem aplicativos para processamento contínuo de streams. Um conector do Storm para o Kinesis está disponível no GitHub aqui, e você pode encontrar um tutorial explicando a configuração do Spark Streaming no EMR e a execução de consultas contínuas aqui.

Adicionalmente, os desenvolvedores podem utilizar a biblioteca cliente do Kinesis para desenvolver aplicativos de processamento em tempo real de streams. Você pode encontrar mais informações sobre o desenvolvimento de aplicativos personalizados para o Kinesis na documentação do Kinesis aqui.

P: Posso especificar uma credencial de acesso para ler um stream do Kinesis que é gerenciado em outra conta da AWS?

Sim. Você pode ler streams de outra conta da AWS especificando as credenciais de acesso apropriadas da conta que controla o stream do Kinesis. Por padrão, o conector do Kinesis usa as credenciais de acesso fornecidas pelo usuário que são especificadas quando o cluster é criado. Você pode substituir estas credenciais para acessar streams de outras contas da AWS configurando os parâmetros kinesis.accessKey e kinesis.secretKey. Os exemplos seguintes mostram como configurar os parâmetros kinesis.accessKey e kinesis.secretKey no Hive e Pig.

Exemplo de código do Hive:
...
ARMAZENADO POR
'com.amazon.emr.kinesis.hive.KinesisStorageHandler'
TBLPROPERTIES(
"kinesis.accessKey"="AwsAccessKey",
"kinesis.secretKey"="AwsSecretKey",
);

Exemplo de código do Pig:
…
raw_logs = LOAD 'AccessLogStream' USING com.amazon.emr.kinesis.pig.Kin
esisStreamLoader('kinesis.accessKey=AwsAccessKey', 'kinesis.secretKey=AwsSecretKey'
) AS (line:chararray);

P: Posso executar várias consultas em paralelo em um único stream do Kinesis? Há impacto sobre o desempenho?

Sim, um cliente pode executar várias consultas paralelas no mesmo stream utilizando nomes lógicos individuais para cada consulta. Porém, a leitura de um particionamento em um stream do Kinesis tem um limite de transmissão de 2 MB por segundo. Portanto, se há N consultas paralelas executando no mesmo stream, cada uma conseguiria atingir uma taxa aproximada de saída de (2/N) MB por segundo por estilhaço no stream. Isto pode tornar o processamento mais lento e em alguns casos ocasionar a falha das consultas também.

P: Posso unir e analisar múltiplos streams do Kinesis no EMR?

Sim, por exemplo, no Hive, você pode criar duas tabelas mapeadas para dois streams distintos do Kinesis e criar uniões entre as tabelas.

P: O conector do EMR do Kinesis faz o tratamento de eventos de escalabilidade do Kinesis, como fusão e divisão?

Sim. A implementação trata eventos de divisão e fusão. O conector do Kinesis faz ligações de estilhaços individuais do Kinesis (a unidade lógica de escala em um stream do Kinesis) com tarefas de mapeamento do Hadoop MapReduce. Cada estilhaço individual existente em um stream no período lógico de uma iteração resultará em exatamente uma tarefa de mapeamento. No caso de um evento de divisão ou fusão de estilhaços, o Kinesis provisionará novos IDs únicos de estilhaços. Como resultado, a infraestrutura do MapReduce provisionará mais tarefas de mapeamento para leitura do Kinesis. Tudo isso é transparente para o usuário.

P: O que acontecerá se houverem períodos de “silêncio” no meu stream?

A implementação permite que você configure um parâmetro chamado kinesis.nodata.timeout. Por exemplo, considere um cenário onde o kinesis.nodata.timeout esteja configurado para 2 minutos e você queira executar uma consulta do Hive a cada 10 minutos. Também leve em consideração que alguns dados foram escritos no stream após a última iteração (há 10 minutos atrás). Porém, no momento nenhum novo registro está chegando, ou seja, há silêncio no stream. Neste caso, quando a iteração atual da consulta executar, o conector do Kinesis observará que não há novos registros chegando. O conector continuará verificando o stream por 2 minutos e se nenhum registro chegar neste intervalo, ele parará e processará apenas os registros que já foram lidos no lote atual do stream. Porém, se novos registros começarem a chegar antes do fim do intervalo kinesis.nodata.timeout, então o conector aguardará por um intervalo adicional correspondente a um parâmetro chamado kinesis.iteration.timeout. Consulte os tutoriais para ver como definir esses parâmetros.

P: Como depuro uma consulta que falha continuamente em cada iteração?

Na ocasião de uma falha de processamento, você pode utilizar as mesmas ferramentas que usa para depurar tarefas do Hadoop. Incluindo o web console do Amazon EMR, que ajuda a identificar e acessar logs de erro. Mais detalhes sobre como depurar uma tarefa do EMR podem ser encontrados aqui.

P: O que acontece se eu especificar uma tabela do DynamoDB à qual eu não tenha acesso?

A tarefa falhará e a exceção aparecerá nos logs de erro da tarefa.

P: O que acontece se uma tarefa não falha mas a verificação junto ao DynamoDB falha?

A tarefa falhará e a exceção aparecerá nos logs de erro da tarefa.

P: Como maximizo o throughput de leitura do stream do Kinesis para o EMR?

O throughput de leitura do stream do Kinesis aumenta de acordo com o tamanho da instância utilizada e o tamanho do registro no stream do Kinesis. Recomendamos que você utilize instâncias m1.xlarge ou superior para os nós mestre e principais desse recurso. 

P: O que é o Acordo de nível de serviço do Amazon EMR?

Consulte nosso Acordo de Nível de Serviço.

P: O que seu acordo de nível de serviço do Amazon EMR oferece?