Organizar recursos de código com pastas

O documento a seguir descreve como as pastas do BigQuery funcionam. É possível usar pastas para organizar recursos de código em uma estrutura hierárquica, semelhante à usada pelos sistemas operacionais. Por exemplo, você pode criar uma pasta para organizar os recursos de código para análise de vendas, com subpastas para cada ano fiscal. Você também pode usar pastas para gerenciar o acesso a recursos de código. As pastas oferecem herança de políticas do Identity and Access Management (IAM), que pode ser usada para controlar o acesso a recursos de código com mais eficiência. Com a herança de políticas, as subpastas e os arquivos herdam as permissões da pasta principal.

As pastas do BigQuery são desenvolvidas pelo Dataform.

Para mais informações sobre como trabalhar com pastas no BigQuery, consulte Criar e gerenciar pastas.

Organizar recursos de código com pastas

É possível acessar e organizar seus recursos de código usando pastas no painel Arquivos do BigQuery Studio:

A localização do painel **Arquivos** no BigQuery Studio.

Uma pasta é o contêiner básico para organizar recursos de código, semelhante a uma pasta padrão do sistema de arquivos. É possível criar e organizar subpastas em uma pasta principal, além de mover recursos de código para dentro e para fora das pastas. Quando você concede permissões em uma pasta, elas são propagadas para todas as pastas e arquivos contidos nela.

Só é possível usar pastas para organizar recursos de código de arquivo único, como notebooks, consultas salvas, telas de dados e arquivos de preparação de dados.

Tipos de pasta

O BigQuery é compatível com os seguintes tipos de pastas:

  • Pastas do usuário: cada usuário tem uma pasta raiz pessoal, exibida como Usuário (endereço de e-mail do usuário). A pasta do usuário contém todos os recursos de código que você cria no projeto e no local especificados. É possível criar subpastas na pasta do usuário para organizar esses recursos de código. Os arquivos e pastas na sua pasta de usuário só podem ser acessados por você, a menos que você os compartilhe com outros usuários.

  • Pastas de equipe: são projetadas para colaboração em equipe, semelhante a um drive compartilhado no Google Drive. Você pode usar pastas de equipe para organizar recursos de código que pertencem a uma equipe específica. Somente usuários com permissões de proprietário na pasta da equipe raiz podem conceder permissões para permitir que outros usuários usem a pasta da equipe.

Regiões de código da pasta

Você pode ter pastas e recursos de código em diferentes regiões de código. Por exemplo, você pode ter folderA e os recursos de código que ele contém na região us-west1, e folderB e os recursos de código que ele contém na região us-central1. A região que você está visualizando aparece no painel Arquivos:

A região de código atual é mostrada ao lado do nome do projeto no painel **Arquivos**.

Herança de políticas do IAM

O acesso do IAM a recursos de arquivos e pastas usa uma estrutura hierárquica. Essa hierarquia garante que as políticas de acesso sejam herdadas das pastas principais para o conteúdo delas.

Quando uma política do IAM é definida em uma pasta, as permissões concedidas por essa política também se aplicam a todos os arquivos e subpastas aninhadas na subárvore da pasta. Isso tem as seguintes consequências:

  • As permissões são herdadas de acordo com a hierarquia de pastas. Quando um usuário recebe uma função específica em uma pasta de alto nível, ele tem as permissões incluídas nessa função para todos os recursos contidos nessa pasta e nas subpastas dela.
  • As permissões que um usuário tem em um recurso consistem nas políticas definidas diretamente nesse recurso e em todas as políticas herdadas de cada pasta no caminho até a raiz.

Como resultado, você não precisa de permissões no nível do projeto para realizar ações em recursos localizados em uma estrutura de pastas complexa. Você só precisa da permissão adequada em qualquer pasta no caminho até esse recurso. Por exemplo, se você quiser criar um arquivo em uma subpasta, precisará das permissões necessárias na subpasta específica ou em qualquer uma das pastas mãe, incluindo a pasta de nível superior.

Confira a seguir as práticas recomendadas para aplicar políticas do IAM a arquivos e pastas:

  • Aplique políticas do IAM à pasta mais alta na hierarquia em que as permissões são necessárias de maneira uniforme. Por exemplo, se uma equipe precisar acessar todos os dados no diretório dela, conceda os papéis necessários no nível da pasta da equipe em vez de no nível das subpastas de projetos individuais.
  • Sempre conceda o conjunto mínimo de permissões necessárias para que usuários ou serviços executem as tarefas. Evite conceder papéis amplos quando for possível usar papéis e permissões mais específicos no nível da pasta.

Papéis do IAM concedidos na criação de recursos

Ao criar uma pasta, os seguintes papéis são concedidos automaticamente:

Você não recebe papéis automaticamente ao criar arquivos ou pastas na subárvore de uma pasta de equipe.

Recursos ocupados

Uma pasta de usuário ou de equipe está "ocupada" se estiver envolvida em uma operação de movimentação, seja como o objeto que está sendo movido ou o destino da movimentação. Para garantir a integridade dos dados durante a movimentação, o sistema restringe as seguintes ações em recursos ocupados:

  • Ser o objeto de outra operação de movimentação.
  • Ser o destino de outra operação de movimentação.
  • Ser um ancestral de um objeto de movimento.
  • Ser o objeto de uma operação de exclusão.

Limitações

As pastas do BigQuery têm as seguintes limitações:

  • Só é possível aninhar pastas em até cinco níveis.
  • Ter um grande número de pastas (centenas de milhares) diminui o desempenho ao trabalhar com elas. Por exemplo, ao carregar o explorador de arquivos ou expandir uma pasta.
  • Não é possível mover uma pasta que contenha mais de 100 arquivos ou pastas.

Locais

As pastas do BigQuery são compatíveis com todos os locais do Dataform.

A seguir