Documento de arquitectura de TI del

proyecto: “Construcción de una

plataforma móvil y de grandes datos
para la inspección, vigilancia y control
de establecimientos comerciales a nivel
municipal
1. INTRODUCCIÓN
El presente documento hace parte de los productos finales del proyecto 52860 de Colciencias:
“Construcción de una plataforma móvil y de grandes datos para la inspección, vigilancia y
control de establecimientos comerciales a nivel municipal. Este proyecto fue ejecutado por la
alianza Universidad Sergio Arboleda - Platcom SAS. En resumen, el proyecto plantea una
plataforma con los siguientes componentes tecnológicos:

• Una arquitectura TI que permite la conexión de dispositivos y aplicativos móviles.

• Una plataforma de grandes datos que permite el almacenamiento y consulta a los

funcionarios, comerciantes y ciudadanos.

• Un sistema de analítica con modelos de datos que permiten cuantificar el riesgo y

especializarlo para generar alertas y acciones de prevención

El primer paso para la construcción de la arquitectura TI, fue la construcción de una base de
datos unificada que pudiera centralizar la información que genera el sistema IVC. El siguiente
paso fue la implementación de una arquitectura basada en contenedores con soporte Docker,
en nube privada Amazon Cloud AWS. capaz de soportar procesamiento de Big Data en
Hadoop, con una capa de orquestación mixta que permite manejar tanto recursos
virtualizados en VM como recursos en Bare-Metal.

A continuación se presenta una decripción de la base de datos construida y de la arquitectura

de TI implementada

2. MODELO DE DATOS DEFINITIVO SISTEMA IVC

Una vez depurada la información y la generación de la información geográfica asociada, el

diseño de la base de datos IVC quedó configurado en 2 bases:

2.1. BASE IVC Principal:

De esta base se destacan las tablas relacionadas con establecimiento, visitas, entidades y
códigos CIUU. Además de esta tablas principales se adicionaron tablas que contienen la
información conglomerada de las bases de datos adicionales denominadas
actualizaciones_2014 y visitas_plano, en donde se almacenan todos los registros almacenados
como en su inicio. El detalle del modelo se puede observar en la Ilustración No 1:
Ilustración 1. Modelo Entidad Relación IVC
Ilustración 2. Información geográfica incluída
VISITAS A ESTABLECIMIENTOS

 Las visitas se realizan a establecimientos formales y no formales.

 Se realiza la verificación entre otras del código CIIU registrado y el evidenciado al
momento de la visita.
 Un establecimiento puede tener varias visitas.
 Una visita tiene una motivación o tipo de intervención
 Al finalizar una visita se emite un Concepto favorable, desfavorable o se aplaza emisión
del concepto

Ilustración 3. Modelo datos IVC

 2.2. GEOLOCALIZACIÓN DE VISITAS Y
ESTABLECIMIENTOS

Dentro de la base de IVC también se incorporó información básica de geolocalización de tal

manera que los aplicativos puedan ubicar por latitud y longitud, tanto los establecimientos
como las visita, como se puede observar en la Ilustración 4. Información geográfica de visitas y
establecimientos.

Ilustración 4. Información geográfica de visitas y establecimientos

Para referenciar la información de longitud y latitud, de las tablas geo_establecimiento, se

utilizó forma de información básica como se muestra en la Ilustración 5. Estructura de campos
de la tabla geo_establecimiento.
Ilustración 5. Estructura de campos de la tabla geo_establecimiento

Para ilustrar la manera como esta información es guardada, se puede observar un resultado de
una consulta sobre la tabla en la Ilustración 6. Consulta datos latitud, longitud
establecimientos

Ilustración 6. Consulta datos latitud, longitud establecimientos

2.3. FUENTES DE DATOS UTILIZADAS

Las fuentes utilizadas tienen 2 fuentes principales:

 Bases de datos y actualizaciones sobre los establecimientos y matrículas de origen CCB
 Información de visitas 2014-2016 realizadas por las diferentes entidades de IVC. De
estas fuentes las única completas y funcionales fueron las realizas por la secretaria de
salud.
Se requiere que se pueda identificar la matrícula del establecimiento y su razón social
 2.4. Estadísticas sobre los datos migradas

De visitas

De establecimientos
 2.5. FUENTES DE DATOS DE GEOANÁLISIS

