{"id":371,"date":"2019-10-27T10:12:29","date_gmt":"2019-10-27T10:12:29","guid":{"rendered":"https:\/\/www.digitaldrimz.com\/tusociotecnologico\/?p=371"},"modified":"2024-07-25T12:00:22","modified_gmt":"2024-07-25T12:00:22","slug":"hadoop-en-hadoop-que-me-conviente-schema-on-write-o-schema-on-read","status":"publish","type":"post","link":"https:\/\/www.digitaldrimz.com\/tusociotecnologico\/hadoop-en-hadoop-que-me-conviente-schema-on-write-o-schema-on-read\/","title":{"rendered":"[HADOOP] \u00bfEn Hadoop que me conviente: Schema-on-write o Schema-on-read?"},"content":{"rendered":"\n
\"\"<\/figure>\n\n\n\n

SSupongo que todos vosotros habr\u00e9is experimentado el problema de insertar miles de registros en una base de datos relacional. \u00bfNo?…Bueno, pues yo s\u00ed. En una base de datos relacional como Mysql <\/strong><\/a>con Innodb<\/strong><\/a>, insertar miles de registros puede llegar a tomar m\u00e1s 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].
<\/p>\n\n\n\n

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. \u00bfA cu\u00e1ntos de vosotros os ha pasado que hac\u00e9is una inserci\u00f3n de datos en una tabla y os da error porque un dato, es por ejemplo texto y se esperaba un entero? S\u00ed 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\u00edamos perder datos al ser rechazados y no controlados.
<\/p>\n\n\n\n

Por otro lado, el esquema en escritura tiene varias ventaja. Las lecturas son r\u00e1pidas y nos permite tener un formato definido, conocimiento c\u00f3mo est\u00e1n organizados los datos.
<\/p>\n\n\n\n

En Hadoop<\/strong><\/a>, domina el contexto llamado esquema en lectura, esto significa que los datos est\u00e1n almacenados tal y como llegan, sin procesar, e incluso comprimidos, no tienen formato para nada. A la hora de la inserci\u00f3n es incre\u00edblemente r\u00e1pido. Almacenamos los datos en HDFS <\/strong><\/a>y nada m\u00e1s, pero a la hora de la lectura, esto no es tan bueno.
<\/p>\n\n\n\n

Obviamente, utilizar un esquema u otro, depender\u00e1 de la utilizaci\u00f3n del sistema que tengamos. Una aplicaci\u00f3n de gesti\u00f3n, donde la mayor\u00eda de las veces vamos a leer datos, nos conviene tener un esquema de escritura. Por ejemplo utilizar una base de datos Mysql<\/strong><\/a>, Postgresql<\/strong><\/a>, Sql Server<\/strong><\/a>, Oracle<\/strong><\/a>\u2026 Mientras que si nuestro esquema va a recibir gran cantidad de datos, y despu\u00e9s se leer\u00e1 para hacer estad\u00edsticas o an\u00e1lisis, un esquema en lectura, es la mejor opci\u00f3n. Se cargan los datos en el sistema y despu\u00e9s con un proceso en lotes se puede crear los datos a mostrar.<\/p>\n\n\n\n

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

De esta forma, siguiendo el patr\u00f3n de dise\u00f1o para Kafka<\/strong><\/a> <\/strong>de procesamiento de datos, generamos diferentes topics de Kafka<\/strong><\/a> <\/strong>que serv\u00edan 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\u00e1s datos, esto nos permit\u00eda entrar datos, ya fueran de csv, json, raw, etc\u2026 no ten\u00edamos ning\u00fan tipo de restricci\u00f3n, y el productor, era bastante eficiente, entrando datos, en los diferentes escenarios, el sistema, procesaba los datos, y finalmente los almacenaba en Hive<\/strong><\/a>, Hbase<\/strong><\/a>, Impala<\/strong><\/a>, o cualquier otro sistema de almacenamiento de datos. En cada escenario [lo comentar\u00e9 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\u00e1s tarde, y se enviaba un mensaje a nosotros con el fin de conocer qu\u00e9 hacer con esa informaci\u00f3n.<\/p>\n\n\n\n

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

Si quieres hacerme un comentario, no dudes en seguirme o hacerme un comentario referenci\u00e1ndome a Rafael Piernagorda<\/strong><\/a> en Twitter o a Rafael Piernagorda<\/strong><\/a> en Linkedin
<\/p>\n\n\n\n