Archivos de la categoría Big Data

Aprende Pyspark sin complicaciones

Hace tiempo un gran data engineer me preparó una máquina virtual para hacer "pinitos" con pyspark y llevaba tiempo pensando en como poder publicar trucos y ejemplos con pyspark sin necesidad de máquinas virtuales y empleando notebooks. Ya he encontrado la mejor manera, los contenedores de docker. Cuanto más profundizo en docker más me gusta trabajar con contenedores y con esta entrada me váis a entender perfectamente.

El primer paso es instalar docker y arrancar el terminal. La idea de docker es ejecutar un contenedor en cualquier máquina independientemente del sistema operativo. Instalar spark en windows es un dolor de cabeza, si disponemos de una máquina virtual con linux es más sencillo, pero imaginad que, con dos líneas de código ya podéis trabajar con un notebook y pyspark, pues eso lo podemos hacer con docker.

Descargado e instalado docker abrimos el terminal de docker y hacemos pull sobre un contenedor, en este caso yo recomiendo:

docker pull jupyter/all-spark-notebook

Estamos descargando contenedores con pyspark y notebook, cuando el proceso haya finalizado (unos 5GB) en el terminal de docker podéis ejecutar:

docker images

Y podréis ver jupyter/all-spark-notebook con lo cual ya tenéis disponible un contenedor con un notebook que nos permite ejecutar pyspark. Ahora tenemos que arrancar el servicio Sigue leyendo Aprende Pyspark sin complicaciones

Notebook para empezar (y probar) en spark y scala

No debo enseñar Spark a nadie, no soy ni un usuario avanzado, ni le veo mucho recorrido. Sin embargo tengo que hacer diversos procesos con dataframes en spark y realizar modelos con MLlib y tengo que "perder tiempo" probando cosas, necesitaba un entorno sencillo en casa. En un primer momento exploré máquinas virtuales y alguna sandbox. Ninguna me convencía y le  pedí a un compañero mío, Juanvi, que sabe mucho que me montara un entorno con un notebook de spark para poder jugar con scala y MLlib de modo sencillo. En vez de montarme el entorno en 20 minutos me escribió un correo con 3 direcciones que me están siendo de mucha utilidad y quería compartirlas con vosotros.

La primera dirección es el repositorio donde está alojado este desarrollo del notebook de spark: https://github.com/spark-notebook/spark-notebook Lo primero que debemos estudiar es la documentación y por último generar o seleccionar el notebook que deseamos.  Aquí me gustaría hacer una anotación, no he sido capaz de hacer funcionar en Windows ninguna distribución que no sea de docker, sin ningún problema las dos distribuciones que he probado en Ubuntu y en el Apple sin problema con docker, al final, por temas profesionales, he optado por una versión con Hive-parquet y spark 2.0.1:

 docker pull andypetrella/spark-notebook:0.7.0-scala-2.10.6-spark-2.0.1-hadoop-2.7.2-with-hive
 docker run -p 9001:9001 andypetrella/spark-notebook:0.7.0-scala-2.10.6-spark-2.0.1-hadoop-2.7.2-with-hive

Instalado y arrancado el servicio nos conectamos a http://localhost:9001/ y ya tienes un entorno de pruebas más que digno que funciona mejor que las sandbox que he probado. Un tema, si alguien puede aportar más sobre la distribución del Notebook en Windows que comente la entrada. Espero que pueda ser de utilidad, saludos.

 

Diagramas de Voronoi con spatial de python

En breve "mis cachorros", como llamo a un grupo de los mejores Data Scientist de Europa (de los que tengo que hablar algún día) se van a enfrentar a un problema que probablemente tengan que resolver con análisis geométricos muy complejos. Para despertarles la curiosidad (sé que me leen) hoy traigo al blog una entrada que nos aproxima al método de interpolación geométrica más sencillo, al diagrama de Voronoi. Con spatial de scipy podemos trabajar con estos diagramas:

seed(89)
df = pd.DataFrame(np.random.uniform(1,100,size=(20, 2)), columns=list('XY'))
plt.scatter(df.X, df.Y,marker=".")
show()

voronoi_python1

Estos puntos aleatorios en el espacio de 2 dimensiones pueden generar regiones por interpolación y representarlas con voronoi_2d_plot:

from scipy.spatial import Voronoi, voronoi_plot_2d
vor = Voronoi(df)
voronoi_plot_2d(vor)

voronoi_python2

Ahora si queremos determinar si un punto de espacio está dentro de una de las celdas que delimitan los diagramas de Voronoi que hemos creado podemos hacerlo por vecinos cercanos con la función cKDTree:

