Cualquier sistema de gestión de datos pertenece a uno de dos tipos.
El primero es schema-on-write.
Schema-on-write
Seguramente muchos ya han trabajado con bases de datos relacionales. Sabes que el primer paso para trabajar con una base de datos relacional es crear las tablas y configurar los esquemas. Una vez configurados los esquemas y creadas las tablas, podemos empezar a ingerir los datos. Probablemente sea algo como una carga masiva desde un archivo de texto cuya estructura conocemos de antemano — porque de alguna forma coincide con el esquema de las tablas. Y una vez que los datos están cargados en la tabla, podemos empezar a ejecutar consultas analíticas. Esto es schema-on-write — el enfoque en el que definimos las columnas, el formato de los datos, las relaciones entre columnas, etc. antes de subir los datos de verdad.
Pero hay un problema desafortunado — no podemos subir datos hasta que la tabla esté creada, y no podemos crear tablas hasta que entendamos el esquema de los datos que van a estar en esa tabla. Y eso es imposible hasta que entendamos las entidades que esos datos representan, para reflejar correctamente sus relaciones en las tablas. De ahí también salen los problemas al cambiar los datos. Por ejemplo, cambió el archivo de texto de origen, o alguien agregó datos o cambió el tipo de una columna. Entonces tenemos que dropear la tabla y cargar todos los datos otra vez. Esto está bien cuando hablamos de una cantidad pequeña de datos, está bien si no hay foreign keys. ¿Pero si hay foreign keys y tenemos, por ejemplo, 500 GB de datos? Eso sería un problema real, y con ese enfoque, hacer cambios tan simples tomaría días.
¿Entonces para qué sirve este enfoque?
Una vez que completamos el proceso de ETL de carga de nuestros datos, las lecturas posteriores serán rápidas y deterministas (todos reciben los mismos datos estrictamente definidos que corresponden al esquema original). Pero recuerda que ya pagamos una penalización por eso cuando cargamos los datos por primera vez. Además, la desventaja de un esquema estrictamente definido es que los datos fueron modificados y estructurados para un propósito limitado y específico y no pueden reutilizarse para usos futuros que todavía no conocemos.
Schema-on-read
Con el auge del Big Data por los problemas con los métodos tradicionales y los volúmenes de datos crecientes, nació otro enfoque. Acá subimos los datos tal como llegan, sin ningún cambio ni transformación. De hecho, con este enfoque eliminamos por completo el proceso de ETL original y nos ahorramos los nervios de entender los patrones originales de los datos y su estructura.
Esto es schema-on-read, y la ingesta de datos es rápida porque los datos no tienen que seguir ningún esquema interno — es solo copiar/mover archivos. Este tipo de manejo de datos es más flexible en el caso de big data, datos no estructurados o cambios frecuentes de esquema.
Así que si analizamos los datos y tratamos de entender su estructura y encontrar otra forma de interpretarlos, podemos simplemente cambiar el código que maneja los datos. No necesitamos cambiar los esquemas ni recargar todos los datos en el almacenamiento.
Sin embargo, como los datos no pasan por ETLs estrictos ni por una transformación hacia esquemas estrictos de almacenamiento, puede haber muchos datos faltantes o inválidos, duplicados y muchos otros problemas que llevan a resultados de consultas inexactos o incompletos.
De todos modos, hay que entender que algún nivel de diseño de esquema es inevitable. De una forma u otra, es necesario entender la estructura de los datos para buscar información en ellos, para validar los datos entrantes y para gestionarlos. Pero no todos los datos entran en este proceso — algunos datos no le quedan claros ni al negocio mismo, y no deberías intentar modelarlos y gestionarlos de forma formal antes de poder usarlos.
¿Qué enfoque es mejor?
Como siempre, no hay bala de plata. Como la mayoría de las cosas en ingeniería, depende de cómo lo uses. Schema-on-write ayuda a ejecutar las consultas más rápido porque los datos ya están cargados en un formato estricto y puedes encontrar fácilmente los datos que buscas. Sin embargo, esto requiere mucha más preparación previa y una transformación continua de los datos entrantes, y el costo de hacer cambios en el esquema es alto y conviene evitarlo.
Schema-on-read, por otro lado, puede dar flexibilidad, escalabilidad y prevenir algunos errores humanos. En general se recomienda almacenar los datos en su formato crudo original (por si acaso) y optimizarlos en otro formato adecuado para el procesamiento posterior. El ETL puede tener transformaciones inválidas, y los datos crudos originales te permitirán volver a los datos originales y procesarlos correctamente. Además, como el esquema debe definirse al momento de consultar los datos, las consultas SQL tienden a ser muy complejas. Llevan tiempo escribirlas, y más aún completarlas.
Vale la pena mencionar que algunos enfoques más nuevos, como usar Apache Avro, pueden abstraer los cambios de esquema mediante control de versiones (un mecanismo de formato, no un VCS) o incluso mediante un schema registry. Pero los tipos existentes no van a ninguna parte — solo cambia el enfoque.