Google Cloud para profissionais do AWS: Big Data

Atualizado em 30 de outubro de 2019

Neste artigo, comparamos os serviços de Big Data fornecidos pelo Amazon Web Services (AWS) com os serviços fornecidos pelo Google por meio do Google Cloud.

O artigo aborda os seguintes tipos de serviço:

  • Serviços de ingestão, que são utilizados para ingerir dados de um ambiente de origem para um tipo de dados ou ambiente de destino confiável e estável.
  • Serviços de transformação e preparação, que permitem filtrar, extrair e transformar dados de um tipo ou modelo de dados para outro.
  • Serviços de armazenamento e análise, que permitem armazenar, analisar, visualizar e interagir com os dados processados.

Serviços de ingestão

Esta seção compara maneiras de ingerir dados no AWS e no Google Cloud.

Conectividade

Para algumas migrações iniciais e, especialmente, para o processamento contínuo de dados, você normalmente usa uma conexão de rede com grande largura de banda entre sua nuvem de destino e outra rede. A tabela a seguir resume as opções de conectividade do AWS e do Google Cloud.

Recurso AWS Google Cloud
Rede privada virtual Site-to-Site VPN Cloud VPN
Conectividade privada com uma VPC Direct Connect Interconexão dedicada
Interconexão por parceiro
Conectividade de alta velocidade com outros serviços de nuvem Direct Connect Peering direto
Peering por operadora

Para mais informações sobre as opções do Google Cloud, consulte a seção Conectividade particular com outras redes em Google Cloud para profissionais do AWS: Rede.

Ingestão de stream

É possível usar o Amazon Kinesis Data Streams e o Google Pub/Sub para processar fluxos de dados nos respectivos ambientes de nuvem. No entanto, cada serviço realiza essa tarefa usando modelos de serviço diferentes.

Comparação do modelo de serviço

A tabela a seguir compara recursos do Amazon Kinesis Data Streams e do Pub/Sub.

Recurso Amazon Kinesis Data Streams Pub/Sub
Unidade de implantação Stream Tópico
Unidade de provisionamento Fragmento N/A (totalmente gerenciado)
Unidade de dados Registro Mensagem
Fonte de dados Produtor Editor
Destino dos dados Consumidor Inscrito
Particionamento de dados Chave de partição fornecida pelo usuário N/A (totalmente gerenciado)
Tempo de retenção Até sete dias Até sete dias
Ordem de entrega de dados Chave de sequência fornecida pelo serviço (melhor esforço) Tempo de publicação fornecido pelo serviço (melhor esforço)
Tamanho máximo dos dados 1 MB 10 MB
Localidade da implantação Por região Global
Modelo de preços Por hora de fragmento, unidades de payload PUT e retenção opcional de dados Ingestão e entrega de mensagens e retenção opcional de mensagens
Amazon Kinesis Data Streams

O Amazon Kinesis Data Streams usa um modelo de streaming para processar dados. Nesse modelo, os produtores enviam dados a um stream que você cria e provisiona por fragmento. Cada fragmento em um stream pode fornecer no máximo 1 MiB/s de largura de banda de entrada e 1.000 dados por segundo.

Os usuários enviam dados para o Amazon Kinesis Data Streams usando a API REST de nível inferior ou a biblioteca Kinesis Producer Library (KPL) de nível superior. Esses dados são armazenados em registros de dados que consistem em:

  • um número de sequência incremental
  • uma chave de partição fornecida pelo usuário
  • um blob de dados

A chave de partição é usada para balancear a carga dos registros entre os fragmentos disponíveis. Por padrão, os registros são mantidos por 24 horas. No entanto, os usuários podem aumentar esse período de retenção até no máximo sete dias.

O usuário configura um aplicativo de consumidor que recupera os registros de dados do stream em uma base por fragmento e, em seguida, os processa. O aplicativo é responsável pela multiplexação entre os fragmentos disponíveis. Incorporar a biblioteca de cliente do Amazon Kinesis ao seu aplicativo simplifica essa multiplexação entre os fragmentos e também gerencia o balanceamento de carga e o gerenciamento de falhas em todo o cluster dos nós de aplicativos de consumidor.

Pub/Sub

O Pub/Sub apresenta um serviço de mensagens que usa um modelo de editor/assinante. Depois de criar um tópico do Pub/Sub, você pode publicar dados para ele, e cada aplicativo inscrito nele pode recuperar os dados ingeridos a partir do tópico. Essa abordagem elimina a necessidade de definir uma capacidade específica, como o número de fragmentos.

Cada aplicativo registrado no Pub/Sub pode recuperar mensagens usando um modelo push ou pull:

  • No modelo push, o servidor Pub/Sub envia uma solicitação ao aplicativo do assinante em um endpoint de URL pré-configurado.
  • No modelo pull, o aplicativo do assinante solicita mensagens do servidor e, em seguida, confirma a recepção quando as mensagens chegam. Os assinantes de pull podem recuperar mensagens de maneira assíncrona ou síncrona.

