Python kullanarak tekrarlanabilir veri bilimi için araçlar ve protokol


50

Python kullanarak bir veri bilimi projesi üzerinde çalışıyorum. Projenin birkaç aşaması var. Her aşama, Python scriptleri, yardımcı veriler, konfigürasyon ve parametreler kullanılarak bir veri seti almak ve başka bir veri seti oluşturmaktan oluşur. Kodu git içinde sakladım, böylece o kısım kapsanacak. Şunu duymak isterim:

  1. Veri sürüm kontrolü için araçlar.
  2. Aşamaları ve deneyleri çoğaltmayı sağlayan araçlar.
  3. Protokol ve böyle bir proje için önerilen dizin yapısı.
  4. Otomatik oluşturma / çalıştırma araçları.

2
Bu sorudaki soru nerede ? Lütfen Yardım Merkezi kurallarını incelemek için bir dakikanızı ayırın , özellikle: "Soru sorma motivasyonunuz '______ hakkında bir tartışmaya katılmak istiyorum' ise, o zaman burada sormamanız gerekir."
Air

“Sadece karşılaştığınız gerçek sorunlara dayanarak pratik, yanıtlanabilir sorular sormalısınız.”
Yuval F

Bu pratiktir, yanıtlanabilir ve "Veri bilimini nasıl gerçekleştireceğimi söyleyin" ile aynı şekilde gerçek bir soruna dayanır, pratiktir, cevaplanabilir ve gerçek bir soruna dayanır.
Air

Yanıtlar:


46

Konu tekrarlanabilir araştırma (RR) 'dir çok popüler bugün ve dolayısıyla olduğunu büyük ama cevabım olacağını umuyoruz yeterince kapsamlı bir cevap olarak ve yeterli bilgi sağlayacaktır fazla araştırma Bunu yapmaya karar vermelidir.

RR için Python'a özgü araçlar kesinlikle orada olmasına rağmen, daha evrensel araçlara odaklanmanın daha mantıklı olacağını düşünüyorum (gelecekte hangi programlama dilleri ve hesaplama ortamları ile çalışacağınızı asla bilemezsiniz). Bunu söyledikten sonra, listenizde hangi araçların uygun olduğuna bir göz atalım.

1) Veri sürüm kontrolü için araçlar . (Çok) büyük verilerle çalışmayı planlamazsanız git, kaynak kodu sürüm kontrolü için kullandığınızın aynısını kullanmak mantıklı olacaktır . Altyapı zaten orada. Dosyalarınız ikili ve büyük olsalar bile, bu tavsiye faydalı olabilir: https://stackoverflow.com/questions/540535/managing-large-binary-files-with-git .