Para actualizar y analizar la información geográfica relacionada se creó una base de datos que
está soportada en las extensiones de Postgres para GIS, y su detalle se muestra en la siguiente
figura:
Ilustración 7. Modelo de datos geoanálisis
Dentro de este modelo podemos observar diferentes tablas denominadas grid1 hasta grid7,
que contiene la información de los capas con tamaños de divisiones de colmenas diferente,
barrio, upz, localidad, sector, etc. Además de esto están la información geográfica relacionada
a eventos ocurridos por los números NUSE 123, que se relacionan en las tablas que comienzan
por i611, hasta i968. En cada uno de estas tablas se encuentran datos de geolocalización de
eventos, de cada uno de los tipos.

La información aquí almacenada ha servido para realizar consultas espaciales relacionadas con
el estrato promedio, la población por colmena, el número de incidencias por colmena de los
diferentes tipos y para poder correr los algoritmos de aprendizaje de máquina adicional

3. PROCESO DE DEPURACIÒN DE DATOS E

INSTRUCCIONES PARA CARGA DE DATOS.

Para realizar la limpieza y generación del modelo de datos se utilizaron las siguientes fuentes
de datos:

1. Excel con las visitas depuradas año 2014_206

2. Tablas de establecimientos formales entregados por la cámara de comercio de Bogotá,
CCB.
3. Actualización de establecimientos que actualizaron matricula mercantil hasta el 2016.
4. Excel de visitas realizadas por secretaria de salud 2014-2016

ETLS involucrados:

 clasificacion_trabajadores.ktr
 terminal_portuario.ktr
 etl ciiu.ktr
 ivc_schema_def.sql
 etl_establecimiento.ktr
 etl_excel_visitas.ktr
 tipo_identificacion.ktr
 actualizacion_2016establecimientos.ktr
 nuevos_establecimientos_visitas.ktr

Estos ETL fueron realizados en Pentaho Data Integration, con la herramienta Spoon. A partir de
estos ETL, se cargaron los datos de acuerdo a los siguientes parámetros:

- Solo se cargaron establecimientos a los cuales se les podía asociar un código CIUU
- Solo se cargan los establecimientos que tienen un código CIIU válido y bien
conformado.
- Se realiza validación cruzada entre establecimientos y visitas realizadas dejando solo
aquellas visitas que pueden relacionarse a establecimientos que tenga identificación y
un CIUU para establecimientos formales.

Otras fuentes de datos de visitas fueron examinadas (Secretaria de Hacienda, Idiger y UAECOB
Bomberos) sin embargo fueron descartadas por la calidad de los datos, que no permitían
identificar claramente los establecimientos, de tal manera que se puede identificar mediante
confrontación de información los atributos de los mismos. La principal de razón de rechazo
tiene que ver con documentos de identificación mal formados (NIT con letras) o documentos
de identidad que no corresponden a los formatos establecidos para ellos.

Se creó un modelo de datos con las entidades requeridas que se expresa mediante el siguiente
diagrama Ilustración 1. Modelo Entidad Relación IVC. También se anexa el script sql en donde
se puede crear el esquema descrito en el modelo, denominado ScripbaseDatosVersion1.sql. Es
de anotar que dicho script corresponde al estado actual de los datos que hasta el momento se
han podido acceder y puede cambiar si se lograr obtener nuevas bases de datos que permitan
complementar el modelo.

4. ARQUITECTURA DE BIGDATA

Cuando se habla de BigData podemos indicar que existen 2 clasificaciones, sobre los mismos:

- La primera de ellas relacionada con el tamaño, la variedad y la velocidad de generación

de los grandes volúmenes de datos, que históricamente se han conocido como las 3 V
del Bigdata
- La segunda tiene que ver con la infraestructura necesaria para poder procesar estos
volúmenes de datos, que permitan escalar de manera flexible y rápida cuando la
cantidad o el tipo de análisis sobre los datos así la requieran.

En la propuesta de análisis de IVC se centró en la segunda clasificación, debido a los siguientes

antecedentes:

1. La cantidad de datos disponibles y accesibles para el presente análisis fue limitado y

restringido. Sin embargo, en el ambiente productivo real la cantidad de datos de las
diferentes entidades aportantes de información tiende a crecer rápidamente tanto en
tamaño como en variedad.
2. Se debe asegurar que la propuesta puede ser ejecutada, en pequeñas, medianas o
grandes infraestructuras de cómputo, siempre evitando problemas de licenciamiento
de software y procesos complejos de configuración especializada.
3. Que cualquier entidad que desee utilizar los mecanismos aquí propuestos pueda
usarlos en arquitecturas propias o en arquitecturas basadas en arquitecturas de nubes,
sin que esto cambie radicalmente el diseño propuesta de la solución.

4.1. Elementos de la arquitectura de contenedores

Cuando se habla contenedores, necesariamente se debe hablar de arquitecturas virtualizadas

