SparkSharp, Spark in C# (1) Primeras ideas

Published on Author lopez

Siguiente Post

En el post de ayer mencionaba el uso de Spark por parte de gente de Medallia. Conocía un poco de ese proyecto Apache, pero hoy me puse a ver la interfaz de programación que tienen, y me pareció interesante reproducir alguna parte en C#.

Ellos trabajan con Dataset, conjuntos de datos que pueden venir, por ejemplo, de archivos locales o distribuidos, y a los que aplican funciones de transformación (Map) y funciones de reducción, obtención de algún valor resultante (Reduce). Los trabajos definidos se pueden correr en varios nodos (tengo que revisar cómo consiguen consolidar la etapa de Reduce final).

Pero para comenzar una implementación en C#, me parece interesante comenzar en pequeño, y como es usual, usar el flujo de trabajo de TDD (Test-Driven Development). Así que ni lerdo ni perezoso, en la tarde de ayer comencé este proyecto:

https://github.com/ajlopez/SparkSharp

Si ven los primeros commits, se siguió la idea de flujo de TDD. Va quedando que los datasets implementan como base a un IEnumerable<T> sobre el que se aplican de forma ordenada funciones Map, Reduce, Split, Take, Skip y otras que vayan apareciendo. Esos datasets pueden ser simples “wrappers” de otros IEnumerable<T> (como un arreglo de tipo T, o una lista), o pueden venir de tomar un texto y partirlo en líneas (ver el TextDataset), o tomar un archivo y procesarlo en líneas.

Todos esos datasets son, digamos, locales, no distribuidos. El próximo paso simple (siempre hay que ir por lo más simple) es exponer un dataset cualquiera para que se pueda consumir ordenadamente de forma remota. Por ejemplo, en un nodo/máquina podemos tener un gran archivo de texto a analizar. Queremos procesar sus líneas. Para esto hoy ya en el proyecto está el TextFileDataset, que procesa las líneas a medida que se van leyendo. Pero se podría implementar un ServerDataset o RestDataset, que sea un “wrapper” sobre ese dataset local, y se exponga para afuera, mediante TCP o una API que devuelva JSON o un simple string via HTTP. Entonces, distintas clases clientes (me imagino RestClientDataset, o ServerClientDataset), podrán consumir esos datos desde nodos remotos, como si fueran datasets locales. En el caso normal, un TextFileDataset expondría sus líneas a los nodos remotos, para que se puedan consumir, pero de una forma controlada: cada línea iría al próximo nodo que pida un item del dataset.

Despues de implementar la exposición de un dataset local como remoto (con ese cuidado de que cada item SOLO vaya a un nodo solicitante, que no se REPITA el proceso de un item entregándolo a DOS o más nodos), implementar la serialización/deserialización (temas ya encarados en AjErl y Aktores), automáticamente comenzamos a tener procesamiento distribuido. Claro que todo esto es el caso feliz: si el proyecto progresa, habrá que contemplar fallas en la comunicación, ingreso y egreso de nodos dinámicamente en el medio del proceso, coordinación/recolección de datos en un Reduce final que consuma resultados parciales de varios nodos, etc.

Pero piano, piano se va a lontano. Por ahora, baby steps, la neurona atenta, vermú con papas fritas, y good show!

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez