Notícias

Em entrevista ao C3SL, o ex-mestrando do PPGInf ressalta como o software livre torna o acesso a ferramentas analíticas avançadas mais simples, eficiente e disponível para pesquisadores, empresas e entusiastas ao redor do mundo

Nascido em Fortaleza, no Ceará, Pedro Thiago Timbó Holanda trilhou um caminho que o levou do DINF e do PPGInf/UFPR ao protagonismo global na comunidade de software livre. Formado em Computação pela Universidade Federal do Ceará, Pedro foi bolsista de iniciação científica desde o primeiro semestre, já com direcionamento à pesquisa em bancos de dados. “Comecei testando hipóteses, sempre em busca de novas soluções, ainda no contexto acadêmico e do software open source”, relembra.

Artigo do mestrado aprovado em evento internacional abriu portas para a criação do DuckDB, diz Pedro

Durante o mestrado na UFPR, orientado pelo professor do Dinf e pesquisador do C3SL, Eduardo Almeida, Pedro aprofundou-se no estudo de indexação adaptativa, área-chave para bancos de dados modernos e ferramentas analíticas. Sua dissertação, embasada em técnicas inovadoras como o Database Cracking, conectou sua pesquisa à linha de frente de grupos internacionais — especialmente o CWI, renomado centro holandês de pesquisa em ciências exatas.

Esse olhar inovador sobre indexação e análise de dados foi essencial na transição ao doutorado no CWI, em Amsterdã, aprofundando pesquisas em indexação progressiva. Lá, Pedro aproximou-se de comunidades de software livre e do tema que norteia sua carreira: a democratização do acesso a ferramentas analíticas eficientes.

É nesse contexto que surge sua maior contribuição: o DuckDB, banco de dados analítico de código aberto criado no CWI, do qual Pedro é cofundador do laboratório comercial, o DuckDB Labs. “A grande motivação foi aproximar a potência dos bancos de dados do universo da análise de dados no ambiente open source, tornando mais simples e acessível o processamento massivo de dados para todos”, explica.

Ao se inspirar no universo do SQLite e no apelo “SQLite for analytics”, Pedro buscou unir a simplicidade de uso e a eficiência de performance em um software livre que pudesse ser rapidamente adotado por pesquisadores, empresas e entusiastas. O DuckDB, distribuído sob licença open source, rapidamente se tornou referência mundial. O sucesso da ferramenta reflete a força da comunidade do software livre: “Quem desenvolve uma solução aberta permite avanços globais. O open source é tanto um convite quanto um compromisso de impactar o mundo”, afirma Pedro.

Pedro Thiago, o professor Eduardo Almeida e Mark Raasveldt, Co-criador do DuckDB

Durante sua carreira, Pedro também colaborou com a Microsoft, sempre defendendo a abertura do conhecimento e o impacto transformador do software livre. Essa filosofia marcou sua trajetória desde os tempos de estudante na UFPR, “onde aprendi o valor de compartilhar conhecimento e participar de comunidades acadêmicas e open source”.

Esta reportagem integra uma série de entrevistas promovidas pelo Centro de Computação Científica e Software Livre (C3SL) e Dinf. A iniciativa busca destacar a trajetória e as contribuições de ex-bolsistas, alunos e pesquisadores que se destacam no campo da informática, mostrando a diversidade e o impacto das pesquisas desenvolvidas nesse ambiente acadêmico e tecnológico de excelência.

C3SL – Pedro, para começar, você poderia contar um pouco sobre sua trajetória pessoal e como chegou até o desenvolvimento do DuckDB?

