# Criação de um banco de dados em nuvem para análise de trens de força de veículos elétricos HTML canônico: https://dsti.school/pt/techblog/banco-de-dados-em-nuvem-analise-trem-de-forca-veiculos-eletricos Esta versão em português brasileiro é gerada pelo mesmo build do site estático da DSTI que a página HTML canônica. Ela se destina à leitura por máquinas e à consulta concisa. [DSTI TechBlog](https://dsti.school/pt/techblog) / Estudantes Estudantes Engenharia de dados · inteligência do mercado automotivo Um banco de dados de vendas de veículos pode dizer quantos carros foram vendidos. Ele não pode explicar, por si só, quais componentes do trem de força estão dentro de cada modelo, quem os fornece, como os preços mudam com a potência e a voltagem ou onde os concorrentes podem ter uma oportunidade acessível. Nicolas Len projetou um fluxo de trabalho do Google Cloud para conectar essas questões. NL Nicolas Len Estudante de Engenharia de Dados na DSTI na época do projeto 23 de junho de 2026 12 min de leitura Projeto estudantil de 2024 Google Cloud BigQuery engenharia de dados veículos elétricos análise de mercado projeto estudantil ## Uma pergunta de mercado, várias camadas de dados Google Sheets Lista de valores, horários, fornecedores, preços Cloud Storage Entrada controlada e arquivos intermediários Colab Enterprise Um master mais nove notebooks de processamento BigQuery Tabelas mescladas de preços e endereçabilidade Looker Studio Análise acessível para a equipe 4 níveis de hierarquia de componentes 4 elementos de dados mantidos pela empresa 1 caderno principal 9 notebooks de processamento 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. NL Um projeto de estudante de engenharia de dados Nicolas desenvolveu o projeto enquanto estudava Engenharia de Dados em DSTI. O repositório público contém os cadernos de orquestração e transformação, enquanto a apresentação fornecida documenta o fluxo de trabalho comercial pretendido e as metas de análise. Os dados comerciais subjacentes não são publicados. O resultado útil não é simplesmente “um banco de dados na nuvem”. É uma cadeia repetível de contratos de dados, transformações e camadas de análise que mantém a experiência comercial conectada ao fluxo de trabalho de engenharia. ## 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. Nível 1 Tipo de tensão Famílias de baixa e alta tensão. Nível 2 Tipo de produto A família de componentes principais. Nível 3 Subtipo de produto Uma classificação técnica mais precisa. Nível 4 Classificação do produto 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. VL Lista de valores Arquiteturas de veículos e os componentes do trem de força esperados em cada um. PS Cronograma de energia Fórmulas usadas para calcular a potência do componente para a lógica de preço e dimensionamento. SD Dicionário de fornecedores Mapeamentos de fornecedores e concorrentes endereçáveis por modelo e componente. PL Lista de preços Preços relacionados à potência dos componentes e à tensão do sistema. ### Três contratos de dados por trás do fluxo de trabalho Editável por especialistas em domínios O Planilhas Google mantém acessíveis as entradas mantidas pela empresa. Transferência controlada O Cloud Storage separa as entradas de trabalho das tabelas analíticas. Transformação reproduzível A ordem e o código do notebook tornam cada etapa de processamento inspecionável. ## 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. Domine a orquestração `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. 01 Limpeza Padronize os arquivos de origem enviados. 02 PIHS + VL Adicione arquiteturas de componentes aos modelos de veículos. 03 + Programação de energia Calcule a potência dos componentes. 04.1 + Fornecedores EMOT Aplique as regras de mapeamento de motores elétricos. 04.2 + Fornecedores de OBC Aplique as regras de mapeamento do carregador integrado. 05 Transformação Reorganize os componentes por ano e remova campos redundantes. 06 Preços de LV Remodele os dados de preços de baixa tensão. 07 Preços de HV Remodele os dados de preços de alta tensão. 08 Participação de mercado Prepare a camada final de análise de mercado. ## 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. Planilhas do Google Listas de valores, cronogramas, fornecedores e preços mantidos pela empresa. Cloud Storage Arquivos de entrada, intermediários e de saída. Colab Enterprise Python e cadernos de transformação de pandas. BigQuery Tabelas analíticas, de preços e de endereçamento. Looker Studio Exploração e geração de relatórios voltados para a equipe. ### Perguntas possibilitadas pela camada combinada Volumes e volume de negócios Compare os volumes totais e endereçáveis de componentes e o volume de negócios. Distribuição regional Explore como a demanda de componentes e as posições dos fornecedores variam de acordo com a região. Participação de mercado do fornecedor 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. 01 Modele o domínio primeiro Uma hierarquia de componentes compartilhada impede que os serviços em nuvem se tornem substitutos da modelagem de dados. 02 Separe as entradas editáveis das saídas controladas As equipes de negócios podem manter o conhecimento sem modificar diretamente as tabelas analíticas. 03 Orquestre etapas visíveis Um caderno principal torna explícitas a ordem de processamento e as dependências. 04 Estabeleça o limite da evidência 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 ![Retrato de Nicolas Len](https://media.dsti.school/wp-content/uploads/2024/11/20150451/Nikolai-LinkedIn-Photo.avif) ### 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. [GitHub](https://github.com/nicolas-len) [LinkedIn](https://www.linkedin.com/in/niclen/) [Projeto](https://github.com/nicolas-len/gcp-bigquery-market-database) 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. --- © DSTI School of Engineering 2026 - Todos os direitos reservados. Instituição privada de ensino superior - V350 - 2 de agosto de 2026