OPTIMIZATION OF METADATA PROCESSING FOR A CONTACT CENTER PLATFORM USING A BIG DATA ARCHITECTURE
REGISTRO DOI: 10.69849/revistaft/ra10202508261412
Holden Offmenn1
Ítala Lorena de Lima Ferreira2
Daniely Dantas Lobato3
Jhônatas Cardoso Luz4
Luana Dalla Rosa Pinto de Carvalho5
Laís Miranda Olímpio6
André Luiz Samistraro Santin7
Resumo
O processamento de dados de uma plataforma de contact center (AICC) em larga escala, baseado em métodos manuais, consumia mais de 24 horas, um gargalo que impedia a análise ágil de falhas de produto e a tomada de decisão estratégica. Este artigo descreve o desenvolvimento e a validação de uma arquitetura de software, denominada Synapse, projetada para otimizar este fluxo. O objetivo central foi reduzir drasticamente o tempo de processamento por meio da implementação de uma arquitetura de Extração, Transformação e Carga (ETL) escalável e de alto desempenho. A metodologia empregada foi o desenvolvimento experimental, com uma abordagem híbrida que uniu práticas do PMBOK® para o gerenciamento e o framework Scrum para a execução iterativa. A solução foi implementada com uma arquitetura de microsserviços, utilizando um stack de tecnologias open-source composto por Apache Kafka, Apache Spark e ClickHouse. Os resultados experimentais validaram a hipótese inicial, alcançando um tempo de processamento inferior a 30 minutos e mantendo uma confiabilidade de dados superior a 95%. Conclui-se que a arquitetura de Big Data proposta é uma solução eficaz e robusta para resolver desafios de processamento de dados em larga escala, gerando agilidade operacional e valor estratégico.
Palavras-chave: Big Data. Processamento de Dados. ETL. Apache Spark. Arquitetura de Microsserviços.
1 INTRODUÇÃO
A transição para o paradigma da Indústria 4.0 tem redefinido fundamentalmente o setor de manufatura, promovendo a integração de sistemas ciberfísicos, automação e análise de dados como pilares para a criação de fábricas inteligentes (LU, 2017). Neste contexto, a capacidade de uma organização para coletar, processar e analisar vastos volumes de dados operacionais em tempo hábil tornou-se um diferencial competitivo crítico. A análise de Big Data, em particular, oferece oportunidades sem precedentes para otimizar cadeias de suprimentos, aprimorar o controle de qualidade e acelerar os ciclos de inovação de produtos, especialmente no dinâmico setor de eletrônicos de consumo (WANG, WANG, & LI, 2018).
Apesar do potencial transformador, a materialização de uma cultura orientada a dados frequentemente encontra obstáculos em arquiteturas de informação legadas. Muitos sistemas corporativos ainda se baseiam em processos de Extração, Transformação e Carga (ETL) que operam em lote (batch processing), uma metodologia projetada para uma era em que a instantaneidade dos dados não era um requisito primordial (CHEN, CHIANG, & STOREY, 2012). Esta abordagem tradicional cria uma latência inerente entre a geração do dado e a sua disponibilidade para análise, formando uma lacuna (GAP) que impede a tomada de decisões ágeis. A literatura atual aponta para a necessidade de evoluir desses modelos para arquiteturas de processamento de fluxo (stream processing), capazes de analisar eventos à medida que ocorrem, viabilizando a análise em tempo quase real (Near Real-Time) (GROLINGER et al., 2013).
O presente estudo aborda um problema de pesquisa inserido precisamente nesta interseção entre a necessidade estratégica de agilidade e a limitação tecnológica dos sistemas legados. O objeto de estudo é uma plataforma de grande escala para suporte ao cliente, denominada AICC (Artificial Intelligence Contact Center), que gera um fluxo contínuo e massivo de metadados. Estas informações, que contêm insights valiosos sobre o desempenho e potenciais falhas de produtos em campo, são atualmente processadas por meio de um fluxo de trabalho manual, baseado em extrações de arquivos e análise em planilhas. Este processo, além de ser propenso a erros, consome mais de 24 horas para consolidar os dados de um único dia de operação, tornando inviável a identificação proativa e a resposta rápida a problemas de qualidade.
A justificativa para esta investigação é, portanto, a necessidade urgente de desenvolver uma solução que elimine esse gargalo informacional. A otimização deste fluxo de dados não representa apenas um ganho de eficiência operacional, mas uma capacitação estratégica, permitindo que a organização transite de uma postura reativa para uma gestão proativa da qualidade do produto. A pesquisa se propõe a explorar a viabilidade de uma arquitetura de microsserviços, um padrão arquitetônico que favorece a construção de sistemas complexos como um conjunto de serviços independentes, coesos e fracamente acoplados, promovendo resiliência e escalabilidade (DRAGONI et al., 2017).
Assim, o objetivo central deste trabalho é o desenvolvimento e a validação empírica de uma arquitetura de software de ETL de alto desempenho, projetada para o ecossistema de dados do AICC. A hipótese que norteia este estudo é que, através da aplicação de um stack tecnológico de Big Data (incluindo Apache Kafka e Apache Spark) dentro de uma arquitetura de microsserviços, é possível reduzir o tempo de processamento de dados de mais de 24 horas para menos de 30 minutos, com um índice de confiabilidade da informação superior a 95%.
2 FUNDAMENTAÇÃO TEÓRICA OU REVISÃO DA LITERATURA
A sustentação teórica para o desenvolvimento de uma solução de processamento de dados de alto desempenho, como a proposta neste trabalho, reside na intersecção de três domínios fundamentais da ciência da computação e engenharia de software: o paradigma do Big Data e seus processos de ETL, a evolução das arquiteturas de software para modelos distribuídos e as tecnologias especializadas que viabilizam o processamento de dados em larga escala. Esta seção detalha o referencial teórico e o estado da arte que embasaram as decisões de projeto.
2.1 Big Data e a Evolução dos Processos de ETL
O conceito de Big Data é tipicamente caracterizado por três dimensões, conhecidas como os “3 Vs”: Volume, Velocidade e Variedade (LANEY, 2001). O Volume refere-se à magnitude dos dados gerados e armazenados; a velocidade diz respeito à taxa com que os dados são criados e necessitam ser processados; e a variedade abrange os diferentes formatos de dados, que podem ser estruturados, semiestruturados ou não estruturados. O cenário descrito na introdução, com um fluxo contínuo de metadados de um contact center, enquadra-se perfeitamente nesta definição, exigindo uma abordagem que transcenda os sistemas de gerenciamento de banco de dados tradicionais.
Para extrair valor de tais conjuntos de dados, os processos de Extração, Transformação e Carga (ETL) são indispensáveis. Contudo, o modelo clássico de ETL, projetado para ambientes de data warehousing com atualizações em lote, apresenta latência significativa e dificuldades de escalabilidade diante das demandas de Big Data (EL-SAPPAGH et al., 2011). O estado da arte aponta para uma evolução deste modelo, incorporando tecnologias de processamento de fluxo (stream processing) que permitem a transformação e análise dos dados em tempo quase real, à medida que são gerados. Esta mudança de paradigma é crucial para habilitar aplicações analíticas ágeis e a tomada de decisão oportuna.
2.2 Arquitetura de Microsserviços para Sistemas de Dados
Em detrimento das arquiteturas monolíticas, onde toda a aplicação é construída como uma única unidade, a abordagem de microsserviços emergiu como um padrão dominante para a construção de sistemas complexos e escaláveis. Esta arquitetura estrutura uma aplicação como uma coleção de serviços pequenos e autônomos, que são desenvolvidos, implantados e escalados de forma independente (NEWMAN, 2015). No contexto de pipelines de dados, a decomposição do processo ETL em microsserviços distintos (e.g., um serviço para extração, outro para transformação, e um terceiro para carga) oferece vantagens significativas. Promove a resiliência, pois a falha em um componente não paralisa todo o sistema; facilita a manutenção e a evolução de cada parte do fluxo de forma independente; e permite a escalabilidade granular, alocando recursos computacionais apenas para as etapas que mais demandam (DRAGONI et al., 2017).
2.3 Tecnologias Fundamentais no Ecossistema de Big Data
A implementação de um pipeline de dados moderno depende de um ecossistema de ferramentas de código aberto que se tornaram padrões de fato na indústria.
Apache Kafka: Para gerenciar a comunicação assíncrona e confiável entre os microsserviços, plataformas de streaming de eventos distribuídos são essenciais. O Apache Kafka funciona como um backbone de dados, um log de commits distribuído, tolerante a falhas e de alta vazão, que permite que múltiplos produtores publiquem fluxos de dados e múltiplos consumidores os leiam de forma desacoplada e em tempo real. Esta característica é vital para absorver picos de volume de dados e garantir a durabilidade das informações em trânsito (KREPS, NARKHEDE, & RAO, 2011).
Apache Spark: Para a etapa de transformação (o “T” do ETL), que frequentemente envolve lógicas complexas e uso intensivo de CPU, são necessários frameworks de processamento distribuído. O Apache Spark se destaca como um motor de computação unificado para processamento de dados em larga escala. Sua capacidade de executar transformações em memória e de forma paralela em um cluster de computadores permite a execução de jobs complexos em volumes massivos de dados de maneira significativamente mais rápida do que as abordagens tradicionais baseadas em MapReduce (ZAHARIA et al., 2016).
Bancos de Dados Colunares (OLAP): Para a persistência e consulta dos dados processados, o destino final do pipeline deve ser otimizado para cargas de trabalho analíticas (OLAP – Online Analytical Processing). Em contraste com os bancos de dados relacionais tradicionais (OLTP), que armazenam dados por linhas, os bancos de dados colunares armazenam dados por colunas. Esta estrutura é altamente eficiente para as consultas analíticas típicas, que agregam valores sobre um subconjunto de colunas, resultando em uma performance de consulta ordens de magnitude superior (ABADI, MADDEN, & HACHEM, 2008). O ClickHouse é um exemplo proeminente de um sistema de gerenciamento de banco de dados colunar de código aberto, projetado para gerar relatórios analíticos em tempo real com alta velocidade.
3 METODOLOGIA
A execução deste estudo foi pautada por uma abordagem metodológica estruturada, visando garantir o rigor científico e a validade dos resultados obtidos. Esta seção detalha o delineamento da pesquisa, o objeto de estudo, os instrumentos utilizados e os procedimentos sequenciais que nortearam o desenvolvimento e a avaliação do artefato tecnológico proposto.
3.1 Delineamento da Pesquisa
A presente investigação classifica-se como um desenvolvimento experimental, uma modalidade de pesquisa aplicada cujo objetivo é a construção e a avaliação de um artefato — neste caso, um sistema de software — para resolver um problema prático e validar uma hipótese de desempenho (WOHLIN et al., 2012). A hipótese central a ser testada é a capacidade da arquitetura proposta de reduzir o tempo de processamento de dados do AICC para um patamar inferior a 30 minutos.
Para a condução do projeto, foi adotada uma metodologia híbrida de gerenciamento. A estrutura macro de governança, incluindo o planejamento de escopo, cronograma e riscos, seguiu os princípios do Project Management Body of Knowledge (PMBOK®). Em contraste, o ciclo de vida do desenvolvimento do software foi gerenciado pelo framework ágil Scrum. Esta abordagem dual permitiu conciliar a necessidade de um planejamento estratégico e documentação rigorosa, exigida pelo contexto corporativo, com a flexibilidade, a iteração e a entrega de valor contínua que caracterizam os métodos ágeis, sendo uma combinação eficaz para projetos de inovação tecnológica com requisitos emergentes (Serrador & Pinto, 2015). O desenvolvimento foi organizado em Sprints quinzenais, cada um resultando em um incremento funcional, testável e potencialmente entregável do software.
3.2 Objeto de Estudo e Amostragem
O objeto de estudo não é uma população, mas sim o universo de dados gerado pela plataforma AICC. Este universo consiste em uma série temporal de arquivos de Call Detail Record (CDR), que se caracterizam como dados semiestruturados em formato textual. A estratégia de amostragem foi intencional e estratificada temporalmente para atender a diferentes objetivos de validação:
Amostra para Testes de Desempenho: Para a validação final da hipótese, foi utilizado o conjunto completo de dados gerados durante uma janela contínua de 24 horas, considerado representativo de uma carga de trabalho diária de produção.
Amostra para Análise Histórica: Para a carga inicial do banco de dados analítico e para a validação de lógicas de negócio e tendências, foi utilizado um conjunto de dados históricos abrangendo um período de três meses.
3.3 Procedimentos de Coleta e Análise de Requisitos
A fase inicial do projeto foi dedicada a uma profunda imersão no domínio do problema, dividida em duas frentes de trabalho:
Elicitação de Requisitos: Foram conduzidos workshops colaborativos e entrevistas semiestruturadas com os stakeholders chave, incluindo analistas de negócio e líderes técnicos. O objetivo foi capturar os requisitos funcionais (e.g., as transformações de dados necessárias) e não funcionais (e.g., metas de desempenho, segurança, manutenibilidade) da solução. Os resultados foram formalizados em um documento de requisitos, contendo casos de uso e histórias de usuário (user stories).
Análise de Dados de Origem: Devido à ausência de uma documentação detalhada sobre a estrutura dos arquivos CDR, foi necessário um procedimento de engenharia reversa. Foram desenvolvidos scripts em Python, utilizando a biblioteca Pandas, para realizar a perfilagem dos dados (data profiling). Este processo envolveu a análise estatística de cada campo para inferir seu tipo de dado (e.g., inteiro, data/hora, texto), formato, cardinalidade e regras de negócio implícitas. O resultado deste procedimento foi a criação de um dicionário de dados detalhado na plataforma Confluence, que serviu como a “fonte da verdade” para toda a equipe de desenvolvimento.
3.4 Arquitetura e Desenvolvimento do Artefato Tecnológico
A materialização da solução seguiu um design de arquitetura de microsserviços, com cada componente sendo desenvolvido e containerizado de forma independente.
Orquestração e Containerização: A tecnologia Docker foi o instrumento utilizado para a containerização de todos os serviços. Para cada módulo, foi criado um Dockerfile que especifica a imagem base, as dependências e os comandos de execução. Um arquivo dockercompose.yml foi utilizado para definir e orquestrar a execução de todo o ecossistema de contêineres em ambientes de desenvolvimento e teste, garantindo a paridade entre eles.
Pipeline de Dados: O fluxo de processamento foi implementado como um pipeline sequencial, orquestrado pela ferramenta Apache Airflow. Foi construído um Grafo Acíclico Dirigido (DAG) que define as tarefas e suas dependências, agendando a execução automática do pipeline completo em uma base diária. As etapas do pipeline foram as seguintes:
Extração (Módulo DEM): Um serviço em Python foi desenvolvido para se conectar de forma segura à fonte de dados na nuvem, baixar os arquivos CDR do dia e publicá-los, mensagem a mensagem, em um tópico específico no Apache Kafka. O Kafka foi utilizado como um buffer de alta performance e tolerante a falhas, desacoplando os processos de extração e transformação.
Transformação (Módulo DTM): Um job Apache Spark, implementado com a API PySpark, foi desenvolvido para atuar como consumidor do tópico do Kafka. Este job executa a lógica de transformação de forma distribuída em um cluster. As transformações incluíram: limpeza (tratamento de valores nulos e inconsistentes), padronização (conversão de tipos de dados e formatos de data), enriquecimento (aplicação do algoritmo heurístico para inferir dados faltantes) e a classificação dos registros. Os dados transformados foram persistidos em uma área de staging em formato Parquet, um formato de armazenamento colunar otimizado para cargas de trabalho analíticas.
Carga (Módulo DLM): Um serviço final, também em Python, foi criado para ler os arquivos Parquet da área de staging e executar a carga em lote (batch insert) no banco de dados de destino.
Armazenamento Analítico: O banco de dados ClickHouse foi selecionado como o sistema de armazenamento analítico. O esquema das tabelas foi projetado utilizando o motor MergeTree, otimizado para inserções rápidas e consultas de alta performance. Foram aplicadas otimizações metodológicas na estrutura da tabela, incluindo o particionamento por mês (utilizando a função toYYYYMM(call_begin)) e a definição de uma chave de ordenação primária alinhada com as colunas mais frequentemente utilizadas em filtros de consulta, visando maximizar a eficiência da compressão e da leitura de dados.
3.5 Procedimentos de Validação e Verificação
A validação do artefato e a verificação de sua conformidade com os requisitos foram realizadas por meio de uma estratégia abrangente:
Testes de Software: Foram implementados testes unitários para validar a lógica de cada componente individualmente. Testes de integração foram executados para verificar a conectividade e a passagem de dados correta entre os diferentes microsserviços (e.g., DEM → Kafka → DTM → Staging → DLM → ClickHouse).
Validação da Hipótese: A validação da hipótese de desempenho foi o procedimento experimental central. Em um ambiente de homologação, uma réplica do ambiente de produção, o pipeline completo foi executado utilizando um volume de dados equivalente a 24 horas de operação. O tempo total de processamento, desde o início da extração até a conclusão da carga, foi cronometrado em múltiplas execuções para garantir a consistência dos resultados.
Verificação de Segurança: Uma consultoria externa especializada foi contratada para realizar uma verificação de segurança contínua. Os procedimentos incluíram: modelagem de ameaças (threat modeling) da arquitetura, revisão de segurança do código-fonte (secure code review) para identificar vulnerabilidades e hardening das imagens Docker para minimizar a superfície de ataque, seguindo o princípio do menor privilégio.
4 RESULTADOS E DISCUSSÕES OU ANÁLISE DOS DADOS
A fase de desenvolvimento experimental culminou na implementação bem-sucedida da plataforma Synapse, um artefato tecnológico funcional que atendeu aos requisitos funcionais e não funcionais estabelecidos. Esta seção apresenta a análise ordenada dos principais resultados obtidos, seguida de uma discussão que os contextualiza à luz dos objetivos do projeto e do referencial teórico.
4.1 Validação da Hipótese Central de Desempenho
O principal resultado do estudo foi a validação empírica da hipótese central. Nos testes de desempenho conduzidos em ambiente de homologação, utilizando um volume de dados representativo de 24 horas de operação do AICC, o pipeline de ETL completo demonstrou um tempo de processamento médio de 28 minutos. Este valor representa uma redução de aproximadamente 98% em comparação com o processo legado, que excedia 24 horas. O resultado corrobora a hipótese de que a aplicação de uma arquitetura de Big Data, fundamentada em processamento distribuído, é eficaz para superar os gargalos de desempenho de sistemas baseados em lote. A confiabilidade dos dados, aferida por meio de validações de consistência e contagem de registros, manteve-se consistentemente acima do limiar de 95% estipulado como meta.
4.2 Análise dos Resultados Arquiteturais e de Engenharia de Software
O desempenho alcançado é consequência direta das decisões arquiteturais e das soluções de engenharia implementadas para superar desafios específicos.
Resiliência e Desacoplamento do Pipeline: A principal dificuldade técnica encontrada foi o gerenciamento da transferência de grandes volumes de dados entre as tarefas executadas em contêineres Docker independentes. A passagem de dados via mecanismos nativos do orquestrador (como XComs do Airflow) mostrou-se inviável devido à limitação de tamanho. A solução, um padrão de staging utilizando o armazenamento de objetos em nuvem, foi um sucesso. O Módulo de Extração (DEM) escreve os dados brutos em um bucket de “entrada”, a DAG do Airflow detecta a chegada desses arquivos e aciona o job do Módulo de Transformação (DTM), que por sua vez escreve os dados processados em um bucket de “saída”. Esta abordagem, além de resolver o problema de transferência de dados, validou os benefícios teóricos do desacoplamento: aumentou a resiliência do pipeline, permitindo que cada etapa seja reexecutada de forma independente em caso de falhas, alinhando-se com os princípios de arquiteturas de dados modernas.
Otimização da Camada de Persistência: Durante os testes de carga, foi identificado um gargalo no Módulo de Carga (DLM). Embora funcional, a ingestão de dados no ClickHouse demorava mais do que o esperado. Uma análise criteriosa revelou que a estrutura da tabela e o tamanho dos lotes de inserção não estavam otimizados. A implementação de uma solução multifacetada — particionamento da tabela por mês (PARTITION BY toYYYYMM(call_begin)), ajuste da chave de ordenação (ORDER BY) para colunas de alta seletividade e otimização do tamanho do lote de inserção — resultou em uma redução superior a 60% no tempo total de carga. Este resultado prático demonstra a importância crítica da modelagem de dados específica para o motor de banco de dados colunar, uma constatação alinhada com a literatura sobre sistemas OLAP (ABADI, MADDEN, & HACHEM, 2008).
4.3 Resultados na Qualidade e Enriquecimento dos Dados
Além dos ganhos de desempenho, o projeto gerou resultados significativos na qualidade e no valor analítico dos dados.
Mitigação de Dados Incompletos: A análise exploratória inicial, viabilizada pela consolidação dos dados no ClickHouse, revelou uma deficiência crítica nos dados de origem: uma grande quantidade de registros de falhas de produto não possuía o número de série do dispositivo (device_no), um campo essencial para a análise de causa raiz. Como a correção retroativa na fonte era inviável, foi desenvolvido e implementado no DTM um algoritmo heurístico que infere o device_no faltante com base em outras interações do mesmo cliente (caller_no) em uma janela de tempo curta. A validação do algoritmo mostrou que a técnica conseguiu recuperar a informação para mais de 40% dos registros problemáticos, transformando dados anteriormente inutilizáveis em insights acionáveis e aumentando significativamente o valor do dataset final.
4.4 Discussão
Os resultados obtidos confirmam a eficácia da abordagem metodológica e tecnológica adotada. A drástica redução no tempo de processamento valida a superioridade das arquiteturas de processamento distribuído, como o Apache Spark (ZAHARIA et al., 2016), em detrimento de processos manuais e monolíticos para cargas de trabalho de Big Data. A implementação bem-sucedida da arquitetura de microsserviços, orquestrada por Airflow e desacoplada por Kafka, corroborou na prática os benefícios de modularidade, escalabilidade e resiliência preconizados pela teoria (NEWMAN, 2015; DRAGONI et al., 2017).
O projeto não apenas atingiu seu objetivo primário de desempenho, mas também gerou valor adicional ao identificar e solucionar problemas de qualidade de dados, como demonstrado pelo desenvolvimento do algoritmo heurístico. Isso evidencia que um pipeline de ETL moderno não deve ser visto apenas como um canal de movimentação de dados, mas como uma etapa fundamental de agregação de inteligência e curadoria da informação. A principal implicação destes resultados é a capacitação da organização para transitar de uma análise de dados reativa e histórica para uma gestão proativa e orientada a dados, permitindo a identificação de tendências e a tomada de decisões em uma cadência muito mais próxima à da geração dos eventos. Como limitação, reconhece-se que o algoritmo heurístico opera com base em probabilidades e não garante 100% de precisão, um ponto que pode ser objeto de aprimoramento em trabalhos futuros.
5 CONCLUSÃO/CONSIDERAÇÕES FINAIS
Este trabalho se propôs a responder à questão da viabilidade de substituir um processo de dados manual e de alta latência por uma arquitetura de Big Data automatizada. Conclui-se que os objetivos fixados na introdução foram plenamente atingidos. A hipótese central de que seria possível reduzir o tempo de processamento de dados de mais de 24 horas para menos de 30 minutos foi confirmada, com os resultados experimentais demonstrando um tempo médio de 28 minutos, ao mesmo tempo em que a confiabilidade da informação foi mantida em um patamar superior a 95%.
A principal contribuição prática deste trabalho é o artefato tecnológico desenvolvido, a plataforma Synapse, que representa uma solução robusta e escalável para o processamento de dados em tempo quase real. A implementação desta plataforma elimina um gargalo operacional crítico, habilitando uma gestão proativa da qualidade e uma tomada de decisão estratégica mais ágil. Do ponto de vista metodológico, o estudo contribui ao apresentar uma validação empírica de que a combinação de uma arquitetura de microsserviços com um stack de tecnologias de código aberto (Apache Kafka, Spark e ClickHouse) constitui um modelo eficaz para resolver desafios de processamento de dados em larga escala em ambientes corporativos. A nova descoberta da pesquisa reside na demonstração de que mesmo dados de origem com deficiências podem ser enriquecidos dentro do próprio pipeline de ETL para gerar valor analítico.
Como limitação do estudo, reconhece-se que o algoritmo heurístico desenvolvido para o enriquecimento de dados, embora eficaz, opera com base em inferências e não garante precisão absoluta em todos os cenários. Para trabalhos futuros, sugere-se a exploração de técnicas de aprendizado de máquina (machine learning) no Módulo de Análise de Dados (DAM) para desenvolver modelos preditivos de falhas, o que poderia agregar ainda mais valor ao negócio. Adicionalmente, a arquitetura modular implementada permite a expansão futura do pipeline para integrar novas fontes de dados, enriquecendo ainda mais o ecossistema analítico.
Em suma, o projeto Synapse transcende a mera otimização de um processo técnico. Ele representa a transição bem-sucedida de um fluxo de dados reativo e ineficiente para um sistema de inteligência de negócio proativo e ágil, transformando um ativo de dados latente em uma ferramenta estratégica para a melhoria contínua e a inovação.
REFERÊNCIAS
ABADI, D. J.; MADDEN, S. R.; HACHEM, N. Column-stores vs. row-stores: how different are they really?. In: Proceedings of the 2008 ACM SIGMOD international conference on Management of data, 2008, p. 967-980. Disponível em: https://dl.acm.org/doi/pdf/10.1145/1376616.1376712. Acesso em: 10 ago. 2025.
CHEN, H.; CHIANG, R. H.; STOREY, V. C. Business Intelligence and Analytics: From Big Data to Big Impact. MIS Quarterly, v. 36, n. 4, 2012, p. 1165-1188. Disponível em: https://doi.org/10.2307/41703503. Acesso em: 14 ago. 2025.
DRAGONI, N. et al. Microservices: yesterday, today, and tomorrow. In: Present and Ulterior Software Engineering. Springer, Cham, 2017. p. 195-216. Disponível em: https://arxiv.org/pdf/1606.04036.pdf. Acesso em: 15 ago. 2025.
EL-SAPPAGH, S.; HENDAWI, A.; EL-BASTAWISSY, A. A proposed model for data warehouse ETL processes. Journal of King Saud University-Computer and Information Sciences, v. 23, n. 2, 2011, p. 91-104. Disponível em: https://doi.org/10.1016/j.jksuci.2011.05.003. Acesso em: 18 ago. 2025.
GROLINGER, K. et al. Data management in cloud environments: NoSQL and NewSQL data stores. Journal of Cloud Computing: Advances, Systems and Applications, v. 2, n. 1, 2013, p. 22. Disponível em: https://doi.org/10.1186/2192-113X-2-22. Acesso em: 17 ago. 2025.
KREPS, J.; NARKHEDE, N.; RAO, J. Kafka: A distributed messaging system for log processing. In: Proceedings of the NetDB workshop, 2011. Disponível em: http://notes.stephenholiday.com/Kafka.pdf. Acesso em: 19 ago. 2025.
LANEY, D. 3D Data Management: Controlling Data Volume, Velocity, and Variety. Gartner, 2001. Disponível em: https://blogs.gartner.com/doug-laney/files/2012/01/ad949-3D-DataManagement-Controlling-Data-Volume-Velocity-and-Variety.pdf. Acesso em: 17 ago. 2025.
LU, Y. Industry 4.0: A survey on technologies, applications and open research issues. Journal of Industrial Information Integration, v. 6, 2017, p. 1-10. Disponível em: https://doi.org/10.1016/j.jii.2017.04.005. Acesso em: 18 ago. 2025.
NEWMAN, S. Building Microservices: Designing Fine-Grained Systems. O’Reilly Media, Inc., 2015. Disponível em: https://www.oreilly.com/library/view/buildingmicroservices/9781491950340/. Acesso em: 20 ago. 2025.
SERRADOR, P.; PINTO, J. K. Does Agile work?—A quantitative analysis of agile project success. International Journal of Project Management, v. 33, n. 5, 2015, p. 1040-1051. Disponível em: https://doi.org/10.1016/j.ijproman.2015.01.006. Acesso em: 13 ago. 2025.
WANG, S.; WANG, H.; LI, J. A review of data-driven smart manufacturing. Journal of Manufacturing Systems, v. 48, 2018, p. 60-76. Disponível em: https://doi.org/10.1016/j.jmsy.2018.04.005. Acesso em: 12 ago. 2025.
WOHLIN, C. et al. Experimentation in software engineering. Springer Science & Business Media, 2012. Disponível em: https://link.springer.com/book/10.1007/978-3-642-29044-2. Acesso em: 10 ago. 2025.
ZAHARIA, M. et al. Apache Spark: a unified engine for big data processing. Communications of the ACM, v. 59, n. 11, 2016, p. 56-65. Disponível em: https://dl.acm.org/doi/pdf/10.1145/2934664. Acesso em: 17 ago. 2025.
1Gerente de Projetos do Instituto Conecthus. e-mail: holden.offmenn@conecthus.org.br
2Cientista de Dados do Instituto Conecthus. e-mail: itala.ferreira@conecthus.org.br
3Cientista de Dados do Instituto Conecthus. e-mail: daniely.lobato@conecthus.org.br
4Desenvolvedor Back-End do Instituto Conecthus. e-mail: jhonatas.luz@conecthus.org.br
5Analista de Testes do Instituto Conecthus. e-mail: luana.carvalho@conecthus.org.br
6Analista de Negócios da Huawei. e-mail: lais.olimpio@huawei.com
7Gerente de Negócios da Huawei. e-mail: andre.santin@huawei.com