Soru:
Analiz sırasında kod ve veriler nasıl versiyonlanır?
Iakov Davydov
2017-05-18 14:27:51 UTC
view on stackexchange narkive permalink

Şu anda araştırmamda hem kodu hem de verileri versiyonlamama izin verecek bir sistem arıyorum.

Verileri analiz etme yöntemimin nadir olmadığını düşünüyorum ve bu, birçok kişi biyoinformatik yapıyor ve tekrarlanabilirliği hedefliyor.

İşte gereksinimler:

  • Analiz birden çok makinede (yerel, küme, sunucu) gerçekleştirilir.
  • Tüm kod, makineler arasında şeffaf bir şekilde senkronize edilir.
  • Kaynak kodu versiyonlama.
  • Oluşturulan veri versiyonlama.
  • Çok sayıda küçük oluşturulmuş dosya desteği (> 10k). Bunlar da silinebilir.
  • Büyük dosyalar (> 1 Gb) için destek. Bir noktada eski oluşturulan dosyalar kalıcı olarak silinebilir. Bunların şeffaf senkronizasyonuna sahip olmak delice olurdu, ancak bunları talep üzerine senkronize edebilmek güzel olurdu.

Şimdiye kadar git kullanıyorum + rsync / scp. Ancak bunun birkaç dezavantajı var.

  • Birden fazla makine arasında senkronizasyon biraz sıkıcı, yani çalışmaya başlamadan önce çekmeli ve her güncellemeden sonra git itmeli. Bununla yaşayabilirim.
  • Büyük oluşturulmuş veri dosyalarını veya çok sayıda dosyayı deponuzda saklamamanız gerekir.
  • Bu nedenle veri dosyalarını rsync kullanarak manuel olarak senkronize etmem gerekiyor, bu, hataya açıktır.

git annex diye bir şey var. İhtiyacım olana gerçekten yakın görünüyor. Ama:

  • Git'ten biraz daha fazla iş ama sorun değil.
  • Maalesef çok sayıda dosyada iyi çalışmıyor gibi görünüyor. Genellikle analizimde 10.000'den fazla küçük dosyam var. Dizine eklemeyi iyileştirmenin bazı püf noktaları var, ancak sorunu çözmüyor. İhtiyacım olan şey, dizinin tüm içeriğini temsil eden bir sembolik bağlantıdır.

Olası çözümlerden biri, Dropbox veya benzer bir şeyi ( senkronizasyon gibi) git ile birlikte kullanmaktır. Ancak dezavantajı, kaynak kod sürümü ile veri sürümü arasında bağlantı olmayacak olmasıdır.

Kod ve önerebileceğiniz gereksinimleri karşılayan veriler için herhangi bir sürüm belirleme sistemi var mı?