PEDRO – Fiz minha graduação na Universidade Federal do Ceará. Desde o meu primeiro semestre fui bolsista de iniciação científica na área de indexação de banco de dados. Então, eu passei boa parte da minha graduação já trabalhando com sistemas de banco de dados, mas no nível de pesquisa, sem implementar nada em um sistema mesmo, mas com o que a gente chama de aplicação stand-alone. Você faz basicamente o código mais simples para testar aquela sua hipótese. Quando terminei minha graduação, tive oportunidade de ou continuar trabalhando na empresa que eu estava, ou de seguir para um mestrado. E a realidade é que eu tinha meio que me apaixonado pelo sul. Eu queria ir ou para Curitiba ou para Florianópolis, dar aquele empurrão, para sair da casa dos pais, etc. Então, eu apliquei a prova para Curitiba, Florianópolis, e acho que para Porto Alegre também. E do pessoal que eu conversei, que eu me dei melhor naquela conversinha de uma hora, foi com o professor Eduardo Almeida, da UFPR. Ele também trabalhava com o que na época era meio que os grandes hypes do momento, né, que era NoSQL e Spark. Forçamento MapReduce.

Pedro Thiago e demais pesquisadores do Dinf alunos do professor Eduardo Almeida em evento científico de informática

Neste processo, fui aprovado no mestrado como orientando dele, então eu fui para Curitiba, e a gente começou trabalhando com Banco de Dados NoSQL. Ali pelo meio do mestrado a gente viu que não era uma coisa tão bacana assim, que existiam uma série de problemas dentro da utilização de Banco de Dados NoSQL que não tornava isso interessante, e foi neste ponto que mudamos completamente o tópico para voltar à indexação. Só que a partir de um tipo de indexação chamada de Database Cracking, que é uma técnica de criação de índices em que você cria os índices enquanto está executando consultas. E daí eu fiz meu mestrado nesse tópico e calhou que era um tópico que tinha sido começado pelo Grupo de Pesquisa de Amsterdã que é a CWI (Centrum Wiskunde & Informatica), que é o Centro Viscundia Informática Centro de Matemática e Informática. Quando eu terminei meu mestrado, consegui a aprovação de um paper numa conferência internacional, e foi a partir desta oportunidade que aproveitei para me inscrever em uma vaga de doutorado aqui em Amsterdã. Foi justamente por conta de ter tido esse paper do mestrado e de ter tido alguma visibilidade já e ter feito o mestrado no em um tema central na pesquisa da instituição aqui que consegui a vaga no doutorado. Nisso, vim para cá e dei continuidade na minha pesquisa sobre índice. Em 2019 o Mark Raasveldt, que por sinal era o meu colega de quarto no doutorado, começou a implementar o DUNKDB como um projeto acadêmico.

Os projetos que a gente tem na CWI é um pouco diferente de como ocorre no Brasil. Enquanto o financiamento da pesquisa no Brasil é quase na sua totalidade originária de entes públicos, aqui na Europa é usual termos a grande maioria vindo de financiamentos de iniciativa privada ou público-privados. No meu caso, o projeto era com a fabricante de automóveis Honda. Eles pagavam metade do meu doutorado e o governo holandês pagava outra metade. No caso do Mark, a empresa financiadora era a Tata Steel, empresa global do setor siderúrgico, também neste mesmo modelo de custeio com o governo. Com este modelo, éramos levados a atuar em alguns dos problemas que essas empresas tinham. Além disso, tanto o meu projeto como o do Mark eram projetos que eram mais de ciência de dados, apesar de estarmos vinculado a um grupo com foco de estudo em sistema de banco de dados e desenvolvimento de sistema. Neste momento começamos a perceber que o pessoal tinha meio que aversão a sistemas de banco de dados, o que gerou essa curiosidade nossa. Oras, estamos no campo da informática há 50 anos desenvolvendo pesquisas, tentando fazer as coisas mais rápidas e além da memória, usar todo o processamento do computador. Porém, poucos se interessam por tais soluções, e acabam usando ferramentas que são consideravas inferiores nesse sentido de performance técnico. Neste ponto, começamos a perceber que a grande motivação era que os sistemas de banco de dados eram muito complexos.

