Consultar os dados

Consultar dados é o passo fundamental para realizar quase todas as tarefas orientadas por dados no Azure Databricks. Independentemente do idioma ou da ferramenta usada, as cargas de trabalho começam definindo uma consulta em relação a uma tabela ou outra fonte de dados e, em seguida, executando ações para obter informações dos dados. Este artigo descreve os conceitos e procedimentos fundamentais para executar consultas em várias ofertas de produtos Azure Databricks, incluindo exemplos de código que pode adaptar ao seu caso de uso.

Você pode consultar dados interativamente usando:

• Notebooks
• Editor de SQL
• Editor de ficheiros
• Painéis de Controlo

Você também pode executar consultas como parte de trabalhos ou pipelines declarativos do Lakeflow Spark.

Para uma visão geral das consultas de streaming no Azure Databricks, veja Query streaming data.

Que dados podes consultar com Azure Databricks?

O Azure Databricks suporta consulta de dados em múltiplos formatos e sistemas empresariais. Os dados que consultas usando o Azure Databricks enquadram-se numa de duas grandes categorias: dados num lago Databricks e dados externos.

Quais dados estão em uma casa de lago Databricks?

A Databricks Data Intelligence Platform armazena todos os seus dados em um lago Databricks por padrão.

Isso significa que, ao executar uma instrução básica CREATE TABLE para criar uma nova tabela, você criou uma tabela lakehouse. Os dados do Lakehouse têm as seguintes propriedades:

• Armazenado no formato Delta Lake.
• Armazenado no armazenamento de objetos na nuvem.
• Regido pelo Catálogo Unity.

A maioria dos dados do lago no Azure Databricks está registada no Unity Catalog como tabelas geridas. As tabelas gerenciadas fornecem a sintaxe mais fácil e se comportam como outras tabelas na maioria dos sistemas de gerenciamento de banco de dados relacional. As tabelas gerenciadas são recomendadas para a maioria dos casos de uso e são adequadas para todos os usuários que não querem se preocupar com os detalhes de implementação do armazenamento de dados.

Uma tabela não gerenciada, ou tabela externa, é uma tabela registrada com um LOCATION especificado. O termo externo pode ser enganoso, pois as tabelas Delta externas ainda são dados de lakehouse. Tabelas não gerenciadas podem ser preferidas por usuários que acessam tabelas diretamente de outros clientes de leitor Delta. Para uma visão geral das diferenças na semântica das tabelas, veja Azure Databricks tabelas.

Algumas cargas de trabalho herdadas podem interagir exclusivamente com os dados do Delta Lake por meio de caminhos de arquivo e não registrar tabelas. Esses dados ainda são dados lakehouse, mas podem ser mais difíceis de descobrir porque não estão registrados no Unity Catalog.

Que dados são considerados externos?

Qualquer dado que não esteja em um lago Databricks pode ser considerado um dado externo. Alguns exemplos de dados externos incluem o seguinte:

• Tabelas estrangeiras registadas na Lakehouse Federation.
• Tabelas no metastore do Hive apoiadas pelo Parquet.
• Tabelas externas no Unity Catalog apoiadas por JSON.
• Dados CSV armazenados no armazenamento de objetos na nuvem.
• Dados em streaming lidos de Kafka.

O Azure Databricks suporta configurar ligações a várias fontes de dados. Consulte Conectar-se a fontes de dados e serviços externos.

Embora você possa usar o Unity Catalog para controlar o acesso e definir tabelas em relação aos dados armazenados em vários formatos e sistemas externos, o Delta Lake é um requisito para que os dados sejam considerados parte do lakehouse.

A Delta Lake fornece todas as garantias transacionais no Azure Databricks, que são cruciais para manter a integridade e consistência dos dados. Se quiser saber mais sobre garantias transacionais em dados Azure Databricks e porque são importantes, veja O que são garantias ACID em Azure Databricks?.

A maioria dos utilizadores do Azure Databricks consulta uma combinação de dados de lakehouse e dados externos. Ligar-se a dados externos é sempre o primeiro passo para a ingestão de dados e para os pipelines de ETL que trazem dados para o lakehouse. Para obter informações sobre como ingerir dados, consulte Conectores padrão no Lakeflow Connect.

Consultar tabelas por nome

Para todos os dados registrados como uma tabela, o Databricks recomenda consultar usando o nome da tabela.

Se você estiver usando o Unity Catalog, as tabelas usarão um namespace de três camadas com o seguinte formato: <catalog-name>.<schema-name>.<table-name>.

Sem o Unity Catalog, os identificadores de tabela usam o formato <schema-name>.<table-name>.

A consulta por nome de tabela é suportada em todos os contextos de execução do Azure Databricks e linguagens suportadas.

SQL

SELECT * FROM catalog_name.schema_name.table_name

Python

spark.read.table("catalog_name.schema_name.table_name")

Resolução do identificador no Catálogo Unity

O Databricks recomenda o uso de identificadores totalmente qualificados quando consultas ou cargas de trabalho interagem com objetos de banco de dados armazenados em vários esquemas ou catálogos.

A tabela a seguir descreve comportamentos para identificadores parcialmente qualificados e não qualificados:

Qual é o catálogo e esquema atuais?

Em ambientes de computação interativos, use current_catalog() e current_schema() para confirmar seu catálogo e esquema atuais.

