Explorando Delta Lake: Aplicación y Evolución del Esquema

Prueba esta serie de notebooks en Databricks

Los datos, al igual que nuestras experiencias, están en constante evolución y acumulación. Para mantenernos al día, nuestros modelos mentales del mundo deben adaptarse a nuevos datos, algunos de los cuales contienen nuevas dimensiones: nuevas formas de ver cosas que antes no concebíamos. Estos modelos mentales no se diferencian de un esquema de tabla, que define cómo categorizamos y procesamos la nueva información.

Esto nos lleva a la gestión de esquemas. A medida que los problemas y requisitos empresariales evolucionan con el tiempo, también lo hace la estructura de sus datos. Con Delta Lake, a medida que los datos cambian, incorporar nuevas dimensiones es fácil. Los usuarios tienen acceso a semánticas sencillas para controlar el esquema de sus tablas. Estas herramientas incluyen la aplicación de esquemas, que evita que los usuarios contaminen accidentalmente sus tablas con errores o datos basura, así como la evolución de esquemas, que les permite añadir automáticamente nuevas columnas de datos enriquecidos cuando esas columnas pertenecen. En este blog, profundizaremos en el uso de estas herramientas.

Entendiendo los Esquemas de Tablas

Cada DataFrame en Apache Spark™ contiene un esquema, un plano que define la forma de los datos, como tipos de datos y columnas, y metadatos. Con Delta Lake, el esquema de la tabla se guarda en formato JSON dentro del registro de transacciones.

¿Qué es la Aplicación de Esquemas?

La aplicación de esquemas, también conocida como validación de esquemas, es una salvaguarda en Delta Lake que garantiza la calidad de los datos al rechazar escrituras en una tabla que no coinciden con el esquema de la tabla. Al igual que el recepcionista de un restaurante concurrido que solo acepta reservas, comprueba si cada columna de los datos insertados en la tabla está en su lista de columnas esperadas (en otras palabras, si cada una tiene una "reserva"), y rechaza cualquier escritura con columnas que no estén en la lista.

¿Cómo Funciona la Aplicación de Esquemas?

Delta Lake utiliza la validación de esquemas en la escritura, lo que significa que todas las nuevas escrituras en una tabla se comprueban para ver si son compatibles con el esquema de la tabla de destino en el momento de la escritura. Si el esquema no es compatible, Delta Lake cancela la transacción por completo (no se escriben datos) y genera una excepción para informar al usuario de la discrepancia.

Para determinar si una escritura en una tabla es compatible, Delta Lake utiliza las siguientes reglas. El DataFrame que se va a escribir:

• No puede contener columnas adicionales que no estén presentes en el esquema de la tabla de destino. Por el contrario, está bien si los datos entrantes no contienen todas las columnas de la tabla; esas columnas simplemente se asignarán con valores nulos.
• No puede tener tipos de datos de columna que difieran de los tipos de datos de columna en la tabla de destino. Si una columna de la tabla de destino contiene datos de tipo StringType, pero la columna correspondiente en el DataFrame contiene datos de tipo IntegerType, la aplicación de esquemas generará una excepción y evitará que se realice la operación de escritura.
• No puede contener nombres de columna que difieran solo por mayúsculas/minúsculas. Esto significa que no puede tener columnas como 'Foo' y 'foo' definidas en la misma tabla. Mientras que Spark se puede usar en modo sensible o insensible a mayúsculas/minúsculas (por defecto), Delta Lake conserva las mayúsculas/minúsculas pero es insensible al almacenar el esquema. Parquet es sensible a mayúsculas/minúsculas al almacenar y devolver información de columnas. Para evitar posibles errores, corrupción de datos o problemas de pérdida (que hemos experimentado personalmente en Databricks), decidimos añadir esta restricción.

Para ilustrar, eche un vistazo a lo que sucede en el siguiente código cuando se intenta añadir algunas columnas recién calculadas a una tabla de Delta Lake que aún no está configurada para aceptarlas.

En lugar de añadir automáticamente las nuevas columnas, Delta Lake aplica el esquema y detiene la escritura. Para ayudar a identificar qué columna(s) causaron la discrepancia, Spark imprime ambos esquemas en el stack trace para su comparación.

¿Cómo es Útil la Aplicación de Esquemas?

Debido a que es una verificación tan rigurosa, la aplicación de esquemas es una excelente herramienta para usar como guardián de un conjunto de datos limpio y completamente transformado que está listo para producción o consumo. Normalmente se aplica en tablas que alimentan directamente:

• Algoritmos de machine learning
• Paneles de BI
• Herramientas de análisis y visualización de datos
• Cualquier sistema de producción que requiera esquemas semánticos altamente estructurados y fuertemente tipados

Para preparar sus datos para este obstáculo final, muchos usuarios emplean una arquitectura simple de "múltiples saltos" que agrega progresivamente estructura a sus tablas. Para obtener más información, consulte la publicación titulada Producción de Machine Learning con Delta Lake.

Por supuesto, la aplicación de esquemas se puede usar en cualquier lugar de su pipeline, pero tenga en cuenta que puede ser un poco frustrante que su escritura en streaming a una tabla falle porque olvidó que agregó una sola columna a los datos entrantes, por ejemplo.

Prevención de la Dilución de Datos

