Bluetab

an IBM Company

Bluetab

Regulatorio RDA

by

Regulatorio RDA

En línea con las necesidades de las Instituciones Financieras respecto a los sistemas de agregación y reporte de datos de riesgo (traducción de – RDA –  Risk Data Aggregation) Bluetab ha acompañado inicialmente en los bancos sistémicos (2015-2017) y colaborando posteriormente con otras entidades financieras españolas (2019-2020) para el cumplimento del estándar de supervisión que marca el Comité de Basilea (BCBS239).

Posteriormente al resto de bancos españoles (2019-2020). Debido a las consiguientes exigencias los sistemas informacionales y técnicas de reporting han tenido una creciente atención de las agencias regulatorias, las cuales han puesto foco en trasladar la criticidad de reportar de forma precisa los principales indicadores de riesgos, de exposición, activos, pasivos y obligaciones, etc.

white printed poster

Bluetab ha realizado proyectos de diferente índole, a nivel nacional e internacional, para el Diseño y construcción de un Datamart que aprovisiona los informes del departamento de Riesgos aplicables a RDA, además de una redefinición de los informes actuales adaptados a la nueva metodología para el cumplimiento de los principios que exigen para cumplimiento efectivo de los requerimientos. En el proyecto internacional ha sido necesaria la paquetización de un modelo base (core) que se ha ido adaptando posteriormente a la casuísticas propias de las diferentes Entidades locales.

Para la realización de los diferentes proyectos se ha realizado la construcción de procesos en Powercenter con la construcción de cuadros de mando y validación de información en Microstrategy en el proyecto global para bancos sistémicos por su afección global, y en Data Stage y OBIEE para la entidad financiera de ámbito nacional.

CASOS DE ÉXITO

Normativa MIFID

by

Normativa MIFID

La adaptación a los marcos normativos, regulatorios y de supervisión son un factor clave en las Entidades Financieras para asegurar el cumplimiento de las diferentes transposiciones de reglamentos y directivas a nivel europeo y nacional (España). Bluetab colabora con los principales bancos españoles para adaptar sus plataformas de datos y así cumplir con los crecientes requerimientos y exigencias regulatorias que se han visto obligados a afrontar en el último lustro. En línea con estas colaboraciones Bluetab ha generado un cuadro de mando integral para cumplir con los reportes que exigía MIFID, siglas en inglés de la Directiva Europea sobre mercados de instrumentos financieros. Esta directiva regula la prestación de servicios de inversión en cuanto a la forma en que informan, asesoran o venden los productos financieros a sus clientes actuales o potenciales, así como la manera en la que les ofrecen servicios de ejecución de operaciones sobre instrumentos financieros.

man writing on paper

El reporting realizado por Bluetab para una de las principales Entidades Financieras españolas, facilita un control y monitorización de la aplicación de la normativa en las oficinas posibilitando el acceso a nivel de detalle por ejes de centro, cliente y producto. El cuadro de mando de MIFID permite a la entidad medir el grado de cumplimiento de la normativa y poder reportar al regulador una información correctamente “gobernada” en cuanto a fiabilidad y trazabilidad se refiere, cumpliendo los informes generados los requerimientos especificados como son:

  • barra-bluetab Seguimiento del cumplimiento
  • barra-bluetab Detalle de la información a nivel cliente
  • barra-bluetab Posibilidad Autoservicio a usuarios

El proyecto consiste en el aprovisionamiento y generación del cuadro de mando que permita el almacenamiento y explotación de la información relacionada con el consentimiento de datos del cliente desde la información con origen en el Informacional de Big Data a la BBDD de SQL Server de forma diaria de forma diaria (15 días) y de forma agregada semanal (3 semanas). En el alcance se incluye el análisis funcional y de negocio, con la realización del modelo lógico y físico, el diseño de informes y la construcción, así como la validación de la información.
Las principales tecnologías utilizadas fueron Microstrategy para el reporting y Datastage y SQL Server para el aprovisionamiento y almacenamiento.

CASOS DE ÉXITO

Data Governance en sector Media

by

Data Governance en sector Media