Cada mensagem de dados publicada em um tópico precisa ser codificada em base64 e não pode ter mais que 10 MB. No momento do processamento, o Pub/Sub adiciona um atributo messageId e um atributo publishTime a cada mensagem de dados. O atributo messageId é um ID de mensagem exclusivo no tópico, e o atributo publishTime é um carimbo de data/hora adicionado pelo sistema no momento do processamento de dados. Os editores podem adicionar atributos aos dados no formato de pares de chave-valor.

Ordem dos dados

Nesta seção, descrevemos como o Amazon Kinesis Data Streams e o Pub/Sub gerenciam o ordenamento dos dados solicitados por um aplicativo de consumidor ou assinante.

Amazon Kinesis Data Streams

Por padrão, o Amazon Kinesis Data Streams mantém a ordem dos dados por meio do uso da chave de partição e do número de sequência. Quando um produtor adiciona um registro a um stream, fornece uma chave de partição que determina o fragmento ao qual o registro será enviado. O fragmento adiciona um número de sequência incremental ao registro e, em seguida, armazena o registro de maneira confiável.

Os aplicativos do consumidor solicitam registros por fragmento e recebem os registros por ordem de número de sequência. Esse modelo garante a ordenação por fragmento, mas ela não é garantida quando o aplicativo do consumidor faz solicitações entre fragmentos. Além disso, um registro pode ser entregue a um consumidor mais de uma vez, de modo que o aplicativo precisa aplicar semântica para exatamente uma vez. Para mais informações, consulte Como lidar com registros duplicados na documentação do Amazon Kinesis Data Streams.

Pub/Sub

O Pub/Sub entrega mensagens com base no melhor esforço, usando o atributo publishTime fornecido pelo sistema para entregar mensagens na ordem em que elas foram publicadas. O Pub/Sub não garante uma única exibição ou entrega em ordem: ocasionalmente, uma mensagem pode ser entregue mais de uma vez e fora de ordem. Seu assinante precisa ser idempotente ao processar mensagens e, se necessário, precisa ser capaz de lidar com mensagens que são recebidas fora de ordem.

Você pode conseguir uma ordem mais rígida usando números de sequência fornecidos pelo aplicativo e armazenando mensagens consumidas em buffer. Se o objetivo final de seus dados for um serviço de armazenamento persistente que ofereça suporte a consultas baseadas em tempo, como Firestore ou BigQuery, também será possível visualizar dados em uma ordem estrita, classificando suas consultas por carimbo de data/hora. Se seu objetivo for o Dataflow, você poderá usar IDs de registro para estabelecer um processamento único.

Operações

Nesta seção, examinamos a sobrecarga operacional e de manutenção para as cargas de trabalho de produção em cada serviço.

Amazon Kinesis Data Streams

Como os usuários do Amazon Kinesis Data Streams precisam escalonar os fragmentos para mais ou para menos manualmente, talvez seja preciso monitorar o uso com o Amazon CloudWatch e modificar a escala conforme necessário. Esse processo de escalonamento é chamado de refragmentação e só pode ser feito fragmento por fragmento. A refragmentação é compatível com duas operações: um fragmento pode ser dividido em dois, ou dois fragmentos podem ser fundidos em um único. Assim, a duplicação da capacidade de N fragmentos requer N operações individuais de divisão de fragmentos.

Por conta da natureza fixa dos fragmentos, considere a capacidade de cada fragmento individualmente no seu design. Por exemplo, se você escolher uma chave de partição que direcionaria um pico de tráfego para um único fragmento, esse pico pode sobrecarregar a capacidade de processamento de um fragmento. Esse problema provavelmente não poderá ser evitado no futuro simplesmente pela refragmentação. Em casos como esse, a única maneira de resolver permanentemente o problema é reprojetar o aplicativo com uma chave de partição diferente.

É possível evitar o gerenciamento de fragmentos do Kinesis Data Streams usando o Kinesis Data Firehose. O Kinesis Data Firehose automatiza o gerenciamento, o monitoramento e o escalonamento de streams do Kinesis para um caso de uso específico: agregar dados de um stream para o Amazon S3 ou o Amazon Redshift. Os usuários especificam um cluster do S3 ou do Redshift, e o Kinesis Firehose cria e gerencia um stream em nome do usuário, depositando os dados em intervalos especificados no local especificado.

O Amazon Kinesis é um serviço regional, com streams restritos a regiões específicas. Como tal, todos os dados ingeridos precisam seguir até a região em que o stream é definido.

Pub/Sub

O Pub/Sub não requer provisionamento e lida com fragmentação, replicação e dimensionamento para você.

Além disso, você não precisa usar chaves de partição. O Pub/Sub gerencia o particionamento de dados para você. Embora esses recursos reduzam consideravelmente a sobrecarga de gerenciamento, eles também significam que o Pub/Sub pode fazer menos garantias sobre a ordenação das mensagens.

O Pub/Sub usa o balanceador de carga HTTP(S) do Google para fazer a ingestão de dados globalmente em todas as regiões do Google Cloud. Quando um editor publica dados no Pub/Sub, o balanceador de carga HTTP(S) do Google direciona automaticamente o tráfego para servidores Pub/Sub em uma região apropriada para minimizar a latência.

Custos

