{"id":15634,"date":"2023-10-04T14:12:51","date_gmt":"2023-10-04T14:12:51","guid":{"rendered":"https:\/\/beta.bluetab.net\/?p=15634"},"modified":"2024-03-05T17:34:33","modified_gmt":"2024-03-05T17:34:33","slug":"lakehouse-streaming-en-aws-con-apache-flink-y-hudi-parte-2","status":"publish","type":"post","link":"https:\/\/bluetab.es\/es\/lakehouse-streaming-en-aws-con-apache-flink-y-hudi-parte-2\/","title":{"rendered":"LakeHouse Streaming en AWS con Apache Flink y Hudi (Parte 2)"},"content":{"rendered":"\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

LakeHouse Streaming en AWS con Apache Flink y Hudi (Parte 2)<\/h1>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t
\"\"<\/a><\/figure>

Alberto Jaen<\/a><\/h4>

AWS Cloud Engineer <\/p><\/div><\/div>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t

\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t
\"\"<\/a><\/figure>

Alfonso Jerez<\/a><\/h4>

AWS Cloud Engineer <\/p><\/div><\/div>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t

\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t
\"\"<\/a><\/figure>

Adri\u00e1n Jim\u00e9nez<\/a><\/h4>

AWS Cloud Engineer <\/p><\/div><\/div>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t

\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t<\/i>\t\t\t\t\t\t\t<\/span>\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t<\/i>\t\t\t\t\t\t\t<\/span>\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

Introducci\u00f3n<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Este art\u00edculo es el segundo en una serie de publicaciones que se centran en la <\/span>creaci\u00f3n de un LakeHouse con Hudi<\/b> a partir de una ingesta en streaming procesada por una aplicaci\u00f3n Flink. <\/span>El primer art\u00edculo<\/span><\/a> se centra en sentar una buena base para esta plataforma, donde se desplegaron unas aplicaciones Flink con KDA (Kinesis Data Analytics) para cada tipo de formato (MoR, CoW para Hudi y JSON) que escriben el resultado de este procesamiento en unos <\/span>buckets<\/span><\/i>.<\/span><\/p>

El env\u00edo de datos que se utiliza como <\/span>input<\/span><\/i> se mandaba en el anterior art\u00edculo desde una m\u00e1quina en local ejecutando una aplicaci\u00f3n de Locust, lo que puede presentar problemas a la hora de escalar y querer procesar un volumen alto de eventos. Adem\u00e1s, las aplicaciones de Kinesis Data Analytics con Flink presentan problemas de agilidad en su modo de autoescalado. Todos estos nuevos retos ser\u00e1n resueltos en este art\u00edculo.<\/span><\/p>

Tambi\u00e9n se catalogar\u00e1n estas tablas en Glue, servicio que disponibiliza un cat\u00e1logo de datos en AWS, para poder acceder a estos y as\u00ed realizar <\/span>queries<\/span><\/i> de todo tipo. Como motor de <\/span>queries <\/span><\/i>que consumir\u00e1 estos metadatos se utilizar\u00e1 Athena, que proporciona una experiencia escalable, \u00e1gil y <\/span>serverless<\/span><\/i> para poder ejecutar <\/span>queries<\/span><\/i> con SQL o Spark para nuestras tablas alojadas en S3.<\/span><\/p>

Por otro lado, <\/span>en este art\u00edculo tambi\u00e9n se han desplegado los componentes necesarios para poder monitorizar nuestras aplicaciones<\/b> y extraer as\u00ed conclusiones sobre la velocidad a la que se ingestan los datos y los posibles problemas a resolver para que el procesamiento tenga la latencia requerida seg\u00fan los requisitos que se impongan.<\/span><\/p>

Finalmente se realizar\u00e1 una <\/span>comparativa en cuanto a rendimiento y latencia de las diferentes aplicaciones de Flink<\/b> que escriben datos en los formatos de Hudi y JSON para as\u00ed poder ver las diferentes ventajas e inconvenientes de estos formatos.\u00a0<\/span><\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t

Arquitectura\n<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

A continuaci\u00f3n se puede ver la arquitectura a alto nivel que se desplegar\u00e1:<\/span><\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Para un mayor entendimiento vamos a explicarla de izquierda a derecha. Como se puede observar, el cambio m\u00e1s rese\u00f1able con respecto al primer art\u00edculo es la <\/span>inclusi\u00f3n de un cluster de Kubernetes<\/b> para poder escalar los eventos que ser\u00e1n mandados como <\/span>input <\/span><\/i>de nuestra aplicaci\u00f3n de <\/span>streaming<\/span><\/i>. De esta manera se podr\u00e1 testear de manera exhaustiva el rendimiento de las aplicaciones de Flink dependiendo de su aprovisionamiento y sobre todo del tipo de formato y tabla en el que escriben al LakeHouse. Adem\u00e1s, se ha disponibilizado un ALB (Application Load Balancer) que permite acceder a la interfaz de Locust para poder definir el n\u00famero de usuarios a simular y c\u00f3mo deben escalar estos con el tiempo. La URL para acceder a esta aparecer\u00e1 como <\/span>output <\/span><\/i>al desplegar la infraestructura con Terraform.<\/span><\/p>

Por otro lado se han realizado <\/span>cambios rese\u00f1ables en las aplicaciones KDA de Flink y el <\/b>stream <\/i><\/b>del que leen estas. Cada aplicaci\u00f3n lee ahora como consumidores EFO (Enhanced Fan Out), de tal manera que cada una de ellas tiene un ancho de banda dedicado. La raz\u00f3n de este cambio y sus detalles ser\u00e1n explicados m\u00e1s en detalle en el apartado dedicado para Kinesis.<\/span><\/p>

En cuanto a la monitorizaci\u00f3n y la extracci\u00f3n de m\u00e9tricas en NRT (Near Real Time) se han desplegado unas funciones lambdas que acceden a las tablas apoy\u00e1ndose en Athena gracias a haber registrado los metadatos de estas en el cat\u00e1logo de Glue. Es importante resaltar que los metadatos de las tablas de Hudi son registrados en Glue por Flink pero en el caso de JSON se despliega un <\/span>crawler <\/span><\/i>que registra estas tablas en el cat\u00e1logo. Este crawler se debe ejecutar manualmente para que esta tabla quede registrada en Glue.<\/span><\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t

Escalado<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Kinesis Stream<\/span><\/h3>

Dado que el objetivo es someter la aplicaci\u00f3n a una carga considerable de eventos por segundo, es necesario explicar c\u00f3mo cada una de las piezas de la arquitectura pueden escalar de acuerdo al volumen de datos.<\/span><\/p>

Como hemos comentado previamente, se ha optado por un Kinesis Stream <\/span>On-Demand<\/span><\/i> para automatizar el escalado de los <\/span>shards<\/span><\/i> durante las pruebas de carga. Es necesario tener en cuenta que estos <\/span>streams<\/span><\/i> pueden acomodar una tasa de escritura de hasta el 200% de lo especificado por el n\u00famero de <\/span>shards<\/span><\/i> en un momento dado.<\/span><\/p>

Una vez que el <\/span>stream<\/span><\/i> se encuentra por encima del 100%, aumentar\u00e1 autom\u00e1ticamente el n\u00famero de <\/span>shards<\/span><\/i> en un plazo de 15 minutos. La \u00fanica limitaci\u00f3n por tanto es no superar el doble del volumen de escritura admitido en menos de dicho periodo.<\/span><\/p>

Por otro lado, dado que se tendr\u00e1n tres aplicaciones de Flink leyendo del mismo <\/span>stream<\/span><\/i>, las limitaciones a nivel de lectura ser\u00e1n el mayor problema. Un Kinesis Stream solo admite 5 llamadas <\/span>GetRecord<\/span><\/i> por <\/span>shard <\/span><\/i>por segundo. Dado que cada aplicaci\u00f3n tiene que leer todo el <\/span>stream<\/span><\/i> (y por lo tanto, todos los <\/span>shards<\/span><\/i>), aumentar el n\u00famero de <\/span>shards<\/span><\/i> no ayuda a solventar este problema.<\/span><\/p>

La soluci\u00f3n pasa por registrar cada una de las aplicaciones como un consumidor Enhanced Fan-Out. Esta funcionalidad de los Kinesis Stream provee a cada uno de estos consumidores con un l\u00edmite individual de 5 llamadas <\/span>GetRecord<\/span><\/i> y 2MB por <\/span>shard<\/span><\/i> por segundo de lectura.<\/span><\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Esta configuraci\u00f3n se realiza en el lado del consumidor, en nuestro caso mediante el conector de Kinesis para Flink:<\/span><\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t
'scan.stream.recordpublisher' = 'EFO',\r\n'scan.stream.efo.registration' = 'EAGER\/LAZY',\r\n'scan.stream.efo.consumername' = '{consumer_name}' <\/code><\/pre>