Eser sahibi: kdnuggets
Çeviri: He Zhonghua
Redaksiyon: Ding Nanya
Bu makale hakkında 4200 Word, önerilen okuma 10 dakika.
Bu makale, veri bilimi çalışmalarının kolay uygulanması ve paylaşılması için hızlı bir şekilde standart ancak esnek bir veri bilimi proje yapısı oluşturmaya yardımcı olabilecek bir araç sunar.
DrivenData tarafından sunulmaktadır
Proje yapısına neden dikkat etmelisiniz?Veri analizinden bahsetmişken, genellikle sonuçları, içgörüleri veya görselleştirmeyi raporlamayı düşünüyoruz. Genellikle bu nihai sonuçlar baskındır, böylece insanlar kolayca sonuçların güzel görünmesine odaklanabilir ve onları oluşturan kodun kalitesini görmezden gelebilir. Ancak, bu son sonuçlar programlı olarak oluşturulur, Bu nedenle kod kalitesi hala çok önemlidir! Burada kod girintisini veya biçimlendirme standartlarını tartışmıyoruz Veri bilimi kod kalitesinin son standardı, doğruluk ve tekrarlanabilirliktir.
Hepimizin bildiği gibi, iyi analiz genellikle rastgele ve tesadüfi keşiflerin sonucudur. Her türden keşifsel deneyler ve sonuçsuz hızlı testler, iyi sonuçlara giden yolun bir parçasıdır ve veri keşfini basit bir doğrusal sürece dönüştürebilecek her derde deva yoktur.
Bir proje başlatıldığında, kod yapısı ve proje düzeni hakkında düşünmek zordur. Bu nedenle temiz, mantıklı bir yapıyla başlamak ve onu tutarlı hale getirmek en iyisidir. Bu tür standartlaştırılmış ayarları kullanmanın çok faydalı olduğunu düşünüyoruz. Şöyle nedenleri vardır:
Diğerleri sana teşekkür edecekİyi tanımlanmış standart bir proje yapısı, acemilerin çok sayıda belgeyi incelemek zorunda kalmadan bir analizi anlayabileceği anlamına gelir. Bu aynı zamanda, belirli bir içeriği nerede bulacaklarını bilmek için kodun% 100'ünü okumak zorunda olmadıkları anlamına gelir.
İyi organize edilmiş kod genellikle kendi kendini belgelendirebilir ve organizasyon yapısının kendisi çok fazla ek yük olmadan kodunuz için bağlam sağlayabilir. İnsanlar size bunun için teşekkür edecek çünkü şunları yapabilirler:
Herhangi bir genel web geliştirme çerçevesinde (Django veya Ruby on Rails gibi) bunun iyi örneklerini bulabilirsiniz. Yeni bir Rails projesi oluşturmadan önce kimse onu nereye koyacağını düşünmez, herkes gibi standart proje iskeletini elde etmek için yeni raylar çalıştırırlar. Bu varsayılan yapı çoğu projede mantıklı ve makul olduğundan, bu belirli projeyi hiç görmemiş kişiler kolayca çeşitli parçaları bulabilir.
Bir başka güzel örnek de Unix benzeri sistemler içindir Dosya Sistemi Hiyerarşisi Standardı (Dosya Sistemi Hiyerarşisi Standardı). / Etc dizininin çok özel bir amacı vardır, tıpkı / tmp klasörü gibi, herkes (aşağı yukarı) bu kurala uymayı kabul eder. Bu, hem Red Hat kullanıcılarının hem de Ubuntu kullanıcılarının, birbirlerinin sistemini veya standardı karşılayan başka bir sistemi kullanıyor olsalar bile, belirli dosya türlerini nerede arayacaklarını bildikleri anlamına gelir!
İdeal olarak bu, meslektaşlarınız veri bilimi projenizi açtığında da geçerli olmalıdır.
Kendine teşekkür edeceksinBirkaç ay, hatta yıllar önce yaptığınız analizi yeniden üretmeyi denediniz mi? Kodu yazmış olabilirsiniz, ancak şimdi işi tamamlamak için make_figures.py.old, make_figures_working.py veya new_make_figures01.py kullanmanız gerekip gerekmediğini bilmiyorsunuz. İşte sorularımızdan bazıları:
Bu sorunlar baş ağrısıdır ve organize olmayan projelerin belirtileridir. İyi bir proje yapısı, endişelerin ayrılması, analizi DAG'ye soyutlama ve sürüm kontrol uygulamaları gibi eski çalışmaya dönmeyi kolaylaştırmalıdır.
Herhangi bir kısıtlama olmadanBazı varsayılan klasör adlarına katılmıyor musunuz? Standart olmayan ve mevcut yapıya tam olarak uymayan bir proje üzerinde mi çalışıyorsunuz? Varsayılan (birkaç) paketten farklı bir paket kullanmak ister miydiniz?
Git! Bu, birçok proje için iyi bir başlangıç noktası olacak şekilde tasarlanmış hafif bir yapıdır. PEP 8'in dediği gibi:
Proje içindeki tutarlılık daha önemlidir. Bir modül veya işlev içindeki tutarlılık en önemlisidir. ... Ancak tutarsız olduğunu bilin ve bazen stil kılavuzu önerileri geçerli olmaz. Şüpheniz varsa, sağduyunuzu kullanın. Diğer örnekleri görüntüleyin ve en iyi sonuçları belirleyin. Ve soru sormaktan çekinmeyin!
BaşlatPython projesi için bir veri bilimi cookiecutter şablonu oluşturduk. Analizinizin Python'da olması gerekmez, ancak şablon bazı Python şablonlarını sağlar ve bunları silmek isteyebilirsiniz (örneğin, src klasöründe ve dokümanlardaki Sphinx dokümantasyon çerçevesinde).
talepYeni bir proje başlatın
Yeni bir projeye başlamak için, komut satırında aşağıdaki komutu çalıştırmanız yeterlidir. Önce bir dizin oluşturmanıza gerek yok, cookiecutter bunu sizin için yapacaktır.
cookiecutter https://github.com/drivendata/cookiecutter-data-science MisalOrijinal metin bir videodur, orijinal bağlantıdan izlenmesi tavsiye edilir.
Orijinal bağlantı: https://www.kdnuggets.com/2018/07/cookiecutter-data-science-organize-data-project.html Dizin Yapısı LİSANS Makefile < -'M data` veya `make train` README.md gibi komutlara sahip Makefile < -Bu projeyi kullanan geliştiriciler için en üst düzey README. data harici < -Üçüncü şahıs kaynaklarından gelen veriler. ara < -Dönüştürülmüş ara veriler. işlendi < -Modelleme için son, kanonik veri setleri. ham < -Orijinal, değişmez veri dökümü. docs < -Varsayılan bir Sfenks projesi; ayrıntılar için sphinx-doc.org'a bakın modeller < -Eğitilmiş ve serileştirilmiş modeller, model tahminleri veya model özetleri not defterleri < -Jupyter not defterleri. Adlandırma kuralı bir sayıdır (sipariş için), cre oluşturucunun baş harfleri ve kısa bir "-" ile sınırlandırılmış açıklama, ör. "1.0-jqp-initial-data-exploration". Referanslar < -Veri sözlükleri, kılavuzlar ve diğer tüm açıklayıcı materyaller. raporlar < -HTML, PDF, LaTeX vb. Olarak oluşturulmuş analiz rakamları < -Raporlamada kullanılmak üzere oluşturulmuş grafikler ve şekiller gereksinimler.txt < - Analiz ortamını yeniden oluşturmak için gereksinim dosyası, ör. `` Pip freeze ile oluşturulan > gereksinimler.txt` src < -Bu projede kullanılacak kaynak kodu. __init__.py < -Src'yi bir Python modülü yapar veri < -Veri indirmek veya oluşturmak için betikler make_dataset.py özellikler < Ham verileri modelleme için özelliklere dönüştürmek için betikler build_features.py modeller < -Modelleri eğitmek için betikler ve daha sonra eğitimli modeller kullanarak tahminler tahmin_model.py train_model.py görselleştirme < -Keşif ve sonuç odaklı görselleştirmeler oluşturmak için betikler visualize.py tox.ini < -tox dosyası, toksin çalıştırılması için ayarlar; bkz. tox.testrun.org GörünümVeri bilimi projeleri üzerinde çalışırken uygulanabilir ve gerçekleştirilemeyen iş deneyimimizden elde edilen proje yapısında örtük bazı görüşler vardır. Bazı noktalar iş akışı ile ilgili, bazıları ise verimliliği artıracak araçlarla ilgilidir. Aşağıda projenin dayandığı bazı inançlar yer almaktadır: Fikirleriniz varsa lütfen sağlayın veya paylaşın.
Veriler değişmezdir
Orijinal verileri düzenlemeyin, özellikle manuel olarak düzenlemeyin veya Excel'de düzenlemeyin. Orijinal verilerin üzerine yazmayın. Orijinal verilerin birden çok sürümünü kaydetmeyin. Verileri (ve biçimini) değişmez olarak ele alın. Yazdığınız kod, ham verilerin analiz hattından geçmesine ve son analizi almasına izin vermelidir. Her yeni bir hesaplama oluşturmak istediğinizde tüm adımları çalıştırmak gerekli değildir (bkz. Analiz bir DAG'dir), ancak herkes yalnızca src'deki kodu ve data / raw içindeki verileri kullanarak analiz sonuçlarını yeniden üretebilmelidir.
Ayrıca veriler değişmez ise, kod gibi kaynak kod kontrolü gerektirmez. bu nedenle Varsayılan olarak, veri klasörü .gitignore dosyasına dahil edilir. Nadiren değiştirilen az miktarda veriniz varsa, verileri depoya dahil etmek isteyebilirsiniz. Şu anda, Github dosya 50MByi aşarsa uyaracak ve 100MBnin üzerindeki dosyayı reddedecektir. Büyük verileri depolamaya / senkronize etmeye yönelik diğer bazı çözümler arasında senkronizasyon araçları (örneğin, s3cmd'nin AWS S3, Git Büyük Dosya Deposu, Git Ek ve dat) bulunur. Şu anda varsayılan olarak bir S3 demeti istiyoruz ve veri klasöründeki verileri sunucuyla senkronize etmek için AWS CLI kullanıyoruz.
Keşif ve iletişim için defterlerJupyter not defteri, Beaker not defteri, Zeppelin ve diğer etkileşimli programlama araçları, keşifsel veri analizi (EDA) için çok etkilidir. Bununla birlikte, bu araçlar analizi yeniden oluşturmak için daha az etkilidir. İş yerinde not defterleri kullandığımızda, genellikle not defteri klasörlerini alt bölümlere ayırırız. Örneğin, not defteri / keşif ilk keşfi içerirken, not defteri / rapor daha güzel işler içerir ve rapor dizinine html formatında aktarılabilir.
Dizüstü bilgisayarlar kaynak kontrolü hedefine meydan okuduğundan (örneğin, json'daki farklılıklar genellikle insan tarafından okunamaz ve birleştirilmesi neredeyse imkansızdır), başkalarıyla doğrudan Jupyter dizüstü bilgisayarlarda çalışmanızı önermiyoruz. Dizüstü bilgisayarları verimli bir şekilde kullanmak için işte iki öneri:
Varsayılan olarak, projeyi bir python paketine dönüştürüyoruz (setup.py dosyasına bakın). Kendi kodunuzu içe aktarabilir ve not defterinde aşağıdaki şekilde kullanabilirsiniz:
# İSTEĞE BAĞLI: "autoreload" uzantısını yükleyin, böylece kod% load_ext autoreload'ı değiştirebilir # İSTEĞE BAĞLI: src'deki kodu değiştirdiğinizde, src.data import make_dataset'ten% autoreload 2 yüklenecek şekilde her zaman modülleri yeniden yükleyin Analiz DAG'dirAnalizde, verileri ön işleme veya eğitim modelleri gibi genellikle uzun süren bazı adımlarınız olur. Bu adımlar zaten çalıştırılmışsa (ve çıktıyı data / ara dizin gibi bir yere kaydettiyseniz), bunların her seferinde tekrar çalışmasını beklemek istemezsiniz. Birbirine bağlı adımları, özellikle uzun süre çalışan adımları yönetmek için make'i kullanmayı tercih ediyoruz. Make, Unix tabanlı platformlarda (Windows için mevcuttur) yaygın olarak kullanılan bir araçtır. Resmi yapma belgelerini takiben, Makefile kuralları ve taşınabilirlik kılavuzu, Makefile'ınızın çeşitli sistemlerde etkili bir şekilde çalışmasını sağlamaya yardımcı olacaktır. İşte başlamak için bazı örnekler. Mike Bostock da dahil olmak üzere, veri kullanımıyla çalışan birçok kişi, tercihlerini aracı olarak yapıyor.
DSL (etki alanına özel dil) yerine Python'da yazılan DAG'leri yönetmek için başka araçlar da vardır (örneğin, Paver, Luigi, Airflow, Snakemake, Ruffus veya Joblib). Analiziniz için daha uygunlarsa, lütfen bunları kullanmaktan çekinmeyin.
Çevreden inşa edinBir analizi yeniden oluşturmanın ilk adımı, genellikle içinde çalıştığı bilgi işlem ortamını yeniden üretmektir. Her şeyin birlikte iyi çalışması için aynı araçlara, aynı kitaplıklara ve aynı sürümlere ihtiyacınız var.
Etkili bir yöntem, virtualenv kullanmaktır (virtualenv'leri yönetmek için virtualenvwrapper'ı kullanmanızı öneririz). Depodaki tüm gereksinimleri sıralayarak (bir requirements.txt dosyası ekliyoruz), analizi yeniden üretmek için gereken paketleri kolayca takip edebilirsiniz. Aşağıdakiler iyi bir iş akışıdır:
Ortamı yeniden oluşturmak için daha karmaşık gereksinimleriniz varsa, lütfen Docker veya Vagrant gibi sanal makine tabanlı bir yaklaşımı düşünün. Bu araçların her ikisi de, ihtiyaçlarınızı karşılayan bir sanal makinenin nasıl oluşturulacağını açıklamak için kaynak kontrolüne kolayca ekleyebileceğiniz metin tabanlı biçimleri (sırasıyla Dockerfile ve Vagrantfile) kullanır.
Sürüm kontrolüne şifre ve konfigürasyon eklenmemelidirAWS anahtarlarınızı veya Postgres kullanıcı adınızı ve şifrenizi Github'da kesinlikle açıklamak istemezsiniz. Tekrarlamadan, lütfen bu noktada Twelve Factor Uygulamasına bakın. Bu bir yoldur:
Sırlarınızı ve yapılandırma değişkenlerinizi özel bir dosyada saklayın
Proje kök dizininde bir .env dosyası oluşturun. .Gitignore sayesinde, bu dosyayı asla sürüm kontrol deposuna göndermeyin. Aşağıda bir örnek verilmiştir:
# örnek .env fileDATABASE_URL = postgres: // kullanıcı adı: şifre @ localhost: 5432 / dbnameAWS_ACCESS_KEY = myaccesskeyAWS_SECRET_ACCESS_KEY = mysecretkeyOTHER_VARIABLE = bir şey Bu değişkenleri otomatik olarak yüklemek için paketleri kullanınSrc / data / make_dataset.py'deki stub betiğine bakarsanız, bu dosyadaki tüm girdileri ortam değişkenleri olarak yüklemek için python-dotenv adlı bir paket kullanır, böylece bunlara os.environ.get kullanılarak erişilebilir. Bu, python-dotenv belgelerinden uyarlanmış bir örnek snippet'tir:
# src / data / dotenv_example.pyimport osfrom dotenv import load_dotenv, find_dotenv # find .env bulununcaya kadar dizinleri otomatik olarak gezdirerek .dotenv_path = find_dotenv () # girdileri ortam değişkenleri olarak yükleyin load_dotenv (dotenv_path) database_url = oens. DATABASE_URL ") other_variable = os.environ.get (" OTHER_VARIABLE ") AWS CLI yapılandırmasıVerileri depolamak için Amazon S3 kullanırken, erişim anahtarlarını ortam değişkenleri olarak ayarlayarak AWS erişimini yönetmenin kolay bir yolu vardır. Ancak bir makinede birden çok anahtarı yönetirken (örneğin, aynı anda birden fazla proje vardır), genellikle ~ / .aws / kimlik bilgileri içine yerleştirilen bir kimlik bilgisi dosyası kullanmak daha iyidir, bu da şuna benzer:
aws_access_key_id = myaccesskeyaws_secret_access_key = mysecretkey aws_access_key_id = myprojectaccesskeyaws_secret_access_key = myprojectsecretkeyProjeyi başlatırken isim ekleyebilirsiniz. Uygun ortam değişkenlerinin ayarlanmadığı varsayılarak, varsayılan yapılandırma kullanılır.
Varsayılan klasör yapısını konservatif olarak değiştirinBu yapıyı farklı türdeki projelere yaygın olarak uygulanabilir kılmak için, en iyi yolun kendi projeleriniz için olduğuna inanıyoruz, klasörü özgürce değiştirebilirsiniz, ancak tüm projeler için kullanılan varsayılan yapıyı değiştirirken muhafazakar olun.
Özellikle klasör eklemek, silmek, yeniden adlandırmak veya taşımak için bir klasör düzeni sekmesi oluşturduk. Daha genel olarak, uygulamadan önce dikkatle tartışılması ve geniş çapta desteklenmesi gereken konular için bir gereksinim tartışma sekmesi de oluşturduk.
katkıCookiecutter veri bilimi projesi biraz keyfi, ancak hata yapmaktan korkmuyor. En iyi uygulamalar her zaman değişiyor, araçlar her zaman gelişiyor ve onlardan dersler aldık. Projenin amacı, bir analize başlamayı, oluşturmayı ve paylaşmayı kolaylaştırmaktır. İstekleri ve soruları teşvik ediyoruz. Sizin için neyin işe yaradığını ve neyin işe yaramadığını bilmek isteriz.
Cookiecutter veri bilimi projesini kullanıyorsanız, lütfen bu sayfaya tekrar bağlantı verin veya bize bir beğeni verin ve bize bildirin!
İlgili projeler ve referans bağlantılarıProje yapısı ve tekrarlanabilirlik, R araştırma topluluğunda daha çok tartışılmaktadır. R. ile çalışırsanız size yardımcı olabilecek bazı projeler ve blog gönderileri.
Son olarak, klişe belgeleri düşünmek ve yazmak için daha az zaman harcamamıza ve böylece işi tamamlamak için daha fazla zaman harcamamıza yardımcı olan Cookiecutter projesine (github) çok minnettarım.
Orijinal başlık: Cookiecutter Data Science: Veri Bilimi Proje Bağlantınızı Nasıl Düzenleyebilirsiniz: https://www.kdnuggets.com/2018/07/cookiecutter-data-science-organize-data-project.htmlÇevirmen Profili
Ve Zhonghua, Almanya'da Yazılım Mühendisliği Yüksek Lisansı. Makine öğrenimine olan ilgiden dolayı, yüksek lisans tezi, geleneksel anlamlarını geliştirmek için genetik algoritma fikirlerini kullanmayı seçti. Şu anda Hangzhou'da büyük veri ile ilgili uygulamalar yapıyor. Datapie'ye katılmak THU, BT çalışanları için üzerine düşeni yapmayı ve aynı zamanda benzer düşünen birçok arkadaş edinmeyi umuyor.
Lütfen yeniden yazdırmak için THU verilerini belirtin