O Amazon Kinesis Data Streams tem o preço calculado por hora do fragmento, volume de dados e período de retenção de dados. Por padrão, os dados são mantidos por 24 horas. O aumento do período de retenção gera custos adicionais. Como o Amazon Kinesis Data Streams usa um modelo provisionado, é preciso pagar pelos recursos provisionados mesmo se não usá-los.

O Amazon Kinesis Data Firehose é cobrado pelo volume de dados.

O Pub/Sub tem o preço calculado por volume de dados. Como o Pub/Sub não exige o provisionamento de recursos, você paga apenas pelos recursos que consome.

Ingestão em massa

Tanto o AWS Snowball quanto o Google Transfer Appliance podem ser usados para processar dados em massa nos respectivos ambientes de nuvem.

O AWS Snowball é oferecido em versões de 50 TB (somente para a América do Norte) e 80 TB. O Transfer Appliance é oferecido em uma versão de 100 TB, conhecida como TA100, e uma versão de 480 TB, conhecida como TA480.

Comparação resumida

Na tabela a seguir, comparamos os recursos do AWS Snowball e do Google Transfer Appliance.

Recurso AWS Snowball Transfer Appliance
Capacidade por unidade 50 TB ou 80 TB 100 TB ou 480 TB
Taxa de transferência máxima 10 Gbps 20 Gbps para o TA100
40 Gbps para o TA480
Ambos oferecem agregação automática de links
Atualizações de status por e-mail? Não Sim
É possível montar em rack? Não Sim para o TA100
Não para o TA480
Taxa de uso US$ 200 para 50 TB
US$ 250 para 80 TB
US$ 300 para o TA100
US$ 1800 para o TA480
Taxa diária US$ 15/dia após 10 dias US$ 30/dia após 10 dias para o TA100
US$ 90/dia após 25 dias para o TA480
Modos de transferência Push Push ou pull
Transferir dados do armazenamento de objetos? Sim Não

Operações

Os dois serviços têm um fluxo de trabalho semelhante (recebimento, configuração, transferência de dados, envio de volta), mas existem algumas diferenças importantes na maneira como você os configura e carrega dados neles.

O AWS Snowball não pode ser montado em rack. Em vez disso, ele precisa ser independente, semelhante a um gabinete de PC ATX. O modelo TA100 do Transfer Appliance é fornecido em um formato de montagem em rack 2U para uso em data centers. O modelo TA480 é fornecido em uma caixa própria com rodízios. Não é possível montá-lo em rack.

Talvez o maior contraste entre o AWS Snowball e o Transfer Appliance esteja na capacidade de rede. Ambos têm suporte para 1 Gbps ou 10 Gbps usando uma conexão RJ-45 e 10 Gbps usando uma conexão de fibra óptica. No entanto, os dois modelos do Transfer Appliance oferecem quatro portas ethernet de 10 Gbps com agregação de links com balanceamento de carga adaptável, possibilitando uma capacidade de vários streams muito maior do que apenas 10 Gbps.

O Snowball é configurado usando uma tela de toque de papel eletrônico. O Transfer Appliance requer um monitor VGA e um teclado USB para acessar o console, a partir do qual um console da Web é configurado. A partir daí, você realiza toda a administração remotamente usando um navegador da Web.

Para receber dados no dispositivo, tanto o Snowball quanto o Transfer Appliance oferecem modelos de push de cliente da estação de trabalho. O Snowball também oferece push da API Amazon S3. O Transfer Appliance oferece os modos de transferência NFS Pull (onde atua como um cliente NFS) e NFS Push (onde atua como um servidor NFS).

Tanto para o Snowball quanto para o Transfer Appliance, você devolve o dispositivo por meio de uma transportadora.

Por fim, quando seus dados são carregados no armazenamento de objetos, há uma diferença importante entre os dispositivos do AWS e do Google. Para o Snowball, a descriptografia dos dados do dispositivo é incluída no serviço. Os clientes do Appliance do Transfer precisam usar um dispositivo virtual de reidratação do Compute Engine para descriptografar os dados do dispositivo. O preço normal da VM do Compute Engine é aplicável às instâncias do reidratador.

Transferência do armazenamento de objetos

Como você pode considerar mover cargas de trabalho de Big Data do AWS para o Google Cloud, o Serviço de transferência do Storage do Google pode ser útil para você. Você pode usar o Storage Transfer Service para criar tarefas únicas ou recorrentes para copiar dados dos buckets do Amazon S3 para os buckets do Google Cloud Storage. Outras fontes de dados também são aceitas.

Transformação e preparação

Depois de ter ingerido os dados no ambiente de nuvem, você pode transformá-los, filtrá-los e processá-los conforme o necessário.

Este documento abrange três categorias de serviços para realizar esse trabalho: ETL parcialmente gerenciado, ETL totalmente gerenciado e transformação de stream.

ETL parcialmente gerenciado

Uma abordagem comum para tarefas de transformação de dados é usar ferramentas baseadas em Apache-Hadoop, que normalmente oferecem processamento em lotes flexível e escalável. O Google Cloud e o AWS oferecem serviços gerenciados do Hadoop. No Google Dataproc e no Amazon Elastic MapReduce (EMR), são oferecidos configuração e provisionamento automáticos, gerenciamento de jobs simples, monitoramento sofisticado, além de preços flexíveis. Para dados baseados em stream, tanto o Dataproc quanto o Amazon EMR são compatíveis com o Apache Spark Streaming.

