Blog de Amazon Web Services (AWS)

Integrando Machine Learning con Aurora PostgreSQL

Por Alex Luna, Arquitecto de soluciones para el sector público en México

¿Qué tal si pudiéramos integrar el llamado a un modelo de ML desde una función o un procedimiento almacenado en nuestra base de datos? Podríamos  visualizar una consulta de clientes  y evaluar  su probabilidad  de aceptación  de un nuevo producto o servicio;  consultar el kárdex de un estudiante y saber la posibilidad de deserción o retención; o el expediente de un paciente y poder tener una inferencia sobre alguna patología.

AWS nos permite realizar lo anterior a través de Amazon Aurora en sus variantes de compatibilidad para MySQL y PostgreSQL; y SageMaker o Amazon Comprehend. En este blog veremos como integrar estos servicios.

Amazon Aurora es el motor de base de datos compatible con MySQL y PostgreSQL, nativo de AWS diseñado para aprovechar todas las ventajas de la nube de AWS. Aurora combina el desempeño y la disponibilidad de las bases de datos empresariales con la simplicidad y costo-efectividad de las bases de datos de código abierto. Se desempeña hasta 5 veces más rápido que una base de datos estándar MySQL y hasta 3 veces más rápido que una base de datos estándar PostgreSQL. Provee seguridad, disponibilidad y confiabilidad de las bases de datos comerciales a una décima del costo. Aurora es totalmente administrado por Amazon Relational Database Service (RDS).

Amazon SageMaker es un servicio de AWS que facilita a los científicos de datos y desarrolladores en el proceso de entrenamiento y despliegue de modelos de Machine Learning, desde el proceso de preparación, construcción, entrenamiento y afinación hasta el despliegue y gestión del modelo.

Amazon SageMaker es un servicio totalmente administrado que provee a cada desarrollador y científico de datos con la habilidad de preparar la construcción, entrenamiento y despliegue de modelos de machine learning rápidamente. SageMaker nos quita el trabajo pesado de cada paso en el proceso de machine learning para hacer más fácil el desarrollo de modelos de calidad. SageMaker provee todos los componentes utilizados en machine learning en un solo set de herramientas de tal forma que los modelos salgan a producción más rápido, con mucho menos esfuerzo y a un menor costo.

Amazon Comprehend es un servicio de Procesamiento de Lenguaje Natural (NLP) que usa machine learning para descubrir información dentro de un texto. Proporciona extracción de frases clave, análisis de sentimiento, reconocimiento de entidades, análisis de sintaxis, modelado de tópicos y API’s de detección de lenguaje de tal forma que se pueda, fácilmente, integrar procesamiento de lenguaje natural en las aplicaciones. Amazon Comprehend Medical es una variante para analizar información médica.

En este blog vamos a integrar machine learning de Amazon Comprehend y SageMaker desde Amazon Aurora compatible con PostgreSQL; para ello utilizaremos la funcionalidad de Aurora machine learning, con lo que, no es necesario desarrollar ninguna integración o aprender alguna herramienta adicional porque podemos integrar machine learning directamente dentro de un query de SQL llamando a una función.

Tampoco es necesario mover o copiar  la información fuera de la base de datos, de modo que podremos trabajar con datos transaccionales y tampoco necesitamos convertir o transformar el resultado de la invocación al modelo de machine learning.

Notas: Aurora machine learning para PostgreSQL conecta un clúster de Aurora con SageMaker o Amazon Comprehend usando la misma región.

Actualmente, Aurora machine learning soporta integración con cualquier endpoint de SageMaker que pueda leer y escribir valores en formato separado por comas (CSV), usando ContentType de text/csv. Los algoritmos integrados de SageMaker que actualmente aceptan este formato son Random Cut Forest, Linear Learner y XGBoost.

Seguridad

Tanto Amazon SageMaker como Amazon Comprehend se integran con CloudTrail que es un servicio de AWS que permite tener registro de las llamadas a API de estos servicios. La información enviada a Amazon Comprehend para inferir el sentimiento no es almacenada. La información almacenada en RDS o la empleada para el entrenamiento de cualquier modelo de SageMaker es propiedad del usuario y este tiene control sobre ella.

Se sugiere proteger la información almacenada en BD o en buckets de S3 utilizando mecanismos de control de acceso, utilizar privilegios de acceso mínimo y cifrado para garantizar la privacidad y seguridad, así como llevar a cabo monitoreo.

Prerrequisitos

Se requiere tener aprovisionado un clúster de Aurora PostgreSQL 10 o superior, Aurora machine learning está disponible para cualquier clúster de Aurora a partir de esta versión. Si se tiene una versión inferior se puede actualizar Aurora PostgreSQL a una versión superior para poder utilizar Aurora machine learning.

Se requiere tener un endpoint de un modelo entrenado de SageMaker desplegado en la misma región del clúster de Aurora. En este blog no se cubrirá el proceso de entrenamiento del modelo, pero he utilizado el siguiente modelo de ejemplo, que utiliza el algoritmo XGBoost para predecir la posibilidad de que un cliente determinado abandone el servicio.

