Muchas organizaciones construyen lagos de datos en Servicio de almacenamiento simple de Amazon (Amazon S3) utilizando una arquitectura moderna para una solución escalable y rentable. Los formatos de almacenamiento de código abierto como Parquet y Avro se usan comúnmente, y los datos se almacenan en estos formatos como archivos inmutables. A medida que el lago de datos se expande a casos de uso adicionales, todavía hay algunos casos de uso que son muy difíciles con los lagos de datos, como CDC (cambio de captura de datos), viaje en el tiempo (consulta de datos de un punto en el tiempo), regulación de privacidad que requiere eliminación de datos, escrituras simultáneas y consistencia con respecto al manejo de problemas de archivos pequeños.

apache hudi es un marco de lago de datos transaccionales de código abierto que simplifica en gran medida el procesamiento de datos incrementales y la ingesta de datos de transmisión. Sin embargo, las organizaciones nuevas en los lagos de datos pueden tener dificultades para adoptar Apache Hudi debido a la falta de familiaridad con la tecnología y la falta de experiencia interna.

En esta publicación, mostramos cómo comenzar con Apache Hudi, centrándonos en el tipo de tabla Hudi CoW (Copy on Write) en AWS usando Pegamento AWSe implementar conceptos de diseño clave para diferentes casos de uso. Esperamos que los lectores tengan una comprensión básica de lagos de datos, AWS Glue y Amazon S3. Lo guiaremos a través de casos de uso comunes de ingesta de datos por lotes con resultados de pruebas reales usando un TPC-DS conjunto de datos para mostrar cómo las decisiones de diseño pueden influir en el resultado.

Conceptos clave de Apache Hudi

Antes de profundizar en los conceptos de diseño, repasemos los conceptos clave de Apache Hudi, que es importante comprender antes de tomar decisiones de diseño.

Tipos de consultas y tablas de Hudi

Hudi admite dos tipos de tablas: Copiar en escritura (Vaca) y fusionar en lectura (MoR). Debe elegir el tipo de tabla de antemano, lo que influye en el rendimiento de las operaciones de lectura y escritura.

La diferencia de rendimiento depende del volumen de datos, las operaciones, el tamaño del archivo y otros factores. Para obtener más información, consulte Tipos de tabla y consulta.

Cuando usa el tipo de tabla CoW, los datos comprometidos se compactan implícitamente, lo que significa que se actualizan al formato de archivo en columnas durante la operación de escritura. Con el tipo de tabla MoR, los datos no se compactan con cada confirmación. Como resultado, para el tipo de tabla MoR, los datos compactados viven en almacenamiento en columnas (Parquet) y los deltas se almacenan en un formato sin formato de registro (Avro) hasta que la combinación de compactación cambia los datos al formato de archivo en columnas. Hudi apoya consultas instantáneas, incrementales y optimizadas para lectura para las tablas de Hudi, y la salida del resultado depende del tipo de consulta.

Indexación

Indexación es otro concepto clave para el diseño. Hudi proporciona upserts y eliminaciones eficientes con indexación rápida para tablas CoW y MoR. Para las tablas de CoW, la indexación permite operaciones rápidas de inserción y eliminación al evitar la necesidad de unir el conjunto de datos completo para determinar qué archivos reescribir. Para MoR, este diseño permite a Hudi limitar la cantidad de registros con los que debe fusionarse cualquier archivo base dado. Específicamente, un archivo base determinado debe fusionarse solo con las actualizaciones de los registros que forman parte de ese archivo base. Por el contrario, los diseños sin un componente de indexación podrían terminar teniendo que fusionar todos los archivos base con todos los registros entrantes de actualización y eliminación.

Resumen de la solución

El siguiente diagrama describe la arquitectura de alto nivel para nuestra solución. Ingerimos el conjunto de datos TPC-DS (store_sales) del depósito S3 de origen en formato CSV y lo escribimos en el depósito S3 de destino utilizando AWS Glue en formato Hudi. Podemos consultar las tablas de Hudi en Amazon S3 usando Atenea amazónica y portátiles de AWS Glue Studio.

El siguiente diagrama ilustra las relaciones entre nuestras tablas.

Para nuestra publicación, usamos las siguientes tablas del conjunto de datos TPC-DS: una tabla de hechos, store_sales, y las tablas de dimensiones tienda, artículo y date_dim. La siguiente tabla resume los recuentos de filas de la tabla.

Configurar el entorno

Después de iniciar sesión en su cuenta de prueba de AWS, inicie el Formación en la nube de AWS plantilla eligiendo Pila de lanzamiento:

Esta plantilla configura los siguientes recursos:

• Empleos de AWS Glue hudi_bulk_insert, hudi_upsert_cowy hudi_bulk_insert_dim. Usamos estos trabajos para los casos de uso cubiertos en esta publicación.
• Se ejecuta un depósito de S3 para almacenar el resultado del trabajo de AWS Glue.
• Gestión de identidades y accesos de AWS (IAM) roles y políticas con los permisos adecuados.

Antes de ejecutar los trabajos de AWS Glue, debe suscribirse a AWS Glue Apache Hudi Connector (última versión: 0.10.1). El conector está disponible en AWS Marketplace. Siga el proceso de instalación y activación del conector desde el enlace de AWS Marketplace o consulte Procesar conjuntos de datos Apache Hudi, Delta Lake, Apache Iceberg a escala, parte 1: AWS Glue Studio Notebook para configurarlo

Después de crear la conexión de Hudi, agregue el nombre del conector a todos los scripts de AWS Glue en Propiedades avanzadas.

Trabajo de inserción masiva

Para ejecutar el trabajo de inserción masiva, elija el trabajo hudi_bulk_insert en la consola de AWS Glue.

Los parámetros de trabajo que se muestran en la siguiente captura de pantalla se agregan como parte de la configuración de la pila de CloudFormation. Puede usar diferentes valores para crear tablas particionadas CoW con diferentes opciones de inserción masiva.

Los parámetros son los siguientes:

• HUDI_DB_NOMBRE – La base de datos de AWS Glue Data Catalog donde se crea la tabla de catálogo.
• HUDI_INIT_SORT_OPTION – Las opciones de bulk_insert incluya GLOBAL_SORT, que es el predeterminado. Otras opciones incluyen NONE y PARTITION_SORT.
• HUDI_TABLE_NAME – El prefijo del nombre de la tabla que desea utilizar para identificar la tabla creada. En el código, agregamos la opción de clasificación al nombre que especifique en este parámetro.
• SALIDA_BUCKET – El depósito S3 creado a través de la pila de CloudFormation donde se escriben los conjuntos de datos de la tabla Hudi. El formato del nombre del depósito es . El nombre del depósito es el que se proporcionó al crear la pila de CloudFormation.
• CATEGORIA ID – El valor predeterminado para este parámetro es ALL, que procesa categorías de datos de prueba en un solo trabajo de AWS Glue. Para probar el paralelo en la misma tabla, cambie el valor del parámetro a una de las categorías 3, 5 u 8 para el conjunto de datos que usamos para cada trabajo de AWS Glue paralelo.

Trabajo upsert para la tabla CoW

Para ejecutar el trabajo upsert, elija el trabajo hudi_upsert_cow en la consola de AWS Glue.

Los siguientes parámetros de trabajo se agregan como parte de la configuración de la pila de CloudFormation. Puede ejecutar operaciones upsert y delete en tablas particionadas de CoW con diferentes opciones de inserción masiva en función de los valores proporcionados para estos parámetros.

• CUBO DE SALIDA – El mismo valor que el parámetro del trabajo anterior.
• HUDI_TABLE_NAME – El nombre de la tabla creada en su AWS Glue Data Catalog.
• HUDI_DB_NOMBRE – El mismo valor que el parámetro del trabajo anterior. El valor predeterminado es Predeterminado.

Trabajo de inserción masiva para las tablas de dimensiones

Para probar las consultas en las tablas CoW, la tabla de hechos que se crea usando la operación de inserción masiva necesita tablas dimensionales suplementarias. Este trabajo de AWS Glue debe ejecutarse antes de poder probar las consultas de TPC que se proporcionan más adelante en esta publicación. Para ejecutar este trabajo, elija hudi_bulk_insert_dim en la consola de AWS Glue y use los parámetros que se muestran en la siguiente captura de pantalla.

Los parámetros son los siguientes:

• CUBO DE SALIDA – El mismo valor que el parámetro del trabajo anterior.
• HUDI_INIT_SORT_OPTION – Las opciones de bulk_insert incluya GLOBAL_SORT, que es el predeterminado. Otras opciones disponibles son NONE y PARTITION_SORT.
• HUDI_DB_NOMBRE – El nombre de la base de datos de Hudi. Predeterminado es el valor predeterminado.

Consideraciones de diseño de Hudi

En esta sección, lo guiaremos a través de algunos casos de uso para demostrar la diferencia en el resultado para diferentes configuraciones y operaciones.

Caso de uso de migración de datos

En Apache Hudi, ingiere los datos en los tipos de tablas CoW o MoR mediante operaciones de inserción, upsert o inserción masiva. Las iniciativas de migración de datos a menudo implican cargas iniciales únicas en el almacén de datos de destino y recomendamos utilizar la operación de inserción masiva para las cargas iniciales.

La opción de inserción masiva proporciona la misma semántica que la inserción, al tiempo que implementa un algoritmo de escritura de datos basado en clasificación, que puede escalar muy bien para varios cientos de TB de carga inicial. Sin embargo, esto solo hace un mejor esfuerzo al dimensionar los archivos en lugar de garantizar el tamaño de los archivos, como lo hacen las inserciones y las inserciones. Además, las claves principales no se ordenan durante la inserción, por lo que no se recomienda utilizar la inserción durante la carga de datos inicial. De forma predeterminada, se crea un índice de Bloom para la tabla, lo que permite búsquedas más rápidas para las operaciones de modificación y eliminación.

La inserción masiva tiene las siguientes tres opciones de clasificación, que tienen diferentes resultados.

• CLASIFICACIÓN_GLOAL – Ordena la clave de registro para todo el conjunto de datos antes de escribir.
• PARTICIÓN_SORT – Se aplica solo a tablas particionadas. En esta opción, la clave de registro se ordena dentro de cada partición y el tiempo de inserción es más rápido que el orden predeterminado.
• NINGUNO – No ordena los datos antes de escribirlos.

Para probar la inserción masiva con las tres opciones de clasificación, utilizamos la siguiente configuración de trabajo de AWS Glue, que forma parte del script hudi_bulk_insert:

• Versión de pegamento de AWS: 3.0
• Tipo de trabajador de AWS Glue: G1.X
• Número de trabajadores de AWS Glue: 200
• Archivo de entrada: TPC-DS/2.13/1TB/store_sales
• Formato de archivo de entrada: CSV (TPC-DS)
• Número de archivos de entrada: 1,431
• Número de filas en el conjunto de datos de entrada: aproximadamente 2.8 millones

Los siguientes gráficos ilustran el comportamiento de las operaciones de inserción masiva con GLOBAL_SORT, PARTITION_SORTy NONE como opciones de clasificación para una tabla CoW. Las estadísticas de los gráficos se crean utilizando un promedio de 10 ejecuciones de operaciones de inserción masiva para cada opción de ordenación.

Debido a que la inserción masiva hace un trabajo de mejor esfuerzo para empaquetar los datos en archivos, verá una cantidad diferente de archivos creados con diferentes opciones de clasificación.

Podemos observar lo siguiente:

• Inserto a granel con GLOBAL_SORT tiene la menor cantidad de archivos, porque Hudi intentó crear archivos de tamaño óptimo. Sin embargo, toma la mayor parte del tiempo.
• Inserto a granel con NONE ya que la opción de clasificación tiene el tiempo de escritura más rápido, pero resultó en una mayor cantidad de archivos.
• Inserto a granel con PARTITION_SORT también tiene un tiempo de escritura más rápido en comparación con GLOBAL SORT, pero también da como resultado una mayor cantidad de archivos.

En base a estos resultados, aunque GLOBAL_SORT toma más tiempo ingerir los datos, crea una menor cantidad de archivos, lo que tiene un mejor rendimiento de lectura y upsert.

Los siguientes diagramas ilustran los planes de ejecución de Spark para el bulk_insert operación usando varias opciones de clasificación.

El primero muestra el plan de ejecución de Spark para bulk_insert cuando la opción de clasificación es PARTITION_SORT.

El siguiente es el plan de ejecución de Spark para bulk_insert cuando la opción de clasificación es NONE.

El último es el plan de ejecución de Spark para bulk_insert cuando la opción de clasificación es GLOBAL_SORT.

El plan Spark Run para bulk_insert GLOBAL_SORT implica arrastramiento de datos para crear archivos de tamaño óptimo. Para las otras dos opciones de clasificación, no se incluye la reorganización de datos. Como resultado, bulk_insert GLOBAL_SORT toma más tiempo en comparación con las otras opciones de clasificación.

Para probar la inserción masiva con varias opciones de datos de ordenación de inserción masiva en una tabla particionada, modifique el trabajo de Hudi AWS Glue (hudi_bulk_insert) parámetro --HUDI_INIT_SORT_OPTION.

Cambiamos el parámetro --HUDI_INIT_SORT_OPTION a PARTITION_SORT or NONE para probar la inserción masiva con diferentes opciones de clasificación de datos. Necesita ejecutar el trabajo hudi_bulk_insert_dim, que carga el resto de las tablas necesarias para probar las consultas SQL.

Ahora, mire la diferencia de rendimiento de consulta entre estas tres opciones. Para el tiempo de ejecución de consultas, ejecutamos dos consultas TPC-DS (q52.sql y q53.sql, como se muestra en los siguientes fragmentos de consulta) mediante una sesión interactiva con AWS Glue Studio Notebook con la siguiente configuración de notebook para comparar los resultados.

• Versión de pegamento de AWS: 3.0
• Tipo de trabajador de AWS Glue: G1.X
• Número de trabajadores de AWS Glue: 50

Antes de ejecutar las siguientes consultas, reemplace los nombres de las tablas en las consultas con las tablas que genera en su cuenta.
q52

SELECT
  dt.d_year,
  item.i_brand_id brand_id,
  item.i_brand brand,
  sum(ss_ext_sales_price) ext_price
FROM date_dim dt, store_sales, item
WHERE dt.d_date_sk = store_sales.ss_sold_date_sk
  AND store_sales.ss_item_sk = item.i_item_sk
  AND item.i_manager_id = 1
  AND dt.d_moy = 11
  AND dt.d_year = 2000
GROUP BY dt.d_year, item.i_brand, item.i_brand_id
ORDER BY dt.d_year, ext_price DESC, brand_id
LIMIT 100