Além disso, o Google Cloud oferece o Dataflow, que é baseado no Apache Beam em vez de no Hadoop. Enquanto o Apache Spark Streaming trata os dados de streaming como pequenos jobs em lote, o Dataflow é um mecanismo nativo de processamento focado em stream.

Comparação do modelo de serviço

Veja na tabela a seguir uma comparação dos recursos do Amazon EMR, Dataproc e Dataflow.

Recurso Amazon Elastic MapReduce Google Dataproc Google Dataflow
Biblioteca de código aberto Apache Hadoop e Apache Spark Apache Hadoop e Apache Spark Apache Beam
Escalonamento Manual ou automático Manual ou automático Manual ou automático
Unidade de implantação Cluster Cluster Canal
Unidade de escala Nós (mestre, núcleo e tarefa) Nós (mestre e worker) Workers
Unidade de trabalho Etapa Job Job
Modelo de programação MapReduce, Apache Hive, Pig, Flink, Spark, Spark SQL, PySpark MapReduce, Apache Hive, Pig, Flink, Spark, Spark SQL, PySpark Apache Beam
Dataproc e Amazon EMR

O Dataproc e o Amazon EMR têm modelos de serviço semelhantes. Cada um deles é uma plataforma escalável para filtragem e agregação de dados e está bastante integrado com as ferramentas e os serviços de Big Data do Apache, incluindo Apache Hadoop, Apache Spark, Apache Hive e Apache Pig.

No Dataproc e no Amazon EMR, você cria um cluster que consiste em vários nós. O serviço cria um único nó mestre e um número variável de nós de trabalho. O Amazon EMR ainda classifica os nós de trabalho em nós de núcleo e de tarefa.

Depois que um cluster é provisionado, o usuário envia um aplicativo chamado de job no Dataproc e no Amazon EMR para execução por parte do cluster. Dependências de aplicativo são normalmente adicionadas pelo usuário aos nós do cluster usando scripts de Bash personalizados chamados ações de inicialização no Dataproc e ações de inicialização no Amazon EMR. Os aplicativos normalmente leem dados de armazenamento estável, como Amazon S3, Cloud Storage ou HDFS, e processam os dados usando um serviço ou ferramenta de processamento de dados do Apache. Após terem sido processados, os dados resultantes podem ser posteriormente processados ou enviados de volta ao armazenamento estável.

Dataflow

O Dataflow usa o modelo de programação do Apache Beam para executar processamentos em lote e de stream. Esse modelo oferece maior flexibilidade e expressividade quando comparado ao modelo do Apache Spark usado pelo Amazon EMR e pelo Dataproc, particularmente para processamento de dados em tempo real.

No Dataflow, você especifica um pipeline abstrato, usando uma biblioteca de SDK do Dataflow para fornecer os elementos primitivos para processamento paralelo e para agregação. Ao especificar um pipeline, o usuário define um conjunto de transformações que são enviadas para execução no pipeline. Essas transformações são, por sua vez, mapeadas para um conjunto de nós de trabalho provisionados e configurados para execução pelo Dataflow. Alguns nós podem ser usados para ler dados do Pub/Sub, e outros podem executar outras transformações downstream. Os detalhes são gerenciados pelo tempo de execução do Dataflow.

The Dataflow model, SDKs, and pipeline runners have been accepted into the Apache open source incubator as Apache Beam. Esse desenvolvimento significa que os aplicativos do Dataflow também podem ser executados em um cluster Flink ou Spark ou em um ambiente de desenvolvimento local.

Para ver uma comparação detalhada dos modelos de programação Apache Beam e Apache Spark, consulte Dataflow/Beam e Spark: uma comparação entre modelos de programação.

Escalonamento

Nesta seção, discutimos como gerenciar o escalonamento com o Amazon EMR, o Dataproc e o Dataflow.

Dataproc e Amazon EMR

O Amazon EMR e o Dataproc permitem ajustar manual ou automaticamente o número de nós em um cluster depois que ele é iniciado. Para o escalonamento manual, é possível determinar o tamanho do cluster, bem como as ações de escalonamento, monitorando o desempenho e o uso do cluster para decidir como gerenciá-lo. Em ambos os serviços, os usuários pagam pelo número de nós provisionados.

Dataflow

Com o Dataflow, o escalonamento automático é ativado por padrão. O sistema de tempo de execução do Dataflow faz a escalonabilidade automática dos nós, gerenciando ativamente o provisionamento e a alocação de nós para diferentes partes do pipeline canal conforme necessário. Também é possível gerenciar o escalonamento manualmente.

Custos

Nesta seção, discutimos como os custos são avaliados para o Amazon EMR, o Dataproc e o Dataflow.

Amazon EMR e Dataproc