Então, se você pegava uma pessoa para fazer uma análise de dados, eles preferiam ir para um “Pandas da vida”, que é uma ferramenta mais simples. Isso porque em uma linha de comando você já está conseguindo analisar seus dados. Agora, se você fosse usar um SQL Server, um ADB, era preciso instalar o seu servidor, descobrir como é que faz a conexão do cliente, fazer criação de esquema etc. Você perde um dia para começar a ler o seu primeiro arquivo. O teu custo de interação com a ferramenta era muito grande com sistemas. É desta reflexão que gerado o DuckDB. Será que a gente consegue fazer um sistema para análise de dados que seja tão fácil de usar quanto o Pandas, mas que tenha toda essa bagagem de coisas que a gente tem feito em pesquisa? Nos últimos anos, esse é o problema que o DuckDB surge para poder resolver no universo do banco de dados.

C3SL: O slogan “SQLite for analytics” resume bem a proposta do DuckDB. Como essa analogia ajuda a compreender o projeto? E quais foram os momentos-chave que levaram à criação ou sua entrada no time do DuckDB?

PEDRO: O slogan “SQLite for Data Analytics” que encampamos e a razão desse slogan é porque a gente queria ser na verdade o mesmo que o Pandas era, mas a gente também queria que as pessoas do mundo de banco de dados entendessem a proposta, e o SQLite era o mais próximo, sendo um sistema que não demanda instalação. Contudo, o SQLite é feito para o que a gente chama de cargas transacionais, que é quando você tem muitas atualizações. Seria algo como “o Pedro mudou de endereço”, o que é considerado uma atualização, e nisso o SQLite é muito bom em fazer. Mas se você tiver um tipo de consulta, como “quero saber o que é que as pessoas entre 20 e 30 anos que moram em Curitiba compram mais”, isso é uma carga analítica que demanda uma quantidade muito grande de seus dados. Então, são sistemas com propósitos diferentes. Mas a ideia é que nossa proposta à época era ser o que o SQLite é para essas atualizações, só que para essas cargas analíticas. Em 2019 começou o desenvolvimento do DuckDB.

Apenas para destacar um “fun fact”, na época o Mark estava no Brasil, especificamente em Curitiba. Então o início do DuckDB foi desenvolvido, por coincidência, na UFPR. Claro, não tendo uma relação direta com algum projeto da universidade. O Mark estava em Curitiba, e daí eu conversei com o professor Eduardo para ver se a gente conseguia uma sala para ficar usando naquela época. Isso já era no doutorado, em 2019. Por coincidência, o comecinho aconteceu fisicamente na UFPR. Foi neste ano que comecei a implementação do sistema, com uma carga bem acadêmica, sem também grandes deslumbres ou ainda um sistema de uso real. As coisas começam a mudar um pouco ali por 2021 e 2022. É neste momento temos um insight, e começamos a perceber que existe um interesse comercial na ferramenta. Já existiam empresas que estavam utilizando a ferramenta. E em 2021 é quando criamos a DuckDB Labs, que é a empresa que presta serviço em cima do DuckDB. É ela que opera em serviço o DuckDB, que é uma ferramenta de código aberto completamente gratuita. Na verdade, não tem nada que a gente faz dentro da DuckDB Labs que não seja aberto e gratuito.

Defesa de mestrado no PPGInf da UFPR

Para se ter uma ideia, a propriedade intelectual da ferramenta não é nem da DuckDB Labs, mas sim de uma fundação. Com isso, se algo ocorre com a empresa amanhã, a propriedade intelectual e o código continuam protegido. E uma pergunta muito comum é como mantemos a empresa se a ferramenta é aberta. O modelo de negócio é baseado em desenvolver projetos com a ferramenta aberta. A gente pode ter um projeto com outra empresa grande, como a Google. Eles utilizavam a DuckDB internamente dentro de um ou outro projeto deles, e precisavam que uma determinada carga de trabalho de junção bem específica fosse implementada para poder acelerar o processo deles. Neste caso, fechamos um contrato com a DuckDB Labs, um dos engenheiros vai e trabalha com eles pelo período que seja necessário para implementar. O business é esse desde o começo. A ferramenta foi toda desenvolvida com recurso público, e a ideia foi dar o retorno aos contribuintes deixando-a aberta, para que todos possam usar. O modelo de negócio envolve em aplicá-la em projetos.

