Sql

Mesop, una herramienta de Google para crear “AI apps” en Python.

¿Se nos está yendo el tamaño del código JavaScript de las páginas web de las manos? (De cuya lectura, además, he aprendido que existe webpagetest.org, que parece mejor que otras alternativas que he probado por ahí).

uv, un gestor de paquetes de Python “extremadamente rápido” escrito en Rust. ¿Tocará volver a migrar?

Aquí hay una discusión sobre la diferencia entre lugares y sitios —términos ambos que define estipulativamente—. Proyectos como OpenStreetMap se centran en los primeros: coordenadas, sistemas de referencia, mapas, etc. Overture Maps, parece ser, quiere centrarse en los segundos, los sitios, es decir, los bosques, edificios, panaderías, etc. que ocupan el espacio y que son el objetivo —los mapas son solo el medio— de nuestra preocupación por lo que puebla el espacio.

Tengo un fichero .bak. Un fichero .bak (el mío, al menos) es una copia de seguridad de SQL Server y no hay forma humana de acceder a sus contenidos sin otro SQL Server (que yo sepa). No me preguntéis de dónde lo he sacado. La cuestión es que contiene datos que tengo que leer.

Requisito imprescindible para tener un SQL Server es disponer de una máquina con Windows. Pero yo no tengo ninguna. Cuando tuve, instalé la versión de evaluación gratuita de SQL Server (¿Express?) y me ahorré parte de la pena que describo a continuación. Lo hago por referencia mía, por referencia de otros y por si alguien conoce algún atajo.

Un ejemplo sencillo. Tengo un programa que contiene, por ejemplo, una consulta tal que

query <- "select * from mitabla
    where country = 24 and year = 2014"

Hay gente sumamente diligente, con una enorme capacidad de trabajo y con vocación de hormiguita que en mil ejecuciones distintas (distinto país, distinto año) del código anterior sería capaz de editar la consulta a mano. Probablemente usando el block de notas. Esa gente, que además suele madrugar mucho, siempre me ha dado cierta envidia. No sé por qué.

Las bases de datos son instrumentos magníficos con dos defectos fundamentales: es difícil meter datos en ellas y es difícil sacar datos de ellas. Pero guardarlos… los guardan estupendamente.

Estos días me ha tocado subir a una base de datos tablas bastante grandes y las herramientas proporcionadas por RJDBC para ello, esencialmente dbWriteTable han fallado. Internet no se pone de acuerdo sobre si es un bug de RJDBC o si la culpa la tiene el driver de la base de datos que estoy obligado a utilizar. Como fuere, me ha tocado descender un escalón de abstracción y jugar directamente con la API del driver para ejecutar prepared statements.

En ocasiones uno quiere añadir un total calculado en ciertos bloques a una tabla. Por ejemplo, en la tabla

set.seed(1234)
ventas.orig <- data.frame(
    cliente = rep(1:10, each = 5),
    producto = rep(letters[1:5], times = 10),
    importe = rlnorm(50))

tenemos clientes, productos e importes. Y nos preguntamos por el porcentaje en términos de importe que cada producto supone para cada cliente.

Una manera natural pero torpe de realizar este cálculo consiste en usar un objeto intermedio y merge:

library(plyr)
tmp <- ddply(ventas.orig, .(cliente),
    summarize, total = sum(importe))
ventas <- merge(ventas.orig, tmp)
ventas$pct.producto <- 100 * ventas$importe /
    ventas$total

No os asustéis, se puede hacer aún peor (p.e., usando sqldf). Pero existen dos maneras, cuando menos, de hacerlo mejor. La primera es usando data.table.

Aún tengo pendiente mirar en un diccionario qué es podcast. Pero ya he hecho uno. Tengo el honor de haber sido entrevistado por Jorge Ubero para Big Data 4 Success.

La entrevista, aquí.

Sin darnos cuenta, abusamos de ciertos términos. Uno de ellos es el de la varianza explicada. Después de años utilizándolo como por inercia, he venido a darme cuenta por dos vías distintas de su impropiedad: una de mis recientes lecturas y una experiencia profesional.

Tal vez sea más sencillo comenzar exponiendo la crítica realizada en esa página. Parte del análisis de la serie de muertes en Chicago entre 1987 y el 2000:

Me gustaría haber podido indagar bajo el capó de teradataR, el paquete de R desarrollado por Teradata que permite que R realice lo que llaman por ahí _in database analytics _utilizando dicha plataforma propietaria.

Ya lo probé hace un tiempo con resultados bastante desiguales y que distaban muy mucho de mis expectativas originales, habida cuenta de las muchas bondades del gestor relacional. Durante mucho tiempo he tenido la intención de desentrañar los secretos del paquete, pero me contuvieron los términos desacostumbradamente restrictivos de la licencia:

Codd desarrolló el modelo relacional —la base de casi todos los actuales sistemas de bases de datos— a finales de los años sesenta. El modelo relacional, basado en la lógica proposicional, suponía una ventaja sustancial con respecto a los métodos anteriores de almacenar información y bien implementado permite resolver una serie de problemas que afectaban a los sistemas anteriores:

• Evita la redundancia de los datos.
• Minimiza los problemas de actualización de los datos en las tablas.
• Protege la integridad de los datos.
• Etc.

Sin embargo, hay motivos por los que dicho esquema no es enteramente válido en contextos en los que se manejan datos grandes (para una definición sensata sobre lo que son “datos grandes”, léase este artículo).

Como parte de mis atribuciones dentro del comité organizador de las III Jornadas de Usuarios de R estoy tratando de conseguir la participación (y tal vez la financiación) de empresas e instituciones. Me ha parecido oportuno invitar a tomar parte en ellas a Teradata, empresa que, según la Wikipedia,

[está] especializada en herramientas de data warehousing y herramientas analíticas empresariales.

Teradata no se postula como un vendedor de herramientas de almacenamiento: quiere ir más allá. Su mercado es el de las empresas que aspiran a algo más que a que sus datos permanezcan varados en discos duros esperando, como mucho, a ser exportados a aplicaciones externas. Teradata dice ser capaz de realizar el análisis estadístico de los datos dentro de su propio sistema, eso que se ha dado en llamar in database analytics.

Quiero compartir con mis lectores dos enlaces relacionados. Puede que a alguno le interese su sustancia misma. A mí no tanto. A mí me interesan en cuanto que ilustran la emergencia de R y el papel protagónico que está asumiendo en el universo de las cosas analíticas. Tan protagónico que hasta dos viejos dinosaurios pasan voluntariamente por su aro.

Tradicionalmente, para analizar grandes bases de datos empresariales, se realizaba en primer lugar una extracción masiva de datos. Luego se procesaban con herramientas específicas (SAS, por ejemplo). En muchas ocasiones los resultados eran volcados nuevamente en el sistema de partida.

Yo creo que es un bug, vamos. Y tengo tres motivos para creerlo:

1. Teradata no hace lo que se espera que haga.
2. No he encontrado por ahí motivo técnico alguno que proscriba razonadamente lo que intento hacer.
3. He hablado con un señor empleado de Teradata, le he enviado el ejemplo y en lugar de explicarme mi error (de haberlo) ha hecho el avestruz (ya hablé de lo que pasa cuando uno encuentra _bugs _en software propietario).

He aquí cómo reproducir el bug. Primero creo una tabla muy simple e inserto una única fila en ella.

El otro día, al hablar de la compra de Netezza por parte de IBM, hice referencia a un comentario del blog que es casi el flotador al que me asgo cuando quiero averiguar la verdad de las cosas que se me tuercen (últimamente). Dediqué en mi entrada una única línea para referirme a un único párrafo de la otra. Una visión tan parcial y puntual puede haber generado malinterpretaciones que me apresuro a enmendar con la profusión que el tema merita.