SQL para análisis de datos

Capítulo 1. Análisis con SQL

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: [e-mail]

Si estás leyendo este libro, probablemente estés interesado en el análisis de datos y en utilizar SQL para llevarlo a cabo. Puede que tengas experiencia en el análisis de datos pero seas nuevo en SQL, o puede que tengas experiencia en SQL pero seas nuevo en el análisis de datos. O puede que seas totalmente nuevo en ambos temas. Sea cual sea tu punto de partida, este capítulo sienta las bases para los temas que se tratan en el resto del libro y se asegura de que tengamos un vocabulario común. Empezaré hablando de lo que es el análisis de datos y luego pasaré a hablar de SQL: qué es, por qué es tan popular, cómo se compara con otras herramientas y cómo encaja en el análisis de datos. Luego, dado que el análisis de datos moderno está tan entrelazado con las tecnologías que lo han hecho posible, concluiré con un debate sobre los distintos tipos de bases de datos que puedes encontrar en tu trabajo, por qué se utilizan y qué significa todo eso para el SQL que escribes.

¿Qué es el análisis de datos?

Recoger y almacenar datos para su análisis es una actividad muy humana. Los sistemas de seguimiento de los almacenes de grano, los impuestos y la población se remontan a miles de años atrás, y las raíces de la estadística se remontan a cientos de años atrás. Las disciplinas relacionadas, como el control estadístico de procesos, la investigación operativa y la cibernética, explotaron en el siglo XX. Se utilizan muchos nombres diferentes para describir la disciplina del análisis de datos, como inteligencia empresarial (BI), analítica, ciencia de los datos y ciencia de la decisión, y los profesionales tienen una amplia gama de cargos. El análisis de datos también lo llevan a cabo vendedores, gestores de productos, analistas empresariales y otras muchas personas. En este libro, utilizaré los términos analista de datos y científico de datos indistintamente para referirme a la persona que trabaja con SQL para comprender los datos. Me referiré al software utilizado para crear informes y cuadros de mando como herramientas de BI.

El análisis de datos en el sentido contemporáneo fue posible gracias a la historia de la informática y está entrelazado con ella. Las tendencias tanto en la investigación como en la comercialización le han dado forma, y la historia incluye un quién es quién de investigadores y grandes empresas, de las que hablaremos en la sección sobre SQL. El análisis de datos combina la potencia de la informática con técnicas de la estadística tradicional. El análisis de datos es en parte descubrimiento de datos, en parte interpretación de datos y en parte comunicación de datos. Muy a menudo, el propósito del análisis de datos es mejorar la toma de decisiones, por parte de los humanos y, cada vez más, por parte de las máquinas mediante la automatización.

Una metodología sólida es fundamental, pero el análisis es algo más que producir el número correcto. Se trata de curiosidad, de hacer preguntas y del "por qué" de las cifras. Se trata de patrones y anomalías, de descubrir e interpretar pistas sobre cómo se comportan las empresas y los seres humanos. A veces, el análisis se realiza sobre un conjunto de datos recopilados para responder a una pregunta concreta, como en un entorno científico o en un experimento en línea. El análisis también se realiza sobre datos que se generan como resultado de hacer negocios, como en las ventas de los productos de una empresa, o que se generan con fines analíticos, como el seguimiento de la interacción del usuario en sitios web y aplicaciones móviles. Estos datos tienen una amplia gama de posibles aplicaciones, desde la resolución de problemas a la planificación de mejoras de la interfaz de usuario (IU), pero a menudo llegan en un formato y volumen tales que los datos necesitan ser procesados antes de ofrecer respuestas. El Capítulo 2 tratará sobre la preparación de los datos para el análisis, y el Capítulo 8 tratará algunas de las cuestiones éticas y de privacidad con las que todos los profesionales de los datos deberían estar familiarizados.

Es difícil pensar en una industria que no se haya visto afectada por el análisis de datos: la industria manufacturera, el comercio minorista, las finanzas, la sanidad, la educación e incluso la administración pública han cambiado gracias a él. Los equipos deportivos han empleado el análisis de datos desde los primeros años del mandato de Billy Beane como director general de los Oakland Athletics, hecho famoso por el libro de Michael Lewis Moneyball (Norton). El análisis de datos se utiliza en marketing, ventas, logística, desarrollo de productos, diseño de la experiencia del usuario, centros de asistencia, recursos humanos y mucho más. La combinación de técnicas, aplicaciones y potencia informática ha dado lugar a la explosión de campos relacionados, como la ingeniería de datos y la ciencia de datos.

El análisis de datos se hace por definición sobre datos históricos, y es importante recordar que el pasado no predice necesariamente el futuro. El mundo es dinámico, y las organizaciones también lo son: se introducen nuevos productos y procesos, los competidores suben y bajan, los climas sociopolíticos cambian. Se critica el análisis de datos por mirar hacia atrás. Aunque esa caracterización es cierta, he visto organizaciones que obtienen un enorme valor del análisis de datos históricos. Extraer datos históricos nos ayuda a comprender las características y el comportamiento de los clientes, los proveedores y los procesos. Los datos históricos pueden ayudarnos a desarrollar estimaciones informadas y rangos de predicción de resultados, que a veces serán erróneos, pero muy a menudo serán correctos. Los datos históricos pueden señalar lagunas, puntos débiles y oportunidades. Permiten a las organizaciones optimizar, ahorrar dinero y reducir el riesgo y el fraude. También pueden ayudar a las organizaciones a encontrar oportunidades, y pueden convertirse en los componentes básicos de nuevos productos que deleiten a los clientes.

Nota

