paint-brush
Cómo administrar el cambio de esquema con Apache Pulsarpor@datastax
398 lecturas
398 lecturas

Cómo administrar el cambio de esquema con Apache Pulsar

por DataStax5m2023/05/30
Read on Terminal Reader

Demasiado Largo; Para Leer

Los esquemas proporcionan un modelo de formato de datos. Son el pegamento entre los servicios y el middleware. Cuando el modelo cambia, debe ser un evento elegante que admita diferentes versiones. Aprenda cómo la plataforma de mensajería Apache Pulsar proporciona una forma simple y limpia de administrar esquemas entre temas.
featured image - Cómo administrar el cambio de esquema con Apache Pulsar
DataStax HackerNoon profile picture
0-item


Los esquemas son una parte esencial de cualquier plataforma de datos. Son metadatos que definen la forma de los datos y los nombres y tipos de datos de las propiedades. Los esquemas son útiles de dos maneras. En primer lugar, proporcionan un modelo fijo para el formato de los datos, lo que puede evitar que se utilicen datos mal formados en el contexto del esquema. En segundo lugar, los esquemas permiten a los usuarios comprender cómo analizar los datos y qué esperar de sus propiedades.


Apache Pulsar es un sistema de mensajería distribuido de publicación-suscripción (pub-sub) de código abierto que permite el transporte de datos de servidor a servidor usando el esquema . Los mensajes se envían a través de temas, y el productor coloca mensajes en estos temas para que los lea el consumidor. Un usuario puede definir un esquema para un tema almacenado en el registro de esquemas de Pulsar. Cuando se agregan mensajes al tema, el intermediario Pulsar verifica que el mensaje se ajuste al esquema y se asegura de que solo se envíen mensajes válidos. El esquema actúa como un contrato entre el productor y los consumidores, lo que permite que ambas partes conozcan el formato exacto de los datos.


Con el tiempo, a medida que las aplicaciones evolucionan, es posible que los datos producidos por la aplicación también cambien. Sin embargo, los cambios de esquema pueden afectar a los consumidores finales de los datos que esperan datos en un formato específico. Sin una forma de administrar esquemas entre productores y consumidores, es difícil realizar cambios en los datos que se escriben en los mensajes o eventos sin correr el riesgo de romper las aplicaciones posteriores. Para evitar este tipo de problema, el esquema de los mensajes también debe evolucionar a medida que se agregan nuevas propiedades y permitir que los consumidores comprendan los datos tanto en el formato antiguo como en el nuevo. Este concepto se conoce como evolución de esquema y Pulsar lo respalda.


Este artículo analiza por qué los esquemas evolucionan antes de sumergirse en cómo Pulsar implementa y admite la evolución del esquema.

Por qué evolucionan los esquemas

Los esquemas proporcionan contexto sobre los datos sin procesar. A menudo describen una entidad particular en un sistema, abarcando todas las propiedades de esa entidad. Por ejemplo, puede tener una aplicación que registre usuarios. Almacena detalles de usuario como nombres, direcciones de correo electrónico y edades. Habría un esquema de usuario que describe los datos subyacentes y proporciona contexto, como el nombre del campo y el tipo de datos que contiene. El esquema puede tener el siguiente aspecto:


Ahora, digamos que desea expandir los datos capturados para incluir datos de direcciones y admitir el envío directo de correos a los usuarios. Luego deberá expandir el esquema para incluir los nuevos campos para capturar direcciones, como la primera línea de la dirección, la ciudad y el código postal. Después de incluir estos nuevos campos, el esquema se verá así:


Esta es una forma simple de evolución del esquema, ya que los campos originales no han cambiado y solo se han agregado nuevos campos. En la mayoría de los casos, esto no debería ser un cambio importante para los consumidores intermedios, ya que los consumidores pueden continuar como si los nuevos campos estuvieran ausentes. Los consumidores solo necesitarían actualizarse para consumir y usar las nuevas propiedades.


Sin embargo, a veces es necesario modificar los campos existentes para admitir nuevas funciones. Por ejemplo, digamos que los usuarios se sintieron incómodos al dar una edad exacta y, en cambio, cambia la aplicación para capturar rangos de edad como 18-24, 25-39, 40-49 y 60+. La columna de edad necesitaría modificar su tipo de datos de entero a cadena.