2) RR iş akışlarını ve deneylerini yönetmek için araçlar . İşte bu kategorideki en popüler araçların listesi, bildiğim kadarıyla (azalan popülerlik sırasına göre):

  • Taverna İş Akışı Yönetim Sistemi ( http://www.taverna.org.uk ) - Çok katı, eğer biraz karmaşıksa, araçlar kümesi. Ana araç, Java tabanlı bir masaüstü yazılımıdır. Ancak, kullanıcının RR iş akışlarını depolayıp paylaşabileceği çevrimiçi iş akışı veri havuzu portalı myExperiment ( http://www.myexperiment.org ) ile uyumludur . Taverna ile tamamen uyumlu olan Web tabanlı RR portalı Taverna Online olarak adlandırılıyor , ancak Rusya'da tamamen farklı bir organizasyon tarafından geliştiriliyor ve korunuyor (burada ÇevrimiçiHPC olarak adlandırılıyor : http://onlinehpc.com ).

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

  • VisTrails ( http://vistrails.org )

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

Örnek . İşte Kepler ve myExperiment projelerinin kullanımına dayanan gerçek iş akışı tasarımı ve veri analizi örneği ile bilimsel iş akışları üzerine ilginç bir makale : http://f1000research.com/articles/3-110/v1 .

Yazılım ailesi tarafından örneklenen okuryazar programlama paradigmasını uygulayan birçok RR aracı vardır LaTeX. Rapor oluşturma ve sunumda yardımcı olan araçlar, aynı zamanda muhtemelen en iyi bilinenleri Sweaveve büyük bir kategorisidir knitr. SweaveR'ye odaklanmış bir araçtır, ancak ek bir çaba göstermesine rağmen Python tabanlı projelerle bütünleştirilebilir ( https://stackoverflow.com/questions/2161152/sweave-for-python ). Bunun knitrmodern olduğu için popüler araçlarla (örneğin RStudio) geniş bir desteğe sahip olduğunu ve dil açısından tarafsız olduğunu daha iyi bir seçenek olabileceğini düşünüyorum ( http://yihui.name/knitr/demo/engines ).

3) Protokol ve önerilen dizin yapısı . Protokol ( iş akışı ) terimini kullanarak ne demek istediğinizi doğru anladıysam , genellikle standart RR veri analizi iş akışının aşağıdaki sıralı aşamalardan oluştuğunu düşünüyorum: veri toplama => veri hazırlama (temizleme, dönüştürme, birleştirme, örnekleme) => veri analizi => sonuçların sunumu (raporların ve / veya sunumların oluşturulması). Bununla birlikte, her iş akışı projeye özgüdür ve bu nedenle bazı belirli görevler ek adımlar eklemeyi gerektirebilir.

Örnek dizin yapısı için, veri analizi iş akışlarını ve projelerini otomatikleştirme girişimi olarak R paketi ProjectTemplate( http://projecttemplate.net ) belgelerine bakabilirsiniz :

görüntü tanımını buraya girin

4) Otomatik oluşturma / çalıştırma araçları . Cevabım evrensel (dil-nötr) RR araçlarına odaklandığından en popüler araçlardır make. makeTercih edilen RR iş akışı otomasyon aracı olarak kullanmanızın bazı nedenlerinden dolayı aşağıdaki makaleyi okuyun : http://bost.ocks.org/mike/make . Elbette, bazı yönlerini geliştiren veya bazı ek özellikler ekleyen benzer araçlar da vardır make. Örneğin: ant(resmen, Apache Ant: http://ant.apache.org ), Maven("yeni nesil ant": http://maven.apache.org ), rake( https://github.com/ruby/rake ) , Makepp( http://makepp.sourceforge.net). Bu tür araçların kapsamlı bir listesi için Wikipedia'ya bakınız: http://en.wikipedia.org/wiki/List_of_build_automation_software .


Burada okuryazar programlama hakkında bir link : temel olarak, kodun bağımsız bir dokümantasyon haline gelmesi için kodun yeterince yorumlanması ile ilgilidir.
gaborous

@gaborous: Okuryazar programlamanın anlamının farkındayım ve paradigmaya herhangi bir bağlantı eklemedim, çünkü bunun için pek çok kaynak var ve bulmak çok kolay. Bununla birlikte, yorumunuz için teşekkür ederiz.
Aleksandr Blekh

1
Tahmin etmiştim, bu yüzden ilgilenen okuyucuya yorum olarak bu bilgiyi ekledim :)
gaborous

4
Bu çok kapsamlı bir cevap, ancak bir yönünün eksik göründüğüne şaşırdım. Çapraz doğrulama çoğu DS projesinin hayati bir bileşenidir ve tipik olarak tekrarlanabilirliği zorlaştırabilen rastgele bir örnek gerektirir. İstatistiki değişkenlikten bağımsız olarak sonuçları tekrar üretebilmek için rastgele üreteçler için aynı tohumun kullanılmasına kısaca değinmenizi öneririm. Teşekkürler!
AN6U5

@ AN6U5: Nazik sözleriniz için teşekkürler! Katılıyorum - Bu yönü kaçırdım (+1). Lütfen çapraz doğrulama hakkında kısa bilgi ekleyerek cevabımı güncellemek için çekinmeyin.
Aleksandr Blekh