Hoy en día son pocas las organizaciones que no realizan algún tipo de análisis de datos, pero todavía hay algunas que se resisten. ¿Por qué algunas organizaciones no utilizan el análisis de datos? Un argumento es la relación coste-valor. Recopilar, procesar y analizar datos requiere trabajo y cierto nivel de inversión financiera. Algunas organizaciones son demasiado nuevas, o son demasiado desordenadas. Si no existe un proceso coherente, es difícil generar datos lo suficientemente consistentes como para analizarlos. Por último, hay consideraciones éticas. Recoger o almacenar datos sobre determinadas personas en determinadas situaciones puede estar regulado o incluso prohibido. Los datos sobre niños e intervenciones sanitarias son delicados, por ejemplo, y existe una amplia normativa en torno a su recopilación. Incluso las organizaciones que se rigen por los datos deben tener cuidado con la privacidad de los clientes y pensar detenidamente qué datos deben recopilarse, por qué son necesarios y durante cuánto tiempo deben almacenarse. Normativas como el Reglamento General de Protección de Datos de la Unión Europea, o GDPR, y la Ley de Privacidad del Consumidor de California, o CCPA, han cambiado la forma en que las empresas piensan sobre los datos de los consumidores. Trataremos estas normativas con más profundidad en el Capítulo 8. Como profesionales de los datos, debemos pensar siempre en las implicaciones éticas de nuestro trabajo.

Cuando trabajo con organizaciones, me gusta decir a la gente que el análisis de datos no es un proyecto que termina en una fecha fija: es una forma de vida. Desarrollar una mentalidad basada en los datos es un proceso, y cosechar los frutos es un viaje. Lo desconocido se convierte en conocido, las preguntas difíciles se van desmenuzando hasta que hay respuestas, y la información más crítica se incorpora a cuadros de mando que impulsan las decisiones tácticas y estratégicas. Con esta información, se plantean preguntas nuevas y más difíciles, y entonces se repite el proceso.

El análisis de datos es a la vez accesible para los que quieren iniciarse y difícil de dominar. La tecnología se puede aprender, sobre todo SQL. Muchos problemas, como la optimización del gasto en marketing o la detección del fraude, son familiares y se trasladan a todas las empresas. Cada organización es diferente y cada conjunto de datos tiene peculiaridades, por lo que incluso los problemas familiares pueden plantear nuevos retos. Comunicar los resultados es una habilidad. Aprender a hacer buenas recomendaciones y convertirse en un socio de confianza de una organización lleva tiempo. Según mi experiencia, un análisis sencillo presentado de forma persuasiva tiene más impacto que un análisis sofisticado mal presentado. El éxito del análisis de datos también requiere colaboración. Puedes tener grandes ideas, pero si no hay nadie que las ejecute, no habrás tenido realmente ningún impacto. Incluso con toda la tecnología, sigue tratándose de personas, y las relaciones importan.

¿Por qué SQL?

Esta sección describe qué es SQL, las ventajas de utilizarlo, cómo se compara con otros lenguajes utilizados habitualmente para el análisis y, por último, cómo encaja SQL en el flujo de trabajo del análisis.

¿Qué es SQL?

SQL es el lenguaje utilizado para comunicarse con las bases de datos. El acrónimo significa Lenguaje de Consulta Estructurado y se pronuncia como "sequel" o diciendo cada letra, como en "ess cue el". Ésta es sólo la primera de las muchas controversias e incoherencias en torno a SQL que veremos, pero la mayoría de la gente sabrá lo que quieres decir independientemente de cómo lo digas. Existe cierto debate sobre si SQL es o no un lenguaje de programación. No es un lenguaje de propósito general como lo son C o Python. SQL sin una base de datos y datos en tablas es sólo un archivo de texto. SQL no puede construir un sitio web, pero es potente para trabajar con datos en bases de datos. A nivel práctico, lo que más importa es que SQL pueda ayudarte a realizar el trabajo de análisis de datos.

IBM fue la primera en desarrollar bases de datos SQL, a partir del modelo relacional inventado por Edgar Codd en los años 60. El modelo relacional era una descripción teórica para gestionar datos mediante relaciones. Al crear las primeras bases de datos, IBM contribuyó al avance de la teoría, pero también tuvo consideraciones comerciales, al igual que Oracle, Microsoft y todas las demás empresas que han comercializado una base de datos desde entonces. Desde el principio, ha habido tensión entre la teoría informática y la realidad comercial. SQL se convirtió en una norma de la Organización Internacional de Normalización (ISO) en 1987 y en una norma del Instituto Nacional Estadounidense de Normalización (ANSI) en 1986. Aunque todas las bases de datos importantes parten de estas normas en su implementación de SQL, muchas tienen variaciones y funciones que facilitan la vida a los usuarios de esas bases de datos. Esto tiene el coste de hacer que SQL sea más difícil de trasladar entre bases de datos sin algunas modificaciones.

SQL se utiliza para acceder, manipular y recuperar datos de los objetos de una base de datos. Las bases de datos pueden tener uno o varios esquemas, que proporcionan la organización y la estructura y contienen otros objetos. Dentro de un esquema, los objetos más utilizados en el análisis de datos son las tablas, las vistas y las funciones. Las tablas contienen campos, que contienen los datos. Las tablas pueden tener uno o varios índices; un índice es un tipo especial de estructura de datos que permite recuperar datos con mayor eficacia. Los índices suelen ser definidos por un administrador de la base de datos. Las vistas son esencialmente consultas almacenadas a las que se puede hacer referencia del mismo modo que a una tabla. Las funciones permiten almacenar conjuntos de cálculos o procedimientos de uso común y referenciarlos fácilmente en las consultas. Suelen ser creadas por un administrador de bases de datos, o DBA. La Figura 1-1 ofrece una visión general de la organización de las bases de datos.

Figura 1-1. Visión general de la organización y los objetos de una base de datos

Para comunicarse con las bases de datos, SQL dispone de cuatro sublenguajes para abordar diferentes tareas, y éstos son en su mayoría estándar en todos los tipos de bases de datos. La mayoría de las personas que trabajan en el análisis de datos no necesitan recordar los nombres de estos sublenguajes a diario, pero pueden surgir en una conversación con administradores de bases de datos o ingenieros de datos, así que los presentaré brevemente. Todos los comandos funcionan juntos con fluidez, y algunos pueden coexistir en la misma sentencia SQL.

