Lista de verificação de lançamento do BigQuery

Introdução

Nesta lista de verificação de lançamento do BigQuery, você encontra as atividades recomendadas para o lançamento de um aplicativo comercial que use o Google BigQuery. Essa lista tem como foco as atividades específicas do BigQuery. Também é preciso usar a lista de verificação de lançamento do Google Cloud Platform para entender as atividades aplicáveis a todos os serviços que precisam ser concluídas.

Esta lista de verificação destina-se a desenvolvedores experientes do BigQuery. As instruções não ensinam a usar o BigQuery, caso você esteja começando agora.

Esta lista é dividida nas seguintes seções:

  • Design e desenvolvimento de arquitetura
  • Lançamento restrito
  • Lançamento final

As seções são apresentadas na ordem recomendada para você utilizar à medida que se prepara para lançar o aplicativo. Por exemplo, comece pela lista de verificação de design e desenvolvimento da arquitetura. Ela contém atividades recomendadas para o início do ciclo de desenvolvimento do aplicativo. Da mesma forma, a lista de verificação de lançamento restrito contém atividades recomendadas para quando o lançamento estiver próximo. No entanto, o cronograma exato das atividades da lista de verificação e o tempo necessário dependem do prazo de desenvolvimento do aplicativo.

Lista de verificação de design e desenvolvimento de arquitetura

Recomendamos que você use esta lista de verificação nos estágios iniciais do desenvolvimento do aplicativo. As atividades dessa lista podem ser feitas em paralelo nos grupos. No entanto, recomendamos que você inicie as atividades relacionadas à arquitetura do software o mais cedo possível, pois elas exigem mais tempo para serem concluídas.

Atividade
Comunidade/grupos/fóruns
❑  
Consulte o suporte da comunidade do Google BigQuery no Stack Overflow. É uma ótima fonte de informações e conselhos práticos.
❑  
Inscreva-se no grupo Google BigQuery - Announce.
Design do esquema
❑  
Faça o design do esquema com base na necessidade de consulta. No BigQuery, há suporte para campos aninhados e repetidos (tipo: RECORD), o que permite relações lógicas de 1 a vários em uma tabela desnormalizada. Aproveite esse recurso quando apropriado, mantendo uma estratégia para acessar esses campos. Considere a criação de visualizações lógicas para o desaninhamento comum de campos repetidos. Estime o custo da consulta.
❑  
Consultar campos repetidos após o primeiro ou segundo nível de aninhamento pode ser complexo. Portanto, considere a profundidade ideal do aninhamento de acordo com o uso.
❑  
As junções têm boa execução no BigQuery, mas a desnormalização pode melhorar o desempenho de algumas consultas. Considere onde as junções são importantes no seu modelo de dados.
❑  
O BigQuery permite tabelas anexadas ou atualizadas via DML. O DML é destinado para atualizações em massa, exclusões e inserções, em vez de modificações de linha única. Certifique-se de que os padrões de atualização sejam consistentes com um sistema OLAP.
❑  
Ao contrário de um RDBMS tradicional, não há o conceito de chaves primárias/secundárias ou ID de linha. Se necessário, identifique uma coluna no esquema da tabela para esse fim.
Estimativa de volume de dados
❑  
Calcule o volume de dados do upload inicial para chegar a um nível básico.
❑  
Calcule o volume de dados de upload incremental e defina a velocidade (por hora, dia ou semana).
❑  
Calcule o volume de dados que expira, se houver, e com que frequência.
Estimativa do processamento de consultas
❑  
Identifique os tipos de consultas que serão executados nos conjuntos de dados do BigQuery todos os dias. O monitoramento do Stackdriver fornece diagnósticos úteis sobre utilização de recursos, consultas simultâneas e tamanhos de conjuntos de dados.
❑  
Estabeleça uma estratégia de particionamento/fragmentação de tabelas. Por exemplo, se as consultas emitidas durante o dia forem relevantes para os dados coletados nesse período, crie uma tabela por dia. Para agregar dados por vários dias, execute as consultas usando caracteres curinga de tabela ou a pseudocoluna \_PARTITIONTIME.
❑  
Calcule o volume de dados a serem processados pelo BigQuery diariamente, ou seja, o número de consultas x dados por consulta. Observe que, o que é cobrado é o processamento das colunas individuais, não toda a linha. Considere isso nos cálculos. Note também que, quando houver uma referência a uma coluna na consulta, essa coluna inteira será verificada.
Gerenciamento de cotas
❑  
Entenda as cotas padrão do BigQuery.
❑  
Faça uma análise de cotas nas seguintes áreas, sempre que aplicável:
  • o número de jobs de carregamento por dia necessários para carregar dados no BigQuery
  • o número de jobs de carregamento por tabela, por dia, no BigQuery
  • se você estiver usando uma API de streaming, o número de inserções de streaming, o tamanho da linha nas inserções, o máximo de linhas por segundo, o máximo de linhas por solicitação e outros parâmetros específicos dessa API.
  • o número de consultas emitidas pelo aplicativo para o BigQuery
  • o número de sessões simultâneas usadas para executar consultas simultaneamente
  • o número de jobs de exportação executados por dia para extrair dados do BigQuery
  • Limites da API por taxa e por dia para invocar operações do BigQuery. Para mais informações, consulte Limites de taxa da API.
