Vista geral do esquema e da transferência de dados

Este documento aborda os conceitos e as tarefas para transferir o esquema e os dados do seu armazém de dados existente para o BigQuery.

A migração do seu armazém de dados para a nuvem é um processo complexo que requer planeamento, recursos e tempo. Para simplificar esta complexidade, deve abordar a migração do data warehouse de forma faseada e iterativa. Fazer várias iterações da migração de esquemas e dados pode melhorar o resultado.

Processo de migração de esquemas e dados

No início do seu percurso de migração, tem sistemas a montante que alimentam o seu armazém de dados existente e sistemas a jusante que usam esses dados em relatórios, painéis de controlo e como feeds para outros processos.

Este fluxo geral de dados suporta muitos exemplos de utilização de estatísticas, como mostrado no diagrama seguinte:

Estado inicial antes da migração.

O estado final do seu percurso é ter o maior número possível de exemplos de utilização em execução no BigQuery. Este estado permite-lhe minimizar a utilização do seu armazém de dados existente e, eventualmente, eliminá-lo. Tem controlo sobre os casos de utilização que são migrados e quando, dando-lhes prioridade durante a fase de preparação e descoberta da migração.

Transfira o esquema e os dados para o BigQuery

Na fase de planeamento da migração, identifica os exemplos de utilização que quer migrar. Em seguida, inicia as iterações de migração na fase de execução. Para gerir as suas iterações enquanto executa o ambiente de estatísticas com a mínima interrupção, siga este processo de alto nível:

  1. Transfira tabelas, configure e teste processos a jusante.

    • Transfira o grupo de tabelas para cada exemplo de utilização para o BigQuery sem alterações, através do Serviço de transferência de dados do BigQuery ou de outra ferramenta de ETL. Para obter informações sobre as ferramentas, consulte a secção Transferência de dados inicial.
    • Configure versões de teste dos seus processos a jusante para ler a partir das tabelas do BigQuery.

    Este passo inicial divide o fluxo de dados. O diagrama seguinte mostra o fluxo resultante. Alguns sistemas a jusante leem agora a partir do BigQuery, conforme mostrado nos fluxos etiquetados como B. Outros continuam a ler a partir do armazém de dados existente, conforme mostrado nos fluxos etiquetados como A.

    Os processos a montante alimentam o data warehouse existente. Alguns desses dados são enviados para processos a jusante, mas outros são enviados para o BigQuery através do Serviço de transferência de dados do BigQuery e, a partir daí, para diferentes processos a jusante.

  2. Configure alguns processos a montante de teste para escrever dados em tabelas do BigQuery em vez de (ou além do) armazém de dados existente.

    Após os testes, configure os processos de produção a montante e a jusante para escrever e ler nas tabelas do BigQuery. Estes processos podem ligar-se ao BigQuery através da API BigQuery e incorporar novos produtos na nuvem, como o Looker Studio e o Dataflow.

    Neste ponto, tem três fluxos de dados:

    1. Existente. Os dados e os processos permanecem inalterados e continuam centrados no seu data warehouse existente.
    2. Descarregado. Os processos a montante alimentam o seu armazém de dados existente, os dados são descarregados para o BigQuery e, em seguida, alimentam os processos a jusante.
    3. Totalmente migrado. Os processos a montante e a jusante já não escrevem nem leem do data warehouse existente.

      O diagrama seguinte mostra um sistema com todos estes três fluxos:

      Fluxo de cargas de trabalho através de vários caminhos.

  3. Selecione exemplos de utilização adicionais para a migração e, de seguida, avance para o passo 1 para iniciar uma nova iteração de execução. Continue a iterar estes passos até que todos os seus exemplos de utilização sejam totalmente migrados para o BigQuery. Quando selecionar exemplos de utilização, pode rever os que permaneceram no estado de descarregamento para os mover para o estado totalmente migrado. Para os exemplos de utilização totalmente migrados, considere continuar o processo de evolução seguindo as diretrizes em Evolua o seu esquema no BigQuery.

    Passo final dos exemplos de utilização migrados.