C3SL: Hoje, como é a estrutura dos clientes e seus desafios em nível de complexidade de demandas?

PEDRO: Os projetos são bem diferentes, e a complexidade depende muito da necessidade dos clientes. Desta forma, é muito variada a complexidade. Temos alguns projetos que pedem para fazer melhorias no Iceberg, em outros, há pedidos para aprimoramentos dos da base dos clientes. O DuckDB é uma ferramenta que pode comunicar por diversas linguagens, como C++, Java, Go. Cada um desses é um cliente diferente, e cada um desses é desenvolvido à parte. Por exemplo, o nosso cliente que eu diria que é o mais forte é o Python. Por outro lado, tem uma outra empresa que está mais interessada no cliente Go que a gente tinha desenvolvido há um tempo, mas que só estava com a base. Agora estão pagando pelo desenvolvimento completo.  A complexidade de você desenvolver um cliente e de desenvolver uma integração com o Iceberg são diferentes. No fim das contas, o projeto é mais sobre o tempo gasto daquilo, do que realmente complexidade.

C3SL: A DuckDB fez uma implementação de suporte ao Delta Lake. O que motivou essa decisão e o que ela representa para os usuários e para o cenário do código aberto?

PEDRO: Se você é um usuário da Oracle, tem os seus arquivos salvos na Oracle. Caso queira migrar para um outro sistema, é uma grande dificuldade. No fim, você fica preso. Ou você aceita pagar o que eles quiserem te cobrar, ou você vai ter um custo caro para fazer uma migração. Além disso, migrações são complexas, pois há a necessidade de garantir que seus dados estão corretos no processo. A ideia do Delta Lake é que, em vez de ter um armazenamento de um sistema proprietário, você faria tudo com arquivos que são públicos. No caso, você usaria arquivos parquet que qualquer sistema pode ler ou escrever, e você usaria os outros arquivos JSON e AVRO, que também são arquivos formados públicos, que qualquer sistema pode teoricamente implementar um leitor e uma escrita, porque o formato é aberto. Então, a ideia do Data Lake era basicamente isso.

Em vez de um armazenamento privado, usar esses arquivos de armazenamento público para armazenar os dados. Se o fulano que tem os dados dele usou o Oracle para escrever os dados dele usando o Iceberg, que é basicamente uma coleção de parquet, JSON e AVRO, quiser usar um outro sistema para ler, não tem migração nenhuma. Se os dois sistemas sabem ler, o custo de migração é zero, porque os dados estão em um arquivo aberto, de formato aberto. Por qual motivo a gente decidiu criar um sistema? Basicamente você tinha três formatos: o Hoodie, o Iceberg e o Delta Lake que é do Databricks. São muito similares, sendo uma coleção de arquivos parquet, com uma linha de arquivos JSON, com outra linha de arquivos json e com um arquivo AVRO. Em cada alteração ou leitura, você tem que ir por todos esses arquivos, até chegar aonde os seus dados estão armazenados nesse parquet, e após isso trazer os dados de novo para o cliente. Quando você tem a atualização, é preciso criar novos arquivos. Isso vai aumentando essa estrutura, o que faz com que ela se consolide como uma estrutura muito complexa. A grande razão a que foi criada essa estrutura é porque eles não queriam ter um sistema de banco de dados nesse meio, para não depender de um sistema de certo modo, queriam só arquivos. Porém, eventualmente acabaram adicionando um sistema de banco de dados, o Postgres, para conseguir armazenar qualquer arquivo do topo que era a versão correta. Assim, acabaram adicionando um sistema de banco de dados de qualquer jeito. O que a nós da DuckDB fizemos foi revisitar essa solução. Nós já temos um sistema de banco de dados, um sistema aberto, e a dúvida que surgiu foi: “será que conseguimos eliminar todo esse monte de arquivo no meio, manter os parquets para armazenar os dados, usar um sistema de banco de dados que seja gratuito e aberto e que a maioria das pessoas tem? Será que a gente não consegue se limitar só a SQL 92 e garantir que vários sistemas possam ser utilizados, e a pessoa não fica presa ao Postgres? Daí veio a ideia do Delta Lake, que foi meio que o grande lançamento de dois meses atrás.

