Unidad 3.

Obtención y Tratamiento de Datos

Como en cualquier solución de analítica, para poder explotar los datos, es necesario
primero extraerlos, y luego tener la infraestructura necesaria para su tratamiento. Es
importante entender cuáles son los pasos a seguir para diseñar cualquier solución
de analítica y qué particularidades tienen esos pasos en una solución de wearables o
IoT.
Durante esta unidad revisaremos la secuencia que va desde la ingesta hasta el
almacenamiento y disponibilización de datos, a modo general. En las siguientes
unidades nos enfocaremos, puntualmente, en el diseño de una solución específica
de wearables, para poder comprender todos los aspectos inherentes a la explotación
y minería de datos.

Ingestas de datos desde wearables

Estructuras de datos en wearables.

Procesamiento de datos

Almacenamiento y disponibilización de datos

Página 1 de 4

Ingestas de datos desde wearables

La ingesta de datos es el proceso mediante el que se introducen datos, de diferentes fuentes, estructura y/o
características dentro de otro sistema de almacenamiento o procesamiento de datos.

Es sin duda, el primer paso que ha de tenerse en cuenta a la hora de diseñar una arquitectura Big Data, para
lo cual, hay que tener muy claro no solamente el tipo y fuente de datos sino también cual es el objetivo final y
que se pretende conseguir con ellos.

Es por esto que se debe realizar un análisis detallado, ya que la ingesta es la base para determinar las
tecnologías que compondrán tu arquitectura Big Data. Para realizar dicho análisis, se deben considerar los
siguientes factores:

Origen y formato de los datos

En este punto, habría que hacer varias preguntas:

¿Cuál va a ser el origen u orígenes de los datos?

¿Provienen de sistemas externos o internos?

¿Serán datos estructurados o datos sin estructura?

¿Cuál es el volumen y la periodicidad de los datos?

¿Se prevé un aumento del volumen en el tiempo?

 ¿Se deberá realizar una ingesta inicial de mayor volumen?

¿Existe la posibilidad de que más adelante se incorporen nuevas fuentes de datos?

A partir de la información recolectada se puede comenzar a analizar las conexiones que será necesario
realizar, la capacidad de procesamiento y almacenamiento necesaria, la escalabilidad necesaria para
soportar el sistema actual y a futuro, y también que tan compleja podría resultar la incorporación de nuevas
fuentes de datos.

Latencia/Disponibilidad
Como ya se mencionó anteriormente, y se verá durante todo el cursado, también es clave tener en cuenta
cómo serán utilizados estos datos. Es vital tener este conocimiento para planificar una estrategia de ingesta
de datos y realizar una selección de infraestructura y herramientas a utilizar, definiendo así, el método de
extracción, ya que no es lo mismo en el caso de que trabajemos con un esquema de procesamiento por
lotes, donde la latencia puede estar en horas o días y será más sencillo realizar los cálculos sobre la
infraestructura necesaria, que en el esquema de procesamiento en tiempo real, donde debemos
anticiparnos a la posibilidad de incrementar la capacidad de infraestructura de acuerdo al volumen de datos
que tengamos en un momento dado, además de la complejidad inherente a tener que procesar, almacenar y
disponibilizar los datos con una latencia que se mide en microsegundos.

Actualizaciones
Es habitual que los datos que han sido ingestados sufran modificaciones en sus fuentes de origen, y
entonces es importante considerar con qué frecuencia se realizan esas modificaciones. Además, es
importante entender que estrategia se debe seguir con la información que ya haya sido ingestada, es decir:

¿Es viable almacenar toda la información y guardar un histórico de cambios?

O bien, ¿habría que modificar la información ya almacenada? Y en ese caso, ¿la actualización se realizará
mediante updates, o a través de deletes+insert?
Es importante siempre tener en cuenta qué latencia es necesaria, además de las capacidades que ofrezca
la plataforma final donde se almacenarán los datos.