Tam olarak aradığınız şey değil ve tam zamanlı olarak kullanacağım bir konumda da değil, ancak 'chitin' adlı bir yazılım parçası yazıyorum: https://github.com/SamStudio8/chitin /. Dosyaların nasıl oluşturulduğunu ve onlara ne olduğunu izlemek için tasarlanmıştır. Değişiklikleri depolamak için tasarlanmadı (git gibi) - ama aslında meta verileri gerçek değişikliklerden çok daha yararlı buluyorum (elbette git'te yaşayan kod dışında).
@SamStudio8 ilginç görünüyor. Henüz tam olarak ikna olmadım, ancak IMHO bir cevap olarak göndermeye değer.
Bunun için normal yaklaşım, çeşitli makinelere (yerel, küme, sunucu) verilen tek bir dizine sahip olmaktır. Verileri yalnızca merkezi bir depo kullanmak yerine neden bu şekilde çoğaltasınız?
@terdon genellikle bir kümede kök erişiminiz yoktur, bu nedenle orada bir ağ dosya sistemini bağlayamazsınız (ve performans nedeniyle çok sayıda küçük dosya veya büyük dosya varsa) istemezsiniz. Diğer bir anlamda, bu, kaynak kod ile veriler arasında uygun versiyonlama ve uygunluktan yoksun olan bir senkronizasyon / dropbox çözümüne benzer.
Eh, GB veriyi senkronize etmeniz gerekiyorsa, yanlış yapıyorsunuz demektir. Kök erişimine ihtiyacınız varsa, sistem yöneticinizden sistemi ortak sürücülere sahip olmanıza izin verecek şekilde ayarlamasını isterim. Hiç kimsenin tarif ettiğiniz şekilde çalıştığını görmedim, çalıştığım üç yerde de her zaman paylaşılan ağ sürücüleri vardı. Alternatif olarak, root erişimine ihtiyaç duymadan bunları kendiniz bağlamak için sshfs'yi kullanabilirsiniz. Ağ G / Ç yükü gerçekten bir faktör olsa da, bazen verileri yerel bir sürücüye kopyalar ve analizden sonra sileriz.
@terdon çoklu küçük dosyalar da ağ dosya sistemlerinin çoğu için bir sorundur. Gigabaytlarca veriyi senkronize etmenin her zaman iyi bir fikir olmadığını, ancak bazen kaçınılmaz kötü olduğunu kabul ediyorum (not, git annex bunu otomatik olarak yapmaz; ve bu iyi). Üniversitemde benzer sorunlara sahip pek çok biyoinformatik grup görüyorum, bu yüzden en azından nadir değil. "sshfs" bir seçenektir, ancak yine bir ağ dosya sistemidir. Ve birçok kümede fuse çekirdekte mevcut değil (bildiğim en büyük biyoinformatik kümelerinden biri olan bizimki dahil).
@terdon, ile aynı fikirdeyim, çok sayıda büyük dosyayı birden çok düğümde eşitlemeniz için hiçbir neden yok. Ağa bağlı bir depolama sürücüsünü bağlamak için kök erişiminiz yoksa, onu edinmeniz gerekir. Tüm bu dosya senkronizasyonu ağı tıkayacak ve yöneticileriniz bundan kaçınmak isteyecek. Dosyaların birden fazla kopyasını saklamak bir felaket reçetesidir, bundan ne pahasına olursa olsun kaçınmalısınız.
@woemler yeterince açık değilmişim gibi görünüyor. Verilerin şeffaf senkronizasyonunu istemiyorum. Ben sadece bunun versiyonlanıp geri alınabilir olmasını istiyorum. Soruyu daha net hale getirmek için güncelledim. 100 bin küçük dosyayı ağ fs'de tutmak da felaket için bir reçetedir. Her neyse, büyük dosyalar sorunu git annex ile kolayca çözülebilir; küçük dosyalar daha karmaşıktır.
Yedi yanıtlar:
#1
+14
Michael Schubert
2017-05-18 21:57:58 UTC
view on stackexchange narkive permalink

Burada dikkate alınması gereken birkaç nokta var ve bunları aşağıda özetleyeceğim. Buradaki amaç, halihazırda git kullanmanın yanı sıra asgari düzeyde müdahaleci bir iş akışı bulmak olmalıdır.

Şu an için, tüm kullanım durumlarını kapsayan ideal bir iş akışı yoktur, ancak Aşağıda özetlediğim, ona ulaşabileceğim en yakın şey.

Yeniden üretilebilirlik sadece tüm verilerinizi saklamak değildir

Projenize başladığınız ham verileriniz var.

Proje dizininizdeki diğer tüm veriler asla "orada" olmamalı, ancak nereden geldiklerine dair bir kayıt bulundurmalıdır. Veri işleme komut dosyaları bunun için harikadır çünkü ham verilerinizden analitik verilerinize nasıl geçtiğinizi ve ardından analizleriniz için gereken dosyaları zaten belgelerler.

Ve bu komut dosyaları uygun tek bir işleme noktasıyla sürümlendirilebilir (örn. komut dosyalarınızı nasıl çalıştıracağınızı açıklayan bir Makefile ).

Bu şekilde, tüm proje dosyalarınızın durumu tanımlanır ham verilere ve işleme komut dosyalarınızın sürümüne (ve harici yazılım sürümlerine göre, ancak bu tamamen farklı bir sorundur).

Hangi verilerin / kodun sürümlendirilmesi gerekir ve değiştirilmemelidir

Oluşturulan kod dosyalarını sürümlemeyeceğiniz gibi, analizlerinizi gerçekleştirirken ürettiğiniz 10k ara veri dosyalarını da sürüm istememelisiniz. Sürümlendirilmesi gereken veriler, otomatik olarak oluşturulan dosyalar değil, ham verilerinizdir (ardışık düzeninizin başında).

Almak isteyebilirsiniz proje dizininizin anlık görüntülerini, ancak üretilen her dosyanın her sürümünü saklamayın. Bu zaten sorununuzu adil bir marjla azaltır.

Yaklaşım 1: Verilerin gerçek versiyonunu oluşturma

