Mastering Modern Pandas

Olá, daqui fala o Alex do DEV STORIES DOT EU. Dominar o Pandas moderno, episódio 1 de 8. Vais buscar duas colunas de dados financeiros, somas as duas, e a soma final não faz sentido. As linhas deslocaram-se, e acabaste de somar o preço de fecho de ontem ao volume de hoje. Isso acontece quando tratas os dados como uma grelha burra em vez de confiares na abstração central: DataFrames e alinhamento de labels. As pessoas muitas vezes olham para o pandas e pensam que é apenas uma folha de cálculo programática ou um array NumPy bidimensional comum. Não é. Um array NumPy simples depende de uma indexação posicional estrita. Se somares dois arrays, o item na posição zero é somado ao item na posição zero. Se faltar uma linha aos teus dados, tudo se desloca, e os teus cálculos são corrompidos silenciosamente. O pandas resolve exatamente este problema ao desacoplar os dados da sua posição física na memória. Usa um alinhamento de dados intrínseco, o que significa que alinha os dados por labels, nunca por posição. Para entenderes isto, olha para a base da biblioteca, a Series. Uma Series é um array unidimensional que pode guardar qualquer tipo de dados. Ao contrário de uma lista normal, cada item numa Series está firmemente ligado a uma label. Estas labels, em conjunto, formam o que o pandas chama de index. Podes usar integers como labels, mas, mais frequentemente, usas strings ou timestamps. Um DataFrame é simplesmente uma coleção destes objetos Series a atuar como colunas, todos a partilhar o mesmo index, colocados lado a lado. Aqui está a ideia principal. Quando fazes uma operação no pandas, o index dita o comportamento. Imagina que tens duas Series de retornos diários de ações. A Series A tem dados para segunda, terça, quarta e quinta-feira. A Series B tem dados para quarta, quinta e sexta-feira. Se mandares o pandas somar estas duas Series, ele ignora a sua ordem física. Ele olha para as labels de data. Encontra a quarta-feira na Series A e soma-a à quarta-feira na Series B, mesmo que a quarta-feira seja o terceiro item no primeiro dataset e o primeiríssimo item no segundo dataset. Isto levanta o problema dos dias que não se sobrepõem. A segunda-feira existe na primeira Series, mas não na segunda. A sexta-feira existe na segunda, mas não na primeira. O pandas não dá crash, e certamente não tenta adivinhar um valor. Em vez disso, cria um novo index que é a união de todas as labels de ambos os inputs. Para qualquer label que não exista em ambos os lados, o pandas insere um NaN, que significa Not a Number. A operação é concluída com sucesso, e consegues ver imediatamente onde os teus dados estão incompletos. Nunca tens de escrever um loop para verificar se as datas batem certo. O alinhamento é automático, construído diretamente na própria estrutura de dados. Esta mesma lógica escala diretamente para DataFrames. Um DataFrame alinha-se em ambas as dimensões simultaneamente. Quando operas com dois DataFrames, o pandas faz corresponder a label da linha à label da linha, e o nome da coluna ao nome da coluna. Alinha toda a estrutura perfeitamente antes de executar uma única operação matemática. Tudo o que não se sobrepuser tanto nas linhas como nas colunas é marcado como dados em falta. O verdadeiro poder do pandas não está na matemática que faz, mas sim no facto de a label viajar sempre com os dados, tornando as incompatibilidades posicionais estruturalmente impossíveis. Se quiseres apoiar o programa, podes encontrar-nos ao pesquisar por DevStoriesEU no Patreon. Obrigado por ouvirem, e happy coding a todos!