DQL, o lenguaje de consulta de datos, es de lo que trata principalmente este libro. Se utiliza para consultar datos, lo que puede considerarse como utilizar código para hacer preguntas a una base de datos. Los comandos DQL incluyen SELECT, que resultará familiar a los usuarios anteriores de SQL, pero el acrónimo DQL no se utiliza con frecuencia según mi experiencia. Las consultas SQL pueden ser tan cortas como una sola línea o abarcar varias decenas de líneas. Las consultas SQL pueden acceder a una única tabla (o vista), pueden combinar datos de varias tablas mediante el uso de uniones y también pueden consultar varios esquemas de la misma base de datos. Por lo general, las consultas SQL no pueden realizar consultas a través de bases de datos, pero en algunos casos se pueden utilizar configuraciones de red inteligentes o software adicional para recuperar datos de múltiples fuentes, incluso de bases de datos de distintos tipos. Las consultas SQL son autónomas y, aparte de las tablas, no hacen referencia a variables o resultados de pasos anteriores que no estén contenidos en la consulta, a diferencia de los lenguajes de programación.

El DDL, o lenguaje de definición de datos, se utiliza para crear y modificar tablas, vistas, usuarios y otros objetos de la base de datos. Afecta a la estructura, pero no al contenido. Hay tres comandos comunes: CREAR, ALTERAR y ELIMINAR. CREAR se utiliza para crear nuevos objetos. ALTER cambia la estructura de un objeto, por ejemplo añadiendo una columna a una tabla. DROP elimina todo el objeto y su estructura. Puede que oigas a los DBA y a los ingenieros de datos hablar de trabajar con DDL, que en realidad es una forma abreviada de referirse a los archivos o fragmentos de código que crean, modifican o eliminan. Un ejemplo de cómo se utilizan los DDL en el contexto del análisis es el código para crear tablas temporales.

DCL, o lenguaje de control de datos, se utiliza para el control de acceso. Los comandos incluyen GRANT y REVOKE, que dan permiso y quitan permiso, respectivamente. En un contexto de análisis, GRANT puede ser necesario para permitir que un colega consulte una tabla que tú has creado. También puedes encontrarte con un comando de este tipo cuando alguien te ha dicho que una tabla existe en la base de datos pero no puedes verla: puede que sea necesario concederpermisos a tu usuario.

El DML, o lenguaje de manipulación de datos, se utiliza para actuar sobre los propios datos. Los comandos son INSERTAR, ACTUALIZAR y ELIMINAR. INSERTAR añade nuevos registros y es esencialmente el paso de "carga" en extraer, transformar, cargar (ETL). UPDATE cambia los valores de un campo y DELETE elimina filas. Te encontrarás con estos comandos si tienes algún tipo de tablas autogestionadas -tablas temporales, tablas sandbox- o si te encuentras en el papel tanto de propietario como de analizador de la base de datos.

Estos cuatro sublenguajes están presentes en las principales bases de datos. En este libro, me centraré principalmente en DQL. Tocaremos algunos comandos DDL y DML en el Capítulo 8, y también verás algunos ejemplos en el sitio GitHub del libro, donde se utilizan para crear y rellenar los datos utilizados en los ejemplos. Gracias a este conjunto común de comandos, el código SQL escrito para cualquier base de datos resultará familiar a cualquiera que esté acostumbrado a trabajar con SQL. Sin embargo, leer SQL de otra base de datos puede parecer un poco como escuchar a alguien que habla el mismo idioma que tú pero viene de otra parte del país o del mundo. La estructura básica del lenguaje es la misma, pero la jerga es diferente, y algunas palabras tienen significados totalmente distintos. Las variaciones en SQL de una base de datos a otra suelen denominarse dialectos, y los usuarios de bases de datos harán referencia a Oracle SQL, MSSQL u otros dialectos.

Aun así, una vez que conozcas SQL, podrás trabajar con distintos tipos de bases de datos siempre que prestes atención a detalles como el manejo de nulos, fechas y marcas de tiempo; la división de enteros; y la distinción entre mayúsculas y minúsculas.

Este libro utiliza PostgreSQL, o Postgres, para los ejemplos, aunque intentaré señalar dónde el código sería significativamente diferente en otros tipos de bases de datos. Puedes instalar Postgres en un ordenador personal para seguir los ejemplos.

Ventajas de SQL

Hay muchas buenas razones para utilizar SQL para el análisis de datos, desde la potencia de cálculo hasta su ubicuidad en las herramientas de análisis de datos y su flexibilidad.

Quizás la mejor razón para utilizar SQL es que gran parte de los datos del mundo ya están en bases de datos. Es probable que tu propia organización tenga una o más bases de datos. Incluso si los datos no están ya en una base de datos, cargarlos en una puede merecer la pena para aprovechar las ventajas informáticas y de almacenamiento, sobre todo si se comparan con alternativas como las hojas de cálculo. La potencia de cálculo se ha disparado en los últimos años, y los almacenes de datos y la infraestructura de datos han evolucionado para aprovecharla. Algunas bases de datos en la nube más recientes permiten consultar grandes cantidades de datos en memoria, lo que acelera aún más las cosas. Los días de esperar minutos u horas a que volvieran los resultados de las consultas pueden haber terminado, aunque los analistas pueden limitarse a escribir consultas más complejas en respuesta.

SQL es la norma de facto para interactuar con las bases de datos y recuperar datos de ellas. Una amplia gama de software popular se conecta a las bases de datos con SQL, desde hojas de cálculo a herramientas de BI y visualización y lenguajes de codificación como Python y R (que se tratan en la siguiente sección). Debido a los recursos informáticos disponibles, realizar tanta manipulación y agregación de datos como sea posible en la base de datos suele tener ventajas a posteriori. En el Capítulo 8 trataremos en profundidad las estrategias para crear conjuntos de datos complejos para las herramientas posteriores.

Los componentes básicos de SQL pueden combinarse de infinitas maneras. Partiendo de un número relativamente pequeño de bloques de construcción -la sintaxis-, SQL puede realizar una amplia gama de tareas. SQL puede desarrollarse de forma iterativa, y es fácil revisar los resultados sobre la marcha. Puede que no sea un lenguaje de programación en toda regla, pero puede hacer mucho, desde transformar datos hasta realizar cálculos complejos y responder preguntas.