Tanto o Amazon EMR quanto o Dataproc têm preços sob demanda, além de descontos para uso de curto e longo prazo. Ambos os serviços são cobrados por segundo. Para reduzir o custo dos nós, os usuários do Amazon EMR podem pré-comprar instâncias reservadas. O Dataproc fornece descontos por uso prolongado automaticamente.

Além disso, cada serviço oferece opções para a compra de capacidade excedente de computação com desconto. O Amazon EMR é compatível com o provisionamento de nós usando as instâncias Spot do Amazon EC2, em que a capacidade não utilizada é leiloada para os usuários em incrementos de curto prazo. Esses nós podem ser recuperados pelo EC2, mas o cluster continua o processamento à medida que os nós são adicionados ou removidos. Da mesma maneira, o Dataproc é compatível com VMs preemptivas que podem ser recuperadas a qualquer momento. VMs preemptivas não são leiloadas em um mercado. Em vez disso, elas oferecem um desconto fixo por hora para cada tipo de máquina do Compute Engine.

Para ver uma comparação detalhada dos preços gerenciados do Hadoop para ambientes de nuvem comuns, incluindo o Google Cloud e o AWS, consulte Noções básicas dos preços do Cloud: mecanismos de processamento de Big Data.

Dataflow

O Dataflow tem o preço fixado por hora, dependendo do tipo de trabalho. Para mais informações, consulte Preços do Dataflow.

ETL totalmente gerenciado

O AWS e o Google Cloud têm ofertas que reduzem o trabalho de configuração das transformações automatizando partes significativas do trabalho e gerando pipelines de transformação.

No AWS, você pode usar o AWS Glue, um serviço totalmente gerenciado do AWS que combina as preocupações de um catálogo de dados e preparação de dados em um único serviço. O AWS Glue usa rastreadores definidos pelo usuário que automatizam o processo de preenchimento do catálogo de dados do AWS Glue a partir de várias origens de dados. Depois que o catálogo de dados for preenchido, você poderá definir um job do AWS Glue. A criação do job gera um script em Python ou Scala compatível com o Apache Spark, que você pode personalizar. Os jobs do AWS Glue podem ser executados com base em programações baseadas em tempo ou podem ser iniciados por eventos.

O Google Dataprep é um serviço totalmente gerenciado operado pela Trifacta e é facilmente integrado aos seus projetos e dados do Cloud. É possível usar o Dataprep para explorar e limpar os dados identificados para análise posterior. Seus dados podem ser estruturados ou não e podem ser provenientes do Google Cloud Storage, do BigQuery ou de um arquivo enviado. O trabalho é organizado em torno de fluxos, que representam um ou mais conjuntos de dados de origem, transformações e conjuntos de dados preparados. O Dataprep oferece uma GUI para descobrir informações e planejar um fluxo de transformação. Essas transformações são especificadas na linguagem do domínio Wrangle e podem ser determinadas manualmente, bem como por meio da GUI. Seu fluxo é executado no Dataflow totalmente gerenciado para realizar transformações.

Transformação de stream

Há vários serviços no AWS e no Google Cloud que podem ser usados para transformar streams de dados.

Dataproc e Amazon EMR

O Amazon EMR implementa nativamente um modelo de streaming de dados ao auxiliar o Amazon Kinesis Data Streams como um método de ingestão de dados. Nesse modelo, o aplicativo lê os dados disponíveis armazenados no stream até que não haja novos dados disponíveis para algum valor de tempo. Quando todos os fragmentos ficarem vazios, a etapa de redução da operação será iniciada e os dados serão agregados. O Amazon EMR também é compatível com streaming de serviços de terceiros, como o Apache Kafka, por meio de uma implementação nativa do Apache Spark Streaming.

Embora o Dataproc não possa ler dados de streaming diretamente do Pub/Sub, o Apache Spark vem pré-instalado em todos os clusters do Dataproc. Isso permite que você use o Dataproc para ler dados de streaming do Apache Kafka. Além disso, é possível usar o Dataflow para ler e processar dados de streaming do Pub/Sub.

Google Dataflow e Amazon Kinesis Data Firehose

O Dataflow aceita o processamento de stream, além do processamento em lote, conforme descrito anteriormente. O mecanismo de streaming executa o Apache Beam, assim como ocorre em lote, e é possível aplicar uma transformação a origens em lote e em stream sem nenhuma alteração de código. O Pub/Sub é a única fonte de eventos usada com o Dataflow no modo de streaming, e o Pub/Sub processa mensagens de até 10 MB. Assim como as transformações em lote, as transformações de streaming do Dataflow são totalmente gerenciadas e escalonadas automaticamente, com escalonamento independente entre os componentes no pipeline de transformação.

O Amazon Kinesis Data Firehose pode realizar transformações de stream anexando uma função do AWS Lambda ao stream. A função pode processar uma entrada de 6 MB e retornar até 6 MB de dados. É possível espelhar essa abordagem no Google Cloud usando o Pub/Sub e o Cloud Functions.

Armazenamento e análise

Depois de ingerir e transformar os dados, você pode executar uma análise dos dados e criar visualizações a partir deles. Normalmente, os dados prontos para análise acabam em um destes dois locais:

  • um serviço de armazenamento de objetos, como o Amazon S3 ou o Google Cloud Storage;
  • um serviço de armazenamento de dados gerenciado, como o Amazon Redshift ou o Google BigQuery.

