Consultar dados

Consultar dados é o passo fundamental para realizar quase todas as tarefas data-driven no Databricks. Independentemente da linguagem ou da ferramenta usada, as cargas de trabalho começam definindo uma consulta em uma tabela ou outra fonte de dados e, em seguida, executam ações para extrair insights dos dados. Este artigo descreve os principais conceitos e procedimentos para executar consultas em várias ofertas de produtos do Databricks e inclui exemplos de código que você pode adaptar ao seu caso de uso.

Você pode consultar dados interativamente usando:

  • Notebooks

  • Editor de SQL

  • Editor de arquivos

  • Painéis

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

Para uma visão geral das consultas de transmissão no Databricks, veja Consultar dados de transmissão.

Quais dados é possível consultar com o Databricks?

O Databricks permite a consulta de dados em vários formatos e sistemas empresariais. Os dados que você consulta usando o Databricks se enquadram em uma das duas categorias amplas: dados em um lakehouse do Databricks e dados externos.

Quais dados estão em um lakehouse do Databricks?

Por padrão, a Databricks Data Intelligence Platform armazena todos os seus dados em um lakehouse do Databricks.

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

  • Armazenados no formato Delta Lake.

  • Armazenados no armazenamento de objetos na cloud.

  • Governado pelo Unity Catalog.

A maioria dos dados do lakehouse no Databricks é registrada no Unity Catalog 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 bancos de dados relacionais. As tabelas gerenciadas são recomendadas para a maior parte dos casos de uso e são indicadas 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. As tabelas não gerenciadas podem ser preferidas pelos usuários que acessam diretamente as tabelas de outros clientes do leitor Delta. Para obter uma visão geral das diferenças na semântica das tabelas, consulte O que são tabelas e visualizações?

Algumas cargas de trabalho antigas 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 de lakehouse, mas podem ser mais difíceis de descobrir, já que não estão registrados no Unity Catalog.

Observação

O administrador do workspace pode não ter atualizado sua governança de dados para usar o Unity Catalog. Você ainda pode ter muitos dos benefícios de um lakehouse do Databricks sem o Unity Catalog, mas nem todas as funcionalidades indicadas neste artigo ou na documentação do Databricks são aceitas.

Quais dados são considerados externos?

Quaisquer dados que não estejam em um lakehouse do Databricks podem ser considerados externos. Alguns exemplos de dados externos são:

  • Tabelas externas registradas na Lakehouse Federation.

  • Tabelas no Hive metastore com suporte do Parquet.

  • Tabelas externas no Unity Catalog com suporte de JSON.

  • Dados CSV armazenados no armazenamento de objetos na cloud.

  • Dados de transmissão lidos do Kafka.

O Databricks permite a configuração de conexões com várias fontes de dados. Consulte Conectar-se a fontes de dados.

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 no lakehouse.

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

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

Consultar tabelas por nome

Para todos os dados registrados como uma tabela, a Databricks recomenda fazer consultas 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 utilizam o formato <schema-name>.<table-name>.

Observação

O Databricks herda grande parte de sua sintaxe SQL do Apache Spark, que não distingue entre SCHEMA e DATABASE.

A consulta pelo nome da tabela é permitida em todos os contextos de execução e linguagens compatíveis do Databricks.

SELECT * FROM catalog_name.schema_name.table_name

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

Consultar dados por caminho

É possível consultar dados estruturados, semiestruturados e não estruturados usando caminhos de arquivo. A maioria dos arquivos no Databricks são apoiados pelo armazenamento de objetos na cloud. Consulte Trabalhe com arquivos no Databricks.

Databricks recomenda configurar todo o acesso ao armazenamento de objetos cloud usando Unity Catalog e definindo 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 do cloud usando nomes de catálogos e esquemas para o caminho do arquivo. Consulte Conectar-se ao serviço e armazenamento de objetos cloud usando Unity Catalog.

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

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

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

Para locais na cloud que não estejam configurados como volumes do Unity Catalog, você pode consultar os dados diretamente com URIs. É necessário configurar o acesso ao armazenamento de objetos na cloud para consultar dados com URIs. Consulte Configurar acesso ao armazenamento de objetos na cloud para o Databricks.

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

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`;

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 Databricks utiliza SQL warehouses para compute nas seguintes interfaces:

  • Editor de SQL

  • Consultas Databricks SQL

  • Painéis

  • Dashboards legados

  • Alertas SQL

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

  • Notebooks do Databricks

  • Editor de arquivos do Databricks

  • Jobs do Databricks

Ao consultar dados com SQL warehouses, você pode usar somente a sintaxe SQL. Outras linguagens de programação e APIs não são aceitas.

Para workspaces habilitados para o Unity Catalog, os SQL warehouses sempre usam o Unity Catalog para gerenciar o acesso a fontes de dados.

A maioria das consultas executadas em SQL warehouses têm como destino tabelas. Consultas direcionadas a arquivos de dados devem aproveitar os volumes do Unity Catalog para gerenciar o acesso aos locais de armazenamento.

Usar URIs diretamente em consultas executadas em SQL warehouses pode levar a erros inesperados.

Consultar dados usando compute para múltiplas finalidades ou compute de jobs

A maioria das consultas executadas em notebooks, fluxos de trabalho e editor de arquivos do Databricks é realizada em clusters de compute configurados com o Databricks Runtime. Você pode configurar esses clusters para serem executados interativamente ou implantá-los como compute de jobs que alimentam fluxos de trabalho. A Databricks recomenda que você sempre utilize compute de jobs para cargas de trabalho não interativas.

Cargas de trabalho interativas versus não interativas

Muitos usuários acham útil visualizar os resultados da consulta enquanto as transformações são processadas durante o desenvolvimento. Ao migrar uma carga de trabalho interativa de compute para múltiplas finalidades para compute de jobs, é possível economizar tempo e custos de processamento removendo consultas que exibem resultados.

O Apache Spark utiliza execução de código lenta, o que significa que os resultados são calculados apenas conforme necessário. Além disso, 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 rápido 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 o seu objetivo é salvar dados limpos, transformados e agregados como um novo dataset, remova as consultas que exibem resultados do seu código antes de programá-las para execução.

Para pequenas operações e pequenos datasets, a economia de tempo e custo pode ser marginal. Ainda assim, com operações de grande porte, pode-se desperdiçar muito tempo calculando e imprimindo resultados em um notebook que pode não ser inspecionado manualmente. Os mesmos resultados provavelmente poderiam ser consultados na saída salva quase sem custo após seu armazenamento.