Desenvolva o seu esquema no BigQuery

O esquema do armazém de dados define a estrutura dos seus dados e as relações entre as entidades de dados. O esquema está no centro do design dos seus dados e influencia muitos processos, tanto a montante como a jusante.

Uma migração do armazém de dados apresenta uma oportunidade única para desenvolver o seu esquema depois de ser movido para o BigQuery. Esta secção apresenta diretrizes para desenvolver o seu esquema através de uma série de passos. Estas diretrizes ajudam a manter o ambiente do data warehouse em funcionamento durante as alterações ao esquema com uma interrupção mínima dos processos a montante e a jusante.

Os passos nesta secção focam-se na transformação do esquema para um único exemplo de utilização.

Consoante o nível de evolução que pretende alcançar, pode parar num passo intermédio ou continuar até o sistema estar totalmente evoluído.

  1. Transferir um exemplo de utilização tal como está para o BigQuery.

    Antes de continuar com os passos seguintes, certifique-se de que os processos a montante e a jusante do seu exemplo de utilização já estão a escrever e a ler a partir do BigQuery. No entanto, também é possível começar a partir de um estado intermédio em que apenas o processo a jusante está a ler a partir do BigQuery. Neste cenário, aplique apenas as diretrizes para a parte a jusante. O diagrama seguinte ilustra um exemplo de utilização em que os processos a montante e a jusante escrevem e leem tabelas no BigQuery.

    Os processos a montante alimentam as tabelas do BigQuery e, a partir daí, os processos a jusante.

  2. Aplique otimizações simples.

    1. Recrie as tabelas aplicando a partição e o agrupamento. Para esta tarefa, pode usar o método de criação de uma tabela a partir do resultado de uma consulta. Para obter detalhes, consulte a discussão e o exemplo para tabelas particionadas, e consulte a discussão e o exemplo para tabelas agrupadas.
    2. Redirecione os processos a montante e a jusante para as novas tabelas.

  3. Crie vistas de fachadas.

    Se quiser desenvolver ainda mais o seu esquema além das otimizações simples, crie vistas de fachada para as suas tabelas. O padrão de fachada é um método de design que oculta o código ou as estruturas subjacentes para ocultar a complexidade. Neste caso, as vistas de fachada mascaram as tabelas subjacentes para ocultar a complexidade causada pelas alterações das tabelas dos processos a jusante.

    As vistas podem descrever um novo esquema, sem dívidas técnicas, e ser modeladas tendo em conta novos cenários de carregamento e consumo.

    Nos bastidores, as tabelas e a própria definição da consulta de visualização podem mudar. No entanto, as vistas abstraem estas alterações como um detalhe de implementação interno do seu data warehouse e devolvem sempre os mesmos resultados. Esta camada de abstração criada com vistas de fachada isola os seus sistemas a montante e a jusante das alterações durante o tempo necessário e só apresenta as alterações quando adequado.

  4. Transformar processos posteriores.

    Pode transformar alguns dos seus processos a jusante para ler a partir das vistas de fachada em vez das tabelas reais. Estes processos já vão beneficiar do esquema evoluído. Para estes processos, é transparente que, nos bastidores, as visualizações de fachada continuam a obter os respetivos dados do esquema do BigQuery de origem, conforme mostrado no diagrama seguinte:

    Os processos a montante alimentam as tabelas do BigQuery. Alguns alimentam processos posteriores. Outros alimentam as vistas de fachada, que alimentam os processos posteriores evoluídos.

    Descrevemos primeiro a transformação do processo a jusante. Isto permite-lhe mostrar o valor empresarial mais rapidamente, sob a forma de painéis de controlo ou relatórios migrados, do que se transformasse processos a montante que não são visíveis para as partes interessadas não técnicas. No entanto, é possível iniciar a transformação com os processos a montante. A prioridade destas tarefas depende inteiramente das suas necessidades.

  5. Transformar processos a montante.

    Pode transformar alguns dos seus processos a montante para escrever no novo esquema. Uma vez que as visualizações de propriedade são apenas de leitura, cria tabelas com base no novo esquema e, em seguida, modifica a definição da consulta das visualizações de propriedade de fachada. Algumas vistas continuam a consultar o esquema de origem, enquanto outras consultam as tabelas criadas recentemente ou executam uma operação SQL UNION em ambas, conforme mostrado no diagrama seguinte:

    Os processos a montante alimentam as tabelas do BigQuery, mas já não alimentam os processos a jusante. Em alternativa, as tabelas do BigQuery alimentam vistas de fachada, que, por sua vez, alimentam processos posteriores evoluídos.

    Neste momento, pode tirar partido dos campos aninhados e repetidos quando cria as novas tabelas. Isto permite-lhe desnormalizar ainda mais o seu modelo e tirar partido direto da representação de dados colunar subjacente do BigQuery.

    Uma vantagem das vistas de fachada é que os seus processos a jusante podem continuar a transformação independentemente destas alterações ao esquema subjacente e independentemente das alterações nos processos a montante.

  6. Desenvolver totalmente o seu exemplo de utilização.

    Por último, pode transformar os processos a montante e a jusante restantes. Quando todos estes elementos evoluem para escrever nas novas tabelas e ler a partir das novas vistas de fachada, modifica as definições de consulta das vistas de fachada para não lerem mais a partir do esquema de origem. Em seguida, pode retirar as tabelas do modelo de origem do fluxo de dados. O diagrama seguinte mostra o estado em que as tabelas de origem já não são usadas.

    Os processos originais a montante já não estão em utilização. Apenas permanecem os processos a montante evoluídos, que alimentam as tabelas evoluídas, que alimentam as vistas de fachada, que alimentam todos os processos a jusante.

    Se as vistas de fachada não agregarem campos nem filtrarem colunas, pode configurar os processos a jusante para lerem a partir das tabelas evoluídas e depois retirar as vistas de fachada para reduzir a complexidade, conforme mostrado no seguinte diagrama:

    Na configuração final, as tabelas do BigQuery e as tabelas evoluídas alimentam as vistas de fachada, que são a única origem para processos a jusante.

