Implementación y configuración de un proceso de ETL en el ambiente de la nube pública para proyectos de Analítica Visual

Santiago Sáenz González

Universidad de Los Andes

Facultad de Ingeniería

Departamento de Ingeniería de Sistemas y Computación

Bogotá, 2020

2

Implementación y configuración de un proceso de ETL en el ambiente de la nube pública para proyectos de Analítica Visual

Santiago Sáenz González

Asesor

José Tiberio Hernández, Ph.D.

Profesor Asociado

Universidad de Los Andes

Facultad de Ingeniería

Departamento de Ingeniería de Sistemas y Computación

Bogotá, 2020

3

TABLA DE CONTENIDO

Resumen .......................................................................................................................................... 6

1 Introducción ........................................................................................................................... 7

2 Problema y Propuesta de Solución ................................................................................ 9 2.1 Problemática ............................................................................................................................... 9 2.2 Propuesta ...................................................................................................................................... 9

2.2.1 Objetivos .............................................................................................................................................. 9

3 Trabajo Relacionado ........................................................................................................ 10

4 Diseño de la Solución ....................................................................................................... 10 4.1 Almacenamiento de información sin procesar, Blop Storage ................................ 10 4.2 ETL, Azure Data Factory ....................................................................................................... 11

4.2.1 Configuración general ................................................................................................................. 12 4.2.2 Configuración Data Flow............................................................................................................ 14

4.3 Almacenamiento de la BD no relacional, Cosmos DB ................................................ 18 4.4 API, Azure function ................................................................................................................. 20

4.4.1 Conexión a Base de datos. ......................................................................................................... 20 4.4.2 Exposición del API ........................................................................................................................ 21

4.5 Costo total de sistema en la nube: ..................................................................................... 23

5 Implementación en proyecto de analytics................................................................ 23 5.1 Diseño ......................................................................................................................................... 23 5.2 Prototipo Versión JSON STATE ........................................................................................... 26 5.3 Prototipado Versión 2: JSON Copia ................................................................................... 28 5.4 Prototipado Versión 3: Edición de archivo JSON ......................................................... 29

6 Evaluación ............................................................................................................................ 30 6.1 Análisis del cumplimiento de los objetivos ................................................................... 30 6.2 Análisis de la implementación ........................................................................................... 30

7 Conclusiones y trabajo futuro ....................................................................................... 33 7.1 Conclusiones ............................................................................................................................. 33 7.2 Trabajo futuro .......................................................................................................................... 33

8 Trabajos citados ................................................................................................................. 34

4

INDICE DE FIGURAS

Ilustración 1: proyecto de análisis de Analítica Visual ......................................................................................................... 7 Ilustración 2:Servicios de Azure en el proyecto ....................................................................................................................... 8 Ilustración 3: Diagrama de componente de Azure .............................................................................................................. 10 Ilustración 4: Almacenamiento del Blob storage con tamaño del archivo ................................................................ 11 Ilustración 5:Precios dados por Microsoft a los contenedores por tamaño .............................................................. 11 Ilustración 6:Configuración a conexión al conteiner del esquema ............................................................................... 12 Ilustración 7: Configuración a conexión del container de los items ............................................................................. 12 Ilustración 8: Configuración MV ................................................................................................................................................. 13 Ilustración 9:Configuración del trigger ................................................................................................................................... 13 Ilustración 10: Esquema del proceso de Data flow.............................................................................................................. 14 Ilustración 11:Blob storage información ................................................................................................................................ 14 Ilustración 12: Preview de la información en un node de Data Flow .......................................................................... 15 Ilustración 13: Esquema utilizado para traer la información del blob storage ...................................................... 15 Ilustración 14: Validación del esquema del blob storage ................................................................................................. 15 Ilustración 15:Bifuración de nodos de información ............................................................................................................ 16 Ilustración 16:Filtrado y agregado de la columna de fecha de esquema ................................................................... 16 Ilustración 17:Configuración del sink del esquema ............................................................................................................ 17 Ilustración 18:Configuración de recreación y de RUS ........................................................................................................ 17 Ilustración 19:Proceso de ETL en tiempos .............................................................................................................................. 18 Ilustración 20:Conteiner Canguro .............................................................................................................................................. 19 Ilustración 21:Container esquema ............................................................................................................................................. 19 Ilustración 22:Index policy ............................................................................................................................................................ 19 Ilustración 23:Precio por RU ........................................................................................................................................................ 20 Ilustración 24: Claves Cosmos ...................................................................................................................................................... 20 Ilustración 25:Configuración desde Azure function a DB ................................................................................................. 21 Ilustración 26:Consumo de la aplicación en el body ........................................................................................................... 21 Ilustración 27:Requerimientos en el body............................................................................................................................... 21 Ilustración 28:Mensaje de error .................................................................................................................................................. 21 Ilustración 29:Condiciones de la query .................................................................................................................................... 22 Ilustración 30:Gráfica de tiempos por año ............................................................................................................................. 22 Ilustración 31:Cors policy Azure function ............................................................................................................................... 22 Ilustración 32:Precio función Azure .......................................................................................................................................... 23 Ilustración 33:Tabla de precios ................................................................................................................................................... 23 Ilustración 34:Configuración de las carpetas ........................................................................................................................ 24 Ilustración 35:Muestra general de la aplicación VA ........................................................................................................... 24 Ilustración 36:Rango de colores ................................................................................................................................................. 25 Ilustración 37: Date view ............................................................................................................................................................... 25 Ilustración 38: Estadísticos de máx y mín ............................................................................................................................... 25 Ilustración 39:Histograma por día de hospitalización ...................................................................................................... 26 Ilustración 40:Ocurrencia de días de hospitalización dado día de la semana ......................................................... 26 Ilustración 41:ComponentDidMount para obtener información de la api ................................................................ 27 Ilustración 42:Aplicación con fetch ........................................................................................................................................... 27 Ilustración 43:Visualización de espera mientas cargado de la información ............................................................ 28 Ilustración 44:Cambio de modelo ............................................................................................................................................... 28 Ilustración 45:Base de datos persistida de la aplicación localmente ........................................................................... 29 Ilustración 46:Paths del empaquetado la información ..................................................................................................... 29 Ilustración 47:Diagrama final cloud ......................................................................................................................................... 31 Ilustración 48:Precios finales del ambiente cloud ............................................................................................................... 31 Ilustración 49:Petición post a la función azure .................................................................................................................... 31 Ilustración 50:Proyecto usando el api ...................................................................................................................................... 32 Ilustración 51:Proyectos sin api, json local............................................................................................................................. 32 Ilustración 52: ETL process ........................................................................................................................................................... 10 Ilustración 53:Modelo ETL ............................................................................................................................................................ 10