Ham veya analitik verileriniz için Git LFS (ve alternatif olarak, daha önce bahsettiğiniz Git Ek) tam olarak bunu çözmek için tasarlanmıştır sorun: Git ağacınızdaki dosyaların izleme bilgilerini ekleyin, ancak bu dosyaların içeriğini havuzda depolamayın (çünkü aksi takdirde, yaptığınız her değişiklikle değişmeyen bir dosyanın boyutunu ekler).

Ara dosyalarınız için, ara kod dosyalarında yaptığınız gibi aynı şeyi yaparsınız: onları .gitignore ’unuza ekleyin ve sürümlerini atmayın.

Bu, birkaç noktaya dikkat çekiyor:

  • Git LFS, Github'ın ücretli bir hizmetidir (ücretsiz katman, ayda 1 GB depolama / bant genişliği ile sınırlıdır, bu çok azdır), ve diğer benzer bulut depolama çözümlerinden daha pahalıdır. Github'daki depolama için ödeme yapmayı veya kendi LFS sunucunuzu çalıştırmayı düşünebilirsiniz (bir referans uygulaması vardır, ancak bunun yine de önemli bir çaba olacağını varsayıyorum)
  • Git Annex ücretsizdir, ancak dosyaları şu şekilde değiştirir: bağlantı kurar ve dolayısıyla zaman damgalarını değiştirir, bu da örneğin GNU Make tabanlı iş akışları (benim için en büyük dezavantaj). Ayrıca, dosyaların getirilmesinin manuel olarak veya bir kaydetme kancası aracılığıyla yapılması gerekir

Yaklaşım 2: Yalnızca kod sürüm oluşturma, verileri eşitleme

Analitik verileriniz aşağıdakiler için aynı kalırsa analizlerinizin çoğu, bu nedenle onu sürümleme ihtiyacı (önemli olan veri kaynağını yedeklemek ve belgelemek yerine) sınırlı olabilir.

Bunun işe yaramasını sağlamanın anahtarı, tüm .gitignore dosyanızdaki güçlü> veri dosyaları ve proje kökünüzde bir komut dosyasıyla rsync içindeki tüm kod dosyalarınızı yoksayın ( uzantılar ve dizinler yalnızca örnektir):

  #! / bin / bashcd $ (dizin adı $ 0) rsync -auvr \ --hariç "* .r" \ --dahil "* .RData "\ --exclude" dizinini yerel olarak ihtiyaç duymadığınız büyük dosyalarla "\ ana bilgisayarınız: / / proje / yol / *.  

Buradaki avantaj, çalıştırdığınız rsync komutunu hatırlamanıza gerek olmamasıdır. Komut dosyasının kendisi sürüm kontrolüne girer.

Bu, özellikle yoğun işlemlerinizi bir bilgisayar kümesinde yapıyorsanız ancak yerel makinenizdeki sonuç dosyalarınızdan grafikler oluşturmak istiyorsanız yararlıdır. Çift yönlü senkronizasyona genellikle ihtiyacınız olmadığını iddia ediyorum.

Bu arada, en azından biomake'de zaman damgası yerine dosya hash'i kullanabilirsiniz (doi: 10.1093 / bioinformatics / btx306).
@IakovDavydov Bunun farkındayım ama işe yarayıp yaramadığını gerçekten denemedim
Ham verilerdeki tüm değişiklikler için +1, dosya karması için +1 olarak belgelenmelidir. Ben de okuryazar programlamanın büyük bir hayranıyım ve ayrıca ham verilerin analizi ve karması için kullandığım araçları / paketlerimin sürümünü belgelemek için bu yaklaşımdan faydalandım. Dolayısıyla, bir sonuç ya da olay örgüsü gördüğümde onun üretim bağlamına da sahibim.
#2
+9
Sam Nicholls
2017-05-18 14:51:52 UTC
view on stackexchange narkive permalink

Sorunuz biraz açık, ancak ilginç bir tartışma olabileceğini düşünüyorum. Çoğu durumda, git 'de oluşturduğunuz verileri depolamanın değeceğine inanmıyorum. Sizin de belirttiğiniz gibi, büyük dosyalar için tasarlanmadı ( git-lfs 'ye sahip olsak da) ve kesinlikle BAM gibi ikili biçimler için tasarlanmadı.

