Archivos de la categoría Big Data

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.

¿Cuándo tenemos BIG DATA?

No es que sea yo un gurú del tema precisamente, pero considero que llevo más de 12 años haciendo Big Data, por ello a lo peor alguno toma en serio mis reflexiones. Entonces, ¿cuándo tenemos, hacemos, trabajamos Big Data? La respuesta parece sencilla, “cuando tenemos muchos datos”. Pues no, este es un nombre con mucha pegada (como me han dicho hoy en la comida) es un nombre acertado desde un punto de vista “marketiniano”. Pero muchos datos tiene el operacional de un banco y no creo que un entorno Mainframe haga Big Data. Big Data tenemos cuando accedemos a datos desestructurados. Ya la dimensionalidad pasa a un segundo plano y las tecnologías tradicionales/actuales y sus hechos, metadatas, cubos y demás dejan de tener sentido. Hay Big Data cuando no se prepara la información. Anteriormente el acceso a los datos necesitaba un periodo previo para adaptarlo a una estructura, ahora no, ahora accedemos (por ejemplo) a un sistema operacional sin necesidad de pasar por una capa previa. En realidad hacemos lo mismo, tabulamos, graficamos, modelamos pero sobre datos que no están preparados. Eso es Big Data.

Como vemos el tipo de análisis que utilizamos con el Big Data no dista mucho de lo que hacemos ahora mismo. Por ello las personas que se dedican actualmente a analizar la información serán las mismas que lo harán en el futuro. Pero estas personas tienen que familiarizarse con el empleo de otras tecnologías. Algún compañero de la blogosfera ya está comenzando a definir el nuevo paradigma del gestor de la información. En este blog ya se habló sobre el tema en 2010. La personas que nos dedicamos a la estadística (aunque algunos estemos muy orientados al negocio) tenemos que tener presente este cambio de conceptos y adaptarnos si no queremos quedarnos fuera. El Big Data es lo mismo de siempre pero de otra forma más barata y no necesariamente menos complicada.

¡No seamos dinosaurios! [Aunque luego terminemos pintando todo con Excel]

Nos hemos terminado de reinventar. Acabamos con el Data Mining y empezamos con el Big Data

Google Trends y buscamos los términos Big Data y Data Mining y obtenemos la figura de arriba. Ya convergen las búsquedas. Muchos opinamos que estamos trabajando con Big Data desde hace muchos años sin embargo es ahora cuando este trabajo parece que se está dando a conocer. Y las escuelas de negocio son conscientes de ello. El sector de las tecnologías de la información tiene que estar continuamente renovándose. A lo largo de los años han habido mas revoluciones conceptuales que verdaderamente tecnológicas, sin embargo este nuevo concepto de Big Data si trae consigo una nueva visión de acceso a la información.

No me gusta mucho hablar del tamaño de los datos. A toda esta nueva visión se le ha llamado así debido a que se accede a un gran volumen de datos. Pero lo más revolucionario de todo no es el volumen, sino la forma de acceder a los datos. Antes (y ahora) se accedía a información estructurada, a dimensiones, hechos, cubos,... Ahora accedemos a información desestructurada y somos capaces de visualizarla y tabularla. Para ello también han mejorado los sistemas de almacenamiento de datos, aunque en este caso he de confesar que me pierdo un poco con nubes, hadoops, sistemas distribuidos, map reduces y demás pero es cierto que la verdadera revolución está en estos nuevos sistemas y en la reducción de costes que implica su utilización.

Estaremos muy atentos sobre estas nuevas tendencias en la gestión de la información. Lo primero que se va a hacer en esta bitácora es crear una nueva categoría llamada Big Data en la que espero hablar sobre la reconversión de un viejo dinosaurio al nuevo paradigma [da un poco pereza empezar de nuevo].