Por último, SQL es relativamente fácil de aprender, con una sintaxis finita. Puedes aprender las palabras clave y la estructura básicas rápidamente y luego perfeccionar tu destreza con el tiempo trabajando con conjuntos de datos variados. Las aplicaciones de SQL son prácticamente infinitas, si tienes en cuenta la variedad de conjuntos de datos que hay en el mundo y las posibles preguntas que se pueden hacer a los datos. SQL se enseña en muchas universidades, y muchas personas adquieren algunas habilidades en el trabajo. Incluso los empleados que aún no tienen conocimientos de SQL pueden recibir formación, y la curva de aprendizaje puede ser más fácil que la de otros lenguajes de programación. Esto hace que el almacenamiento de datos para su análisis en bases de datos relacionales sea una opción lógica para las organizaciones.

SQL frente a R o Python

Aunque SQL es un lenguaje popular para el análisis de datos, no es la única opción. R y Python se encuentran entre los más populares de los otros lenguajes utilizados para el análisis de datos. R es un lenguaje estadístico y de gráficos, mientras que Python es un lenguaje de programación de uso general que tiene puntos fuertes en el trabajo con datos. Ambos son de código abierto, pueden instalarse en un ordenador portátil y tienen comunidades activas que desarrollan paquetes, o extensiones, que abordan diversas tareas de manipulación y análisis de datos. Elegir entre R y Python está fuera del alcance de este libro, pero hay muchos debates en Internet sobre las ventajas relativas de cada uno. Aquí los consideraré conjuntamente como lenguajes de programación alternativos a SQL.

Una diferencia importante entre SQL y otros lenguajes de codificación es dónde se ejecuta el código y, por tanto, cuánta potencia de cálculo hay disponible. SQL siempre se ejecuta en un servidor de base de datos, aprovechando todos sus recursos informáticos. Para realizar análisis, R y Python suelen ejecutarse localmente en tu máquina, por lo que los recursos informáticos están limitados por lo que haya disponible localmente. Por supuesto, hay muchas excepciones: las bases de datos pueden ejecutarse en ordenadores portátiles, y R y Python pueden ejecutarse en servidores con más recursos. Cuando vayas a realizar algo que no sea el análisis más sencillo de grandes conjuntos de datos, es una buena opción trasladar el trabajo a un servidor de bases de datos con más recursos. Dado que las bases de datos suelen estar configuradas para recibir continuamente nuevos datos, SQL también es una buena opción cuando un informe o cuadro de mando necesita actualizarse periódicamente.

Una segunda diferencia está en cómo se almacenan y organizan los datos. Las bases de datos relacionales siempre organizan los datos en filas y columnas dentro de tablas, por lo que SQL asume esta estructura para cada consulta. R y Python tienen una mayor variedad de formas de almacenar datos, como variables, listas y diccionarios, entre otras opciones. Éstas proporcionan más flexibilidad, pero a costa de una curva de aprendizaje más pronunciada. Para facilitar el análisis de datos, R dispone de marcos de datos, que son similares a las tablas de las bases de datos y organizan los datos en filas y columnas. El paquete pandas hace que los DataFrames estén disponibles en Python. Incluso cuando se dispone de otras opciones, la estructura de tabla sigue siendo valiosa para el análisis.

Los bucles son otra diferencia importante entre SQL y la mayoría de los demás lenguajes de programación informática. Un bucle es una instrucción o un conjunto de instrucciones que se repiten hasta que se cumple una condición especificada. Las agregaciones SQL realizan implícitamente un bucle sobre el conjunto de datos, sin necesidad de código adicional. Veremos más adelante cómo la falta de capacidad para hacer bucles sobre los campos puede dar lugar a largas sentencias SQL cuando se pivotan o despivotan datos. Aunque un debate más profundo queda fuera del alcance de este libro, algunos proveedores han creado extensiones de SQL, como PL/SQL en Oracle y T-SQL en Microsoft SQL Server, que permiten funcionalidades como la de bucle.

Un inconveniente de SQL es que tus datos deben estar en una base de datos,¹ mientras que R y Python pueden importar datos de archivos almacenados localmente o pueden acceder a archivos almacenados en servidores o sitios web. Esto es conveniente para muchos proyectos puntuales. Se puede instalar una base de datos en un ordenador portátil, pero esto añade una capa adicional de sobrecarga. En la otra dirección, paquetes como dbplyr para R y SQLAlchemy para Python permiten a los programas escritos en esos lenguajes conectarse a bases de datos, ejecutar consultas SQL y utilizar los resultados en otros pasos del procesamiento. En este sentido, R o Python pueden ser complementarios de SQL.

Tanto R como Python disponen de sofisticadas funciones estadísticas incorporadas o disponibles en paquetes. Aunque SQL tiene, por ejemplo, funciones para calcular la media y la desviación típica, los cálculos de los valores p y la significación estadística que se necesitan en el análisis de experimentos (que se tratan en el Capítulo 7) no pueden realizarse sólo con SQL. Además de la estadística sofisticada, el aprendizaje automático es otra área que se aborda mejor con uno de estos otros lenguajes de codificación.

Cuando decidas si utilizar SQL, R o Python para un análisis, tenlo en cuenta:

• ¿Dónde se encuentran los datos: en una base de datos, un archivo, un sitio web?

• ¿Cuál es el volumen de datos?

• ¿Adónde van los datos: a un informe, a una visualización, a un análisis estadístico?

• ¿Necesitará actualizarse o refrescarse con nuevos datos? ¿Con qué frecuencia?

• ¿Qué utiliza tu equipo u organización, y qué importancia tiene ajustarse a las normas existentes?

No faltan los debates sobre qué lenguajes y herramientas son los mejores para hacer análisis de datos o ciencia de datos. Como ocurre con muchas cosas, a menudo hay más de una forma de realizar un análisis. Los lenguajes de programación evolucionan y cambian en popularidad, y tenemos suerte de vivir y trabajar en una época con tantas buenas opciones. SQL existe desde hace mucho tiempo y probablemente seguirá siendo popular en los próximos años. El objetivo final es utilizar la mejor herramienta disponible para el trabajo. Este libro te ayudará a sacar el máximo partido de SQL para el análisis de datos, independientemente de qué otras herramientas tengas.