En uno de nuestros clientes del sector «media» participamos con nuestras soluciones de gobierno del dato en el proceso de transformación digital de la arquitectura de datos sobre entornos Cloud.

 

Dentro de esta iniciativa hemos incorporado distintas piezas sobre su plataforma Cloud, proporcionando una visión completa del dato desde un punto único de acceso.

Para ello se ha diseñado e implementado un Catálogo de datos y mecanismos para para el descubrimiento de metadatos. Además nuestras soluciones nos permiten gestionar las definiciones de los datos desde un puesto de vista de negocio por medio del Glosario de Negocio desde dónde medimos y controlamos la calidad de la información.

En el proyecto las tecnologías más utilizadas han sido los diferentes servicios de Azure en cloud (ADLS, Blob, ADLA, etc)

laptop computer on glass-top table

CASOS DE ÉXITO

Almacén Cloud en Banca

by

Almacén Cloud en Banca

El camino de los bancos a ser “Data driven companies” hace que crezca exponencialmente el volumen de datos a almacenar y procesar.

Realizamos uno de los proyectos más estratégicos de Data para facilitar el escalado de la infraestructura en una de las mayores entidades financieras de España. gestionando un entorno Cloud para soportar la elasticidad que demandan los usuarios.

A través de este servicio se proporciona un reporting que permite controlar y detectar los factores que impactan en la calidad de los servicios ofrecidos por la Entidad. El cuadro de mando facilita la toma de decisiones para implementar procesos de mejora continua, específicamente a través de lógicas de detección, preventivas y correctivas que permitan minimizar los tiempos de respuesta para mejorar la calidad de los servicios digitales.

El proyecto se basa en bots que simulan peticiones virtuales de servicio para todos los canales, permitiendo conocer el estado de todos los procesos implicados en cada momento. Adicionalmente se proporciona una visión cliente, trazando la información de los ficheros (logs) que contienen información propia de cliente para seleccionar los KPIS más relevantes y realizar extracciones agregadas para su explotación.

Tecnologías: Cloud AWS, PostgreSQL, S3, Grafana, MicroStrategy

macro photography of black circuit board

CASOS DE ÉXITO

Introducción a los productos de HashiCorp

by

Introducción a los productos de HashiCorp

Jorge de Diego

Cloud DevOps Engineer

Desde la Práctica Cloud queremos impulsar el uso de los productos Hashicorp y por ello vamos a publicar artículos temáticos sobre cada uno de ellos.

Debido a la multitud de posibilidades que ofrecen sus productos, en éste artículo abordaremos una visión de conjunto y en publicaciones posteriores, entraremos en detalle de cada uno de ellos, aportando casos de uso no convencionales que muestren el potencial que tienen los productos de Hashicorp.

¿Por qué Hashicorp?

Durante estos últimos años, Hashicorp viene desarrollando diferentes productos Open Source los cuales ofrecen una gestión transversal de la infraestructura en entornos Cloud y on-premises. Estos productos, han marcado estándares en la automatización de infraestructura.

En la actualidad, sus productos aportan soluciones robustas en los ámbitos del aprovisionamiento, seguridad, interconexión y coordinación de cargas de trabajo.

El código fuente de sus productos está liberado bajo licencia MIT, lo cual ha tenido una gran acogida dentro de la comunidad Open Source (cuentan con más de 100 desarrolladores aportando mejoras de forma continua)

Además de los productos que expondremos en este artículo, disponen de interesantes soluciones Enterprise.

Respecto al impacto que tienen sus soluciones, poniendo como ejemplo Terraform, se ha convertido en un referente en el mercado. Esto significa que Hashicorp está haciendo las cosas bien, por lo que es conveniente entender y aprender a usar sus soluciones.

Aunque nos estemos centrando en su uso en el ámbito Cloud, sus soluciones tiene gran presencia en los entornos on-premises, pero alcanzan todo su potencial cuando trabajamos en la nube.

¿Cuáles son estos productos?

Hashicorp cuenta con los siguientes productos:

  • Terraform: infraestructura como código.
  • Vagrant: máquinas virtuales para entornos de pruebas.
  • Packer: construcción de imágenes de forma automatizada.
  • Nomad: “orquestador” de cargas de trabajo.
  • Vault: gestión de secretos y protección de datos.
  • Consul: gestión y descubrimiento de servicios en entornos distribuidos.


