Consultar datos

La consulta de datos es el paso fundamental para realizar casi todas las tareas controladas por datos en Azure Databricks. Independientemente del lenguaje o la herramienta que se use, las cargas de trabajo comienzan definiendo una consulta en una tabla u otro origen de datos y realizando acciones para obtener información de los datos. En este artículo se describen los conceptos básicos y los procedimientos para ejecutar consultas en varias ofertas de productos de Azure Databricks e incluye ejemplos de código que puede adaptar para su caso de uso.

Puede consultar datos de forma interactiva mediante:

• Cuaderno
• Editor SQL
• Editor de archivos
• Paneles

También puede ejecutar consultas como parte de canalizaciones o trabajos de Delta Live Tables.

Para obtener información general sobre las consultas de streaming en Azure Databricks, vea Consulta de datos de streaming.

¿Qué datos puede consultar con Azure Databricks?

Azure Databricks admite la consulta de datos en varios formatos y sistemas empresariales. Los datos que consulta mediante Azure Databricks se dividen en una de las dos categorías generales: los datos de una instancia de Databricks Lakehouse y datos externos.

¿Qué datos hay en una instancia de Databricks Lakehouse?

Databricks Data Intelligence Platform almacena todos los datos en una instancia de Databricks Lakehouse de forma predeterminada.

Esto significa que, al ejecutar una instrucción CREATE TABLE básica para crear una nueva tabla, ha creado una tabla lakehouse. Los datos de Lakehouse tienen las siguientes propiedades:

• Almacenado en el formato Delta Lake.
• Almacenado en el almacenamiento de objetos en la nube.
• Regido por el catálogo de Unity.

La mayoría de los datos de Lakehouse en Azure Databricks se registran en el catálogo de Unity como tablas administradas. Las tablas administradas proporcionan la sintaxis más sencilla y se comportan como otras tablas en la mayoría de los sistemas de administración de bases de datos relacionales. Las tablas administradas se recomiendan para la mayoría de los casos de uso y son adecuadas para todos los usuarios que no quieren preocuparse por los detalles de implementación del almacenamiento de datos.

Una tabla no administrada, o tabla externa, es una tabla registrada con un LOCATION especificado. El término externo puede ser engañoso, ya que las tablas delta externas siguen siendo datos de lakehouse. Las tablas no administradas pueden ser preferidas por los usuarios que acceden directamente a las tablas de otros clientes de lector delta. Para obtener información general sobre las diferencias en la semántica de tablas, consulte ¿Qué son las tablas y vistas?.

Algunas cargas de trabajo heredadas pueden interactuar exclusivamente con los datos de Delta Lake a través de rutas de acceso de archivo y no registrar tablas en absoluto. Estos datos siguen siendo datos de lakehouse, pero pueden ser más difíciles de detectar porque no están registrados en Unity Catalog.

Nota:

Es posible que el administrador del área de trabajo no haya actualizado la gobernanza de datos para usar Unity Catalog. Todavía puede obtener muchas de las ventajas de una instancia de Databricks lakehouse sin Unity Catalog, pero no todas las funcionalidades enumeradas en este artículo o en toda la documentación de Azure Databricks son compatibles.

¿Qué datos se consideran externos?

Los datos que no están en una instancia de Databricks Lakehouse se pueden considerar datos externos. Algunos ejemplos de datos externos son los siguientes:

• Tablas extranjeras registradas con la Federación de Lakehouse.
• Tablas del metastore de Hive respaldadas por Parquet.
• Tablas externas de Unity Catalog respaldadas por JSON.
• Datos CSV almacenados en el almacenamiento de objetos en la nube.
• Datos de streaming leídos de Kafka.

Azure Databricks admite la configuración de conexiones a muchos orígenes de datos. Vea Conexión a orígenes de datos.

Aunque puede usar Unity Catalog para controlar el acceso a y definir tablas en los datos almacenados en varios formatos y sistemas externos, Delta Lake es un requisito para que los datos se consideren en lakehouse.

Delta Lake proporciona todas las garantías transaccionales en Azure Databricks, que son cruciales para mantener la integridad y la coherencia de los datos. Si desea obtener más información sobre las garantías transaccionales en los datos de Azure Databricks y por qué son importantes, vea ¿Qué son las garantías ACID en Azure Databricks?.

La mayoría de los usuarios de Azure Databricks consultan una combinación de datos de lakehouse y datos externos. La conexión con datos externos siempre es el primer paso para las canalizaciones de ingesta de datos y ETL que incorporan datos a lakehouse. Para obtener información sobre la ingesta de datos, vea Ingesta de datos en un lago de datos de Databricks.

Tablas de consulta por nombre

Para todos los datos registrados como una tabla, Databricks recomienda consultar con el nombre de la tabla.

