Ferramentas e protocolo para ciência de dados reproduzíveis usando Python

Estou trabalhando em um projeto de ciência de dados usando Python. O projeto tem várias etapas. Cada estágio consiste em pegar um conjunto de dados, usando scripts Python, dados auxiliares, configuração e parâmetros e criar outro conjunto de dados. Eu guardo o código no git, para que essa parte seja coberta. Eu gostaria de ouvir sobre:

1. Ferramentas para controle de versão de dados.
2. Ferramentas que permitem reproduzir etapas e experimentos.
3. Protocolo e estrutura de diretórios sugerida para esse projeto.
4. Ferramentas de criação / execução automatizadas.

O tópico da pesquisa reproduzível (RR) é muito popular hoje e, consequentemente, é enorme , mas espero que minha resposta seja abrangente o suficiente como resposta e forneça informações suficientes para pesquisas adicionais , caso você decida fazer isso.

Embora as ferramentas específicas para Python para RR certamente existam por aí, acho que faz mais sentido se concentrar em ferramentas mais universais (você nunca sabe ao certo com quais linguagens de programação e ambientes de computação você estará trabalhando no futuro). Dito isto, vamos dar uma olhada em quais ferramentas estão disponíveis para sua lista.

1) Ferramentas para controle de versão de dados . A menos que você planeje trabalhar com (muito) big data , acho, faria sentido usar o mesmo git, que você usa para o controle de versão do código-fonte. A infraestrutura já está lá. Mesmo que seus arquivos sejam binários e grandes, este conselho pode ser útil: https://stackoverflow.com/questions/540535/managing-large-binary-files-with-git .

2) Ferramentas para gerenciar fluxos de trabalho e experiências de RR . Aqui está uma lista das ferramentas mais populares nesta categoria, com o melhor de meu conhecimento (na ordem decrescente de popularidade):

