Autor: afm

Caso de éxito – Big Data & Analytics: Aguas Araucanía – Reconocimiento de Imágenes y Video usando Aprendizaje Automático

Lo que opina nuestro Cliente Para la Sub Gerencia Corp. de Sistemas de Aguas Araucanía ha sido el modelo más adecuado y eficiente para poder entregar soluciones a nuestros clientes, a costos más convenientes. La disposición y calidad de los profesionales de Morris & Opazo nos ha permitido ejecutar proyectos con alto nivel de calidad del producto final, con estándares de desarrollo y focalizados a los procesos y problemáticas de nuestra organización. Las soluciones a la medida ha dado respuesta a los procesos en donde soluciones de mercado no lo han sido. Fernando Javier Valdés Álvarez, SubGerente Corporativo de Sistemas El problema La oportunidad en esta etapa es presentar nuevas tecnologías que permitan mejorar los diferentes canales de comunicación con el cliente. En este caso en particular, a través de videos e imágenes. Solución propuesta Nuestra solución consiste en la implementación de un flujo de Big Data para la recolección, almacenamiento, procesamiento y consumo/visualización de los datos que permita, a través del uso de tecnologías de inteligencia artificial, la extracción de los metadatos de las imágenes y videos. Beneficios Innovación: Confiabilidad, agilidad, escalabilidad y desempeño requeridos por sus cambiantes negocios. Flexibilidad: Infraestructura bajo demanda que permite la rápida experimentación e iteración. Agilidad: Confiabilidad, escalabilidad y desempeño requeridos por sus negocios. Tecnologías usadas Amazon S3 Amazon Cognito Amazon API Gateway AWS Lambda AWS Step Functions Amazon Rekognition Amazon Transcribe Amazon Comprehend Amazon Elasticsearch Resultados La solución implementada entrega una plataforma muy poderosa para almacenar y procesar imágenes y video, alcanzando resultados que entregan gran valor al negocio al analizar y extraer metadatos del material fuente, y haciendo que esta información esté disponible para los procesos del negocio que se beneficien de ella.

Caso de éxito – Big Data & Analytics: Rimac – Data Lake Perú (+Video)

El Problema Rimac tenía una carga de trabajo grande y muy pesada para sus procesos de datos y análisis, realizados todos ellos en servidores on-premise. Cada nuevo proceso generaba una nueva tabla en su base de datos, lo cual hacía aún más compleja la administración de la información, y contribuía a los costosos tiempos de procesamiento de la información. Estos y otros factores crearon un escenario en que los procesos de negocio no podían continuar escalando en respuesta al creciente volúmen de datos y complejidad de los mismos, y era necesario mejorar los tiempos de procesamiento. Continuidad Operativa Para garantizar la continuidad operativa de la plataforma se han escogido servicios que en su mayoría se caracterizan por ser “serverless”, es decir no dependen de infraestructura de servidores para la ejecución de sus procesos. Esto no solo simplifica la administración de la plataforma, sino que entrega características de alta disponibilidad en los servicios de forma automática sin requerir esfuerzos adicionales. Escalabilidad Los recursos provisionados por AWS para dar soporte a la operación del Data Lake de Rimac se caracterizan por ser flexibles, permitiendo escalabilidad vertical u horizontal según sea necesario. Seguridad Para acceder a los servicios del Data Lake los usuarios deben autenticarse con credenciales propias de la plataforma AWS a través del servicio de Identity & Access Management (IAM). El mismo servicio IAM permite establecer el nivel de acceso y privilegios para cada servicio que reciben los usuarios, lo que determina finalmente quién puede acceder a cada servicio, y qué acciones o actividades puede realizar Protección de Datos en Reposo Los servicios de almacenamiento de datos de la Nube de AWS cuentan con sistemas de encriptación para los datos en reposo, de manera que no es posible realizar una lectura de los datos sin pasar por el sistema de desencriptado correspondiente. Monitoreo Permanente CloudWatch y CloudTrail proveen la capacidad de monitoreo constante de los recursos y servicios del Data Lake de Rimac: alertas y notificaciones relacionadas con las métricas de los servicios e infraestructura en uso. Todo evento generado por los usuarios es registrado y almacenado, permitiendo realizar procesos de auditoría y conformidad. Tecnologías usadas AWS Direct Connect AWS IAM Amazon S3 Amazon Redshift AWS EMR Amazon Athena Amazon Sagemaker AWS Storage Gateway Amazon CloudWatch Amazon CloudTrail   La fuente de datos primaria del Data Lake es el servicio de Amazon S3. En Amazon S3 se almacenan los diferentes archivos planos generados por los Data Extractors. Amazon Redshift es el repositorio de los datos transformados del Data Lake. Amazon Redshift recibe información desde las transformaciones del script ETL en EMR y desde Amazon S3. El Data Lake permite hacer uso de clústers EMR para realizar análisis predictivo de los datos almacenados en el servicio Amazon S3. Amazon Athena permite realizar consultas interactivas en el Data Lake. Con Amazon SageMaker, Rimac puede crear, entrenar y ejecutar sus modelos de Machine Learning. Para facilitar la carga de datos hacia el Data Lake y proveer un sistema seguro de transferencia de datos de fácil uso e implementación, AWS Storage Gateway provee un punto único de acceso a la estructura del Data Lake en S3, que permite el copiado de archivos hacia el Data Lake. Resultados La solución implementada trasladó la carga de trabajo de los procesos de datos y análisis realizados on-premise, hacia la nube de AWS, entregando con esto una plataforma de clase mundial para el procesamiento y almacenamiento de los datos que permite optimizar y acelerar la obtención de resultados en los procesos de datos incorporados a esta nueva plataforma, y aliviando la carga de trabajo de la infraestructura y recursos on-premises.