5

Ilustración 54:Configuración Runtime ETL ............................................................................................................................ 10

6

RESUMEN

La nube pública es un paradigma que otorga la posibilidad del uso de infraestructura tecnológica sin tener que preocuparse del mantenimiento y de los costos de las máquinas físicas (Sahrif, 2015). Actualmente las tres grandes compañías que ofrecen estos servicios son Google (Google Cloud), Amazon (Amazon Web Services) y Microsoft (Azure), las cuáles ofrecen un catálogo de productos entre los que se encuentra la creación de instancias de máquinas virtuales, instancias Serverless, Pipelines, bases de datos transaccionales y no transaccionales, entre otros (Durkee, 2010). El gran espectro de instituciones con o sin ánimo de lucro, que han migrado sus propias infraestructuras para delegarlas a los terceros ya mencionado es amplia, nombres como e-Bay, Boeing, Samsung, BMW, y muchas otras compañías que se encuentran en el Fortune 500 (Durkee, 2010), hacen parte de este grupo, y la razón es simple, la tercerización de los servicios de infraestructura permite focalizar los esfuerzos de las organizaciones en sus operaciones principales.

Existe variables que permiten que una organización decida usar los servicios de una o varias entidades de nube pública, entre ellas se encuentra el porcentaje de disponibilidad que ofrecen sus servicios, la disponibilidad geográfica de los servidores (Durkee, 2010), el catálogo de productos, la usabilidad de los productos y la compatibilidad que tienen estos respecto al software que haya desarrollado cada una de las organizaciones. Por lo planteado, se puede asumir que no hay un único proveedor que cumpla con todas las necesidades del mercado, y cada uno de ellos tiene un nivel de especialización en diferentes productos lo que permite perfilar a los posibles clientes (Di Niu, 2012).

Este trabajo tiene el fin proponer e implementar los servicios de la nube pública a los proyectos de Analítica Visual que están siendo usados por la Fundación Canguro actualmente. Parte de la problemática con la que se encuentran actualmente, es que no existe un sistema centralizado de información de donde puedan obtener, los distintos proyectos, de manera homogénea los registros de información, de tal manera que se tenga una infraestructura escalable parar los futuros desarrollos que la organización vaya a implementar.

El proyecto cuenta con una etapa de evaluación de arquitectura, implementación de productos y demo con un prototipo de Analítica Visual que permita verificar los manejos correctos que se debe tener para el uso de la infraestructura implementada. El resultado del proyecto debe de ser un sistema centralizado en la nube pública que se conecte con un proyecto de Analítica Visual y que esté basado en los datos suministrados por la fundación.

Para evaluar el proyecto se considera que debe cumplir con consistencia, acceso restringido para los distintos usuarios, y costos de mantenimientos que no superen los 150 dólares anuales, lo que garantiza una infraestructura ideal para la organización.

7

1 INTRODUCCIÓN

Actualmente, la fundación Canguro cuenta con dos grandes bases de datos de información de recién nacidos, en una almacena registros de bebés prematuros nacidos desde el 2007 hasta la actualidad, y en otra se tiene registros tomados en el año 1994 (Charpak, 2017), en done hay información de más de 33,000 recién nacidos. La información registrada puede ser de carácter fisiológico, económico (de la familia) y psicológico. La cantidad de atributos, atribuido al primer set mencionado, es a la fecha de 268, este valor a aumentado con el tiempo y se espera que siga siendo así.

Como se puede ver reflejado, esta gran cantidad de información requiere de herramientas que puedan permitir a los investigadores de la fundación, analizar y genera conclusiones respecto a diferentes patrones que se encuentren en los registros almacenado. Esta necesidad ha llevado a que la fundación se apoye de diferentes proyectos de Analítica Visual, con los fines ya mencionados.

Actualmente se tienen dos proyectos de Analítica Visual por parte del grupo de investigación IMAGINE, uno desarrollado por la Magister Deisy J. Díaz (Díaz, 2017) , el cual se conoce como “KMC-1stYear-VA” y otro por el actual estudiante Juan Pablo González Pena que tiene el nombre de “PMC-crecimiento1año” (González, 2020).

El proyecto “KMC-1stYear-VA” Deisy explora un proyecto de Analítica Visual con la base que se tomó en el año 1994. El proyecto analiza la información fisiológica, tanto de los recién nacidos como de los padres, y de los factores ambientales a los que estuvo expuesto el sujeto durante la etapa de gestación y nacimiento. Con la ayuda de elementos visuales como histogramas, diagramas de caja, entre otros, cumple con la finalidad de proveer información valiosa a los stakeholders de la fundación (Díaz, 2017).

Ilustración 1: proyecto de análisis de Analítica Visual

El proyecto de “PMC-crecimiento1año” explora también con la base que se tomó en el año 1994. Este proyecto se apoya de elementos visuales como histogramas de tendencia, entre otros elementos, que permiten responder a diferentes preguntas respecto al estado fisiológico del recién nacido, dando un mayor beneficio a los stakeholders de la fundación (González, 2020).

Actualmente estos dos proyectos cuentan cumplen con su finalidad desde una perspectiva de Visual Anlytics, pero cuenta con un gran problema, y es que ambos proyectos de diseñaron con información persistida localmente, lo que implica que no existe una consistencia entre ambos.

8

Además, dificulta con mayores veras la homogeneidad de la información que los proyectos necesitan para dar con seguridad a los stakeholders información valiosa.

En este proyecto de grado se plantea la estructura y el uso de un sistema en la nube pública para que se genere un proceso de ETL que se desencadene en un api que pueda ser consumida por los diferentes proyectos de los cuales la fundación utiliza para el análisis de su información.

Ilustración 2:Servicios de Azure en el proyecto

9

2 PROBLEMA Y PROPUESTA DE SOLUCIÓN

Esta sección presenta una explicación detallada de la problemática y una propuesta de solución basada en tres productos de Microsoft Azure: CosmosDB, DataFactory y Azure Function y la creación de un proyecto con el Framework de react para la validación del sistema.

2.1 Problemática

Actualmente, la fundación Canguro cuenta con un registro de 50.000 bebes prematuros, que crece cada año, en donde se incluye información fisiológica del bebe e información económica y social de su entorno familiar. La fundación cuenta con diferentes proyectos de Analítica Visual que tiene como función permitir visualizar información valiosa para los stakeholders que puede ser identificada más fácilmente por elementos visuales. Actualmente se tienen dos proyectos principales como lo son el implementados por Deisy y Juan Pablo. Estos dos cuentan con archivos JSON incrustados en sus directorios locales, con los registros ya mencionado, lo que implica que no se puede garantizar la homogeneidad de la información en todo el espectro de los proyectos que busque proveer información a la fundación, lo cual puede implicar que la información mostrada a los stakeholders puede llegar a ser engañosa, lo que puede llevar a que la organización a tomar decisiones que no son realmente beneficiosas para esta misma. Además de un claro problema de consistencia, el problema se agrava en el momento que se escale la cantidad de proyectos que estén relacionados a la base de registros ya mencionada, sin mencionar los futuros problemas de seguridad, en especial de confidencialidad que supone dar acceso a la información de los sujetos a cualquier desarrollador sin ningún tipo de control.

2.2 Propuesta

Proporcionar un sistema de centralizado de información en la nube pública, en donde se procese, almacene y distribuya los registros que anualmente crecen de tal manera que la organización pueda garantizar la integridad y la accesibilidad en sus proyectos de desarrollo.

2.2.1 Objetivos

Los objetivos del proyecto se basan principalmente en el desarrollo de todo el ambiente en la nube pública con el fin de desarrollar un ambiente de información homogénea para la fundación canguro.

Objetivo general: Diseñar e implementar un sistema centralizado basado en la nube publica para el procesamiento, almacenamiento y distribución de la información.

Objetivos específicos: Para cumplir con el objetivo general, se proponen los siguientes objetivos específicos:

• Desarrollar un proceso de ETL que procese y guarde la información de un archivo a una base de datos no relacional.

• Crear una API que permita el acceso a la información centralizada del sistema.

• Disminuir los costos se los servicios de la nube, tan poco como el proyecto lo permita.

• Almacenar un histórico de esquemas procesados.

10

• Crear un proyecto de Analítica Visual que utilice, exitosamente, el sistema centralizado en la nube.

3 TRABAJO RELACIONADO

4 DISEÑO DE LA SOLUCIÓN

Esta sección describe, de forma específica, la arquitectura de la solución propuesta en este proyecto. Para esto se empezará dando una breve introducción a los servicios usados de la nube pública de Azure. Azure es el servicio de la nube prestados por Microsoft, en el proyecto actual se crearon y configuraron Blob Storage, Azure Data Factory, CosmosDB y Azure Function. Cada uno de estos componentes fue creado en las costas este central de los Estados Unidos de América. La ubicación se plantea por el hecho de que los componentes deber de estar en una única ubicación para tener una mejor conectividad entre ellos (Wenjin Hu, 2010).

El diagrama de componente se muestra en la siguiente imagen:

Ilustración 6: Diagrama de componente de Azure

Como se observa, existe un proceso de almacenamiento inicial, seguido por un proceso de ETL, para finalizar con la exposición del Api para el consumo. A continuación, se explicará cada servicio y su función en el sistema de la nube.

4.1 Almacenamiento de información sin procesar, Blop Storage

“Blob Storage” es un servicio prestado por Azure para el almacenamiento de información sin procesar (Tamra Myers, 2020). En nuestro caso, la fundación Canguro almacena la información en archivos Excel, por lo que el servicio cumple con el requerimiento de almacenar información preprocesada.

Este servicio tiene un costo de 0.0184 dólares por GB al mes, por almacenar en “Caliente” una cantidad equivalente a 50 TB al mes (Di Niu, 2012). El archivo proporcionado por la fundación canguro tiene un peso actual de 113,2 MB por lo que este precio será constante a pesar de que aumente significativamente la recolección de registros.

11

Ilustración 7: Almacenamiento del Blob storage con tamaño del archivo

Ilustración 8:Precios dados por Microsoft a los contenedores por tamaño

La inserción del archivo debe hacerse siempre con el mismo nombre, y se debe cambiar el nombre del anterior archivo con el fin de que todo el proceso se ejecute sin ningún problema.

El servicio, como se verá más adelante, es usado para almacenar los logs dados por el servicio de Azure Function.

4.2 ETL, Azure Data Factory

El proceso de ETL (Extract, transform and load) es un proceso usados en el Data Engineer, con el fin de extraer información cruda para procesarla y almacenarla de una manera que sea beneficiosa para el negocio (AliEl-Sappagh, 2011).

12

El Data factory es un servicio especializado de Azure que permite de manera interactiva configurar estos procesos (Wee Hyong tok, 2019). El servicio cuenta con diferentes subservicios que son esenciales para la transformación de la información. Para el caso actual, solo se hará uso del Data Flow, subservicios idóneo para lo que se requiere en el proyecto (Vassiliadis, 2006).

Para que el Azure Data Factory funcione correctamente, debe de tener una configuración general del servicio y uno especializado para el data Flow. A continuación, se explicará las dos configuraciones.

4.2.1 Configuración general

Para que el servicio se pueda ejecutar correctamente, debe de tener una configuración de las bases de datos usadas. En el caso en particular del proyecto solo se usa una base de datos no relacional, la cual sería Cosmos DB. La configuración de esta conexión requiere permisos de administrador, que permita conectar a la base de datos.

Ilustración 9:Configuración a conexión al conteiner del esquema

Ilustración 10: Configuración a conexión del container de los items

Parte de cómo funciona el Data Factory, se basa en crear una máquina virtual, para poder ejecutar todo el proceso. La máquina virtual mínima utilizable, se crea con cuatro cors y 1GB de RAM. La creación de las MV puede ser tan potente como se desee, pero eso también implica un aumento de los precios.

13

Ilustración 11: Configuración MV

Existen dos últimas configuraciones necesario para la ejecución debida, la configuración de los triggers con el fin de que la ejecución sea única. La configuración se da cada 6 meses para que el proceso no necesite se supervisión.

Ilustración 12:Configuración del trigger

Finalmente se debe crear el primer componente que hará una referencia al Data Flow que se explicará a continuación.

14

4.2.2 Configuración Data Flow

El data Flow funciona con nodos equivalentes a funciones. El fin de este subservicio es insertar la información procesada en la base de datos no relacional. Se debe considerar que la BD debe de tener un registro con la información procesada y también con un container que tenga la muestra de un elemento del set de datos y la fecha de inserción, de esta forma se puede tener un rastreo del esquema usado en cada proceso (Hassan Rasheed, 2020).

Ilustración 13: Esquema del proceso de Data flow

• Configuración de nodo Source