SQL como parte del flujo de trabajo del análisis de datos

Ahora que ya he explicado qué es SQL, he hablado de algunas de sus ventajas y lo he comparado con otros lenguajes, pasaremos a hablar de dónde encaja SQL en el proceso de análisis de datos. El trabajo de análisis siempre empieza con una pregunta, que puede ser sobre cuántos clientes nuevos se han captado, cómo evolucionan las ventas o por qué algunos usuarios permanecen durante mucho tiempo mientras que otros prueban un servicio y nunca vuelven. Una vez formulada la pregunta, consideramos dónde se originaron los datos, dónde se almacenan, el plan de análisis y cómo se presentarán los resultados al público. La Figura 1-2 muestra los pasos del proceso. Las consultas y el análisis son el tema central de este libro, aunque hablaré brevemente de los demás pasos para situar la etapa de consultas y análisis en un contexto más amplio.

Figura 1-2. Pasos del proceso de análisis de datos

En primer lugar, los datos son generados por sistemas fuente, término que incluye cualquier proceso humano o mecánico que genere datos de interés. Los datos pueden ser generados por personas a mano, como cuando alguien rellena un formulario o toma notas durante una visita al médico. Los datos también pueden ser generados por máquinas, como cuando una base de datos de aplicaciones registra una compra, un sistema de flujo de eventos registra un clic en un sitio web o una herramienta de gestión de marketing registra la apertura de un correo electrónico. Los sistemas fuente pueden generar muchos tipos y formatos diferentes de datos, y el Capítulo 2 los tratará con más detalle, así como el modo en que el tipo de fuente puede afectar al análisis.

El segundo paso consiste en trasladar los datos y almacenarlos en una base de datos para su análisis. Utilizaré los términos almacén de datos, que es una base de datos que consolida los datos de toda una organización en un repositorio central, y almacén de datos, que se refiere a cualquier tipo de sistema de almacenamiento de datos que pueda consultarse. Otros términos que puedes encontrar son data mart, que suele ser un subconjunto de un almacén de datos, o un almacén de datos con un enfoque más limitado; y data lake, un término que puede significar que los datos residen en un sistema de almacenamiento de archivos o que se almacenan en una base de datos, pero sin el grado de transformación de datos que es habitual en los almacenes de datos. Los almacenes de datos van de pequeños y sencillos a enormes y caros. Una base de datos que se ejecute en un ordenador portátil será suficiente para que sigas los ejemplos de este libro. Lo que importa es tener los datos que necesitas para realizar un análisis reunidos en un solo lugar.

Nota

Normalmente, una persona o equipo se encarga de introducir los datos en el almacén de datos. Este proceso se denomina ETL, o extraer, transformar, cargar. La extracción extrae los datos del sistema fuente. La transformación modifica opcionalmente la estructura de los datos, realiza una limpieza de la calidad de los datos o los agrega. La carga introduce los datos en la base de datos. Este proceso también puede denominarse ELT, de extraer, cargar, transformar, con la diferencia de que, en lugar de realizar las transformaciones antes de cargar los datos, se cargan todos los datos y luego se realizan las transformaciones, normalmente mediante SQL. También es posible que oigas los términos fuente y destino en el contexto de la ETL. La fuente es de donde proceden los datos, y el objetivo es el destino, es decir, la base de datos y las tablas que contiene. Incluso cuando se utiliza SQL para hacer la transformación, se utiliza otro lenguaje, como Python o Java, para unir los pasos, coordinar la programación y emitir alertas cuando algo va mal. Existen varios productos comerciales, así como herramientas de código abierto, para que los equipos no tengan que crear un sistema ETL totalmente desde cero.

Una vez que los datos están en una base de datos, el siguiente paso es realizar consultas y análisis. En este paso, se aplica SQL para explorar, perfilar, limpiar, dar forma y analizar los datos. La Figura 1-3 muestra el flujo general del proceso. Explorar los datos implica familiarizarse con el tema, dónde se generaron los datos y las tablas de la base de datos en las que están almacenados. Perfilar implica comprobar los valores únicos y la distribución de los registros en el conjunto de datos. La limpieza implica corregir los datos incorrectos o incompletos, añadir categorizaciones y banderas, y tratar los valores nulos. Dar forma es el proceso de organizar los datos en las filas y columnas necesarias en el conjunto de resultados. Por último, el análisis de los datos consiste en revisar los resultados en busca de tendencias, conclusiones e ideas. Aunque este proceso se muestra como lineal, en la práctica suele ser cíclico; por ejemplo, cuando la conformación o el análisis revelan datos que deben limpiarse.

Figura 1-3. Etapas dentro del paso de consultas y análisis del flujo de trabajo de análisis

La presentación de los datos en un formato de salida final es el último paso del flujo de trabajo global. A los empresarios no les gustará recibir un archivo de código SQL; esperan que presentes gráficos, tablas y perspectivas. La comunicación es clave para tener un impacto con el análisis, y para ello necesitamos una forma de compartir los resultados con otras personas. En otras ocasiones, puede que necesites aplicar un análisis estadístico más sofisticado de lo que es posible en SQL, o puede que quieras introducir los datos en un algoritmo de aprendizaje automático (ML). Afortunadamente, la mayoría de las herramientas de elaboración de informes y visualización tienen conectores SQL que te permiten extraer datos de tablas enteras o de consultas SQL preescritas. El software estadístico y los lenguajes utilizados habitualmente para el ML también suelen tener conectores SQL.

Los flujos de trabajo de análisis abarcan una serie de pasos y a menudo incluyen múltiples herramientas y tecnologías. Las consultas y análisis SQL son el núcleo de muchos análisis y es en lo que nos centraremos en los siguientes capítulos. El Capítulo 2 tratará sobre los tipos de sistemas fuente y los tipos de datos que generan. El resto de este capítulo echará un vistazo a los tipos de bases de datos que es probable que encuentres en tu viaje de análisis.

Tipos de bases de datos y cómo trabajar con ellas