Bir dosyanın nasıl oluşturulduğu ve bu dosyaya ne yapıldığının çok önemli olduğunu düşünüyorum. Oluşturulması çok çaba gerektiren büyük dosyaların bir yere yansıtılması gerekir (ancak bir sürüm kontrol sisteminde olması gerekmez). Daha az önemli (veya oluşturulması daha az zor olan), kaybolan, yıpranan veya başka bir şekilde lekelenen dosyalar, nasıl olduklarını bildiğiniz sürece yeniden oluşturulabilir.

Değeri ne olursa olsun, ben chitin adlı bir yazılım parçası üzerinde çalışıyor (kendi kendine düzensiz biyoinformatisyenler için bir kabuk olarak tanımlanıyor). Ayrıca bunun neden benim için gerekli bir proje olduğunu düşündüğüm hakkında uzun bir blog yazısı yazdım, ancak asıl neden, dosya sistemimi düzenleme ve deneylerimin iyi arşivlerini oluşturma girişimlerime rağmen, zamanla Kısaltılmış dizin adlarının ne anlama geldiğini veya hangi programın hangi verileri oluşturduğunu unutun.

chitin 'in amacı, bir komutun yürütülmesi sırasında dosya sisteminde yapılan değişiklikleri otomatik olarak yakalamaktır. . Belirli bir dosyayı yeniden oluşturmak için hangi komutların çalıştırılacağını, hangi komutların bu dosyayı kullandığını bilir ve bu dosyanın ne zaman ve neden değiştirildiğini (ve kim tarafından da) söyleyebilir.

Bitmedi. (hiçbir şey olmadı), ancak tüm verilerinizi ve sürümlerini saklamak isteyerek yanlış yola giriyor olabileceğinizi hissediyorum, ancak bence çoğu insan değişiklikleri teşvik eden komutları bilmek istiyor. Veri geçmişi önemliyse (ve kodunuzun sürümü iyi ayarlanmışsa), verileri yeniden oluşturmak için herhangi bir işlemi kontrol edebilir ve analizinizi yürütebilirsiniz.

Özür dilerim ama bunu olumsuz olarak değerlendiriyorum. İlginç tartışma noktası, ancak OP'nin sorusuna cevap vermiyor.
#3
+6
Daniel Standage
2017-05-21 12:27:58 UTC
view on stackexchange narkive permalink

Öncelikle, sürüm oluşturmayı ciddiye aldığınız için sizi tebrik ederiz. Bu sorunu dikkate aldığınız gerçeği, sorumlu araştırma yapmak istediğinize dair iyi bir işarettir!

Birçok biyoinformatik projesi için, veri dosyaları o kadar büyüktür ki, verileri doğrudan git gibi bir araçla versiyonlamak pratik değil. Ancak sorunuz gerçekten birkaç farklı konuyu ele alıyor.

  • Araştırmamı nasıl tekrarlanabilir şekilde yapabilirim ve ürettiğim her veri noktası ve sonucun tam kaynağını nasıl gösterebilirim?
  • Araştırmamı birden çok makinede nasıl yönetirim ve senkronize ederim?

Kısa cevap :

  • Birincil verileri arşivleyin.
  • İş akışınızı sürüm kontrolü altına alın.
  • Büyük veri dosyalarının sürüm sağlama toplamları.
  • İş akışınızı makineler arasında senkronize etmek için GitHub'ı kullanın.

Uzun cevap :

Birincil verileri arşivleyin

Tekrarlanabilirlik söz konusu olduğunda, en önemli olan birincil verilerdir: enstrümandan topladığınız ham, işlenmemiş veriler. Başkaları tarafından yayınlanan verileri analiz ediyorsanız, verileri birincil resmi kaynağından indirme görevini otomatikleştirecek bir komut dosyası yazın ve bu komut dosyasını sürüm kontrolü altına alın.

Siz veya bir Laboratuar arkadaşı veya bir meslektaşınız verileri üretti ve henüz yayınlanmadı, o zaman bir arşive göndermek için planlarınız olmalı. Aslında, çoğu dergi ve finansman kuruluşu artık yayınlanmadan önce buna ihtiyaç duymaktadır. Hatta verilerin toplanır toplanmaz sunulması gerektiğini söyleyecek kadar ileri gidiyorum. Bilim adamları, verilerinin çalınması ve fikirlerinin toplanması konusunda çok endişeleniyorlar, ancak istatistiksel olarak konuşursak, kepçelenme olasılığı, hiç kimsenin verilerinize dokunmamasından veya makalenizi okumadan çok daha düşük. Ancak siz veya bir danışman ısrar ederse, çoğu veri arşivi, destekleyici bir makale yayınlanana kadar verileri uzun süre gizli tutmanıza izin verir.

