Translate

Mostrando entradas con la etiqueta SQL. Mostrar todas las entradas
Mostrando entradas con la etiqueta SQL. Mostrar todas las entradas

jueves, 8 de junio de 2023

Crear un modelo de regresión linear en BigQuery ML- GCP

Una de las cosas que mas me ha llamado la atencion al ponerme con Google Cloud platform y especialmente BigQuery (que es la joya de la Corona) es la posiblidad de hacer modelosusando SQL. Después de tan tiempo aprendiendo R y luego Python, ahora resulta que en BigQuery los debes hacer en SQL. 

Bueno, pues nada, parece un poco fuera de lugar pero allá vamos. En el curso una cosa que he echado en falta ha sido el hecho de que apenas se explican que hacen los ejercicios. En decir te explican la forma, pero no el porqué. Aunque entiendo que un ingeniero de datos no debe saber tanto de como hacer los modelos, a mi parece queda un poco cojo hacer un copia y pega sin saber en realidad lo que hace el código. Sobre todo si vienes de Software Engineering, y no sabes ni como funcionan los modelos.
Así que aquí estoy yo para intentar dar un poco de luz a esto.
Además a mi me resultó especialmente fácil porque para mi dissertation yo hice un modelo parecido. (si es que está todo inventado... larga vida al Machine Learning)

A la hora de crear un mdoelo, lo primero que tenemos que hacer es éntrenar nuestro modelo. Para eso vamos a usar una parte de nuesta muestra para entrenarlo(un porcentaje) y luego lo aplicaremos al total para ver si se puede extrapolar.

En cuanto al código que nos da para el ejercicio Google Cloud

Aquí ya vamos a crear un modelo que se llamará bike model. 

// Query train a model
CREATE OR REPLACE MODEL
  bike_model.model

En Options le vamos a meter las variable target. Es decir la que queremos predecir y además le vamos a decir el tipo de algortimo que vamos a usar. En este caso vamos a hacer una regresion lineal
 
OPTIONS
  (input_label_cols=['duration'],
    model_type='linear_reg') 

Para hacer la regresión lineal  vamos a seleccionar además otras variables llamadas independientes. En este caso vamos a seleccionar la duración, el dia de la semana y la hora.
Si no estás muy puesto en SQL te puede resulta raro el tema CAST que se mete por ahí en medio.Es una sentencia avanzada del lenguaje que se usa para cambiar el tipo de variable.En este caso las dos variable las convertimos a string y las llamamos como dayofweek y hoursofday. Las dos las convertirmos desde start-date  
AS
SELECT
  duration,
  start_station_name,
  CAST(EXTRACT(dayofweek
    FROM
      start_date) AS STRING) AS dayofweek,
  CAST(EXTRACT(hour
    FROM
      start_date) AS STRING) AS hourofday
FROM
  `bigquery-public-data`.london_bicycles.cycle_hire

Y para terminar con el from elegimos el dataset que estamos usando. 
Espero que esto sirva para dar un poco más de luz en BigQuery. Todos los derechos reservados a Google que son los que han escrito el código.

En caso de que quieras saber que pasa una vez que le das a run. BigQuery te calculos los cohefientes como si hubieras usado cualquier libreria de DataScience en R o Python. Te lo saca en su tablita y así puedes ver si funciona tu moledo o si debes seguir trabajando en el.

Seguiremos informando
Otros link a checkear

lunes, 26 de septiembre de 2022

HOW-TO: SQL When to use USING instead of WHERE - SQL INTERMEDIATE

 Visto en Leetcode:

https://leetcode.com/

Problema: 

Dadas dos tablas con IDs de usuario queremos saber el nombre y el id de usuario con su id único.


Además queremos que aparezcan los nulls

Explicación:

En un primer momento lo más fácil sería pensar en usar un LEFT JOIN o un RIGHT JOIN

Sin embargo tenemos una claúsulas que nos puede ayudar a simplicar el código creada para estos casos concretos y sería USING