Armazenamentos de dados gerenciados

Nesta seção, nosso foco é o Amazon Redshift e o armazenamento nativo do Google BigQuery.

Comparação do modelo de serviço

A tabela a seguir compara os recursos do Amazon Redshift e do Google BigQuery.

Recurso Amazon Redshift Google BigQuery
Unidade de implantação Cluster N/D (totalmente gerenciado)
Unidade de provisionamento Node N/A (totalmente gerenciado)
Tipos de armazenamento de nós HDD/SSD N/A (totalmente gerenciado)
Escalonamento da computação Manual, com um máximo de 128 nós Ajustado automaticamente, sem limite
Escalonamento da consulta Até 50 consultas simultâneas em todas as filas definidas pelo usuário Até 1.000 consultas simultâneas
Escalonamento de tabelas Até 20.000 tabelas para tipos de nós grandes Sem limite. O desempenho é inferior a 50.000 tabelas por conjunto de dados. Conjuntos de dados ilimitados.
Gerenciamento de backups Instantâneos N/D (totalmente gerenciado)
Localidade da implantação Zona Regional
Modelo de preços Por hora Por volume de consulta e armazenamento
Linguagem da consulta Compatível com PostgreSQL SQL legado do BigQuery ou SQL padrão
Aprendizado de máquina integrado? Não Sim
Amazon Redshift

O Amazon Redshift usa uma arquitetura de processamento paralelo em um cluster de nodes provisionados para fornecer execução de SQL de alto desempenho. Quando você usa o Amazon Redshift, os dados são armazenados em um banco de dados em colunas que é replicado automaticamente entre os nodes do cluster. Seus dados ficam dentro do cluster, por isso o cluster precisa ser mantido em execução para preservar os dados. No entanto, você pode exportar seus dados do Amazon Redshift para o Amazon S3 e recarregá-los em um cluster do Amazon Redshift para consultas posteriores. Uma extensão do Amazon Redshift, o Spectrum, fornece uma alternativa que permite consultar diretamente os dados armazenados em formatos compatíveis no Amazon S3.

Como observado, o Amazon Redshift usa um modelo provisionado. Nesse modelo, você seleciona um tipo de instância e provisiona um número específico de nós de acordo com suas necessidades. Depois de concluir o provisionamento, você pode se conectar ao cluster e, em seguida, carregar e consultar seus dados usando o conector compatível com PostgreSQL da sua escolha.

O Amazon Redshift é um serviço parcialmente gerenciado. Se você quiser escalonar um cluster para mais ou menos, por exemplo, para reduzir custos durante períodos de baixa utilização ou para aumentar recursos durante períodos de uso intenso, faça isso manualmente. Além disso, o Amazon Redshift exige que você defina e gerencie chaves de distribuição e chaves de classificação, além de executar processos de limpeza e desfragmentação de dados manualmente.

Google BigQuery

O BigQuery é totalmente gerenciado. Não é preciso provisionar recursos. Em vez disso, você pode simplesmente enviar dados para o BigQuery e consultá-los. O BigQuery gerencia os recursos necessários e os escalona automaticamente conforme apropriado. O BigQuery também oferece suporte a consultas federadas, que podem incluir dados armazenados em formatos de código aberto no Cloud Storage ou no Google Drive, além de dados armazenados nativamente no Cloud Bigtable.

Nos bastidores, o BigQuery usa os mesmos serviços poderosos e de escala global que o Google usa internamente.

  • Ele armazena, criptografa e replica dados usando o Colossus, o sistema de arquivos distribuídos de última geração do Google.
  • Ele processa tarefas usando o Borg, o sistema de gerenciamento de clusters em grande escala do Google.
  • Ele executa consultas com o Dremel, o mecanismo de consulta interno do Google.

Para mais informações, consulte a postagem Por trás do BigQuery no blog do Google Cloud.

As tabelas do BigQuery são somente anexadas, com suporte para exclusões limitadas para corrigir erros. Os usuários podem executar consultas interativas e criar e executar jobs de consulta em lote. O BigQuery é compatível com duas linguagens de consulta:

  • SQL legado, que é um dialeto de SQL específico do BigQuery.
  • SQL padrão, que é compatível com o SQL 2011 padrão e inclui extensões para consulta a dados repetidos e aninhados.

Além disso, o BigQuery é compatível com a integração a diversos serviços de parceiros, conectores e ferramentas de terceiros para ingestão, análise, visualização e desenvolvimento.

Machine learning

O BigQuery inclui suporte nativo para aprendizado de máquina. O BigQuery ML oferece vários modelos para abordar questões comerciais comuns. Os exemplos incluem regressão linear para previsões de vendas e regressão logística binária para classificação, como se é provável que um cliente faça uma compra. É possível usar vários conjuntos de dados do BigQuery para treinamento e previsão de modelos.

Escalonar

O Amazon Redshift pode ser dimensionado de um único nó para um máximo de 32 ou 128 nós para diferentes tipos de nós. Usando os nós de armazenamento denso, o Redshift tem capacidade máxima de 2 PB de dados armazenados, incluindo dados replicados. Os mecanismos de ingestão e consulta do Amazon Redshift usam o mesmo pool de recursos, o que significa que o desempenho da consulta pode se degradar quando você carrega quantidades muito grandes de dados.