Todos os espaços de trabalho configurados com o Unity Catalog têm um catálogo padrão definido no nível do espaço de trabalho. Consulte Gerenciar o catálogo padrão.

A tabela a seguir descreve configurações para produtos Databricks que podem substituir o catálogo padrão do espaço de trabalho:

Use a sintaxe USE CATALOG ou USE SCHEMA para especificar o catálogo ou esquema atual para sua sessão atual. O catálogo ou esquema atual é usado quando uma consulta ou instrução usa um dentificador parcialmente qualificado ou não qualificado.

Consultar dados por caminho

Você pode consultar dados estruturados, semiestruturados e não estruturados usando caminhos de arquivo. A maioria dos ficheiros no Azure Databricks é suportada por armazenamento de objetos na cloud. Veja Trabalhar com ficheiros em Azure Databricks.

O Databricks recomenda configurar todo o acesso ao armazenamento de objetos em nuvem usando o Unity Catalog e definir volumes para locais de armazenamento de objetos que são consultados diretamente. Os volumes fornecem aliases legíveis por humanos para locais e arquivos no armazenamento de objetos em nuvem usando nomes de catálogo e esquema para o caminho de arquivo. Consulte Conectar-se ao armazenamento de objetos na nuvem usando o Unity Catalog.

Os exemplos a seguir demonstram como usar caminhos de volume do Unity Catalog para ler dados JSON:

SQL

SELECT * FROM json.`/Volumes/catalog_name/schema_name/volume_name/path/to/data`

Python

spark.read.format("json").load("/Volumes/catalog_name/schema_name/volume_name/path/to/data")

Para locais na nuvem que não estão configurados como volumes do Catálogo Unity, você pode consultar dados diretamente usando URIs. Você deve configurar o acesso ao armazenamento de objetos na nuvem para consultar dados com URIs. Veja Configure o acesso ao armazenamento de objetos na cloud para Azure Databricks usando padrões legados.

Os exemplos seguintes demonstram como usar URIs para consultar dados JSON no Azure Data Lake Storage, GCS e S3:

SQL

SELECT * FROM json.`abfss://container-name@storage-account-name.dfs.core.windows.net/path/to/data`;

SELECT * FROM json.`gs://bucket_name/path/to/data`;

SELECT * FROM json.`s3://bucket_name/path/to/data`;

Python

spark.read.format("json").load("abfss://container-name@storage-account-name.dfs.core.windows.net/path/to/data")

spark.read.format("json").load("gs://bucket_name/path/to/data")

spark.read.format("json").load("s3://bucket_name/path/to/data")

Consultar dados usando armazéns SQL

O Azure Databricks utiliza armazéns SQL para computação nas seguintes interfaces:

• Editor de SQL
• Consultas SQL do Databricks
• Painéis de Controlo
• Alertas SQL

Opcionalmente, você pode usar armazéns SQL com os seguintes produtos:

• Notebooks Databricks
• Editor de arquivos Databricks
• Empregos em Lakeflow

Ao consultar dados com armazéns SQL, você pode usar apenas a sintaxe SQL. Não há suporte para outras linguagens de programação e APIs.

Para espaços de trabalho habilitados para o Catálogo Unity, os armazéns SQL sempre usam o Catálogo Unity para gerenciar o acesso a fontes de dados.

A maioria das consultas executadas em armazéns SQL tem como alvo as tabelas. As consultas destinadas a arquivos de dados devem aproveitar os volumes do Catálogo Unity para gerenciar o acesso aos locais de armazenamento.

Usar URIs diretamente em consultas executadas em armazéns SQL pode levar a erros inesperados.

Consultar dados usando computação genérica ou computação para tarefas

A maioria das consultas executadas a partir de blocos de anotações Databricks, fluxos de trabalho e do editor de arquivos é executada em clusters de computação configurados com o Databricks Runtime. Você pode configurar esses clusters para serem executados interativamente ou implantá-los como trabalhos computados que alimentam fluxos de trabalho. O Databricks recomenda que você sempre use a computação de trabalhos para cargas de trabalho não interativas.

Cargas de trabalho interativas versus não interativas

Muitos usuários acham útil exibir os resultados da consulta enquanto as transformações são processadas durante o desenvolvimento. Movendo uma carga de trabalho interativa da computação genérica para a computação dedicada a tarefas, pode-se economizar tempo e custos de processamento ao remover consultas que exibem resultados.

O Apache Spark usa execução de código preguiçosa, o que significa que os resultados são calculados apenas conforme necessário, e várias transformações ou consultas em uma fonte de dados podem ser otimizadas como uma única consulta se você não forçar os resultados. Isso contrasta com o modo de execução ansioso usado em pandas, que exige que os cálculos sejam processados em ordem antes de passar os resultados para o próximo método.

Se o seu objetivo é salvar dados limpos, transformados e agregados como um novo conjunto de dados, você deve remover consultas que exibem resultados do seu código antes de programá-lo para execução.

Para pequenas operações e pequenos conjuntos de dados, a economia de tempo e custos pode ser marginal. Ainda assim, com grandes operações, pode-se perder tempo substancial calculando e imprimindo resultados em um notebook que pode não ser inspecionado manualmente. Os mesmos resultados poderiam provavelmente ser consultados a partir da saída guardada praticamente sem custo, após seu armazenamento.