A continuación, resumimos las principales características de los productos. En próximas publicaciones entraremos en detalle de cada uno de ellos.

Terraform se ha posicionado como el producto más extendido en el ámbito del aprovisionamiento de Infraestructura como Código.

Utiliza un lenguaje específico (HCL) para desplegar infraestructura a través del uso de los diferentes proveedores de Cloud. Terraform también permite gestionar recursos de otras tecnologías o servicios, como Gitlab o Kubernetes.

Terraform hace uso de un lenguaje declarativo y se basa en tener desplegado exactamente lo que pone en el código.

El típico ejemplo que se muestra para entender la diferencia con el paradigma que sigue por ejemplo Ansible (procedimental) es:

En un primer momento queremos desplegar 5 instancias EC2 en AWS:

Ansible:

- ec2:
    count: 5
    image: ami-id
    instance_type: t2.micro

Terraform:

resource "aws_instance" "ejemplo" {
  count         = 5
  ami           = "ami-id"
  instance_type = "t2.micro"
}

Como puede observarse, no existen prácticamente diferencias entre los códigos. Ahora necesitamos desplegar dos instancias más para hacer frente a una carga de trabajo mayor:

Ansible:

- ec2:
    count: 2
    image: ami-id
    instance_type: t2.micro

Terraform:

resource "aws_instance" "ejemplo" {
  count         = 7
  ami           = "ami-id"
  instance_type = "t2.micro"
}

En este momento, podemos ver que mientras en Ansible estableceríamos en 2 el número de instancias a desplegar para que en total haya 7 desplegadas, en Terraform estableceríamos el número directamente a 7 y Terraform sabe que tiene que desplegar 2 más porque ya hay 5 desplegadas.

Otro aspecto importante es que Terraform no necesita un server Master como Chef o Puppet. Es una herramienta distribuida cuyo elemento común y centralizado es el tfstate (se explica en el siguiente párrafo). Se lanza desde cualquier sitio con acceso al tfstate (que puede ser remoto, guardado en un almacenamiento común como puede ser AWS S3) y terraform instalado, el cual se distribuye como un binario descargable desde la web de Hashicorp.

El último punto a comentar sobre Terraform es que se basa en un archivo denominado tfstate en el que va guardando y actualizando la información relativa al estado de la infraestructura, y el cual va a consultar para conocer si es necesario realizar cambios sobre la misma. Es muy importante tener en cuenta que este estado es lo que conoce Terraform. Terraform no va a conectarse a AWS para ver qué hay desplegado. Por ello es necesario no realizar cambios a mano sobre infraestructura desplegada por Terraform (ni nunca. Cambios a mano, nunca), ya que no se actualiza el tfstate y por tanto se crearán inconsistencias.

Vagrant permite desplegar entornos de test de manera local de forma rápida y muy simple, basados en código. Por defecto utiliza por debajo VirtualBox, pero es compatible con otros providers como por ejemplo VMWare o Hyper-V. Es posible desplegar máquinas sobre proveedores Cloud como AWS instalando plugins. Personalmente no encuentro la ventaja de usar Vagrant para esta función.

Las máquinas que despliega se basan en boxes, y desde el código se indica qué box se quiere desplegar. En este aspecto podría compararse en modo de funcionamiento con Docker. Sin embargo, la base es totalmente distinta. Vagrant levanta máquinas virtuales con una herramienta de virtualización por debajo (VirtualBox) mientras que Docker despliega contenedores y su soporte es una tecnología de contenerización Vagrant VS Docker.

Casos de uso típicos pueden ser probar playbooks de Ansible, recrear un entorno de laboratorio de manera local en muy pocos minutos, realizar alguna demo, etc.

Vagrant se basa en un archivo Vagrantfile. Una vez situado en el directorio donde se encuentra este Vagrantfile, con ejecutar vagrant up, la herramienta comienza a desplegar lo que se indique dentro de dicho archivo.

Los pasos para lanzar una máquina virtual con Vagrant son:

1- Instalar Vagrant. Se distribuye como un binario al igual que el resto de productos de Hashicorp.

