Do disco à memória colunar: o que o Apache Arrow resolve que o Parquet não resolve

O texto compara duas camadas que costumam ser confundidas. O Parquet guarda dados colunares em disco, de forma compacta. O Arrow define como essas colunas ficam na RAM depois de decodificadas. A frase do FAQ oficial do Arrow resume: o Parquet é como o dado colunar fica no disco, o Arrow é como ele fica na memória. Engines como DuckDB, Spark e pandas entram na história porque cada uma, antes do Arrow, decodificava o Parquet para um layout privado (objetos no heap, arrays NumPy e assim por diante).

O argumento técnico é de hardware. A CPU lê memória em cache lines de cerca de 64 bytes, então uma coluna int32 contígua traz 16 valores por busca. Valores espalhados em objetos do heap forçam uma busca por valor e desperdiçam a linha com cabeçalho de objeto. Além disso, instruções SIMD só operam sobre dados adjacentes e uniformes, algo que pilhas de objetos com ponteiros não oferecem. O Arrow usa um buffer tipado por coluna mais um bitmap de nulos, e strings ficam em pares valores+offsets. Já o autor do texto (um artigo no Medium) é distinto do DuckDB, que aparece como exemplo de engine que roda SQL direto sobre buffers Arrow em zero copy. O texto não traz repositório do projeto nem benchmarks próprios. O ganho de "10x+" citado vem de uma estimativa do autor, não de medição apresentada.

A cobertura do CEVIU mostra o mesmo tema em camadas. Em 20 de maio de 2026, o CEVIU noticiou "Apache Arrow como formato universal para intercâmbio de dados", com a tese de evitar serializar e copiar dados entre ferramentas. Em 8 de junho de 2026, em "Apache Arrow Flight: a infraestrutura de alta performance para mover dados em escala", o foco foi o transporte de RecordBatches com zero-copy. A matéria de agora volta um passo e explica o porquê no nível de memória e CPU. Também ajuda a separar da novidade de 28 de setembro de 2026, "Apache Parquet Aprimora Compressão de Dados com Nova Codificação ALP", que mexe no lado do disco, não no da memória.

Para quem opera pipelines, a leitura é prática: o gargalo muitas vezes não está no formato do arquivo, e sim na conversão entre ferramentas. Se Spark, Python e DuckDB trocam dados em Arrow, a "taxa de conversão" some. Ao desenhar um pipeline, vale perguntar onde os dados viram objetos de linha e se isso é mesmo necessário.