SELECT unique_id, name 

FROM Employees e

LEFT JOIN EmployeeUNI u ON e.id = u.id


Por qué usar USING en SQL

Using hace más legible el código y además nos ayuda a prevenir problemas más complejos.

Cómo usar USING en SQL

# Write your MySQL query statement below
SELECT unique_id,name
FROM Employees
LEFT JOIN EmployeeUNI
USING(id)

martes, 6 de octubre de 2020

Bigquery user interface para principiantes

Este ultimo año me he convertido en una advocate de Google Cloud y de BigQuery y me ha tocado enseñar como funciona. Parece que muchos analistas digitales miran con bastante recelo a la interfaz de usuario de BigQuery con toda esa parafernalia de Ingenieria de Datos o cientifico de datos. La buena noticia es que 

En realidad BigQuery quita mucha complejidad a las asi que se me ha ocurrido llenarla de dibujitos y colorines y explicar como es la arquitectura de datos para el usuario final, tipo analista digital.

Bueno, el diseño no es lo mio, y la verdad es que  habría que echar la culpa del resultado final, no soy a mi (mea culpa) sino tambien a Microsoft por su programa ´Paint 3d´.

Una vez que accedemos a GCP Google Cloud Platform   en nuestro proyecto sólo tendremos que poner en el buscador BigQuery y nos llevará a la siguiente pantalla.

Una vez en seleccionado nuestro proyecto vamos a crear un dataset para poder analizar datos.
En nuestro caso se va a llamar eCommerce, ya que vamos a medir transacciones en él.

Aqui es donde he visto que los principiantes tienes mas problemas con la interfaz.

Dentro de nuestro proyecto, vamos a tener
- Un proyecto
- Donde crearemos un dataset
- Este Dataset tendrá tablas
- Las tablas tendrán filas y columnas

- Además para tener mayor acceso a los datos vamos a crear vistas, pero esto lo explicaré más abajo
#Si miramos la interfaz de usuarios podemos ver la siguiente estructuras en nuestros proyectos.


Practicamente de un vistazo, bajo el menú de la izquierda, podemos ver todo lo necesario para hacer nuestras queries. Y además si miramos el resto de la pantalla podemos encontrar las misma referencias. He añadido las referencias (dibujitos) 

viernes, 6 de diciembre de 2019

MVCC - multiversion concurrency control en base de datos

Hace unas semanas me pasó un marrón considerable. Fui a sacar dinero al cajero y úna vez puestos mis 400 euros, el cajero me dió un error y suspendió la transacción. Así que como yo quería mi dinero volví a repetirlo todo y esta vez si obtuve m dinero.
Cual es mi sorpresa cuando miro en la APP que había sacado dinero dos veces.

Seguido de un sudor frio y un ahora qué

Empecé a imaginarme tener que llamar  a mi banco, al cajero, a mi cuenta de Reino Unido, a ver como explico yo que estaba diciendo la verdad y nada más que la verdad. Joder 400 euros, es una pasta eh. Y no tengo testigo. A ver si le da mi dinero al segundo que llegue... overthinking

Y al llegar a casa y llamar al banco, me dicen que todo esta bien y que ese dinero esta en mi cuenta. 
Pero, sennorita, que yo lo he visto con mis ojos. Y ella, pues vuelve a mirar. Tachán ahí estaba.

Acaso he entrado en un agujero del tiempo del camino del banco. Nota mental - Dark y Rick y Morty me están afectando seriamente.

Pues no, tiene pinta que ha sido tema MVCC.  Y aquí ya hay que ponerse un poco nerd.

Qué es el MVCC

El control de concurrencia mediante versiones múltiples (Multiversion concurrency control o MVCC) es un método para control de acceso generalmente usado por SGBDs para proporcionar acceso concurrente a los datos, y en lenguajes de programación para implementar concurrencia.
En la wikipedia tienes más información  https://es.wikipedia.org/wiki/Multiversion_concurrency_control

Para que sirve el Multiversion concurrency control