Transformaciones
En muchos casos es necesario, adicionalmente, realizar transformaciones durante el proceso de ingesta.
Este proceso de transformación puede depender de las diferencias entre las plataformas de origen/destino,
o puede ser por necesidades del negocio. En todos aquellos casos en los que sea posible, es considerado
una mejor práctica el almacenar primero los datos en un formato exactamente igual al de origen y luego
hacer las transformaciones correspondientes. Esto es más correcto desde el punto de vista de trazabilidad
de los datos. Sin embargo, en aquellos casos en los que se decida realizar las transformaciones al vuelo
(suele suceder cuando se necesita trabajar los datos en tiempo real), es importante considerar cómo
incidirá ese procesamiento en la latencia para el uso de los datos.

Destino de los datos

Este también es un punto importante a analizar a la hora de definir la estructura de la ingesta y las
herramientas a utilizar. Algunas preguntas clave a realizarse en este punto son:

¿Los datos serán almacenados en una base de datos relacional, en un sistema de archivos, en una
base documental?

¿Cuáles serán los procesos, servicios o usuarios que luego utilicen esos datos?

¿Cuáles serán las consultas que se realizarán con mayor frecuencia?

Las respuestas a estas preguntas ayudarán a decidir cómo realizar el particionamiento y modelado de datos
a partir de la ingesta.

Otros factores a tener en cuenta:

Calidad de los datos

–
Es interesante evaluar durante el proceso de ingesta de los datos la calidad de los mismos, es decir, la
existencia de datos incoherentes o incompletos. En este caso, también hay que evaluar cuáles serán las
ventajas y las desventajas de realizar esa limpieza o preprocesamiento de los datos durante el proceso de
ingesta, o en etapas posteriores.

Seguridad de los datos

–
Los datos sensibles, o sujetos a regulaciones, deben cumplir ciertos criterios a la hora de ser ingestados.
En ese sentido, hay que tomar muy en consideración esas regulaciones y evaluar, de acuerdo a la
necesidad, si esos datos serán ingestados de forma anonimizada o si directamente se optará por no
introducirlos en el sistema.

Tecnologías de ingesta de datos

Finalizado todo el análisis anterior, es importante comenzar con la selección de las herramientas a utilizar
para el proceso de ingesta. En este sentido, se puede trabajar con herramientas on premise (locales) o
cloud, donde la mayoría de los servicios cloud tienen herramientas auto gestionadas que facilitan el proceso
de gestión y utilización de las mismas. En este apartado nombraremos algunas de las más utilizadas tanto
en entornos on premise como en cloud, aunque este es un terreno que cambia y evoluciona continuamente,
por lo que es más importante entender los procesos que enfocarse en las herramientas.

On Premise:

Transferencia Básica de Ficheros a HDFS

Apache Flume

Apache Kafka
 Logstash

Fluentd

Sqoop

Apache NiFi

Apache Spark

Cloud:

Servicios IoT AWS, incluyendo:

IoT Core

IoT GreenGrass

Kinesis DataStreams, Firehose, Analytics

Servicios IoT GCP:

Cloud IoT Core

Cloud BigQuery Transfer

Cloud Pub/Sub

Servicios IoT Azure:

Azure IoT Central

Azure IoT Edge

Azure IoT Hub

Toda herramienta tiene sus ventajas y desventajas, por lo que es importante estudiar esas diferencias para
seleccionar aquella que mejor se adapte a nuestras necesidades.
Página 2 de 4

Estructuras de datos en wearables.

En relación a la estructura de los datos desde diferentes wearables, los fabricantes

pueden optar por definir sus propios protocolos y estructuras de datos, procurar
imponerlos como estándares del mercado si es que no existieren, o bien adoptar los que
ya estén estandarizados para el mercado. Al momento de optar por desarrollar un
software, es importante priorizar el uso de estándares fundamentados en una gran
cantidad de ventajas, entre las que destacamos la reducción de la dependencia del
fabricante de hardware, mayor compatibilidad multi-dispositivo, facilidad de
mantenimiento y escalabilidad.

