Consultar dados

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

Você pode query dados interativamente usando:

  • Notebooks

  • Editor de SQL

  • Editor de arquivos

  • Painéis

Você também pode executar consultas como parte do pipeline ou fluxo de trabalho do Delta Live Tables.

Para obter uma visão geral da query de transmissão no Databricks, consulte query transmissão data.

Quais dados você pode consultar com Databricks?

Databricks oferece suporte à consulta de dados em vários formatos e sistemas corporativos. Os dados que você query usando o Databricks se enquadram em uma de duas categorias amplas: dados em um databricks lakehouse e dados externos.

Quais dados estão em um lakehouse do Databricks?

A Databricks Data Intelligence Platform armazena todos os seus dados em um databricks lakehouse por default.

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

  • Armazenado no formato Delta Lake.

  • Armazenado em armazenamento de objetos clouds .

  • Governado pelo Unity Catalog.

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

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

Observação

O administrador do seu workspace pode não ter atualizado a governança de dados para usar o Unity Catalog. Você ainda pode obter muitos dos benefícios de um databricks lakehouse sem Unity Catalog, mas nem todas as funcionalidades listadas nestes artigos ou em toda a documentação do Databricks são suportadas.

Quais dados são considerados externos?

Quaisquer dados que não estejam num lakehouse do Databricks podem ser considerados dados externos. Alguns exemplos de dados externos incluem o seguinte:

  • Tabelas estrangeiras registradas na lakehouse Federation.

  • Tabelas no Hive metastore apoiadas por Parquet.

  • Tabelas externas no Unity Catalog apoiadas por JSON.

  • Dados CSV armazenados em armazenamento de objetos clouds .

  • dados de transmissão lidos do Kafka.

Databricks oferece suporte à configuração de conexões com muitas fontes de dados. Consulte Conectar-se à fonte 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, Delta Lake é um requisito para que os dados sejam considerados no lakehouse.

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

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

Consultar tabelas por nome

Para todos os dados registados como tabela, a Databricks recomenda a consulta utilizando 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>.

Observação

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

A consulta por nome de tabela tem suporte em todos os contextos de execução do Databricks e idiomas com suporte.

SELECT * FROM catalog_name.schema_name.table_name

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

Consultar dados por caminho

Você pode query caminhos de arquivos de uso de dados estruturados, semiestruturados e não estruturados. A maioria dos arquivos no Databricks é apoiada por armazenamento de objetos clouds . Consulte Trabalhar com arquivos no Databricks.

A Databricks recomenda configurar todo o acesso ao armazenamento de objetos clouds usando o Unity Catalog e definir volumes para locais de armazenamento de objetos que são query diretamente. Os volumes fornecem aliases legíveis para locais e arquivos no armazenamento de objetos clouds usando nomes de catálogo e esquema para o caminho do arquivo. Consulte Conectar-se ao armazenamento de objetos clouds usando o Unity Catalog.

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

Os exemplos a seguir demonstram como usar URIs para query 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 uso de dados SQL warehouse

Databricks usa SQL warehouse para compute nas seguintes interfaces:

  • Editor de SQL

  • Databricks SQL query

  • Painel do Databricks SQL

  • Alerta SQL

Opcionalmente, você pode usar SQL warehouse com o seguinte produto:

  • Databricks Notebook

  • Editor de arquivos Databricks

  • Fluxos de trabalho da Databricks

Ao query dados com SQL warehouse, você pode usar apenas a sintaxe SQL. Outras linguagens de programação e APIs não são suportadas.

Para workspace habilitados para o Unity Catalog, SQL warehouse sempre usa o Unity Catalog para gerenciar o acesso à fonte de dados.

A maioria query executadas em tabelas de destino SQL warehouse . query se os arquivos de dados de destino devem aproveitar os volumes do Unity Catalog para gerenciar o acesso aos locais de armazenamento.

Usar URIs diretamente na execução query no SQL warehouse pode levar a erros inesperados.

Consultar uso de dados para computação multifuncional ou computação Job

A maioria query que você executa no Databricks Notebook, no fluxo de trabalho e na execução do editor de arquivos em clusters compute configurados com o Databricks Runtime. Você pode configurar esses clusters para execução de forma interativa ou implantá-los como Job compute que potencializam o fluxo de . A Databricks recomenda que você sempre use Job compute para cargas de trabalho não interativas.

Cargas de trabalho interativas versus não interativas

Muitos usuários acham útil view os resultados query enquanto as transformações são processadas durante o desenvolvimento. Ao mover uma carga de trabalho interativa da multifuncional para compute Job compute, você pode economizar tempo e custos de processamento removendo query que exibem resultados.

O Apache Spark usa execução lenta de código, o que significa que os resultados são calculados apenas conforme necessário, e múltiplas transformações ou query em uma fonte de dados podem ser otimizadas como uma única query 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, você deve remover query que exibe os resultados do seu código antes de programá-lo para execução.

Para pequenas operações e pequenos dataset, a economia de tempo e custos pode ser marginal. Ainda assim, com grandes operações, pode-se perder muito tempo calculando e imprimindo resultados em um Notebook que pode não ser inspecionado manualmente. Os mesmos resultados provavelmente poderiam ser query a partir da saída salva quase sem nenhum custo após armazená-los.