Autor
Zigurat Global Institute of Technology
Blog / BIM & Construction Management
BIM no es Big Data
Categorias
En el siguiente artículo, Fernando Iglesias Gamella, Profesor del Máster Internacional BIM Management de Zigurat, expone la relación que existe entre BIM y Big Data y el por qué -de momento- ambos términos no están estrictamente interrelacionados. En este contexto, expone Fernando, la sensorización y el Gemelo Digital se erigen como vía para eliminar las fronteras existentes entre ambos conceptos.
Hoy en día no resulta, ni tan siquiera novedosa, la expresión que asegura que vivimos en un mundo rodeado de datos. Si pensamos en almacenar datos, parece lógico hablar de bases de datos. Bien, para la gran mayoría de usuarios de BIM las bases de datos están formadas por las diferentes “Data Sheets” que contienen la información extraída de los modelos. Bien almacenadas en una hoja de cálculo (Excel), una librería de Access o incluso varios .csv almacenados en una base de datos SQL donde realizar consultas. En definitiva, independientemente del volumen y almacén, datos estructurados en filas y columnas y relaciones entre cada uno de estos registros.
Esta manera de clasificar y almacenar datos no es ninguna novedad. La mayor novedad es que las herramientas de trabajo ahora nos permiten almacenar una mayor cantidad de datos y extraerlos de manera más ágil. Pero esta manera de almacenar datos no es, para nada novedosa. De hecho, venimos trabajando con esta tipología de bases de datos desde que, allá por los años setenta Edgar Codd alumbrara la génesis de este tipo relacional de base de datos. Por lo que el reinado de este tipo de bases de datos por tanto alcanza ya, prácticamente los 50 años.
Hasta aquí parece todo claro, sin embargo, los datos por el mero hecho de existir, generarse y multiplicarse no implican un aporte de valor. Sea cual sea su origen, es importante saber qué hacer con ello. Un modelo BIM no deja de ser una fuente de datos como cualquier otra. Sin embargo, únicamente por el mero hecho de existir, los datos, por números que sean, no se etiquetan como Big Data. No se trata de acumular, sino de extraer valor. Tratar los datos implica convertirlos en información útil sobre la que elaborar análisis y, sobre ese análisis, aplicar un aprendizaje que provoque de manera implícita una optimización.
Es más, tampoco podríamos considerar el almacenar datos en estas bases de datos relacionales como tecnología Big Data. Siendo puristas, el motivo es su incapacidad para cumplir con la “3 Vs” del Big Data. No son capaces de almacenar un gran volumen de datos variables entre sí, y que mutan a gran velocidad. En esas 3V es donde reina el Big Data. Aunque el número de “uves” crece a la misma velocidad que los datos. El naming, el marketing, o la generación espontánea, hace que se hable de cinco, ocho o incluso diez “uves”. Pero de momento nos vamos a quedar con tres.
Todas las bases de datos Big Data son a su vez bases de datos NoSQL. Término intangible y que parece el paradigma de la ambigüedad. Pues bien, no es otra cosa que bases de datos que rompen el esquema relacional y por tanto conviven muy bien con las “Vs” anteriormente citadas. No se piensa en tablas, filas o columnas sino datos agregados de múltiples naturalezas. Aquí es donde aparecen las herramientas más comunes en esta tecnología: Hadoop, MongoDB, DynamoDB (Amazon) o Cassandra (Facebook), BigTable (Google)… Como vemos cada Big Five con su caballo ganador.
Parece que en este punto hemos perdido la escala y el enfoque. Un modelo BIM no está en esa escala a menos que tengamos cinco millones. ¿Qué pasa entonces con la disciplina que aborda la limpieza, preparación y análisis de los datos? ¿No es eso lo que hacemos con la información alojada en un modelo BIM cuando queremos que aporte un valor en cualquiera de las fases del ciclo de vida? Bien, eso es ciencia de Datos (Data Science). O, mejor dicho, ciencia de datos a pequeña escala para extraer valor de un análisis de los datos, gestionar la información con herramientas estadísticas para corregir y detectar errores. Una tasa de predicción alta ayuda a anticipar la decisión correcta y por tanto optimizar procesos. Todo esto con potentes y amigables herramientas de visualización de datos. Esto, hoy en día, es una realidad en nuestro sector. La manera más común de garantizar la trazabilidad de elementos entre varios softwares en un proceso BIM, hoy en día, es a través del GUID, UniqueID, IDs o sistemas de clasificación. Extrapolando esa manera de trabajar. ¿Sería correcto controlar la trazabilidad de toda información que un individuo genera utilizando siempre una clave común, por ejemplo, el DNI? Parece impensable. Insisto de nuevo, de momento el Volumen no es lo suficientemente grande y podemos sobrevivir sin la brújula de GUIDs.
Sin embargo, hay vida más allá del GUID. MongoDb trabaja con JSON (JavaScript Object Notation), formato de texto para el intercambio de datos y una, más que factible, vía de entrada al intercambio de modelos IFC. Con los JSON se soluciona el problema de impedancia (incompatibilidad entre diferentes tipos de datos) que llevan implícito las BBDD relacionales. MongoDB nos permite trabajar con colecciones, que son simplemente secuencias de datos de distinto tipo donde no se nos pone ninguna restricción para trabajar con ellos. Los JSON permiten almacenar información de manera más cómoda con independencia de los datos almacenados. No es necesario descomponer la información en valores individuales a modo de parámetros alojados en una base de datos relacional. Quizás, después de todo lo anterior, lleguemos a la conclusión de que los modelos BIM no tienen necesidad de entrar dentro de la tecnología Big data. Y, hoy en día, es así. Estamos muy lejos. De momento a nivel de generación de datos es grano de arena en el desierto frente a los datos expuestos anteriormente. Podemos manejarnos con bases de datos relacionales y llevar al límite de sus posibilidades. Realizar consultas complejas, agrupar la información en tablas resumen o pivotantes, extraer informes con colores y gráficos (PowerBI/Tableu), pero la frontera del cambio está más cerca de lo que pensamos.
¿Cómo podemos asemejarnos a una producción de información similar a una página web? La sensorización. Esto multiplicará los datos generados. En el grado que seamos capaces de generar Gemelos Digitales que sirvan de fuente de todos esos datos capturados por los sensores nos aproximaremos a la frontera del Big Data y a poner en jaque a la utilización del modelo relacional de bases de datos. Con los sensores y la gestión de la información que estos producen a través de los Modelos Digitales, entramos en la liga de los datos de las 3V. El BIM es la puerta de entrada para conectar el gemelo digital con el activo físico (sea en la fase de diseño y obra o en fase de explotación) con las grandes tecnologías existentes de gestión de datos de manera masiva. Pero, si esa conexión llega a producirse con éxito, siempre se producirá fuera del modelo BIM. Entendiendo el modelo en su representación tridimensional y apoyado en capas de información por detrás que, para gestionarlas sería imprescindible contar con tecnologías Big Data. El BIM no es Big Data, todavía. Autor: Fernando Iglesias Gamella, Profesor responsable del Módulo de diseño Revit del Máster Internacional BIM Management de Zigurat.
Muchos datos no son Big Data
Hasta aquí parece todo claro, sin embargo, los datos por el mero hecho de existir, generarse y multiplicarse no implican un aporte de valor. Sea cual sea su origen, es importante saber qué hacer con ello. Un modelo BIM no deja de ser una fuente de datos como cualquier otra. Sin embargo, únicamente por el mero hecho de existir, los datos, por números que sean, no se etiquetan como Big Data. No se trata de acumular, sino de extraer valor. Tratar los datos implica convertirlos en información útil sobre la que elaborar análisis y, sobre ese análisis, aplicar un aprendizaje que provoque de manera implícita una optimización.
Las "3V" del Big Data
Es más, tampoco podríamos considerar el almacenar datos en estas bases de datos relacionales como tecnología Big Data. Siendo puristas, el motivo es su incapacidad para cumplir con la “3 Vs” del Big Data. No son capaces de almacenar un gran volumen de datos variables entre sí, y que mutan a gran velocidad. En esas 3V es donde reina el Big Data. Aunque el número de “uves” crece a la misma velocidad que los datos. El naming, el marketing, o la generación espontánea, hace que se hable de cinco, ocho o incluso diez “uves”. Pero de momento nos vamos a quedar con tres.
- Volumen. ¿Qué es una gran cantidad de datos? Basta con preguntarse, ¿Qué pasa en internet en 1min?
"Un minuto en Internet en 2020". Fuente: Statista
- Variedad, los datos han de ser variados, y con ello se entiende la capacidad de combinar datos de diferentes formatos (string, number, boolean…o textos, videos, audio, json, html, csv) estructurados, semiestructurados y no estructurados.
- Velocidad, los datos pierden valor al momento, se actualizan porque aparecen otros más recientes.
Bases de Datos NSQL
Todas las bases de datos Big Data son a su vez bases de datos NoSQL. Término intangible y que parece el paradigma de la ambigüedad. Pues bien, no es otra cosa que bases de datos que rompen el esquema relacional y por tanto conviven muy bien con las “Vs” anteriormente citadas. No se piensa en tablas, filas o columnas sino datos agregados de múltiples naturalezas. Aquí es donde aparecen las herramientas más comunes en esta tecnología: Hadoop, MongoDB, DynamoDB (Amazon) o Cassandra (Facebook), BigTable (Google)… Como vemos cada Big Five con su caballo ganador.
BIM = Big Data: ¿tan lejos estamos?
Parece que en este punto hemos perdido la escala y el enfoque. Un modelo BIM no está en esa escala a menos que tengamos cinco millones. ¿Qué pasa entonces con la disciplina que aborda la limpieza, preparación y análisis de los datos? ¿No es eso lo que hacemos con la información alojada en un modelo BIM cuando queremos que aporte un valor en cualquiera de las fases del ciclo de vida? Bien, eso es ciencia de Datos (Data Science). O, mejor dicho, ciencia de datos a pequeña escala para extraer valor de un análisis de los datos, gestionar la información con herramientas estadísticas para corregir y detectar errores. Una tasa de predicción alta ayuda a anticipar la decisión correcta y por tanto optimizar procesos. Todo esto con potentes y amigables herramientas de visualización de datos. Esto, hoy en día, es una realidad en nuestro sector. La manera más común de garantizar la trazabilidad de elementos entre varios softwares en un proceso BIM, hoy en día, es a través del GUID, UniqueID, IDs o sistemas de clasificación. Extrapolando esa manera de trabajar. ¿Sería correcto controlar la trazabilidad de toda información que un individuo genera utilizando siempre una clave común, por ejemplo, el DNI? Parece impensable. Insisto de nuevo, de momento el Volumen no es lo suficientemente grande y podemos sobrevivir sin la brújula de GUIDs.
JSON, una nueva esperanza
Sin embargo, hay vida más allá del GUID. MongoDb trabaja con JSON (JavaScript Object Notation), formato de texto para el intercambio de datos y una, más que factible, vía de entrada al intercambio de modelos IFC. Con los JSON se soluciona el problema de impedancia (incompatibilidad entre diferentes tipos de datos) que llevan implícito las BBDD relacionales. MongoDB nos permite trabajar con colecciones, que son simplemente secuencias de datos de distinto tipo donde no se nos pone ninguna restricción para trabajar con ellos. Los JSON permiten almacenar información de manera más cómoda con independencia de los datos almacenados. No es necesario descomponer la información en valores individuales a modo de parámetros alojados en una base de datos relacional. Quizás, después de todo lo anterior, lleguemos a la conclusión de que los modelos BIM no tienen necesidad de entrar dentro de la tecnología Big data. Y, hoy en día, es así. Estamos muy lejos. De momento a nivel de generación de datos es grano de arena en el desierto frente a los datos expuestos anteriormente. Podemos manejarnos con bases de datos relacionales y llevar al límite de sus posibilidades. Realizar consultas complejas, agrupar la información en tablas resumen o pivotantes, extraer informes con colores y gráficos (PowerBI/Tableu), pero la frontera del cambio está más cerca de lo que pensamos.
Sensorización y gemelos digitales: oportunidad de acercar BIM y Big Data
¿Cómo podemos asemejarnos a una producción de información similar a una página web? La sensorización. Esto multiplicará los datos generados. En el grado que seamos capaces de generar Gemelos Digitales que sirvan de fuente de todos esos datos capturados por los sensores nos aproximaremos a la frontera del Big Data y a poner en jaque a la utilización del modelo relacional de bases de datos. Con los sensores y la gestión de la información que estos producen a través de los Modelos Digitales, entramos en la liga de los datos de las 3V. El BIM es la puerta de entrada para conectar el gemelo digital con el activo físico (sea en la fase de diseño y obra o en fase de explotación) con las grandes tecnologías existentes de gestión de datos de manera masiva. Pero, si esa conexión llega a producirse con éxito, siempre se producirá fuera del modelo BIM. Entendiendo el modelo en su representación tridimensional y apoyado en capas de información por detrás que, para gestionarlas sería imprescindible contar con tecnologías Big Data. El BIM no es Big Data, todavía. Autor: Fernando Iglesias Gamella, Profesor responsable del Módulo de diseño Revit del Máster Internacional BIM Management de Zigurat.
