O que é um conjunto de dados? Uma explicação para principiantes

A nossa perspetiva, que é modesta: somos a Geonode e vendemos proxies a pessoas que recolhem dados da Web, pelo que vemos muitos conjuntos de dados no momento em que são criados. A observação que vale a pena partilhar é que os erros mais graves ocorrem na fase de recolha e só são descobertos meses mais tarde. Não anotar quando os dados foram recolhidos, não registar quais os campos que poderiam estar em falta, não guardar as respostas em bruto — nada disto parece prejudicial no primeiro dia, mas tudo isto torna um conjunto de dados inutilizável quando alguém faz uma pergunta que não se tinha previsto. Nada neste artigo exige a compra de nada; os bons hábitos são gratuitos e a maioria deles demora apenas alguns minutos.

A Estrutura Básica

A maioria dos conjuntos de dados tem a mesma forma, independentemente do formato.

Registos — os itens individuais. Linhas numa tabela, objetos num array JSON, ficheiros num diretório. Um registo corresponde a uma coisa que se está a descrever: uma pessoa, uma transação, um produto, uma fotografia.

Campos — os atributos de cada registo. Colunas numa tabela, chaves num objeto. Nome, preço, data, categoria.

Valores — o que um determinado campo contém para um determinado registo.

Esquema — a descrição de quais os campos que existem, que tipos de dados contêm e quais são obrigatórios. Por vezes formal e imposta, por vezes um entendimento informal e, ocasionalmente, nada de todo — o que é o caso que causa problemas mais tarde.

Metadados — dados sobre o próprio conjunto de dados. Quando foi recolhido, por quem, de onde, sob que licença, com que limitações conhecidas.

Este último é o que os principiantes ignoram e os profissionais experientes insistem em considerar. Um conjunto de dados sem metadados é um conjunto de números sem qualquer forma de avaliar se respondem à sua pergunta.

Estruturados, semiestruturados e não estruturados

Uma distinção tripla útil, porque determina o que é possível fazer sem pré-processamento.

Os dados estruturados têm um esquema fixo e tipos consistentes. Uma tabela de base de dados, um ficheiro CSV com um cabeçalho estável, uma folha de cálculo. É possível consultá-los, filtrá-los e agregá-los diretamente.

Os dados semiestructurados têm uma organização, mas não um esquema rígido. JSON, em que os registos podem ter campos diferentes, XML, linhas de registo. Existe uma estrutura a analisar, e esta varia entre registos.

Os dados não estruturados não têm uma estrutura de registo inerente. Documentos de texto, imagens, áudio, vídeo. Não é que não haja informação; é que extrair campos desses dados requer um modelo ou a intervenção humana.

Na prática, as fronteiras tornam-se difusas. Um diretório de imagens com um ficheiro CSV que lista nomes de ficheiros, dimensões e etiquetas é conteúdo não estruturado com um índice estruturado — o que constitui a disposição padrão para conjuntos de dados de aprendizagem automática e, em geral, um bom padrão.

A maior parte do trabalho real envolve a conversão entre estes dois tipos. O scraping transforma páginas web não estruturadas em registos estruturados; é nessa conversão que surgem a maioria dos erros, e é por isso que é importante manter a fonte bruta.

Formatos e o que lhe custam

A escolha é mais importante do que parece.

Três pontos que determinam a maioria dos casos.

O CSV não tem uma especificação formal. A RFC 4180 refere-o explicitamente, descrevendo o que «parece ser seguido pela maioria das implementações». Essa é a origem dos problemas com delimitadores, codificação e aspas com que todos já se depararam. É também compacto e universalmente legível, razão pela qual persiste.

O JSON Lines é subutilizado e, normalmente, adequado para a recolha de dados. Um documento JSON por linha: é processado em memória constante, permite acréscimos com segurança e um ficheiro truncado continua a fornecer todos os registos completos. Uma matriz JSON não faz nada disso, e uma tarefa de recolha que falhe deixa um ficheiro impossível de analisar.

O Parquet é o destino certo para qualquer coisa de grande dimensão e de natureza analítica. O armazenamento colunar significa que uma consulta que abranja três de quarenta colunas lê apenas essas três; a compressão é muito melhor do que a do texto, porque valores semelhantes ficam agrupados; e os tipos são preservados com exatidão. Não é legível por humanos, o que constitui a contrapartida.

Um pipeline sensato recolhe os dados em JSON Lines, porque tolera interrupções, e depois converte-os para Parquet em lotes para análise. Comparámos os formatos de texto em pormenor em JSON vs CSV.

O que torna um conjunto de dados utilizável: FAIR

A comunidade científica formalizou este conceito, e este quadro aplica-se muito para além da investigação.

