Modelado de datos

En este artículo se presentan consideraciones, advertencias y recomendaciones para el modelado de datos en Azure Databricks. Está dirigido a los usuarios que configuran nuevas tablas o crean cargas de trabajo de ETL, poniendo énfasis en la comprensión de los comportamientos de Azure Databricks que influyen en la transformación de datos sin procesar en un nuevo modelo de datos. Las decisiones de modelado de datos dependen de cómo la organización y las cargas de trabajo usan tablas. El modelo de datos que elija afecta al rendimiento de las consultas, los costos de proceso y los costos de almacenamiento. Esto incluye una introducción a los conceptos fundamentales del diseño de bases de datos con Azure Databricks.

Conceptos de administración de bases de datos

Una instancia de Lakehouse creada con Azure Databricks comparte muchos componentes y conceptos con otros sistemas de almacenamiento de datos empresariales. Tenga en cuenta los siguientes conceptos y características al diseñar el modelo de datos.

Transacciones en Azure Databricks

Azure Databricks limita las transacciones a tablas individuales. Esto significa que Azure Databricks no admite instrucciones de varias tablas (también denominadas transacciones de varias instrucciones).

En el caso de las cargas de trabajo de modelado de datos, esto se traduce en tener que realizar varias transacciones independientes cuando la ingesta de un registro de origen requiere insertar o actualizar filas en dos o más tablas. Cada una de estas transacciones puede realizarse correctamente o producir errores independientemente de otras transacciones, y las consultas de nivel inferior deben ser tolerantes a la falta de coincidencia de estado debido a transacciones erróneas o retrasadas.

Claves principales y externas en Azure Databricks

Las claves principales y externas son informativas y no se aplican. Este modelo es común en muchos sistemas de base de datos basados en la nube empresarial, pero difiere de muchos sistemas tradicionales de bases de datos relacionales. Consulte Restricciones en Azure Databricks.

Combinaciones en Azure Databricks

Las combinaciones pueden introducir cuellos de botella de procesamiento en cualquier diseño de base de datos. Al procesar datos en Azure Databricks, el optimizador de consultas busca optimizar el plan de combinaciones, pero puede tener problemas cuando una consulta individual debe combinar resultados de muchas tablas. El optimizador también puede no omitir los registros de una tabla cuando los parámetros de filtro están en un campo de otra tabla, lo que puede dar lugar a un recorrido de tabla completo.

Consulte Trabajo con combinaciones en Azure Databricks.

Trabajo con tipos de datos anidados y complejos

Azure Databricks admite el trabajo con orígenes de datos semiestructurados, como JSON, Avro y ProtoBuff, y el almacenamiento de datos complejos como estructuras, cadenas JSON y asignaciones y matrices. Consulte Modelos de datos semiestructurados.

Modelos de datos normalizados

Azure Databricks puede funcionar bien con cualquier modelo de datos. Si tiene un modelo de datos existente que necesita consultar o migrar a Azure Databricks, debe evaluar el rendimiento antes de rediseñar los datos.

Si va a diseñar una nueva instancia de Lakehouse o agregar conjuntos de datos a un entorno existente, Azure Databricks recomienda usar un modelo muy normalizado, como la tercera forma normal (3NF).

Los modelos como el esquema de estrella o el esquema de copo de nieve funcionan bien en Azure Databricks, ya que hay menos combinaciones presentes en consultas estándar y menos claves para mantener la sincronización. Además, tener más campos de datos en una sola tabla permite al optimizador de consultas omitir grandes cantidades de datos mediante estadísticas de nivel de archivo. Para obtener más información sobre la omisión de datos, consulte Omisión de datos para Delta Lake.