Análisis de sentimiento en Twitter: Plataforma de gestión de modelos

UNIVERSIDAD AUTONOMA DE MADRID
ESCUELA POLITECNICA SUPERIOR
Experto en Big Data y Data Science: ciencia e ingeniería de datos
TRABAJO FIN DE TÍTULO
ANALISIS DE SENTMIENTO EN TWITTER:
APROVISIONAMIENTO.
Autor : Jose Luis Mínguez González
Tutor: Álvaro Barbero
Julio 2016

i
ANALISIS DE SENTMIENTO EN TWITTER:
APROVISIONAMIENTO
AUTOR: Jose Luis Mínguez González
TUTOR: Álvaro Barbero
Escuela Politécnica Superior
Universidad Autónoma de Madrid
Julio de 2016

i
Resumen
Este Trabajo Fin de Título está compuesto por 2 TFT que si bien abordan aspectos
diferentes del problema, están totalmente integrados. Dichos trabajos son los siguientes:
Análisis de sentimiento en Twitter. Aprovisionamiento.
Análisis de sentimiento en Twitter. Clasificación. Realizado por David Serrano Gil
El primero de ellos aborda todos los aspectos involucrados en la creación, documentación
y puesta en producción de modelos de aprendizaje automático, excepto el propio
entrenamiento cuyo contenido es el tema tratado en el segundo de los TFT mencionados.
En relación al aprovisionamiento de los tweets, se ha intentado ampliar el alcance del TFT.
No solo se ha conseguido la descarga y persistencia de los mismos sino que se ha creado
toda una plataforma para la gestión integral del ciclo de vida de un modelo, todo ello de
forma automática y desatendida. Esta plataforma está integrada por los siguientes módulos:
Descarga, persistencia y recuperación de los tweets:
- Recopilación de tweets por medio del API suministrada por Twitter, persistencia de los
mismos en elasticsearch y recuperación para su procesado.
Ilustración 1. Esquema general del trabajo

ii
Gestión y administración de los Modelos (Documentación e inventariado):
- Con estas funciones se puede administrar y gestionar todo lo relacionado con la
documentación, inventariado y persistencia de los modelos así como sus resultados.
Gestión y administración de los pasos a producción de los Modelos:
- Una vez creado, entrenado, documentado e inventariado el nuevo modelo se pasaría a
producción donde comenzaría a clasificar. Con estas funciones este paso a producción
es automático. Incluso se pueden definir unos umbrales mínimos de calidad para que
solo pasen a producción los mejores. En cualquier momento se pueden dar de baja los
modelos para que dejen de clasificar.
Visualización:
- En cualquier momento se puede ver los datos más relevantes de un modelo de forma
automatizada a través del interface gráfico “kibana”. También se tiene datos
relacionados con los tweets, resultados, etc. de forma casi instantánea.

i
Agradecimientos
A Estrella Pulido, por embarcarse en este proyecto y organizar esta magnífica
titulación.
A todo el profesorado, por compartir conmigo todos sus conocimientos y hacerme ver
el mundo desde otra perspectiva.
A Álvaro Barbero, por darme la oportunidad de realizar este TFT y adentrarme en el
impresionante mundo del Deep Learning y Text Mining.
A mi compañero David Serrano Gil, por permitirme realizar junto a él este TFT.

i
INDICE DE CONTENIDOS
1 Introducción .............................................................................................................. 1
1.1 Motivación .................................................................................................................... 1
1.2 Objetivos....................................................................................................................... 1
1.3 Organización de la memoria........................................................................................... 1
2 Estado del arte .......................................................................................................... 3
2.1 Que aporta esta plataforma. .......................................................................................... 3
2.2 Componentes elegidos................................................................................................... 3
2.2.1 Limitaciones Iniciales ...................................................................................................................... 3
2.2.2 Elementos Seleccionados................................................................................................................ 3
2.2.2.1 Python ( tweepy ).................................................................................................................... 3
2.2.2.2 Elasticsearch:........................................................................................................................... 4
2.2.2.3 Kibana...................................................................................................................................... 4
3 Diseño ....................................................................................................................... 5
3.1 Ciclo de Vida de un Modelo: Descripción General............................................................ 5
3.2 Módulo1: Recopilación, Persistencia y Recuperación de los tweets. ................................ 6
3.3 Módulo 2: Gestión y documentación de modelos............................................................ 6
3.4 Módulo 3: Paso a producción de los modelos.................................................................. 7
3.5 Módulo 4: Visualización. ................................................................................................ 7
4 Desarrollo.................................................................................................................. 9
4.1 Infraestructura HW y SW................................................................................................ 9
4.2 Diseño de la BD Elasticsearch. ...................................................................................... 10
4.2.1 Configuración del cluster. ............................................................................................................. 10
4.2.2 Diseño de la BD ............................................................................................................................. 11
4.3 Diseño del Aplicativo.................................................................................................... 13
4.3.1 Descripción general....................................................................................................................... 13
4.3.2 Módulo 1. Descarga de tweets ..................................................................................................... 14
4.3.3 Módulo 2 - Gestión de Modelos .................................................................................................. 17
4.3.4 Módulo 3 - Paso a Producción. ..................................................................................................... 18
4.3.5 Módulo 4: Visualización................................................................................................................ 19
5 Integración, pruebas y resultados ............................................................................ 21
5.1 Entorno de trabajo....................................................................................................... 21
5.2 Integración entre módulos ........................................................................................... 23
5.3 Pruebas ....................................................................................................................... 24
6 Conclusiones y trabajo futuro................................................................................... 25
6.1 Conclusiones................................................................................................................ 25
6.2 Trabajo futuro.............................................................................................................. 25
Referencias ................................................................................................................ 27
Anexo 1. Manual de referencia. .................................................................................. 29
6.3 ES_TOOLS. ................................................................................................................... 29