Olá, daqui é o Alex da DEV STORIES DOT EU. Dominar o Pandas Moderno, episódio 2 de 8. Extrais uma slice dos teus dados, atualizas um único valor e, de repente, o teu dataset original está corrompido. Ou pior, recebes um warning imprevisível e não fazes ideia se a tua atualização foi realmente aplicada à slice ou à source. A versão 3.0 finalmente resolve este caos, tornando o Copy-on-Write o comportamento default. O Copy-on-Write reescreve fundamentalmente a forma como o pandas gere a memória. Em versões anteriores, o pandas frequentemente criava cópias defensivas para evitar que modificasses acidentalmente o dataset original. Se filtrasses um dataset, o pandas copiava-o. Se fizesses drop de uma column, o pandas copiava o resto. Isto desperdiçava quantidades enormes de memória e ciclos de CPU. Quando não copiava, retornava uma view, o que significava que modificar o novo objeto alterava silenciosamente o parent. Com o Copy-on-Write, qualquer DataFrame ou Series derivado de outro partilha exatamente a mesma memória subjacente. Isto significa que extrair um subset, fazer drop de uma column ou fazer reset a um index é praticamente instantâneo. Nenhuns dados são duplicados à partida. Aqui está o ponto chave. Não confundas uma legacy view com uma lazy copy do Copy-on-Write. Numa view tradicional, tanto o parent como o child apontam para a mesma memória, e uma alteração num altera o outro. O Copy-on-Write é diferente. A memória partilhada é temporária e estritamente protegida. A partilha dura apenas até tentares alterar alguma coisa. Considera um cenário concreto. Tens um DataFrame com perfis de utilizadores. Selecionas a column age e atribuis a uma nova variável chamada age subset. Neste exato momento, a age subset ocupa zero memória extra. Aponta diretamente para o DataFrame original de perfis de utilizadores. A seguir, atualizas o primeiro valor na tua age subset para noventa e nove. É aqui que a parte write do Copy-on-Write acontece. O pandas deteta a modificação. Antes de executar a tua atualização, verifica se algum outro objeto está a partilhar este bloco de dados específico. Como o DataFrame parent ainda o está a usar, o pandas aloca instantaneamente nova memória, copia os dados, e depois escreve o valor noventa e nove na nova localização. O teu DataFrame parent permanece intacto e seguro. Mutar um subset nunca muta o parent. Este mecanismo funciona perfeitamente em cascata em chained operations. Quando encadeias operações como fazer drop de rows vazias, substituir values e fazer rename de columns, as versões mais antigas do pandas criavam uma physical copy a cada passo. Com o Copy-on-Write, esses passos intermédios simplesmente partilham memória. Uma physical copy só é triggered quando um passo realmente muta os data arrays subjacentes. Se uma operação apenas reorganiza referências, não ocorre nenhuma cópia. Isto elimina completamente a corrupção acidental de dados. Já não precisas de tentar adivinhar se uma operação retornou uma view ou uma copy, e nunca mais vais ver o warning Setting With Copy. A regra é absoluta: um objeto parent e um objeto child nunca se vão modificar mutuamente. Ao adiar as copies até ao milissegundo exato em que ocorre uma modificação, o pandas dá-te a fast performance e o low memory footprint das views, aliados à segurança rigorosa das deep copies. É tudo por este episódio. Obrigado por ouvires, e continua a desenvolver!