O Amazon Redshift Spectrum amplia essa capacidade. No entanto, ao usar o Redshift Spectrum, um cluster do Amazon Redshift precisa estar em execução para executar consultas nesses dados. As consultas são processadas entre duas camadas (Amazon Redshift e Redshift Spectrum), e você precisa criar consultas para usar cada camada com mais eficiência.

Em contrapartida, o BigQuery não tem limites práticos para o tamanho de um conjunto de dados armazenado. Os recursos de processamento são escalonados rapidamente, e o processamento propriamente dito é extremamente rápido. Com a API BigQuery, você pode processar milhões de linhas no BigQuery a cada segundo. Além disso, os recursos de ingestão são desacoplados dos recursos de consulta, portanto uma carga de ingestão não pode degradar o desempenho de uma carga de consulta. O BigQuery também pode realizar consultas de dados armazenados no Google Cloud Storage. Essas consultas federadas não exigem alterações na maneira como as consultas são escritas, os dados são apenas visualizados como uma outra tabela.

Operações

Nesta seção, comparamos as considerações operacionais do uso do Amazon Redshift e do Google BigQuery.

Amazon Redshift

O Amazon Redshift é parcialmente gerenciado, de modo que ele cuida de muitos dos detalhes operacionais necessários para ter um armazenamento de dados em execução. Esses detalhes incluem backups de dados, replicação de dados, gerenciamento de falhas e implantação e configuração de software. No entanto, vários detalhes operacionais continuam sendo sua responsabilidade, incluindo gerenciamento de desempenho, escalonamento e simultaneidade.

Para conseguir um bom desempenho, é preciso definir chaves de distribuição estáticas ao criar tabelas. Essas chaves de distribuição são então usadas pelo sistema para fragmentar os dados entre os nós de modo que as consultas possam ser executadas em paralelo. Como as chaves de distribuição podem ter um efeito significativo no desempenho da consulta, é preciso escolhê-las com cuidado. Depois que você define as chaves de distribuição, não será possível alterá-las. Para usar chaves diferentes, crie uma nova tabela com as novas chaves e copie os dados da tabela antiga.

Além disso, a Amazon recomenda que você realize a manutenção periódica para manter um desempenho de consulta consistente. As atualizações e exclusões não compactam automaticamente os dados no disco, o que pode levar a gargalos de desempenho. Para mais informações, consulte Como usar o comando vacuum em tabelas na documentação do Amazon Redshift.

No Amazon Redshift, você precisa gerenciar os usuários finais e os aplicativos com cuidado. Por exemplo, os usuários precisam ajustar o número de consultas simultâneas que realizam. Por padrão, o Amazon Redshift executa até cinco consultas simultâneas. Você pode aumentar o número de consultas simultâneas para até 50. No entanto, como os recursos são provisionados antecipadamente, à medida que você aumenta esse limite, o desempenho e a capacidade podem ser afetados. Para mais informações, consulte a seção Níveis de simultaneidade de Implementar o WLM manual na documentação do Amazon Redshift.

Também é preciso dimensionar o cluster para garantir a compatibilidade com o tamanho geral dos dados, o desempenho das consultas e o número de usuários simultâneos. Você pode escalonar o cluster para mais. No entanto, considerando o modelo provisionado, você paga pelo que provisiona, independentemente do uso.

Por fim, os clusters do Amazon Redshift são restritos a uma única zona por padrão. Para criar uma arquitetura multirregional altamente disponível do Amazon Redshift, é preciso criar clusters adicionais em outras zonas e, em seguida, criar um mecanismo para atingir a consistência entre clusters. Para mais informações, consulte a postagem Criação de clusters multi-AZ ou multirregionais do Amazon Redshift no blog de Big Data da Amazon.

Para ver detalhes sobre outras cotas e limites do Amazon Redshift, consulte Limites no Amazon Redshift.

BigQuery

O BigQuery é totalmente gerenciado, com pouca ou nenhuma sobrecarga operacional para o usuário:

  • O BigQuery lida com fragmentação automaticamente. Não é preciso criar e manter chaves de distribuição.
  • O BigQuery é um serviço sob demanda, não um provisionado. Não é preciso se preocupar com o subprovisionamento, que pode causar gargalos, ou provisionamento em excesso, que pode resultar em custos desnecessários.
  • O BigQuery oferece replicação de dados gerenciada e global. Você não precisa configurar e gerenciar várias implantações.
  • O BigQuery é compatível com até 50 consultas interativas simultâneas, sem efeito sobre o desempenho ou a capacidade.

Para detalhes sobre as cotas e os limites do BigQuery, consulte a página Política de cotas na documentação do BigQuery.

Custos

O Amazon Redshift tem dois tipos de preços: preços sob demanda e de instâncias reservadas. O preço é baseado no número e no tipo das instâncias provisionadas. Você pode conseguir taxas de desconto por meio da compra antecipada de instâncias reservadas. A Amazon oferece prazos de reserva de um e três anos. Para mais informações, consulte a página de preços do Amazon Redshift.

