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.
Mi amigo Carlos escribió esta entrada en su blog. Si fuera un manifiesto la primera de las firmas de apoyo sería la mía. Cuando programamos en SAS hemos de usar PROC SQL siempre que podamos. Fundamentalmente porque un programa puede ser usado por múltiples usuarios y en muchas ocasiones hemos de realizar migración entre aplicaciones y casi todas las personas y sistemas pueden interpretar SQL. Con este argumento si se puede hacer con el PROC SQL… En fin, esto me parece tan evidente que hoy sábado, después de acostar a mis hijos y navegar por la blogosfera encontrarme con esto es demasiado para mi.
Algunos diréis, eso te pasa por leer lo que escribe la paisana esta. Bien, vale, estamos de acuerdo, perfecto, pero me cuesta mucho comprenderlo. En fin, no leáis ninguna de las entradas que podéis crisparos.
El paquete sqldf de R nos permite ejecutar sentencias de SQL . Las cláusulas, las expresiones, los predicados,… son lasalvación para muchos tipos mediocres como el ahora escribiente. sqldf es un módulo imprescindible, hasta el novio de Falete es capaz de programar en SQL. Evidentemente no voy a enseñaros a hacer queries, pero si quiero mostraros algunas de las posibilidades que nos ofrece este paquete de R. Como siempre y como caracterizan la mayoría de los mensajes del blog trabajaremos con ejemplos. El primer paso es crear un data.frame:
saldo1=runif(100,0,1)*1000
saldo2=runif(100,0,0.5)*10000
saldos=data.frame(cbind(saldo1,saldo2))
saldos$id_cliente=c(1:100)
saldos$alto=as.factor(ifelse(saldo1+saldo2>=4000,1,2))
summary(saldos)
Creamos una estructura con dos variables numéricas saldo1 y saldo2, una variable id_cliente (más…)
Hace unos meses padecí (eso sí, brevemente) un proyecto que consistía en la migración de cierto código en SAS (¡nos lo pasaron como un documento de 20 hojas de Word!) a otro lenguaje de programación.
Esencialmente, desde la nueva plataforma habrían de lanzarse consultas a cierta base de datos (cuando el código SAS permitiese resolver los cálculos como una consulta de SQL) y procesarse los resultados procedimentalmente desde el nuevo lenguaje de programación cuando SQL ,declarativo, no fuese suficiente. Surgió el problema de que el lenguaje procedimental era incapaz de procesar bloques tan grandes de información. Pero ésa es otra historia.
En esencia, lo que SQL era incapaz (¿lo era realmente? sigamos leyendo…) de procesar eran pasos data muy simples pero que contenían llamadas a la función lag. Esta función, en esencia, ordena a SAS en un paso data recordar el valor de cierta variable en la línea anterior para compararlo con el de la presente. Se usa principalmente para calcular incrementos cuando los datos están ordenados temporalmente.
Las nuevas especificaciones de SQL (la 2003 y la 2008) introdujeron y detallaron el uso de funciones de ventana. Las funciones de ventana son extensiones de las clásicas consultas con “group by”. Éstas últimas sólo permiten devolver una fila por cada nivel de agrupamiento. Las funciones de ventana permiten operar sobre el bloque completo que define un nivel y:
Puede leerse más al respecto aquí y aquí.
Estoy seguro de que el uso de este tipo de extensiones ahorrará a muchos desarrolladores kilómetros de líneas de código y eones de tiempo de depuración.