A abordagem era exatamente poder usar um sistema de banco de dados. Existe toda a especificação das consultas que são utilizadas. A única obrigatoriedade é que o sistema que está sendo usado tem que garantir transação ACID (atomicidade, consistência, isolamento e durabilidade), e garantir que suas transações são seguras. Mas você pode usar qualquer sistema. Como essa do Duck Lake, ela é uma especificação, mas a gente também tem uma implementação para o DuckDB, e na nossa implementação você pode usar como esse catálogo tanto o Postgres, como o MySQL, ou o SQLite, ou ainda o próprio DuckDB. A ideia é mostrar que você não está preso a nada, e que você pode usar qualquer sistema, eliminando essa grande quantidade de arquivos. Com isso você tem um ganho de performance muito alto. O resultado é que chegamos a ver ganho de performance em atualização de duas ordens de magnitude. Ou seja, se um procedimento demorasse um segundo para uma transação, ele passaria demorar 0.01. É uma diferença gritante de performance. Considero que é uma mudança de jogo comparado às outras ferramentas. A maior dificuldade, como qualquer standard que você cria, é a adoção. O Iceberg, por exemplo, já está bem definido, com vários sistemas que usam ele. O Snowflake o usa, o próprio Databricks, o Trino. O desafio é fazer esses usuários mudarem para um formato novo, criar uma cultura. E temos conquistado boa aceitação. Isso também pela vantagem que tem o sistema em reduzir o custo de pessoal para implementar. Um suporte para o Iceberg ou um Oracle, por exemplo, não é fácil de implementar. É preciso ter um time de engenheiros. No Duck Lake, você só precisa falar SQL. Ou seja, a curva de aprendizagem e de aplicação é extremamente mais curta do que qualquer outro.

Para ter uma ideia, estamos implementando a integração com o Iceberg, e temos um time hoje de quatro pessoas que está trabalhando há um ano neste projeto. A nossa implementação do Duck Lake demorou três meses, com uma pessoa. Fica evidente que a dificuldade de implementar um e outro é gritante. Eu diria que a diferença de tempo é de uma ordem de magnitude. Isso torna o Duck Lake muito atraente, ainda mais para sistemas menores, por conta do custo. O sistema já está maduro o suficiente para poder começar a implementação, porém, logo que alcançarmos a versão 1.0, e tivermos um desses grandes sistemas implementando, isso passa a dar uma garantia de que há um padrão que está sendo mais aceito. Temos uma confiança muito alta no nosso sistema, e temos um número de download ou número de estrela no GitHub com um pico gigantesco. O DuckDB hoje tem entre 20 a 30 milhões de downloads por mês. Cada download seria, basicamente, uma utilidade, de pequeno a grande porte. Se você imaginar a Tesla, o Google, o Facebook, eu sei que já usaram o sistema, assim como a Airbnb.

C3SL – Nesta trajetória toda, qual o papel do DINF, do PPGInf e das instituições de ensino públicas brasileiras?

PEDRO: Cada passo e cada etapa da minha formação foi importante e contribuiu para este processo. E certamente o mestrado no PPGInf com o professor Eduardo foi essencial. Ele me ajudou muito. Como orientador, ele me impulsionou bastante. Ele até brinca, ele chama de programar em baixaria, que é fazer programação em linguagem de baixo nível. A minha experiência antes da minha graduação tinha sido mais alto nível, o nível de programação. Então o professor Eduardo me puxou para coisas que eram mais atraentes para sistemas. Ele me puxou mais para fazer implementação que não é dentro do sistema, porque fazer isso no Brasil ainda é muito complexo. E a razão pela qual é complexo é que se você vem para um grupo aqui, se você vem fazer hoje um mestrado ou doutorado na CWI, ao seu redor estão os rapazes que implementam no sistema.