ii
6.3.1 BD elasticsearch............................................................................................................................ 29
6.3.1.1 Connect ................................................................................................................................. 29
6.3.1.2 es_check................................................................................................................................ 29
6.3.1.3 active_shards ........................................................................................................................ 30
6.3.2 Índices........................................................................................................................................... 30
6.3.2.1 create_index.......................................................................................................................... 30
6.3.2.2 create_index_tweet .............................................................................................................. 30
6.3.2.3 create_index_result .............................................................................................................. 30
6.3.2.4 create_index_*[happy|sad].................................................................................................. 30
6.3.2.5 drop_index ............................................................................................................................ 30
6.3.2.6 rebuild_index_tweet............................................................................................................. 30
6.3.3 Descarga de tweets....................................................................................................................... 31
6.3.3.1 get_tweet_happy.py | get_tweet_sad.py ............................................................................ 31
6.3.4 Persistencia de Tweets.................................................................................................................. 31
6.3.4.1 insert_jtweet / insert_tweet................................................................................................. 31
6.3.4.2 insert_from_file .................................................................................................................... 31
6.3.4.3 insert_From_file_sad / insert_From_file_happy .................................................................. 32
6.3.4.4 copy_tweet ........................................................................................................................... 32
6.3.5 Recuperación de Tweets............................................................................................................... 32
6.3.5.1 Filtrado de tweets ................................................................................................................. 32
6.3.5.2 Manipulación de listas de caracteres.................................................................................... 32
6.3.5.3 filter_tweet ........................................................................................................................... 33
6.3.5.4 count_tweets ........................................................................................................................ 33
6.3.5.5 select_tweets ........................................................................................................................ 33
6.3.5.6 select_htweets_by_id / select otweets_by_id...................................................................... 34
6.4 ES_MODEL................................................................................................................... 34
6.4.1 Repositorio.................................................................................................................................... 35
6.4.1.1 create_index_model ............................................................................................................. 35
6.4.1.2 drop_index_model................................................................................................................ 35
6.4.2 Manipulación de parámetros........................................................................................................ 35
6.4.2.1 default_param....................................................................................................................... 35
6.4.2.2 set_param / set_jparam / set_fparam.................................................................................. 35
6.4.2.3 show_param.......................................................................................................................... 36
6.4.2.4 del_param ............................................................................................................................. 36
6.4.2.5 save_filtro / get_filtro ........................................................................................................... 36
6.4.3 Gestión de modelos ...................................................................................................................... 36
6.4.3.1 Save_model........................................................................................................................... 36
6.4.3.2 Save_automatic_model ........................................................................................................ 36
6.4.3.3 Del_model............................................................................................................................. 37
6.4.3.4 Update_model ...................................................................................................................... 37
6.4.3.5 Bck_model............................................................................................................................. 37
6.4.3.6 Get_model............................................................................................................................. 37
6.4.4 Recarga automática de modelos................................................................................................... 37
6.4.4.1 set_active_model_mark / get_active_model_mark ............................................................. 37
6.4.5 Paso a producción......................................................................................................................... 38
6.4.5.1 add_active_model................................................................................................................. 38
6.4.5.2 get_active_models................................................................................................................ 38
6.4.5.3 del_active_model.................................................................................................................. 38
6.4.5.4 keras_model.......................................................................................................................... 38
6.4.5.5 rebuild_models ..................................................................................................................... 38
6.4.6 Clasificación .................................................................................................................................. 38
6.4.6.1 codificaTexto......................................................................................................................... 38
6.4.6.2 predict_models ..................................................................................................................... 39
6.4.6.3 insert_model_result.............................................................................................................. 39
6.4.6.4 get_model_Result ................................................................................................................. 39

iii
INDICE DE FIGURAS
Ilustración 1. Esquema general del trabajo.........................................................................................................i
Ilustración 2 - Ciclo de vida de un modelo ......................................................................................................... 5
Ilustración 3 - Módulo 1. Recopilación, Persistencia y Recuperación de tweets................................................ 6
Ilustración 4 - Módulo 2. Gestión repositorio de modelos................................................................................. 7
Ilustración 5 – Módulo 3. Puesta en producción de modelos ............................................................................ 7
Ilustración 6 - Módulo 4. Visualización.............................................................................................................. 7
Ilustración 7 - Infraestructura Hw y Sw. Cluster Elasticsearch........................................................................... 9
Ilustración 8 - Aplicaciones instaladas............................................................................................................. 10
Ilustración 9 - Configuración cluster Elasticsearch. ......................................................................................... 10
Ilustración 10 - Configuración Índices. Settings............................................................................................... 11
Ilustración 11 - Configuración Índices. Mappings............................................................................................ 12
Ilustración 12 - Ejemplo Índice Model. ............................................................................................................ 12
Ilustración 13 - Ejemplos Índice Resultado ...................................................................................................... 13
Ilustración 14 - Cabecera programas Python. ................................................................................................. 14
Ilustración 15 - Descripción captura tweets. ................................................................................................... 15
Ilustración 16 - Valores por defecto del l filtro................................................................................................ 16
Ilustración 17 - Módulo 1. Relación detallada de las funciones. ..................................................................... 17
Ilustración 18 - Módulo 2. Relación detallada de las funciones ...................................................................... 17
Ilustración 19 - Módulo 3. Relación detallada de las funciones ...................................................................... 18
Ilustración 20 - Campos actualizados desde el Módulo 3................................................................................ 18
Ilustración 21 - Dashboard con pas principales métricas. ............................................................................... 19
Ilustración 22 - Dashboard con las principales métricas. ................................................................................ 20
Ilustración 23 - Diferentes aplicaciones ( plugins ) utilizados . ........................................................................ 21
Ilustración 24 - Entorno de trabajo.................................................................................................................. 22
Ilustración 25 - Conexión enre los difernetes módulos ................................................................................... 23
Ilustración 26- Módulo 1. Relación detallada de las funciones. ...................................................................... 29
Ilustración 27 - Módulo 2. Relación detallada de las funciones...................................................................... 34
Ilustración 28 - Módulo 3. Relación detallada de las funciones. ..................................................................... 35

Análisis de sentimiento en Twitter. Aprovisionamiento. 1
1 Introducción
1.1 Motivación
La principal motivación a la hora de realizar este TFT es la de realizar un conjunto de
herramientas que liberen al científico de datos de todas aquellas tareas tediosas y poco
gratificantes relacionadas con el entrenamiento de datos. Me refiero a tareas relacionadas
con la descarga de datos, la documentación e inventariado de los modelos y su posterior
puesta en producción así como la recopilación de los resultados y su visualización. Todo
esto de forma desatendida y automática.
1.2 Objetivos
El principal objetivo del presente TFT es hacer que el científico de dato solo se tenga que
preocupar de entrenar y conseguir el mejor modelo dejando que la plataforma diseñada en
este TFT haga el resto del trabajo por él.
El segundo objetivo es hacer que las herramientas utilizadas sean lo más sencillas
posibles a la hora de ser utilizadas y que su nivel de abstracción sea máximo. Por
supuesto, dando a su vez la posibilidad de poder realizar estas operaciones de forma
manual o desatendida.
El tercer objetivo es crear las condiciones idóneas para que el entrenamiento sea lo más
eficaz posible contando con los recursos disponibles.
Por último, he intentado poner en práctica todos los conocimientos adquiridos durante el
curso en un solo trabajo:
Análisis de datos y su interpretación:
Modelos Deep Learning. ( TFT realizado por David Serrano )
Análisis de datos en movimiento y reposo – BBDD noSQL:
Elasticsearch
Infraestrucura para big data:
gestión, configuración y administración de un cluster Elasticsearch
Visualización:
Dashboard con Kibana
Aplicaciones Big data:
Text Mining. Análisis de sentimiento en Twitter.
1.3 Organización de la memoria
La memoria consta de los siguientes capítulos:
- 2.- Estado del arte. En donde se comparan algunos productos similares con el presente
trabajo y se describe los elemento usados para la realización del mismo

- 3.- Diseño. Breve descripción de los diferentes módulos que conforman la plataforma.
- 4.- desarrollo. Detalle de cada uno de los módulos.
- 5.- integración, pruebas y resultados. Se comenta no solo la integración de los
diferentes módulos, sino la integración de los elementos con los que se ha construido
la plataforma con diversas herramientas, así como la integración del equipo humano a
la hora de abordar conjuntamente este trabajo.
- Apéndice 1. Se detallan todas y cada una de las funciones integradas en la plataforma