2- Con un Vagrantfile de ejemplo:

Vagrant.configure("2") do |config|
  config.vm.box = "gbailey/amzn2"
end

PD: (el parámetro 2 dentro de configure se refiere a la versión de Vagrant, que me ha tocado mirarlo para el post)

3- Ejecutar dentro del directorio donde se encuentra el Vagrantfile

vagrant up

4- Entrar por ssh a la máquina

vagrant ssh

5- Destruir la máquina

vagrant destroy

Vagrant se encarga de gestionar el acceso ssh creando una clave privada y almacenándola en el directorio .vagrant, aparte de otros metadatos. Se puede acceder a la máquina ejecutando vagrant ssh. También es posible visualizar las máquinas desplegadas en la aplicación de VirtualBox.

Con Packer puedes construir imágenes de máquinas de forma automatizada. Puede utilizarse para, por ejemplo, construir una imagen en un proveedor Cloud como AWS con una configuración inicial ya realizada y poder desplegarla un número indeterminado de veces. De esta forma solo es necesario aprovisionar una sola vez y al desplegar la instancia con esa imagen ya tendrá la configuración deseada sin tener que invertir mayor tiempo en aprovisionarla.

Un pequeño ejemplo sería:

1- Instalar Packer. De la misma forma, es un binario que habrá que colocar en una carpeta que se encuentre en nuestro path.

2- Crear un archivo, por ejemplo builder.json. También se crea un pequeño script en bash (el link que se muestra en builder.json es dummy):

{
  "variables": {
    "aws_access_key": "{{env `AWS_ACCESS_KEY_ID`}}",
    "aws_secret_key": "{{env `AWS_SECRET_ACCESS_KEY`}}",
    "region": "eu-west-1"
  },
  "builders": [
    {
      "access_key": "{{user `aws_access_key`}}",
      "ami_name": "my-custom-ami-{{timestamp}}",
      "instance_type": "t2.micro",
      "region": "{{user `region`}}",
      "secret_key": "{{user `aws_secret_key`}}",
      "source_ami_filter": {
        "filters": {
            "virtualization-type": "hvm",
            "name": "amzn2-ami-hvm-2*",
            "root-device-type": "ebs"
        },
        "owners": ["amazon"],
        "most_recent": true
      },
      "ssh_username": "ec2-user",
      "type": "amazon-ebs"
    }
  ],
  "provisioners": [
    {
        "type": "shell",
        "inline": [
            "curl -sL https://raw.githubusercontent.com/example/master/userdata/ec2-userdata.sh | sudo bash -xe"
        ]
    }
  ]
}

Los proveedores utilizan software integrado y de terceros para instalar y configurar la imagen de la máquina después del arranque. Nuestro ejemplo ec2-userdata.sh

yum install -y \
  python3 \
  python3-pip \

pip3 install cowsay

3- Ejecutar:

packer build builder.json

Y ya tendríamos una AMI aprovisionada con cowsay instalado. Ahora nunca más será necesario que, como primer paso tras lanzar una instancia, sea necesario instalar cowsay porque ya lo tendremos de base, como debe ser.

Como es de esperar, Packer no solo funciona con AWS sino con cualquier proveedor Cloud como Azure o GCP. También funciona con VirtualBox y VMWare y una gran lista de builders. Además, se puede crear una imagen anidando builders en el archivo de configuración de Packer que sea igual para distintos proveedores _Cloud. Esto es muy interesante para entornos multi-cloud en los que haya que replicar diferentes configuraciones.

Nomad es un orquestador de cargas de trabajo. A través de sus Task Drivers ejecutan una tarea en un entorno aislado. El caso de uso más común es orquestar contenedores Docker. Tiene dos actores básicos: Nomad Server y Nomad Client. Ambos actores se ejecutan con el mismo binario pero diferente configuración. Los Servers organizan el cluster mientras que los Agents ejecutan las tareas.

Un pequeño “Hello-world” en nomad podría ser:

1- Descargar e instalar Nomad y ejecutarlo (en modo development, este modo nunca debe usarse en producción):

nomad agent -dev

Una vez hecho esto ya es posible acceder a la UI de nomad en localhost:4646