El nodo source es de donde se extrae la información para ser procesada. Como se mostró anteriormente, la información sin procesar es almacenado en un Blob storage en forma de un archivo de Excel, lo que implica que se debe configurar la conexión al servicio, para posteriormente indicar el archivo, y la hoja a procesar.

Ilustración 14:Blob storage información

Parte de cómo se comprueba el correcto funcionamiento del nodo es activando el Data Debug, el cual permite visualizar una muestra de datos del proceso que realmente se desea. El “Preview” aunque muestra información correcta, no será posible de utilizar en nodos posteriores porque no cuenta con un esquema definido.

15

Ilustración 15: Preview de la información en un node de Data Flow

La configuración del esquema se puede importar o definir con ciertas reglas, por facilidad en nodos posteriores, el esquema es importado y a su vez es definido como para que los valores numéricos siempre sean valorados como Integers, mientras que los valores de fecha se manejan con un estándar definido para obtener homogeneidad en todo el espectro de información.

Ilustración 16: Esquema utilizado para traer la información del blob storage

Ilustración 17: Validación del esquema del blob storage

16

• Configuración de esquema

Como se plantea en los objetivos, los procesos de transformación deben de ser registrados, de tal forma que puedan ser rastreables los esquemas usados en todo el historial de procesamientos.

Es por el objetivo ya mencionado que se hace una bifurcación del proceso como se puede ver en la imagen.

Ilustración 18:Bifuración de nodos de información

La idea de este proceso es crear una nueva columna con el valor de la fecha actual, con el fin de que se pueda tener un rastreo de la información.

Ilustración 19:Filtrado y agregado de la columna de fecha de esquema

La idea de esta parte del proceso es solo obtener un elemento de la muestra, por lo que solo se filtra el primer elemento de los registros.

• Sink

El proceso Sink, es la etapa final, en donde se insertan los datos deseados en los containers estipulados, tanto como para el caso del esquema como para el caso de los datos procesados. Para la configuración del Sink, se debe de tener mucho cuidado al ajustar la opción de solo permitir inserciones, también al permitir la nueva creación del container y obviamente de que se tenga el partition key estipulado en la base de datos.

17

Ilustración 20:Configuración del sink del esquema

El proceso de sink de los datos procesados es ligeramente distinto, dado que la idea es que el container sea creado desde un principio, es configurado de tal manera borrar los anteriores registros, lo que implica configurar un nuevo RU, procesamiento de base de datos. Es muy importante que los RU sean configurados con su mínimo posible, que son 400, en caso de no hacerlo esto podría afectar notoriamente el proceso de costos de la aplicación.

Ilustración 21:Configuración de recreación y de RUS

EL proceso de ETL una vez ejecutado, tarda un total de 43 minutos, en todo el proceso ya mencionado.

18

Ilustración 22:Proceso de ETL en tiempos

• Costos

El proceso en total se puede facturar a partir de varios elementos, tiempo de máquina en ejecución, número de registros procesados, uso de Data flows etc. En nuestro caso particular el precio fue de 7 dólares aproximadamente. Se debe recordar que este precio es algo que sucede semestralmente (Di Niu, 2012).

4.3 Almacenamiento de la BD no relacional, Cosmos DB

Este proyecto cuenta con el uso de una Base de datos no relacional. Esta Base de datos, cuenta con dos containers que almacenan los datos procesados y el esquema de información (Mark Brown, 2020).

El container de los datos procesados es nombrado como CanguroContainer, en él se establece una partition Key nombrada como Iden_Codigo.

19

Ilustración 23:Conteiner Canguro

Por otro lado, los datos de los esquemas son nombrado como CanguroEsquema, y tiene como partitio key Iden_Codigo.

Ilustración 24:Container esquema

Es importante establecer que un index policy es fundamental, para un correcto funcionamiento, al procesar la información. Las políticas son definidas de la siguiente manera:

Ilustración 25:Index policy

20

Finalmente, el precio de los procesos varía respecto la cantidad de RUS planteados para usar, y el tamaño de la información a almacenar. La base de datos tiene un total de 1.5 GB por lo que se puede entender que el precio es estable.

La variable más importante son los RU, estos tienen un valor mínimo posible, que es equivalente a 400 RU y que implican un valor total de 20 dólares (Di Niu, 2012).

Ilustración 26:Precio por RU

4.4 API, Azure function

Una función Azure, es el servicio denominado Serverless, porque permite no tener un mantenimiento de los procesos de una máquina virtual. Esto implica una funcionalidad constante y estable. Las funciones de Azure se crean junto a un servicio de telemetría, un servicio blob storage y una instancia de Linux (Practical Azure functions, 2019).

La implementación de una función Azure puede hacerse en distintos lenguajes de programación, para el caso del proyecto de grado, se decide usar Python 3.8. El proyecto debe se implementarse localmente en visual studio code, como requerimiento impuesto por Microsoft, una vez desplegado, el código podrá ser modificado desde el navegador.