Caso de éxito – Soluciones en la Nube: Copias de Seguridad & Recuperación en AWS

Lo que opina nuestro cliente Para la Sub Gerencia Corp. de Sistemas del grupo Aguas Nuevas ha sido el modelo más adecuado y eficiente para poder entregar soluciones a nuestros clientes, a costos más convenientes. La disposición y calidad de los profesionales de Morris & Opazo nos ha permitido ejecutar proyectos con alto nivel de calidad del producto final, con estándares de desarrollo y focalizados a los procesos y problemáticas de nuestra organización. Las soluciones a la medida ha dado respuesta a los procesos en donde soluciones de mercado no lo han sido. Fernando Javier Valdés Álvarez, SubGerente Corporativo de Sistemas El Problema A medida que crece “Aguas Nuevas”, también aumenta el tamaño de las bases de datos de Oracle y la enorme cantidad de bases de datos que mantienen. Esto ha generado cada vez más problemas relacionados con la realización de backups de las bases de datos existentes de Oracle en cintas, por lo que se han contemplado estrategias alternativas como la utilización de los servicios de la cloud de Amazon Web Services (AWS), una subsidiaria de Amazon.com. Entre los retos empresariales a los que se enfrenta “Aguas Nuevas” destacan: La planificación de uso y capacidad resulta compleja, y el tiempo y el presupuesto de inversión de capital son de suma importancia. Con los años se necesitaron importantes inversiones de capital para hardware de cinta, espacios de centros de datos para dicho hardware y gastos de licencias empresariales para software de cinta. Durante dicho periodo, la administración de la infraestructura de cinta requería contar con personal altamente cualificado dedicado a la configuración, certificación e ingeniería de la planificación de archivado, en lugar de dedicarse a proyectos de mayor valor. Y, al final de cada ejercicio fiscal, prever los futuros requisitos de capacidad requería auditorías, previsiones y elaboración de presupuestos que consumían mucho tiempo. El costo del software de backup necesario para varios dispositivos de cinta podía ser toda una sorpresa. Los robots de cintas ofrecen una capacidad básica de lectura/escritura, pero para poder utilizarlos completamente, es necesario invertir en software de backup en cinta patentado. Para “Aguas Nuevas”, el costo del software había sido alto y constituía una parte importante de los costos generales de backup. El costo de este software no dejaba de plantear un problema en los presupuestos, pero resultaba difícil de solucionar debido a que era necesario grabar los backups en dispositivos de cinta. Mantener backups de confianza y disfrutar de rapidez y eficacia al recuperar los datos son tareas que requieren mucho tiempo y esfuerzo con la cinta. Si los datos tienen que almacenarse de manera duradera en la cinta, es necesario realizar varias copias. Si todo funciona correctamente y existe una contención mínima de los recursos de cinta, los robots de cinta y el software de backup pueden encontrar los datos necesarios con facilidad. No obstante, si el hardware falla, se precisa de la intervención humana para restablecer los datos desde la cinta. La contención de las unidades de cinta derivada de solicitudes de cinta de varios usuarios ralentiza todavía más los procesos de restablecimiento. Esto afecta al objetivo de tiempo de recuperación (RTO) y hace que conseguirlo sea más complicado que con las backups almacenadas en la cloud Solución propuesta “Aguas Nuevas” empezó a evaluar Amazon S3 para poder introducir mejoras económicas y de desempeño en el ámbito de la backup de los datos. Como parte de dicha evaluación, estudiaron los aspectos de seguridad, disponibilidad y desempeño de las backups de Amazon S3. “Aguas Nuevas” también realizó un análisis costo-beneficio para garantizar que la migración a Amazon S3 merecía la pena desde el punto de vista económico. Este análisis costo-beneficio comprendía los siguientes elementos: Ventajas de desempeño y competitividad de los costos. Era importante que los costos generales de los backups no aumentaran. Al mismo tiempo, “Aguas Nuevas” precisaba de un desempeño más rápido para backups y recuperaciones. El tiempo y el esfuerzo necesarios para las operaciones de backup y recuperación demostraron ser una mejora importante con respecto a la cinta, ya que el restablecimientos desde Amazon S3 se ejecutaba de dos a doce veces más rápido que un restablecimiento similar desde la cinta. “Aguas Nuevas” necesitaba un nuevo método de backup para ofrecer más desempeño y, al mismo tiempo, mantener o reducir los costos generales. Los backups en discos on-premise hubieran mejorado el desempeño, pero hubiesen supuesto pérdidas en relación con la competitividad de los costos. El almacenamiento basado en la cloud de Amazon S3 cumplía los dos criterios. Mayor durabilidad y disponibilidad. Amazon S3 está diseñado para ofrecer una durabilidad del 99,999999999% y una disponibilidad de los objetos del 99,99% durante un año concreto. “Aguas Nuevas” comparó estas cifras con las de la infraestructura de la cinta, tras lo cual determinó que Amazon S3 ofrecía una mejora importante. Menor fricción operativa. Los administradores de bases de datos de “Aguas Nuevas” tuvieron que evaluar si las backups de Amazon S3 serían viables para las backups de las bases de datos. Determinaron que utilizar Amazon S3 para las backups resultaba fácil de implementar ya que funcionaba perfectamente con Oracle RMAN. Seguridad de los datos potente. “Aguas Nuevas” observó que AWS cumplía todos los requisitos de seguridad física, acreditaciones de seguridad y procesos de seguridad, protegía los datos activos e inactivos y utilizaba los estándares de cifrado adecuados. Beneficios Reducida Inversión en Hardware El diseño de almacenamiento distribuido en línea de la Nube de AWS elimina los cuellos de botella y las restricciones de las soluciones on-premise y de cinta. La replicación instantánea garantiza que los datos están asegurados generando automáticamente tres copias de los datos a diferentes regiones de AWS. Tiempos de Recuperación Más Rápidos Amazon S3 proporciona control sobre la región en la cual están almacenados los datos, para minimizar la latencia para una más rápida y más fácil recuperación de los datos. El almacenamiento en línea permite una recuperación más rápida que con las cintas, con latencias de milisegundos. Costos Operativos Más Bajos Utilice una solución que conoce y en