Si trabajas con SQL, trabajarás con bases de datos. Hay una amplia gama de tipos de bases de datos: de código abierto a propietarias, de almacenamiento de filas a almacenamiento de columnas. Hay bases de datos locales y bases de datos en la nube, así como bases de datos híbridas, en las que una organización ejecuta el software de la base de datos en la infraestructura de un proveedor en la nube. También hay una serie de almacenes de datos que no son bases de datos en absoluto, pero que se pueden consultar con SQL.

Las bases de datos no son todas iguales; cada tipo de base de datos tiene sus puntos fuertes y débiles cuando se trata de trabajo de análisis. A diferencia de las herramientas utilizadas en otras partes del flujo de trabajo de análisis, puede que no tengas mucho que decir sobre qué tecnología de base de datos se utiliza en tu organización. Conocer los entresijos de la base de datos que tengas te ayudará a trabajar con más eficacia y a aprovechar las funciones SQL especiales que ofrezca. La familiaridad con otros tipos de bases de datos te ayudará si te encuentras trabajando en un proyecto para construir o migrar a un nuevo almacén de datos. Puede que quieras instalar una base de datos en tu portátil para proyectos personales a pequeña escala, u obtener una instancia de un almacén en la nube por razones similares.

Las bases de datos y los almacenes de datos han sido un área dinámica de desarrollo tecnológico desde que se introdujeron. Desde principios del siglo XXI, algunas tendencias han impulsado la tecnología de formas que resultan realmente interesantes para los profesionales de los datos de hoy en día. En primer lugar, los volúmenes de datos han aumentado increíblemente con Internet, los dispositivos móviles y el Internet de las Cosas (IoT). En 2020, IDC predijo que la cantidad de datos almacenados en todo el mundo crecerá hasta 175 zettabytes en 2025. Es difícil siquiera pensar en esta escala de datos, y no todos se almacenarán en bases de datos para su análisis. Hoy en día, no es raro que las empresas tengan datos a escala de terabytes y petabytes, una escala que habría sido imposible procesar con la tecnología de los años 90 y anteriores. En segundo lugar, la disminución de los costes de almacenamiento de datos y de computación, junto con la llegada de la nube, han abaratado y facilitado a las organizaciones la recopilación y almacenamiento de estas cantidades masivas de datos. La memoria informática se ha abaratado, lo que significa que se pueden cargar grandes cantidades de datos en la memoria, realizar cálculos y devolver resultados, todo ello sin leer ni escribir en el disco, lo que aumenta enormemente la velocidad. En tercer lugar, la informática distribuida ha permitido repartir las cargas de trabajo entre muchas máquinas. Esto permite destinar una cantidad grande y ajustable de computación a tareas de datos complejas.

Las bases de datos y los almacenes de datos han combinado estas tendencias tecnológicas de distintas formas, con el fin de optimizarlas para determinados tipos de tareas. Hay dos grandes categorías de bases de datos que son relevantes para el trabajo de análisis: el almacén de filas y el almacén de columnas. En la siguiente sección las presentaré, hablaré de lo que las hace similares y diferentes entre sí, y hablaré de lo que todo esto significa en cuanto a realizar análisis con datos almacenados en ellas. Por último, presentaré algunos tipos adicionales de infraestructura de datos, aparte de las bases de datos, con los que te puedes encontrar.

Bases de datos de almacenamiento por filas

Las bases de datosde almacenamiento de filas -también llamadas bases de datos transaccionales- están diseñadas para ser eficientes en el procesamiento de transacciones: INSERTAR, ACTUALIZARy ELIMINAR. Las bases de datos de código abierto más populares son MySQL y Postgres. En el ámbito comercial, Microsoft SQL Server, Oracle y Teradata son muy utilizadas. Aunque no están realmente optimizadas para el análisis, durante varios años las bases de datos de almacenamiento por filas fueron la única opción para las empresas que creaban almacenes de datos. Mediante un cuidadoso ajuste y diseño del esquema, estas bases de datos pueden utilizarse para el análisis. También son atractivas por el bajo coste de las opciones de código abierto y porque resultan familiares a los administradores de bases de datos que las mantienen. Muchas organizaciones replican su base de datos de producción en la misma tecnología como primer paso hacia la creación de una infraestructura de datos. Por todas estas razones, es probable que los analistas y científicos de datos trabajen con datos en una base de datos en hilera en algún momento de su carrera.

Pensamos en una tabla como filas y columnas, pero los datos tienen que serializarse para su almacenamiento. Una consulta busca los datos necesarios en un disco duro. Los discos duros están organizados en una serie de bloques de tamaño fijo. Escanear el disco duro lleva tiempo y recursos, por lo que es importante minimizar la cantidad de disco que hay que escanear para devolver los resultados de la consulta. Las bases de datos por filas abordan este problema serializando los datos en una fila. La Figura 1-4 muestra un ejemplo de almacenamiento de datos por filas. Al realizar una consulta, se lee toda la fila en memoria. Este enfoque es rápido cuando se realizan actualizaciones por filas, pero es más lento cuando se realizan cálculos en muchas filas si sólo se necesitan unas pocas columnas.

Figura 1-4. Almacenamiento por filas, en el que cada fila se almacena junta en el disco

Para reducir la anchura de las tablas, las bases de datos de almacenamiento por filas suelen modelarse en tercera forma normal, que es un enfoque de diseño de bases de datos que trata de almacenar cada dato una sola vez, para evitar duplicaciones e incoherencias. Esto es eficaz para el procesamiento de transacciones, pero a menudo da lugar a un gran número de tablas en la base de datos, cada una con sólo unas pocas columnas. Para analizar esos datos, pueden ser necesarias muchas uniones, y puede ser difícil para los no desarrolladores comprender cómo se relacionan entre sí todas las tablas y dónde se almacena un dato concreto. Al hacer un análisis, el objetivo suele ser la desnormalización, o reunir todos los datos en un solo lugar.