• Sistema de Gerenciamento de Fluxo de Trabalho Taverna ( http://www.taverna.org.uk ) - conjunto de ferramentas muito sólido, se um pouco complexo demais. A principal ferramenta é um software de desktop baseado em Java. No entanto, é compatível com o portal do repositório de fluxo de trabalho online myExperiment ( http://www.myexperiment.org ), onde o usuário pode armazenar e compartilhar seus fluxos de trabalho RR. O portal RR baseado na Web, totalmente compatível com o Taverna, é chamado Taverna Online , mas está sendo desenvolvido e mantido por uma organização totalmente diferente na Rússia (conhecida como OnlineHPC : http://onlinehpc.com ).

• O Projeto Kepler ( https://kepler-project.org )

• VisTrails ( http://vistrails.org )

• Madagascar ( http://www.reproducibility.org )

EXEMPLO . Aqui está um artigo interessante sobre fluxos de trabalho científicos, com um exemplo do design real do fluxo de trabalho e da análise de dados, com base no uso de projetos Kepler e myExperiment : http://f1000research.com/articles/3-110/v1 .

Existem muitas ferramentas de RR que implementam o paradigma de programação alfabetizado , exemplificado pela LaTeXfamília de software. As ferramentas que ajudam na geração e apresentação de relatórios também são uma categoria grande, onde Sweavee knitrprovavelmente são as mais conhecidas. Sweaveé uma ferramenta focada em R, mas pode ser integrada a projetos baseados em Python, embora com algum esforço adicional ( https://stackoverflow.com/questions/2161152/sweave-for-python ). Eu acho que essa knitrpode ser uma opção melhor, pois é moderna, tem amplo suporte de ferramentas populares (como RStudio) e é neutra em termos de idioma ( http://yihui.name/knitr/demo/engines ).

3) Protocolo e estrutura de diretórios sugerida . Se entendi corretamente o que você sugeriu usando o termo protocolo ( fluxo de trabalho ), geralmente penso que o fluxo de trabalho padrão da análise de dados RR consiste nas seguintes fases seqüenciais: coleta de dados => preparação de dados (limpeza, transformação, fusão, amostragem) => análise de dados => apresentação de resultados (geração de relatórios e / ou apresentações). No entanto, todo fluxo de trabalho é específico do projeto e, portanto, algumas tarefas específicas podem exigir a adição de etapas adicionais.

Para uma estrutura de diretórios de amostra, você pode dar uma olhada na documentação do pacote R ProjectTemplate( http://projecttemplate.net ), como uma tentativa de automatizar os fluxos de trabalho e projetos de análise de dados:

4) Ferramentas de construção / execução automatizadas . Como minha resposta está focada em ferramentas RR (neutras em termos de idioma) universais, as ferramentas mais populares são make. Leia o artigo a seguir por alguns motivos para usar makecomo a ferramenta de automação de fluxo de trabalho RR preferida: http://bost.ocks.org/mike/make . Certamente, existem outras ferramentas semelhantes , que aprimoram alguns aspectos makeou adicionam alguns recursos adicionais. Por exemplo: ant(oficialmente, Apache Ant: http://ant.apache.org ), Maven("próxima geração ant": http://maven.apache.org ), rake( https://github.com/ruby/rake ) , Makepp( http://makepp.sourceforge.net) Para obter uma lista abrangente dessas ferramentas, consulte a Wikipedia: http://en.wikipedia.org/wiki/List_of_build_automation_software .

Desde que comecei a pesquisar na academia, procurava constantemente um fluxo de trabalho satisfatório. Acho que finalmente encontrei algo com o qual estou feliz:

1) Coloque tudo sob controle de versão, por exemplo, Git:

Para projetos de pesquisa de hobby, uso o GitHub, para pesquisas no trabalho, uso o servidor GitLab privado fornecido por nossa universidade. Eu também mantenho meus conjuntos de dados lá.

2) Faço a maioria das minhas análises, juntamente com a documentação dos notebooks IPython. É muito organizado (para mim) ter o código, as plotagens e a discussão / conclusão em um único documento. Se eu estiver executando scripts maiores, normalmente os colocaria em arquivos .py de script separados, mas ainda os executaria. do bloco de notas do IPython por meio da% run magic para adicionar informações sobre a finalidade, o resultado e outros parâmetros.

Eu escrevi uma pequena extensão cell-magic para notebooks IPython e IPython, chamada "marca d'água" que eu uso para criar convenientemente carimbos de data e hora e acompanhar as diferentes versões de pacotes que usei e também Git hashs

Por exemplo

%watermark

29/06/2014 01:19:10

CPython 3.4.1
IPython 2.1.0

compiler   : GCC 4.2.1 (Apple Inc. build 5577)
system     : Darwin
release    : 13.2.0
machine    : x86_64
processor  : i386
CPU cores  : 2
interpreter: 64bit

%watermark -d -t

29/06/2014 01:19:11 

%watermark -v -m -p numpy,scipy

CPython 3.4.1
IPython 2.1.0

numpy 1.8.1
scipy 0.14.0

compiler   : GCC 4.2.1 (Apple Inc. build 5577)
system     : Darwin
release    : 13.2.0
machine    : x86_64
processor  : i386
CPU cores  : 2
interpreter: 64bit

Para mais informações, consulte a documentação aqui .

A melhor ferramenta de reprodutibilidade é fazer um log de suas ações, algo como isto:

experiment/input ; expected ; observation/output ; current hypothesis and if supported or rejected
exp1 ; expected1 ; obs1 ; some fancy hypothesis, supported

Isso pode ser anotado em um documento, mas, se suas experiências se encaixarem em uma estrutura computacional, você pode usar ferramentas computacionais para automatizar parcial ou completamente esse processo de registro (principalmente ajudando a rastrear os conjuntos de dados de entrada que podem ser enormes e a saída figuras).

Uma ótima ferramenta de reprodutibilidade para Python com baixa curva de aprendizado é o IPython / Jupyter Notebook (não se esqueça das magias % logon e% logstart ). Dica: para garantir a reprodutibilidade do seu notebook, reinicie o kernel e tente executar todas as células de cima para baixo (botão Executar todas as células): se funcionar, salve tudo em um arquivo ("congelamento"); se você precisar executar células de maneira não linear, seqüencial e não óbvia para evitar erros, precisará refazer um pouco.

Outra ótima ferramenta muito recente (2015) é o recebimento , que é muito parecido com o sumatra (veja abaixo), mas feito especificamente para o Python. Não sei se ele funciona com os Jupyter Notebooks, mas sei que o autor os usa com frequência, então acho que, se não houver suporte no momento, será no futuro.

O Git também é incrível, e não está vinculado ao Python. Ele ajudará não apenas a manter um histórico de todos os seus experimentos, códigos, conjuntos de dados, figuras, etc., mas também fornecerá ferramentas para manter ( git pickaxe ), colaborar ( culpar ) e depurar ( git - bisect ) usando um método científico. método de depuração (chamado depuração delta ). Aqui está uma história de um pesquisador fictício tentando criar seu próprio sistema de registro de experimentos, até que ele acaba sendo um fac-símile do Git.

Outra ferramenta geral trabalhar com qualquer linguagem (com uma API Python em pypi ) é Sumatra , que é projetado especificamente para ajudar você a fazer replicável pesquisa ( replicáveis pretende produzir os mesmos resultados dado exatamente o mesmo código e softwares, enquanto reprodutibilidade objetivos para produzir o mesmos resultados em qualquer meio, o que é muito mais difícil, demorado e não automatizável).

Aqui está como o Sumatra funciona: para cada experimento que você realiza através do Sumatra, esse software age como um "estado de jogo salvo", freqüentemente encontrado em videogames. Mais precisamente, ele salvará:

• todos os parâmetros que você forneceu;
• o estado exato do código fonte de todo o seu aplicativo experimental e arquivos de configuração;
• a saída / plotagens / resultados e também qualquer arquivo produzido por sua aplicação experimental.

Ele criará um banco de dados com o carimbo de data e hora e outros metadados para cada uma das suas experiências, que você poderá rastrear posteriormente usando a webGUI. Como o Sumatra salvou o estado completo do seu aplicativo para um experimento específico em um ponto específico no tempo, você pode restaurar o código que produziu um resultado específico a qualquer momento que desejar, para ter uma pesquisa replicável a um custo baixo (exceto armazenamento, se você trabalha em grandes conjuntos de dados, mas pode configurar exceções se não quiser salvar tudo sempre).

Outra ferramenta incrível é o Zeitgeist do GNOME (anteriormente codificado em Python, mas agora portado para Vala), um sistema de diário de ação abrangente, que registra tudo o que você faz e pode usar o aprendizado de máquina para resumir por um período que você deseja que o relacionamento entre itens seja baseado. sobre padrões de similaridade e uso, por exemplo, respondendo a perguntas como "O que foi mais relevante para mim, enquanto eu trabalhava no projeto X, durante um mês no ano passado?" . Curiosamente, o Zim Desktop Wiki , um aplicativo de anotações semelhante ao Evernote, possui um plug-in para trabalhar com o Zeitgeist.

No final, você pode usar o Git, o Sumatra ou qualquer outro software que desejar, eles fornecerão aproximadamente o mesmo poder de replicabilidade, mas o Sumatra é especificamente adaptado para pesquisa científica, por isso fornece algumas ferramentas sofisticadas, como uma GUI da Web para rastrear seus resultados, enquanto o Git é mais adaptado à manutenção de código (mas possui ferramentas de depuração como o git-bisect, portanto, se seus experimentos envolverem códigos, pode ser melhor). Ou é claro que você pode usar os dois!

/ EDIT: dsign tocou em um ponto muito importante aqui: a replicabilidade da sua configuração é tão importante quanto a replicabilidade do seu aplicativo. Em outras palavras, você deve pelo menos fornecer uma lista completa das bibliotecas e compiladores que você usou, juntamente com suas versões exatas e os detalhes da sua plataforma .

Pessoalmente, na computação científica com Python, descobri que empacotar um aplicativo junto com as bibliotecas é muito doloroso, portanto, agora apenas uso um pacote python científico completo como o Anaconda (com o ótimo gerenciador de pacotes conda ), e apenas aconselhe os usuários a usar o mesmo pacote. Outra solução poderia ser fornecer um script para gerar automaticamente um virtualenv ou empacotar tudo usando o aplicativo comercial do Docker, conforme citado por dsign ou o Vagrant de código aberto (por exemplo, pylearn2-in-a-box que usa o Vagrant para produzir um redistribuível facilmente pacote de ambiente virtual).

Por fim, para realmente garantir que você tenha um ambiente totalmente funcional sempre que precisar, você pode criar uma máquina virtual (consulte VirtualBox) e até salvar o estado da máquina (instantâneo) com o seu experimento pronto para ser executado dentro. Depois, você pode compartilhar esta máquina virtual com tudo incluído, para que qualquer pessoa possa replicar sua experiência com sua configuração exata. Esta é provavelmente a melhor maneira de replicar um experimento baseado em software. Os contêineres podem ser uma alternativa mais leve, mas não incluem todo o ambiente, para que a fidelidade à replicação seja menos robusta.

/ EDIT2: Aqui está um ótimo vídeo resumindo (para depuração, mas isso também pode ser aplicado à pesquisa) o que é fundamental para fazer pesquisas reproduzíveis: registrando seus experimentos e os passos do método científico, uma espécie de "experimentação explícita" .

Não deixe de conferir o docker ! E, em geral, todas as outras coisas boas que a engenharia de software criou ao longo de décadas para garantir isolamento e reprodutibilidade.

Eu gostaria de enfatizar que não é suficiente ter apenas fluxos de trabalho reproduzíveis, mas também fácil de reproduzir fluxos de trabalho. Deixe-me mostrar o que quero dizer. Suponha que seu projeto use Python, um banco de dados X e Scipy. Certamente você estará usando uma biblioteca específica para se conectar ao seu banco de dados a partir do Python, e o Scipy, por sua vez, usará algumas rotinas algébricas esparsas. Esta é de todo modo uma configuração muito simples, mas não totalmente simples de configurar, com trocadilhos. Se alguém quiser executar seus scripts, ela precisará instalar todas as dependências. Ou pior, ela pode ter versões incompatíveis já instaladas. Consertar essas coisas leva tempo. Também levará tempo se você precisar, em algum momento, mover seus cálculos para um cluster, para um cluster diferente ou para alguns servidores em nuvem.

Aqui é onde eu acho o docker útil. O Docker é uma maneira de formalizar e compilar receitas para ambientes binários. Você pode escrever o seguinte em um arquivo docker (estou usando aqui o inglês simples em vez da sintaxe do Dockerfile):

• Comece com um ambiente binário básico, como o Ubuntu
• Instale libsparse-dev
• (Pip) Instale numpy e scipy
• Instalar X
• Instale o libX-dev
• (Pip) Instalar python-X
• Instale o IPython-Notebook
• Copie meus scripts / blocos de anotações python para meu ambiente binário, esses arquivos de dados e essas configurações para fazer outras coisas diversas. Para garantir a reprodutibilidade, copie-os de um URL nomeado em vez de um arquivo local.
• Talvez execute o IPython-Notebook.

Algumas das linhas instalarão coisas no Python usando o pip, pois o pip pode fazer um trabalho muito limpo ao selecionar versões de pacotes específicas. Confira também!

E é isso. Se, depois de criar o Dockerfile, ele puder ser construído, ele poderá ser criado em qualquer lugar, por qualquer pessoa (desde que eles também tenham acesso aos arquivos específicos do seu projeto, por exemplo, porque você os coloca em um URL público referenciado no Dockerfile). O que é melhor, você pode fazer upload do ambiente resultante (chamado de "imagem") para um servidor público ou privado (chamado de "registro") para que outras pessoas possam usar. Portanto, quando você publica seu fluxo de trabalho, possui uma receita totalmente reproduzível na forma de um arquivo Docker e uma maneira fácil de você ou outras pessoas reproduzirem o que você faz:

docker run dockerregistery.thewheezylab.org/nowyouwillbelieveme

Ou se eles querem bisbilhotar seus scripts e assim por diante:

docker run -i -t dockerregistery.thewheezylab.org/nowyouwillbelieveme /bin/bash

Infelizmente, eu não tenho pontos de reputação suficientes para responder à postagem do Plank, então tenho que responder a todo o tópico - desculpe por isso.

Na verdade, sou o desenvolvedor do Collective Knowledge Framework de código aberto mencionado acima. Ele tenta simplificar o compartilhamento de artefatos e fluxos de trabalho experimentais como componentes Python reutilizáveis ​​e reproduzíveis com a API JSON unificada e a meta JSON compartilhada via GitHub. Eles também podem ser conectados à análise preditiva com a mesma API JSON unificada.

Acabamos de lançar a nova versão V1.8.1 e fornecemos documentação extensa. Espero que agora seja mais fácil entender os conceitos: http://github.com/ctuning/ck/wiki

Agora, temos muitos projetos acadêmicos e industriais baseados nessa estrutura, portanto, você pode verificar um deles - a otimização do programa de crowdsourcing em dispositivos móveis, fornecida por voluntários de maneira reproduzível: http://cknowledge.org/repo

Também acompanhamos vários recursos relacionados à ciência reproduzível aqui: https://github.com/ctuning/ck/wiki/Enabled-open-science

Embora eu me concentre principalmente em tornar a pesquisa de sistemas de computador reproduzível, tive conversas interessantes com colegas de outros domínios e parece que eles têm problemas muito semelhantes. Então, ficarei muito feliz se nossa estrutura puder ajudar em outras comunidades! Se você tiver alguma dúvida ou sugestão, não hesite em entrar em contato!

Há todo um curso dedicado à pesquisa reproduzível. https://www.coursera.org/learn/reproducible-research Este curso é baseado em R, mas a ideia subjacente pode ser aprendida.

Uma maneira simples é ter um notebook Ipython e salvar cada trabalho sujo que você faz, seja na limpeza dos dados, na análise exploratória ou na construção do modelo.

Recentemente, deparei com a seguinte ferramenta - http://github.com/ctuning/ck . Ele já está escrito em Python e parece incluir o que você precisa (meu colega o está usando no projeto piloto para automatizar o reconhecimento de imagens).

Prós:

1. muito pequeno, portátil e personalizável
2. inclui servidor web para distribuir experimentos e processá-los usando análises preditivas
3. tem um exemplo legal de uso para crowdsource e reproduzir a otimização do compilador - http://cknowledge.org/repo

Contras:

1. um pouco baixo - você precisa implementar seu próprio fluxo de trabalho a partir de componentes Python compartilhados via GitHub usando API JSON ou linha de comando
2. a documentação é um pouco complexa - eu realmente espero que eles encontrem tempo para atualizá-la em breve.

Criei e liberei recentemente uma ferramenta de código aberto http://dvc.org ou DVC que faz exatamente o que você está tentando alcançar:

1. [Ferramentas para controle de versão de dados.] O DVC funciona sobre o Git, adiciona controle de versão de arquivo de dados (os arquivos são armazenados fora do Git) e rastreia as dependências entre o código e os arquivos de dados. O DVC deriva automaticamente o gráfico de dependência (DAG) para código e dados.
2. [Ferramentas que permitem reproduzir estágios e experimentos.] dvc repro data/scores.csvReproduz todas as etapas necessárias em relação ao DAG.
3. [Protocolo e estrutura de diretórios sugerida para esse projeto.] O DVC exigia um diretório de dados ( datapor padrão) onde você deveria armazenar todos os arquivos de dados. No entanto, o DVC move de maneira transparente o conteúdo real para o .cachediretório e cria os links simbólicos (sim, eu o fiz funcionar também no Windows). O .cachediretório não está sincronizado com o Git, mas pode ser sincronizado através da nuvem (S3 ou GCP) por comando dvc sync data/scores.csv(sincroniza o arquivo de dados correspondente do cache, como .cache/scores.csv_29de545)
4. [Ferramentas de criação / execução automatizadas.] Veja acima.

O tutorial do DVC é um bom ponto de partida - "Controle de versão de dados: aprendizado de máquina iterativo" .

AVISO LEGAL: Eu trabalho em uma empresa, a Datmo , que cria uma ferramenta de código aberto para fazer isso.

A melhor prática para reprodutibilidade é a seguinte:

1) Primeiro conteinerize seu ambiente em um ambiente Docker criando um arquivo Docker e assegurando que todas as dependências sejam cobertas nesse arquivo. Eu achei esse recurso o melhor ( https://arxiv.org/pdf/1410.0846.pdf )

2) Quando tiver, decida onde poderá acompanhar todas as métricas e configurações de desempenho (para que você possa revisitá-lo para experiências futuras)

3) Por fim, escreva alguma documentação para que um novo experimentador / desenvolvedor possa revisitar seu código, replicá-lo com o ambiente e ver onde você manteve suas configurações e métricas de desempenho.