Habilitar Aurora machine learning

  1. Configurar acceso IAM a servicios de machine learning de AWS
    Para que Aurora pueda tener acceso a SageMaker o Amazon Comprehend, es necesario configurar un rol para conceder acceso desde Aurora a SageMaker y otro para acceder a Comprehend.
    Los roles se pueden configurar desde la consola o desde línea de comando, aquí se mostrará como configurar mediante la consola. Primero crearemos el rol para SageMaker, al final se deben repetir los pasos para crear el rol para Comprehend.
    1. Iniciar sesión en la consola de AWS.
    2. Ir a la consola de IAM
    3. Antes de crear el rol, necesitamos crear una política de permisos que será asignada al role. Seleccionar la opción “Policies” del menú izquierdo.
    4. Clic en el botón “Create Policy”.
    5. En la ventana “Create policy” podemos utilizar el editor visual, pero aquí proporciono la plantilla JSON para fines prácticos.
    6. Dar clic en la pestaña JSON.
    7. Pegar el siguiente código JSON y reemplazar el ARN del endpoint del modelo publicado en SageMaker.
    8. Clic en “Next” y agregar un tag (opcional), clic en “Review”
    9. Capturar un nombre para la política, por ejemplo: “AllowAuroraToInvokeSageMakerEndpoint”, capturar una descripción y dar clic en “Create policy”
    10. Una vez creada la política, dar clic en la opción “Roles” del menú izquierdo de la consola IAM. Y dar clic en “Create role”.
    11. En la ventana “Create role”.
      • En “Select type of trusted entity”, seleccionar “AWS service”.
      • En la lista de servicios, seleccionar “RDS”.
      • En “Select your use case”, seleccionar “RDS – Add Role to Database”.
      • Clic en “Permissions”.
    12. En la ventana “Attach permissions policies”, buscar la política recién creada “AllowAuroraToInvokeSageMakerEndpoint”, clic en el botón “Next: Tags”.
    13. Agregar etiquetas (opcional) y clic en “Next: Review”.
    14. Capturar un nombre, por ejemplo: » AuroraExecuteSageMakerModel” y una descripción, clic en “Create role”.
  2. Para crear el role para Amazon Comprehend, repetir todo el paso 1 y utilizar la siguiente política. Para el ejemplo he nombrado a este rol “AuroraExecuteComprehend”.
  3. Asociar ambos roles IAM al clúster de Aurora PostgreSQL.
    1. Acceder a la consola de RDS y seleccionar el clúster de Aurora PostgreSQL.
    2. En la sección Manage IAM roles, seleccionar los roles creados y el Feature correspondiente (Comprehend y SageMaker), clic en el botón “Add role”.
  4. Instalar la extensión aws_ml para modelo de inferenciaDespués de crear el rol con los permisos necesarios y asociarlo al clúster de Aurora PostgreSQL es necesario instalar las funciones que permiten invocar las funcionalidades de que usan SageMaker y Amazon Comprehend. La extensión aws_ml de Aurora PostgreSQL provee la función aws_sagemaker.invoke para comunicarse con un modelo de SageMaker y la función aws_comprehend.detect_sentiment que permite comunicarse con Amazon Comprehend.
    1. Para instalar estas funciones en una base de datos en particular, se debe ejecutar el siguiente comando en el prompt de psql.psql> CREATE EXTENSION IF NOT EXISTS aws_ml CASCADE;
    2. Después de instalar la extensión se puede verificar la lista de extensiones instaladas con el comando:
postgres=> \dx List of installed extensions Name     | Version |   Schema   |              Description             
-------------+---------+------------+---------------------------------------
aws_commons | 1.2     | public     | Common data types across AWS services
aws_ml      | 1.0     | public     | ml integration
plpgsql     | 1.0     | pg_catalog | PL/pgSQL procedural language

Ejecutar Amazon Comprehend desde Aurora

Para usar Amazon Comprehend he creado la tabla statements e insertado algunos enunciados que analizaremos con Comprehend para determinar el sentimiento que reflejan.

Después invocamos la función “detect_sentiment” de la siguiente forma y pasar dinámicamente el enunciado, así como el idioma en que está escrito.

select id, statement, aws_comprehend.detect_sentiment(statement, 'es', null) from statements;

Podemos ver como se ejecuta la inferencia por cada línea de la tabla y determina el sentimiento con un gado de probabilidad.

  

Ejecutar inferencia de SageMaker desde PostgreSQL

Para utilizar SageMaker desde Aurora he creado la siguiente tabla de clientes e intentaremos inferir la posibilidad de perder a un cliente.

select state, area_code, phone, int_plan, vmail_plan, vmail_msg, day_calls, eve_calls,      int_calls

from customers limit 10;

Se necesita tener un modelo desplegado de SageMaker, como se mencionó anteriormente, para este blog se entrenó y se desplegó el siguiente ejemplo de predicción de abandono de clientes utilizando XGBoost. Para más información sobre como entrenar y desplegar un modelo de SageMaker, ver Train a Model with Amazon SageMaker. La imagen siguiente muestra el endpoint en la consola de SageMaker, tomar nota del ARN del endpoint del modelo.