y por tanto es necesario realizar la diferencia entre contenedores y máquinas virtuales.
Figure 1. Comparación VM y Contenedores. Fuente https://sreeninet.wordpress.com/2014/12/28/docker-overview/

Las máquinas virtuales permiten que el hardware físico sea presentado a sus diferentes
instancias como un “hardware virtualizado”, que es manejado por un hipervisor (dentro de los
cuales hoy en día tenemos ESX, XEN, HyperV, KVM, etc).

Ahora bien los Contenedores virtualizan el software, permitiendo compartir el sistema

operativo de base, ya sea este sobre hardware físico o virtualizado

Figure 2. Arquitectura modular de un contenedor Docker. Fuente

https://sreeninet.wordpress.com/2014/12/28/docker-overview/

De esta manera podemos ver que el servicio (demonio) de Docker corre en el host y que los
clientes (Contenedores) se comunican mediante una interface Rest. Los repositorios de
imágenes de docker son almacenados en un índice y pueden ser compartidas de manera
privada o pública.

4.2. Análisis de rendimiento de una solución basada en

Contenedores
Usar contenedores permite que cada aplicación o conjunto de aplicaciones corriendo en un
contenedor esté aislado de los demás de una manera mucho más liviana que la creación de
máquinas virtuales, permitiendo portabilidad entre diferentes ambientes, como VM alojadas,
sistemas bare-metal, sistema de cloud públicas o privadas, permitiendo que los equipos de
desarrollo permitan que el despliegue de las aplicaciones liberadas, tengan los elementos de
configuración asegurados.

Por definición al ser más livianos dentro de infraestructura consume menos recursos y por
tanto puede aprovechar mejor la infraestructura (física o virtual) donde está alojada. El estudio
realizado por Ferreira Alexandre, Fleter Wes 1 y otros sobre un análisis de rendimiento entre
máquinas virtuales y Linux containers muestra una verdadera ventaja de los Contenedores
sobre las máquina virtuales.

4.3. Propuestas existentes para arquitecturas basadas en

Contenedores

Con los aspectos anteriormente podemos ver la implementación de la este tipo de soluciones
de dos maneras diferentes:

1. Implementación basado en BareMetal

2. Implementación basado en sistema de Cloud computing.

Implementación basado en BareMetal :

Cuando las solucione son altamente demandantes en recursos y se requiere garantizar que el
desempeño sea predecible durante el tiempo, las soluciones basadas en Cloud Computing
presentan serios problemas, pues dependen de la demanda del tipo de demanda que hagan
los usuarios en un determinado periodo de tiempo.

Bajo estos requerimientos usar una arquitectura Bare-Metal resulta ser una excelente opción
dado que Docker “Virtualiza” los ambientes de ejecución permitiendo explotar los recursos de
hardware directamente al mismo tiempo que entrega aislamiento para cada aplicación o
conjunto de aplicaciones.

Para el caso específico de soluciones de BigData intensivas en memoria, o que basen su

procesamiento en hadoop esta podría ser una solución benéfica en términos de desempeño.

1
An Updated Performance Comparison of Virtual Machines and Linux Containers. Disponible en
https://domino.research.ibm.com/library/cyberdig.nsf/papers/0929052195DD819C85257D2300681E7B
/$File/rc25482.pdf
 Sistema Operativo
Virtualizado

Machine Apache Apache

Learning Spark Hadoop Aplicaciones

Apps Virtualizadas

Esta distribución de componentes si bien permite lograr un mejor nivel de desempeño,

compromete la velocidad de alistamiento de la infraestructura, haciendo que los procesos de
aprovisionamiento dinámico sean difíciles de lograr, por tal motivo es necesaria una capa de
gestión de nivel superior de los servidores Bare-Metal de tal manera que permitan realizar el
alistamiento para containers de una manera mucho más flexible.

Dentro de esta visión, se debe usar una capa de orquestación y aprovisionamiento, basado en
soluciones estándar que permitan liberar el proceso de la administración tal como lo hace las
soluciones de cloud.

5. Arquitectura propuesta

Las soluciones de BigData además del desafío del Volumen, Variedad, Velocidad y Veracidad
que presenta basado en su tamaño, resulta ser una tendencia comercial meramente siempre
que no esté asociada a los servicios que saquen provecho de la información allí soportada. En
este ambiente de Cloud Computing uno de los elementos que más preocupan a Gobiernos es
el tema de la privacidad de la información, evitar que información sensible o privada pueda ser
manipulada o conocida por terceros que podrían ganar ventaja o revelar elementos
estratégicos.

Estos dos elementos hacen que el planteamiento de una arquitectura de hardware para
soportar procesos de BigData sea un tema tanto tecnológico, como estratégico y legal. De las
restricciones anteriormente propuestas se proyecta las nubes privadas y no públicas como
aquellas que pueden ofrecer todos los servicios de aprovisionamiento de la infraestructura de
manera dinámica y a la vez mantener los niveles de privacidad dentro de los estándares
requeridos a nivel gubernamental.

La implementación de nubes privadas pueden involucrar elementos puramente

gubernamentales o elementos mixtos donde parte de la infraestructura de un proveedor
privado esté localizado y gobernado bajo estándares de gobiernos que aseguren que la
información solo permanecerá dentro de su custodia.

Por las consideraciones anteriores y premisas se propone una arquitectura de hardware para
soluciones BigData basada en Contenedores basada en nube privada, con posibilidad de
consumir servicios de nubes públicas. La arquitectura propuesta cumple con los preceptos de
flexibilidad, confidencialidad de los datos y es capaz de adaptarse cuando el procesamiento
intensivo así lo requiera

Esta nube debe poseer una capa de orquestación mixta que permitan manejar tanto recursos
puramente virtualizados basados en máquinas virtuales como en recursos basados en Bare-
metal. Cualquiera que el soporte físico (VM o Bare-Metal) deberá tener el soporte de
Contenedores (principalmente docker) y permitir que para servicio requerido se pueda
proveer o construir una imagen para ser deplegada a demanda cuando así se requiera.

Los servicios se especializan dependiendo el tipo de infraestructura que requieran

(especializada para performance o virtualizada para flexibilidad), de esta manera los servicios
de analítica de datos y de cómputo intensivo deberán ser provisto en contenedores corriendo
en una solución de Bare-Metal y los demás pueden ser provistos en contenedores soportados
por ambientes virtualizados.
Figure 3. Arquitectura propuesta

Ilustración 8. Arquitectura Inicial basada en nube privada

5.1. Alternativas analizadas y realizadas

Para la experimentación se tenía una cantidad fija de grillas como se ha mencionado en el ,

para lo cual se estableció una arquitectura adicional basada en distribución de contenedores
por nivel de agrupación de colmena como se muestra en la siguiente figura:
 Ilustración 9. Arquitectura implementada en Amazon Cloud AWS

Para la realización de este experimento se utilizó la API de Amazon denominada boto3, que
permite configurar, actualizar, operar y monitorear un cluster previamente creado con amazon
ECR. La identificación de los miembros del cluster se hace mediante el siguiente script:

def getClusterMembers(clustername) :
   ##############################
   # Clear the global list
   ###############################
   running_instancesip=[]
   client_ecs = boto3.client('ecs')
   client_ec2= boto3.client('ec2')
   ec2 = boto3.resource('ec2')
   #clustername='IVCMachineLearning'
   hostname = socket.gethostname()
   ##############################################
   # Storage the members of cluster and theirs ips
   ##############################################
   cluster_members =[]
   #######################################
   #print(client.list_clusters())
   response =  client_ecs.list_container_instances(cluster=clustername)
   if response['containerInstanceArns']:
       container_instance_resp = client_ecs.describe_container_instances(
               cluster=clustername,
               containerInstances=response["containerInstanceArns"]
           )
       for ec2_instance in container_instance_resp["containerInstances"]:
           cluster_members.append(ec2_instance['ec2InstanceId'])

   ##############################
   # get instance IPs
   ##############################3
   instances = ec2.instances.filter(
       Filters=[{'Name': 'instance-state-name', 'Values': ['running']}])
   for instance in instances:
       if instance.id in cluster_members:
           if instance.public_ip_address != getInternalIp():
               running_instancesip.append(instance.public_ip_address)
               print(instance.id, instance.instance_type, instance.public_ip_address)
   return running_instancesip

Una vez identificados las configuraciones internas y obtenidas las IP de cada miembros del
cluster se procede a preparar cada miembro del cluster para ejecutar las operaciones de
geoprocesamiento, incluyendo las imágenes de Docker.

def prepareServer(bucket,cluster,operation,node):
   print ("Preparing servers")
   copy_command="/home/ec2-user/.local/bin/aws s3 cp --recursive s3://" +bucket +"