Si usa Unity Catalog, las tablas usan un espacio de nombres de tres niveles con el formato siguiente: <catalog-name>.<schema-name>.<table-name>.

Sin Unity Catalog, los identificadores de tabla usan el formato <schema-name>.<table-name>.

Nota:

Azure Databricks hereda gran parte de su sintaxis SQL de Apache Spark, que no diferencia entre SCHEMA y DATABASE.

La consulta por nombre de tabla se admite en todos los contextos de ejecución de Azure Databricks y en los lenguajes admitidos.

SQL

SELECT * FROM catalog_name.schema_name.table_name

Python

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

Consulta de datos por ruta de acceso

Puede consultar datos estructurados, semiestructurados y no estructurados mediante rutas de acceso de archivo. La mayoría de los archivos de Azure Databricks están respaldados por el almacenamiento de objetos en la nube. Consulte Trabajar con archivos en Azure Databricks.

Databricks recomienda configurar todo el acceso al almacenamiento de objetos en la nube mediante Unity Catalog y definir volúmenes para ubicaciones de almacenamiento de objetos que se consultan directamente. Los volúmenes proporcionan alias legibles a ubicaciones y archivos en el almacenamiento de objetos en la nube mediante nombres de catálogo y esquema para la ruta de acceso a archivos. Consulte Conexión al almacenamiento y servicios de objetos en la nube mediante el catálogo de Unity.

En los ejemplos siguientes se muestra cómo usar rutas de acceso de volumen del Unity Catalog para leer datos 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")

En el caso de las ubicaciones en la nube que no están configuradas como volúmenes de Unity Catalog, puede consultar datos directamente mediante URI. Debe configurar el acceso al almacenamiento de objetos en la nube para consultar datos con URI. Vea Configuración del acceso al almacenamiento de objetos en la nube de Azure Databricks.

En los ejemplos siguientes se muestra cómo usar los URI para consultar datos JSON en Azure Data Lake Storage Gen2, GCS y 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")

Consulta de datos mediante almacenes de SQL

Azure Databricks usa almacenes de SQL para el proceso en las interfaces siguientes:

• Editor SQL
• Consultas SQL de Databricks
• Paneles
• Paneles heredados
• Alertas de SQL

Opcionalmente, puede usar almacenes de SQL con los siguientes productos:

• Cuadernos de Databricks
• Editor de archivos de Databricks
• Trabajos de Databricks

Al consultar datos con almacenes de SQL, solo puede usar la sintaxis SQL. No se admiten otros lenguajes de programación ni API.

En el caso de las áreas de trabajo habilitadas para Unity Catalog, los almacenes de SQL siempre usan el Unity Catalog para administrar el acceso a los orígenes de datos.

La mayoría de las consultas que se ejecutan en tablas de destino de SQL warehouse. Las consultas que tienen como destino los archivos de datos deben aprovechar los volúmenes de Unity Catalog para administrar el acceso a las ubicaciones de almacenamiento.

El uso de URI directamente en consultas que se ejecutan en almacenes de SQL puede provocar errores inesperados.

Consulta de datos mediante todos los procesos de proceso o trabajos de uso

La mayoría de las consultas que se ejecutan desde cuadernos, flujos de trabajo y cuadernos de Databricks se ejecutan en clústeres de proceso configurados con Databricks Runtime. Puede configurar estos clústeres para que se ejecuten de forma interactiva o implementarlos como trabajos de proceso que impulsan los flujos de trabajo. Databricks recomienda usar siempre el proceso de trabajos para cargas de trabajo no interactivas.

Cargas de trabajo interactivas frente a no interactivas

Muchos usuarios consideran útil ver los resultados de la consulta mientras se procesan las transformaciones durante el desarrollo. Al mover una carga de trabajo interactiva del proceso de uso completo al proceso de trabajos, puede ahorrar tiempo y procesar los costos mediante la eliminación de consultas que muestran los resultados.

Apache Spark usa la ejecución diferida de código, lo que significa que los resultados se calculan solo según sea necesario y se pueden optimizar varias transformaciones o consultas en un origen de datos como una sola consulta si no fuerza los resultados. Esto contrasta con el modo de ejecución diligente usado en pandas, que requiere que los cálculos se procesen en orden antes de pasar los resultados al método siguiente.

Si el objetivo es guardar los datos limpios, transformados y agregados como un nuevo conjunto de datos, debe quitar las consultas que muestran los resultados del código antes de programarlos para que se ejecuten.

En el caso de las operaciones pequeñas y los conjuntos de datos pequeños, el tiempo y el ahorro de costos pueden ser marginales. Sin embargo, con operaciones grandes, se puede desperdiciar el tiempo considerable calculando e imprimiendo resultados en un cuaderno que podría no inspeccionarse manualmente. Es probable que se consulten los mismos resultados de la salida guardada casi sin costo después de almacenarlos.