Pues para que no pasen errores como el mio. Yo pedí sacar un dinero y seguramente hubo un timeout en medio de la query. Al usar el banco de otra sucursal en mi app salió como que ya había cogido ese dinero. Entonces miré en la app, y mi dinero había desaparecido. Más tarde el cajero del banco mandaría un código de error como que no se había completado la transacción. Así que la base de datos de mi banco volvió al estado anterior, es decir no completó esa transacción.

Mmmmmm todo tiene sentido ahora. Y oye, esto es bastante importe porque estas cosas pueden pasar varias veces al día. 

Cómo funciona el control de concurrencia mediante versiones múltiples

La verdad, es que el tema es un poco complicado de explicar con palabras, así que lo mejor es tirar de diagramas. Dejo aquí un artículo que lo explica muy bien. 

En que bases de datos se puede dar el MVCC


sábado, 5 de mayo de 2018

Cómo se ejecuta una query en SQL

Para seguir poniéndome al día y no olvidar el coding, estoy haciendo unos cursos a modo de repaso. Además, siempre se aprende alguna libreria o alguna forma nueva de hacer algo que siempre hacemos de una forma más optimizada.

En este caso estoy repasando SQL para business y he recordado un concepto que me costó pillar al principio. Así que aquí queda por si alguien empieza en SQL y se encuentra con ello.

Una vez que ya sabemos lo básico de SQL con una tabla, y se te pasa por la cabeza que qué fácil y lógico es esto

SELECT  //Dame esto
FROM     // De esta tabla
WHERE // donde ocurre esto (tal es igual, mayor, menor que ...)

llega el momento JOIN. Aquí vamos a tener dos tablas o más.

Como en SQL estamos trabajando en un modo tabular (es decir, trabajamos con formato tablas de filas y columnas) vamos a necesitar una misma columna para juntar (JOIN) las tablas. Esto es muy parecido al VLookUp de toda la vida de Excel (en castellano Buscarv)

Por lo tanto necesitamos saber en que tablas están las columnas que queremos. Así que en el ON vamos a poner el nombre de las columnas como referencia. Si la base de datos está bien hecha (es decir bien disennada, es que no tengo ennes en el teclado) la columna que vamos a usar para unirla se llamará igual en ambas tablas. A esta columna se le llama primary key, pero eso es otra historia...
 Total, que en todos los ejercicios que hagas esto será de cajón. Sin embargo, en el día a día en el trabajo te puedes encontrar cualquier cosa y las columnas no se llamen así. Si te encuentras con el caso siempre pregunta por un data dictionary, sería lo primero que deberías pedir. Sin embargo, parece que nadie los necesita ( en realidad quiero decir usa´)

Así que vamos a tener un

FROM // De esta tabla
JOIN // Juntamos  con esta otra tabla
ON // las columnas que nos sirven para juntar porque son las mismas

Antes de nuestro JOIN
nos vamos a encontrar la segunda tabla. El orden de las tablas es importante porque hay diferentes tipos de JOINs y eso va a influenciar también. Esto también es otra historia... Y justo detrás del ON vamos a poner las columnas que son iguales en ambas tablas. Como estamos juntando dos tablas que pueden tener el mismo nombre de columnas (ideally) o no, debemos poner el nomber de la tabla antes de la columna. Por lo tanto
meals(tabla) . meal.id(columna)

OK; Vamos allá,
SELECT price, quantity-order
  FROM meals
  JOIN orders ON meals.meal_id = orders.meal_id
WHERE user_id = 10;
Ahora tenemos todas las columnas a nuestra disposición.
Pero wait a minute, si yo selecciono precio y order de la primera tabla y esa columna está en la segunda tabla  (la que va después del JOIN). Cómo puede ser que no necesite poner como sintaxis order.quantity-order ?

* En realidad puedes ponerlo pero eso significa dar más complejidad y ensuciar la Query. El tema aquí es que la query va a ser leída como un todo, no de forma secuencial. Así que primero se ejecutará el FROM y el JOIN y de forma recursiva se irá ejecutando las demás partes de la query.