2- Ejecutar un job de ejemplo que lanzará una imagen de grafana

nomad job run grafana.nomad

grafana.nomad:

job "grafana" {
    datacenters = [
        "dc1"
    ]

    group "grafana" {
        task "grafana"{
            driver = "docker"

            config {
                image = "grafana/grafana"
            }

            resources {
                cpu = 500
                memory = 256

            network {
                mbits = 10

                port "http" {
                    static = "3000"
                }
            }
            }
        }
    }
}

3- Acceder a localhost:3000 para comprobar que se puede acceder a grafana y acceder a la UI de Nomad (localhost:4646) para ver el job

4- Destruir el job

nomad stop grafana

5- Parar el agente de Nomad. Si se ha ejecutado tal y como se ha indicado aquí, con pulsar Control-C en la terminal donde se está ejecutando bastará

En resumen, Nomad es un orquestador muy ligero, al contrario que Kubernetes. Lógicamente no tiene las mismas funcionalidades que Kubernetes pero ofrece la posibilidad de ejecutar cargas de trabajo en alta disponibilidad de forma sencilla y sin necesidad de usar gran cantidad de recursos. Se tratarán ejemplos con más detalle en el post de Nomad que se publicará en un futuro.

Vault se encarga de gestionar secretos. A través de su api los usuarios o aplicaciones pueden pedir secretos o identidades. Estos usuarios se autentican en Vault, el cual tiene conexión a un proveedor de identidad de confianza como un Active Directory, por ejemplo. Vault funciona con dos tipos de actores al igual que otras de las herramientas mencionadas, Server y Agent.

Al inicializar Vault, comienza en estado sellado (Seal) y se generan diferentes tokens para deshacer el sellado (Unseal). Un caso de uso real sería demasiado largo para este artículo y se verá en detalle en el artículo destinado únicamente a Vault. Sin embargo, se puede descargar y probar en modo dev al igual que se ha mecionado antes con Nomad. En este modo, Vault se inicializa en modo Unsealed , almacenando todo en memoria sin necesidad de autenticación, sin utilizar TLS y con una única clave de sellado. De esta forma podremos jugar con sus funcionalidades y explorarlo de una manera rápida y sencilla.

Consultar en este enlace para mayor información.

1- Instalar Vault. Al igual que el resto de productos de Hashicorp, se distribuye como un binario a través de su web. Una vez hecho, lanzar (este modo nunca debe usarse en producción):

vault server -dev

2- Vault mostrará el token de root que sirve para autenticarse contra Vault. También mostrará la única clave de sellado que crea. Ahora Vault es accesible a través de localhost:8200

3- En otra terminal, exportar las siguientes variables para poder hacer pruebas:

export VAULT_ADDR='http://127.0.0.1:8200'
export VAULT_DEV_ROOT_TOKEN_ID="token-showed-when-running-vault-dev"

4- Crear un secreto (En la terminal en la que se han exportado las variables anteriores)

vault kv put secret/test supersecreto=iewdubwef293bd8dn0as90jdasd

5- Recuperar ese secreto

vault kv get secret/test

Estos pasos son el Hello World de Vault, para comprobar su funcionamiento. En el artículo de Vault veremos de forma detallada el funcionamiento y la instalación de Vault, así como más características como las policies, explorar la UI, etc.

Consul sirve para crear una red de servicios. Funciona de forma distribuida y un cliente de consul se ejecutará en una localización en la que existan servicios que se quieran registrar. Consul incluye Health Checking de servicios, una base de datos de clave valor y funcionalidades para securizar el tráfico de red. Al igual que Nomad o Vault, Consul tiene dos actores principales, Server y Agent.

De la misma manera que hemos hecho con Nomad y Vault, vamos a ejecutar Consul en modo dev para mostrar un pequeño ejemplo definiendo un servicio:

1- Instalar Consul. Crear una carpeta de trabajo y dentro de la misma crear un archivo json con un servicio a definir (ejemplo de nombre de carpeta: consul.d).

Archivo web.json (ejemplo de la web de Hashicorp):

{
  "service": {
    "name": "web",
    "tags": [
      "rails"
    ],
    "port": 80
  }
}