from scipy.spatial import cKDTree
vor_kdtree = cKDTree(df)
puntos = [[1,100],[100,1]]
test_point_dist, test_point_regions = vor_kdtree.query(puntos,k=1)
test_point_regions

Y ahora viene lo único interesante de esta entrada, ¿cómo identificamos las regiones? No empleéis .regions, emplead:

pd.concat([df,pd.DataFrame(vor.point_region)],axis=1)

Los puntos (1,100) y (100,1) aparecen en la región que nos identifica la posición 19 y 9... Me ha costado tiempo entenderlo, me hago viejo. Saludos.

Parámetros en las consultas de Hive. Ejemplo con fechas

Soy cinturón blanco de Hive pero aprovecho el blog para mostraros como he añadido unas variables a mi consulta de Hive, en realidad espero que algún alma caritativa me indique alguna forma más elegante. Necesito que mis consultas vayan parametrizadas por fechas que hacen mención a particiones de la tabla, estas particiones no son variables fecha, son string con el formato YYYYMMDD así que es necesario transformar las variables para realizar operaciones con ellas. En este caso tengo una fecha inicio y quiero irme tres meses hacia atrás:

set inicio="20161231";
set f_aux = add_months(from_unixtime(unix_timestamp(${hiveconf:inicio} ,'yyyyMMdd'), 'yyyy-MM-dd'),-3);
set f_mes_menos3 = from_unixtime(unix_timestamp(${hiveconf:f_aux} ,'yyyy-MM-dd'), 'yyyyMMdd');

Con set defino las variables de mi entorno a las que yo referencio como ${hiveconf:variable}, desconozco si hay otra forma mejor de hacerlo y transformo de caracter a fecha con from_unixtime + unix_timestamp para así poder usar la función add_months que no me funcionaba con string. Después deshago el cambio y ya tengo otra variable a partir de la primera, puedo automatizar mis parámetros. ¿Lo estoy haciendo bien?

De estadístico a minero de datos a científico de datos…

Hace unos meses estuve en un data beers que organizó Accenture que mas parecía una reunión de viejas glorias de Neo Metrics y hablé sobre la transformación de un dinosaurio a un científico de datos, por cierto, me llamó la atención como el resto de compañeros hicieron sus presentaciones con software del siglo pasado y eso que yo era el dinosaurio... Hoy ha salido una noticia sobre el uso de la información de Facebook para tarificar en seguros que define hacía donde quiero ir y los problemas con los que he de lidiar. Así que hoy voy a escribir sobre mi y la transformación del dinosaurio al científico de datos.

Un poco de mi vida. Yo antes fui aplicador de plaguicidas, Infante de Marina, oficial de segunda en mantenimiento industrial,... y por las tardes dio por estudiar y en 2001 me diplomé en estadística y en 2003 sacrifiqué mi sueldo de oficial de mantenimiento para trabajar en una consultora de esas que hace body shopping (yo soy partidario del body shopping) aunque ganaba más y trabajaba menos como oficial de mantenimiento descubrí que me gustaba mucho la estadística, había una web en geocities que lo demuestra, con uno de los primeros cursos de R en español. Al principio, en mi trabajo, hacía eso estadísticas, y a esto lo empezaron a llamar Business Intelligence y allí estaba yo con SAS y mis primeras segmentaciones, mis primeras regresiones logísticas con más o menos acierto y sobre todo con mis primeras reglas de negocio, empezaban a sonar términos como data mining. [La primera entrada de la wikipedia sobre data mining data de 2002]. SAS, Clementine, Pretium, software comercial muy caro, consultoras que se forraron, yo decía que R era capaz de hacer todo aquello gratis, pero nadie me escuchaba. Me gustaba mucho lo que hacía, disfruté y aprendí en telecos, bancos y ASEGURADORAS,... Bueno pues en las aseguradoras conocí a los actuarios y con ellos llevo mano a mano 10 años, ellos me consideran actuario, yo no. El paradigma de como la estadística ha mejorado los negocios es el sector asegurador. En concreto en el ámbito del cálculo de precios que es donde yo trabajo las relaciones lineales entre variables llevan siendo beneficiosas desde hace muchos años tanto para las compañías como para los asegurados.

