Consultar dados

A consulta aos dados é a etapa fundamental para executar quase todas as tarefas controladas por dados no Azure Databricks. Independentemente da linguagem ou ferramenta usada, as cargas de trabalho começam definindo uma consulta em uma tabela ou outra fonte de dados e, em seguida, executando ações para obter insights dos dados. Este artigo descreve os principais conceitos e procedimentos para executar consultas em várias ofertas de produtos do Azure Databricks e inclui exemplos de código que você pode adaptar para seu caso de uso.

Você pode consultar dados interativamente usando:

• Notebooks
• Editor SQL
• Editor de arquivos
• Dashboards

Você também pode executar consultas como parte dos pipelines ou trabalhos do Delta Live Tables.

Para obter uma visão geral das consultas de streaming no Azure Databricks, confira Consultar dados de streaming.

Quais dados você pode consultar com o Azure Databricks?

O Azure Databricks dá suporte à consulta de dados em vários formatos e sistemas corporativos. Os dados que você consulta usando o Azure Databricks se enquadram em uma das duas categorias amplas: dados em um Databricks Lakehouse e dados externos.

Quais dados estão em um lakehouse do Databricks?

A Plataforma Data Intelligence do Databricks armazena todos os seus dados em um lakehouse do Databricks por padrão.

Isso significa que, ao executar uma instrução CREATE TABLE básica 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 de nuvem.
• Regido pelo Catálogo do Unity.

A maioria dos dados do lakehouse no Azure Databricks é registrada no Catálogo do Unity como tabelas gerenciadas. 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 relacionais. 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 tabelas Delta externas ainda são dados do lakehouse. Tabelas não gerenciadas podem ser preferenciais por usuários que acessam diretamente tabelas de outros clientes leitores Delta. Para obter uma visão geral das diferenças na semântica de tabela, consulte O que são tabelas e exibições?.

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 do Lakehouse, mas podem ser mais difíceis de descobrir porque não estão registrados no Catálogo do Unity.

Quais dados são considerados externos?

Todos os dados que não estão em um lakehouse do Databricks podem ser considerados dados externos. Alguns exemplos de dados externos incluem o seguinte:

• Tabelas estrangeiras registradas na Federação do Lakehouse.
• Tabelas no metastore do Hive apoiadas por Parquet.
• Tabelas externas no Catálogo do Unity apoiadas por JSON.
• Dados CSV armazenados no armazenamento de objetos de nuvem.
• Dados de streaming lidos do Kafka.

O Azure Databricks dá suporte à configuração de conexões para muitas fontes de dados. Confira Conectar-se às fontes de dados.

Embora você possa usar o Catálogo do Unity 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 no lakehouse.

O Delta Lake fornece todas as garantias transacionais no Azure Databricks, que são cruciais para manter a integridade e a consistência dos dados. Se você quiser saber mais sobre garantias transacionais nos dados do Azure Databricks e por que elas são importantes, confira Quais são as garantias ACID no Azure Databricks?.

A maioria dos usuários do Azure Databricks consulta uma combinação de dados do lakehouse e dados externos. A conexão a dados externos é sempre a primeira etapa para ingestão de dados e pipelines de ETL que trazem dados para o lakehouse. Para obter informações sobre como ingerir dados, confira Ingerir dados em um lakehouse do Azure Databricks.

Tabelas de consulta por nome

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

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

Sem o Catálogo do Unity, os identificadores de tabela usam o formato <schema-name>.<table-name>.

Há suporte para consulta por nome de tabela em todos os contextos de execução do Azure Databricks e idiomas compatíveis.

SQL

SELECT * FROM catalog_name.schema_name.table_name

Python

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

Resolução do identificador do Catálogo do 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:

O que é o catálogo e o esquema atuais?

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

Todos os workspaces configurados com o Catálogo do Unity têm um catálogo padrão definido no nível do workspace. Confira Gerenciar o catálogo padrão.

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

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

Consultar dados por caminho

Você pode consultar dados estruturados, semi-estruturados e não estruturados usando caminhos de arquivo. A maioria dos arquivos no Azure Databricks tem o apoio do armazenamento de objetos na nuvem. Consulte Trabalhar com arquivos no Azure Databricks.

O Databricks recomenda configurar todo o acesso ao armazenamento de objetos de nuvem usando o Catálogo do Unity 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 de nuvem usando nomes de catálogo e esquema para o caminho do arquivo. Confira Conectar-se ao armazenamento e aos serviços de objetos de nuvem usando o Catálogo do Unity.

Os exemplos a seguir demonstram como usar caminhos de volume do Catálogo do Unity 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 de nuvem que não estão configurados como volumes do Catálogo do Unity, você pode consultar dados diretamente usando URIs. Você deve configurar o acesso ao armazenamento de objetos de nuvem para consultar dados com URIs. Consulte Configurar o acesso ao armazenamento de objetos de nuvem para o Azure Databricks.

Os exemplos a seguir demonstram como usar URIs para consultar dados JSON no Azure Data Lake Storage Gen2, 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 SQL warehouses

O Azure Databricks usa SQL warehouses para computação nas seguintes interfaces:

• Editor SQL
• Consultas SQL do Databricks
• Dashboards
• Painéis herdados
• Alertas do SQL

Opcionalmente, você pode usar os SQL warehouses com os seguintes produtos:

• Notebooks do Databricks
• Editor de arquivos do Databricks
• Trabalhos do Databricks

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

Para workspaces habilitados para o Catálogo Unity, os SQL Warehouses sempre usam o Catálogo Unity para gerenciar o acesso a fontes de dados.

A maioria das consultas que são executadas em SQL Warehouses tem como alvo tabelas. As consultas direcionadas aos arquivos de dados devem aproveitar os volumes do Catálogo do Unity para gerenciar o acesso aos locais de armazenamento.

O uso de URIs diretamente em consultas executadas em SQL warehouses pode causar erros inesperados.

Consultar dados usando computação de todas as finalidades ou computação de trabalhos

A maioria das consultas executadas em notebooks do Databricks, fluxos de trabalho e no 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 computação de trabalhos que alimentam os 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. Com a movimentação de uma carga de trabalho interativa da computação de todas as finalidades para a computação de trabalhos, você pode economizar tempo e processar custos removendo consultas que exibem resultados.

O Apache Spark usa a execução lenta de código, 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 resultados. Isso contrasta com o modo de execução adiantado usado no pandas, que exige que os cálculos sejam processados em ordem antes de passar os resultados para o próximo método.

Se sua meta for salvar dados limpos, transformados e agregados como um novo conjunto de dados, você deverá remover consultas que exibem resultados do código antes de agendá-los para execução.

Para pequenas operações e pequenos conjuntos de dados, a economia de tempo e custo pode ser mínima. Ainda assim, com operações grandes, um tempo substancial pode ser desperdiçado calculando e imprimindo resultados em um bloco de anotações que pode não ser inspecionado manualmente. Os mesmos resultados provavelmente podem ser consultados da saída salva quase sem custo depois de armazená-los.