[HADOOP] ¿En Hadoop que me conviente: Schema-on-write o Schema-on-read?

Supongo que todos vosotros habréis experimentado el problema de insertar miles de registros en una base de datos relacional. ¿No?…Bueno, pues yo sí. En una base de datos relacional como Mysql con Innodb, insertar miles de registros puede llegar a tomar más tiempo del que esperamos, el problema viene determinado porque las bases de datos relacionales utilizan el esquema en escritura [in inglis plis: Schema-on-write]. 

El esquema en escritura, es generalmente utilizado en bases de datos relacionales, tales sistemas requiere que el esquema de los datos sea creado y definido previamente antes de insertar los datos. Eso supone que cuando se cargan, estos han de ser analizados para comprobar si encajan con el esquema de la tabla. ¿A cuántos de vosotros os ha pasado que hacéis una inserción de datos en una tabla y os da error porque un dato, es por ejemplo texto y se esperaba un entero? Sí no os ha pasado, solo puede ser dos cosas, una, no has hecho suficientes inserciones, dos, eres un crack. Esto tiene una desventaja bastante incipiente, y es que podríamos perder datos al ser rechazados y no controlados.

Por otro lado, el esquema en escritura tiene varias ventaja. Las lecturas son rápidas y nos permite tener un formato definido, conocimiento cómo están organizados los datos.

En Hadoop, domina el contexto llamado esquema en lectura, esto significa que los datos están almacenados tal y como llegan, sin procesar, e incluso comprimidos, no tienen formato para nada. A la hora de la inserción es increíblemente rápido. Almacenamos los datos en HDFS y nada más, pero a la hora de la lectura, esto no es tan bueno.

Obviamente, utilizar un esquema u otro, dependerá de la utilización del sistema que tengamos. Una aplicación de gestión, donde la mayoría de las veces vamos a leer datos, nos conviene tener un esquema de escritura. Por ejemplo utilizar una base de datos Mysql, Postgresql, Sql Server, Oracle… Mientras que si nuestro esquema va a recibir gran cantidad de datos, y después se leerá para hacer estadísticas o análisis, un esquema en lectura, es la mejor opción. Se cargan los datos en el sistema y después con un proceso en lotes se puede crear los datos a mostrar.

Nosotros obviamente, al mostrar datos en tiempo real, no nos encaja ninguno de los dos esquemas, es un problema. Para resolver el problema, habíamos utilizado Hive con ORC, o incluso Impala [en otra entrada, mostraré los diferentes esquemas de datos], pero en ORC había que cargar los esquemas igual que con Impala, lo que significaba que teníamos un esquema en escritura, y si fallaba al registrarse el error perdíamos datos.

De esta forma, siguiendo el patrón de diseño para Kafka de procesamiento de datos, generamos diferentes topics de Kafka que servían para diferenciar los diferentes estados [tiers] de nuestro pipeline de procesamiento. Los datos sin procesar [raw] entraban en el primer tiers, dejando al productor libre de seguir insertando los demás datos, esto nos permitía entrar datos, ya fueran de csv, json, raw, etc… no teníamos ningún tipo de restricción, y el productor, era bastante eficiente, entrando datos, en los diferentes escenarios, el sistema, procesaba los datos, y finalmente los almacenaba en Hive, Hbase, Impala, o cualquier otro sistema de almacenamiento de datos. En cada escenario [lo comentaré en otra entrada] los datos iban siendo analizados, procesados y finalmente almacenados, y si un dato, llegaba de forma incorrecta, se almacenaba para ser procesado más tarde, y se enviaba un mensaje a nosotros con el fin de conocer qué hacer con esa información.

Resumiendo, el schema-on-write es un sistema utilizado por los sistemas de gestión de bases de datos [SGBD] tradicionales, con sus ventajas e inconvenientes. Con los nuevos sistemas de entrada de datos y análisis en tiempo real, estos sistemas quedan relegados por los sistemas que utilizan schema-on-read cómo Hadoop, donde se prima la entrada de datos, y con sistemas de computación, pasar estos datos a formatos legibles, para hacer fácil la programación. Luego, a la hora de evaluar un sistema u otros, debes de tener en cuenta todas las ventajas y desventajas, pues hará que tu sistema sea rápido y/o consistente.

Si quieres hacerme un comentario, no dudes en seguirme o hacerme un comentario referenciándome a Rafael Piernagorda en Twitter o a Rafael Piernagorda en Linkedin.