Tengo curiosidad si no es sencillo escribir mi propio código para leer de Kafka usando la API del consumidor de Kafka y usar el SDK de AWS para escribir en S3. ¿Hay muchas complicaciones no obvias con las que lidiar?
Lo pregunto porque Kafka Connect parece ser la forma más sugerida de escribir en S3 desde Kafka.
Es posible que lo haya visto mencionado antes como una analogía, así que lo usaré aquí también: puede pensar en Connect como un marco de trabajo de alto nivel de productores y consumidores de Kafka que tienen como objetivo integrar sus datos con Kafka usando fuentes y sumideros (el equivalentes de alto nivel de productores y consumidores respectivamente en Connect). Una variedad de fuentes y sumideros, brevemente conectores, ya están disponibles .
Específicamente, con respecto a la exportación de datos de Kafka a Amazon S3, ya hay algunos conectores disponibles y, dado que soy en parte responsable del último , permítanme mencionar algunas ventajas de su uso. (Con suerte, esto responderá a su pregunta sobre si es más o menos sencillo implementar todas estas funciones desde cero).
Agruparé mis argumentos en comparación con escribir un programa directamente basado en los consumidores aproximadamente en dos categorías:
- Ejecución transparente y escalable en un clúster.
- Ejecución tolerante a fallas, igual que con grupos de consumidores de Kafka (la ventaja es que se obtiene tolerancia a fallas sin tener que escribir el código)
- Una interfaz REST para iniciar y detener conectores.
- Un pequeño conjunto de métricas (que pronto se ampliará a un conjunto completo de métricas operativas y de rendimiento).
- En general, defina flujos de datos de transmisión simples e intuitivos que incluyan fuentes, transformaciones simples en sus datos ( SMT ) y sumideros.
- Formateadores múltiples (actualmente exportando archivos binarios .avro y archivos de texto .json)
- Soporte de datos estructurados o no estructurados, con modos de evolución de esquemas para los primeros.
- Una gama de particionadores: basados en tamaño, tiempo o campo, que puede usar como clases base para crear sus propios particionadores personalizados que se ajusten a su caso de uso, si no hacen exactamente lo que desea de inmediato.
- Semántica exactamente una vez para la mayoría de los casos de uso de los particionadores anteriores (lo que significa que, si reprocesa sus datos o se recupera de una falla, no verá registros duplicados en S3).
- Fácilmente configurable.
- Soporte activo de la comunidad (que sus clases también podrían terminar teniendo si las abre).
En general, no tendrá que escribir desde cero y mantener el código que muchos otros (como usted) quieren usar. Además, si encuentra que faltan una o más funciones, puede contribuir con estas funciones en el S3 Connector de código abierto.
Hay un par de ventajas:
Por supuesto, puede escribir su propia aplicación de consumo que escriba en S3, pero ¿por qué reinventar la rueda?