2 Estado del arte
2.1 Que aporta esta plataforma.
Existen muchas herramientas que abordan el análisis de sentimientos en twitter. Estas
herramientas te permiten seleccionar tweets y procesarlos. Apoyados en unos modelos ya
entrenados, son capaces de predicen el sentimiento del tweet.
Algunas de estas herramientas son:
- AcimyAPI
- Twitter Sentiment
- Twitrrart
- twtbase
Lo que aporta esta plataforma como novedad es la de permitir genera modelos nuevos y
poder ponerlos en producción de forma automática permitiendo que múltiples modelos
clasifiquen tweets en paralelo, todo ello en tiempo real.
2.2 Componentes elegidos
Uno de los requisitos principales a la hora de seleccionar los componentes ha sido elegir
aquellos que estén más de moda y que sean ampliamente utilizados. De esta forma evito la
obsolescencia prematura de la aplicación, a la vez que me aseguro un buen soporte técnico
debido a la inmensa comunidad de programadores que hay tras ellos.
2.2.1 Limitaciones Iniciales
Actualmente disponemos de un cluster Hadoop (distribución FusionInsight de Huawei con
7 nodos) la idea es utilizar dicha plataforma para desarrollar este proyecto. Esta
distribución tiene casi todos los elementos de una distribución Hadoop excepto Spark
Streaming que es una extensión. Esto significa orden de compra, justificación de la misma
y meses de demora. Por este motivo esta opción ha quedado descartada a pesar de ser una
de las que se contempló en un principio. Después pude ver cómo no fue tan mala idea ya
las librerías necesarias para entrenar los modelos no estaban en las Mlib de Spark
añadiendo la complejidad de tener que integrar dichas librerías a Spark con componentes
tipo Apache Thrift.
2.2.2 Elementos Seleccionados.
2.2.2.1 Python ( tweepy )
Su popularidad no ha parado de crecer, no solo en el ámbito del Machine Learning sino en
cualquier ámbito ya que se trata de un lenguaje de programación de ámbito general, ideal
para resolver cualquier situación. Sin ir más lejos, las librerías utilizadas para la descarga
de tweets ( tweepy ) están hechas en Python.

2.2.2.2 Elasticsearch:
Sin duda es una de las bbdd de más actualidad, sobre todo en el ámbito del procesamiento
en tiempo real y especialmente cuando se trata de logs. No en vano existe una Distribución
especializada en el procesamiento en tiempo real de logs, ELK ( Elasticsearch – Logstash –
Kibana ) . Al tratarse de una BD ( tipo MongoDB ) + Buscador ( basado en Lucent ) que
trabaja directamente con documentos tipo JSON y que además esta información ya se
guarda comprimida e indexada, es la candidata ideal a formar parte de la plataforma ya que
los documentos con los que vamos a tratar son tweets que ya están en formato JSON.
Además la capacidad de indexación es perfecta ya que se van a descargar y almacenar
millones de tweets que después se tendrán que buscar.
A todo esto hay que añadir la facilidad para poder instalarla en cluster, lo que va a permitir
aprovecha al máximo todos los nodos de nuestro cluster hadoop, mejorando el acceso a los
datos.
2.2.2.3 Kibana
Con la visualización no tuve ningún problema ya que KIBANA está totalmente integrado
con elasticsearch y era un producto que estabas deseando probar. Aunque no es un Qlik o
PowertPivot, sus capacidades son más que suficientes para lo que pretendo hacer con ellas.
También hay que decir que a pesar de sus limitaciones, estas son cada vez menores gracias
a la comunidad de programadores que tiene detrás y que no paran de generar nuevos
plugins de visualización. [17]
En resumen, los componentes elegidos para el desarrollo de esta plataforma son los
siguientes:
- Python: Como lenguaje de programación
- Tweepy: Librería para la adquisición de tweets
- Elasticsearch : Almacenamiento y buscador.
- Kibana: Visualización y elaboración de los diferentes dashboard.

3 Diseño
3.1 Ciclo de Vida de un Modelo: Descripción General
El presente trabajo se ha desarrollado siguiendo el orden cronológico a la hora de generar
un modelo, es decir, se ha seguido su ciclo de vida desde que nace hasta que se pone en
producción.
En el siguiente gráfico se pueden apreciar las diferentes fases por las que pasa un modelo.
El ciclo se inicia con la descarga de nuevos tweets que se almacenan directamente en
elasticsearch (insert_tweet) ya que en este momento aún no disponemos de ningún modelo
en producción. Una vez recopilados los suficientes tweets como para poder iniciar el
entrenamiento (copy_tweet), se recuperan de la bd (select_tweet) y se entrena el modelo
con ellos. Una vez obtenido el modelo, se documenta e inventaría dentro de la bd
(save_model) . Esta información es utilizada por la plataforma para añadir dicho modelo a
producción (add_active_model) previa reconstrucción del mismo (rebuild_models) .
Una vez que el modelo esta reconstruido en producción, ya es apto para comenzar de
forma automatizada y en tiempo real a clasificar los nuevos tweets (predict_models) y
guardar los resultados de dicha clasificación en bd (insert_model_result). A medida que
los resultados están siendo recogidos se pueden ir viendo en el interface web gráfico.
(kibana)
Ilustración 2 - Ciclo de vida de un modelo

El que sea un ciclo continuo significa que a medida que los modelos finalizan su
entrenamiento, se documentan y pasan a producción de forma automática, sin intervención
del científico de datos que entrena dichos modelos.
3.2 Módulo1: Recopilación, Persistencia y Recuperación de los
tweets.
Este módulo se encarga de todas aquellas operaciones relacionadas con la recogida de los
tweets, su almacenaje en BD y posterior recuperación para ser utilizado en el
entrenamiento de los modelos.
Con este módulo se pueden realizar las siguientes operaciones:
[1] Debido a la relación tan estrecha que hay entre esta funcionalidad y el tipo de modelo entrenado, este tipo de
funciones han sido realizadas por David Serrano Gil.
3.3 Módulo 2: Gestión y documentación de modelos.
Este módulo engloba todas aquellas funciones relacionadas con la gestión, administración,
inventariado y documentación no solo de los datos necesarios para la reconstrucción del
modelo, sino todos aquellos que por su relevancia merece la pena ser conservados.
- Conexión, chequeo y obtención de datos relacionados con la BD.
- Administración de los diferentes repositorios de datos ( índices )
o Creación / borrado / modificación de índices
- Recopilación de los tweets.
o Directamente a través del API proporcionada por Twitter
o A través de fichero.
- Persistencia de los tweets.
o Inserción dentro de la BD en diferentes formatos.
o Copiado de tweets entre índices o de un índice a fichero.
- Recuperación de los Tweets.
o Selección de tweets ( con o sin retweets, con o sin
duplcados)
o Filtrado de tweets. (eliminar elementos no necesarios, url,
hastags etc.)
o Vectorización de los tweets.[1]
Ilustración 3 - Módulo 1. Recopilación, Persistencia y Recuperación de tweets