23

Akademi'de araştırma yapmaya başladığımdan beri sürekli tatmin edici bir iş akışı arıyordum. Sonunda mutlu olduğum bir şey bulduğumu düşünüyorum:

1) Her şeyi sürüm kontrolü altına alın, örneğin Git:

Hobi araştırma projeleri için GitHub'u kullanıyorum, işteki araştırmalar için üniversitemiz tarafından sağlanan özel GitLab sunucusunu kullanıyorum. Ayrıca veri kümelerimi orada tutuyorum.

2) Analizlerimin çoğunu, IPython dizüstü bilgisayarlarındaki belgelerle birlikte yapıyorum. Kodun, çizimlerin ve tartışmaların / sonuçların hepsinin tek bir belgede olması (benim için) çok organize oldu. Daha büyük komut dosyaları çalıştırıyorsam, genellikle onları ayrı komut dosyası .py dosyalarına koyardım, ancak yine de yürütürdüm IPython not defterinden% run sihir ile amaç, sonuç ve diğer parametreler hakkında bilgi eklemek için.

IPython ve IPython notebooklar için "filigran" adı verilen ve zaman damgaları oluşturmak ve kullandığım farklı paket versiyonlarını ve Git hash'lerini takip etmek için kullandığım küçük bir hücre büyüsü uzantısı yazdım.

Örneğin


%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

Daha fazla bilgi için buradaki belgelere bakın .


2
Filigran büyüsünü seviyorum. Farkında olmayanlar için GitHub şimdi akademik kurumlarla ilişkili kullanıcılar için 5'e kadar ücretsiz özel depo sunmaktadır.
bogatron

19

En iyi yeniden üretilebilirlik aracı, eylemlerinizin bir günlüğünü, bunun gibi bir şey yapmaktır:

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

Bu, bir kağıda yazılabilir, ancak denemeleriniz hesaplama çerçevesine uyuyorsa, hesaplama araçlarını bu kayıt sürecini kısmen veya tamamen otomatikleştirmek için kullanabilirsiniz (özellikle çok büyük olan girdi veri setlerini ve çıktıyı izlemenize yardımcı olarak) rakamlar).

Düşük öğrenme eğrisine sahip Python için harika bir tekrarlanabilirlik aracı elbette IPython / Jupyter Notebook'tur ( % logon ve% logstart magics'i unutmayın ). İpucu: dizüstü bilgisayarınızın çoğaltılabilir olduğundan emin olmak için çekirdeği yeniden başlatın ve tüm hücreleri yukarıdan aşağıya doğru çalıştırmayı deneyin (düğme Tüm Hücreleri Çalıştır): çalışıyorsa, daha sonra her şeyi bir arşiv dosyasına ("dondurma") kaydedin; Hataları önlemek için hücreleri doğrusal olmayan ve sıralı olmayan ve belirgin olmayan bir şekilde çalıştırmanız gerekirse , biraz yeniden çalışmanız gerekir.

Çok yakın zamanda ortaya çıkan bir başka harika araç (2015), özellikle Sumatra'ya benzeyen (aşağıya bakınız) bir tarif, ancak Python için özel olarak yapılmış. Jupyter Notebook'larla çalışıp çalışmadığını bilmiyorum, ancak yazarın bunları sık kullandığını biliyorum, bu nedenle şu anda desteklenmiyorsa gelecekte de olacağını tahmin ediyorum.

Git de harika ve Python'a bağlı değil. Yalnızca tüm deneylerinizin, kodunuzun, veri kümelerinin, rakamların vb. Geçmişini tutmamanıza yardımcı olmakla kalmayacak, aynı zamanda bir bilimsel kullanarak ( git kazma ), işbirliği yapma ( suçlama ) ve hata ayıklama ( git - bisect ) uygulamalarını da sağlayacak. hata ayıklama yöntemi ( delta hata ayıklama olarak adlandırılır ). İşte kendi deneylerini yapmaya çalışan kurgusal bir araştırmacının hikayesini , Git'in bir faktörü haline gelene kadar kayıt sistemi.