Esta es una evolución de esquema más compleja, ya que podría interrumpir a los consumidores intermedios que están procesando la propiedad de edad y esperando que sea un número o analizando el número utilizando un lenguaje estrictamente tipado como Java. También podrían realizar cálculos numéricos sobre la propiedad, que ya no funcionaría en su nuevo formato.


Para superar este desafío, las plataformas de datos pueden admitir la evolución del esquema para manejar escenarios como este. Pulsar reconoce la importancia del esquema para el procesamiento de datos; de hecho, lo trata como un ciudadano de primera clase al incluir compatibilidad integrada con la evolución del esquema. Veamos cómo Pulsar hace esto.

Cómo Pulsar admite la evolución del esquema

Pulsar define esquemas en una estructura de datos llamada `SchemaInfo`. Esta es una estructura de datos específica de Pulsar, que en sí misma es un esquema, que describe el esquema de los mensajes transportados a través de Pulsar. Cada `SchemaInfo` pertenece a un tema (canal de mensajes) y describe los mensajes que se producirán y consumirán usando ese tema.


Cada `SchemaInfo` tiene un tipo que detalla el tipo de esquema que se está utilizando. Esto puede ser cualquier cosa, desde un número entero, una cadena o un esquema complejo como Avro o Protobuf.


Apoyar evolución del esquema , Pulsar utiliza comprobaciones de compatibilidad de esquemas para comparar un esquema entrante con los esquemas conocidos de un tema. Las comprobaciones de compatibilidad de esquemas se producen cuando un productor o consumidor intenta conectarse a un tema en particular. La estrategia se elige durante la configuración del bróker, con el valor `schemaCompatibilityStrategy`. El objetivo es verificar el `SchemaInfo` proporcionado por el cliente que se conecta con el `SchemaInfo` existente para ver si son compatibles.


Pulsar admite ocho tipos diferentes de estrategias de compatibilidad de esquemas , que puede establecer en función de los requisitos del cambio. Estas estrategias también vienen con reglas que describen qué cambios se pueden realizar y sugerencias sobre qué clientes actualizar primero. (Consulte la documentación vinculada anteriormente para obtener una explicación más detallada de cada estrategia de compatibilidad).


Volviendo a los ejemplos anteriores, implementemos los cambios de esquema utilizando la estrategia de compatibilidad de Pulsar. Primero, comience con el esquema de usuario inicial (sin la dirección).


Este será el V1 de su esquema. Por lo tanto, cuando implemente un productor o consumidor de Pulsar por primera vez, se almacenará el `SchemaInfo` para esta versión, y el productor y el consumidor funcionarán como se espera.


A continuación, desea agregar los nuevos campos de dirección a su esquema de usuario. El primer paso es consultar las estrategias de compatibilidad de esquemas y determinar cuál es la mejor para este cambio. Usando la columna "cambios permitidos" en la documentación, está buscando cualquier estrategia que permita agregar nuevos campos. Esto le da BACKWARD, BACKWARD_TRANSITIVE, FORWARD y FORWARD_TRANSITIVE.


BACKWARD debe usarse cuando no hay garantía de que los consumidores que usan una versión anterior puedan entender el nuevo esquema. FORWARD se utiliza cuando es posible que los consumidores de la última versión del esquema no puedan leer los datos de las versiones anteriores. Si desea actualizar todos los consumidores primero para usar el nuevo esquema, use una estrategia HACIA ATRÁS. De lo contrario, ADELANTE es mejor.


Mirando el panorama general, Pulsar se refiere al acto completo de desarrollar el esquema de un tema como verificación de esquema . Es la combinación de un productor o consumidor que proporciona `SchemaInfo`, la estrategia de compatibilidad elegida para el tema y el intermediario que decide qué hacer.

Conclusión

Es raro que los esquemas permanezcan iguales para siempre. A medida que se introducen nuevas funciones en las aplicaciones, los esquemas a menudo tienen que evolucionar para admitir estas funciones. Sin embargo, mantener sincronizados a los productores y consumidores de datos a menudo puede ser un desafío cuando se modifican los esquemas.


Los conceptos de evolución de esquema integrados de Pulsar ayudan a lidiar con estos cambios. Usando estrategias de compatibilidad de esquemas, puede definir las reglas de cómo son las diferentes versiones compatibles de un esquema. Pulsar usa esto junto con un proceso de verificación de esquemas que luego usa estas reglas para determinar qué esquemas puede usar un consumidor cuando se conecta a un tema en particular.


También publicado aquí.