3.4 Módulo 3: Paso a producción de los modelos.
Este módulo permite poner en producción de forma automática aquellos modelos
entrenados y que superen el umbral de calidad configurado. Inicialmente se puede
configurar para que todos los modelos creados pasen directamente y una vez obtenidos
modelos mejores, dar de baja los anteriores y dejar pasar solo los mejores.
[2] Este tipo de funciones han sido realizadas por David Serrano Gil.
3.5 Módulo 4: Visualización.
- Gestión del repositorio de modelos.
- Manipulación de parámetros.
o Establecer nuevos datos
o Actualizar / eliminar datos ya existentes
o Mostrar los datos configurados hasta el
momento
- Persistencia de los modelos:
o Salvar un nuevo modelo
o Actualizar / eliminar modelos
o Realizar copias de seguridad de
modelos.
- Recuperar de modelos.
- Reconstrucción de modelos.
o Modelos LSTM con keras [2]
- Gestionar el paso a producción de los Modelos.
o Altas / bajas / consulta
- Categorización de los tweets.
- Control de la recarga automática de los modelos.
- Persistencia de los resultados
- Actualización del inventario de modelos
o Indicando si el modelo está activo o no
Ilustración 4 - Módulo 2. Gestión repositorio de modelos
Ilustración 5 – Módulo 3. Puesta en producción de modelos
Este módulo va a permitir ver datos en tiempo real de
lo que está pasando en la plataforma. Desde la
creación de nuevos modelos junto a sus datos
estadísticos más relevantes como lo bien o mal que
están clasificando en esos momentos.
Ilustración 6 - Módulo 4. Visualización.