Caso de éxito – Big Data & Analytics: Insights de Redes Sociales

Lo que opina nuestro cliente “Morris & Opazo ha sido un colaborador importante en el apoyo a nuestras iniciativas para aprovechar los recursos en la nube y aprovechar al máximo las tecnologías en la nube para Big Data y Analytics”. – Francois Toubol, VP of Technology, SIM Partners El problema La solución final tenía que ser lo suficientemente escalable para recopilar, almacenar, procesar y visualizar las métricas de diferentes redes sociales. También esta información debía quedar disponible para distintos consumidores de la plataforma. Solución propuesta La solución de Big Data representó una mejora en seguridad, tiempos de desarrollo más cortos, amplia disponibilidad, actualizaciones más frecuentes, más elasticidad, una mayor cobertura geográfica, todo esto minimizando los costos finales. Beneficios: Velocidad: El data lake nos permitió importar cantidades significativas de datos que se originaban en tiempo real. Los datos se recuperaban desde diferentes fuentes, y fueron movidos a un data lake en su formato original. Este proceso permitió escalar a datos de cualquier tamaño y a la vez ahorrar tiempo. Economía de escala: Los servicios de la nube de AWS siguen un modelo de precios por capa y descuentos por volumen. Esto nos ha permitido crecer sin llegar a situaciones de facturación inesperadas, teniendo la tranquilidad de pagar el menor costo posible por los servicios consumidos. Integración de servicios: Al implementar nuestro Data Lake nos fue posible acceder a múltiples servicios de la nube de AWS, entre ellos Machine Learning, lo que nos permitió mejorar nuestros productos y entregar valor agregado en nuestra oferta de servicios. Tecnologías usadas Morris & Opazo created a Data Producer which streamed (via Amazon Kinesis) the metrics data from Social Network APIs to a Data Lake implemented in Amazon S3. This first stage represented a significative savings in costs for storage-related components, with an optimal performance and speed. Amazon Kinesis Amazon Redshift AWS S3 Resultados: El data lake nos permitió importar cantidades significativas de datos que se originaban en tiempo real. Los datos se recuperaban desde diferentes fuentes, y fueron movidos a un data lake en su formato original. Este proceso permitió escalar a datos de cualquier tamaño y a la vez ahorrar tiempo. Los servicios de la nube de AWS siguen un modelo de precios por capa y descuentos por volumen. Esto nos ha permitido crecer sin llegar a situaciones de facturación inesperadas, teniendo la tranquilidad de pagar el menor costo posible por los servicios consumidos. Al implementar nuestro Data Lake nos fue posible acceder a múltiples servicios de la nube de AWS, entre ellos Machine Learning, lo que nos permitió mejorar nuestros productos y entregar valor agregado en nuestra oferta de servicios.