Me gusta mucho mi trabajo,  llevo 10 años buscando relaciones lineales en aseguradoras. He establecido relaciones lineales en seguros de crédito, multirriesgo, hogar, RC,... pero sobre todo en Automóviles. Además de que me gusta creo que no se me da mal. Ahí está mi curriculum y he cambiado mucho y siempre con un motivo y la compañía para la que actualmente trabajo opina lo mismo que yo hay que ir más alla de las técnicas clásicas de minería de datos, eso ya lo hacen todas las aseguradoras, no es una ventaja, y sobre todo las compañías de venta directa necesitan añadir más a esos modelos de prima de riesgo que tan buenos resultados han dado a lo largo de los años. Ahora no hay data mining ahora hay data science. [La primera entrada en la wikipedia data de 2012] y desde entonces hasta ahora no se para de hablar machine learning, nosql, spark, hadoop, big data, concursos de científicos de datos, del trabajo del nuevo milenio,... La verdad es que da un tufillo a burbuja pero es cierto que es necesario diferenciarse, evolucionar y no seguir encapsulado en crear relaciones lineales cuando el software y sobre todo el hardware nos permite ir más allá. Ya no tengo que ser un actuario (de esos), ahora soy un científico de datos (por más que no me guste el término).

Sin embargo, ¿no nos estaremos pasando? La noticia con la que empiezo esta entrada: Facebook no permite usar su información para personalizar precios a Admirall es un jarro de agua fría pero si no lo permite Facebook usamos R en Twitter y sino Instagram, el BOE, Testra, Google,... tenemos información de muchas fuentes pero en el sector asegurador también tenemos regulación, que no se nos olvide por ejemplo no nos dejan usar el sexo para tarificar (esto perjudica a las mujeres por cierto). Son ellos los que dentro de su marco regulatorio deben establecer los límites, pero es curioso que no te dejen usar el sexo para crear un precio y si te permitan saber si empleas el coche las noches de los fines de semana. Pero no se lo tenemos en cuenta porque están muy liados con Solvencia II para que se forren más consultoras.

"Tengo que dejar de ser un dinosaurio para ser un científico de datos" esto se lo dije una vez a alguien de Amazon Web Services pero inmediatamente después comenté "los dinosaurios pesaban toneladas y duraron 65 millones de años no sé si el Homo Sapiens va a durar tanto" le ruboricé pero en el fondo sabía que yo tenía razón.

El parámetro gamma, el coste, la complejidad de un SVM

letra_o_svm_r

Cuando clasificamos datos con SVM es necesario fijar un margen de separación entre observaciones, si no fijamos este margen nuestro modelo sería tan bueno tan bueno que sólo serviría para esos datos, estaría sobrestimando y eso es malo. El coste C y el gamma son los dos parámetros con los que contamos en los SVM. El parámetro C es el peso que le

damos a cada observación a la hora de clasificar un mayor coste implicaría un mayor peso de una observación y el SVM sería más estricto (este link aclara mejor las cosas). Si tuvieramos un modelo que clasificara observaciones en el plano como una letra O podemos ver como se modifica la estimación en esta secuencia en la que se ha modificado el parámetro C:

r_svm_2

Sigue leyendo El parámetro gamma, el coste, la complejidad de un SVM

Cuando paralelizar procesos con R era otra cosa

Allá en noviembre de 2011 en las III jornadas de usuarios de R en España José Ramón Díaz Uriarte nos habló de paralelizar procesos con R, los principios de ese concepto que han denominado Big Data:

http://usar.org.es/pdfs/Diaz_Uriarte-final.pdf

Han avanzado los tiempos en el mundo de R y de la paralelización de procesos. Y es quizá lo que hará que R sobreviva frente a otras herramientas que no se han subido al carro por ser encapsuladas y “oscuras” (se me ocurren algunas). El problema es que perdemos mucho tiempo montando complejos sistemas, tiempo que podría ser empleado en un trabajo que aportara más valor. Necesitamos oír la expresión “yo no paralelizo a mi me paralelizan”. Ese será el momento de R. ¿Lo conseguirá Microsoft? ¿Lo conseguirá Yhat?

Data mining vs Bigdata. De momento con Google Trends

Bigdata por aquí bigdata por allá y resulta que en Google sigue habiendo muchas más búsquedas sobre data mining. Este dato tiene importancia porque el bigdata no tiene sentido sin el data mining. Incluso podríamos prescindir del bigdata porque lo importante es lo que queremos hacer no como lo queramos hacer. Saludos.

SQL vs Hadoop. Más que una tendencia

Google Trends, SQL frente a Hadoop. La tendencia es clara, mientras el interés por Hadoop está creciendo, el interés por SQL baja en picado [aunque vaticino un estancamiento de 2-3 años]. Y si analizamos el interés por zona geográfica por Hadoop:

Ya podéis avidinar quienes marcarán el ritmo en el sector. Quienes serán la referencia en Big Data en 3-4 años. A dónde irán los servidores de las principales compañías mundiales. Muy significativo.