❑  
Se a cota for insuficiente, solicite ajustes de cota por meio do GWSC.
Análise de custo
❑  
Com base na estimativa de volume de dados e no processamento de consultas, calcule o custo de armazenamento e processamento do BigQuery usando os preços do BigQuery e/ou a calculadora de preços.
❑  
Considere as seguintes recomendações de otimização de custos:
  • Selecione apenas colunas relevantes nas consultas. Note que, no BigQuery, uma verificação da coluna inteira selecionada é executada e cobrada, independentemente dos filtros da cláusula where.
  • Particione/fragmente as suas tabelas em unidades menores para otimizar o custo de processamento. Geralmente, há um dilema entre otimização e desempenho. Se você tiver muitas tabelas pequenas, ocorrerá uma sobrecarga fixa no carregamento de cada tabela consultada, o que poderá afetar o desempenho.
  • Teste as consultas em partições menores da tabela em vez de uma grande tabela.
  • Se estiver usando a API, valide a sintaxe das consultas e veja estatísticas de processamento de dados usando a sinalização dryRun.
  • Exclua tabelas mais antigas se não forem necessárias para consulta ou use expirationTime nas tabelas.
Segurança
❑  
Revise cuidadosamente as políticas do IAM para BigQuery para garantir que o acesso ao conjunto de dados e as permissões de execução de jobs estejam corretos. Pontos a considerar:
  • Verifique as permissões do BigQuery para os membros do projeto para garantir que suas políticas de segurança sejam seguidas. O papel bigquery.User permite que os usuários executem jobs no projeto. Já o papel dataset.Viewer controla a capacidade de ler todas as tabelas em um determinado conjunto de dados. Os papéis dataset.Editor e dataset.Owner só podem ser concedidos se o usuário precisar modificar tabelas ou conjuntos de dados, respectivamente.
  • Caso haja a necessidade de compartilhar conjuntos de dados específicos com os membros da equipe, use o compartilhamento de conjunto ou funções do IAM.
  • Se precisar de uma segurança mais granular, considere o uso de Visualizações Autorizadas para controlar o acesso.
Como pré-processar os dados anteriores ao BigQuery
❑  
Considere pré-processar os dados antes de carregá-los no BigQuery para otimizar o custo e o desempenho. Por exemplo, faça o seguinte:
  • Pré-processe as conversões de tipo e os cálculos.
  • Faça previamente as junções frequentes.
  • Agregue previamente as métricas e as análises executadas frequentemente.
❑  
Faça o pré-processamento dos dados (transformar, desnormalizar etc.) usando o próprio BigQuery, o Google Cloud Dataflow, o Google Cloud Dataproc ou as ferramentas ETL.
❑  
Considere múltiplas versões do mesmo conjunto de dados estruturadas de maneira diferente para diferentes tipos de consultas.
❑  
Como há um limite diário para instruções DML por tabela, planeje atualizações/exclusões por meio de modificações ou lotes programados.
Ajuste de consulta e teste
❑  
Teste as consultas no volume de dados esperado e ajuste-as de acordo com os seguintes princípios:
  • Omita colunas desnecessárias da cláusula select para reduzir custos e melhorar o desempenho.
  • No contexto das consultas aninhadas, use as cláusulas where de forma eficiente para filtrar dados nas consultas mais internas. Desse modo, as consultas externas terão menos dados para processar.
  • Coloque o nivelamento o máximo possível para o interior e use cláusulas WHERE em conjunto, se possível.
  • Mova os filtros mais pesados, como regexp, para o final.
  • Evite agrupamento em strings e quando os dados originais equivalentes estiverem disponíveis, use carimbos de data/hora em vez de strings.
  • Tente usar ORDER BY e LIMIT nas consultas externas. Evite ORDER BY nas consultas internas o máximo possível.
  • Observe que usar GROUP BY ao lidar com grupos distorcidos (grandes) pode resultar em aumento da latência de cauda. Filtre-os para melhorar o desempenho da consulta.
  • Considere usar IF/CASE ou funções SQL analíticas em vez de junções automáticas, já que elas têm uma sobrecarga de processamento mais baixa.
Visualização de dados
❑  
O BigQuery é uma ferramenta para consultar dados em grandes conjuntos de dados. Para a visualização de dados, há uma conectividade sólida com ferramentas de terceiros:
  • Google Data Studio
  • ferramentas de produtividade como Planilhas Google e Microsoft Excel
  • ferramentas comerciais como Tableau, BIME, Informatica
  • Alternativas de código aberto como redash

Lista de verificação de lançamento restrito

Antes do lançamento comercial do aplicativo, recomendamos usar as atividades da lista de verificação de lançamento restrito para testar se está tudo pronto para o lançamento.

Atividade
❑  
Se você estiver usando uma API de streaming para carregar dados, faça um teste para simular o carregamento e garantir que não haja violações de cota.
❑  
Se você estiver usando jobs em lote para carregar dados, faça um teste para simular o carregamento e garantir que isso ocorra em tempo razoável no BigQuery e que não haja violações de cota.
❑  
Avalie o seu modelo de custo em relação aos custos reais. Verifique se os custos operacionais estão dentro do orçamento. Avalie o seu modelo de custo. Mesmo que a calculadora de preços do Google Cloud Platform permita estimativas razoáveis, não é possível saber o volume exato de dados processados durante um dia até o teste de carregamento.

Lista de verificação de lançamento final

Use a lista de verificação de lançamento final um pouco antes e durante o lançamento.

Atividade
❑  
Se você seguiu a lista de verificação até este ponto, o aplicativo está pronto para um lançamento bem-sucedido no Google BigQuery. Parabéns! Recomendamos que você consulte também a lista de verificação de lançamento final nesta seção.
Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…

Precisa de ajuda? Acesse nossa página de suporte.