Y esta fue mi cara tras una semana revisando oráculos intentando encontrar la respuesta y acabar leyendola en una cheatsheet


via GIPHY

En qué orden se ejecuta una query en SQL

Yendo por partes, cómo se va a ejecutar esto.


  1. PRIMERO se ejecuta FROM-JOIN
  2. Después WHERE
  3. Más tarde todo lo que hay debajo del WHERE como GROUP BY y HAVING
  4. Finalmente SELECT
  5. En quinto lugar tenemos el disctinct (dónde), order by y limit/offset que en realidad es una forma de formatear la query que queremos una vez que tenemos los datos.
Logicamente todo puede ser más complicado con subqueries pero las subqueries serán ejecutadas en

Dónde se sejecuta una subquery en SQL 


  • SELECT
  • FROM
  • WHERE


Y esta fue la cara con la que el manual me miró. Bueno, de forma figurada claro.


via GIPHY


sábado, 3 de febrero de 2018

Calcular Unique Visitors en eCommerce usando BigQuery

 Como calcular Unique Visitor para Channel Grouping de Google Analytics

Uno de las metricas mas importantes para un analista web son los unique visitors. Hasta ahora para conseguir esta metrica en BigQuery debemos usar el fullVisitorId que es semejante a userID

La siguiente consulta nos muestra como conseguir los unique visitors de cada canal del Channel Grouping de 

- nuestro proyecto llamado misdatos

- donde hemos exportado una tabla con todas las sesiones

Qué hace este código SQL?

Google Analytics nos proporciana el fullVisitorId, y para poder contar los no duplicados necesitamos usar DISTINCT. Con el AS creamos ademas el nombre de la nueva variable que vamos a llamar unique_visitors - visitantes unicos.



Otras  métricas similares se pueden encontrar en la tabla de abajo, actualizado a Agosto 2021. Actualmente ha quedado como deprecated el visitorID y ha aparecido (desde mediados de 2018) otra métrica que si que podemos encontrar como tal aparece en en la interface de Google Analytics, el ClientID. 


Más info sobre BigQuery






miércoles, 16 de agosto de 2017

Refrescando mis conocimientos de SQL

Ahora que he acabo del master y estoy y estoy otra vez en busqueda de empleo me he encontrado con el siguiente tema: ahora debo saber tambien SQL.

El tema es que yo ya sabia toda la teoria de base de datos relacionales en el Tecnico de Desarrollo de Aplicaciones Informaticas y ademas he tenido que ampliar este conocimiento con lo del master (que ademas versaba sobre base de datos noSQL, pero teniamos un tema de crea base de datos con MySQL). Sin embargo como gran parte de los datos que uso los analizo con las librerias de R y de Python, no he tenido necesidad de hacer mas cursos de SQL.

 Pero claro al llegar a la entrevista y decir que en mi ultimo puesto no usaba SQL (pq no tenia acceso a los datos de la base de datos directamente 😣) pues parece que no es muy convincente. Asi que manos a la obra para refrescar todo esto.

El fin de semana pasado en el Measurecamp estube hablando con un analista de este tema. SQL no es dificil de aprender si sabes como funciona. Ademas, cuando explicaba a unos amigos (developers) el momento en la entrevista que me pregunta por esto directamente me dijeron: buaaah, en un mes te da aprender todo el SQL q puedas necesitar.

Asi que llevo unas semanas actualilzando mis conocimientos en SQL y la verdad. SQL no tiene ningun misterio: aqui un resumen si nunca lo has usado

Como es una sentencia en SQL (se pronuncia "siquel" en ingles)


SELECT name, age FROM customers WHERE age > 18 ORDER BY  age

SELECT -> aqui se seleccionan las variables. Si quieres seleccionarlas todas ellas debes poner un *
FROM -> la tabla donde quieras seleccionar esas variables
---
WHERE-> la condicion que quieras que se cumpla: una fecha (ej. year = 2016),

