A parte difícil desse projeto não foi escolher um serviço em nuvem. Foi traduzir uma questão do mercado automotivo em um modelo de dados e, em seguida, tornar explícita cada transformação entre os arquivos de origem e os resultados da análise.
01 A questão do mercado era mais ampla do que as vendas de veículos
O ponto de partida foi um banco de dados de veículos de terceiros contendo volumes globais de vendas. Essa fonte respondeu a uma pergunta importante — quantos veículos foram vendidos — mas não descreveu os componentes do trem de força dentro de cada modelo, os fornecedores por trás desses componentes, seus preços indicativos ou a participação de mercado que poderia ser endereçada a fornecedores concorrentes.
O projeto, portanto, teve que combinar visões comerciais, técnicas e organizacionais do mesmo mercado. Os volumes totais e endereçáveis precisavam ser analisados por tipo e região de eletrificação. A rotatividade de componentes tinha que estar conectada ao tipo de produto, arquitetura do veículo e posição do fornecedor. Nenhuma dessas perguntas pode ser respondida de forma confiável se os dados de veículos, componentes, fornecedores e preços permanecerem em planilhas separadas.
02 Modele o trem de força antes de escolher a plataforma
Antes da arquitetura em nuvem, o projeto definiu uma hierarquia de quatro níveis para os componentes do trem de força. O nível 1 identifica o tipo de tensão. O nível 2 identifica o tipo de produto. O nível 3 refina o subtipo do produto. O nível 4 registra a classificação ou a posição do produto no sistema de transmissão — uma distinção que pode afetar os preços.
Essa hierarquia é a espinha dorsal conceitual do banco de dados. Ela atribui a cada componente um lugar em um modelo compartilhado, para que as junções posteriores não dependam apenas de nomes de colunas ou rótulos ad hoc. Em termos de engenharia de dados, o projeto primeiro estabeleceu o modelo de domínio e só então selecionou os serviços que o implementariam.
Famílias de baixa e alta tensão.
A família de componentes principais.
Uma classificação técnica mais precisa.
Sua posição no sistema de transmissão e lógica de preços.
03 Mantenha a experiência do domínio perto dos dados
Quatro elementos mantidos pela empresa capturam o conhecimento que uma fonte genérica de vendas de veículos não contém. A Lista de Valores descreve possíveis arquiteturas de veículos e os componentes do trem de força associados a cada arquitetura. O Power Schedule contém fórmulas para calcular a potência do componente. Os dicionários de fornecedores mapeiam fornecedores e concorrentes endereçáveis a modelos e componentes. A Lista de Preços conecta os preços dos componentes à energia e à tensão.
O design mantém essas entradas no Google Sheets para que os especialistas em marketing possam mantê-las em uma interface familiar. Os arquivos atualizados são copiados para o Cloud Storage por meio de uma API, enquanto o banco de dados de veículos de terceiros é carregado separadamente. Esse arranjo dá aos especialistas em negócios a propriedade das entradas do domínio sem precisar que editem diretamente o código do notebook ou as tabelas do BigQuery.
Arquiteturas de veículos e os componentes do trem de força esperados em cada um.
Fórmulas usadas para calcular a potência do componente para a lógica de preço e dimensionamento.
Mapeamentos de fornecedores e concorrentes endereçáveis por modelo e componente.
Preços relacionados à potência dos componentes e à tensão do sistema.
Três contratos de dados por trás do fluxo de trabalho
04 Torne a cadeia de transformação explícita
O repositório expõe um caderno mestre e nove cadernos de processamento. O mestre instala os pacotes necessários, se autentica com o Google Cloud, recupera as entradas do notebook do Cloud Storage e usa o Papermill para executar os notebooks restantes em sequência. Essa sequência torna as dependências visíveis em vez de escondê-las dentro de um script monolítico.
A cadeia de processamento limpa os arquivos recebidos; mescla o banco de dados de veículos com a Lista de Valores; adiciona o cronograma de energia; aplica uma lógica separada de mapeamento de fornecedores para motores elétricos e carregadores de bordo; transforma a estrutura mesclada; remodela os dados de preços de baixa e alta tensão e, finalmente, prepara os resultados de participação de mercado. Os artefatos intermediários são gravados de volta no armazenamento em nuvem ou consultados por meio do BigQuery à medida que o fluxo de trabalho avança.
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 Os nomes dos arquivos e a ordem de execução são preservados do repositório fornecido.
05 Use o BigQuery como camada de análise
Após as transformações do notebook, as saídas CSV preparadas são carregadas no BigQuery. As consultas SQL adicionam informações de preço e a capacidade de endereçamento do fornecedor à estrutura transformada de componentes do veículo. O banco de dados resultante pode então ser conectado ao Google Sheets e ao Looker Studio para análise e geração de relatórios.
Essa separação é importante. O Planilhas Google continua sendo a camada editável de entrada comercial. O Cloud Storage mantém arquivos controlados. Os notebooks Colab Enterprise implementam a lógica de transformação. O BigQuery se torna a camada analítica estruturada. O Looker Studio fornece uma interface de consumo. Cada serviço tem uma responsabilidade distinta, em vez de se tornar outro lugar onde a mesma lógica é duplicada.
Perguntas possibilitadas pela camada combinada
Compare os volumes totais e endereçáveis de componentes e o volume de negócios.
Explore como a demanda de componentes e as posições dos fornecedores variam de acordo com a região.
Analise as distribuições de produtos e fornecedores nas arquiteturas de veículos.
06 O que o repositório público demonstra — e o que ele não demonstra
O repositório público é uma forte evidência do fluxo de trabalho de engenharia: orquestração de notebooks, autenticação do Google Cloud, acesso ao armazenamento, transformações de pandas e consultas do BigQuery podem ser inspecionadas. A apresentação também registra o modelo de dados, a automação planejada e os objetivos da análise de negócios.
Ele não publica os conjuntos de dados comerciais de origem, os mapeamentos de fornecedores, os preços nem os painéis operacionais. O registro público tampouco comprova, de forma independente, níveis de serviço em produção ou resultados comerciais. Portanto, este artigo documenta a arquitetura e a implementação sem transformar um projeto estudantil em uma alegação infundada de implantação industrial ao vivo.
O que é evidenciado
- O repositório contém o fluxo de trabalho do notebook e as integrações na nuvem.
- A apresentação documenta a hierarquia de dados e as entradas comerciais.
- O código mostra operações sequenciais de limpeza, fusão, transformação e BigQuery.
O que permanece fora do registro público
- Os conjuntos de dados de entrada comerciais não são publicados.
- Os resultados comerciais e os painéis não podem ser reproduzidos de forma independente apenas a partir do repositório.
- O material público não estabelece certificação de serviço de produção ou segurança.
07 Lições de engenharia de dados do projeto
O projeto ilustra um princípio recorrente: a arquitetura em nuvem é mais útil quando esclarece a responsabilidade. O modelo de negócios pertence a estruturas de dados explícitas. Os especialistas do domínio precisam de formas controladas de manter as entradas. Os estágios de transformação precisam de uma ordem observável. As saídas analíticas precisam de uma camada estável que possa servir a mais de uma interface.
Também mostra por que a “automação” não é um recurso. Copiar arquivos atualizados, selecionar a fonte mais recente, executar notebooks, carregar tabelas e atualizar análises são transições separadas. Tratá-las separadamente facilita a localização das falhas e facilita a evolução do fluxo de trabalho.
Uma hierarquia de componentes compartilhada impede que os serviços em nuvem se tornem substitutos da modelagem de dados.
As equipes de negócios podem manter o conhecimento sem modificar diretamente as tabelas analíticas.
Um caderno principal torna explícitas a ordem de processamento e as dependências.
O código aberto pode demonstrar a arquitetura sem expor dados proprietários ou exagerar o status da implantação.
08 Registro do projeto
O repositório contém o caderno principal, nove cadernos de processamento, o README do projeto e a apresentação de alto nível. Juntos, eles fornecem um registro público compacto da arquitetura e da sequência de transformação do projeto.
Nicolas Len é creditado como autor do projeto. Seus perfis públicos e repositório estão no link abaixo para leitores que desejam inspecionar os cadernos ou acompanhar seu trabalho subsequente.
Recursos do projeto
Nicolas Len
Nicolas Len desenvolveu este projeto enquanto estudava Engenharia de Dados na DSTI. O trabalho combina modelagem do mercado automotivo, arquitetura de dados em nuvem, notebooks Python, BigQuery e análises voltadas aos negócios.
Fonte e nota editorial: Artigo desenvolvido a partir da apresentação do projeto, do README e do instantâneo fornecido do repositório. Nomes de produtos, nomes de arquivos de notebooks e identificadores técnicos foram preservados. O artigo descreve a arquitetura pública e as evidências de implementação sem divulgar nem inferir dados proprietários de origem.