Por un lado, se usarán estándares, por el otro, en este momento de definición y durante
todo el ciclo de desarrollo, toma un papel preponderante la heterogeneidad de capacidades
que tienen los diferentes dispositivos. No poseen los mismos sensores un smartwatch
para natación, que otro enfocado para corredores de maratón; mucho más distante es aún
en el ciclismo, donde el dispositivo tiene gran capacidad computacional. Por dicha
variedad, es que existen diferentes estándares.

Para abordar la diversidad de dispositivos, se hará foco en los dos estándares principales
en la industria, señalados por Dynastream Innovations Inc. (2017).

Estos incluyen el FIT, diseñado para trabajar con wearables de pocos recursos computacionales, y el TCX
que está orientado a dispositivos de mayor capacidad como minicomputadoras.
FIT - Transferencia de datos flexible e interoperable
Este protocolo está diseñado específicamente para el almacenamiento e intercambio de datos que se
originan en los dispositivos de deporte, fitness y salud. El protocolo FIT define un conjunto de plantillas de
almacenamiento de datos (mensajes FIT) que se pueden utilizar para almacenar información, tal como
perfiles de usuario, y los datos de actividad en los ficheros. Está específicamente diseñado para ser
compacto, interoperable y extensible.

ANT-FS proporciona un marco sólido para la transferencia de archivos de forma inalámbrica entre dos
dispositivos. La Figura 1, ilustra el protocolo FIT que se utiliza para transferir información personal de
monitorización adquirida durante el ejercicio, para una base de datos de Internet.

Figura 1: Archivo FIT a la computadora personal

Fuente: (Dynastream Innovations Inc., 2017b).

El protocolo FIT define el proceso para que los archivos se transfieran. Normalmente, los datos de difusión
se recogen mediante un dispositivo de visualización. El dispositivo de visualización, entonces, codificaría los
datos en el formato de archivo FIT de acuerdo a su perfil de producto. El archivo FIT se transfiere asimismo a
otro dispositivo, que a continuación decodificaría los archivos recibidos de acuerdo a su propio perfil de
producto.

Los sensores ANT+ recogen parámetros de medida, tales como la frecuencia cardíaca y la velocidad de
carrera. Los datos se transmiten en tiempo real, utilizando formatos de datos interoperables ANT +. Los
eventos de sesión y los datos de la actividad en tiempo real se guardan en un archivo que se muestra en un
dispositivo de visualización.

De la misma forma, el archivo FIT se transfiere a la PC a través de recursos compartidos de archivos ANT
(ANT-FS). Acá la opción de integración más completa es que la transferencia se haga a un smartphone, y
desde el mismo, a un servidor (PC) para ser utilizados por las aplicaciones de internet. El protocolo FIT
ofrece un formato coherente, permitiendo que todos los dispositivos posteriores puedan compartir y utilizar
los datos.

Estructura de los archivos FIT

Un archivo FIT está compuesto de uno o varios registros, cada registro, a su vez, contiene un encabezado
(indica el tipo del mensaje) y el contenido (datos). Todos los archivos FIT tienen la misma estructura que
consiste en un encabezado de archivo, una sección principal de registros de datos que contiene los
mensajes FIT codificados, seguido de un CRC de 2 bytes, tal como se aprecia en la Figura 2.

Figura 2: Estructura de un archivo FIT.

 Fuente: (Dynastream Innovations Inc., 2017a).

Es importante, señalar lo siguiente:

El encabezado del archivo proporciona información sobre el archivo FIT.

Los registros de datos en el archivo FIT son el contenido principal y el propósito del protocolo FIT.

Por otra parte, hay dos tipos de registros de datos:

Mensajes de definición
–
tal como lo indica su nombre, precisa los próximos mensajes de datos; específicamente, definirá un tipo de
mensaje local y lo asociará a un mensaje FIT específico.

Mensaje de datos
–
campos de datos poblados en el formato descrito por el mensaje de definición anterior. El mensaje de
definición y sus mensajes de datos asociados tendrán tipos de mensajes locales coincidentes.

Protocolo de archivo FIT

