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.
01La 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.
02Modelar 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.
Familias de bajo y alto voltaje.
La familia principal del componente.
Una clasificación técnica más precisa.
Su posición en el tren motriz y la lógica de precios.
03Mantener 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.
Arquitecturas de vehículos y componentes esperados en cada una.
Fórmulas para calcular potencia y apoyar la lógica de precios.
Mapeos de proveedores y competidores direccionables por modelo y componente.
Precios vinculados con la potencia del componente y el voltaje del sistema.
Tres contratos de datos detrás del flujo
04Hacer 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.
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.ipynbLos nombres de archivo y el orden de ejecución se conservan tal como aparecen en el repositorio proporcionado.
05Usar 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.
Preguntas que permite la capa integrada
Comparar volúmenes y facturación total y direccionable.
Explorar cómo cambian la demanda y la posición de proveedores por región.
Analizar distribuciones por producto, proveedor y arquitectura vehicular.
06Lo 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.
07Lecciones 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.
Una jerarquía compartida evita que los servicios cloud sustituyan el modelado de datos.
El negocio mantiene el conocimiento sin modificar directamente las tablas analíticas.
Un notebook maestro hace explícitos el orden del procesamiento y sus dependencias.
El código abierto puede demostrar la arquitectura sin exponer datos propietarios ni exagerar el estado del despliegue.
08Registro 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
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.
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.