El código cuenta con dos etapas, conexión a base de datos Cosmos DB y exposición del API.

4.4.1 Conexión a Base de datos.

La conexión a base de datos de cosmos, se deber realizar a través, de la información de los keys presentador en la configuración del servicio.

Ilustración 27: Claves Cosmos

21

Es primordial configurar un archivo requirements.txt, el cual va a tener todas las dependencias necesarias para ejecutar el proyecto, en nuestro caso particular serán las librerías cosmos y Azure.

Una vez conocida la información es posible configurar, con ayuda de las librerías, la conexión a base de datos.

Ilustración 28:Configuración desde Azure function a DB

4.4.2 Exposición del API

Para la exposición del API, se plantea un servicio POST, en donde el body recibe tres parámetros: FechaInicial, FechaFinal y Atributos. En caso de que no se quiera considerar alguna de las fechas el valor deberá ser asociado a un “*”. Para el caso de los atributos, se pueden obtener los atributos que se deseen, siempre y cuando estén separados por una coma.

Ilustración 29:Consumo de la aplicación en el body

Ilustración 30:Requerimientos en el body

En caso de que alguno de los elementos principales del body, se indica al usuario aquellos datos que no fueron dados.

Ilustración 31:Mensaje de error

22

El código puede ser asociado a distintas sentencias SQL, dependiendo de la información dada en el body del POST.

Ilustración 32:Condiciones de la query

Una vez configurado el código, puede desplegarse el proyecto y hacer pruebas de tiempos de ejecución, la siguiente gráfica muestra los tiempos de respuestas dados los filtros de fechas asociados.

Ilustración 33:Gráfica de tiempos por año

Finalmente, es necesario que el proyecto tanga configurado las políticas de CORS necearías para que pueda ser consumido por los dominós que se considere permisibles.

Ilustración 34:Cors policy Azure function

Las funciones de Azure tiene un precio asociado estático por petición realizada, esto lo hace un producto barato y útil para la gran cantidad de datos que se plantea utilizar en todo el proceso.

23

Ilustración 35:Precio función Azure

4.5 Costo total de sistema en la nube:

Todo el ecosistema en la nube tiene un valor mensual aproximado a 6 dólares esto se puede explicar en el siguiente cuadro comparativo, en donde se muestra cada uno de los servicios ya mencionado su precio asociado y su uso (Durkee, 2010).

Ilustración 36:Tabla de precios

5 IMPLEMENTACIÓN EN PROYECTO DE ANALYTICS

Esta sección presenta la implementación del prototipo de un proyecto de Analítica Visual que use el api desarrollado de la sección anterior. Para este ejercicio de usará el Framework de Javascript React junto con D3 (Andrienko, 2007). Se exploran tres aproximaciones, el manejo de la información en los estados internos, la escritura de las peticiones en archivos internos, y el manejo manual de la inserción del proyecto.

5.1 Diseño

La aplicación consta de un archivo donde se persiste la información, tres componentes globales y un state general de toda la aplicación, la información siempre tendrá el mismo formato por el cuál fue registrado en la base de datos (Sacha, 2016).

24

Ilustración 37:Configuración de las carpetas

La aplicación consta de tres partes fundamentales: date view, estadísticas de texto y un histograma. La finalidad de la aplicación es poder mostrar información de los días de hospitalización en relación con los recién nacidos, y por lo tanto cada componente tiene la finalidad de proveer información adicional a los stakeholders.

Ilustración 38:Muestra general de la aplicación VA

Para el caso particular de los Date view, se desea mostrar las fechas de nacimiento que implicaron una mayor cantidad de días de hospitalización. El rango de colores es categorizado de la siguiente manera.

25

Ilustración 39:Rango de colores

Ilustración 40: Date view

Las estadísticas de máximos, mínimos y promedio son calculadas con recorridos básicos, y son resaltados para dar la importancia necesaria para que el proceso sea considerado por los stakeholders.

Ilustración 41: Estadísticos de máx y mín

Los histogramas, tienen la misión de dar información acerca de la acumulación de días de hospitalización, dado el día de la semana (lunes, martes, miércoles, etc.).

26

Ilustración 42:Histograma por día de hospitalización

El usuario tiene la posibilidad de ver la muestra asociada a cada componente, en sus respectivos días de la semana.

Ilustración 43:Ocurrencia de días de hospitalización dado día de la semana

Cabe resaltar que se implementan don versiones para la información del año 2020 y para el 2019, se desea con esto comparar persistencia de la información localmente, bajo escritura y con manejo del state.

5.2 Prototipo Versión JSON STATE

Para este prototipo se utilizan los state que permite persistir la información, una cualidad particular de React.js. El principio de renderización que se utilizó fue de componentDidMound, este principio permite ejecutar una función en el momento en que se está renderizando la información. El cargue de la información suele tomar 5.67 segundos en promedio, por lo que se presenta una página de espera para que el usuario entienda que se está extrayendo la información.