Ejemplo Básico de CI/CD – Amazon (AWS)

Ejemplo Básico de CI/CD: Cuando se aborda el tema de CI/CD (Continuous Integration/Continuous Delivery, Integración Continua/Entrega Continua) muchas veces los conceptos se presentan de manera ‘filosófica’, olvidando un poco cómo ‘aterrizarlos’ a la práctica. En este blog queremos presentar un acercamiento precisamente a cómo llevar a la práctica un flujo básico de CI/CD. Es muy importante comprender el flujo básico CI/CD para un proyecto de Desarrollo de Software, ya que al comienzo podría parecer confuso qué paso lleva a cuál, qué debe hacerse en cada etapa, o qué elemento es responsable de cuál tarea. Una vez se ha entendido este flujo, el segundo punto más complejo de entender podría ser la configuración en sí del Sistema de Integración Continua (qué herramienta utilizar, qué plugins instalar, cómo configurar los permisos, cómo generar los contenedores, etc.) Aunque existen múltiples formas de abordar una implementación de CI/CD, vamos a tomar un ejemplo básico representado por el siguiente diagrama: (Basic Flow for a Back-End CI/CD Project) Este flujo comienza cuando un desarrollador envía (‘push’) su archivo/código fuente a un repositorio, el cual puede ser GitHub. Cuando GitHub detecta un push, envía una notificación a un Sistema de Integración Continua (por ejemplo, Jenkins). Una vez Jenkins recibe la información de GitHub, construye el proyecto (‘build’) mediante una configuración previamente establecida (jobs de Jenkins): Compilación Pruebas unitarias Pruebas de integración Entre otras, sobre el proyecto. Esta construcción depende del tipo de proyecto: pueden haber proyectos de Front-End o de Back-End. Para este ejemplo vamos a trabajar con Java. Si la construcción se llevó a cabo correctamente sin errores, Jenkins genera un contenedor y ese contenedor se puede subir a Amazon ECR. De lo contrario si ocurre algún error, el proceso no llega hasta el ECR. Es elección del Desarrollador cada cuánto realiza push al repositorio (desde su IDE). Para el caso de GitHub, es necesario configurar ‘webhooks’, el cual es un ‘punto de información’ para notificar a un servicio externo cada vez que se realice un push: En la imagen anterior, la URL corresponde a un webhook asociado con Jenkins. Jenkins, a su vez, permite configurar trabajos asociados con ese webhook: Un job (en Jenkins) es un proyecto que se puede configurar para especificar cómo se va a compilar, construir, y distribuir un sistema: El ‘disparador’ asociado a este proyecto de Jenkins está vinculado con GitHub: Permite especificar el repositorio y la rama (‘branch’) asociada con el proyecto: En este caso, la construcción pasa por un archivo (Jenkinsfile): En el archivo Jenkinsfile podríamos configurar las diferentes etapas por las que pasa la construcción de la aplicación: En la imagen anterior el archivo Jenkinsfile especifica diferentes etapas de construcción. Cada etapa debe ser ejecutada satisfactoriamente antes de que inicie la siguiente. La primera etapa es el ‘checkout’, en la cual Jenkins obtiene todas las fuentes modificadas del repositorio una vez que GitHub le informa de un nuevo ‘Push’. En la segunda etapa (‘compile’) se construye el proyecto. Para este ejemplo se está construyendo un proyecto en Java por medio de Maven, para lo cual se ejecuta el comando: mvn -U clean compile Con este comando se generan, a partir de código fuente, los .class de java (que serán interpretados posteriormente por la Máquina Virtual de Java). Para la tercera etapa que son las pruebas de unidad (‘Unit Test’) se ejecuta el comando: mvn test Una vez se han completado las pruebas, se ‘empaqueta’ el proyecto mediante el comando: mvn package El cual genera un .jar, que se podría considerar ya como el ‘entregable’ que contiene todos los .class necesarios para el proyecto Java: Por último se realizan pruebas de integración: mvn verify Un ejemplo de prueba de integración puede ser realizar una solicitud a una API REST y verificar que la respuesta sea siempre la esperada (llamar a la API proporcionando un argumento y comparar que la respuesta). Para este punto se utiliza un contenedor Docker temporal, el cual dura sólo durante la ejecución de las pruebas de integración. Cuando las pruebas de integración terminan satisfactoriamente, se realiza el despliegue definitivo (‘deploy’). El ‘deploy’ consiste en tomar la imagen recién generada y llevarla al repositorio de imágenes (en este caso Amazon ECR). En el ejemplo anterior, este despliegue se está haciendo a un ambiente de UAT, el paso previo a producción. Cada construcción que se realiza queda registrada en Jenkins: El ‘recorrido’ (pipeline) que realiza el proyecto en Jenkins puede verse también gráficamente de la siguiente forma: En la imagen anterior se puede observar cómo el flujo (en Jenkins) es: En caso de presentarse un error, Jenkins indica precisamente la etapa en la que se produjo. Por ejemplo en la construcción #39 el error se produjo en las Pruebas de Integración. En las otras construcciones no se produjo ningún error: Es posible obtener más información sobre el error que se generó: Al fallar una etapa las siguientes (si existen) no se ejecutan: En cada etapa de la construcción se indica su duración total (en milisegundos o segundos). Jenkins también calcula la duración promedio para cada etapa en todo el proyecto. Una vez Jenkins envía la nueva imagen a Amazon ECR, Jenkins reinicia el servicio para que ECS detecte la nueva imagen (comienzan a bajarse las instancias actuales de contenedores, y a subirse nuevas instancias). Las imágenes que se van enviando a Amazon ECR quedan almacenadas en repositorios: Cada repositorio puede contener una o más imágenes: Cada vez que se solicita un reinicio desde Jenkins lo que se reinicia es un servicio asociado a un cluster de AWS ECS: En la imagen anterior existen varios servicios dentro del cluster. Cada uno de esos servicios (para el ejemplo) tiene una instancia en ejecución ya que se ha configurado ese número de instancias como el deseado. Una vez se ha reiniciado el servicio, se puede acceder a las diferentes opciones que tiene el software desarrollado. Es decir, si el proyecto es una API REST ya podrían empezar a hacerse solicitudes a esta API. Es importante resaltar que el único