Defesa da tese de Pedro Thiago, na Centrum Wiskunde & Informatica

Por mais que o sistema esteja aberto, a tua barreira de entrada é muito baixa. E no Brasil a gente não tem essa proximidade. Mas o professor Eduardo me puxou para fazer isso, fazer a minha própria aplicação de qualquer. Ele me ajudou muito com a escrita, com a apresentação dos projetos. A pesquisa que a gente fez, que foi basicamente uma atualização de uma estrutura de dados que já existia para um tipo de problema. A gente teve um ganho de performance bom com a ideia.  E o importante foi a metodologia aplicada. Seguimos todo o processo de você ter uma hipótese, de implementar, validar, escrever o artigo e gerar as figuras. Também foi muito importante ter conseguido uma publicação internacional com o professor, que foi o que abriu a porta para eu vir para cá, em Amsterdã. Da mesma forma foi importante ter uma publicação da conferência regional a partir da graduação. Cada etapa é o que chamamos de stepping stones. Cada coisa vai te elevando um pouco além, e vai te abrindo novas oportunidades. Sem dúvida alguma, eu não estaria aqui se não fosse pela formação no Brasil, tanto na graduação como no mestrado. Todas as oportunidades são, sem dúvidas, dadas por conta da universidade.

C3SL – Que conselhos você daria hoje para estudantes brasileiros que gostariam de colaborar com o DuckDB ou projetos open source de alta complexidade?

PEDRO: Todo projeto de alta complexidade também tem problemas de baixa complexidade. O DuckDB, se você pegar a parte central dele, a parte realmente do sistema de banco de dados, é muito complexo. Se você for mexer no otimizador, fazer um novo algoritmo de junção, isso não são coisas fáceis. O DuckDB tem vários clientes. Assim, uma sugestão é contribuir para o sistema já atuando junto a um dos clientes. É uma barreira menor para você começar a entrar dentro do sistema. Agora, olhando para o Pedro do passado, se pudesse, o conselho que daria é investir muito no aprendizado do inglês. Afinal de contas, para ser apto a contribuir para esses projetos, a comunicação vai ser toda em inglês. Isso é um fato, isso não vai mudar. É preciso ser capaz de se expressar, de exprimir ideias e debater elas. Ainda mais quando você tem esse tipo de discussão online e assíncrona, como muitas vezes ocorre. Você tem que estar mais apto a conseguir realmente escrever e relatar suas ideias.

O aprendizado disso começa a ser evidente na graduação e pós, quando é necessário usar esta capacidade comunicativa nos papers. Um segundo conselho é que encontre projeto que você gosta, que te interessa, que seja gratuito, que seja open source e contribua para ele. Porque, em geral, vários projetos têm até uma própria tag de Good First Issue. Além de investir no aprendizado, há também, neste caso, uma demonstração de interesse nos projetos que pode ajudar lá na frente. Só para se ter uma ideia, nesse exato momento, estou fazendo seleção para os estagiários desse ano. Se tem alguém que já contribuiu para o DuckDB, com o que quer que seja, mesmo uma coisa pequena, já está a um passo além de quem não contribuiu. Isso pelo fato de que esta pessoa já demonstrou previamente que consegue atuar, que tem algum certo tipo de entrega de sistema, que consegue compilar, consegue executar, consegue rodar teste e modificar o código. Isso modifica muito as possibilidades. No caso do DuckDB, quem quiser contribuir, pode também aproveitar as extensões que o ele permite usar. Você consegue criar algoritmos novos, operadores novos. Acho que quase tudo hoje no sistema é extensível, fazendo uma coisa completamente externa ao DuckDB. Então, a minha dica paraquem está fazendo pesquisa em sistemas de banco de dados, especificamente, é se você estiver fazendo mestrado, na graduação também, ou doutorado, é tentar implementar uma extensão do DuckDB para aquilo que você está pesquisando.