Las tablas suelen tener una clave primaria que impone la unicidad, es decir, impide que la base de datos cree más de un registro para la misma cosa. Las tablas suelen tener una columna id que es un número entero autoincrementado, en el que cada nuevo registro obtiene el número entero siguiente al último insertado, o un valor alfanumérico creado por un generador de claves primarias. También debe haber un conjunto de columnas que juntas hagan que la fila sea única; esta combinación de campos se denomina clave compuesta, o a veces clave de negocio. Por ejemplo, en una tabla de personas, las columnas first_name, last_name, y birthdate juntas podrían hacer que la fila fuera única. Social_security_id también sería un identificador único, además de la columna person_id de la tabla.

Las tablas también pueden tener índices que agilizan la búsqueda de registros concretos y las uniones entre estas columnas. Los índices almacenan los valores del campo o campos indexados como datos individuales junto con un puntero de fila, y como los índices son más pequeños que toda la tabla, son más rápidos de escanear. Normalmente se indexa la clave primaria, pero también se pueden indexar otros campos o grupos de campos. Cuando trabajes con bases de datos de almacenamiento por filas, es útil conocer qué campos de las tablas que utilizas tienen índices. Las uniones comunes pueden acelerarse añadiendo índices, por lo que merece la pena investigar si las consultas de análisis tardan mucho en ejecutarse. Los índices no son gratis: ocupan espacio de almacenamiento y ralentizan la carga, ya que hay que añadir nuevos valores con cada inserción. Es posible que los DBA no indexen todo lo que podría ser útil para el análisis. Más allá de los informes, el trabajo de análisis puede no ser lo suficientemente rutinario como para molestarse en optimizar los índices. Las consultas exploratorias y complejas suelen utilizar patrones de unión complejos, y puede que desechemos un enfoque cuando descubramos una nueva forma de resolver un problema.

El modelado de esquemas en estrella se desarrolló, en parte, para hacer que las bases de datos de almacén de filas fueran más amigables con las cargas de trabajo analíticas. Los fundamentos se exponen en el libro The Data Warehouse Toolkit,² que aboga por modelar los datos como una serie de tablas de hechos y dimensiones. Las tablas de hechos representan eventos, como las transacciones de una tienda minorista. Las dimensiones contienen descriptores como el nombre del cliente y el tipo de producto. Como los datos no siempre encajan perfectamente en las categorías de hechos y dimensiones, existe una extensión denominada esquema de copo de nieve, en el que algunas dimensiones tienen dimensiones propias.

Bases de datos con almacén de columnas

Las bases de datos decolumnas despegaron a principios del siglo XXI, aunque su historia teórica se remonta a la de las bases de datos de filas. Las bases de datos de columnas almacenan juntos los valores de una columna, en lugar de almacenar juntos los valores de una fila. Este diseño está optimizado para consultas que leen muchos registros, pero no necesariamente todas las columnas. Entre las bases de datos de columnas más populares están Amazon Redshift, Snowflake y Vertica.

Las bases de datos en columnas son eficaces para almacenar grandes volúmenes de datos gracias a la compresión. Los valores que faltan y los que se repiten pueden representarse mediante valores sustitutos muy pequeños en lugar del valor completo. Por ejemplo, en lugar de almacenar "Reino Unido" miles o millones de veces, una base de datos con almacén de columnas almacenará un valor sustitutivo que ocupa muy poco espacio de almacenamiento, junto con una búsqueda que almacena el valor completo de "Reino Unido". Las bases de datos con almacén de columnas también comprimen los datos aprovechando las repeticiones de valores en los datos ordenados. Por ejemplo, la base de datos puede almacenar el hecho de que el valor del marcador de "Reino Unido" se repite 100 veces, y esto ocupa incluso menos espacio que almacenar ese marcador 100 veces.

Las bases de datos de columnas no tienen claves primarias ni índices. Los valores repetidos no son problemáticos, gracias a la compresión. Como resultado, los esquemas pueden adaptarse a las consultas de análisis, con todos los datos juntos en un solo lugar, en lugar de estar en varias tablas que hay que unir. Sin embargo, los datos duplicados pueden colarse fácilmente sin claves primarias, por lo que es importante conocer el origen de los datos y comprobar su calidad.

Las actualizaciones y eliminaciones son caras en la mayoría de las bases de datos con almacén de columnas, ya que los datos de una fila se distribuyen en lugar de almacenarse juntos. En las tablas muy grandes, puede existir una política de sólo escritura, por lo que también necesitamos saber algo sobre cómo se generan los datos para averiguar qué registros utilizar. Los datos también pueden ser más lentos de leer, ya que hay que descomprimirlos antes de aplicar los cálculos.

Las bases de datos de columnas suelen ser el estándar de oro para el trabajo de análisis rápido. Utilizan SQL estándar (con algunas variaciones específicas del proveedor), y en muchos aspectos trabajar con ellas no difiere de trabajar con una base de datos de filas en cuanto a las consultas que escribes. El tamaño de los datos importa, al igual que los recursos informáticos y de almacenamiento asignados a la base de datos. He visto agregaciones de millones y miles de millones de registros en cuestión de segundos. Esto hace maravillas por la productividad.

Consejo

Hay algunos trucos que debes conocer. Como algunos tipos de compresión se basan en la ordenación, conocer los campos por los que se ordena la tabla y utilizarlos para filtrar las consultas mejora el rendimiento. Unir tablas puede ser lento si ambas tablas son grandes.

Al fin y al cabo, algunas bases de datos serán más fáciles o rápidas de trabajar, pero no hay nada inherente al tipo de base de datos que te impida realizar cualquiera de los análisis de este libro. Como con todas las cosas, utilizar una herramienta que sea adecuadamente potente para el volumen de datos y la complejidad de la tarea te permitirá centrarte en crear análisis significativos.

Otros tipos de infraestructura de datos