Faça uma transferência inicial do esquema e dos dados

Esta secção aborda considerações práticas para migrar o seu esquema e dados de um armazém de dados existente para o BigQuery.

Recomendamos que transfira o esquema sem alterações durante as iterações iniciais da migração. Isto oferece-lhe as seguintes vantagens:

  • Os pipelines de dados que alimentam o seu armazém de dados não precisam de ser ajustados para um novo esquema.
  • Evita adicionar um novo esquema à lista de material de formação para o seu pessoal.
  • Pode tirar partido das ferramentas automáticas para realizar o esquema e a transferência de dados.

Além disso, as provas de conceito (PoCs) e outras atividades de exploração de dados que tiram partido das capacidades da nuvem podem prosseguir sem impedimentos, mesmo enquanto a sua migração ocorre em paralelo.

Escolha um método de transferência

Pode fazer a transferência inicial através de uma de várias abordagens.

Para mais considerações ao escolher um método de transferência de dados, consulte o artigo Escolher um método de carregamento de dados.

Considere a transformação de dados

Consoante o formato de extração de dados e se quer recortar ou enriquecer os dados antes de os carregar para o BigQuery, pode incluir um passo para transformar os dados. Pode transformar os dados no ambiente existente ou no Trusted Cloud:

  • Se transformar os dados no ambiente atual, considere como a capacidade de computação e as ferramentas disponíveis podem limitar o débito. Além disso, se estiver a enriquecer os dados durante o processo de transformação, pondere se precisa de tempo de transferência ou largura de banda da rede adicionais.
  • Se transformar os dados no Trusted Cloud, consulte o artigo Carregue dados através de uma ferramenta ETL para mais informações sobre as suas opções.

Extraia o esquema e os dados existentes para ficheiros