2- Ejecutar el agente de Consul indicándole el directorio de configuración creado antes donde se encuentra web.json (este modo nunca debe usarse en producción):

consul agent -dev -enable-script-checks -config-dir=./consul.d

3- A partir de ahora, aunque no hay nada realmente ejecutándose en el puerto indicado (80), se ha creado un servicio con un nombre DNS al que se puede preguntar para poder acceder al mismo a través de dicho nombre DNS. Su nombre será NAME.service.consul. En nuestro caso NAME es web. Ejecutar para preguntar:

dig @127.0.0.1 -p 8600 web.service.consul

Nota: Consul por defecto se ejecuta en el puerto 8600.

De la misma manera se puede preguntar por un record de tipo SRV:

dig @127.0.0.1 -p 8600 web.service.consul SRV

También se puede preguntar a través de los tags del servicio (TAG.NAME.service.consul):

dig @127.0.0.1 -p 8600 rails.web.service.consul

Y se puede consultar a través de la API:

curl http://localhost:8500/v1/catalog/service/web

Nota final: Consul se utiliza como complemento a otros productos, ya que sirve para crear servicios sobre otras herramientas ya desplegadas. Es por ello que este ejemplo no es demasiado ilustrativo. Aparte del artículo específico de Consul, se encontrará como ejemplo en otros artículos como en el de Nomad.

En futuros artículos se explicará también Consul Service Mesh para interconexión de servicios a través de sidecars proxies, la federación de Datacenters de Nomad en Consul para realizar despliegues o las intentions, que sirven para definir reglas de con qué servicios puede comunicarse otro servicio.

Conclusiones

Todos estos productos tienen un gran potencial en sus respectivos ámbitos y ofrecen una gestión transversal que puede ayudar a evitar el famoso vendor lock-in de los proveedores de Cloud. Pero lo más importante es su interoperabilidad y compatibilidad.

¿Quieres saber más de lo que ofrecemos y ver otros casos de éxito?
DESCUBRE BLUETAB
Jorge de Diego
Cloud DevOps Engineer

Mi nombre es Jorge de Diego y estoy especializado en entornos Cloud. Trabajo habitualmente con AWS aunque tengo conocimientos sobre GCP y Azure. Entré en Bluetab en septiembre de 2019 y desde entonces trabajo de Cloud DevOps y tareas de seguridad. Me interesa todo lo relacionado con la tecnología y en especial, los ámbitos de modelos de seguridad e Infraestructura. Podréis identificarme en la oficina por los pantalones cortos.

SOLUCIONES, SOMOS EXPERTOS

DATA STRATEGY
DATA FABRIC
AUGMENTED ANALYTICS

Te puede interesar

Conceptos básicos de AWS Glue

by

Conceptos básicos de AWS Glue

Álvaro Santos

Senior Cloud Solution Architect​

Desde la Práctica Cloud queremos impulsar la adopción de la nube como forma de trabajo en el mundo de IT. Para ayudar en esta tarea, vamos a publicar multitud de artículos de buenas prácticas y casos de uso, otros hablarán aquellos servicios clave dentro de la nube.

A continuación os vamos a presentar los conceptos básicos de AWS Glue.

¿Qué es AWS Glue?

AWS Glue es uno de esos servicios de AWS que son relativamente nuevos pero que tienen un enorme potencial. En especial este servicio puede ser muy beneficioso para todas aquellas empresas que trabajan con datos y que aún no posean una infraestructura de Big Data potente.

Básicamente, Glue es un servicio de ETLs totalmente administrado por AWS y de pago por uso sin necesidad de aprovisionar instancias. Para conseguirlo, combina la velocidad y potencia de Apache Spark con la organización de datos que ofrece Hive Metastore.

AWS Glue Data Catalog