Las bases de datos no son la única forma de almacenar datos, y cada vez hay más opciones para almacenar los datos necesarios para el análisis y la alimentación de las aplicaciones. Los sistemas de almacenamiento de archivos, a veces llamados lagos de datos, son probablemente la principal alternativa a los almacenes de bases de datos. Las bases de datos NoSQL y los almacenes de datos basados en búsquedas son sistemas alternativos de almacenamiento de datos que ofrecen baja latencia para el desarrollo de aplicaciones y la búsqueda en archivos de registro. Aunque no suelen formar parte del proceso de análisis, forman parte cada vez más de la infraestructura de datos de las organizaciones, por lo que también los presentaré brevemente en esta sección. Una tendencia interesante que hay que señalar es que, aunque al principio estos nuevos tipos de infraestructura pretendían romper con los confines de las bases de datos SQL, muchos han acabado implementando algún tipo de interfaz SQL para consultar los datos.

Hadoop, también conocido como HDFS (por "Hadoop distributed filesystem"), es un sistema de almacenamiento de archivos de código abierto que aprovecha el coste cada vez menor del almacenamiento de datos y la potencia de cálculo, así como los sistemas distribuidos. Los archivos se dividen en bloques, y Hadoop los distribuye en un sistema de archivos que se almacena en los nodos, u ordenadores, de un clúster. El código para ejecutar las operaciones se envía a los nodos, y éstos procesan los datos en paralelo. El gran avance de Hadoop fue permitir almacenar enormes cantidades de datos a bajo coste. Muchas grandes empresas de Internet, con cantidades masivas de datos a menudo no estructurados, descubrieron que esto era una ventaja frente a las limitaciones de coste y almacenamiento de las bases de datos tradicionales. Las primeras versiones de Hadoop tenían dos grandes inconvenientes: se necesitaban conocimientos especializados de codificación para recuperar y procesar los datos, ya que no eran compatibles con SQL, y el tiempo de ejecución de los programas solía ser bastante largo. Desde entonces, Hadoop ha madurado, y se han desarrollado varias herramientas que permiten el acceso SQL o similar a SQL a los datos y aceleran los tiempos de consulta.

En los últimos años se han introducido otros productos comerciales y de código abierto para aprovechar el almacenamiento de datos barato y el procesamiento de datos rápido, a menudo en memoria, al tiempo que ofrecen capacidad de consulta SQL. Algunos de ellos incluso permiten al analista escribir una única consulta que devuelva datos de múltiples fuentes subyacentes. Esto es emocionante para cualquiera que trabaje con grandes cantidades de datos, y es la validación de que SQL está aquí para quedarse.

NoSQL es una tecnología que permite modelar datos que no son estrictamente relacionales. Permite un almacenamiento y recuperación de muy baja latencia, fundamental en muchas aplicaciones en línea. Esta clase incluye el almacenamiento de pares clave-valor y las bases de datos de grafos, que almacenan en un formato de nodo-perímetro, y los almacenes de documentos. Ejemplos de estos almacenes de datos de los que puedes oír hablar en tu organización son Cassandra, Couchbase, DynamoDB, Memcached, Giraph y Neo4j. Al principio, NoSQL se comercializaba como que dejaba obsoleto a SQL, pero el acrónimo se ha comercializado más recientemente como "no sólo SQL". A efectos de análisis, el uso de datos almacenados en un almacén NoSQL de clave-valor para el análisis suele requerir trasladarlos a un almacén de datos SQL más tradicional, ya que NoSQL no está optimizado para consultar muchos registros a la vez. Las bases de datos de grafos tienen aplicaciones como el análisis de redes, y el trabajo de análisis puede hacerse directamente en ellas con lenguajes de consulta especiales. Sin embargo, el panorama de las herramientas está en constante evolución, y quizás algún día podamos analizar estos datos también con SQL.

Los almacenes de datos basados en búsquedas incluyen Elasticsearch y Splunk. Elasticsearch y Splunk se utilizan a menudo para analizar datos generados por máquinas, como los registros. Estas tecnologías y otras similares tienen lenguajes de consulta que no son SQL, pero si sabes SQL, a menudo puedes entenderlos. Reconociendo lo comunes que son los conocimientos de SQL, algunos almacenes de datos, como Elasticsearch, han añadido interfaces de consulta SQL. Estas herramientas son útiles y potentes para los casos de uso para los que fueron diseñadas, pero no suelen ser adecuadas para los tipos de tareas de análisis que trata este libro. Como he explicado a la gente a lo largo de los años, son estupendas para encontrar agujas en pajares. No son tan buenas para medir el propio pajar.

Independientemente del tipo de base de datos u otra tecnología de almacenamiento de datos, la tendencia es clara: aunque los volúmenes de datos crezcan y los casos de uso se hagan más complejos, SQL sigue siendo la herramienta estándar para acceder a los datos. Su gran base de usuarios existente, su curva de aprendizaje asequible y su potencia para las tareas analíticas hacen que incluso las tecnologías que intentan alejarse de SQL vuelvan y se adapten a él.

Conclusión

El análisis de datos es una disciplina apasionante con diversas aplicaciones para las empresas y otras organizaciones. SQL tiene muchas ventajas para trabajar con datos, en particular con cualquier dato almacenado en una base de datos. La consulta y el análisis de datos forman parte de un flujo de trabajo de análisis más amplio, y existen varios tipos de almacenes de datos con los que un científico de datos podría esperar trabajar. Ahora que hemos sentado las bases del análisis, SQL y los almacenes de datos, el resto del libro tratará en profundidad el uso de SQL para el análisis. El Capítulo 2 se centra en la preparación de los datos, comenzando con una introducción a los tipos de datos y pasando después a la creación de perfiles, la limpieza y la configuración de los datos. Los capítulos 3 a 7 presentan las aplicaciones del análisis de datos, centrándose en el análisis de series temporales, el análisis de cohortes, el análisis de textos, la detección de anomalías y el análisis de experimentos. El Capítulo 8 abarca técnicas para desarrollar conjuntos de datos complejos para su posterior análisis en otras herramientas. Por último, el Capítulo 9 concluye con reflexiones sobre cómo pueden combinarse los tipos de análisis para obtener nuevas perspectivas y enumera algunos recursos adicionales para apoyar tu viaje analítico.

¹ Existen algunas tecnologías más recientes que permiten realizar consultas SQL sobre datos almacenados en fuentes no relacionales.

² Ralph Kimball y Margy Ross, The Data Warehouse Toolkit, 3ª ed. (Indianápolis: Wiley, 2013).