A sua plataforma existente oferece provavelmente uma ferramenta para exportar dados para um formato independente do fornecedor, como o Apache AVRO ou CSV. Para reduzir a complexidade da transferência, recomendamos que use AVRO, ORC ou Parquet, em que as informações do esquema estão incorporadas nos dados. Se escolher CSV ou um formato de dados delimitados simples semelhante, tem de especificar o esquema separadamente. A forma como o faz depende do método de transferência de dados que selecionar. Por exemplo, para o carregamento em lote, pode especificar um esquema no momento do carregamento ou permitir a deteção automática do esquema com base no conteúdo do ficheiro CSV.

À medida que extrai estes ficheiros da sua plataforma existente, copie-os para o armazenamento de preparação no seu ambiente existente.

Carregue os ficheiros para o Cloud Storage

A menos que esteja a usar o Serviço de transferência de dados do BigQuery para carregar dados diretamente de um armazém de dados do Amazon Redshift ou Teradata existente, tem de carregar os ficheiros extraídos para um contentor no Cloud Storage. Consoante a quantidade de dados que está a transferir e a largura de banda da rede disponível, pode escolher entre as seguintes opções de transferência:

  • Se os dados extraídos estiverem noutro fornecedor de nuvem, use o Serviço de transferência de armazenamento.

  • Se os dados estiverem num ambiente nas instalações ou numa instalação de partilha de espaço físico com uma boa largura de banda da rede, use a CLI do Google Cloud. A CLI gcloud suporta carregamentos paralelos com várias linhas de execução, retoma após erros e encripta o tráfego em trânsito para segurança.

    • Se não conseguir usar a CLI gcloud, pode experimentar uma ferramenta de terceiros de um parceiro da Google.
    • Se a largura de banda da sua rede for limitada, pode usar técnicas de compressão para limitar o tamanho dos dados ou pode modificar a sua ligação atual para Trusted Cloud para aumentar a largura de banda.

  • Se não conseguir alcançar uma largura de banda de rede suficiente, pode fazer uma transferência offline através de um Transfer Appliance.

Quando cria o contentor do Cloud Storage e transfere dados através da rede, minimize a latência da rede escolhendo a localização mais próxima do seu centro de dados. Se possível, escolha a localização do contentor para que seja igual à localização do conjunto de dados do BigQuery.

Para ver informações detalhadas sobre as práticas recomendadas ao mover dados para o Cloud Storage, incluindo a estimativa de custos, consulte o artigo Estratégias para transferir grandes conjuntos de dados.

Carregue o esquema e os dados para o BigQuery

Carregue o esquema e os dados para o BigQuery através de uma das opções abordadas em Escolha um método de transferência.

Para mais informações sobre carregamentos únicos, consulte o artigo Introdução ao carregamento de dados a partir do Cloud Storage na documentação do BigQuery. Para mais informações sobre carregamentos agendados a intervalos regulares, consulte a vista geral das transferências do Cloud Storage na documentação do Serviço de transferência de dados do BigQuery.

Carregue dados através de uma ferramenta ETL

Se os seus dados precisarem de mais transformações à medida que são carregados para o BigQuery, use uma das seguintes opções:

  • Cloud Data Fusion. Esta ferramenta cria graficamente pipelines de dados ETL/ELT totalmente geridos através de uma biblioteca de código aberto de transformações e conetores pré-configurados.
  • Fluxo de dados. Esta ferramenta define e executa transformações de dados complexas e gráficos de enriquecimento usando o modelo Apache Beam. O Dataflow é sem servidor e totalmente gerido pela Google, o que lhe dá acesso a uma capacidade de processamento praticamente ilimitada.
  • Dataproc. Esta opção executa o cluster Apache Spark e Apache Hadoop num serviço de nuvem totalmente gerido.
  • Ferramentas de terceiros. Contacte um dos nossos parceiros. Podem oferecer escolhas eficazes quando quer externalizar a criação de um pipeline de dados.

O diagrama seguinte mostra o padrão descrito nesta secção. A ferramenta de transferência de dados é a CLI gcloud, e existe um passo de transformação que tira partido do Dataflow e escreve diretamente no BigQuery, talvez usando o conetor Google BigQuery I/O incorporado do Apache Beam.

