0
197
VistasSolicitud de transmisión de datos con kinesis stream y firehose
Tengo un dilema de arquitectura para mi proyecto actual que es para el procesamiento casi en tiempo real de una gran cantidad de datos. Así que aquí hay un diagrama de la arquitectura actual:
Aquí hay una explicación de mi idea que me llevó a esa imagen:
Cuando la puerta de enlace API recibe una solicitud, se incluye en la transmisión (esto se debe a la naturaleza de mi aplicación: "dispara y olvida"). Así es como llegué a esa conclusión . Los datos de entrada se separan en fragmentos en función de una solicitud específica. atributo que me garantiza el orden correcto.
Luego tengo una lambda que se preocupa por validar la entrada y la detección de anomalías. Por lo tanto, es una abstracción que mantiene los datos limpios para la siguiente capa: el enriquecimiento de datos. Entonces, este lambda envía los datos a un kinesis firehose porque puede hacer una copia de seguridad de los datos "en bruto" (algo que definitivamente quiero tener) y también adjuntar un lambda de transformación que hará el enriquecimiento, por lo que no me importará guardar los datos en S3, saldrá de la caja. Así que todo va bien hasta el momento en que necesito un orden conservado de los datos recibidos (el enriquecedor está haciendo sesionización), que se pierde en el firehose, porque no hay separación de datos allí como en los flujos de kinesis.
Entonces, lo único en lo que podría pensar es en mover la sisionización en la primera lambda, lo que romperá mi abstracción, porque comenzará a preocuparse por el enriquecimiento de datos y el mayor inconveniente es que los datos de copia de seguridad tendrán datos enriquecidos, lo que también está rompiendo la arquitectura. Y todo esto sucede porque falta el concepto de fragmentación en la manguera de incendios.
Entonces, ¿alguien puede pensar en una solución a ese problema sin perder las funciones listas para usar que nos proporciona AWS?
1 Respuestas
Responde la pregunta0
Creo que la sesionización y el enriquecimiento de datos son dos abstracciones diferentes, deberán dividirse entre las lambdas.
Una sesión es un flujo de eventos estrictamente ordenado y limitado en el tiempo que está limitado por un propósito o tarea. Solo tiene esa información en la primera etapa lambda (de la categorización del flujo de Kinesis) y debe etiquetar los flujos con el contexto de la sesión en el origen y dónde se pueden delimitar las sesiones.
Si almacenar información de sesión en una copia de seguridad es un problema, puede ser que la definición de una sesión no esté bien especificada o esté sujeta a redefinición. Si las sesiones están sujetas a una futura refundición, los datos de la sesión ya calculados pueden ignorarse, siempre que se hayan registrado con suficiente detalle suficientes datos adicionales para informar los conceptos futuros impredecibles de las posibles sesiones.
El enriquecimiento adicional que proporciona el contexto comercial (también conocido como datos identificables externamente) debe procesar las sesiones de forma transaccional dentro de los límites registrados previamente.
Si las sesiones no son transaccionales a nivel empresarial, la definición de una sesión está sobre o subespecificada. Si ese es el caso, está fuera del negocio del procesamiento de secuencias y se encuentra en el procesamiento por lotes, donde deberá escalar el estado al número de posibles sesiones intercaladas simultáneas y sus duraciones máximas, consultando todo el corpus de eventos para dividir las sesiones de con suerte, duraciones de tiempo manejables.