Neste post, comparamos abordagens para obter insights sobre seu footprint no BigQuery e apresentamos um script Python sob medida para flexibilidade total.
No mundo em rápida evolução da análise de dados, o Google BigQuery se destaca como um data warehouse serverless e poderoso, que roda consultas SQL ultrarrápidas em volumes enormes de dados. Seja você cientista de dados, engenheiro de dados ou especialista em analytics, navegar pelos amplos recursos do BigQuery muitas vezes parece uma caça ao tesouro. À medida que sua organização cresce, o footprint no BigQuery tende a crescer junto, e um dos desafios que muita gente enfrenta é listar tabelas e datasets de forma eficiente em diferentes escopos.
O objetivo deste post é guiar você pelos diversos métodos de listagem de tabelas e datasets no BigQuery, com o foco específico de listar esses ativos em toda a sua organização e mostrar as limitações inerentes de cada abordagem ao longo do caminho.
Conforme exploramos as diferentes técnicas, das interações básicas pela GUI até consultas SQL e chamadas de API mais avançadas, você vai entender os pontos fortes e as limitações de cada uma. No fim, apresentamos uma solução que oferece a maior flexibilidade, mas exige um pouco mais de mão na massa — isto é, se já não tivéssemos feito boa parte do trabalho por você!
Vamos passar pelas seguintes opções:
- Web UI do Google Cloud Console
- BigQuery CLI
- Dataplex (Data Catalog)
- INFORMATION_SCHEMA
- Script sob medida
E vamos considerar algumas dimensões de avaliação no caminho:
- Escopo da listagem
- Nível de detalhe
- Flexibilidade
- Preço
Um bom ponto de partida é a já conhecida web UI do Google Cloud Console. Acessando o BigQuery Studio dentro da página do produto BigQuery, você visualiza os datasets e tabelas do projeto atual (e de outros projetos, caso tenha adicionado) organizados no painel Explorer. Também dá para buscar recursos (dataset, tabela ou view) por nome ou label, e os resultados abrangem tanto projects quanto organisations aos quais você tem acesso.
Datasets (esquerda) e tabelas (direita) na UI do BigQuery
Prós:
- Fácil de acessar pelo BigQuery Studio.
- Faz busca em
projectseorganisations, ou seja, sem limitação de escopo. - Essa abordagem é gratuita.
Contras:
- Não traz uma lista exaustiva de todos os datasets ou tabelas da sua organização ou aos quais você tem acesso.
- Não fornece outros metadados sobre as tabelas.
Se você não curte muito UIs e prefere passar o tempo no terminal, talvez se identifique mais com o BigQuery CLI.
Com um PROJECT_ID, você lista todos os datasets desse projeto rodando:
bq ls --project_id $PROJECT_ID
Datasets no BigQuery CLI
Ou, com PROJECT_ID e DATASET_ID, dá para listar todas as tabelas desse dataset rodando:
bq ls --project_id $PROJECT_ID --dataset_id=$DATASET_ID
Tabelas no BigQuery CLI
Prós:
- CLI fácil de usar.
- A saída pode ser usada em processamentos leves a jusante com, por exemplo,
jq, sobretudo com a flag--format: <none|json|prettyjson|csv|sparse|pretty>. - Operações de metadados são gratuitas.
Contras:
- O escopo da listagem é limitado: um projeto no nível de dataset e um dataset no nível de tabela.
- Os detalhes retornados também são limitados.
Quando o assunto é encontrar todos os dados relevantes da sua organização, o Data Catalog vem logo à cabeça! O Data Catalog já foi um produto independente, mas virou funcionalidade do Dataplex desde meados de 2022. O Dataplex é a plataforma inteligente de gerenciamento de dados do Google Cloud, que automatiza a organização, a segurança e a análise de dados em data lakes, warehouses e bancos de dados, ajudando sua organização com descoberta, governança e compliance. O Data Catalog funciona como o inventário central dos ativos de dados da sua organização.
Ele permite buscar entre organizações e sistemas, filtrar por tipos de dados, tags etc. No nosso caso de uso, dá para recuperar todos os datasets e tabelas dentro de uma organização específica simplesmente aplicando o filtro adequado na UI:
O legal é que, para quem prefere CLI no lugar de UI, dá para chegar ao mesmo resultado com um comando gcloud assim:
Para datasets:
gcloud data-catalog search "type=dataset" --include-organization-ids=YOUR_ORG_ID
Datasets no Dataplex
Para tabelas:
gcloud data-catalog search "type=table" --include-organization-ids=YOUR_ORG_ID
Tabelas no Dataplex
Prós:
- Faz buscas entre organizações E vai além do BigQuery.
Contras:
- O Data Catalog armazena diferentes tipos de metadados (de negócio e técnicos), mas deixa de fora alguns detalhes, como tamanho da tabela ou total de bytes armazenados.
- Nem o Dataplex nem o Data Catalog são gratuitos, embora o preço seja tranquilo na maioria dos casos de uso. Veja a página de preços para mais detalhes.
Os fãs de carteirinha do BigQuery com certeza conhecem o INFORMATION_SCHEMA. As views do INFORMATION_SCHEMA do BigQuery são views somente leitura, definidas pelo sistema, que fornecem informações de metadados sobre os seus objetos do BigQuery. Existe um monte de views diferentes, confira a documentação para uma visão completa.
No nosso caso de uso, o que mais interessa são as views SCHEMATA e TABLES:
Podemos usar a view SCHEMATA para listar todos os datasets de uma região, por exemplo, em us-central1:
SELECT * FROM `region-us-central1`.INFORMATION_SCHEMA.SCHEMATA;
Datasets no INFORMATION_SCHEMA
Ou podemos usar a view TABLES para listar todas as tabelas de uma região, por exemplo, em us-central1:
SELECT * FROM `region-us-central1`.INFORMATION_SCHEMA.TABLES;
Tabelas no INFORMATION_SCHEMA
Prós:
- Acesso programático fácil via SQL direto no BigQuery.
- Informação bem detalhada; por exemplo, a
[TABLES](https://cloud.google.com/bigquery/docs/information-schema-tables#schema) [view](https://cloud.google.com/bigquery/docs/information-schema-tables#schema) inclui `creation_time`, `ddl`,e a TABLE_STORAGE view traz informações sobretotal_rows, além do tamanho da tabela (armazenamento físico e lógico).
Contras:
- Informação no máximo no escopo de uma região (mesmo na view de nível organizacional). Como a lista de regiões já é bem extensa e pode mudar de forma dinâmica, montar scripts em torno disso talvez não seja o ideal.
- Não é gratuito, embora o preço seja tranquilo na maioria dos casos de uso.
Como costuma acontecer, nossos clientes mais técnicos vieram com um desafio: queriam visibilidade em toda a organização, além de um nível detalhado de informação sobre as tabelas em todos os projetos.
Acabamos escrevendo um pequeno script que faz exatamente isso, e você também encontra ele no nosso GitHub. Ele exige a configuração de algumas variáveis de ambiente, que provisionam uma service-account no nível da organização, e depois percorre todos os projetos e datasets dessa organização, buscando as tabelas dentro desses datasets e os detalhes relevantes (neste caso: tamanho da tabela). Embora seja preciso ter algum conhecimento básico de Python e familiaridade com a API do BigQuery, essa abordagem oferece a maior flexibilidade (dá para recuperar outras propriedades de tabela consultando a documentação da API), e os dados podem ser gravados no formato que você quiser para uso posterior.
Prós:
- Flexibilidade máxima:
- Extraia da API todos os dados que quiser.
- O resultado pode sair no formato que você quiser.
- Adicione filtros ou estenda o script à vontade.
- Gratuito, da DoiT para você.
Contras:
- Tempo e esforço adicionais para escrever o script — mas já adiantamos boa parte do trabalho pesado para você!
Navegar pelo BigQuery pode ser complexo, e cada método tem vantagens próprias, conforme as necessidades de cada organização. As ferramentas padrão entregam simplicidade e acessibilidade, enquanto um script sob medida desbloqueia uma flexibilidade e um nível de detalhe sem paralelo, ainda que demande algum esforço inicial.
Você já adotou outra abordagem? Conta pra gente o seu caminho favorito ou estenda o script básico para se adaptar às suas necessidades!