Los datos entrantes tales como ajustes, eventos y datos de sensores se escriben en campos de mensaje
FIT de acuerdo con los formatos definidos. El proceso de codificación FIT está optimizado, de tal manera
que sólo se escriben campos válidos en el archivo. El archivo se puede transferir a otro dispositivo FIT.

Cuando los datos son utilizados por el dispositivo receptor, se decodifica, para eso se relacionan los
mensajes FIT recibidos con la lista global de mensajes FIT. Los valores decodificados se pasarán entonces
como estructuras u objetos a la aplicación.

Si hay una diferencia en la versión de perfil entre los dos dispositivos, los datos que faltan se establecerán
en valores no válidos o predeterminados como se definen en el protocolo FIT y cualquier mensaje o datos
desconocidos se ignorarán. El archivo FIT se mantiene en su forma original para su transferencia a otros
dispositivos, si lo desea (Dynastream Innovations Inc., 2017a).

TCX - Training Center XML

Los archivos TCX se utilizan para el intercambio de datos; implementados por el software Garmin Training
Center, están basados en XML (W3C, 2008). Estos archivos tratan a cada pista como una actividad,
permitiendo guardar más que una serie de puntos; también almacenan datos de fitness, como el tipo de
deporte, tiempo de vuelta, la distancia recorrida, calorías, frecuencia cardíaca, cadencia, entre otros.

Esquema de un TCX
El Esquema XML es un lenguaje de esquema basado en XML utilizado para describir la estructura y las
restricciones de los contenidos de los documentos XML. O sea, un esquema XML es quien verifica si un
mensaje XML entrante o saliente es válido acorde a lo que se espera que tenga su contenido. El esquema
TCX entonces será de gran utilidad y aplicación, para conocer qué datos puede contener cada mensaje TCX,
cuáles de ellos son opciones u obligatorios, cómo se le denomina a cada uno, qué tipo de valores puede
tener, etcétera. En el marco del desarrollo de software, en la fase de análisis y diseño, el esquema XML se
utiliza para definir cómo serán los mensajes XML a intercambiar entre dispositivos. En la fase de
programación, tener el esquema XML definido, otorga gran facilidad para corroborar si los mensajes
recibidos son válidos. En este caso, para corroborar si un mensaje TCX recibido es válido, se lo contrarresta
contra el esquema en cuestión.

Estructura de un plan de entrenamiento. Elementos que contiene

La estructura de un plan de entrenamiento puede ser ampliada, agregando elementos de otros esquemas.
Sin embargo, pueden mencionarse, los siguientes elementos (Garmin, 2017d):

Carpetas, con entrenamientos, circuitos e historiales.

Actividades.

Entrenamiento. Incluye los pasos.

Circuito.

Historial. Incluye carpetas de running, bicicleta y otros deportes.

Carpetas con deportes múltiples. Indica qué semana, y qué deportes se realizan.

Semanas, con día de inicio.

Múltiples deportes por sesión. El primer deporte y el próximo deporte.

Primer deporte. Indica la actividad.

Próximo deporte. Contiene la transición y la actividad.

Deporte. Puede ser running, bicicleta u otro.

Actividad. Creación, vuelta de actividad, deporte, notas.

Dispositivo. Contiene producto y versión.

Aplicación. Contiene fecha de creación, lenguaje y número de serie.

Ejercicio rápido. Tiempo total en segundos y distancia en metros.

Plan. nombre, tipo de plan (circuito, entrenamiento), entrenamiento intervalado.

Vuelta de actividad. Incluye tiempo total en segundos, distancia en metros, máxima velocidad,
calorías, intensidad, cadencia, puntos, y notas; como extensión se le agrega la potencia.

Punto. Contiene tiempo, posición (latitud y longitud), altura en metros, distancia en metros,
cadencia.

Repeticiones. Cantidad mínima y cantidad máxima.

Pasos. Nombre, duración, intensidad.

Página 3 de 4

Procesamiento de datos