En este punto, podría preguntarse, ¿por qué tanto alboroto? Después de todo, a veces un error inesperado de "discrepancia de esquema" puede tropezarlo en su flujo de trabajo, especialmente si es nuevo en Delta Lake. ¿Por qué no dejar que el esquema cambie como sea necesario para que pueda escribir mi DataFrame sin importar qué?

Como dice el viejo refrán: "más vale prevenir que curar". En algún momento, si no aplica su esquema, surgirán problemas de compatibilidad de tipos de datos; fuentes de datos aparentemente homogéneas pueden contener casos extremos, columnas corruptas, mapeos mal formados u otras cosas aterradoras que ocurren en la noche. Un enfoque mucho mejor es detener a estos enemigos en las puertas, usando la aplicación de esquemas, y lidiar con ellos a la luz del día en lugar de más tarde, cuando estarán acechando en los rincones sombríos de su código de producción.

La aplicación de esquemas proporciona la tranquilidad de que el esquema de su tabla no cambiará a menos que usted tome la decisión afirmativa de cambiarlo. Evita la "dilución" de datos, que puede ocurrir cuando se agregan nuevas columnas con tanta frecuencia que las tablas anteriormente ricas y concisas pierden su significado y utilidad debido al diluvio de datos. Al animarle a ser intencional, establecer altos estándares y esperar alta calidad, la aplicación de esquemas está haciendo exactamente lo que fue diseñada para hacer: mantenerlo honesto y sus tablas limpias.

Si, tras una revisión adicional, decide que realmente quería añadir esa nueva columna, es una solución fácil de una línea, como se discute a continuación. ¡La solución es la evolución de esquemas!

¿Qué es la Evolución de Esquemas?

La evolución de esquemas es una característica que permite a los usuarios cambiar fácilmente el esquema actual de una tabla para acomodar datos que cambian con el tiempo. Lo más común es que se use al realizar una operación de adición o sobrescritura, para adaptar automáticamente el esquema e incluir una o más columnas nuevas.

¿Cómo Funciona la Evolución de Esquemas?

Siguiendo el ejemplo de la sección anterior, los desarrolladores pueden usar fácilmente la evolución de esquemas para agregar las nuevas columnas que fueron previamente rechazadas debido a una discrepancia de esquema. La evolución de esquemas se activa agregando  .option('mergeSchema', 'true') a su comando Spark .write o .writeStream.

Para ver el gráfico, ejecute la siguiente instrucción Spark SQL.

Alternatively, you can set this option for the entire Spark session by adding spark.databricks.delta.schema.autoMerge = True to your Spark configuration. Use with caution, as schema enforcement will no longer warn you about unintended schema mismatches.

By including the mergeSchema option in your query, any columns that are present in the DataFrame but not in the target table are automatically added on to the end of the schema as part of a write transaction. Nested fields can also be added, and these fields will get added to the end of their respective struct columns as well.

Data engineers and scientists can use this option to add new columns (perhaps a newly tracked metric, or a column of this month's sales figures) to their existing machine learning production tables without breaking existing models that rely on the old columns.

The following types of schema changes are eligible for schema evolution during table appends or overwrites:

• Adding new columns (this is the most common scenario)
• Changing of data types from NullType -> any other type, or upcasts from ByteType -> ShortType -> IntegerType

Other changes, which are not eligible for schema evolution, require that the schema and data are overwritten by adding .option("overwriteSchema", "true"). For example, in the case where the column "Foo" was originally an integer data type and the new schema would be a string data type, then all of the Parquet (data) files would need to be re-written.  Those changes include:

• Dropping a column
• Changing an existing column's data type (in place)
• Renaming column names that differ only by case (e.g. "Foo" and "foo")

Finally, with the upcoming release of Spark 3.0, explicit DDL (using ALTER TABLE) will be fully supported, allowing users to perform the following actions on table schemas:

• Adding  columns
• Changing column comments
• Setting table properties that define the behavior of the table, such as setting the retention duration of the transaction log

How is Schema Evolution Useful?

Schema evolution can be used anytime you intend  to change the schema of your table (as opposed to where you accidentally added columns to your DataFrame that shouldn't be there). It's the easiest way to migrate your schema because it automatically adds the correct column names and data types, without having to declare them explicitly.

Summary

Schema enforcement rejects any new columns or other schema changes that aren't compatible with your table. By setting and upholding these high standards, analysts and engineers can trust that their data has the highest levels of integrity, and reason about it with clarity, allowing them to make better business decisions.

On the flip side of the coin, schema evolution complements enforcement by making it easy for intended schema changes to take place automatically. After all, it shouldn't be hard to add a column.

Schema enforcement is the yin to schema evolution's yang. When used together, these features make it easier than ever to block out the noise, and tune in to the signal.

We'd also like to thank Mukul Murthy and Pranav Anand for their contributions to this blog.

Related

Articles in this series:
Diving Into Delta Lake #1: Unpacking the Transaction Log
Diving Into Delta Lake #2: Schema Enforcement & Evolution
Diving Into Delta Lake #3: DML Internals (Update, Delete, Merge)

Productionizing Machine Learning With Delta Lake
What Is A Data Lake?

(Esta entrada del blog ha sido traducida utilizando herramientas basadas en inteligencia artificial) Publicación original