Herhangi bir dilde ( pypi'de bir Python API'siyle ) çalışan diğer bir genel araç da, özellikle kopyalanabilir araştırmalar yapmanıza yardımcı olmak için tasarlanmış ( yinelenebilir aynı kod ve yazılımları verilen aynı sonuçları elde etmeyi amaçlarken , çoğaltılabilirlik de üretmeyi amaçlar) tasarlanan Sumatra'dır . Çok zor ve zaman alıcı olan ve otomatikleştirilemeyen, herhangi bir ortama verilen aynı sonuçlar).

Sumatra nasıl işliyor: Sumatra üzerinden yaptığınız her deney için, bu yazılım video oyunlarında sıkça bulunan bir "oyun durumunu kaydet" gibi davranacaktır. Daha doğrusu, kurtaracak:

  • verdiğiniz tüm parametreler;
  • tüm deneysel uygulamanızın ve config dosyalarınızın tam kaynak kod durumu;
  • çıktı / grafikler / sonuçlar ve ayrıca deneysel uygulamanız tarafından üretilen herhangi bir dosyayı.

Daha sonra, deneylerinizin her biri için zaman damgasına ve diğer meta verilere sahip bir veritabanı oluşturacaktır, daha sonra webGUI'yi kullanarak tarama yapabilirsiniz. Sumatra, başvurunuzun tam durumunu belirli bir zamanda belirli bir noktada belirli bir deneme için kaydettiğinden, istediğiniz anda belirli bir sonuç üreten kodu geri yükleyebilirsiniz, böylece düşük maliyetle tekrarlanabilir bir araştırma yapabilirsiniz (depolama için büyük veri kümeleri üzerinde çalışıyorsunuz, ancak her zaman her şeyi kaydetmek istemiyorsanız istisnaları yapılandırabilirsiniz).

Bir başka harika araç, GNOME’un Zeitgeist’idir (daha önce Python’da kodlanmış ancak şimdi Vala’ya taşınmış), her şeyi pekiştiren bir eylem günlüğü sistemi olan ve yaptığınız her şeyi kaydeden ve makine temelli öğrenmeyi kullanarak, öğeleri temel alan arasındaki ilişkiyi istediğiniz bir süre boyunca özetlemek için kullanabilirsiniz. benzerlik ve kullanım şekilleri üzerine, örneğin "Geçen yıl bir ay boyunca X projesi üzerinde çalışırken benimle en alakalı olan ne oldu?" . İlginçtir, Evernote'a benzer bir not alma uygulaması olan Zim Desktop Wiki'nin Zeitgeist ile çalışacak bir eklentisi vardır.

Sonunda Git veya Sumatra ya da istediğiniz herhangi bir yazılımı kullanabilirsiniz, bunlar size yaklaşık olarak aynı kopyalanabilirlik gücü sağlarlar, ancak Sumatra, araştırmak için bir web GUI gibi birkaç fantezi araç sağlar. sonuçlarınız Git, kod bakımına göre daha uyarlanmış olsa da (ancak git-bisect gibi hata ayıklama araçları vardır, bu nedenle deneyleriniz kod içeriyorsa, aslında daha iyi olabilir). Ya da elbette ikisini de kullanabilirsiniz!

/ EDIT: dsign burada çok önemli bir noktaya değindi: kurulumunuzun tekrarlanabilirliği uygulamanızın tekrar edilebilirliği kadar önemlidir. Başka bir deyişle, en azından tam sürümleri ve platformunuzun detayları ile birlikte kullandığınız kitaplıkların ve derleyicilerin tam bir listesini vermelisiniz .