Independientemente del origen de los datos, y de las herramientas utilizadas, todas las soluciones de
analítica involucran pasos similares en cuanto al procesamiento, incluyendo limpieza y curación de datos,
transformación e ingeniería de variables, modelado, visualización y disponibilización. En general, cuando
hablamos del procesamiento de los datos, estamos refiriéndonos, principalmente a las etapas de limpieza,
curación, transformación e ingeniería de variables.

Limpieza y Curación de Datos en IoT y Wearables

Los datos de los dispositivos IoT y wearables pueden estar sujetos a distintos grados de ruido. Además, al
carecer de un estándar fijo, muchas veces resulta necesario realizar un proceso de traducción a un objeto
genérico, que luego será consumido por nuestra aplicación principal, y que permite adaptarse a dispositivos
de distintas marcas.

Además, la mayoría de estos datos tienen las características de series de tiempo, por lo que su análisis
suele estar vinculado a procesos de agregación y cálculo de distintos indicadores.

El procesamiento de datos a partir de dispositivos IoT y Wearables suele llevarse adelante en tres partes o
capas.

Figura 3. Procesamiento de datos de Wearables en tres capas

 Fuente: de Arriba Pérez, Caeiro Rodriguez y Santos (2016)

La primera capa consiste en el propio wearable o dispositivo IoT. Si bien la capacidad de procesamiento de
este tipo de dispositivos suele ser relativamente limitada, ha venido creciendo en el tiempo y permite un
procesamiento cada vez mayor «on the edge». En este sentido, estos dispositivos realizan un primer
procesamiento, estabilizando lecturas incongruentes y completando datos faltantes en el propio dispositivo.
Además, es cada vez más frecuente que estos dispositivos cuenten con alguna pantalla o mecanismo para
comunicar los detalles de esa información al usuario final. Recordando que el volumen generado es
considerable, también suelen tener un método de agregación para realizar y visualizar una analítica básica
sobre esos datos. Sin embargo, a la hora de exportar los datos, lo más habitual es obtenerlos de forma cruda
y no agregados, ya que el potencial de los mismos es mucho mayor.

La segunda capa, en la mayoría de los casos, es el dispositivo móvil. El móvil es el elemento concentrador
de los datos de los wearables, ya contando con una mayor capacidad de procesamiento. La capacidad del
dispositivo móvil para utilizar esos datos dependerá del desarrollo de software que haya detrás de la
aplicación utilizada para vincular con el wearable. Esta capa es opcional, ya que existen dispositivos que se
conectan directamente a la nube, pero lo más habitual es que esté presente.

Las tareas de procesamiento realizadas en esta capa suelen involucrar tareas de agregación de datos en
ventanas temporales más allá de las soportadas por el dispositivo wearable, y cálculos más avanzados. Se
suelen involucrar, además, tareas adicionales de integración con información provenientes de otras fuentes,
como mapas, redes sociales y otros. Esta integración permite explotar el verdadero potencial de los
dispositivos wearables sin necesidad, en algunos casos, de tener que vincularse a un servidor centralizado
de datos.

La tercera capa es aquella a la que llamamos «la nube». Consiste en un conjunto de recursos de
infraestructura gestionados, generalmente, por la empresa fabricante del dispositivo wearable. Los datos
procesados en esta capa ya no son individuales, en el sentido de que no se analiza sólo el dato del
dispositivo, sino la relación de ese dispositivo con toda la población existente. Estos datos suelen ser
trabajados con bastante discreción por parte de estas compañías ya que son, por un lado, datos privados y
sensibles. Por otro lado, esos datos son, además, el activo más importante de la empresa, que permite
hacer el diferencial contra los competidores. En esta capa se brindan soluciones más complejas, como
algoritmos de machine learning para realizar análisis predictivos y de segmentación de clientes.
Página 4 de 4

Almacenamiento y disponibilización de datos

La selección y utilización de la capa de almacentamiento y disponibilización de datos, dada las necesidades