Olá, daqui fala o Alex da DEV STORIES DOT EU. Dominar o Pandas Moderno, episódio 3 de 8. Carregas um dataset com alguns milhões de linhas e, de repente, o uso de memória dispara. Os números estão bem, mas as colunas de texto e os missing values estão a destruir silenciosamente a tua RAM. A solução é uma mudança fundamental na forma como o pandas armazena dados, e é exatamente sobre isso que este episódio trata: a Engine Room do PyArrow. Se já ouviste falar do Apache Arrow, podes pensar que é estritamente para grandes sistemas distribuídos como o Spark ou o Hadoop. Não é. O Arrow é agora um formato de memória nativo de primeira classe e um execution engine integrado diretamente no pandas. Durante anos, o pandas dependeu inteiramente do NumPy. O NumPy é incrivelmente rápido para cálculos numéricos densos, mas tem um enorme ponto cego em relação a missing data. O NumPy não tem um conceito nativo de um missing integer ou de um missing boolean. Se tens uma coluna de integers e um único valor está em falta, o pandas tem sido historicamente forçado a converter a coluna inteira para floating-point numbers só para poder usar o marcador Not a Number. Isto altera os teus data types, arruína os exact matches e consome mais memória. O PyArrow resolve isto usando um validity bitmap. Em vez de alterar o data type para acomodar um missing value, o Arrow mantém os teus integers como integers. Adiciona um array oculto e altamente comprimido de uns e zeros ao lado dos teus dados. O número um significa que o valor é válido. O zero significa que está em falta. O teu data type permanece intacto, e rastrear os missing values custa quase zero de memória. Aqui está o ponto chave. A poupança de memória é ainda mais extrema quando lidamos com texto. Tradicionalmente, o pandas armazena strings usando o data type object do NumPy. Isto significa que a coluna não guarda realmente o teu texto. Guarda memory pointers. Cada linha aponta para um string object standard do Python espalhado algures na memória do teu computador. Se tiveres dez milhões de linhas de texto, tens dez milhões de pointers e dez milhões de string objects separados. O memory overhead é impressionante, e iterar por eles é terrivelmente lento. O PyArrow muda a arquitetura por completo. Quando configuras as tuas colunas do pandas para usar um data type string do PyArrow, o texto é armazenado num único bloco contíguo de memória. A coluna apenas regista os byte offsets. Regista exatamente onde cada palavra começa e acaba nesse grande bloco contínuo. Imagina um dataset de alta cardinalidade. Tens uma coluna de user agent strings ou transaction IDs únicos. Muitas das linhas estão vazias. Se leres isto para o pandas da forma tradicional, ele assume por default um object array do NumPy. Agora, diz ao pandas para usar antes o engine do PyArrow, atribuindo explicitamente um data type string com backend PyArrow durante o teu read step. Instantaneamente, o memory footprint cai, muitas vezes em cinquenta por cento ou mais. A melhoria vai além dos limites da RAM. Como os dados estão agora bem compactados numa estrutura construída para analytics, as operações de string matching aceleram. Se executares uma pesquisa por regular expression nessa coluna, o engine do Arrow processa os raw bytes diretamente ao nível do sistema. Faz um bypass completo ao lento object overhead do Python. Ficas com colunas de integers que permanecem realmente integers quando há missing data, e operações de strings que não asfixiam o teu hardware. Se processas texto ou messy data, depender do object array do NumPy é obsoleto. Usar data types com backend PyArrow é a forma mais rápida de tornar um pipeline pesado de pandas instantaneamente mais leve. Obrigado por ouvirem, happy coding a todos!