SELECT *
FROM
  (SELECT
    i_manufact_id,
    sum(ss_sales_price) sum_sales,
    avg(sum(ss_sales_price))
    OVER (PARTITION BY i_manufact_id) avg_quarterly_sales
  FROM item, store_sales, date_dim, store
  WHERE ss_item_sk = i_item_sk AND
    ss_sold_date_sk = d_date_sk AND
    ss_store_sk = s_store_sk AND
    d_month_seq IN (1200, 1200 + 1, 1200 + 2, 1200 + 3, 1200 + 4, 1200 + 5, 1200 + 6,
                          1200 + 7, 1200 + 8, 1200 + 9, 1200 + 10, 1200 + 11) AND
    ((i_category IN ('Books', 'Children', 'Electronics') AND

Como se puede ver en el siguiente gráfico, el rendimiento de la GLOBAL_SORT la mesa supera NONE y PARTITION_SORT debido a una menor cantidad de archivos creados en la operación de inserción masiva.

Caso de uso de replicación en curso

Para la replicación continua, las actualizaciones y eliminaciones generalmente provienen de bases de datos transaccionales. Como viste en la sección anterior, la operación masiva con GLOBAL_SORT tomó más tiempo y la operación con NINGUNO tomó menos tiempo. Cuando anticipa un mayor volumen de actualizaciones y eliminaciones de forma continua, la opción de clasificación es fundamental para su rendimiento de escritura.

Para ilustrar la replicación en curso con las operaciones upsert y delete de Apache Hudi, probamos con la siguiente configuración:

• Versión de pegamento de AWS: 3.0
• Tipo de trabajador de AWS Glue: G1.X
• Número de trabajadores de AWS Glue: 100

Para probar las operaciones upsert y delete, usamos el store_sales CoW, que se creó utilizando la operación de inserción masiva en la sección anterior con las tres opciones de clasificación. Realizamos los siguientes cambios:

• Insertar datos en una nueva partición (mes 1 y año 2004) utilizando los datos existentes del mes 1 del año 2002 con una clave principal nueva; total de 32,164,890 registros
• Actualizar el ss_list_price columna por $1 para la partición existente (mes 1 y año 2003); total de 5,997,571 registros
• Eliminar los datos del mes 5 para el año 2001; total de 26,997,957 registros

El siguiente gráfico ilustra los tiempos de ejecución para la operación upsert para la tabla CoW con diferentes opciones de clasificación utilizadas durante la inserción masiva.

Como puede ver en la ejecución de prueba, el tiempo de ejecución de upsert es mayor para NONE y PARTITION_SORT Mesas de vaca. El índice Bloom, que se crea de forma predeterminada durante la operación de inserción masiva, permite una búsqueda más rápida de operaciones de inserción y eliminación.

Para probar las operaciones upsert y delete en una tabla CoW para tablas con diferentes opciones de clasificación de datos, modifique el trabajo de AWS Glue (hudi_upsert_cow) parámetro HUDI_TABLE_NAME a la tabla deseada, como se muestra en la siguiente captura de pantalla.

Para cargas de trabajo donde las actualizaciones se realizan en las particiones más recientes, un índice Bloom funciona bien. Para cargas de trabajo donde el volumen de actualización es menor pero las actualizaciones se distribuyen entre particiones, un índice simple es más eficiente. Puede especificar el tipo de índice al crear la tabla Hudi usando el parámetro hoodie.index.type. Tanto el índice Bloom como el índice simple imponen la unicidad de las claves de la tabla dentro de una partición. Si necesita claves únicas para toda la tabla, debe crear un índice Bloom global o un índice simple global basado en las cargas de trabajo de actualización.

Caso de uso de diseño particionado multiinquilino

En esta sección, cubrimos Concurrencia optimista Hudi usando un diseño de tabla de múltiples inquilinos, donde los datos de cada inquilino se almacenan en una partición de tabla separada. En un escenario del mundo real, puede encontrarse con la necesidad comercial de procesar diferentes datos de inquilinos simultáneamente, como un SLA estricto para que los datos estén disponibles para el consumo posterior lo más rápido posible. Sin la simultaneidad optimista de Hudi, no puede tener escrituras simultáneas en la misma tabla de Hudi. En tal escenario, puede acelerar las escrituras de datos utilizando la simultaneidad optimista de Hudi cuando cada trabajo opera en un conjunto de datos de tabla diferente. En nuestro diseño de tabla multiinquilino que utiliza la simultaneidad optimista de Hudi, puede ejecutar trabajos simultáneos, donde cada trabajo escribe datos en una partición de tabla separada.

Para AWS Glue, puede implementar la simultaneidad optimista de Hudi mediante un Amazon DynamoDB proveedor de bloqueo, que se introdujo con Apache Hudi 0.10.0. El script de inserción masiva inicial tiene todas las configuraciones necesarias para permitir escrituras múltiples. El rol que se utiliza para AWS Glue debe tener permisos de DynamoDB agregados para que funcione. Para obtener más información sobre el control de concurrencia y las alternativas para los proveedores de bloqueo, consulte Control de concurrencia.

Para simular escrituras simultáneas, suponemos que su arrendatario se basa en el campo de categoría del conjunto de datos de prueba de TPC DC y, en consecuencia, se divide en función del campo de identificación de categoría (i_category_id). Modifiquemos el script hudi_bulk_insert para ejecutar una carga inicial para diferentes categorías. Debe configurar su trabajo de AWS Glue para que se ejecute simultáneamente según el Simultaneidad máxima parámetro, ubicado en las propiedades avanzadas. Describimos los parámetros de configuración de Hudi que se necesitan en el apéndice al final de esta publicación.

El conjunto de datos de TPC-DS incluye datos de los años 1998–2003. Usamos i_catagory_id como la identificación del inquilino. La siguiente captura de pantalla muestra la distribución de datos para varios inquilinos (i_category_id). En nuestras pruebas, cargamos los datos para i_category_id valores 3, 5 y 8.

El trabajo de AWS Glue hudi_bulk_insert está diseñado para insertar datos en particiones específicas según el parámetro CATEGORY_ID. Si el trabajo de inserción masiva para tablas de dimensiones no se ejecuta antes de que necesite ejecutar el trabajo hudi_bulk_insert_dim, que carga el resto de las tablas necesarias para probar las consultas SQL.

Ahora ejecutamos tres trabajos simultáneos, cada uno con los valores respectivos 3, 5 y 8 para simular escrituras simultáneas para múltiples inquilinos. La siguiente captura de pantalla ilustra el parámetro de trabajo de AWS Glue para modificar para CATEGORY_ID.

Usamos la siguiente configuración de trabajo de AWS Glue para cada uno de los tres trabajos de AWS Glue paralelos:

• Versión de pegamento de AWS: 3.0
• Tipo de trabajador de AWS Glue: G1.X
• Número de trabajadores de AWS Glue: 100
• Archivo de entrada: TPC-DS/2.13/1TB/store_sales
• Formato de archivo de entrada: CSV (TPC-DS)

La siguiente captura de pantalla muestra que los tres trabajos simultáneos comenzaron aproximadamente al mismo tiempo para tres categorías, que cargaron 867 millones de filas (50.1 GB de datos) en el store_sales mesa. usamos el GLOBAL_SORT opción para los tres trabajos simultáneos de AWS Glue.

La siguiente captura de pantalla muestra los datos de la tabla Hudi donde los tres escritores simultáneos insertaron datos en diferentes particiones, que se ilustran con diferentes colores. Todos los trabajos de AWS Glue se ejecutaron en la zona horaria central de EE. UU. (UTC -5). los _hoodie_commit_time está en UTC.

Los primeros dos resultados resaltados en azul corresponden al trabajo de AWS Glue CATEGORY_ID = 3, cuya hora de inicio fue el 09/27/2022 21:23:39 EE. UU. CST (09/28/2022 02:23:39 UTC).

Los siguientes dos resultados resaltados en verde corresponden al trabajo de AWS Glue CATEGORY_ID = 8, cuya hora de inicio fue el 09/27/2022 21:23:50 EE. UU. CST (09/28/2022 02:23:50 UTC).

Los dos últimos resultados resaltados en verde corresponden al trabajo de AWS Glue CATEGORY_ID = 5, cuya hora de inicio fue el 09/27/2022 21:23:44 EE. UU. CST (09/28/2022 02:23:44 UTC).

Los datos de muestra de la tabla Hudi tienen _hoodie_commit_time valores correspondientes a los tiempos de ejecución del trabajo de AWS Glue.

Como puede ver, pudimos cargar datos en varias particiones de la misma tabla de Hudi al mismo tiempo usando la concurrencia optimista de Hudi.

Principales conclusiones

Como muestran los resultados, bulk_insert GLOBAL_SORT escala bien para cargar TB de datos en el proceso de carga inicial. Esta opción se recomienda para casos de uso que requieren cambios frecuentes después de una gran migración. Además, cuando el rendimiento de la consulta es crítico en su caso de uso, recomendamos el GLOBAL_SORT opción debido a la menor cantidad de archivos que se crean con esta opción.

PARTITION_SORT tiene un mejor rendimiento para la carga de datos en comparación con GLOBAL_SORT, pero genera una cantidad significativamente mayor de archivos, lo que afecta negativamente el rendimiento de las consultas. Puede usar esta opción cuando la consulta implica muchas uniones entre tablas particionadas en columnas de clave de registro.

La opción NINGUNO no ordena los datos, pero es útil cuando necesita el tiempo de carga inicial más rápido y requiere actualizaciones mínimas, con la capacidad adicional de admitir cambios de registro.

Limpiar

Cuando haya terminado con este ejercicio, complete los siguientes pasos para eliminar sus recursos y dejar de incurrir en costos:

1. En la consola de Amazon S3, vacíe los depósitos creados por la pila de CloudFormation.
2. En la consola de CloudFormation, seleccione su pila y elija Borrar.

Esto limpia todos los recursos creados por la pila.

Conclusión

En esta publicación, cubrimos algunos de los conceptos de Hudi que son importantes para las decisiones de diseño. Usamos AWS Glue y el conjunto de datos de TPC-DS para recopilar los resultados de diferentes casos de uso para compararlos. Puede aprender de los casos de uso cubiertos en esta publicación para tomar las decisiones de diseño clave, especialmente cuando se encuentra en la etapa inicial de adopción de Apache Hudi. Puede seguir los pasos de esta publicación para iniciar una prueba de concepto con AWS Glue y Apache Hudi.

Referencias

Apéndice

La siguiente tabla resume los parámetros de configuración de Hudi que se necesitan.

Acerca de los autores

Amit Maindola es un arquitecto de datos centrado en big data y análisis en Amazon Web Services. Ayuda a los clientes en su viaje de transformación digital y les permite crear soluciones analíticas basadas en la nube altamente escalables, sólidas y seguras en AWS para obtener información oportuna y tomar decisiones comerciales críticas.

Srinivas Kandi es Arquitecto de datos especializado en lago de datos y análisis en Amazon Web Services. Ayuda a los clientes a implementar soluciones de análisis de datos en AWS para habilitarlos con análisis prescriptivos y predictivos.

mitesh patel es Arquitecto Principal de Soluciones en AWS. Su principal área de profundidad es la modernización de aplicaciones y datos. Ayuda a los clientes a crear soluciones escalables, seguras y rentables en AWS.