El Catálogo de datos de Glue es donde se almacenan todos los orígenes y destinos de datos para los trabajos de Glue.

  • Table es la definición de una tabla de metadatos sobre las fuentes de datos y no los datos en sí. Las tablas de AWS Glue pueden referirse datos basados ​​en archivos almacenados en S3 (como Parquet, CSV…), tablas de RDBMS…

  • Database se refiere a una agrupación de fuentes de datos a las que pertenecen las tablas.

  • Connection es un enlace configurado entre AWS Glue y un cluster de RDS, Redshift u otra BBDD compatible con JDBC. Estas permiten que Glue acceda a sus datos.

  • Crawler es el servicio encargado de conectarse a un almacén de datos, avanza a través de una lista priorizada de clasificadores para determinar el esquema de los datos y de generar las tablas de metadatos. Son compatibles de determinar el esquema de datos complejos no estructurados o semi-estructurados. Ésto es especialmente importante cuando se trabajan con fuentes de datos de tipo Parquet, AVRO, …

ETL

Una ETL en AWS Glue está compuesta principalmente de los scripts y otras herramientas que utilizan los datos configurados en Data Catalog para extraer, transformar y cargar los datos en un sito definido.

  • Job es el motor principal de la ETL. Un trabajo consiste en un script que carga datos de las fuentes definidas en el catálogo y realiza transformaciones sobre ellos. Glue puede generar automáticamente un script, o se puede crear uno personalizado usando la API de Apache Spark en Python (PySpark) o Scala. Además, se permite el uso de bibliotecas externas que vinculara al trabajo mediante un archivo zip en S3.

  • Triggers se encargan de ejecutar los Jobs. Pueden ejecutarse según un cronograma, un evento de CloudWatch o incluso un comandos cron.

  • Workflows es un conjunto triggers, crawlers y jobs relacionados entre sí en AWS Glue. Con ellos se puede crear un flujo de trabajo para realizar una ETL compleja de varios pasos pero que AWS Glue puede ejecutar como entidad única.

  • ML Transforms son unos trabajos específicos que mediante modelos de Machine Learning crean transformaciones personalizadas para la limpieza de los datos como por ejemplo identificación de datos duplicados.

  • Finalmente, también es posible usar Dev Endpoints y Notebooks, que facilitan el desarrollo y probar los scripts de manera más rápida y sencilla.

Ejemplos

Script de ejemplo de ETL en Python:

import sys
from awsglue.transforms import *
from awsglue.utils import getResolvedOptions
from pyspark.context import SparkContext
from awsglue.context import GlueContext
from awsglue.dynamicframe import DynamicFrame
from awsglue.job import Job

args = getResolvedOptions(sys.argv, ['JOB_NAME'])

sc = SparkContext()

glueContext = GlueContext(sc)
spark = glueContext.spark_session
job = Job(glueContext)

## Read Data from a RDS DB using JDBC driver
connection_option = {
"url": "jdbc:mysql://mysql–instance1.123456789012.us-east-1.rds.amazonaws.com:3306/database",
"user": "test",
"password": "password",
"dbtable": "test_table",
"hashexpression": "column_name",
"hashpartitions": "10"
}

source_df = glueContext.create_dynamic_frame.from_options('mysql', connection_options = connection_option, transformation_ctx = "source_df")

job.init(args['JOB_NAME'], args)

## Convert DataFrames to *AWS Glue* 's DynamicFrames Object
dynamic_df = DynamicFrame.fromDF(source_df, glueContext, "dynamic_df")

## Write Dynamic Frame to S3 in CSV format
datasink = glueContext.write_dynamic_frame.from_options(frame = dynamic_df, connection_type = "s3", connection_options = {
"path": "s3://glueuserdata"
}, format = "csv", transformation_ctx = "datasink")

job.commit()

Creación de un Job mediante línea de comandos:

aws glue create-job --name python-job-cli --role Glue_DefaultRole \

--command '{"Name" : "my_python_etl", "ScriptLocation" : "s3://SOME_BUCKET/etl/my_python_etl.py"}'

Ejecución de un Job mediante línea de comandos:

aws glue start-job-run --job-name my_python_etl

Además, AWS tiene publicado un repositorio con multitud de ejemplos de ETLs para AWS Glue.

Seguridad