Olá, daqui é o Alex da DEV STORIES DOT EU. Dominar o Pandas Moderno, episódio 4 de 8. Tens um ficheiro Parquet de vários gigabytes com cem colunas. Só precisas de quatro delas para executar as tuas métricas. Se o teu primeiro passo for carregar o ficheiro inteiro para um dataframe e depois filtrar as colunas, estás a desperdiçar quantidades enormes de RAM e ciclos de CPU antes mesmo da tua análise começar. A solução está em dominar a Ingestão de Dados Moderna. O principal bottleneck na ingestão de dados é o input e output do disco. As funções de leitura do Pandas, como read underscore csv e read underscore parquet, fazem o scan dos dados do disco para a memória. Para minimizar esta transferência, usas um argumento chamado usecols. Passas uma lista com os nomes exatos das colunas que queres. O parser lê apenas essas colunas específicas do ficheiro. O ganho de performance que vês depende muito do formato do teu ficheiro. Os ficheiros CSV guardam os dados linha a linha. Quando usas o usecols com um ficheiro CSV, o parser ainda tem de fazer o scan de todo o ficheiro de texto linha a linha, mas descarta imediatamente as colunas desnecessárias antes de alocar memória para o dataframe. Os ficheiros Parquet, no entanto, guardam os dados coluna a coluna. Para um ficheiro Parquet de cem colunas, onde só precisas de quatro colunas de métricas, passar o usecols significa que o parser ignora completamente os blocos do ficheiro que contêm as outras noventa e seis colunas. Lê do disco apenas os bytes de que absolutamente precisa. Isto reduz drasticamente tanto o teu tempo de leitura como o teu memory footprint. Restringir colunas é apenas o primeiro passo. A próxima otimização acontece na forma como o Pandas guarda essas colunas em memória. Historicamente, o Pandas dependia inteiramente de arrays NumPy. O NumPy é excelente para computação numérica densa, mas tem dificuldades com dados de texto e missing values. Guarda as strings como objetos Python dispersos em memória, e força as colunas de integers a tornarem-se floats apenas para representar missing data. Para resolver isto, o Pandas introduziu o argumento dtype backend. Quando defines este argumento para a string pyarrow, o Pandas usa o Apache Arrow como backend dos teus dados. O Arrow guarda as strings em blocos de memória contíguos e altamente eficientes, e usa uma bitmask separada para fazer o tracking dos missing values, mantendo os teus integers intactos. Aqui está o insight principal. Podes pensar que o Pandas lê os dados primeiro para arrays NumPy e depois os converte para Arrow. Não é isso que acontece. Quando especificas o backend PyArrow durante a função read, o Pandas faz bypass ao NumPy por completo durante a fase de parse. Os dados fluem diretamente do ficheiro no disco para arrays PyArrow em memória. Isto evita a severa penalização de performance das alocações de memória intermédias. Vamos olhar para o pipeline completo. Chamas o read underscore parquet. Primeiro, passas o teu file path. Segundo, passas o usecols com uma lista das tuas quatro colunas de métricas. Terceiro, defines o argumento dtype backend para pyarrow. O parser salta diretamente para as quatro colunas no disco, extrai-as, e faz o stream delas diretamente para a memória com backend Arrow. Acabas com um dataframe leve e super rápido, que contém exatamente o que precisas, com o backend de data types modernos. Filtrar colunas na camada de IO em vez da camada de aplicação é a maneira mais eficaz de evitar crashes de out-of-memory no Pandas. É tudo por este episódio. Obrigado por ouvires, e continua a desenvolver!

Olá, daqui é o Alex do DEV STORIES DOT EU. A dominar o Pandas moderno, episódio 5 de 8. Tens uma lista de dez milhões de transações, e cada uma delas tem apenas um customer ID. Precisas dos nomes reais dos clientes associados a essas transações. Se estás a escrever um loop em Python ou a usar um dictionary mapping para mapear esses IDs para os nomes, estás a desperdiçar ciclos de CPU e memória. O Pandas tem um engine otimizado, criado especificamente para operações estilo SQL numa única linha. Hoje vamos falar sobre álgebra relacional: merge e join. Antes de avançarmos, vamos esclarecer uma confusão comum. As pessoas muitas vezes confundem merge com concatenação. A concatenação é simplesmente empilhar arrays uns em cima dos outros ou lado a lado. O merge é completamente diferente. O merge serve para joins em bases de dados relacionais. Ele alinha as rows de duas tabelas diferentes com base nos valores de keys partilhadas. A função principal para isto é o pandas ponto merge. Ela recebe dois DataFrames, aos quais chamamos left table e right table. Lembra-te do nosso cenário das transações. O teu left DataFrame é uma fact table enorme com milhões de compras. O teu right DataFrame é uma dimension table mais pequena com os detalhes dos clientes, como nomes e endereços de email. Ambas as tabelas partilham uma coluna chamada customer ID. Este setup específico chama-se um many-to-one join. Tens muitas transações que pertencem a um único cliente. Quando fazes o merge usando a key customer ID, o pandas pega no registo único do cliente da right table e faz o broadcast por todas as transações correspondentes na left table. Aqui está a ideia principal. O parâmetro mais crítico que controlas é o argumento how. Isto dita quais keys sobrevivem ao merge e entram no resultado final. Por omissão, o pandas usa um inner join. Se não especificares o argumento how, o resultado apenas mantém as rows onde o customer ID existe em ambas as tabelas. Se um cliente fez uma transação, mas o seu registo foi apagado da base de dados de clientes, essa transação desaparece completamente do teu resultado do merge. Para evitar perder dados da tua tabela principal, usas um left join. Ao passar left para o argumento how, o pandas mantém todas as rows da tua left table, que é a tua enorme lista de transações. Se uma transação tiver um customer ID que não existe na right table, o pandas mantém a row da transação na mesma, mas preenche os detalhes em falta do cliente com valores Not a Number. Esta é exatamente a lógica que queres ao anexar dimension details a uma fact table principal. O oposto exato é um right join. Passar right mantém todas as rows da dimension table de clientes, independentemente de terem ou não transações correspondentes na left table. Ficas com uma lista de todos os clientes, e aqueles que não compraram nada simplesmente mostram missing values para os dados da transação. Por fim, tens o outer join. Passa outer para o argumento how, e o pandas mantém tudo. Ele faz a união das keys de ambos os frames. Cada transação e cada cliente entram no dataset final, com missing values a preencher as lacunas onde não se encontra um match perfeito. O inner join por omissão descarta silenciosamente os dados sem correspondência, por isso, a não ser que queiras filtrar rows explicitamente, deves sempre especificar um left join ao anexar lookup tables ao teu dataset principal. É tudo por este episódio. Obrigado por ouvires, e continua a desenvolver!