Construyendo un Data Lake en AWS

Logs con ElasticSearch

Using Bootstrap Actions in EMR – Amazon (AWS)

Dentro del conjunto de herramientas que ofrece AWS para Big Data, EMR es una de las más versátiles y poderosas, brindando al usuario un sinfín de opciones de hardware y software con el propósito de enfrentar cualquier desafío -y tener éxito- relacionado con el procesamiento de grandes volúmenes de datos. Sin embargo, un usuario que trabaje con la consola EMR por primera vez encontrará que las opciones están empaquetadas en una lista generosa, pero limitada, de configuraciones de software y hardware, y puede llegar a la conclusión -¡equivocada!- de que EMR no tiene lo que se necesita para la tarea. Consola Web: Creando un Cluster de EMR En este artículo nos centraremos en estudiar cómo incluir elementos de software adicionales y/o diferentes a los que se ofrecen en el paquete de la consola Web, y dejaremos la configuración del Hardware y otras opciones para otro momento. Maestro contra esclavo Uno de los primeros desafíos para comprender cómo incorporar realmente el software en EMR es tener claro la infraestructura de hardware y software que admite EMR. En términos muy simples, solo hay 2 categorías: Master y Slave (Master + Slaves = Cluster). Map-Reduce es un modelo de programación que se beneficia de la capacidad de «divide para vencer», estableciendo cargas de trabajo para los múltiples nodos del clúster, distribuyendo y organizando las tareas de cada nodo para que un gran trabajo se convierta en pequeños trabajos múltiples, generalmente más fáciles y rápidos de realizar. completo en comparación con tratar de asumir el trabajo como una unidad completa. Modelo programático EMR En este modelo cada nodo recibe una carga de trabajo, para luego trabajar sobre ella, y finalmente entregar un resultado consolidado por el nodo maestro. Clúster EMR: Master Node y Slave Node trabajando juntos para resolver el trabajo de acuerdo con los algoritmos Map-Reduce. Para que todo esto funcione, el software incorporado en los nodos esclavos debe “corresponder” al software del nodo maestro, y así poder “hablar” correctamente durante la ejecución del trabajo del clúster. Cuando nos conectamos al clúster, normalmente lo que hacemos es conectarnos al nodo líder, ya través de este llevamos a cabo la ejecución de la obra. Es en este mismo nodo líder donde podemos tomar control remoto vía SSH, y realizar actividades a nivel de sistema operativo, como, por ejemplo, instalar nuevo software, o alterar la configuración del software ya instalado. Sin embargo, es fundamental tener en cuenta que el nodo líder no replica ni distribuye estas modificaciones al resto de nodos del clúster, por lo que si instalamos una nueva biblioteca, como Boto3, solo estará disponible en el nodo Líder, dejando a los nodos esclavos incapaces de abordar las tareas que requieren esta biblioteca, y luego cualquier trabajo que la requiera no se ejecutará. La lección que debemos aprender es muy simple: el software debe instalarse y configurarse ANTES de que exista el clúster. De lo contrario, los cambios de configuración y el software instalado solo estarán disponibles en el nodo maestro. ¿Cómo? Muy simple: con acciones de arranque. arranque Bueno, puede que no sea tan simple al principio, especialmente si no está acostumbrado a ejecutar scripts Bash en Linux. Sin embargo, ese es, en términos generales, el único desafío para comenzar a trabajar con EMR y Bootstrap Actions. Las acciones Bootstrap son esencialmente scripts Bash para Linux, que automatizan la ejecución de los pasos de instalación o la manipulación de la configuración del software instalado y del sistema operativo en general. Una supersimplificación del punto anterior es: cada paso que realizaría un humano con el mando de una consola de SSH en Linux, se lo puede llevar a una línea de un script de Bash, que se puede ejecutar de forma automática. , sin supervisión humana. Por ejemplo, para instalar Boto3: sudo pip install -U awscli boto Luego, se convierte en un script Bash. Llamaremos a este archivo install_boto3.sh: #!/bin/bash sudo pip install -U awscli boto Y finalmente lo guardamos en S3: s3://mi_bucket/scripts/install_boto3.sh Sencillo, ¿no? Ahora solo necesita hacer referencia a este script en una acción de Bootstrap desde la configuración durante la creación del clúster. Básicamente hay 2 opciones para hacer esto (hay más opciones para lanzar un clúster, pero estas son las más utilizadas): 1. Uso de la consola web Siguiendo las opciones avanzadas, en el paso 3 de la configuración durante la creación del clúster, abra la sección «Acciones de Bootstrap» Aparecerán las opciones para referenciar el script ya guardado en S3: Y finalmente solo queda lanzar la creación del clúster, siguiendo los pasos restantes de la configuración. 2. Uso de la CLI de AWS Esta opción es la más fácil de controlar y ejecutar. Requiere tener instalado y configurado correctamente AWS CLI con nuestra cuenta de AWS. Simplemente ejecute en nuestra CLI la siguiente línea de comandos: aws emr create-cluster –applications Name=Hadoop Name=Hive Name=Pig Name=Hue Name=Spark Name=Zeppelin –ec2-attributes ‘{«KeyName»:»mi_cluster»,»InstanceProfile»:»EMR_EC2_Profile»,» SubnetId»:»subnet-XXXXXXXXX»,»EmrManagedSlaveSecurityGroup»:»sg-XXXXXXXXX»,»EmrManagedMasterSecurityGroup»:»sg-XXXXXXXXX»}’ –release-label emr-5.12.0 –log-uri ‘s3n:// aws-logs-XXXXXXXXXXXXXXX-us-east-1/elasticmapreduce/’ –steps ‘[{«Args»:[«spark-submit»,»–deploy-mode»,»cluster»,»–driver-cores «,»1″,»–maximizeResourceAllocation»,»s3://mi_bucket/scripts/mi_script_python.py»],»Tipo»:»CUSTOM_JAR»,«ActionOnFailure»:»CANCEL_AND_WAIT»,»Jar»:»command-runner.jar»,»Properties»:»»,»Name»:»Mi Programa Spark»}]’ –instance-groups ‘[{«InstanceCount» :4,»EbsConfiguration»:{«EbsBlockDeviceConfigs»:[{«VolumeSpecification»:{«SizeInGB»:32,»VolumeType»:»gp2″},»VolumesPerInstance»:1}]},»InstanceGroupType»:»CORE» ,»InstanceType»: «r4.xlarge»,»Name»:»Core – 2″},{«InstanceCount»:1,»EbsConfiguration»:{«EbsBlockDeviceConfigs»:[{«VolumeSpecification»:{«SizeInGB»:32 ,»VolumeType»:»gp2″},»VolumesPerInstance»:1}]},»InstanceGroupType»:»MASTER»,»InstanceType»: «r4.xlarge»,»Name»:»Master – 1″}]’ –bootstrap-actions ‘[{«Path»:»s3://mi_bucket/scripts/install-boto3. sh»,»Name»:»Instalar Boto3″}]’ –ebs-root-volume-size 50 –service-role EMR_Role –enable-debugging–name ‘mi_aplicacion’ –scale-down-behavior TERMINATE_AT_TASK_COMPLETION –region us-east-1 Vale la pena señalar que este comando es una sola línea de texto , que se ha dividido aquí para facilitar la lectura. Hay parámetros que son opcionales (es decir  , –enable-debugging ) y otros que dependen de los recursos de infraestructura de su propia cuenta de AWS (es decir, ID de grupos de seguridad, nombres de perfiles de instancia como » EMR_EC2_Profile » y roles de servicio, como –service- rol EMR_Role , entre otros). Puede parecer un poco difícil de manejar al principio, pero en la práctica es la opción más fácil y rápida para lanzar un clúster, y con el tiempo es fácil acostumbrarse. 3. Recursos públicos Como no siempre somos los primeros en enfrentar un problema, la mayoría de las veces es posible encontrar a alguien que haya resuelto el problema antes que nosotros. Y una buena parte de esas veces, que alguien ha sido tan amable de poner la solución

