La conciliación de cuentas es un paso importante para garantizar la integridad y precisión de los estados financieros. En concreto, las empresas deben conciliar balance cuentas que podrían contener errores significativos o materiales. Los contadores revisan cada cuenta en el libro mayor de cuentas y verifican que el saldo indicado esté completo y sea exacto. Cuando se encuentran discrepancias, los contadores investigan y toman las medidas correctivas adecuadas.

Como parte de la organización FinTech de Amazon, ofrecemos una plataforma de software que permite a los equipos de contabilidad internos de Amazon realizar conciliaciones de cuentas. Para optimizar el proceso de conciliación, estos usuarios requieren una transformación de alto rendimiento con la capacidad de escalar según demanda, así como la capacidad de procesar tamaños de archivos variables que van desde unos pocos MB hasta más de 100 GB. No siempre es posible colocar datos en una sola máquina o procesarlos con un solo programa en un período de tiempo razonable. Este cálculo debe realizarse lo suficientemente rápido para proporcionar servicios prácticos donde la lógica de programación y los detalles subyacentes (distribución de datos, tolerancia a fallas y programación) puedan separarse.

Podemos lograr estos cálculos simultáneos en múltiples máquinas o subprocesos de la misma función en grupos de elementos de un conjunto de datos mediante el uso de soluciones de procesamiento de datos distribuidos. Esto nos animó a reinventar nuestro servicio de conciliación impulsado por los servicios de AWS, incluidos EMR de Amazon y del Apache Spark marco de procesamiento distribuido, que utiliza PySpark. Este servicio permite a los usuarios procesar archivos de más de 100 GB que contienen hasta 100 millones de transacciones en menos de 30 minutos. El servicio de conciliación se ha convertido en una potencia para el procesamiento de datos y ahora los usuarios pueden realizar sin problemas una variedad de operaciones, como Pivot, SUSCRÍBETE (como una operación BUSCARV de Excel), aritmética operaciones, y más, , proporcionando una solución versátil y eficiente para conciliar grandes conjuntos de datos. Esta mejora es un testimonio de la escalabilidad y velocidad logradas mediante la adopción de soluciones de procesamiento de datos distribuidos.

En esta publicación, explicamos cómo integramos Amazon EMR para construir un sistema escalable y de alta disponibilidad que nos permitió ejecutar un proceso de conciliación financiera de gran volumen.

Arquitectura antes de la migración

El siguiente diagrama ilustra nuestra arquitectura anterior.

Nuestro servicio heredado fue construido con Servicio de contenedor elástico de Amazon (Amazon ECS) en AWS Fargate. Procesamos los datos secuencialmente usando Python. Sin embargo, debido a su falta de capacidad de procesamiento paralelo, con frecuencia teníamos que aumentar el tamaño del clúster verticalmente para admitir conjuntos de datos más grandes. En contexto, 5 GB de datos con 50 operaciones tardaron alrededor de 3 horas en procesarse. Este servicio se configuró para escalar horizontalmente a cinco instancias de ECS que sondearon mensajes de Servicio de cola simple de Amazon (Amazon SQS), que alimentó las solicitudes de transformación. Cada instancia se configuró con 4 vCPU y 30 GB de memoria para permitir el escalado horizontal. Sin embargo, no pudimos ampliar su capacidad de rendimiento porque el proceso se produjo de forma secuencial, seleccionando fragmentos de datos de Servicio de almacenamiento simple de Amazon (Amazon S3) para su procesamiento. Por ejemplo, una operación BUSCARV en la que se van a unir dos archivos requirió que ambos archivos se leyeran en la memoria fragmento por fragmento para obtener el resultado. Esto se convirtió en un obstáculo para los usuarios porque tenían que esperar largos períodos de tiempo para procesar sus conjuntos de datos.

Como parte de nuestra reestructuración y modernización, queríamos lograr lo siguiente:

• Alta disponibilidad – Los clústeres de procesamiento de datos deben tener alta disponibilidad, proporcionando tres 9 de disponibilidad (99.9%)
• rendimiento – El servicio debería gestionar 1,500 recorridos por día.
• Estado latente – Debería poder procesar 100 GB de datos en 30 minutos
• Heterogeneidad – El clúster debería poder soportar una amplia variedad de cargas de trabajo, con archivos que van desde unos pocos MB hasta cientos de GB.
• Consulta de simultaneidad – La implementación exige la capacidad de soportar un mínimo de 10 grados de concurrencia.
• Fiabilidad de los trabajos y coherencia de los datos. – Los trabajos deben ejecutarse de manera confiable y consistente para evitar romper los acuerdos de nivel de servicio (SLA)
• Rentable y escalable – Debe ser escalable en función de la carga de trabajo, haciéndolo rentable
• Seguridad y cumplimiento – Dada la sensibilidad de los datos, debe admitir un control de acceso detallado e implementaciones de seguridad adecuadas.
• Monitoreo – La solución debe ofrecer monitoreo de extremo a extremo de los clústeres y trabajos.

