services - Mejor uso de R y SQL si está restringido a una máquina local

sql en r (3)

Estoy tratando de mejorar mi flujo de trabajo, y espero que la comunidad pueda brindar información, ya que soy relativamente nuevo en "big data".

Normalmente descargo varios marcos de datos de fuentes públicas que pueden estar relacionados entre sí. Después de extraer varios marcos de datos, hago varios pasos de procesamiento de datos (por ejemplo, filtrado, clasificación, agregación, cálculos personalizados) antes de hacer análisis de regresión y / u otras estadísticas inferenciales en mi conjunto final de datos.

Específicamente, qué estrategia recomendarías:

Descargando todos los datos como archivos separados de la web a mi máquina local y luego usando R para procesarlos directamente (como lo he estado haciendo). El problema potencial que veo con esto es que todo está en el entorno de trabajo de R, lo que puede ralentizar el proceso y bloquear mi máquina.

Descargando todos los datos como archivos separados de la web a mi máquina local, creando una base de datos con sqldf en la máquina local y utilizando consultas de seguimiento con sqldf para extraer y agregar información de esa base de datos antes de realizar el análisis final de los datos en R. El problema potencial que veo con esto es que una base de datos, formada por un puñado de tablas / marcos de datos, creada en mi máquina local con sqldf es más grande que simplemente guardar varios archivos .csv individuales.

Estoy bastante familiarizado con las técnicas estadísticas, pero debo admitir que tengo varios vacíos de conocimiento cuando se trata de la gestión de bases de datos y las operaciones del servidor. Me he familiarizado con los sqldf básicos de SQL, como lenguaje, y sé cómo usar sqldf con los marcos de datos que se ejecutan en el entorno de trabajo de R. Sin embargo, francamente no sé qué ventaja ofrece el hecho de aprender a usar las funciones básicas de R para filtrar, ordenar y agregar datos. Además, he leído algunas páginas web sobre la exageración del emparejamiento de SQL Server con R, pero no estoy seguro de que esta sea una buena opción para mí ya que ejecuto todo de forma local.

¿Algún consejo para este novato sobre cómo mejorar mi análisis y procesamiento de datos mediante la combinación de R con alguna implementación de SQL?

¡Gracias de antemano!

Dado que está buscando "mejores prácticas de flujo de trabajo", hay una gran prima que debe asignarse tanto a la reproducibilidad como a la transparencia . Dado que su objetivo es el análisis de datos y no la recopilación de datos o la administración de bases de datos, no hay una razón sólida para crear sus propias bases de datos y una base de datos personalizada probablemente haga que su flujo de trabajo y análisis sean menos transparentes. En resumen, si no necesita crear una base de datos, no lo haga.

Parece que su flujo de trabajo es el siguiente:

Descargue datos de fuentes públicas (idealmente .csv o un formato similar)
Limpiar y procesar los datos.
Ejecutar análisis en los datos limpiados (potencialmente vinculados)

Recomendaría dividir su flujo de trabajo en dos pasos distintos:

1. Descargar y limpiar datos

Si sus archivos son todos .csv (u otros archivos delimitados regulares), entonces solo necesita el paquete data.table para este paso. Puede escribir un solo script R para descargar, limpiar y guardar los datos que necesita. Un ejemplo mínimo es a continuación:

# Download data library(data.table) salary_data <- fread(''https://data.phila.gov/api/views/25gh-t2gp/rows.csv'') # Clean data (only looking at City Council salaries) cleaned_data <- salary_data[Department == ''CITY COUNCIL''] # Saving cleaned data save(cleaned_data, file = ''my_file_name.rda'', compress = TRUE)

Idealmente, solo tendría que ejecutar este archivo una vez para generar el conjunto de datos en el que realmente realiza su análisis estadístico. Si decide limpiar o procesar sus datos de manera diferente, simplemente vuelva a visitar este archivo, realice los cambios apropiados y vuelva a ejecutarlo. Recomendaría tener un script para cada archivo que esté descargando para que sea fácil ver cómo está procesando los datos sin procesar directamente desde la fuente ( transparencia ). Simplemente tener este archivo satisface la reproducibilidad .

2. Análisis estadístico

Si necesita combinar sus conjuntos de datos, data.table proporciona una forma rápida y transparente de hacerlo. Simplemente cargue los conjuntos de datos individuales que haya limpiado, identifique la clave que usará para combinarlos y luego fusionarlos. Luego ejecute su análisis en el conjunto de datos fusionado. A continuación se muestra un ejemplo de esta funcionalidad:

# dt1 has salary information for 10 people and dt2 # has the number of kids for the same 10 people library(data.table) dt1 <- data.table(id = 1:10, salary = sample(0:100000, 10) dt2 <- data.table(id = 1:10, kids = sample(0:5, 10) save(dt1, file = ''dt1.rda'', compress = TRUE) save(dt2, file = ''dt2.rda'', compress = TRUE) # Loading and merging data load(file = ''dt1.rda'') load(file = ''dt2.rda'') setkey(dt1, id) setkey(dt2, id) merged_dt <- merge(dt1, dt2) # Doing regression analysis on merged data reg <- lm(salary ~ kids, data = merged_dt)

Esto hace que el procedimiento de fusión y el posterior análisis sean transparentes y reproducibles .

Resumen

Este procedimiento garantiza que sus fuentes de datos, limpieza / procesamiento de datos y análisis estén bien documentados, sean transparentes y reproducibles . Además, este procedimiento se escala con tu computadora. Si no necesita crear una base de datos, no lo haga.