Incorporando Acciones de Bootstrap en EMR – Amazon (AWS)

Dentro del conjunto de herramientas que AWS ofrece para Big Data, EMR es una de las más versátiles y potentes, poniendo a disposición del usuario un sinfín de opciones de hardware y software con el fin de enfrentar – con todo éxito- cualquier desafío relacionado con el procesamiento de grandes volúmenes de datos. Sin embargo, un usuario que se encuentra ante la consola de EMR por primera vez encuentra que las opciones se encuentran empaquetadas en una lista -generosa, pero limitada- de configuraciones de software y hardware, y quizás sacar la conclusión -errónea!- de que EMR no tiene lo necesario para la tarea. Consola Web: Creando un Cluster de EMR En este artículo nos enfocaremos en estudiar cómo incorporar elementos de software adicionales y/o distintos a los ofrecidos en el paquete de la consola Web, y dejaremos las configuraciones de Hardware y otras opciones para otra oportunidad. Líder contra Esclavo Uno de los primeros desafíos para entender cómo incorporar software a EMR es tener claridad acerca de la infraestructura de hardware y software que da soporte a EMR. En términos muy sencillos, existen simplemente dos categorías: Líder y Esclavo (Lider + Esclavos = Cluster). Map-Reduce es un modelo de programación que se beneficia de la capacidad de “dividir para conquistar”, utilizar cargas de trabajo para los múltiples nodos del clúster, distribuyendo y organizando las tareas de cada nodo de modo que un gran trabajo se vuelve múltiples trabajos pequeños, normalmente más fáciles y rápidos de completar comparados con intentar abordar el trabajo como una unidad. Modelo programático de EMR En este modelo cada nodo recibe una carga de trabajo, para trabajar luego en ella, y finalmente entrega un resultado que es consolidado por el nodo líder. Cluster EMR: Nodo Líder y Nodos Esclavos trabajan en conjunto para resolver el trabajo según algoritmos Map-Reduce Para que todo esto funcione, el software incorporado en los nodos esclavos debe estar “de acuerdo” con el software del nodo líder, y así poder “conversar” adecuadamente durante la ejecución del trabajo del clúster. Cuando nos conectamos al clúster, normalmente lo que hacemos es conectarnos al nodo líder, ya través de este llevamos a cabo la ejecución del trabajo. Es en este mismo nodo líder donde podemos tomar control remoto vía SSH, y realizar actividades a nivel de sistema operativo, como -por ejemplo- instalar nuevo software, o alterar la configuración del software ya instalado. Sin embargo, es imprescindible tener presente que el nodo líder no replica ni distribuye estas modificaciones al resto de los nodos del clúster, por lo que si instalamos una nueva librería -como por ejemplo Boto3- esta sólo estará disponible en el nodo Líder, dejando a los nodos Esclavos incapaces de abordar tareas que requieren de esta librería, y luego cualquier trabajo que la requiera fallará en ejecutarse. La lección que debemos sacar es muy sencilla: el software se debe instalar y configurar ANTES de que exista el clúster. De lo contrario, los cambios de configuración, y el software instalado, sólo estarán disponibles en el nodo Líder. ¿Cómo? Pues muy simple: con acciones de bootstrap. arranque Bueno, puede no resultar tan simple en un comienzo, especialmente si no están acostumbrados a realizar scripts de Bash en Linux. Sin embargo eso es, a grandes características, el único desafío para comenzar a trabajar con EMR y Acciones de Bootstrap. Las Acciones de Bootstrap son suficientes scripts de Bash para Linux, que automatizan la ejecución de pasos de instalación o manejo de configuración del software instalado y del sistema operativo en general. Una súper-simplificación de lo anterior es: cada paso que realizaría un humano al mando de una consola de SSH en Linux, es posible llevar a una línea de un script de Bash, que se puede ejecutar de forma automática, sin supervisión humana. Por ejemplo, para instalar Boto3: sudo pip install -U awscli boto Luego, esto se convierte en un script de Bash. Llamemos a este archivo install_boto3.sh: #!/bin/bash sudo pip install -U awscli boto Y finalmente lo guardamos en S3: s3://mi_bucket/scripts/install_boto3.sh Sencillo, ¿verdad?. Ahora sólo resta referenciar este script en una acción de Bootstrap desde la configuración durante la creación del clúster. Para esto, hay básicamente dos opciones (hay más opciones para lanzar un clúster, pero estas son las dos más utilizadas): 1. Uso de la consola Web Siguiendo las opciones avanzadas, en el paso 3 de la configuración durante la creación del clúster, abra la sección de Acciones de Bootstrap (Bootstrap Actions) Aparecerán las opciones para referenciar el guión que ya tenemos en S3: Y finalmente sólo resta lanzar la creación del clúster, continuando los pasos restantes de configuración. 2. Uso de la CLI de AWS Esta es la opción más fácil de controlar y ejecutar. Requiere tener la AWS CLI apropiadamente instalada y configurada con nuestra cuenta de AWS. Basta ejecutar con nuestro CLI la siguiente línea de comandos: aws emr create-cluster –applications Name=Hadoop Name=Hive Name=Pig Name=Hue Name=Spark Name=Zeppelin –ec2-attributes ‘{«KeyName»:»mi_cluster»,»InstanceProfile»:»EMR_EC2_Profile»,» SubnetId»:»subnet-XXXXXXXXX»,»EmrManagedSlaveSecurityGroup»:»sg-XXXXXXXXX»,»EmrManagedMasterSecurityGroup»:»sg-XXXXXXXXX»}’ –release-label emr-5.12.0 –log-uri ‘s3n:// aws-logs-XXXXXXXXXXXXXXX-us-east-1/elasticmapreduce/’ –steps ‘[{«Args»:[«spark-submit»,»–deploy-mode»,»cluster»,»–driver-cores «,»1″,»–maximizeResourceAllocation»,»s3://mi_bucket/scripts/mi_script_python.py»],»Tipo»:»CUSTOM_JAR», «ActionOnFailure»:»CANCEL_AND_WAIT»,»Jar»:»command-runner.jar»,»Properties»:»»,»Name»:»Mi Programa Spark»}]’ –instance-groups ‘[{«InstanceCount» :4,»EbsConfiguration»:{«EbsBlockDeviceConfigs»:[{«VolumeSpecification»:{«SizeInGB»:32,»VolumeType»:»gp2″},»VolumesPerInstance»:1}]},»InstanceGroupType»:»CORE» ,»InstanceType»: «r4.xlarge»,»Name»:»Core – 2″},{«InstanceCount»:1,»EbsConfiguration»:{«EbsBlockDeviceConfigs»:[{«VolumeSpecification»:{«SizeInGB»:32 ,»VolumeType»:»gp2″},»VolumesPerInstance»:1}]},»InstanceGroupType»:»MASTER»,»InstanceType»: «r4.xlarge»,»Name»:»Master – 1″}]’ –bootstrap-actions ‘[{«Path»:»s3://mi_bucket/scripts/install-boto3. sh»,»Name»:»Instalar Boto3″}]’ –ebs-root-volume-size 50 –service-role EMR_Role –enable-debugging –name ‘mi_aplicacion’ –scale-down-behavior TERMINATE_AT_TASK_COMPLETION –region us-east-1 Cabe resaltar que este comando es una sola línea de texto , que aquí hemos separado en varias líneas para facilitar la lectura. Hay varios parámetros que son opcionales (ej: –enable-debugging ) y otros que dependen de los recursos de infraestructura de su propia cuenta de AWS (ej: IDs de grupos de seguridad, nombres de perfiles de instancia como “ EMR_EC2_Profile ” y roles de servicio, como –service-role EMR_Role , entre otros). Puede parecer un tanto difícil de manejar al principio, pero en la práctica es la opción más fácil y rápida de lanzar un clúster, y con el tiempo es fácil acostumbrarse. 3. Recursos Públicos Como no siempre somos los primeros en enfrentar un problema, la mayoría de las veces es posible encontrar a alguien que haya resuelto el problema antes que nosotros. Y buena parte de esas veces, ese alguien ha