27

Ilustración 44:ComponentDidMount para obtener información de la api

Cabe resaltar que este manejo de la información es notoriamente inconveniente si se carga una cantidad de información mayor a un año, además implica un mayor costo dado que la petición se hará constantemente cada vez que se renderice la página. Para nuestra prueba, es decir la del año 2019, se usa un fetch para extraer la información de la BD

Ilustración 45:Aplicación con fetch

28

La persistencia de la información hace que la aplicación se ralentice notoriamente, y esto se puede notar en dos aspectos. Para el caso del histograma, la opción de cambiar a la cantidad de sujetos genera un retraso de un promedio de 2.34 segundos.

Ilustración 46:Visualización de espera mientas cargado de la información

Para el caso de cambio de url, en donde se puede devolverse a la url que maneja la información de los usuarios persistidos en un archivo localmente, tiene un tiempo de retraso de 3.45 segundos.

Ilustración 47:Cambio de modelo

5.3 Prototipado Versión 2: JSON Copia

Esta aproximación tiene el fin de hacer una copia manual de la información haciendo uso de la aplicación POSTMAN. El principio es permite tener una fluidez en la aplicación que en otras circunstancias no se tendrían. Dado que la aplicación siempre maneja el mismo nombre de las variables no habría ningún problema ejecutándolo.

29

Ilustración 48:Base de datos persistida de la aplicación localmente

El problema de esta aproximación es que simplemente no es un proceso automático y que puede permitir lapsos de tiempo en el que la información no sea consistente.

5.4 Prototipado Versión 3: Edición de archivo JSON

El prototipo de escritura de json, tenía el fin de combinar las dos anteriores aproximaciones. Esta aproximación a diferencia de las anteriores no fue exitosa, debido a que el empaquetado de archivos en react, genera diferentes paths en el browser que no pueden ser editables. Para los archivos JSON que se desean editar se genera un PATH ‘data’ y otro PATH ‘data//.*’ que empaquetan la información del json y no permite que se mutable.

Ilustración 49:Paths del empaquetado la información

Como principio de seguridad general una aplicación web no debería ser capaz de modificar archivos locales del computador o mucho menos del mismo browser por lo que esta aproximación es descartada.

30

6 EVALUACIÓN

6.1 Análisis del cumplimiento de los objetivos

Los objetivos planteados en la sección 2.2 fueron cumplidos en su gran mayoría, esto debido a las diferentes iteraciones y experimentaciones que se hicieron tanto en el entorno de la nube como en la aplicación de React. Esto implica que existieron deslicen a la hora de implementar servicios en la nube afectando la facturación. Estos deslices fueron mitigados limitando el acceso al ambiente interno y específico local

A continuación se presenta un analisis punto por punto de los objetivos específicos planteados en la sección 2.2:

• El proceso desarrollado juntando los servicios de blob sotrage, data factory y cosmos db, son la perfecta combinación para que un proceso ETL sea creado y ejectudado correctamente en un tiempo mínimo posible, posibilitando un proceso automático de transofrmación de la información que usualmente sería manual.

• El uso del Azure function permite crear una api con una única función POST que premite entregar a todos los integrantes de la fundación canguro, limitando el uso cualquier uso externo, para que se pueda obtener información dado los atributos requeridos en los rangos de fecha de partos que se deseen.

• La disminución de los costos de logra usando los servicios y configuraciones más bajas posibles, desde la máquina con menor cantidad de recursos en el ETL, pasando por la configuración de 400 RUS de la base de datos de cosmos DB, hasta finalmente el uso de las funciones de Azure que por su naturaleza están diseñaos para generar costos casi imperseptibles para la fundación.

• El peroceso de ETL es capaz de genera un registro de la información que permite rastrear en la base de datos de cosmos información de los esquemas utilizados en cada proceso.

• Se implementa una aplicación de Analítica Visual que prueba que la api es posible de utilizar en diferentes tipos de entornos a excepción de la escritura local de archivos.

6.2 Análisis de la implementación

La implementación de este proyecto, en especial del prototipo final, se basó en cumplir con los objetivos declarados en la sección 2.2, para desarrollar y diseñar un sistema de autenticación amigable y seguro para los usuarios móviles.

6.2.1.1 Resultados

Como resultados podemos ver el siguiente ecosistema en la nube que se muestra en el siguiente diagrama:

31

Ilustración 50:Diagrama final cloud

Este ecosistema permite procesar información la base dada por la fundación en una hora y con un total de precios asociados a la siguiente información:

Ilustración 51:Precios finales del ambiente cloud

Se genera un api capaz de proveer información a los participantes de la fundación canguro con de manera consistente y con el siguiente esquema en la petición de JSON:

Ilustración 52:Petición post a la función azure

32

Se crea un prototipo de un proyecto de Analítica Visual que permite obtener mostrar la interacción de una aplicación y como el manejo de persistencia de estados puede ralentizar la aplicación, y como el manejo manual de la copia de información es la opción más viable para proyectos ya existentes de la fundación canguro.