Fastq dosyalarını bir git deposuna koymak (örneğin) birçok nedenden dolayı kötü bir fikirdir. Hiçbir barındırma hizmeti bu kadar büyük dosyaları desteklemez, git bu kadar büyük dosyalarla çok yavaş olacaktır, ancak en önemlisi git / GitHub arşivlenemez! Uygun bir veri arşivi kullanın!

İş akışınızı sürüm kontrolü altına alın

Ham verilerinize salt okunur muamelesi yapın. Ham verileri yalnızca komut dosyalarını kullanarak işleyin ve bu komut dosyalarını sürüm kontrolü altında tutun. Vince Buffalo bunu Bioinformatics Data Skills kitabında iyi anlatıyor. Kontrol edin!

Büyük veri dosyalarının sürüm sağlama toplamları

İzlemek istediğiniz ancak sürüm kontrolü altına yerleştirilemeyecek kadar büyük veri dosyaları varsa, sağlama toplamlarını hesaplayın ve yerleştirin bunlar sürüm kontrolü altında. Sağlama toplamları, tüm pratik amaçlar için her veri dosyası için benzersiz olan çok küçük alfasayısal dizelerdir. Bu nedenle, 5 GB kırpılmış Fastq dosyasını veya 7 GB BAM dosyasını sürüm kontrolü altına koymak yerine, sağlama toplamlarını hesaplayın ve sağlama toplamlarını sürüm kontrolü altına alın. Sağlama toplamları dosyalarınızın içeriğini size söylemez, ancak dosya içeriği değiştiğinde size söyleyebilirler.

Bu, analizinizdeki her veri noktası için tam açıklama ve tam bir kaynak sağlayacaktır. İş akışında birincil verileri indirmek için bir komut dosyası / komut, verilerin işlenmesi için komut dosyaları / komutlar ve ara ve son çıktı dosyalarını doğrulamak için imza görevi gören sağlama toplamları bulunur. Bununla, herkes analizinizi yeniden üretebilir!

İş akışınızı makineler arasında senkronize etmek için GitHub'ı kullanın

İş akışınız zaten git ile sürüm kontrolü altındaysa, bunu zorlamak çok önemsizdir GitHub, GitLab veya BitBucket gibi bir barındırma hizmetine. O halde, kodunuzu çeşitli makinelerinizde güncel tutmak için git push ve git pull kullanmak yeterlidir.

#4
+5
H. Gourlé
2017-05-18 17:46:13 UTC
view on stackexchange narkive permalink

Open Science Framework, tüm dosyalar için sürüm oluşturmayı kullanır ve kullanımı ücretsizdir: https://osf.io

Aşağıdakiler gibi çeşitli kaynaklardan gelen verileri veya kodu entegre edebilirsiniz: github, dropbox, google drive, figshare veya amazon cloud

OSF veri depolamasını kullanarak da dosyalarınızı sunucularında depolayabilirsiniz, ancak dosya boyutu sınırının ne olduğunu tam olarak bilmiyorum.

#5
+4
Ian Sudbery
2017-05-19 14:33:59 UTC
view on stackexchange narkive permalink