O data warehouse existente copia os dados para o armazenamento temporário no local. A CLI gcloud copia os dados para um contentor do Cloud Storage. O Dataflow lê a partir do contentor de preparação e move os dados para o BigQuery.

Depois de carregar um conjunto inicial dos seus dados para o BigQuery, pode começar a tirar partido das funcionalidades avançadas do BigQuery.

No entanto, tal como quando transferiu o seu esquema, o carregamento dos dados faz parte de um processo iterativo. As iterações subsequentes podem começar por expandir a área de cobertura dos dados que estão a ser transferidos para o BigQuery. Em seguida, pode reencaminhar os feeds de dados a montante para o BigQuery para eliminar a necessidade de manter o armazém de dados existente em funcionamento. Estes tópicos são explorados na secção seguinte.

Valide os dados

Agora que os seus dados estão no BigQuery, pode validar o êxito da transferência de dados com a ferramenta de validação de dados (DVT). O DVT é uma ferramenta de CLI Python de código aberto que lhe permite comparar dados de várias origens com o seu destino no BigQuery. Pode especificar as agregações que quer executar (por exemplo, contagem, soma, média) e as colunas às quais devem ser aplicadas. Para mais informações, consulte o artigo Automatize a validação de dados com a DVT.

Repita a transferência inicial

Esta secção aborda como proceder após a transferência de dados inicial para tirar o máximo partido do BigQuery.

Um subconjunto dos seus dados está agora no BigQuery. Está a preparar-se para aumentar a área de cobertura dos dados que estão a ser usados no BigQuery e, por isso, reduzir a dependência do seu data warehouse existente.

O método que escolher para as iterações subsequentes depende da importância que tem para o seu exemplo de utilização ter os dados atualizados até ao segundo atual. Se os seus analistas de dados puderem trabalhar com dados incorporados no armazém de dados a intervalos recorrentes, uma opção agendada é o caminho a seguir. Pode criar transferências agendadas de forma semelhante à transferência inicial. Usa o Serviço de transferência de dados do BigQuery, outras ferramentas de ETL, como o Serviço de transferência de armazenamento> da Google, ou implementações de terceiros.

Se usar o Serviço de transferência de dados do BigQuery, primeiro decide que tabelas mover. Em seguida, crie um padrão de nome de tabela para incluir essas tabelas. Por fim, define um horário recorrente para quando executar a transferência.

Por outro lado, se o seu exemplo de utilização exigir acesso quase instantâneo a novos dados, precisa de uma abordagem de streaming. Tem duas opções:

  • Configure um pipeline de carregamento com Trusted Cloud produtos. A Google fornece um conjunto de modelos do Dataflow de streaming para facilitar esta tarefa.
  • Use uma solução de um dos nossos parceiros.

A curto prazo, o aumento da área de cobertura dos seus dados do BigQuery e a sua utilização para processos posteriores devem focar-se na satisfação dos seus exemplos de utilização de prioridade máxima, com o objetivo a médio prazo de abandonar o seu data warehouse existente. Use as iterações iniciais com moderação e não gaste muitos recursos a aperfeiçoar os pipelines de carregamento do seu armazém de dados existente para o BigQuery. Em última análise, tem de adaptar esses pipelines para não usarem o data warehouse existente.

Otimize o esquema

A simples migração das tabelas tal como estão para o BigQuery permite-lhe tirar partido das respetivas funcionalidades únicas. Por exemplo, não é necessário reconstruir índices, reorganizar blocos de dados (limpeza) nem qualquer tempo de inatividade ou degradação do desempenho devido a atualizações de versões.

No entanto, manter o modelo do armazém de dados intacto para além das iterações iniciais da migração também tem desvantagens:

  • Os problemas existentes e a dívida técnica associados ao esquema permanecem.
  • As otimizações de consultas são limitadas e podem ter de ser refeitas se o esquema for atualizado numa fase posterior.
  • Não tira total partido de outras funcionalidades do BigQuery, como campos aninhados e repetidos, partição e agrupamento.

À medida que avança para uma transferência final, recomendamos que melhore o desempenho do sistema aplicando a partição e o agrupamento às tabelas que cria no seu esquema.

