yo te he entendido perfecto, debe ser porque ya he trabajado con kinesis y colas SQS, ya conozco esa arquitectura, queda muy claro qué es kafka y flink. En mi empresa voy a trabajar en un proyecto de big data y es mi primera toma de contacto con flink. Por cierto, también me llamo Javier Ramírez. Un saludo y gracias por el tutorial.
Hola. Ya no trabajo en AWS y estoy algo desconectado. Ahora trabajo en QuestDB, donde desarrollamos una base de datos de series temporales open source (también con versión totalmente gestionada en AWS si lo prefieres). Si lo que quieres resolver con Druid es sobre series temporales, puede que QuestDB te pueda ayudar questdb.io. Sé que en AWS tienen Timestream, pero hasta donde sé llevan como dos años sin sacar ninguna feature nueva y no veo casos de uso nuevos de clientes, así que si lo vas a usar investiga un poco por tu cuenta. Nosotros sacamos nuevas features cada pocas semanas y tenemos más de 12.500 desarrolladores que han marcado nuestro proyecto como favorito en github
@Javier en la nube, muchas gracias por tu vídeo, muchos no somos especialistas, si pudieras ser mas didactico, fantastico!!! En horabuena y Ole por tus aportes.
Muchas gracias, Leo. Tienes razón que me faltó ponerle al video el nivel. Normalmente en mi equipo de AWS tenemos videos de nivel 100, 200, 300 o 400, dependiendo de la familiaridad y experiencia que se requieran con los servicios. En este caso no lo puse, pero estaba orientado a nivel 250-300, es decir, a quienes ya tienen cierta experiencia haciendo analítica de datos con servicios como Apache Kafka o Apache Flink y quieren ver cómo hacer lo mismo pero usando AWS. En el futuro me aseguraré de poner el nivel o el público objetivo en los comentarios. Otros videos del canal sí son más didácticos. Gracias de nuevo
Yo a día de hoy te haría la pregunta inversa. ¿Por qué no moverte a la nube? A no ser que tengas un caso de uso muy específico, creo que la nube te da en general más flexibilidad y más seguridad que trabajar en un entorno más tradicional. Te permite enfocar tus esfuerzos en la lógica de negocio de tu aplicación, y delegar gran parte de la gestión de la infraestructura en tu proveedor. Además te permite hacerlo de forma elástica, pudiendo añadir o quitar recursos de forma dinámica en función de tu demanda real, y reduce la barrera de entrada a tecnologías como analítica de datos, IoT, machine learning e incluso computación cuántica. Tengo curiosidad por saber cuál es el caso de uso en el que prefieres no estar usando una nube
@@javierenlanube apenas estoy adentrandome al mundo de kafka pero mis conocimientos en la nube con kafka son escasos, ojalá cuando tenga oportunidad pueda hacer algo más a profundidad y de kafka en la nube. Gracias por su canal!
Gracias. No tengo nada específicamente, pero me gusta el post de Ververica (los creadores de Flink) sobre backpressure www.ververica.com/blog/how-flink-handles-backpressure. Podrías combinar las métricas personalizadas (usando la técnica explicada en ci.apache.org/projects/flink/flink-docs-release-1.12/ops/monitoring/back_pressure.html) con autoescalado basado en custom metrics de Amazon Kinesis (aws.amazon.com/blogs/big-data/enhanced-monitoring-and-automatic-scaling-for-apache-flink/) para detectar backpressure e intentar mitigarla. En caso de que el problema de backpressure fuera por el destino de los datos, tendrías que aplicar la escalabilidad en ese lado y no dentro de Kinesis
@@javierenlanube gracias Javier yo estoy haciendo una tesis sobre streaming y solución para el backpresure. No te dejo mi contacto por acá por que es público. Ya me subscribí a tu canal es excelente.
@@SuperJavierus estrictamente hablando, en flink puedes leer de diferentes fuentes, incluyendo sistemas "estáticos" de almacenamiento de objetos como S3 o HDFS. Una cola de mensajes te sirve para almacenar tus eventos de forma escalable y fiable de cara a consumirlos después por una o varias aplicaciones.
@@SuperJavierus Tambien si manejas una Unbounded stream no sabes el final del mismos y requires que la informacion este ordenada entonces kafta te podria ayudar con eso ya que te garantiza el orden de los mensajes
Muchas gracias por tu video!
yo te he entendido perfecto, debe ser porque ya he trabajado con kinesis y colas SQS, ya conozco esa arquitectura, queda muy claro qué es kafka y flink. En mi empresa voy a trabajar en un proyecto de big data y es mi primera toma de contacto con flink. Por cierto, también me llamo Javier Ramírez. Un saludo y gracias por el tutorial.
¿Teneis algo como apache Druid en AWS ? ¿ Como se usaria Ksql con MSK ?
Hola. Ya no trabajo en AWS y estoy algo desconectado. Ahora trabajo en QuestDB, donde desarrollamos una base de datos de series temporales open source (también con versión totalmente gestionada en AWS si lo prefieres). Si lo que quieres resolver con Druid es sobre series temporales, puede que QuestDB te pueda ayudar questdb.io. Sé que en AWS tienen Timestream, pero hasta donde sé llevan como dos años sin sacar ninguna feature nueva y no veo casos de uso nuevos de clientes, así que si lo vas a usar investiga un poco por tu cuenta. Nosotros sacamos nuevas features cada pocas semanas y tenemos más de 12.500 desarrolladores que han marcado nuestro proyecto como favorito en github
@Javier en la nube, muchas gracias por tu vídeo, muchos no somos especialistas, si pudieras ser mas didactico, fantastico!!! En horabuena y Ole por tus aportes.
Muchas gracias, Leo. Tienes razón que me faltó ponerle al video el nivel. Normalmente en mi equipo de AWS tenemos videos de nivel 100, 200, 300 o 400, dependiendo de la familiaridad y experiencia que se requieran con los servicios. En este caso no lo puse, pero estaba orientado a nivel 250-300, es decir, a quienes ya tienen cierta experiencia haciendo analítica de datos con servicios como Apache Kafka o Apache Flink y quieren ver cómo hacer lo mismo pero usando AWS. En el futuro me aseguraré de poner el nivel o el público objetivo en los comentarios. Otros videos del canal sí son más didácticos. Gracias de nuevo
Me costó casi 2 años viviendo en España para saber que 1 billón no es 1 billón, y si mil millones. :D
Sigue siendo una cantidad bastante grande, jajaja. Habiendo vivido en US y UK, te entiendo perfectamente :). Gracias por tu interés
Como saber cuando moverse a la nube? cuales son esos parámetros o señales que dicen que hay que pasarse a la nube?
Gracias y saludos !
Yo a día de hoy te haría la pregunta inversa. ¿Por qué no moverte a la nube? A no ser que tengas un caso de uso muy específico, creo que la nube te da en general más flexibilidad y más seguridad que trabajar en un entorno más tradicional. Te permite enfocar tus esfuerzos en la lógica de negocio de tu aplicación, y delegar gran parte de la gestión de la infraestructura en tu proveedor. Además te permite hacerlo de forma elástica, pudiendo añadir o quitar recursos de forma dinámica en función de tu demanda real, y reduce la barrera de entrada a tecnologías como analítica de datos, IoT, machine learning e incluso computación cuántica. Tengo curiosidad por saber cuál es el caso de uso en el que prefieres no estar usando una nube
@@javierenlanube apenas estoy adentrandome al mundo de kafka pero mis conocimientos en la nube con kafka son escasos, ojalá cuando tenga oportunidad pueda hacer algo más a profundidad y de kafka en la nube.
Gracias por su canal!
Buen video!
Imparten algún curso sobre kafka?
Hola. Yo personalmente no imparto cursos sobre Kafka, pero sé que en udemy o coursera hay cursos especializados
Muy bueno el video , de backpressure tenes material ?
Gracias. No tengo nada específicamente, pero me gusta el post de Ververica (los creadores de Flink) sobre backpressure www.ververica.com/blog/how-flink-handles-backpressure. Podrías combinar las métricas personalizadas (usando la técnica explicada en ci.apache.org/projects/flink/flink-docs-release-1.12/ops/monitoring/back_pressure.html) con autoescalado basado en custom metrics de Amazon Kinesis (aws.amazon.com/blogs/big-data/enhanced-monitoring-and-automatic-scaling-for-apache-flink/) para detectar backpressure e intentar mitigarla. En caso de que el problema de backpressure fuera por el destino de los datos, tendrías que aplicar la escalabilidad en ese lado y no dentro de Kinesis
@@javierenlanube gracias Javier yo estoy haciendo una tesis sobre streaming y solución para el backpresure. No te dejo mi contacto por acá por que es público. Ya me subscribí a tu canal es excelente.
Algo confuso, además... creo que no me queda claro, qué haces en flink y qué haces en kafka, pero bueno. la idea general la he pillado.
Gracias por el feedback, Rafa. Intentaré hacerlo mejor la siguiente vez :)
quizás la pregunta es, por qué necesitas una cola de mensajes como entrada a flink?
@@SuperJavierus estrictamente hablando, en flink puedes leer de diferentes fuentes, incluyendo sistemas "estáticos" de almacenamiento de objetos como S3 o HDFS. Una cola de mensajes te sirve para almacenar tus eventos de forma escalable y fiable de cara a consumirlos después por una o varias aplicaciones.
@@SuperJavierus Tambien si manejas una Unbounded stream no sabes el final del mismos y requires que la informacion este ordenada entonces kafta te podria ayudar con eso ya que te garantiza el orden de los mensajes
desde cuando wismichu hace contenido relacionado a las tecnoligias de informacion