Como todo servicio de AWS, está diseñado e implementado para ofrecer la mayor seguridad posible. Estas son algunas de las funcionalidades de seguridad que ofrece AWS GLUE:

  • Cifrado en Reposo: este servicio admite el cifrado de datos (SSE-S3 o SSE-KMS) en reposo para todos los objetos que trabaja (catálogo de metadatos, contraseña de conexiones, escritura o lectura de los datos de la ETL, …).

  • Cifrado en Tránsito: AWS ofrece cifrado de conexión segura (SSL) para todos los datos en movimiento, las llamadas a la API de AWS Glue y a todos los servicios de AWS como S3, RDS…

  • Registro y monitorización: está fuertemente integrado con AWS CloudTrail y AWS CloudWatch.

  • Seguridad de red: es capaz de habilitar conexiones dentro de una VPC privada y trabajar con Security Groups.

Precio

AWS factura por el tiempo de ejecución de los crawlers / jobs de ETLs y por el uso de Data Catalog.

  • Crawlers: se factura sólo por el tiempo de ejecución del crawler. El precio es de $0.44 (eu-west-1) por cada hora de DPU (4 vCPUs y 16 GB RAM) facturados en tramos de hora.

  • Data Catalog: se puede almacenar hasta un millón de objetos de manera gratuita y a partir de ahí $1.00 (eu-west-1) cada 100.000 objetos. Además, se factura $1 (eu-west-1) por cada 1.000.000 de peticiones al Data Catalog de las cuales el 1er millón es gratuito.

  • ETL Jobs: se factura sólo por el tiempo que el trabajo de ETL demore en ejecutarse. El precio es de $0.44 (eu-west-1) por cada hora de DPU (4 vCPUs y 16 GB RAM) facturados por segundo.

Beneficios

Pese a ser un servicio joven es bastante maduro y se está usando mucho por clientes del todo el mundo de AWS. Las características más importantes que nos aporta son:

  • Gestiona automáticamente el escalado de recursos, reintentos de tareas y gestión de errores automáticamente.

  • Es un servicio Serverless, AWS maneja el aprovisionamiento y escalado de los recursos para ejecutar los comandos o consultas en el entorno Apache Spark.

  • Los crawlers son capaces de rastrear tus datos, sugerir esquemas y almacenarlos en un catálogo centralizado. Además, son detectan cambios en los mismos.

  • El motor ETL de Glue genera automáticamente código Python / Scala y tiene un programador incluyendo dependencias. De este modo, facilita el desarrollo de las ETLs.

  • Usando el catálogo Glue, podemos consultar directamente los datos S3 usando Athena y Redshift Spectrum.

Conclusiones

Como toda Base de Datos, herramienta o servicio ofrecido, AWS Glue tiene ciertas limitaciones que habría que tener en cuenta para adoptarlo como servicio de ETLs. Por ello deberías tener presente que:

  • Está muy enfocado a trabajar con fuentes de datos en S3 (CSV, Parquet…) y JDBC (MySQL, Oracle…).

  • La curva de aprendizaje es alta. Si tu equipo viene del mundo de ETL tradicional, tendrás que esperar a que gane conocimientos de Apache Spark.

  • Al contrario que otras herramientas de ETLS, carece por defecto de compatibilidad con muchos servicios de terceros.

  • No es una herramienta de ETLs 100% al uso y, puesto que usa Spark, es necesario realizar optimizaciones en el código manualmente.

  • Hasta hace poco (abril 2020), AWS Glue no soportaba fuente de datos en streaming. Es demasiado prematuro usar AWS Glue como herramienta de ETLS para datos en tiempo real.
¿Quieres saber más de lo que ofrecemos y ver otros casos de éxito?
DESCUBRE BLUETAB
Álvaro Santos
Senior Cloud Solution Architect

Mi nombre es Álvaro Santos y ejerzo como Solution Architect desde hace más de 5 años. Estoy certificado en AWS, GCP, Apache Spark y alguna que otras más. Entré a formar parte en Bluetab en octubre de 2018 y desde entonces estoy involucrado en proyectos cloud de Banca y Energía y además participo como Cloud Master Partitioner. Soy un apasionado de las nuevas patrones distribuidos, Big Data, Open-source software y cualquier otra cosa de mundo IT que mole.

SOLUCIONES, SOMOS EXPERTOS

DATA STRATEGY
DATA FABRIC
AUGMENTED ANALYTICS

Te puede interesar

© 2024 Bluetab Solutions Group, SL. All rights reserved.