Şahsen, Python ile yapılan bilimsel hesaplamada, bir uygulamayı kitaplıklar ile birlikte paketlemenin çok acı verici olduğunu buldum, bu yüzden şimdi sadece Anaconda gibi bir all-in-one bilimsel python paketi kullanıyorum (büyük paket yöneticisi conda ile ), ve sadece kullanıcılara aynı paketi kullanmalarını tavsiye edin. Başka bir çözüm, otomatik olarak bir sanalenv oluşturmak için bir komut dosyası sağlamak veya dsign veya açık kaynak kodlu Vagrant tarafından belirtilen ticari Docker uygulamasını kullanarak her şeyi paketlemek olabilir (örneğin , kolayca yeniden dağıtılabilen bir ürün üretmek için Vagrant kullanan bir kutu içi p22 ile). sanal ortam paketi).

Son olarak, ihtiyaç duyduğunuz her zaman tam olarak çalışan bir ortama sahip olduğunuzdan emin olmak için, sanal bir makine (VirtualBox'a bakın) yapabilir ve hatta makinenizin durumunu (anlık görüntü) denemeniz için çalışmaya hazır bir şekilde kaydedebilirsiniz. Daha sonra bu sanal makineyi dahil olan her şeyle paylaşabilirsiniz, böylece denemenizi tam kurulumunuzla yineleyebilirsiniz. Yazılım tabanlı bir deneyi kopyalamanın en iyi yolu muhtemelen budur. Konteynırlar daha hafif bir alternatif olabilir, ancak bütün ortamı içermezler, böylece çoğaltma doğruluğu daha az sağlam olacaktır.

/ EDIT2: İşte size özetleyebileceğiniz harika bir video (hata ayıklamak için ama bu araştırma için de geçerli olabilir) tekrarlanabilir araştırma yapmak için neyin temel olduğunu: deneylerinizi ve bilimsel yöntemin diğer adımlarını bir tür "açık deney" olarak günlüğe kaydetme .


14

Liman işçisi kontrol ettiğinizden emin olun ! Genel olarak, yazılım mühendisliğinin on yıl boyunca yarattığı diğer tüm iyi şeyler, izolasyon ve yeniden üretilebilirlik sağlamak için.

Sadece yeniden üretilebilir iş akışlarına sahip olmanın yeterli olmadığını, iş akışlarını çoğaltmanın da kolay olduğunu vurgulamak isterim . Ne demek istediğimi göstereyim. Projenizin bir veritabanı X ve Scipy olan Python kullandığını varsayalım. Tabii ki Python'dan veritabanınıza bağlanmak için belirli bir kütüphane kullanacaksınız ve Scipy de bazı seyrek cebirsel rutinleri kullanacak. Bu elbette, çok basit bir kurulum, ancak kurulum için tamamen basit değil, amaçlanan. Birisi komut dosyalarınızı çalıştırmak isterse, tüm bağımlılıkları kurması gerekir. Daha da kötüsü, zaten yüklü olan uyumsuz sürümlerine sahip olabilir. Bunları düzeltmek zaman alıyor. Hesaplamalarınızı bir kümeye, farklı bir kümeye veya bazı bulut sunucularına taşımanız gerekirse, zaman alacaktır.

İşte liman işçisi yararlı buluyorum. Docker, ikili ortamlar için tarifleri biçimlendirmenin ve derlemenin bir yoludur. Aşağıdakileri bir docker dosyasına yazabilirsiniz (Dockerfile sözdizimi yerine burada düz İngilizce kullanıyorum):

  • Ubuntu's gibi basit bir ikili ortamla başlayın
  • Libsparse-dev yükle
  • (Pip) Numpy ve scipy yükleyin
  • X'i yükle
  • LibX-dev'i kurun
  • (Pip) python-X'i yükleyin
  • IPython-Notebook'u yükleyin
  • Python komut dosyalarımı / not defterlerimi diğer ortamları yapmak için ikili ortamıma, bu veri dosyalarına ve bu yapılandırmalara kopyalayın. Yeniden üretilebilirliği sağlamak için, bunları yerel bir dosya yerine adlandırılmış bir URL'den kopyalayın.
  • Belki IPython-Notebook'u çalıştırın.

Satırlardan bazıları Python'da pip kullanarak bir şeyler kuracak, çünkü pip belirli paket sürümlerini seçerken çok temiz bir çalışma yapabilir. Bunu da kontrol et!

Ve bu kadar. Docker dosyasını oluşturduktan sonra, oluşturulabilir, o zaman herhangi bir yere, herhangi biri tarafından oluşturulabilir (ayrıca projeye özel dosyalarınıza erişmeleri koşuluyla, örneğin Dockerfile'dan başvurulan bir genel URL'ye yerleştirdiğiniz için). En iyisi, ortaya çıkan ortamı ("resim" olarak adlandırılır) başkalarının kullanması için genel veya özel bir sunucuya ("kayıt" olarak adlandırılır) yükleyebilirsiniz. Dolayısıyla, iş akışınızı yayınladığınızda, hem Dockerfile şeklinde tamamen yeniden üretilebilir bir tarifin hem de sizin veya diğer kişilerin yaptığınız şeyi çoğaltması için kolay bir yönteminiz olur:

docker run dockerregistery.thewheezylab.org/nowyouwillbelieveme

Veya senaryolarınızda dolaşmak istiyorlarsa:

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

8

Ne yazık ki, Plank'ın gönderisine cevap vermek için yeterli itibar puanım yok, bu yüzden tüm konuya cevap vermek zorundayım - bunun için üzgünüm.

Aslında yukarıda bahsettiğim açık kaynaklı Kolektif Bilgi Çerçevesinin geliştiricisiyim. Artefaktların ve deneysel iş akışlarının GitHub ile paylaşılan birleşik JSON API ve JSON metaleri ile yeniden kullanılabilir ve tekrar üretilebilir Python bileşenleri olarak paylaşılmasını kolaylaştırmaya çalışır. Ayrıca, aynı birleşik JSON API ile tahmine dayalı analitiklere bağlanabilirler.

Yeni V1.8.1 versiyonunu yeni piyasaya sürdük ve kapsamlı dökümantasyon sağladık, bu yüzden şimdi kavramları anlamak daha kolay olacaktır: http://github.com/ctuning/ck/wiki

Artık bu çerçeveye dayanan birçok akademik ve endüstriyel projemiz var, bu nedenle bunlardan birini kontrol edebilirsiniz - gönüllüler tarafından sağlanan mobil cihazlar arasında kitle kaynaklı program optimizasyonunu tekrarlanabilir bir şekilde kontrol edebilirsiniz: http://cknowledge.org/repo

Ayrıca burada tekrarlanabilir bilim ile ilgili çeşitli kaynakları takip ediyoruz: https://github.com/ctuning/ck/wiki/Enabling-open-science

Öncelikle bilgisayar sistemlerinin araştırmalarını tekrarlanabilir kılmaya odaklanmakla meşgul olmama rağmen, diğer alanlardan gelen meslektaşlarımla ilginç sohbetler yaptım ve çok benzer problemleri var gibi görünüyor. Öyleyse, çerçevemiz diğer topluluklara yardımcı olabilirse çok mutlu olacağım! Herhangi bir sorunuz veya öneriniz varsa, bizimle iletişime geçmekten çekinmeyin!


1
Bu yaz tekrarlanabilir araştırma özeti (ilgili araçlara, veri kümelerine, makalelere ve etkinliklere bağlantılar da dahil olmak üzere) de ilgi çekici olabilir: github.com/ctuning/ck/wiki/Enabling-open-science-blog-20160919
gfursin

7

Tekrarlanabilir araştırmaya adanmış bir kurs vardır. https://www.coursera.org/learn/reproducible-research Bu kurs R'ye dayanmaktadır, ancak altta yatan fikir öğrenilebilir.

Basit bir yol, bir Ipython dizüstü bilgisayarına sahip olmak ve yaptığınız her kirli işi kaydetmeye devam etmektir, verileri temizliyor, keşif analizleri yapıyor veya modeli oluşturuyor.


6

Son zamanlarda aşağıdaki araca rastladım - http://github.com/ctuning/ck . Python'da zaten yazılmış ve ihtiyacınız olanı içeriyor gibi görünüyor (meslektaşım görüntü tanıma özelliğini otomatikleştirmek için pilot projede kullanıyor).

Artıları:

  1. çok küçük, taşınabilir ve özelleştirilebilir
  2. deneyleri dağıtmak ve yordayıcı analitik kullanarak bunları işlemek için web sunucusu içerir
  3. kalabalık kaynak kullanımı ve derleyici optimizasyonunu çoğaltmak için harika bir kullanım örneğine sahiptir - http://cknowledge.org/repo

Eksileri:

  1. biraz düşük seviyede - JSON API veya komut satırını kullanarak GitHub ile paylaşılan Python bileşenlerinden kendi iş akışınızı uygulamanız gerekir
  2. Belgeler biraz karmaşık - umarım yakında güncellemek için zaman bulurlar.

6

Tam olarak ulaşmaya çalıştığınız şeyi yapan http://dvc.org veya DVC adlı bir açık kaynak aracı oluşturdum ve yayınladım :

  1. [Veri sürümü kontrolü için araçlar.] DVC Git'in üzerinde çalışır, veri dosyası sürüm kontrolü ekler (dosyalar Git'in dışında depolanır) ve kod ile veri dosyaları arasındaki bağımlılıkları izler. DVC, kod ve veriler için bağımlılık grafiğini (DAG) otomatik olarak türetir.
  2. [Aşamaları ve deneyleri çoğaltmayı sağlayan araçlar.] dvc repro data/scores.csv, DAG ile ilgili gerekli tüm adımları çoğaltır.
  3. [Böyle bir proje için protokol ve önerilen dizin yapısı.] DVC, datatüm veri dosyalarını kaydetmeniz gereken bir veri dizini ( varsayılan olarak) istedi . Ancak DVC, asıl içeriği .cachedizine şeffaf bir şekilde taşır ve sembolik bağlar oluşturur (evet, Windows'ta da çalışmasını sağladım). .cacheDizin Git senkronize edilmez ancak bulut üzerinden senkronize edilebilir (S3 veya GSO) komutuyla dvc sync data/scores.csv(Bu gibi önbellekten uymakta veri dosyasını eşitler .cache/scores.csv_29de545)
  4. [Otomatik oluşturma / çalıştırma araçları.] Yukarıdan bakın.

DVC eğitimi, iyi bir başlangıç ​​noktasıdır - "Veri Sürümü Kontrolü: yinelemeli makine öğrenmesi" .


5

YASAL UYARI: Bunu yapmak için açık kaynak kodlu bir araç yaratan bir şirket olan Datmo'da çalışıyorum .

Yeniden üretilebilirlik için en iyi yöntem şudur:

1) İlk önce bir Docker dosyası oluşturarak ve tüm bağımlılıkların bu dosyada kapsandığından emin olarak ortamınızı Docker ortamına kaplayın. Bu kaynağı en iyi buldum ( https://arxiv.org/pdf/1410.0846.pdf )

2) Tüm performans ölçümlerini ve yapılandırmalarını nerede takip edeceğinize karar vermek isteyeceğinize karar verdikten sonra (gelecekteki denemeler için tekrar ziyaret edebilmeniz için)

3) Son olarak, yeni bir deneyci / geliştirici kodunuzu tekrar ziyaret edebilecek, çevre ile çoğaltabilecek ve yapılandırmalarınızı ve performans ölçümlerinizi nerede tuttuğunuzu görebilecek şekilde bazı belgeler yazınız.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.