El prototipo tiene como meta de mostrar dos alternativas de implementación que pueden ser usadas al momento de usar la api canguro:

Primera alternativa:

Cargara toda la información necesaria del api en el cache de la aplicación, siendo más específico para el caso de React, serían cargar la información del “State”. Esta implementación implica una ralentización de la aplicación que es notoria en el caso del primer renderizaje.

Ilustración 53:Proyecto usando el api

Segunda Alternativa:

La segunda alternativa implica que el usuario debe hacer el llamado del api en una aplicación tercera, como lo es POSTMAN o Insomnia, para posteriormente pegarlas en el json de la aplicación del cual se alimenta la aplicación. El problema de esta aproximación es que no permite una actualización automática de la aplicación, pero evita la ralentización de la aplicación, a diferencia de la primera alternativa.

Ilustración 54:Proyectos sin api, json local

33

7 CONCLUSIONES Y TRABAJO FUTURO

7.1 Conclusiones

Un ecosistema centralizado en la nube es fundamental para que una organización pueda consumir información de manera centralizada y consistente, aunque este genera gastos extras, se pueden disminuir los precios en la medida que se seleccione, se implemente y se configure correctamente los productos.

La configuración errónea de los productos puede terminar en consecuencias como costos desmesurados o fallos en el proceso de ETL. Se debe limitar siempre el uso de los servicios a aquellos usuarios que estés autorizados para usarlos.

Los proyectos de Analítica Visual pueden consumir información masiva de un api para permitir consistencia en la información tanto en el proyecto que se esté trabajando como con sus homólogos, generando resultados óptimos a los stakeholders. El uso del api también ralentiza el uso de las aplicaciones, la escritura de su información implica un enorme problema de seguridad.

7.2 Trabajo futuro

Como trabajo futuro para la continuación de este proyecto, se plantean las siguientes mejoras:

• Implementar el uso del api en proyectos existentes de la fundación canguro para que pueda ser globalmente usado en toda la fundación canguro.

• Crear proyectos back en donde se permita la escritura de archivos con el fin de se pueda escribir la información del api sin tener que implicar problemas de seguridad.

• Migrar el proyecto “KMC-1stYear-VA” a la infraestructura desarrollada de Azure para que la herramienta funcione con la versión de los últimos datos actualizados.

• Crear el ambiente configurado para únicamente el servicio de la fundación canguro y sus proyectos asociados.

34

8 TRABAJOS CITADOS

AliEl-Sappagh, S. H. (2011). A proposed model for data warehouse ETL processes. Journal of King Saud University, 104.

Andrienko, G. (2007). Visual Analytics Tools for Analysis of Movement Data. ACM, I(1), 9.

Charpak, N. (2017). Twenty-year Follow-up of Kangaroo Mother Care Versus Traditional Care. American Academy of Pediatrics, I(1), 12.

Di Niu, C. F. (2012). Pricing Cloud Bandwidth Reservations. ACM, 40(1), 12.

Díaz, D. V.-G. (2017). Visual tools for the exploration of growth data in a cohort of kangaroo infants during their first year of life. IEEE, I(1), 9-16.

Durkee, D. (2010). Why cloud computing will never be free. ACM, 11.

Fischer, F. (2013). BANKSAFE: Visual analytics for big data. SAGE.

Glenn Gailey. (2018). Choose the right integration and automation services in Azure. Redmond: Microsoft.

González, J. C. (2020). Herramienta de análisis visual para la exploración y comprensión del crecimiento de los bebés canguro desde el momento en que nacieron hasta su primer año. Universidad de los Andes.

Hassan Rasheed. (2020). Extract, transform, and load (ETL) at scale. Redmond: Microsoft.

Mark Brown. (2020). Welcome to Azure Cosmos DB. Redmond: Microsoft.

Practical Azure functions. (2019). Singapur: Apress.

Prada, J. P. (2018). Visual Tools for data in a cohort of kangaroo infants. IEEE, I(1), 8.

Roberto Freato. (2015). Microsoft Azure Security. Redmond: Packt Publishing.

Rodic, J. (2009). Generating Data Quality Rules and Integration into ETL. Oracle, 72.

Sacha, D. (2016). The Role of Uncertainty, Awareness, and Trust in Visual Analytics. IEEE, 9.

Sahrif, A. M. (2015). The hype and promise of Cloud Computing. Brunnel Bussiness school, 5.

Tamra Myers. (2020). Storage account overview. Redmond: Microsoft.

Vassiliadis, P. (2006). Conceptual modeling for ETL process. National technical univeristy of athens, 21.

Wee Hyong tok. (2019). What is Azure Data Factory? Redmond: Microsoft.

Wenjin Hu, T. Y. (2010). The Good, the Bad and the Ugly of Consumer Cloud Storage. Clarkson Univerisy, I(1), 6.