de baja latencia, no son menores. Dado el tipo de datos, de características generalmente no estructuradas y
de bajo volumen individual, pero gran volumen colectivo, el enfoque más habitual es usar bases de datos no
estructuradas, documentales, también conocidas como NoSQL, que suelen permitir una latencia muy baja
de escritura. Esto permite soportar la escritura concurrente de datos de múltiples dispositivos a grandes
velocidades. Algunos ejemplos habituales de este tipo de bases de datos son:

On Premise:

Cassandra

MongoDB

Redis

On Cloud:

DynamoDB (AWS)

DocumentDB (AWS)

Cloud DataStore (GCP)

BigQuery (GCP)

Cosmos DB (Azure)
La utilización de estas bases de datos suele requerir un modelado de datos cuidadoso y una arquitectura
diseñada ad hoc. Son uno de los puntos más costosos de la infraestructura cuando hablamos de procesos
en realtime, por eso es importante diseñar la estrategia con cuidado. Estas capas de almacenamiento sólo
deberían usarse para los datos que deben mantenerse en caliente, es decir, que deben ser almacenados y
consultados con una latencia de un dígito de milisegundos.

En aquellos casos en los que no sea necesaria una consulta inmediata, y pueda manejarse un esquema de
espera o colas para consultar los datos, es más recomendable utilizar otros tipos de almacenamiento como
ser el HDFS. Particularmente los servicios cloud de almacenamiento HDFS tienen muy buenos tiempos de
respuesta y pueden ser utilizados para el almacenamiento de data a consultar en frío, y también datos a
archivar, a muy bajo costo.

Las soluciones de HDFS en la nube más conocidas son Simple Storage Service (AWS), Google Cloud
Storage y Azure Blob Storage.

Es en este contexto que hay que trabajar con negocio en definir muy claramente cuanto será el tiempo a
mantener los datos en cada zona, con el fin de poder mantener una arquitectura óptima operacionalmente al
menor costo posible.

Llamados a la bibliografía obligatoria

 Para profundizar en los elementos abordados en la unidad, deberá dirigirse a:

Casas Roma, J., Nin Guerrero, J. y Julbe López, F. (2019). Big data. ES: Editorial UOC.
Extensión: capítulo 1, páginas 21-60.
Para acceder, ingrese a eBook21. Por dudas o inconvenientes comuníquese a
biblioteca@ues21.edu.ar.

Godfrey, A., Hetherington, V., Shum, H., Bonato, P., Lovell, N.H. y Stuart, S. (2015). From A
to Z: Wearable technology explained. Recuperado de
https://www.sciencedirect.com/science/article/pii/S0378512218302330
 Kirby, B. y Mosley, B. (2015). The Architecture of Wearable Technology. Recuperado de
https://www.researchgate.net/publication/278327463_The_Architecture_of_Wearable_Tec
hnology

Llanesa Gonzalez, P. (2018). Seguridad y responsabilidad en la Internet de las cosas (IoT).

ES: Ed. Wolters Kluwer. Extensión: capítulo 1, Páginas 19-33.
Para acceder, ingrese a eBook21. Por dudas o inconvenientes comuníquese a
biblioteca@ues21.edu.ar.

Actividades de repaso de lecturas

Las soluciones ideales de almacenamiento para datos de dispositivos de

Internet de las Cosas están basadas en HDFS.

Verdadero

Falso

SUBMIT

Los pasos de una solución analítica involucran:

 Ingesta, Procesamiento, Almacenamiento,
Disponibilización

Almacenamiento, Procesamiento y Disponibilización.

Ingesta y Procesamiento.

Almacenamiento

SUBMIT

Las estructuras de datos estandarizadas más habituales para los wearables

son:

XML

FIT

JSON
 TCX

No hay estándar

SUBMIT

Relacione los procesamientos a realizar con las capas de procesamiento

Capa del Dispositivo

Registro de Datos Agregaciones Simples

Capa del Móvil

 Visualización y Agregaciones
complejas

Capa de la Nube o Servidor

Central

Algoritmos Predictivos

Las necesidades de procesamiento en tiempo real para dispositivos de tipo

wearable obligan al uso de tecnologías que permitan reducir la latencia al
mínimo posible.

Verdadero
Falso

SUBMIT