Bununla başa çıkma şeklimiz şudur:

  • Tüm iş, kümeye monte edilmiş tek bir dosya sisteminde yapılır
  • Bu dosya sistemi, sshfs aracılığıyla yerel makinelere bağlanır / samba (ağdaki mevcut "yerel" makinenin konumuna bağlı olarak).
  • Kod, git hub ile sürümlendirilir
  • Tüm hesaplamalar, hafif otomatikleştirilmiş ardışık düzenler aracılığıyla gerçekleştirilir . Ruffus'u şirket içi bir yardımcı katmanla birlikte kullanıyoruz. Sistemin, boru hattına manuel olarak yürütmekten daha fazla bir adım eklemeye çalışması olmadığı sürece gerçekten önemli değil.
  • Şüpheli tasarım kararlarının tümü yapılandırma dosyalarında kodlanmıştır. Bu yapılandırma dosyaları, ardışık düzen tarafından çok ayrıntılı bir günlük çıktısı (çalıştırılan, çalıştırılan kodun git commit'si, çalıştırıldığı dosyaların zaman damgası vb.) Ve ilk girdi dosyaları ile birlikte sürüm kontrollü.
  • Bunun yararı, kod + yapılandırma + zaman = çıktı olmasıdır. Her değişiklik yapıldığında tüm ardışık düzeni yeniden çalıştırılması beklenmez, ancak ardışık düzen size bir şeyin güncel olup olmadığını söyleyecektir (zaman damgaları veya dosya karmaları kullanabilir) ve bunların tümü yayınlanmadan önce tek seferde çalıştırılabilir.
  • Diğer tüm analizler juptyer not defterlerinde yapılır. Bunlar sürüm kontrollüdür.

Özetlemek gerekirse, birden fazla CPU konumu kullansak bile yalnızca bir disk konumundan çalıştığımız için senkronize etmiyoruz. Sürüm kontrolü yapıyoruz:

  • Kod
  • Girişler, yapılandırma, günlükler
  • Juptyer not defterleri

Günlük, git commits geçerli çıktıları üretmek için kullanılır.

İlginç Ian, bu arzuladığım türden bir tasarım, ama gerçekten uygulamaya geçme. Ruffus'un üstündeki bu kurum içi katman ilgimi çekti, nedir bu?
İşin püf noktası, bir ardışık düzen görevi yazmayı bir küme iş gönderme betiğinden daha kolay hale getirmektir. Kullanım katmanı CGATPipelines (www.github.com/CGATOxford/CGATPipelines) tarafından sağlanmaktadır.
#6
+3
woemler
2017-05-18 18:44:31 UTC
view on stackexchange narkive permalink

Git'i sürüm kontrol kodu için kullanmak iyi bir uygulamadır, ancak büyük veri dosyalarının sürümlerini oluşturmaya pek uygun değildir. Verileri birden çok düğüm arasında manuel olarak senkronize etmek sorun yaratır, bu senkronizasyonun ya yönetilen bir ortamda otomatik olarak yapılmasını ya da dosyaların ağa bağlı tek bir depolama cihazında tutulmasını istiyorsunuz.

Yapabileceğiniz bir araç araştırmak istiyorum, biyoinformatik verilerini ve iş akışlarını birden çok makinede senkronize etmek için tasarlanmış Arvados. Proje web sitesinden:

Arvados, genomik ve diğer büyük verileri depolamak, düzenlemek, işlemek ve paylaşmak için bir platformdur. Platform, veri bilimcilerinin analizler geliştirmesini, geliştiricilerin genomik web uygulamaları oluşturmasını ve BT yöneticilerinin büyük ölçekli bilgi işlem ve depolama genomik kaynaklarını yönetmesini kolaylaştırmak için tasarlanmıştır. Platform, bulutta veya kendi donanımınızda çalışacak şekilde tasarlanmıştır.

Arvados'u sadece eskisinden çok daha iyi hale gelirse kullanırdım.
@nuin: Özellikle neyin eksik olduğunu düşünüyorsunuz ve / veya bunu OP'nin problemine bir çözüm olarak uygun kılmaz?
@woemier Son zamanlarda denemedim ve eğer doğru hatırlıyorsam, basit şeyler kurmak ve çalıştırmak için bir PITA idi. Ama dediğim gibi, daha iyi olup olmadığını bilmiyorum.
#7
+3
weiji14
2018-03-27 08:17:13 UTC
view on stackexchange narkive permalink

Bu yanıt, yalnızca büyük veri bölümlerini, yani 100MB'nin üzerindeki şeyleri kapsayacaktır ve yalnızca analiz hattınız Python ekosistemiyle bağlantılıysa. Biraz öğrenme gerektirecek

"Veri için kapı açma aracı" ( Github sayfası) gibi yorgan kullanmayı deneyin.

  $ pip install quilt $ quilt uciml / iris -x da2b6f5 #note kısa karması $ python>>> quilt.data.uciml'den import iris # veriniz var  

Artıları:

  • Genel paketler için bir dosya boyutu sınırı yok gibi görünüyor (ancak bunu stres testi yapmadım)
  • Tekrarlanabilirliği sağlamak için verilerinizi susturur
  • Sürüm belirleme ve etiketler için destek

Dezavantajları:

  • Özel verilerin depolanması, kullanıcı / ay başına 7 ABD dolarından başlayıp 1 TB veriye kadar
  • Python yalnızca bu noktada, bazı topluluk R desteği

Daha fazla bilgi buradan.



Bu Soru-Cevap, otomatik olarak İngilizce dilinden çevrilmiştir.Orijinal içerik, dağıtıldığı cc by-sa 3.0 lisansı için teşekkür ettiğimiz stackexchange'ta mevcuttur.
Loading...