Para poder realizar la inferencia hacia el endpoint de SageMaker necesitamos crear una función que a su vez ejecute la función aws_sagemaker.invoke_endpoint (instalada al momento de habilitar la extensión aws_ml.

Utilizar una función de usuario nos da varias ventajas:

  • Utilizar un nombre función personalizado para llamar a invoke_endpoint
  • Especificar el endpoint en un solo lugar
  • Control independiente de los permisos de ejecución para cada función de machine learning
  • Declaración de tipos de entrada y salida del modelo usando tipos de SQL. Controlar el número de argumentos necesarios.

Para definir la función se utiliza la sentencia CREATE FUNCTION de SQL data definition language (DDL) y se debe especificar lo siguiente:

  • Parámetros de entrada del modelo
  • El endpoint de SageMaker a invocar
  • El tipo de dato de retorno

Para este ejercicio, cree la siguiente función, que como se verá recibe varios parámetros de tipo numérico y texto, que son necesarios para ejecutar la predicción.

CREATE OR REPLACE FUNCTION predecir_abandono(
       state character varying, acc_length bigint, area_code bigint,
       phone character varying, int_plan character varying,
       vmail_plan character varying, vmail_msg bigint, day_mins double precision,   day_calls bigint, day_charge double precision, eve_mins double precision,   eve_calls bigint, eve_charge double precision, night_mins double precision,        night_calls bigint, night_charge double precision, int_mins double precision,       int_calls bigint, int_charge double precision, cust_service_calls bigint,   max_rows_per_batch INT DEFAULT NULL, OUT salida character varying)
 
       RETURNS character varying
       LANGUAGE 'sql'
      
       COST 5000
       VOLATILE PARALLEL SAFE
   
AS $BODY$
SELECT aws_sagemaker.invoke_endpoint
('sagemaker-sklearn-automl-2021-10-25-05-19-06-167', max_rows_per_batch,
       state, acc_length, area_code, phone, int_plan, vmail_plan, vmail_msg, day_mins,       day_calls, day_charge, eve_mins, eve_calls,
       eve_charge, night_mins, night_calls, night_charge, int_mins, int_calls,       int_charge, cust_service_calls
        )  ::varchar(2048);
$BODY$;

Notar que el parámetro opcional max_rows_per_batch controla el número de filas para una invocación en modo batch. Si es NULL, entonces el optimizador de consultas elige automáticamente el máximo tamaño del batch.

Ejecutamos la consulta, que incluye el llamado a la función de usuario.

select state, area_code, phone, predecir_abandono(state, acc_length, area_code, phone, int_plan, vmail_plan, vmail_msg, day_mins, day_calls, day_charge, eve_mins, eve_calls, eve_charge, night_mins, night_calls, night_charge, int_mins, int_calls, int_charge, cust_service_calls) as probabilidad_abandono

from customers;

La función devuelve un valor de tipo carácter determinado por varchar(2048), el valor podría ser un número si así lo devolviera el modelo y se pueden aplicar casteos tanto en los parámetros de entrada como en la salida según se requiera. En este caso se consideran 2 valores, la primera es una etiqueta binaria y la probabilidad de abandono.

La ejecución de la consulta y la del modelo se ejecutan en capas diferentes, esta separación nos permite escalar los recursos de machine learning separadamente de los del clúster de Aurora, por lo que debemos buscar que la función de usuario sea tan eficiente como sea posible.

Algunos aspectos a considerar son:

  • El parámetro max_rows_per_batch para llamadas a las funciones de aws_ml
  • El número de vCPUs de la instancia de base de datos, que determina el grado de paralelismo que se usará al invocar las inferencias de ML
  • La parametrización de PostgreSQL de ejecutar consultas en paralelo.

Aurora automáticamente utilizará el modo batch cuando la función sea invocada desde una sentencia SELECT, WHERE o HAVING, lo que implica que Aurora machine learning ejecutará todas las llamadas al modelo de todas las filas devueltas por la consulta para realizar una sola ejecución en batch y luego las devuelve al query en ejecución línea por línea; lo que optimiza las consultas de Aurora sin limitar el query optimizer.

Sin duda esta flexibilidad de integración permitirá agregar valor a las aplicaciones, haciéndolas mas inteligentes y poniendo a la vanguardia a las organizaciones que le saquen provecho. Este enfoque de  análisis dentro  la base de datos es un modelo de análisis en el que al procesar los datos dentro de una base de datos, permite eliminar la sobrecarga de mover grandes conjuntos de datos a aplicaciones analíticas. En este modelo de análisis, la lógica analítica está integrada en una base de datos en lugar de en una aplicación separada, reduciendo tiempo y costo.

Sobre el Autor

Alex Luna es Arquitecto de soluciones para el sector público en México. Apoyo a organizaciones educativas, de gobierno y organizaciones sin ánimo de lucro a generar soluciones de vanguardia empleando servicios de AWS.