Partição

O BigQuery permite-lhe dividir os seus dados em segmentos, denominados partições, que facilitam e tornam mais eficiente a gestão e a consulta dos seus dados. Pode particionar as tabelas com base numa coluna de TIMESTAMP ou DATE. Em alternativa, o BigQuery pode adicionar pseudocolunas para particionar automaticamente os dados durante a ingestão. As consultas que envolvem partições mais pequenas podem ter um melhor desempenho porque analisam apenas um subconjunto dos dados e podem reduzir os custos minimizando o número de bytes lidos.

A partição não afeta a estrutura existente das suas tabelas. Por conseguinte, deve considerar criar tabelas particionadas, mesmo que o esquema não seja modificado.

Clustering

No BigQuery, não são usados índices para consultar os seus dados. O desempenho do BigQuery é otimizado pelo modelo subjacente, pelas técnicas de armazenamento e de consulta, e pela arquitetura massivamente paralela. Quando executa uma consulta, quanto mais dados forem processados, mais máquinas são adicionadas para analisar dados e agregar resultados em simultâneo. Esta técnica é facilmente escalável para conjuntos de dados enormes, ao contrário da recriação de índices.

No entanto, é possível otimizar ainda mais as consultas com técnicas como a agrupamento. Com a clustering, o BigQuery ordena automaticamente os seus dados com base nos valores de algumas colunas que especificar e coloca-os em blocos de tamanho ideal. A agrupagem melhora o desempenho das consultas em comparação com a não utilização da agrupagem. Com a clustering, o BigQuery pode estimar melhor o custo de execução da consulta do que sem clustering. Com as colunas agrupadas, as consultas também eliminam as análises de dados desnecessários e podem calcular agregações mais rapidamente porque os blocos colocam os registos com valores semelhantes.

Examine as suas consultas para ver as colunas usadas frequentemente para filtragem e crie as suas tabelas com agrupamento nessas colunas. Para mais informações sobre a criação de clusters, consulte o artigo Introdução às tabelas agrupadas em clusters.

Desnormalização

A migração de dados é um processo iterativo. Assim, depois de mover o esquema inicial para a nuvem, fazer otimizações simples e testar alguns exemplos de utilização importantes, pode ser altura de explorar capacidades adicionais que beneficiam da estrutura subjacente do BigQuery. Estes incluem campos aninhados e repetidos.

Os esquemas de armazéns de dados usaram historicamente os seguintes modelos:

  • Esquema em estrela. Este é um modelo desnormalizado, em que uma tabela de factos recolhe métricas como o valor do pedido, o desconto e a quantidade, juntamente com um grupo de chaves. Estas chaves pertencem a tabelas de dimensões, como cliente, fornecedor, região, etc. Graficamente, o modelo assemelha-se a uma estrela, com a tabela de factos no centro rodeada por tabelas de dimensões.
  • Esquema de floco de neve. Isto é semelhante ao esquema em estrela, mas com as tabelas de dimensões normalizadas, o que dá ao esquema o aspeto de um floco de neve único.

O BigQuery suporta esquemas em estrela e floco de neve, mas a respetiva representação de esquema nativa não é nenhuma dessas duas. Em vez disso, usa campos aninhados e repetidos para uma representação mais natural dos dados. Para mais informações, consulte o esquema de exemplo na documentação do BigQuery.

Alterar o esquema para usar campos aninhados e repetidos é uma excelente escolha evolutiva. Reduz o número de junções necessárias para as suas consultas e alinha o seu esquema com a representação de dados interna do BigQuery. Internamente, o BigQuery organiza os dados através do modelo Dremel e armazena-os num formato de armazenamento em colunas denominado Capacitor.

Para decidir a melhor abordagem de desnormalização para o seu caso, considere usar campos aninhados e repetidos no BigQuery, bem como as técnicas para processar alterações ao esquema.

O que se segue?

Saiba mais sobre os seguintes passos na migração do armazém de dados:

Também pode saber como fazer a migração de tecnologias de armazém de dados específicas para o BigQuery: