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 são tabelas e modos de exibição?.
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.
Nota
O administrador do espaço de trabalho pode não ter atualizado sua governança de dados para usar o Catálogo Unity. Você ainda pode obter muitos dos benefícios de uma casa de lago Databricks sem o Catálogo Unity, mas nem todas as funcionalidades listadas neste artigo ou em toda a documentação do Azure Databricks são suportadas.
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 Ingestão de dados num lakehouse Azure 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>.
Nota
O Azure 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 é 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")
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:
| Padrão identificador | Comportamento |
|---|---|
catalog_name.schema_name.object_name |
Refere-se ao objeto de banco de dados especificado pelo identificador. |
schema_name.object_name |
Refere-se ao objeto de banco de dados associado aos schema_name e object_name especificados no catálogo atual. |
object_name |
Refere-se ao objeto de banco de dados associado ao object_name especificado no catálogo e esquema atuais. |
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:
| Produto | Configuração |
|---|---|
| Computação polivalente ou para tarefas | Defina a spark.databricks.sql.initial.catalog.namespace de configuração do Spark ao configurar a computação. |
| Tabelas Delta Live | O catálogo e o esquema especificados durante a configuração do pipeline substituem os padrões do espaço de trabalho para toda a lógica do pipeline. |
Nota
O catálogo ou esquema padrão também pode ser definido por configurações JDBC ao se conectar a sistemas externos ou metastores. Entre em contato com o administrador responsável pela configuração de seus sistemas integrados e de computação Databricks se encontrar um comportamento padrão inesperado.
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.
| Declaração | Resultado |
|---|---|
USE CATALOG catalog_name |
Define o catálogo atual usando o catalog_namefornecido . Define o esquema atual como default. |
USE SCHEMA schema_name |
Define o esquema atual usando o schema_name fornecido no catálogo atual. |
USE SCHEMA catalog_name.schema_name |
Defina o catálogo atual usando o catalog_name fornecido e o esquema atual usando o schema_namefornecido. |
Nota
Consultas e comandos que usam identificadores totalmente qualificados para interagir com objetos como tabelas, exibições, funções ou modelos não alteram o catálogo ou esquema atual e sempre se referem ao objeto especificado.
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 e serviços 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.