Olá, daqui é o Alex da DEV STORIES DOT EU. Dominar o Pandas Moderno, episódio 6 de 8. Provavelmente pensas que agrupar dados se resume a somar números para encontrar um total ou uma média. Mas e se precisares de avaliar uma única row com base no comportamento do grupo a que pertence, sem perder a estrutura original do teu dataset? Isto exige ir além de simples resumos e usar o padrão Split-Apply-Combine. Quando chamas um método groupby no pandas, acionas um processo sequencial de três etapas. Primeiro é o split. O pandas pega no teu dataset inteiro e divide-o em grupos independentes com base numa key que tu forneces. A seguir vem o passo de apply, onde uma função é executada em cada grupo, de forma completamente independente dos outros. Finalmente, o passo de combine pega nos resultados de cada grupo e volta a uni-los numa única estrutura de dados. Muitos developers pensam que o passo de apply serve apenas para agregação. A agregação pega num grupo de valores e devolve um único número, como a soma ou a média. Se agrupares um dataset de suporte ao cliente por agente e pedires o tempo médio de resolução, obténs um novo dataset com uma row por agente. Isso é útil, mas é apenas um terço da história. Aqui está a ideia principal. O passo de apply é usado com a mesma frequência para transformação e filtragem. Uma transformação faz um cálculo no grupo, mas devolve um objeto que é indexado exatamente como os dados originais. Não reduz a contagem de rows. Vamos voltar ao nosso dataset de suporte ao cliente. Queres saber se um ticket específico demorou um tempo invulgarmente longo a ser resolvido. Mas um tempo invulgar para um agente júnior pode ser um tempo normal para um agente sénior que lida com problemas altamente complexos. Precisas do z-score do tempo de resolução, relativo apenas à média histórica desse agente específico. Fazes o split dos dados por agente, e aplicas uma função de transformação que calcula o z-score. O pandas calcula a média e o desvio padrão para o agente A, padroniza os tickets do agente A, faz exatamente o mesmo para o agente B, e depois faz o combine. Recebes o teu dataset original de volta, row a row, mas agora cada ticket tem um score padronizado baseado estritamente no seu contexto de grupo específico. A terceira aplicação principal é a filtragem. Isto permite-te descartar grupos inteiros com base numa propriedade coletiva, em vez de avaliar rows individuais. Supõe que queres analisar esses z-scores dos tickets, mas alguns agentes no teu dataset processaram apenas dois ou três tickets. As suas médias não têm significado estatístico. Podes usar uma função de filter no teu objeto agrupado para verificar o tamanho de cada grupo. Se um grupo tiver menos de dez tickets, a lógica de filter devolve false, e o pandas descarta todas as rows pertencentes a esse agente. O passo de combine devolve então um dataset contendo apenas os tickets dos agentes com um tamanho de amostra válido. Fazes o split dos dados por uma key, aplicas uma regra lógica que avalia o grupo, e fazes o combine dos sobreviventes. A agregação reduz os dados. A transformação padroniza os dados dentro do seu contexto local. A filtragem descarta dados com base em regras de grupo. O verdadeiro poder do padrão split-apply-combine é que te permite manipular rows individuais usando o contexto ao nível do grupo, sem nunca escreveres um loop manual. Se achas estes deep dives úteis e queres apoiar o programa, podes procurar por DevStoriesEU no Patreon. Gostaria de tirar um momento para te agradecer por ouvires — ajuda-nos imenso. Tem um ótimo dia!