4 Desarrollo
4.1 Infraestructura HW y SW
Ilustración 7 - Infraestructura Hw y Sw. Cluster Elasticsearch
Actualmente disponemos de un cluster de 7 nodos con la distribución de Hadoop
FusionInsigh de Huawei cuyas características principales son las resaltadas en el dibujo.
El Cluster consta de 3 nodos de gestión ( BDI1, BDI2 y BDI3) y 4 de datos (BDI4, BDI5,
BDI6 y BDI7). Solo los nodos de Gestión son accesibles desde el exterior.
Sobre este cluster se ha instalado y configurado un cluster Elasticsearh utilizando de
momento solo 5 de los 7 Nodos (BDI1 como Master y DBI4 a BDI7 como datos).
Una vez finalizada la arquitectura HW, se comenzó con la instalación y configuración del
Software. Siendo estos los principales componentes instalados:
- Java 8. Instalado en todos nodos del cluster elasticsearch ya que es usado por el sw de
elasticsearch.
- Elasticsearch. Versión 2.3.3. ( instalado en los 5 nodos del cluster elasticsearch
- Pluggins para Elasticsearch:
o mobz/elasticsearch-head
o jettro/elasticsearch-gui
o elasticsearch-sql-2.3.3.0

o royrusso/elasticsearch-HQ
- Kibana Versión 4.5.2 ( instalado el DBI1 )
- Pluggins para Kibana:
o elastic/sense
- Anaconda Versión 3.4 ( Instalado en todos los Nodos )
- Paquetes adiccionales para Python:
o Elasticsearch 2.3.0
o Nltk 3.2.1
o Keras 1.0.3 y Theano 0.8.2
o Tweepy 3.5.0
Anaconda se ha instalado en todos los nodos porque desde el principio se quiso
aprovechar todo el hw disponible. De esta forma podemos entrenar 7 modelos en paralelo.
Jupyter.Notebook. Aunque está instalado en todas las máquinas solo se puede usar desde
las 3 de gestión ya que son las únicas visibles desde el exterior.
Se ha creado un usuario a nivel de SO para la instalación de todos los paquetes
relacionados con el proyecto y poderlos tener identificados.
usuario: elastic
Home : /home/elastic Dir de instalación: /opt/elastic
Ilustración 8 - Aplicaciones instaladas.
4.2 Diseño de la BD Elasticsearch.
Este elemento es uno de los más importantes dentro del Framework ya que es
donde se van a persistir todos los datos, desde los tweets iniciales, hasta el resultado final
de las clasificaciones, pasando por el inventario y documentación de los modelos.
Además, va a ser el interface entre los diferentes módulos de la plataforma.
4.2.1 Configuración del cluster.
La BD se ha configurado para que trabaje en modo cluster y poder tener distribuida la
información entre los diferentes nodos.
Ilustración 9 - Configuración cluster Elasticsearch.

4.2.2 Diseño de la BD
Elasticsearch es una BD basada en índices, dentro de cada índice se puede organizar la
información en grupos (doc_types), sería algo similar a lo que pasa en las bbdd
relacionales. En este caso los índices serían los esquemas y los grupos las tablas. Otra
diferencia importante es el tipo de información con la que se trabaja, en este caso son
documentos tipo JSON.
A la hora de diseñar la BD se ha intentado simplificar al máximo la complejidad por eso
dentro de cada índice vamos a tener un único doc_type cuyo nombre va a ser el mismo que
el del índice.
Se han diferenciado los datos en 2 tipos:
HISTÓRICOS: Son aquellos datos que van a ser utilizados en la fase de entrenamiento de
los modelos. En esta categoría entran aquellos tweets antiguos y el inventario de modelos.
- TWEET_SAD / TWEET_HAPPY
- MODEL / MODEL2
ONLINE: Son datos “frescos”, recién capturados. En esta categoría entran los tweets que
se están descargando en ese momento y que se van a utilizar para clasificar junto a los
resultados obtenidos después de realizar esta categorización. Los Tweets, una vez
clasificados, podrían pasar a Histórico para ser utilizados en futuros entrenamientos.
- TWEET_ONLINE_SAD / TWEET_ONLINE_HAPPY
- RESULTADOS
Los índices se crean por defecto con el siguiente settings:
Ilustración 10 - Configuración Índices. Settings
Esto nos va a permitir agilizar las búsquedas ya que las va a distribuir entre los shards de
cada índice.
En la mayoría de los índices va a ser necesario forzar a que un campo sea del tipo date ya
que después va a ser necesario mostrar dicha información a lo largo de tiempo. Por
defecto, si no se especifica lo contrario a través del mappings, Elasticsearch determina su
tipo por defecto en función de los datos que contenga. EL campo fecha necesario lo
considera un string por eso es necesario forzar su tipo.

Ilustración 11 - Configuración Índices. Mappings.
Los datos de un tweet se guardan íntegros pero con alguna modificación:
Campo _ID: Hay que eliminar este campo debido a que en las versiones superiores a 3 de
Elasticsearch se trata de un campo reservado.
Campo CLASE: Se añade este campo para indicar la clase del tweet ( SAD (0) o HAPPY
(1). Esta información se conoce de antemano ya que los tweets se descargan por separado
almacenándose cada tipo en un índice diferente.
EL índice MODEL a priori carece de estructura prefijada debido a que es el índice
dedicado a guardar e inventarios los diferentes modelos entrenados y su contenido depende
del tipo de modelo a entrenar. Aquí no se necesita fecha porque es una información estática
por eso solo comparte con el resto de índices el setttings. Un modelo LSTM realizado con
keras tiene el siguiente aspecto:
Ilustración 12 - Ejemplo Índice Model.

MODEL2 solo se usa para realizar los backups de MODEL.
En el Índice RESULTADOS se van a guardar los resultados de clasificación de los
modelos. Aquí tanto el settings como el mappings van a ser idénticos a los índices para
tweets ya que vamos a necesitar un campo de tipo date para ver la evolución de los datos a
lo largo del tiempo.
En este caso los campos van a ser fijos.
Siendo su aspecto el siguiente:
4.3 Diseño del Aplicativo
4.3.1 Descripción general.
A la hora de diseñar el aplicativo me he inclinado por seguir con la filosofía de Python en
lo que se refiere a la forma de agrupar funciones con características similares. En este caso
he agrupado todas las funciones en 2 paquetes diferentes:
Tabla 1 - Descripción Índice Resultados.
Ilustración 13 - Ejemplos Índice Resultado

ES_TOOLS:
Agrupa todas aquellas herramientas relacionadas con la BD. Conexión, consulta, inserción,
creación de índices, borrado de documentos, filtrado de tweets, etc. Podemos encontrar los
siguientes grupos:
- Gestion BD ( connect, check, etc )
- Gestión índices
- Persistencia de tweets ( insert, copy, delete )
- Recuperación de tweets ( select , filtrado, etc )
ES_MODEL_ADMIN:
En este caso se han agrupado todas las funciones relacionadas con la gestión y
administración de los modelos, Alta/baja/modificación de los modelos, reconstrucción de
los mismos, categorización, manipulación de parámetros, etc.
- Gestión de índices
- Manipulación de parámetros ( set_param, show_param,del_param)
- Gestión de Modelos ( save_model, update_model,del_model, bck_model)
- Gestión Pasos a Producción. ( add_Active_model, del_active_model,…)
Parta hacer uso de estas librerías se ha de incorporar al principio del programa las
siguientes líneas:
4.3.2 Módulo 1. Descarga de tweets
Este módulo dispone de 2 scripts idéntico (uno para SAD y otro para HAPPY) que han de
ser lanzados en modo demonio ya que son los que van a estar continuamente descargando
los tweets. La única diferencia está en su configuración.
get_tweet_happy.py get_tweet_sad.py
Ambos descargan los tweets en español. Estos scripts hacen uso del módulo tweepy
A continuación se muestra unas capturas de uno de ellos mostrando a modo de debug los
pasos internos que se efectúan a la hora de procesar un tweet.
Ilustración 14 - Cabecera programas Python.

1.- La primera vez que se ejecuta el script, chequea los modelos que están en ese momento
en producción y los carga en memoria. Estos modelos se encuentran en el siguiente
fichero: active_models.conf
2.- Una vez cargados los modelos comienza con la recepción de los tweets. En el punto 2
muestra el tweet tal como se recibe.
3.- En este punto se observa el tweet después de haber sido filtrado. Hay un siguiente paso
que no aparece en esta captura y es la vectorización del tweet para poder ser clasificado por
aquellos modelos del tipo LSTM.
4.- Muestra los score devueltos por cada modelo y que se va a guardar en BD.
5.- Es un ejemplo de clasificación. El primer valor corresponde a un score para sad mayor
de 0.5, el segundo para 0.6 , así hasta 0.9. Esto es útil por ejemplo para representa la curva
ROC. Los valores mostrados son:
6.- Cada cierto tiempo se revisa si hay modelos nuevos a incluir en producción o darlos de
baja. La marca de tiempo está incluida en el fichero: active_models.mark
Ilustración 15 - Descripción captura tweets.

Una de las utilidades más importantes y complejas dentro de este módulo es el poder filtrar
los tweets. Esta operación se ha de realizar en la selección de datos y en la clasificación de
los mismos y se han de emplear los mismos criterios de filtrado. Por eso estos parámetros
no solo se guardan junto al resto de parámetros sino que también quedan guardados en un
documento especial cuyo id es LAST_FILTER.
La razón de ser de este documento especial dentro del índice MODEL se debe a que son
operaciones que se realizan con poca frecuencia ya que es bastante habitual recoger un
dataset con un filtro determinado y utilizarlo en multitud de sesiones de entrenamiento. En
estos casos se generarían modelos en los cuales no se ha definido ningún filtro por no hacer
falta. Como el filtro es imprescindible a la hora de clasificar los tweets, si el filtro no se
define, se registraría con el contenido de LAST_FILTER ya que contendría el último filtro
usado.
Los 3 parámetros relacionados con el filtro son:
FILTRO : conjunto de flags utilizados para filtrar.
ALLOWED_CHARS: caracteres permitidos.
REMOVED_CHARS: caracteres a descartar
Y los valores por defecto son los siguientes:
Ilustración 16 - Valores por defecto del l filtro.
Los filtros configurados hasta el momento son:
Esos flags en realidad no filtran tweets, solo los descartan.
Por eso solo son utilizados en el momento de selección de
los mismos.
Estos flag sí que son
auténticos filtros y son
utilizados tanto en la fase
de selección como en la
de clasificación.
Tabla 2 - Opciones de filtrado.

El orden de filtrado es el siguiente:
Las principales funciones junto a la relación entre ellas se puede observar en el siguiente
gráfico:
4.3.3 Módulo 2 - Gestión de Modelos
Este módulo surgió por la necesidad de tener documentados todos los modelos de forma
sencilla y transparente.
Se proporciona un api que permite realizar las siguientes operaciones:
- Administración del repositorio. Creación / destrucción de los índices
- Manipulación de los parámetros: set_param, show_param, etc
- Gestión de modelos : save_model, del_model, update_model
- Paso a producción: add_active_model
Ilustración 17 - Módulo 1. Relación detallada de las funciones.
Ilustración 18 - Módulo 2. Relación detallada de las funciones

4.3.4 Módulo 3 - Paso a Producción.
Este módulo permite a la plataforma poner automáticamente en producción aquellos
modelos que superen unos umbrales mínimos de calidad (por defecto pasan a producción
todos los modelos).
Este API proporciona las siguientes funcionalidades:
- Reconstrucción de modelos.
- gestionar el paso a producción de los modelos ( alta / bajas )
- categorización de los tweets
- Control de la recarga automática de los modelos.
- Persistencia de los resultados
- Actualización del inventario.
Se puede apreciar 2 partes bien diferenciadas:
- Una dedicada a la descarga de tweets, clasificación y persistencia en BD.
- Otra centrada en dar de alta/baja nuevos modelos. Esta parte mantiene actualizada la
BD en relación a la información que índica si un modelo está o no en producción.
Los parámetros actualizados por éste módulos son:
Status: indica si un modelo está en producción o no.
Status_Date: fechas de la última puesta en producción.
Ilustración 19 - Módulo 3. Relación detallada de las funciones
Ilustración 20 - Campos actualizados desde el Módulo 3.

4.3.5 Módulo 4: Visualización
El módulo de visualización se encarga de mostrar
de forma gráfico diferentes aspectos de los datos,
desde datos generales de los tweets, estadísticas de
los modelos como los resultados de los diferentres
modelos.
También permite la obtención de dichos datos para ser procesados en la fase de
entrenamiento y poder evaluar dicho modelo (get_model_result).
El dasboard creado para visualizar los datos más relevantes es el siguiente:
Ilustración 21 - Dashboard con pas principales métricas.

Ilustración 22 - Dashboard con las principales métricas.

5 Integración, pruebas y resultados
5.1 Entorno de trabajo.
Ha sido necesario instalar e integrar un conjunto de herramientas que han sido casi
imprescindibles a la hora de llevar a cabo este TFT.
Anaconda: Módulos adicionales para poder realizar operaciones que no estaban incluidas
en la distribución estándar.
Elasticsearch:
Ilustración 23 - Diferentes aplicaciones ( plugins ) utilizados .

Como este proyecto consta de 2 partes, se ha tenido que establecer un entorno de trabajo
adecuado con el fin de compartir la actual infraestructura. El problema principal radica en
que la creación del de esta plataforma y su utilización para el entrenamiento de modelos se
ha tenido que realizar de forma sincronizada y en paralelo. Para ello se ha establecido el
siguiente escenario:
BDI1:
- Descarga , clasificación y visualización.
- Repositorio central de ficheros.
- Entrenamiento ( solo cuando sea necesario )
BDI2:
- Desarrollo de SW. Mantenimiento y versionado del mismo.
- Entrenamiento
RESTO:
- Entrenamiento
Existe un entorno de Preproducción en donde se desarrollan todos los módulos que
integran esta plataforma. Una vez terminada una versión ésta se replica en todos los nodos
para que pueda ser utilizada por el módulo de entrenamiento.
Generalmente se libera una versión cuando se ha terminado de desarrollar un módulo o
cuando se hace imprescindible añadir nuevas funcionalidades para evitar que el
entrenamiento quede parado. (Líneas marrones en el gráfico. Solo se han dibujado 2 por
claridad)
Cada nodo de entrenamiento envía sus ficheros (generalmente el layout y los pesos de los
modelos obtenidos durante el entrenamiento) a DBI1 ya que son necesarios para
reconstruir de nuevo el modelo y poderlo poner en producción. Esto se puede hacer a mano
Ilustración 24 - Entorno de trabajo.

o de forma automática a través de esta plataforma. (Líneas rojas en el gráfico. Solo se han
representado 2 por claridad)
A su vez los modelos se guardan en elasticsearch para su posterior puesta en producción.
(Líneas verdes )
Con esta organización somos capaces de tener entrenando 7 máquinas a la vez sin que
interfieran entre ellas y de forma automática y a 2 personas desarrollando aplicativos sin
que ninguna de ellas se vea afectada por el otro.
5.2 Integración entre módulos
Otro reto importante fue resolver la comunicación entre los diferentes módulos de la
plataforma. Se optó por utilizar como interface el único elemento común a todos ellos, la
BD Elasticsearch.
Prácticamente todos los módulos usan JSON para comunicarse. La única excepción es la
comunicación con el módulo de training. Este módulo utiliza JSON para guardar los datos
pero a la hora de pedirlos, los obtiene en forma de dataframe Pandas.
La otra excepción es el control de pasos a producción de nuevos modelos (o baja de los
existentes) que se realiza a través de fichero utilizándose el formato TXT para ello.
Existen también 2 tipos de datos (diccionarios) utilizados para el intercambio de
información entre módulos:
Ilustración 25 - Conexión enre los difernetes módulos

MParam: se utiliza para gestionar y manipulas los datos del modelos.
MModel: Se utilizan para trabajar con los modelos en producción. Sus 2 elementos
principales son:
Param : del tipo MParam
Model : puntero al modelo creado a partir de los datos en <Param>.
5.3 Pruebas
Debido a las características especiales de este TFT, Las pruebas se han tenido que ir
realizando casi de forma continua, solapándose la creación de un módulo con las pruebas
del anterior. De hecho quien realmente ha probado dichos módulos en profundidad ha sido
mi compañero de TFT, David Serrano, ya que la finalidad última de este TFT es servir
como plataforma integrada para la gestión y puesta en producción de modelos y por lo
tanto que fuese usada por él.

6 Conclusiones y trabajo futuro
6.1 Conclusiones
Yo vengo del mundo de las BBDD relacionales ( Oracle, SQL Server, mysql . etc ) y la
forma de trabajar de las bbdd noSQL me parecía un caos, realmente no entendía cómo la
gente las utilizaba. Gracias a este TFT mi visión sobre ellas ha cambiado radicalmente, no
solo las entiendo sino que me parecen una opción muy buena a tener en cuenta. De hecho,
la aplicación realizada en este TFT sería casi inviable se tuviese que realizar con bbdd
relacionales, ya que los repositorios pueden cambiar en cualquier momento, sobre todo a la
hora de inventariar nuevos modelos.
Esta aplicación te permite centrarte en el entrenamiento, en adquirir más conocimientos ya
que te libera de tener que dedicarte al resto de tareas que rodean al propio training.
También te permite ver los resultados casi al momento comparando unos modelos con
otros.
6.2 Trabajo futuro
Aunque parece que esta aplicación está terminada, aún se me ocurren gran cantidad de
mejoras que seguramente incorpore en un fututo Algunas de ellas son las detalladas a
continuación:
- Posibilidad de enviar un correo cada vez que un modelo finalice su entrenamiento
enviando toda la información relevante del mismo y si ha sido o no puesto en
producción.
- Ahora mismo se envían los ficheros a un repositorio común. La siguiente mejora será
integrarlo con Hadoop, en concreto, integrarlo con HDFS, de esta forma ya no sería
necesario enviar ficheros a ningún sitio, serían accesibles por todos los nodos.
- Incorporación de los propios ficheros de pesos en el repositorio.
- Mejorar y ampliar las búsquedas.
- Ya que tenemos unos cuantos clasificadores clasificando en paralelo, no sería mala
idea implementar conjunto de clasificadores aprovechando los modelos en producción.

Referencias
[1] Huseyin Akdogan. “Elasticsearch indexing. Packt publishing . 2016
[2] Marek Rogozinski, Rafal Kuc. “Elasticsearch Server. 2nd Edition”. Packt publishing
2014
[3] Matthew Lee Hinman, Radu Gheorghe, Roy Russo. “Elasticsearch in Action”.
Manning. 2015
[4] Saurabh Chhajed “Learning ELK Stack”. Packt publishing 2015
[5] Yuvraj Gupta “Kibana Essentials”. Packt publishing 2015
[6] Micha Jaworski, Tarek Ziade. “Expert Python Programming”. Packt publishing 2015
[7] Allen B. Downey. “ Think Python, 2nd Edition” . O’Really . 2015
[8] Python elasticsearch client . https://elasticsearch-py.readthedocs.io/en/master/
[9] elasticsearch-py https://www.elastic.co/guide/en/elasticsearch/client/python-
api/current/index.html
[10] python + elasticsearch. First steps. http://blog.tryolabs.com/2015/02/17/python-
elasticsearch-first-steps/
[11] How to query elasticsearch with python.
https://marcobonzanini.com/2015/02/02/how-to-query-elasticsearch-with-python/
[12] Having gun: python and elasticsearch, Part 1. https://bitquabit.com/post/having-fun-
python-and-elasticsearch-part-1/
[13] Twittrer. REST API. https://dev.twitter.com/rest/public
[14] Tweet data format . http://support.gnip.com/sources/twitter/data_format.html
[15] a beginners guide to streamed data from tweeter.
http://mike.teczno.com/notes/streaming-data-from-twitter.html
[16] Tweeter API tutorial. http://socialmedia-class.org/twittertutorial.html
[17] Plugins para kibana https://github.com/elastic/kibana/wiki/Known-Plugins

Anexo 1. Manual de referencia.
6.3 ES_TOOLS.
Como hemos indicada a lo largo de esta memoria, este paquete engloba todas aquellas
funciones relacionadas con la manipulación directa de los datos.
6.3.1 BD elasticsearch
Estas funciones se encargan de gestionar la BD Elasticsearch así como los propios índices.
6.3.1.1 Connect
Realiza una conexión contra Elasticsearch.
connect(host=ES_MASTER)
HOST Host al que se quiere conectar. Por defecto se conecta al Master.
ES_PORT "9200"
ES_MASTER 0
6.3.1.2 es_check
Chequea conexión contra Elasticsearch.
es_check(host=None )
SALDA: estado de cada una de las máquinas
HOST Host que se quiere chequear. (Por defecto chequea todos).
Ejemplo:
print(es_check())
{'BDI6': 'OK', 'BDI7': 'OK', 'BDI4': 'OK', 'BDI1': 'OK', 'BDI5': 'OK'}
Ilustración 26- Módulo 1. Relación detallada de las funciones.

6.3.1.3 active_shards
Obtiene el número de shards configurados del índice solicitado.
active_shards(ind)
SALIDA: Total de shards configurados.
Ind Nombre del índice.
6.3.2 Índices
6.3.2.1 create_index
Crea el índice especificado
create_index(ind,setting=None)
Settings Settings y mappings a la hora de crear el índice
6.3.2.2 create_index_tweet
Crea el índice especificado de tipo tweet
create_index_tweet(index)
6.3.2.3 create_index_result
Crea el índice especificado del tipo resultado.
create_index_result(index)
6.3.2.4 create_index_*[happy|sad]
Crea los índices especificado del tipo tweet. Es una abstracción de las vunciones
anteriores:
create_index_online_happy()
create_index_online_sad()
create_index_happy()
create_index_sad()
6.3.2.5 drop_index
Elimina el índice especificado
drop_index(ind)
6.3.2.6 rebuild_index_tweet
Reconstruye el índice especificado

rebuild_index_tweet(index)
ind Nombre del índice.
6.3.3 Descarga de tweets
6.3.3.1 get_tweet_happy.py | get_tweet_sad.py
Provisiona los tweets necesarios para los entrenamientos conectándose
directamente con el API de twitter. ( Exite uno para bajar los tweets tristes y otro
para los felices )
Estos scripts están en ejecución continuamente.
Python get_tweet_hapy.py &
Python get_tweet_sad.py &
6.3.4 Persistencia de Tweets
6.3.4.1 insert_jtweet / insert_tweet
Inserta un tweet en la BD elasticsearch (es1) dentro del índice indicado.
insert_jtweet(es1,tweet,ind)
insert_tweet(es1,tweet,clase,ind)
insert_jtweet: el tweet que se le pasa es ubn JSON ( parámetro tweet )
insert_tweet : el tweet que se le pasa es un string ( parámetro línea )
SALIDA:
<string> : resultado de la operación.
insert --> se ha insetrtado correctamente
dupli --> es un tweet duplicado
err_json --> el formato del tweet no es correcto
error --> se ha producido algún error a la hora de isertar
es1 Conexión a la BD
Tweet Tweet a insertar. En format JSON o string
clase En el caso de ser un tweet en formato string, indica la clase 0(sad) 1 (happy)
ind Indice donde se va a realizar la insercción
6.3.4.2 insert_from_file
inserta en la BD elasticsearch en el indice tweet/<doctype> los tweets
contenidos en el fichero <f> que son de la clase <clase>
insert_from_file(ind,clase,f)
SALIDA: Muestra una serie de contadores:
Total Tweets leidos
Total Error json
Total tweets no insertados

Total tweets insertadps
clase Clase del tweet. 0(sad) 1 (happy)
f Path del fichero a leer
6.3.4.3 insert_From_file_sad / insert_From_file_happy
Insertar desde fichero los tweets indicados
insert_From_file_sad(f)
insert_From_file_happy(f)
f Path del fichero a leer
6.3.4.4 copy_tweet
Copia tweets desde el indice origen haste el destino. El destino puede ser otro indice
o un fichero
copy_tweet(orig,dest,clase,size=0,dest_type='index')
orig Índice Origen de datos.
dest Destino de los datos ( puede ser un índice o un fichero )
clase Clase de los datos 0(sad) 1 (happy)
size Total de tweets a copiar
Dest_type
Tipo de destino.
Index  índice file  fichero
6.3.5 Recuperación de Tweets
6.3.5.1 Filtrado de tweets
Todas estas funciones realizan el filtado especificado en su nombre.
remove_chars(text, list_chars=None)
keepOnlyAllowedChars(text,list_chars=None)
remove_url(text)
remove_mention(text)
remove_hashtag(text)
remove_space(text)
remove_unicode(text)
change_vowels(text)
SALIDA: el texto con el filtrado aplicado
text Texto a filtrar
List_chars Lista de caracteres a eliminar o mantener
6.3.5.2 Manipulación de listas de caracteres
Con estas funciones se pueden manipular las listas de caracteres.

get_allowed_chars(list_char)
set_allowed_chars(list_char)
get_removed_chars(list_char)
set_removed_chars(list_char)
List_chars Lista de caracteres a eliminar o mantener.
6.3.5.3 filter_tweet
Esta función realiza las llamadas al resto de funciones de filtrado según se defina
en el parámetro filtro.
filter_tweet(text,fil='uhmClrdsv', list_chars=None)
Texto Texto a filtrar
fil
Filtros a aplicar.
La descripción completa de los flags está detallada en select_tweets
List_chars Lista de caracteres a utilizar cuando el flag es c o C
6.3.5.4 count_tweets
Devuelve el total de tweets almacenados ( online + históricos )
count_tweets(index=None)
index Índice a contar. Por defecto cuanta todos los indices
6.3.5.5 select_tweets
Devuelve los tweets solicitados en formato pandas o lista.
select_tweets(index_type='happy',cantidad=10,
salida='pandas',init_scroll=0,_filtro='uhmClrdsv',list_chars=None)
Index_type
Tipo de tweets a bajar.
Sad : solo recupera tweets tristes
Happy : solo recupera tweets feclices
<number> : indica el porcentaje de tweets de cada tipo. El número es el porcentaje de
tweets happy, el resto serán tristes. 30  30% happy 70% sad
cantidad
Total de tweets recuperar.
0  indica que queremos todos.
Si se ha optado por la opción de recuperar ambos tipos, esta cantidad es el total de
ambos tipos
salida
Pandas  la salida es un dataframe de Pandas
List  la salida es una lista de twets
Init_scroll
grupo de datos que queremos coger. ( por defecto 0 )
por ejemplo : queremos 10000 ( cantidad=10000 )
0--> cogemos los primeros 10000
1--> saltamos los primeros 10000 y cogemos los siguientes 10000
n --> saltamos los primeros (n-1) * 10000 y cogemos los csiguientes al scroll n
filtro
filtro utilizado para limpiar los datos
u --> elimina las utls
m --> elimina los mencionados
h --> elimina los hastags
c --> elimina los simbilos de puntiación

C --> Mantiene los caracteres de la lista
r --> filtra los datos eliminando los retweets
R --> Obtiene solo los Retweets
l --> pasa a minusculas
s --> elimina los espacios sobrantes(solo deja 1 )
d --> elimina duplicados
c --> elimina tildes, dieresiss, etc ( la vocal permanece )
List_chars Lista de caracteres a eliminar o mantener ( cuando el flag es c o C )
6.3.5.6 select_htweets_by_id / select otweets_by_id
Devuelve los tweets correspondientes a la lista de ids suministrados
select_htweets_by_id(ids,columnas=['text','clase'],salida='pandas')
select_otweets_by_id(ids,columnas=['text','clase'],salida='pandas')
htweet  históricos
otweet  online
ids Lista de ids a buscar
columnas Campos que queremos que devuelva. Por defecto [id,text,clase]
salida Pandas o list
6.4 ES_MODEL
En este paquete se encuentran todas las funciones necesarias para para gestionar la
documentación de los modelos y su puesta en producción.
Gestión de Modelos: Documentación.

Gestión de Modelos: Paso a Producción y Clasificación.
6.4.1 Repositorio
6.4.1.1 create_index_model
Crea el índice donde vamos a tener el repositorio de modelos
Create_index_model()
6.4.1.2 drop_index_model
Elimina el índice donde vamos a tener el repositorio de modelos
drop_index_model()
6.4.2 Manipulación de parámetros
6.4.2.1 default_param
Elimina todos los valores configurados dejando únicamente los valores por defecto
Default_param()
6.4.2.2 set_param / set_jparam / set_fparam
Añade el parámetro indicado.
Set_param(param=None, valor=None)
Set_jparam(param=None, valor=None)
Set_jparam(param=None, valor=None)
Param: añade valores únicos

Jparam: añade un diccionario
Fparam: añade el contenido de un fichero
Param Parámetro a añadir
Valor Valor a añadir
6.4.2.3 show_param
Muestra el parámetro indicado.
Show_param(param=None)
Param Parámetro a mostrar ( por defecto muestra todos )
6.4.2.4 del_param
Elimina el parámetro especificado
select_htweets_by_id(ids,columnas=['text','clase'],salida='pandas')
select_otweets_by_id(ids,columnas=['text','clase'],salida='pandas')
Param Parámetro a eliminar
6.4.2.5 save_filtro / get_filtro
Salva o recupera el los parámetros relacionados con el filtro. Solo se usan cuando
no se han definido previamente.
Save_filtro()
Get_filtro()
Param Parámetro a eliminar
6.4.3 Gestión de modelos
6.4.3.1 Save_model
Salva todos los parámetros guardados con set_param en la BD. no se han definido
previamente.
Save_model(model_id,param=None,index=None)
Model_id Id del modelo
Param Set de parámetros diferentes a los actuales
Index Índice apternativo al que hay por defecto
6.4.3.2 Save_automatic_model
Salva todos los parámetros guardados con set_param en la BD. El id del modelo se
genera automáticamente en función del tipo de modelo.
Save_automatic_model(model_type)
Model_type
tipo de modelo.
Los modelos se organizan por tipos y dentro de cada tipo se van creando con un
numero secuencia.
por ejemplo: keras_0, keras_1, keras_2, forest_0 ....

6.4.3.3 Del_model
Elimina el modelo indicado
Del_model(model_id,index=None)
Model_id Id del modelo
Index Se puede especificar un índice alternativo
6.4.3.4 Update_model
Actualiza el modelo indicado.
Update_model(model_id=None,param=None)
Model_id Modelo a actualizar. Por defecto es el modelo actual
Param
Diccionario de valores a modificar o insertar.
{
“parámetro1” : “valor1”,
“parámetro2” : “valor2”,
}
6.4.3.5 Bck_model
Realiza una copia de seguridad del modelo en otro índice diferente.
Bck_model(model_id=None)
Model_id modelo a copiar. Por defecto es el actual
6.4.3.6 Get_model
Muestra los datos configurados del modelo.
Get_model(model_id=None)
Model_id Modelo a recuperar. Por defecto muestra los del modelo actual.
6.4.4 Recarga automática de modelos
6.4.4.1 set_active_model_mark / get_active_model_mark
Pone marca de tiempo.
Set_Active_model_mark()
Obtiene la última marca de tiempo.
Get_active_model_mark()

6.4.5 Paso a producción
6.4.5.1 add_active_model
Añade el modelo indicado a producción su supera el umbral configurado.
Add_Active_model(model_id, umbral=None)
Model_id Modelo a añadir
Umbral
Umbral que han de superar los modelos para para pasar a producción. Por defecto no
hay umbral.
{
“param1” : [ “> | <”, valor1 ],
“param2” : [ “> | <”, valor2 ]
}
6.4.5.2 get_active_models
Obtiene los modelos activos en cada momento.
Get_Active_models()
6.4.5.3 del_active_model
Saca de producción el modelo indicado.
del_Active_model(model_id)
Model_id Modelo a dar de baja
6.4.5.4 keras_model
Reconstruye modelos keras LSTM.
Keras_model(param)
param Parámetros recuperados del inventario para poder reconstruirlo.
6.4.5.5 rebuild_models
Reconstruye todos los modelos pasados a producción.
Rebuild_models()
SALIDA: lista con los punteros de todos los modelos cargados en memoria
Model_id Modelo a dar de baja
6.4.6 Clasificación
6.4.6.1 codificaTexto
Vectoriza el texto que va a ser clarificado
codificartexto(texto, char_idx, allowed_chars)
texto Texto a vectorizar

Char_idx Índices del diccionario de caracteres
Allowed_Chars Diccionario de caracteres
6.4.6.2 predict_models
Realiza la clasificación con cada uno de los modelos en producción.
predict_models(MM,text)
SALIDA: diccionario con los score(sad y happy ) de cada modelo + texto filtrado
MM
Lista con los punteros a los modelos cargados en memoria. Es la salida de la función
rebuild_models
Text Texto a clasificar
6.4.6.3 insert_model_result
Añade los resultados a la BD.
Insert_model_result(es1,tweet,clasificación)
Es1 Conexión a la bd
Tweet Tweet leído
clasificación Resultado de la clasificación
6.4.6.4 get_model_Result
Obtiene los resultados de un modelo dado.
Get_model_Result()
SALIDA: pandas con todos los resultados de ese modelo
Model_id Id del modelo.

Análisis de sentimiento en Twitter: Plataforma de gestión de modelos

Recomendados

Recomendados

Más contenido relacionado

Destacado

Destacado (6)

Similar a Análisis de sentimiento en Twitter: Plataforma de gestión de modelos

Similar a Análisis de sentimiento en Twitter: Plataforma de gestión de modelos (20)

Análisis de sentimiento en Twitter: Plataforma de gestión de modelos