¿Qué pasa si los datos son demasiado grandes para mi computadora? Si necesita más espacio, simplemente ejecute el código que ya ha escrito en un servidor dedicado o en una máquina de servicios web de Amazon.

¿Qué pasa si los datos son demasiado grandes para un servidor dedicado? Es probable que los datos se almacenen en una base de datos real y la única parte del flujo de trabajo que cambia es la descarga de datos y (potencialmente) parte del procesamiento será una consulta de SQL a la base de datos (lo más probable es que utilice el paquete DBI que ejecuta consultas de SQL). en R), que debería ser lo suficientemente pequeño para ejecutarse localmente o en un servidor dedicado.

¿Qué pasa si mis datos son demasiado grandes para eso? Probablemente debería mirar en lenguajes de datos pesados más pesados como Hadoop.

Nota complementaria: si sus datos no están en un formato delimitado regular (como un archivo Excel, SAS o Stata), recomendaría usar la función download_file() junto con el paquete tidyverse (que tiene una capacidad fantástica para leer estos archivos menos agradables, pero comunes)

library(tidyverse) taxi_data_excel <- download.file(url = ''http://www.nyc.gov/html/tlc/downloads/excel/current_medallion_drivers.xls'', destfile = ''taxi_data_excel.xls'') taxi_data <- read_excel(''taxi_data_excel.xls'')

Luego haz tu limpieza como de costumbre.

Depende mucho de la infraestructura de su entorno, pero en el mundo de "Big Data" recomendaría usar ambos porque cada uno tiene ventajas a las que es difícil renunciar.

La mayoría de las acciones de limpieza y manipulación de datos se pueden realizar en ambas plataformas, algunas a costa del rendimiento y otras a los recursos.

En memoria: El entorno de R está principalmente dentro de la memoria RAM. Que es mucho más rápido, pero no siempre necesario. Si tiene un conjunto de datos de 100 GB, cargarlo en la memoria RAM sería inviable. La mayoría de las bases de datos ya han introducido tablas en la memoria, por lo que si hay tablas específicas a las que desea un acceso más rápido, siempre puede cargarlas en la RAM.

Índices y particiones: Es mucho más fácil consultar datos que se han indexado y particionado de manera eficiente en una base de datos que a través de archivos CSV. La mayoría del análisis exploratorio se realiza en particiones o grupos de datos, y renunciar a esto es un enorme compromiso de rendimiento.

Descarga y almacenamiento: en R es muy fácil escribir un script para descargar datos y cargarlos en una base de datos. En una base de datos, los datos pueden almacenarse más fácilmente para un acceso rápido, así como comprimirse de manera eficiente para el rendimiento y la escalabilidad.

Vistas de tabla: hay muchos conjuntos de datos o manipulaciones básicas en los conjuntos de datos que desearía almacenar para su uso posterior. En una base de datos puede hacer uso de vistas de tabla que pueden unir y manipular datos en cualquier número de tablas. Para obtener el mismo resultado en R, tendría que cargar todas las tablas relevantes y realizar las fusiones y manipulaciones cada vez que desee acceder a los mismos datos.

Análisis: Esto es para lo que R fue construido. Muchas bases de datos hacen imposible realizar incluso el análisis más básico, por lo que dejaría todo el análisis estadístico en R.

Estoy seguro de que hay muchas más ventajas / desventajas que pueden compararse entre R y el uso de una base de datos. Nuevamente, si está trabajando en pequeñas cantidades de datos por diversión, puede usar R en todo momento. De lo contrario, utilice ambos. Es más fácil, más rápido y mucho más cómodo.

Lo primero es lo primero. sqldf no es una base de datos, es un paquete que le permite manipular un objeto data.frame en la sintaxis SQL. Bueno, para ser precisos, usa SQLite en el back-end, pero no debes considerar un paquete sqldf como una base de datos.

sqldf es un paquete bueno y conveniente. En algunos casos, también puede ser efectivo, pero la efectividad no es su objetivo principal. Te recomiendo que consideres un paquete data.table . Está diseñado para ser efectivo y el rendimiento puede sorprenderlo.

El primer y principal consejo para elegir una estrategia es el siguiente: ¡Respete el factor de compensación! La implementación de la base de datos SQL real con R puede darle una gran ventaja, pero supone una sobrecarga considerable en el proceso de desarrollo. Todo depende del alcance del proyecto. No hay reglas generales, pero puedo intentar indicar algunas reglas generales.

Por defecto, trataría de evitar involucrar la base de datos SQL, a menos que me enfrente a argumentos específicos del proyecto para SQL.
Si el cuello de la botella es RAM y R es necesario solo para datos agregados, entonces realmente debería considerar el uso de la base de datos SQL. Por ejemplo, MySQL se encargará de la paginación, el almacenamiento en caché y los subprocesos múltiples, esto podría ser argumentos importantes.
Si la estructura de datos de diferentes fuentes tiene diferencias significativas, entonces el uso de SQL supondrá una sobrecarga adicional porque tendrá que administrarlo en R y en SQL: intente evitarlo. Por otro lado, si hay muchas fuentes con la misma estructura de datos, la base de datos le proporcionará una buena mejora.
Si solo necesita continuar con los datos de origen, entonces tratar con archivos está bien. Pero si necesita ejecutarlo repetidamente y guardar todos los resultados, cambios, versiones, etc., entonces la base de datos se convierte en una necesidad.

Esta es solo mi humilde opinión.