Os princípios FAIR, publicados em 2016, estabelecem quatro propriedades.

Localizável. O F1 exige que «aos (meta)dados seja atribuído um identificador globalmente único e persistente»; o F2, que «os dados sejam descritos com metadados ricos»; o F3, que os metadados «incluam de forma clara e explícita o identificador dos dados que descrevem»; e o F4, que sejam «registados ou indexados num recurso pesquisável».

Acessível. A1 exige a recuperação «através do seu identificador, utilizando um protocolo de comunicação normalizado». A2 é a que as pessoas consideram surpreendente e é, sem dúvida, a mais valiosa: «Os metadados são acessíveis, mesmo quando os dados já não estão disponíveis.» A descrição de um conjunto de dados deve sobreviver ao próprio conjunto de dados, para que quem ler um artigo anos mais tarde possa saber o que foi utilizado.

Interoperável. I1 exige «uma linguagem formal, acessível, partilhada e amplamente aplicável para a representação do conhecimento»; I2 exige vocabulários que, por si só, sigam os princípios FAIR; I3 exige «referências qualificadas a outros (meta)dados».

Reutilizável. R1 exige que os dados sejam «descritos de forma detalhada com uma pluralidade de atributos precisos e relevantes».

Traduzido na prática para um projeto comum: atribua ao seu conjunto de dados um identificador estável, registe o que este contém e de onde provém, utilize nomes de campos e unidades padrão sempre que existam, indique a licença e mantenha a documentação mesmo que elimine os dados.

Documentação de um conjunto de dados

Os princípios FAIR afirmam que a documentação é importante. O documento «Datasheets for Datasets» indica o que deve ser escrito.

Essa proposta de 2018 inspira-se na indústria eletrónica, onde cada componente é fornecido com uma ficha técnica. Defende que cada conjunto de dados deve ser acompanhado por documentação que abranja «a sua motivação, composição, processo de recolha, utilizações recomendadas, etc.», a fim de «facilitar uma melhor comunicação entre os criadores e os utilizadores dos conjuntos de dados e incentivar a comunidade de aprendizagem automática a dar prioridade à transparência e à responsabilização».

A lista de verificação prática que daí decorre:

Por que razão isto existe? Que pergunta se pretendia responder ao recolher estes dados. Isto determina se responde à sua pergunta.

O que contém? Registos, campos, tipos, unidades e o que se considera em falta.

Como foi recolhido? Método, datas, fontes, amostragem. Um conjunto de dados extraído de um site numa semana é um objeto diferente de um agregado ao longo de um ano.

O que não é? Lacunas conhecidas, enviesamentos, populações excluídas, períodos em falta. A secção mais valiosa e a que mais frequentemente está ausente.

Como deve ser utilizado e como não deve? Aplicações pretendidas e aplicações conhecidas como inadequadas.

Qual é a licença? E quem contactar.

Como é mantido? Se será atualizado e como as versões são identificadas.

Escrever isto demora uma hora quando o conjunto de dados está recente e torna-se quase impossível dezoito meses depois, quando a pessoa que o recolheu já se foi embora.

Avaliação da qualidade

Seis dimensões, e cada uma tem uma verificação que pode efetivamente realizar.

Exaustividade. Quanto falta e essa falta é aleatória? Conte os valores nulos por campo. Um campo que está 40% vazio está a dizer-lhe algo — ou uma falha na recolha de dados ou uma verdadeira opcionalidade que deve documentar.

Precisão. Os valores refletem a realidade? É difícil de verificar em geral, mas viável em casos específicos: compare manualmente uma amostra aleatória com a fonte. Vinte registos demoram quinze minutos e permitem detetar a maioria dos erros sistemáticos.

Consistência. As mesmas coisas aparecem da mesma forma? Datas em formatos mistos, países apresentados tanto como UK como United Kingdom, preços com e sem símbolos monetários. Conte os valores distintos por campo categórico — um campo com trezentos «países» distintos tem um problema de normalização.

Atualidade. Quando foi recolhido e isso é relevante para a sua questão? Os preços do último trimestre são história, e não dados.

Representatividade. A amostra corresponde à população que lhe interessa? Um conjunto de dados de avaliações é um conjunto de dados de pessoas que escrevem avaliações.

Proveniência. Consegue rastrear cada registo até à sua fonte? É isto que lhe permite recalcular, auditar e corrigir — e é por isso que vale a pena guardar as respostas em bruto juntamente com os registos analisados, mesmo que ocupem espaço de armazenamento.

Faça estas verificações antes da análise, não depois. Descobrir um problema de normalização num gráfico é consideravelmente mais dispendioso do que descobri-lo numa contagem de valores.

Divisão de dados para aprendizagem automática

Se o conjunto de dados se destinar ao treino de um modelo, a divisão é tão importante quanto os próprios dados.

Conjunto de treino — aquilo com que o modelo aprende. Normalmente, a maior parte. Conjunto de validação — utilizado para ajustar e escolher entre modelos. Conjunto de teste — mantido totalmente à parte, utilizado uma única vez para estimar o desempenho no mundo real.

Existem três formas comuns de isto correr mal.

Fuga de informação. A informação do conjunto de teste influencia o treino. A escala ou a imputação utilizando estatísticas calculadas sobre todo o conjunto de dados antes da divisão é a versão clássica e inflaciona os resultados de forma silenciosa.

Registos duplicados entre divisões. Itens quase idênticos tanto no conjunto de treino como no de teste significam que o modelo já viu a resposta. Os dados recolhidos na Web são particularmente propensos a isto, uma vez que o mesmo conteúdo aparece em vários URLs.

Fuga temporal. Para dados ordenados cronologicamente, uma divisão aleatória permite que o modelo aprenda com o futuro. Em vez disso, divida por data.

O princípio geral: o conjunto de teste deve assemelhar-se à situação com que irá realmente deparar-se. Se pretender prever o amanhã a partir de hoje, divida por tempo. Se for receber novos utilizadores, divida por utilizador.

Licenciamento: a parte que determina o que pode fazer

Um conjunto de dados que não pode utilizar legalmente não é um conjunto de dados que possui. O licenciamento é verificado com muito menos frequência do que deveria, normalmente porque é aborrecido até ao ponto de se tornar a única coisa que importa.

Licenças de dados abertos. A Creative Commons é a família mais comum. A CC0 coloca as obras no domínio público na medida em que a lei o permite e não impõe quaisquer condições. A CC BY exige atribuição. A CC BY-SA acrescenta uma condição de partilha em termos idênticos, o que significa que as obras derivadas têm de ter a mesma licença — o que pode ser incompatível com um produto comercial. A CC BY-NC proíbe a utilização comercial, e o termo «não comercial» é definido de forma suficientemente vaga para constituir um risco real caso a sua utilização seja ambígua. Os portais governamentais utilizam frequentemente licenças abertas personalizadas que, na prática, são permissivas; leia-as uma vez em vez de partir de suposições.

Os direitos sobre bases de dados são distintos dos direitos de autor. Na UE e no Reino Unido, um direito sui generis protege o investimento substancial na obtenção, verificação ou apresentação do conteúdo de uma base de dados — independentemente de cada registo individual ser ou não passível de direitos de autor. Um conjunto de dados composto apenas por factos pode ainda assim ser protegido como uma base de dados, o que é precisamente a situação em que se encontram os projetos de agregação.

Os termos de serviço são contratuais. Um conjunto de dados recolhido de um site cujos termos proíbem o acesso automatizado acarreta esse problema, independentemente do conteúdo dos registos individuais. Trata-se de uma questão diferente dos direitos de autor e aplica-se mesmo quando os próprios factos não estão protegidos.

Os dados pessoais têm o seu próprio regime. Se os registos identificarem pessoas — diretamente ou em combinação —, a legislação em matéria de proteção de dados aplica-se à sua posse e tratamento dos mesmos, e não apenas à sua recolha. Isso significa uma base legal, limites de retenção e direitos que os titulares dos dados podem exercer contra si. «Estava visível ao público» não constitui, por si só, uma base legal.

E os conjuntos de dados derivados herdam restrições. Treinar um modelo com base num conjunto de dados de partilha igualitária, ou agregar várias fontes com licenças diferentes, gera obrigações que correspondem à união das condições de cada fonte, e não à mais permissiva.

A prática habitual consiste em registar a licença na documentação do conjunto de dados no momento da recolha, juntamente com um link para os termos tal como se encontravam nesse dia. As licenças mudam, as páginas de termos são reescritas e poder demonstrar o que aceitou quando efetuou a recolha vale mais do que apenas lembrar-se disso.

De onde vêm os conjuntos de dados

Cinco fontes, por ordem decrescente do trabalho que cada uma exige.

Conjuntos de dados abertos publicados. Portais governamentais, repositórios de investigação, arquivos institucionais. Gratuitos, documentados e, frequentemente, suficientemente bons. Verifique primeiro — a quantidade de dados já disponíveis publicamente é considerável.

APIs. Estruturadas, homologadas, estáveis. Se uma fonte publicar uma, é quase sempre a opção certa.

Fornecedores de dados comerciais. Licenciados, com suporte e com preços adequados. Frequentemente mais baratos do que construir o mesmo, uma vez contabilizado o tempo de engenharia.

Os seus próprios sistemas. Registos, transações, telemetria. Normalmente, são os dados mais valiosos à disposição de uma organização e os mais negligenciados.

