# Construir una base de datos en la nube para analizar el tren motriz de vehículos eléctricos HTML canónico: https://dsti.school/es/techblog/base-datos-nube-analisis-tren-motriz-vehiculos-electricos Esta versión Markdown se genera con el mismo build del sitio estático de DSTI que la página HTML canónica. Está pensada para facilitar la lectura automática y la consulta concisa. [DSTI TechBlog](https://dsti.school/es/techblog) / Estudiantes Estudiantes Data Engineering · inteligencia de mercado automotriz Una base de ventas automotrices puede indicar cuántos vehículos se vendieron. Por sí sola, no explica qué componentes del tren motriz lleva cada modelo, quién los suministra, cómo cambian los precios según la potencia y el voltaje, ni qué oportunidades podrían ser atendidas por proveedores competidores. Nicolas Len diseñó un flujo en Google Cloud para conectar esas preguntas. NL Nicolas Len Estudiante de Data Engineering en DSTI cuando desarrolló el proyecto 23 de junio de 2026 12 min de lectura Proyecto estudiantil de 2024 google-cloud bigquery data-engineering vehiculos-electricos analisis-mercado proyecto-estudiantil ## Una pregunta de mercado, varias capas de datos Google Sheets Value List, schedules, proveedores, precios Cloud Storage Archivos de entrada e intermedios controlados Colab Enterprise Un notebook maestro y nueve notebooks de procesamiento BigQuery Tablas integradas de precios y mercado direccionable Looker Studio Análisis accesible para el equipo 4 niveles de jerarquía de componentes 4 elementos mantenidos por el negocio 1 notebook maestro 9 notebooks de procesamiento La dificultad principal del proyecto no era elegir un servicio en la nube. Era traducir una pregunta del mercado automotriz a un modelo de datos y hacer explícita cada transformación entre los archivos fuente y los resultados de análisis. NL Un proyecto estudiantil de Data Engineering Nicolas desarrolló el proyecto mientras estudiaba Data Engineering en DSTI. El repositorio público contiene los notebooks de orquestación y transformación, mientras que la presentación proporcionada documenta el flujo de negocio previsto y los objetivos de análisis. Los datos comerciales subyacentes no se publican. El resultado útil no es simplemente “una base de datos en la nube”. Es una cadena reproducible de contratos de datos, transformaciones y capas analíticas que mantiene el conocimiento del negocio conectado con el flujo de ingeniería. ## 01 La pregunta de mercado iba más allá de las ventas de vehículos El punto de partida era una base de terceros con volúmenes globales de ventas de vehículos. Esa fuente respondía una pregunta importante —cuántos vehículos se vendieron—, pero no describía los componentes del tren motriz de cada modelo, sus proveedores, los precios indicativos ni la parte del mercado que podría ser atendida por competidores. El proyecto debía combinar perspectivas comerciales, técnicas y organizacionales del mismo mercado. Los volúmenes y la facturación total y direccionable debían analizarse por tipo de electrificación y región. La facturación de componentes debía conectarse con el tipo de producto, la arquitectura del vehículo y la posición del proveedor. Ninguna de esas preguntas puede responderse de forma confiable si los datos de vehículos, componentes, proveedores y precios permanecen en hojas separadas. ## 02 Modelar el tren motriz antes de elegir la plataforma Antes de definir la arquitectura en la nube, el proyecto estableció una jerarquía de cuatro niveles para los componentes del tren motriz. El nivel 1 identifica el tipo de voltaje. El nivel 2 corresponde al tipo de producto. El nivel 3 precisa el subtipo. El nivel 4 registra el rango o la posición del producto dentro del sistema —una distinción que puede influir en el precio. Esa jerarquía es la columna vertebral conceptual de la base. Da a cada componente una ubicación dentro de un modelo compartido, para que los joins posteriores no dependan únicamente de nombres de columnas o etiquetas ad hoc. Desde la perspectiva de Data Engineering, el proyecto define primero el modelo del dominio y después selecciona los servicios que lo implementan. Nivel 1 Tipo de voltaje Familias de bajo y alto voltaje. Nivel 2 Tipo de producto La familia principal del componente. Nivel 3 Subtipo de producto Una clasificación técnica más precisa. Nivel 4 Rango del producto Su posición en el tren motriz y la lógica de precios. ## 03 Mantener el conocimiento del negocio cerca de los datos Cuatro elementos mantenidos por el negocio capturan conocimiento que una fuente genérica de ventas no contiene. La Value List describe las arquitecturas posibles y los componentes asociados. El Power Schedule contiene fórmulas para calcular la potencia. Los Supplier Dictionaries relacionan proveedores y competidores direccionables con modelos y componentes. La Price List conecta los precios con la potencia y el voltaje. El diseño mantiene estas entradas en Google Sheets para que los especialistas de marketing puedan actualizarlas en una interfaz conocida. Los archivos modificados se copian a Cloud Storage mediante una API, mientras que la base externa de vehículos se carga por separado. Así, las personas expertas en el negocio conservan el control de los insumos sin editar directamente el código de los notebooks ni las tablas de BigQuery. VL Value List Arquitecturas de vehículos y componentes esperados en cada una. PS Power Schedule Fórmulas para calcular potencia y apoyar la lógica de precios. SD Supplier Dictionary Mapeos de proveedores y competidores direccionables por modelo y componente. PL Price List Precios vinculados con la potencia del componente y el voltaje del sistema. ### Tres contratos de datos detrás del flujo Editable por especialistas del negocio Google Sheets mantiene las entradas accesibles para el equipo. Transferencia controlada Cloud Storage separa los archivos de trabajo de las tablas analíticas. Transformación reproducible El orden y el código de los notebooks hacen visible cada etapa. ## 04 Hacer explícita la cadena de transformación El repositorio expone un notebook maestro y nueve notebooks de procesamiento. El maestro instala los paquetes necesarios, se autentica con Google Cloud, recupera las entradas desde Cloud Storage y usa Papermill para ejecutar el resto en secuencia. El orden hace visibles las dependencias en lugar de esconderlas dentro de un script monolítico. La cadena limpia los archivos de entrada; fusiona la base de vehículos con la Value List; añade el Power Schedule; aplica reglas independientes de proveedores para motores eléctricos y cargadores a bordo; transforma la estructura integrada; remodela los precios de bajo y alto voltaje; y finalmente prepara los resultados de participación de mercado. Los artefactos intermedios vuelven al almacenamiento en la nube o se consultan mediante BigQuery conforme avanza el flujo. Orquestación maestra `00 Master.ipynb → 01 Cleaning.ipynb → 02 PIHS VL.ipynb → 03 PIHS VL PS.ipynb → 04.1 / 04.2 supplier mapping → 05 Transformation.ipynb → 06 / 07 prices → 08 MARKETSHARE.ipynb` Los nombres de archivo y el orden de ejecución se conservan tal como aparecen en el repositorio proporcionado. 01 Cleaning Estandarizar los archivos fuente. 02 PIHS + VL Añadir arquitecturas de componentes a los modelos. 03 + Power Schedule Calcular la potencia de los componentes. 04.1 + proveedores EMOT Aplicar reglas para motores eléctricos. 04.2 + proveedores OBC Aplicar reglas para cargadores a bordo. 05 Transformation Reorganizar componentes por año y eliminar campos redundantes. 06 Precios LV Remodelar precios de bajo voltaje. 07 Precios HV Remodelar precios de alto voltaje. 08 Participación Preparar la capa final de análisis de mercado. ## 05 Usar BigQuery como capa de análisis Después de las transformaciones, los archivos CSV preparados se cargan en BigQuery. Las consultas SQL añaden información de precios y mercado direccionable a la estructura transformada de vehículos y componentes. La base resultante puede conectarse con Google Sheets y Looker Studio para análisis y reportes. Esta separación importa. Google Sheets sigue siendo la capa editable para el negocio. Cloud Storage conserva los archivos controlados. Los notebooks de Colab Enterprise implementan la lógica de transformación. BigQuery se convierte en la capa analítica estructurada. Looker Studio ofrece la interfaz de consulta. Cada servicio tiene una responsabilidad distinta, sin duplicar la misma lógica en varios lugares. Google Sheets Value lists, schedules, proveedores y precios mantenidos por el negocio. Cloud Storage Archivos de entrada, intermedios y de salida. Colab Enterprise Notebooks de transformación con Python y pandas. BigQuery Tablas de precios, mercado direccionable y análisis. Looker Studio Exploración y reportes para el equipo. ### Preguntas que permite la capa integrada Volúmenes y facturación Comparar volúmenes y facturación total y direccionable. Distribución regional Explorar cómo cambian la demanda y la posición de proveedores por región. Participación de proveedores Analizar distribuciones por producto, proveedor y arquitectura vehicular. ## 06 Lo que demuestra el repositorio público — y lo que no demuestra El repositorio público ofrece evidencia sólida del flujo de ingeniería: se pueden inspeccionar la orquestación de notebooks, la autenticación con Google Cloud, el acceso al almacenamiento, las transformaciones con pandas y las consultas de BigQuery. La presentación también registra el modelo de datos, la automatización prevista y los objetivos del análisis. No publica los conjuntos de datos comerciales, los mapeos de proveedores, los precios ni los tableros operativos. El registro público tampoco demuestra por sí solo niveles de servicio en producción ni resultados de negocio. Por ello, el artículo documenta la arquitectura y el enfoque de implementación sin convertir un proyecto estudiantil en una afirmación no sustentada de despliegue industrial. ### Lo que sí está documentado - El repositorio contiene el flujo de notebooks y las integraciones en la nube. - La presentación documenta la jerarquía de datos y las entradas del negocio. - El código muestra limpieza, joins, transformaciones y operaciones en BigQuery. ### Lo que queda fuera del registro público - Los datos comerciales de entrada no se publican. - Los resultados de negocio y tableros no se pueden reproducir con el repositorio por sí solo. - El material público no demuestra certificación de producción o seguridad. ## 07 Lecciones de Data Engineering del proyecto El proyecto ilustra un principio recurrente: la arquitectura en la nube es útil cuando aclara responsabilidades. El modelo del negocio debe expresarse en estructuras explícitas. Las personas expertas necesitan formas controladas de mantener las entradas. Las etapas de transformación requieren un orden observable. Los resultados analíticos necesitan una capa estable que pueda alimentar más de una interfaz. También muestra por qué “automatizar” no es una sola función. Copiar archivos actualizados, seleccionar la fuente más reciente, ejecutar notebooks, cargar tablas y actualizar el análisis son transiciones distintas. Tratarlas por separado facilita localizar fallas y evolucionar el flujo. 01 Modelar primero el dominio Una jerarquía compartida evita que los servicios cloud sustituyan el modelado de datos. 02 Separar entradas editables de salidas gobernadas El negocio mantiene el conocimiento sin modificar directamente las tablas analíticas. 03 Orquestar etapas visibles Un notebook maestro hace explícitos el orden del procesamiento y sus dependencias. 04 Declarar el límite de la evidencia El código abierto puede demostrar la arquitectura sin exponer datos propietarios ni exagerar el estado del despliegue. ## 08 Registro del proyecto El repositorio contiene el notebook maestro, nueve notebooks de procesamiento, el README del proyecto y la presentación de alto nivel. En conjunto ofrecen un registro público compacto de la arquitectura y la secuencia de transformación. Nicolas Len figura como autor del proyecto. Sus perfiles públicos y el repositorio aparecen abajo para quienes quieran revisar los notebooks o seguir su trabajo posterior. ### Recursos del proyecto ![Retrato de Nicolas Len](https://media.dsti.school/wp-content/uploads/2024/11/20150451/Nikolai-LinkedIn-Photo.avif) ### Nicolas Len Nicolas Len desarrolló este proyecto mientras estudiaba Data Engineering en DSTI. Combina modelado del mercado automotriz, arquitectura de datos en la nube, notebooks de Python, BigQuery y análisis orientado al negocio. [GitHub](https://github.com/nicolas-len)[LinkedIn](https://www.linkedin.com/in/niclen/)[Project](https://github.com/nicolas-len/gcp-bigquery-market-database) Fuentes y nota editorial: Artículo elaborado a partir de la presentación, el README y la copia del repositorio proporcionados. Se conservan los nombres de productos, archivos de notebooks e identificadores técnicos. El artículo describe la arquitectura pública y la evidencia de implementación sin divulgar ni inferir datos fuente propietarios.