ORDER BY -> ordenado por la variable que quieras.

Todo muy facil hasta aqui. En datacamp tienes un curso que puedes encontrar mas abajo. .Si quieres puedes jugar un poco con esto, pero si lo has utilizado anteriormente n un par de horas lo tienes hecho.

Aqui tienes el curso:
Curso iniciacion sobre SQL


Una vez que ya sabes como funciona el lenguaje (facilillo no?) viene el tema de poder utilizar varias tablas. Aqui la cosa ya se complica un poco mas, sobre todo porque dependiendo de la base de datos vamos a poder utilizar un dialecto de SQL u otro. En realidad esto no es mas que una extension del propio lenguaje SQL para darle mas funcionalidades a este.  Al fin y al cabo SQL es muy parecido pero cada "dialecto" te va a hacer la vida mas facil o mas complicada en cada caso a la hora de hacer queries.

Por ejemplo aqui puedes ver las diferencias entre Transact SQL y PostgresSQL.Pero, para resumir el primero lo usa Microsofts,y por tanto sus bases de datos SQL server y demas, mientras que el segundo lo utilizan muchas bases de datos abiertas.

Pero volviendo al tema...

Si queremos utilizar dos tablas o mas!, como vamos a poder juntar las tablas?
Pues logicamente vamos a necesitar que tengan un indice( columna) en comun. Para ellos vamos a tener en cada tabla alguna columna que se repita en otra tabla, aunque no tenga el mismo nombre, eso nos va a dar igual porque vamos a poder renombrarla.

Si usas Excel, piensa en como funciona unVLOOKUP (o buscarV). Tienes una columna que comparas con otras, pues eso. No tiene mas.Bueno, un poquico mas solo

En funcion de las necesidades cuando vayamos q juntar estas dos tablas (join las tablas) tenemos determinadas formas de hacerlo:

Podemos querer copiar todo lo que se queda a la derecha de la primera tabla o a la izquierda o solo vamos querer quedarnos con las columnas que tengan en comun. Para esto tenemos diferentes tipos de join (left-join,right-join, inner-join).


miércoles, 3 de febrero de 2016

Segmentando con el modelo RFM con SQL : Recency, Frequency & Monetary value

Si contamos con una base de datos de clientes podemos aplicar un modelo bastante fácil y que ya lleva bastante rodaje en el Marketing Directo:el modelo RFM.

¿Qué es RFM?

El fin de este modelo es poder segmentar a nuestros clientes para saber cuales son los que mayor beneficio nos puede aportar. Así a esos clientes podemos mandarles códigos promocionales, por poner un ejemplo.

Descuartizando el modelo RFM

¿Qué significan cada una de esas letras?
  • Recency: que podríamos describir como recencia.
  • ¿Hace cuánto que compró el cliente? Si el cliente hace mucho que no ha comprado puede ser que se haya ido a la competencia.
  • Frecuency: Frecuencia
  • ¿Con qué frecuencia suele comprar?
  • Monetary Value: valor monetario
Cantidad de dinero que ha gastado de media. Si un cliente suele gastar más será más valioso que otro que suele hacer una compra pequeña.

Cómo definimos RFM en una sentencia de SQL

  • La recencia ("recency") viene definida por el día de la última compra: MIN(dias_desde_la_ultima_compra).
  • La frecuencia ("frequency") viene definida por el total de veces que el cliente ha comprado.
  • El valor monetario ("monetary value"), en este caso, lo vamos a definir como la media de la cantidad comprada de cada uno de los clientes.
Imaginando un CRM con un id por cliente podríamos definir la query como: SELECT cliente_id,
MIN(dias_desde_ultima_compra) AS 'recencia',
COUNT(*) AS 'frecuencia',
AVG(cantidad_comprada) AS 'valor monetario'
FROM data GROUP BY 1")
Al ser en SQL la podríamos usar tanto R como en Python, o cualquier otro lenguaje de programación.