O BigQuery cobra pelo uso. O preço é baseado no tamanho do armazenamento de dados, no custo computacional de consultas e nas inserções de streaming. Se uma tabela não for atualizada por 90 dias consecutivos, o preço do armazenamento de dados cairá pela metade. As consultas são cobradas por terabyte de dados processados. O preço do BigQuery é calculado por programações sob demanda e de taxa fixa, o que pode resultar em economias significativas para cargas de trabalho previsíveis. O BigQuery oferece uso gratuito significativo, até 20 GB de armazenamento e 1 TB de leituras de consulta por mês. Para mais informações, consulte a página de preços do BigQuery.

Armazenamentos de objetos

Os armazenamentos de objetos são outro mecanismo comum de armazenamento de Big Data. O Amazon S3 e o Google Cloud Storage são serviços de armazenamento de objetos totalmente gerenciados e comparáveis. Para uma discussão mais detalhada dos dois, consulte a seção sobre armazenamento de objetos distribuídos na documentação de comparação de armazenamento.

Para grandes quantidades de dados que você acessaria com pouca frequência, o Google Cloud Storage Coldline é uma boa escolha, comparável ao armazenamento do Amazon Glacier. Para uma discussão detalhada sobre os dois, consulte Google Cloud para profissionais do AWS: Storage.

Análise no armazenamento de objetos

O foco desta seção é a compatibilidade do Amazon Athena e do Google BigQuery com o armazenamento de objetos.

Modelo de serviço

O AWS Athena é um serviço de análise de armazenamento de objetos sem servidor. Ele permite executar consultas SQL em dados cujo esquema é definido no Amazon S3. As consultas federadas do BigQuery são comparáveis, aceitando dados do Google Cloud Storage, do Google Drive e do Bigtable.

Tanto o Athena quanto o BigQuery no Cloud Storage são totalmente gerenciados, incluindo o escalonamento automático, de modo que os modelos de serviço são semelhantes.

Escalonar

Em termos de escala de dados, o Amazon S3 e o Cloud Storage oferecem armazenamento em escala de exabytes. O Amazon S3 limita os buckets a 100 por conta. O Cloud Storage limita a criação de blocos a um bucket a cada dois segundos, mas não há limite para o número de blocos em um projeto, uma pasta ou uma organização.

Em termos de escala de consulta, o tempo limite das consultas do Athena é de 30 minutos, enquanto as consultas do BigQuery atingem o tempo limite após 6 horas. A Athena tem um limite flexível de até 20 consultas de DDL e 20 consultas de DML ao mesmo tempo. O BigQuery é compatível com até 50 consultas interativas simultâneas, sem efeito sobre o desempenho ou a capacidade. As consultas de simulação não contribuem para esse limite. É possível aumentar esse limite no nível do projeto.

As strings de consulta do Athena estão limitadas a 262.144 bytes. As consultas SQL legadas do BigQuery estão limitadas a 256 KB não resolvidos, enquanto as consultas SQL padrão estão limitadas a 1 MB não resolvidos. Após a resolução, que expande as visualizações e as tabelas curinga referenciadas pela consulta no tamanho geral da consulta, o limite para os dois dialetos SQL do BigQuery é de 12 MB.

Operações

Tanto o Athena quanto o BigQuery são totalmente gerenciados, com pouca ou nenhuma sobrecarga operacional para o usuário.

Custos

Para os custos de armazenamento, o Google Cloud Storage e o Amazon S3 são comparáveis, e a maior parte do custo é de transferências e de armazenamento. Os clientes do Cloud Storage que precisam de estabilidade de custos podem se inscrever no Storage Growth Plan para fazer com que os custos sejam iguais a cada mês.

Tanto o AWS Athena quanto o BigQuery (com o preço sob demanda) cobram US$ 5 por terabyte para consultas. No entanto, um terabyte é medido de maneira diferente entre os dois serviços. O Athena cobra em bytes lidos do Amazon S3, o que significa que as consultas de dados compactados custam menos do que as de dados descompactados. O BigQuery cobra os bytes processados, de modo que o custo é o mesmo, independentemente de onde e como os dados são armazenados.

Ambos os serviços têm um faturamento mínimo de 10 MB por consulta. Nenhum cobra taxas de serviço para consultas com falha, mas ambos os serviços cobram pelo trabalho realizado em consultas canceladas.

O Athena não tem um nível gratuito. O BigQuery oferece o primeiro 1 TB por mês gratuitamente, durante a vida útil da sua conta.

Visualização de dados

Se você usa o AWS QuickSight, poderá encontrar recursos comparáveis no Google Data Studio. A principal diferença é o preço. O Data Studio é gratuito, enquanto o QuickSight é cobrado por sessão. Além disso, o Data Studio é integrado ao G Suite para facilitar o compartilhamento na sua organização, assim como no Documentos, Planilhas e Apresentações.

Para ter mais controle, ou para trabalhos científicos, o Google também oferece o Colaboratory, um serviço gratuito e sem configuração que se integra ao BigQuery usando os notebooks do Jupyter.