/opt/sharing/"
   copy_credentials=""
   if operation=="download":
       commands=[]
       print ("Running only download process")
       commands=["sudo chown -R ec2-user:ec2-user /opt/"]
       commands.append(copy_command)
   
   elif operation =="upload":
       commands=["/home/ec2-user/.local/bin/aws s3 sync
/opt/sharing/geodatos/results/ s3://"+bucket+"/geodatos/results/"]
   
   elif operation=="initNode":
       commands=["sudo rm -Rf /opt/sharing/geodatos","sudo chown -R ec2-user:ec2-user
/opt/","sudo yum install -y python35-pip","/usr/bin/pip-3.5 install --upgrade --user
awscli",copy_command]
       remote_command(node,command)
       return
   elif operation=="initCluster":
       #commands=["sudo mkdir -p /opt/sharing/geodatos","sudo chown -R ec2-user:ec2-
user /opt/sharing","sudo yum install -y python35-pip","/usr/bin/pip-3.5 install --
upgrade --user awscli"]
       #commands.append("docker run --name geopandas3 -v
/opt/sharing/geodatos:/opt/sharing/geodatos -t -d eshernan/geopandas:latest
/bin/bash")
       commands=["docker ps "]
       for server in getClusterMembers(cluster):
           for command in commands:
               remote_command(server,command)
              # remote_copy(server,'/home/ec2-user/.aws/credentials','/home/ec2-
user/.aws/credentials')
           #remote_command(server,copy_command)
       print("finish processing")
   print ("Executing remote commands")

def executeDockerCommand(cluster,file):
   print ("execute Remote Docke in cluster" + cluster)
   commands=["docker exec geopandas3 sh -c \'/usr/local/bin/python3.5
/opt/sharing/geodatos/"+file+"\' &"]
   for server in getClusterMembers(cluster):
       for command in commands:
           print ("Running " + command +"in server: " + server)    
           remote_command(server,command)

def updateDocker(cluster):
   print ("updating Docker image ")
   commands=["docker stop geopandas3","docker rm geopandas3","docker run --name
geopandas3 -v /opt/sharing/geodatos:/opt/sharing/geodatos -t -d
eshernan/geopandas:latest  /bin/bash"]
   for server in getClusterMembers(cluster):
       for command in commands:
           print ("Running " + command +"in server: " + server)    
           remote_command(server,command)

Una vez el ambiente ha sido configurado, se realiza la ejecución de experimentación acorde a

los algoritmos seleccionados y los datos requeridos.

def remote_command(server,command):
   port='22'
   filekey='/home/ec2-user/source-code/spark-cluster-key.pem'
   private_key = paramiko.RSAKey.from_private_key_file(filekey)
   client = paramiko.SSHClient()
   client.set_missing_host_key_policy(paramiko.AutoAddPolicy())
   print ("connecting")
   client.connect( hostname = server, username ="ec2-user", pkey = private_key )
   print ("connected and running "+ command)
   stdin , stdout, stderr = client.exec_command(command)
   print (stdout.read())
   client.close()

def remote_copy(server,localpath,remotepath):
   from paramiko import SSHClient
   from scp import SCPClient
   port='22'
   filekey='/home/ec2-user/source-code/spark-cluster-key.pem'
   private_key = paramiko.RSAKey.from_private_key_file(filekey)
   client = paramiko.SSHClient()
   client.set_missing_host_key_policy(paramiko.AutoAddPolicy())
   client.connect(hostname = server, username ="ec2-user", pkey = private_key )
   with SCPClient(client.get_transport()) as scp:
       print ("Putting data"+ remotepath + "on server" + server)
       scp.put(localpath, remotepath)
   client.close()

La herramienta construida, permiten además poder seleccionar las operaciones que se realizan
contra la API, de manera programática como se indica a continuación:

import sys
def main():
   command=""
   clustername=""
   if len(sys.argv)<1:
       print("you need specified a command ex:syncS3, print, execute ...")
       return
   else:
       command=sys.argv[1]
       clustername = sys.argv[2]
   # my code here
   if command == 'print':
       getClusterMembers(clustername)
   elif command  == 'execute':
       for server in running_instancesip:
           print("connecting to "+ server)
           remote_command(server)
   elif command == 'initNode':
       newServer = sys.argv[3]
       print ("Running prepare servers"+newServer)
       prepareServer("ivc-experimento",clustername,"initNode",newServer)
   elif command == 'initCluster':
       print ("Running initcluster")
       prepareServer("ivc-experimento",clustername,"initCluster","none")
   elif command  =="syncS3":
       print ("Running syn serversc")
       prepareServer("ivc-experimento",clustername,"download","none")
   elif command == 'executeFile':
       print ("Running execute file  ")
       executeDockerCommand(clustername, sys.argv[3])
   elif command  =='uploadResults':
       print ("Uploading data to S3")
       prepareServer("ivc-experimento",clustername,"upload","none")
   elif command =="updateDocker":
       updateDocker()
   else:
       print ("Please use one of the following commands: print, execute")

if __name__ == "__main__":
   main()