Olá, daqui é o Alex da DEV STORIES DOT EU. Dominar o Pandas Moderno, episódio 7 de 8. Criar as tuas próprias agregações de tempo à mão é um pesadelo de intervalos em falta, anos bissextos e lógica de dias úteis. Se dás por ti a escrever código custom para arredondar timestamps raw em buckets regulares, estás a trabalhar demasiado. A solução é dominar as time series usando as estruturas temporais nativas do pandas. A espinha dorsal da funcionalidade de time series no pandas é o DatetimeIndex. Em vez dos números inteiros de linha standard, o index do teu dataframe torna-se numa sequência estrita de timestamps precisos. Fazer o upgrade do teu index para um DatetimeIndex muda fundamentalmente a forma como o dataframe se comporta, tornando toda a estrutura temporalmente consciente. Isto permite fazer slicing nativo baseado no tempo. Se precisares de dados apenas de outubro de 2023, passas a simples string 2023-10 para o row locator. O pandas calcula automaticamente as boundaries exatas ao microssegundo para esse mês e devolve o subset correto. Podes passar strings de data parciais até à hora ou ao minuto, e o index resolve a matemática de timestamp subjacente. Assim que os teus dados estiverem temporalmente conscientes, normalmente precisas de os agregar. Muitos developers confundem o resampling baseado no tempo com o grouping básico. Tentam aplicar operações de group-by standard a uma coluna de data. Essa abordagem falha quando lidamos com time series confusas do mundo real. O grouping standard olha apenas para as rows explícitas atualmente presentes no teu dataframe. Se um servidor for abaixo durante uma hora, uma operação de group-by standard simplesmente salta essa hora por completo. A tua timeline de output terá um gap oculto, estragando quaisquer cálculos subsequentes baseados no tempo. Aqui está o insight principal. O método dot resample é fundamentalmente diferente porque entende nativamente a lógica de calendário. Ele projeta uma grid de tempo rígida e contínua sobre os teus dados. Se fizeres resample em intervalos de dez minutos, e não chegarem dados durante uma window específica de dez minutos, o pandas gera esse bucket na mesma. Deixa os valores vazios, preservando a estrita integridade matemática da tua timeline. O resampling entende inerentemente intervalos vazios, durações irregulares de meses e calendários de dias úteis que excluem fins de semana e feriados. Considera o cenário de um analista quantitativo a processar dados de trading. Estás a receber tick data de alta frequência de uma exchange. As trades individuais chegam em intervalos completamente irregulares, às vezes três por microssegundo, às vezes nenhuma durante vinte segundos. O teu modelo de pricing não consegue consumir este caos. Ele requer bars de cinco minutos perfeitamente alinhadas. Como os preços das tuas trades estão mapeados para um DatetimeIndex, chamas o método dot resample no teu dataframe e passas a string de frequência 5min. Isto mapeia cada tick errático para uma grid rigorosa de cinco minutos. Para alimentar um modelo financeiro, precisas especificamente dos preços Open, High, Low e Close para cada bucket. Em vez de escreveres funções custom para extrair a primeira, a máxima, a mínima e a última trade de cada window, fazes chain do método dot ohlc diretamente na tua chamada de resample. O pandas calcula as quatro métricas de uma só vez, fazendo output de um dataset bem estruturado de bars de cinco minutos. Aqueles intervalos vazios que mencionámos anteriormente permanecem intactos neste output. Podes então fazer chain de outro método para fazer forward-fill dos preços de Close anteriores para os gaps vazios, garantindo que o teu modelo tem sempre dados válidos. O resampling transforma records erráticos e event-driven numa timeline previsível e matematicamente sólida, sem exigir que escrevas uma única linha de lógica de calendário. Obrigado por ouvires. Até à próxima!