Mantenimiento Básico de Redshift – Amazon (AWS)

Dentro de los muchos factores que podrían afectar la facturación de Amazon Redshift en una cuenta de AWS, vale la pena mencionar: COPY Al cargar datos utilizando el comando COPY, Redshift se encargará de comprimir los datos de acuerdo a su tipo (en cada caso), lo que representa un ahorro de espacio, mejoras en las consultas, y posible reducción de los nodos requeridos. El siguiente comando, por ejemplo, carga un archivo existente en un bucket de S3, especificando las credenciales y la región: COPY VENTAS FROM ‘ruta_archivo_s3’ WITH CREDENTIALS ‘aws_access_key_id=XXX;aws_secret_access_key=YYY’ REGION ‘us-west-2’ IGNOREHEADER 1 CSV DELIMITER ‘,’ ;   VACUUM Debido a que Redshift no ‘recupera’ automáticamente el espacio de un registro borrado o actualizado, se debe ejecutar con cierta frecuencia el comando VACUUM para reordenar las tablas y así liberar cualquier espacio que no se esté utilizando. Lo anterior representa una mejora en el desempeño y, posiblemente, pueda reducir el número de nodos que se requieran para almacenar los datos. Sólo el propietario de la tabla (o un superusuario) podría ejecutar este comando con resultados efectivos. De lo contrario el comando se ejecuta, pero sin efecto alguno. Por ejemplo, con el siguiente comando se reordenan los registros de la tabla VENTAS sólo si menos del 75% de dichos registros están ya ordenados: vacuum sort only VENTAS to 75 percent;