Consultar os dados

Consultar dados é a etapa fundamental para executar quase todas as tarefas controladas 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 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 ficheiros
• Dashboards

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

Para obter uma visão geral das consultas de streaming no Azure Databricks, consulte 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 de duas categorias amplas: dados em um 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 lakehouse no Azure 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 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 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 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:

• Mesas 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.
• Streaming de dados lidos de Kafka.

O Azure Databricks dá suporte à configuração de conexões com muitas 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 na casa do lago.

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, consulte O que são garantias ACID no Azure Databricks?.

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

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 idiomas suportados.

SQL

SELECT * FROM catalog_name.schema_name.table_name

Python

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

Consultar dados por caminho

Você pode consultar dados estruturados, semiestruturados e não estruturados usando caminhos de arquivo. A maioria dos arquivos no Azure Databricks é apoiada pelo armazenamento de objetos na nuvem. Consulte Trabalhar com arquivos no 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. Consulte Configurar o acesso ao armazenamento de objetos na 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 armazéns SQL

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

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

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

• Notebooks Databricks
• Editor de arquivos Databricks
• Tarefas do Databricks

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 que são executadas em tabelas de destino de armazéns SQL. 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 para todas as finalidades ou computação de trabalhos

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 para a computação de trabalhos, você pode economizar tempo e custos de processamento removendo 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 provavelmente poderiam ser consultados a partir da saída salva quase sem custo depois de armazená-los.