AWS Builder Center
De SSIS a AWS Glue: tres hábitos que desaprendí

De SSIS a AWS Glue: tres hábitos que desaprendí

Vengo de SQL Server y SSIS. Estas son las tres costumbres que tuve que soltar al pasar a Spark en Glue, y la que todavía me confunde.

Trabajo con SQL Server y SSIS todos los días. Construyo paquetes que mueven datos de transacciones de viajes, y en las noches estudio ciencia de datos en Bogotá mientras aprendo la parte de AWS. Hace unas semanas abrí AWS Glue por primera vez esperando reconocer algo. No reconocí nada.
Esa sensación es la razón por la que escribo esto. No como tutorial, que de esos ya hay muy buenos por acá, sino como una nota corta de alguien que todavía está en la mitad del cambio. Si vienes de una herramienta de ETL tradicional, puede que algo de esto te suene familiar.

Seguía buscando el Data Flow

En SSIS todo vive dentro de un paquete. El control flow decide qué corre y en qué orden, el data flow mueve las filas, y los dos están en el mismo archivo. En AWS eso está separado a propósito. La orquestación se va a Step Functions, la transformación se va a un job de Glue corriendo Spark. Mi primer error fue buscar la pantalla única que hiciera las dos cosas. Esa pantalla no existe, y el día que lo acepté todo lo demás se volvió más fácil.

La fila dejó de existir

Este me costó más de lo que quisiera admitir. En SSIS yo pienso en filas. Un Script Component recibe una fila. Una salida de error redirige esa fila. En Spark la unidad es la partición, no la fila, y no existe el "manda este registro malo para allá". Lo que lo reemplazó para mí fue partir los datos a propósito, lo válido por un lado y lo rechazado por el otro, y escribir la parte rechazada en su propio prefijo en S3. Al principio se sintió mal. Ahora lo prefiero, porque mis rechazos se volvieron una tabla que puedo consultar en vez de un log que nadie abre.

Dejé de poder ver mis datos

Lo que más extrañé no fue una función, fue la retroalimentación. Clic derecho en una flecha, pegar un data viewer, F5, y ver pasar las filas. Spark es perezoso, así que no hay nada que mirar hasta que algo lo obliga a ejecutar. Tuve que aprender explain, el Spark UI, y escribir resultados intermedios en una carpeta de prueba para poder consultarlos. Voy a ser honesto, algunos días todavía extraño las flechas verdes. Lo que gané a cambio es que todo el pipeline ahora es texto, así que vive en git, un compañero lo revisa, y un cambio malo se puede deshacer.

Tres cosas que de verdad ayudaron

Si estás empezando este mismo cambio, estas son las que más tiempo me ahorraron. Primero, deja de traducir paquete por paquete y traduce conceptos: un Lookup con caché completo es un broadcast join, un Conditional Split es un filtro, un Aggregate es un groupBy. Segundo, aprende funciones de ventana temprano, porque la deduplicación, el último registro por llave y las dimensiones que cambian lentamente se resuelven todas con ellas una vez que hacen clic. Tercero, haz que cada job sea seguro de correr dos veces. Un paquete de SSIS normalmente corre una vez y una persona lo reinicia si falla, pero un job de Glue se puede reintentar solo, así que hacer append a ciegas te va a duplicar los datos en silencio y nadie se entera hasta que un reporte se ve raro.
Nada de eso es avanzado, y ese es justamente el punto. La parte difícil nunca fue la sintaxis, fue soltar un modelo mental que me había funcionado durante años.

Lo que todavía me confunde

Las cargas incrementales. En SSIS guardo una marca de agua en una tabla de control, la leo, la uso, y la actualizo al final. Glue tiene job bookmarks que hacen algo parecido con mucho menos código, pero no tengo claro cómo se comportan cuando un archivo llega tarde cargando una fecha de negocio anterior. Ya leí la documentación dos veces y todavía quiero oírlo de alguien que lo haya corrido en producción.

Tu turno

Comparto esto porque creo que muchos estamos en la mitad de una migración como esta, y no hablamos lo suficiente de la parte confusa. Publicamos el tutorial después de que ya entendimos, nunca las tres semanas en las que nada tenía sentido.
Así que me gustaría mucho leer tu historia. De dónde vienes, de SSIS, Informatica, Talend, Pentaho, o de una carpeta llena de procedimientos almacenados. Cuál hábito fue el más difícil de desaprender para ti, y qué fue lo que finalmente te hizo clic.
Y si apenas vas empezando y algo todavía no te cuadra, dilo en los comentarios. Te prometo que no eres el único, y con gusto lo pensamos juntos.
Esta nota también está en inglés: https://builder.aws.com/content/3KEgguLkXFfh9yjshOf9ZBsZyeU/coming-from-sql-server-to-aws-glue-three-habits-i-had-to-unlearn
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article