Soy relativamente nuevo en AWS y estoy trabajando en estrategias que mejor respalden un requisito comercial específico del servicio que estamos desarrollando.
Entre nuestros retos:
Nuestro objetivo es mantener estos datos separados de nuestra base de datos principal, de modo que podamos administrarlos y consultarlos de forma independiente según sea necesario. Como tal, la estrategia que hemos estado considerando es:
Sin embargo, aquí tenemos algunos problemas:
No estoy seguro de si esto debería dividirse en tres preguntas, pero esta parece ser la mejor manera de proporcionar el contexto completo.
Algunos comentarios.
Necesitamos extraer un conjunto de datos muy grande (cientos de miles de registros) de una API de terceros, que entrega registros paginados en grupos máximos de 50;
Eso significa alrededor de "miles" de llamadas a la API de terceros. En otra parte de la pregunta mencionas "varias horas". ¿Esta carga está bien con el proveedor con esa API? Solo una cosa a considerar, en caso de que no lo hayas hecho.
Hacer las llamadas a la API en una función lambda recursiva (debido a la paginación);
Tenga mucho cuidado con las llamadas de función Lambda recursivas, es decir, una función Lambda que se invoca a sí misma de forma asincrónica. Puede suceder que debido a un error, Lambda nunca deje de llamarse a sí mismo, y luego entre en bucles interminables de Lambda Calls y cargos crecientes... Se puede detener, pero es un PITA.
Almacenar los resultados de la llamada en un depósito S3 como archivos json únicos o múltiples;
Si desea utilizar S3, probablemente sugiera almacenar los datos agregados en menos archivos. No mencionó el tamaño de cada pieza de datos, pero toneladas de archivos diminutos no son ideales para S3. Por otro lado, un solo gigante (por ejemplo, decenas o cientos de GB o más) no es ideal para el procesamiento posterior (aunque S3 lo manejaría sin ningún problema).
Dos cosas que te sugiero que investigues:
Dado que deberá lidiar con la paginación de la API de terceros, puede definir una máquina de estado en Step Functions que invocará su Lambda por usted. Lambda hará lo suyo (descargará un montón de registros, los almacenará en algún lugar ) y devolverá la cantidad de registros descargados o la cantidad de registros pendientes, algo así. Luego, la máquina de estado de las funciones de paso será responsable de la lógica de decidir si llamar a Download Lambda nuevamente (tal vez incluso con parámetros basados en el valor devuelto por la llamada anterior) o si se hace.
De esta manera, tiene una buena separación de preocupaciones: una función Lambda súper específica, solo ingiere cosas; y separa la lógica de paginación (y tal vez incluso la lógica de "paralelismo" o "tiempo", si por alguna razón se le pide que "reduzca la velocidad" de sus llamadas a la API de terceros).
Kinesis Firehose es una canalización de transmisión de datos. Básicamente, usted configura un flujo de firehose para agregar registros por usted y volcarlos "en algún lugar" (S3 es un objetivo válido, por ejemplo). Tú eliges cómo quieres agregar (tiempo, volumen de datos, por ejemplo). E incluso puede configurar Firehose para invocar una función Lambda para transformar cada registro por usted antes del almacenamiento (aquí es donde podría, por ejemplo, agregar sus 2 identificadores únicos).
Con respecto a la importación de datos, puede crear un bucle con AWS Step Functions para recuperar los datos secuencialmente. Eche un vistazo a esta publicación de blog: https://read.acloud.guru/processing-an-arbitrary-number-of-jobs-with-aws-step-functions-c185c2d2608
Sus otras dos preguntas (asignación de claves y enriquecimiento y actualizaciones posteriores) necesitan más contexto y el mundo probablemente sea mejor si se publican como preguntas separadas.