Por qué Amazon EMR

Amazon EMR es la solución de big data en la nube líder en la industria para procesamiento de datos a escala de petabytes, análisis interactivos y aprendizaje automático (ML) utilizando marcos de código abierto como Apache Spark, Colmena Apachey presto. Con estos marcos y proyectos de código abierto relacionados, puede procesar datos con fines analíticos y cargas de trabajo de BI. Amazon EMR le permite transformar y mover grandes cantidades de datos dentro y fuera de otros almacenes de datos y bases de datos de AWS, como Amazon S3 y Amazon DynamoDB.

Una ventaja notable de Amazon EMR radica en su uso eficaz del procesamiento paralelo con PySpark, lo que marca una mejora significativa con respecto al código Python secuencial tradicional. Este enfoque innovador agiliza la implementación y el escalado de los clústeres de Apache Spark, lo que permite una paralelización eficiente en grandes conjuntos de datos. La infraestructura informática distribuida no sólo mejora el rendimiento, sino que también permite el procesamiento de grandes cantidades de datos a velocidades sin precedentes. Equipado con bibliotecas, PySpark facilita operaciones similares a Excel en marcos de datos, y la abstracción de nivel superior de DataFrames simplifica las manipulaciones de datos complejas, lo que reduce la complejidad del código. Combinado con el aprovisionamiento automático de clústeres, la asignación dinámica de recursos y la integración con otros servicios de AWS, Amazon EMR demuestra ser una solución versátil adecuada para diversas cargas de trabajo, que van desde el procesamiento por lotes hasta el aprendizaje automático. La tolerancia a fallas inherente en PySpark y Amazon EMR promueve la solidez, incluso en caso de fallas en los nodos, lo que la convierte en una opción escalable, rentable y de alto rendimiento para el procesamiento de datos paralelo en AWS.

Amazon EMR amplía sus capacidades más allá de lo básico, ofreciendo una variedad de opciones de implementación para satisfacer diversas necesidades. Ya sea Amazon EMR en EC2, Amazon EMR en EKS, Amazon EMR sin servidoro Amazon EMR en puestos avanzados de AWS, puede adaptar su enfoque a requisitos específicos. Para aquellos que buscan un entorno sin servidor para trabajos Spark, la integración Pegamento AWS También es una opción viable. Además de admitir varios marcos de código abierto, incluido Spark, Amazon EMR brinda flexibilidad para elegir modos de implementación. Nube informática elástica de Amazon (Amazon EC2) tipos de instancias, mecanismos de escalado y numerosas técnicas de optimización para ahorrar costos.

Amazon EMR se erige como una fuerza dinámica en la nube, que ofrece capacidades inigualables para las organizaciones que buscan soluciones sólidas de big data. Su integración perfecta, sus potentes funciones y su adaptabilidad la convierten en una herramienta indispensable para navegar por las complejidades del análisis de datos y el aprendizaje automático en AWS.

Arquitectura rediseñada

El siguiente diagrama ilustra nuestra arquitectura rediseñada.

La solución opera bajo un contrato API, donde los clientes pueden enviar configuraciones de transformación, definiendo el conjunto de operaciones junto con la ubicación del conjunto de datos S3 para su procesamiento. La solicitud se pone en cola a través de Amazon SQS y luego se dirige a Amazon EMR mediante una función Lambda. Este proceso inicia la creación de un paso de Amazon EMR para la implementación del marco Spark en un clúster de EMR dedicado. Aunque Amazon EMR admite una cantidad ilimitada de pasos durante la vida útil de un clúster de larga duración, solo pueden estar en ejecución o pendientes 256 pasos simultáneamente. Para una paralelización óptima, la simultaneidad de pasos se establece en 10, lo que permite que se ejecuten 10 pasos simultáneamente. En caso de errores en la solicitud, Amazon SQS cola de mensajes fallidos (DLQ) conserva el evento. Spark procesa la solicitud y traduce operaciones similares a Excel al código PySpark para un plan de consulta eficiente. Los Resilient DataFrames almacenan datos de entrada, salida y datos intermedios en la memoria, optimizando la velocidad de procesamiento, reduciendo el costo de E/S del disco, mejorando el rendimiento de la carga de trabajo y entregando el resultado final a la ubicación especificada de Amazon S3.