Recolha na Web. O que comercializamos. Adequada quando os dados são visíveis publicamente e não existe nenhuma via autorizada — e acarreta obrigações: «robots.txt», termos de serviço, direitos de autor, direitos sobre bases de dados e, quando estão envolvidos dados pessoais, a legislação em matéria de proteção de dados. É também a fonte que mais requer documentação, porque um conjunto de dados extraídos sem um registo de quando e de onde provêm é muito difícil de defender ou reproduzir.

Perguntas frequentes

O que é um conjunto de dados, em termos simples?

Uma coleção de dados relacionados, organizada de forma a poder ser trabalhada como uma unidade — normalmente registos (os itens) com campos (os seus atributos), além de uma descrição do significado desses campos. Uma folha de cálculo, uma tabela de base de dados e uma pasta de imagens rotuladas são, todas, conjuntos de dados.

Qual é a diferença entre dados e um conjunto de dados?

Os dados são a matéria-prima; um conjunto de dados é uma coleção delimitada e organizada desses dados, reunida com um objetivo específico. A organização e os limites são o que o tornam utilizável — é possível contar os registos de um conjunto de dados, descrever os seus campos e indicar a sua origem.

O que são dados estruturados e não estruturados?

Os dados estruturados têm um esquema fixo e tipos consistentes, como uma tabela de base de dados. Os dados não estruturados não têm uma estrutura de registo inerente — texto, imagens, áudio. Os dados semiestruturados situam-se no meio, com organização mas forma variável, como JSON ou ficheiros de registo.

Que formato devo utilizar para um conjunto de dados?

CSV para tabelas planas a serem importadas para folhas de cálculo ou para um carregador de bases de dados. JSON Lines para tudo o que for recolhido de forma incremental, porque permite o fluxo de dados e resiste ao truncamento. Parquet para grandes volumes de dados analíticos, porque o armazenamento colunar e a tipagem tornam as consultas muito mais eficientes.

O que torna um conjunto de dados de boa qualidade?

Integralidade, precisão, consistência interna, atualidade, representatividade da população que lhe interessa e proveniência rastreável. Cada um destes aspetos tem uma verificação concreta — contagem de valores nulos, uma amostra verificada manualmente, contagem de valores distintos por campo categórico.

Como devo documentar um conjunto de dados?

Registe por que razão existe, o que contém, como e quando foi recolhido, quais são as suas lacunas e enviesamentos conhecidos, como deve e não deve ser utilizado, a sua licença e como é mantido. A proposta «Datasheets for Datasets» é a referência padrão para este efeito.

O que são os princípios FAIR?

Localizável, Acessível, Interoperável, Reutilizável — um quadro de referência para a gestão de dados publicado em 2016. O requisito mais subestimado é que os metadados devem permanecer acessíveis «mesmo quando os dados já não estiverem disponíveis», de modo a que a descrição sobreviva ao próprio conjunto de dados.

Como divido um conjunto de dados para aprendizagem automática?

Em conjuntos de treino, validação e teste (reservado), sendo que o conjunto de teste é utilizado apenas uma vez. Calcule quaisquer transformações apenas a partir do conjunto de treino, remova quase-duplicados entre as divisões e divida por ordem cronológica, em vez de aleatoriamente, no caso de dados ordenados temporalmente — estas três práticas são fontes comuns de resultados inflacionados de forma imperceptível.

Conclusão

Um conjunto de dados é composto por registos, campos e valores, além da descrição que lhes dá significado. A descrição é a parte que determina se alguém poderá utilizá-lo daqui a seis meses, incluindo o próprio utilizador.

Os formatos importam menos do que os hábitos. CSV quando for adequado, JSON Lines para tudo o que estiver a recolher de forma incremental, porque resiste a uma interrupção da tarefa, e Parquet quando os dados forem volumosos e as consultas forem analíticas. Qualquer uma destas opções funciona; o erro é escolher um array JSON para uma recolha de longa duração e deparar-se com um ficheiro impossível de analisar após uma falha do sistema.

O que compensa mais o esforço é a documentação, redigida enquanto o conjunto de dados ainda está fresco. Por que razão existe, como e quando foi recolhido, o que falta e para que não deve ser utilizado. Os princípios FAIR definem-no formalmente, a proposta «Datasheets for Datasets» fornece-lhe uma lista de verificação, e ambos apontam na mesma direção: os metadados devem sobreviver aos dados.

E verifique a qualidade antes de analisar. Contagens de valores nulos por campo, valores distintos por campo categórico e vinte registos verificados manualmente em relação à fonte permitirão detetar a maioria dos problemas sistemáticos em menos de uma hora — o que é muito mais económico do que detetá-los numa conclusão.