Olá, daqui é o Alex da DEV STORIES DOT EU. Dominar o Pandas Moderno, episódio 8 de 8. Antes de pedires uma cloud instance gigante ou recorreres a um cluster de computação distribuída, podes ficar surpreendido por saber que consegues processar terabytes de dados diretamente no teu portátil. A maioria dos erros de out-of-memory não exige uma nova framework, apenas uma mudança na forma como lês os ficheiros. Hoje, vamos falar sobre Scaling para datasets out-of-core. O processamento out-of-core significa simplesmente trabalhar com datasets que são maiores do que a memória disponível do teu sistema. Uma reação comum a um crash de out-of-memory é assumir que o pandas atingiu o seu limite máximo. Muitas vezes, as pessoas saltam logo para a reescrita das suas pipelines em PySpark ou Dask. Mas o pandas consegue lidar com dados massivos nativamente se parares de tentar carregar o dataset inteiro para a RAM de uma só vez. Padrões simples de generators resolvem a grande maioria destes problemas de scaling. O principal mecanismo para processamento out-of-core é o chunking. Se estiveres a lidar com um único ficheiro de texto gigante, a função read standard aceita um argumento de chunk size. Quando forneces este argumento, o pandas deixa de devolver um DataFrame. Em vez disso, devolve um iterator. Sempre que o teu código avança o iterator, o pandas lê apenas o número especificado de linhas do disco e devolve-as como um DataFrame normal. Tu aplicas a tua lógica a esse chunk, extrais o resultado e descartas o chunk. Como os dados antigos são limpos da memória antes de o próximo batch ser lido, a tua utilização de memória mantém-se completamente estável, independentemente do tamanho do ficheiro original. É aqui que a coisa fica interessante. A infraestrutura de dados moderna raramente depende de um único ficheiro de texto gigante. Normalmente, grandes datasets são armazenados como diretórios que contêm centenas de ficheiros menores e particionados, tipicamente num formato binário como o Parquet. Os ficheiros Parquet são altamente comprimidos e carregam muito rápido, mas continuas a não conseguir carregar cinquenta gigabytes de ficheiros Parquet para dezasseis gigabytes de RAM. Para lidar com isto, aplicas o conceito de chunking manualmente ao longo dos ficheiros. Imagina que tens um diretório de ficheiros Parquet anuais e queres calcular a frequência total de categorias em todo o dataset histórico. Constróis um loop iterativo simples. Primeiro, inicializas uma Series vazia do pandas. Esta vai servir como o teu acumulador para os totais globais. A seguir, iteras pelo teu diretório, ficheiro a ficheiro. Dentro do loop, lês o ficheiro atual para um DataFrame. Agora, corres a função value counts na coluna específica que estás a analisar. Isto dá-te uma Series com as frequências apenas para esse ano específico. O passo crucial é combinar este resultado local com o teu acumulador global. Fazes isto chamando o método add na tua Series global e passando a Series local. Como algumas categorias podem existir num ficheiro mas não noutro, tens de definir o argumento fill value para zero. Isto garante que o pandas alinha os indexes corretamente e soma as contagens sem introduzir missing values. Assim que o loop termina de processar esse ficheiro, passa para o próximo. O Python faz automaticamente o garbage collect do DataFrame antigo. Na prática, estás a fazer streaming de um dataset massivo pela memória, um ficheiro de cada vez, construindo uma agregação global contínua. O processamento out-of-core não é sobre atirar hardware a um problema. É sobre manter o teu active state pequeno e empurrar as agregações matemáticas para o nível de cada chunk individual. Como este é o fim da série, encorajo-te vivamente a explorares a documentação oficial do pandas sobre scaling e a experimentares estes padrões hands-on com os teus próprios dados. Se tiveres tópicos que queiras que abordemos em séries futuras, visita devstories dot eu e diz-nos. Obrigado por passares uns minutos comigo. Até à próxima, fica bem.