Definimos nuestro SLA en dos dimensiones: latencia y rendimiento. La latencia se define como la cantidad de tiempo necesaria para realizar un trabajo frente a un tamaño de conjunto de datos determinista y la cantidad de operaciones realizadas en el conjunto de datos. El rendimiento se define como la cantidad máxima de trabajos simultáneos que el servicio puede realizar sin violar el SLA de latencia de un trabajo. El SLA de escalabilidad general del servicio depende del equilibrio entre el escalamiento horizontal de los recursos informáticos elásticos y el escalamiento vertical de los servidores individuales.

Debido a que teníamos que ejecutar 1,500 procesos por día con una latencia mínima y un alto rendimiento, elegimos integrar Amazon EMR en el modo de implementación EC2 con el escalado administrado habilitado para admitir el procesamiento de tamaños de archivos variables.

La configuración del clúster EMR proporciona muchas selecciones diferentes:

• Tipos de nodos EMR – Nodos primarios, centrales o de tareas
• Opciones de compra de instancias – Instancias bajo demanda, instancias reservadas o instancias puntuales
• Opciones de configuración – Flota de instancias de EMR o grupo de instancias uniforme
• Opciones de escala – Escalado automático o escalado administrado por Amazon EMR

Según nuestra carga de trabajo variable, configuramos una flota de instancias de EMR (para conocer las mejores prácticas, consulte Fiabilidad). También decidimos utilizar el escalado administrado de Amazon EMR para escalar los nodos centrales y de tareas (para escenarios de escalamiento, consulte Escenarios de asignación de nodos). Por último, elegimos optimizado para memoria Gravitón de AWS instancias, que proporcionan hasta Un 30 % menos de costos y hasta un 15 % de rendimiento mejorado para cargas de trabajo de Spark.

El siguiente código proporciona una instantánea de la configuración de nuestro clúster:

Concurrent steps:10

EMR Managed Scaling:
minimumCapacityUnits: 64
maximumCapacityUnits: 512
maximumOnDemandCapacityUnits: 512
maximumCoreCapacityUnits: 512

Master Instance Fleet:
r6g.xlarge
- 4 vCore, 30.5 GiB memory, EBS only storage
- EBS Storage:250 GiB
- Maximum Spot price: 100 % of On-demand price
- Each instance counts as 1 units
r6g.2xlarge
- 8 vCore, 61 GiB memory, EBS only storage
- EBS Storage:250 GiB
- Maximum Spot price: 100 % of On-demand price
- Each instance counts as 1 units

Core Instance Fleet:
r6g.2xlarge
- 8 vCore, 61 GiB memory, EBS only storage
- EBS Storage:100 GiB
- Maximum Spot price: 100 % of On-demand price
- Each instance counts as 8 units
r6g.4xlarge
- 16 vCore, 122 GiB memory, EBS only storage
- EBS Storage:100 GiB
- Maximum Spot price: 100 % of On-demand price
- Each instance counts as 16 units

Task Instances:
r6g.2xlarge
- 8 vCore, 61 GiB memory, EBS only storage
- EBS Storage:100 GiB
- Maximum Spot price: 100 % of On-demand price
- Each instance counts as 8 units
r6g.4xlarge
- 16 vCore, 122 GiB memory, EBS only storage
- EBS Storage:100 GiB
- Maximum Spot price: 100 % of On-demand price
- Each instance counts as 16 units

Rendimiento

Con nuestra migración a Amazon EMR, pudimos lograr un rendimiento del sistema capaz de manejar una variedad de conjuntos de datos, desde 273 B hasta 88.5 GB con una p99 de 491 segundos (aproximadamente 8 minutos).

La siguiente figura ilustra la variedad de tamaños de archivos procesados.

La siguiente figura muestra nuestra latencia.

Para comparar con el procesamiento secuencial, tomamos dos conjuntos de datos que contienen 53 millones de registros y ejecutamos una operación BUSCARV entre sí, junto con otras 49 operaciones similares a Excel. Esto tomó 26 minutos para procesarse en el nuevo servicio, en comparación con 5 días para procesarse en el servicio heredado. Esta mejora es casi 300 veces mayor respecto a la arquitectura anterior en términos de rendimiento.

Consideraciones

Tenga en cuenta lo siguiente al considerar esta solución:

• Clústeres de tamaño adecuado – Aunque se puede cambiar el tamaño de Amazon EMR, es importante ajustar el tamaño correcto de los clústeres. El tamaño correcto mitiga un clúster lento, si es de tamaño insuficiente, o costos más altos, si el clúster está sobredimensionado. Para anticiparse a estos problemas, puede calcular la cantidad y el tipo de nodos que se necesitarán para las cargas de trabajo.
• Pasos paralelos – La ejecución de pasos en paralelo le permite ejecutar cargas de trabajo más avanzadas, aumentar la utilización de recursos del clúster y reducir la cantidad de tiempo necesario para completar su carga de trabajo. La cantidad de pasos que se permite ejecutar a la vez es configurable y se puede establecer cuando se inicia un clúster y en cualquier momento después de que se haya iniciado. Debe considerar y optimizar el uso de CPU/memoria por trabajo cuando se ejecutan varios trabajos en un único clúster compartido.
• Clústeres de EMR transitorios basados ​​en trabajos – Si corresponde, se recomienda utilizar un clúster EMR transitorio basado en trabajos, que ofrece un aislamiento superior y verifica que cada tarea funcione dentro de su entorno dedicado. Este enfoque optimiza la utilización de recursos, ayuda a prevenir interferencias entre trabajos y mejora el rendimiento y la confiabilidad generales. La naturaleza transitoria permite un escalamiento eficiente, proporcionando una solución sólida y aislada para diversas necesidades de procesamiento de datos.
• EMR sin servidor – EMR Serverless es la opción ideal si prefiere no encargarse de la gestión y operación de clústeres. Le permite ejecutar aplicaciones sin esfuerzo utilizando marcos de código abierto disponibles en EMR Serverless, ofreciendo una experiencia sencilla y sin complicaciones.
• Amazon EMR en EKS – Amazon EMR en EKS ofrece distintas ventajas, como tiempos de inicio más rápidos y una escalabilidad mejorada que resuelve los desafíos de capacidad informática, lo que es particularmente beneficioso para los usuarios de Graviton y Spot Instance. La inclusión de una gama más amplia de tipos de computación mejora la rentabilidad, permitiendo una asignación de recursos personalizada. Además, la compatibilidad con Multi-AZ proporciona una mayor disponibilidad. Estas atractivas características brindan una solución sólida para administrar cargas de trabajo de big data con rendimiento mejorado, optimización de costos y confiabilidad en varios escenarios informáticos.

Conclusión

En esta publicación, explicamos cómo Amazon optimizó su proceso de conciliación financiera de gran volumen con Amazon EMR para lograr una mayor escalabilidad y rendimiento. Si tiene una aplicación monolítica que depende del escalamiento vertical para procesar solicitudes o conjuntos de datos adicionales, migrarla a un marco de procesamiento distribuido como Apache Spark y elegir un servicio administrado como Amazon EMR para computación puede ayudar a reducir el tiempo de ejecución para reducir su entrega. SLA y también puede ayudar a reducir el costo total de propiedad (TCO).

A medida que adoptamos Amazon EMR para este caso de uso particular, lo alentamos a explorar más posibilidades en su viaje de innovación de datos. Considere evaluar AWS Glue, junto con otras opciones de implementación dinámica de Amazon EMR, como EMR Serverless o Amazon EMR en EKS, para descubrir el mejor servicio de AWS adaptado a su caso de uso exclusivo. El futuro del viaje de innovación de datos presenta posibilidades y avances interesantes que se explorarán más a fondo.

Acerca de los autores

Jeeshan Khetrapal es ingeniero sénior de desarrollo de software en Amazon, donde desarrolla productos fintech basados ​​en arquitecturas sin servidor de computación en la nube que son responsables de los controles generales de TI, los informes financieros y la contraloría de gobernanza, riesgo y cumplimiento de las empresas.

Sakti Mishra es arquitecto principal de soluciones en AWS, donde ayuda a los clientes a modernizar su arquitectura de datos y definir su estrategia de datos de un extremo a otro, incluida la seguridad de los datos, la accesibilidad, la gobernanza y más. También es el autor del libro. Simplifique el análisis de Big Data con Amazon EMR. Fuera del trabajo, a Sakti le gusta aprender nuevas tecnologías, ver películas y visitar lugares con la familia.

• Distribución de relaciones públicas y contenido potenciado por SEO. Consiga amplificado hoy.
• PlatoData.Network Vertical Generativo Ai. Empodérate. Accede Aquí.
• PlatoAiStream. Inteligencia Web3. Conocimiento amplificado. Accede Aquí.
• PlatoESG. Carbón, tecnología limpia, Energía, Ambiente, Solar, Gestión de residuos. Accede Aquí.
• PlatoSalud. Inteligencia en Biotecnología y Ensayos Clínicos. Accede Aquí.
• Fuente: https://aws.amazon.com/blogs/big-data/how-amazon-optimized-its-high-volume-financial-reconciliation-process-with-amazon-emr-for-higher-scalability-and-performance/