Blog

Dobre nawyki to jedno, ale skąd brać wiedzę? Jakis książki przeczytać? Najpierw czytać książki czy materiały w Internecie? Poczytać i zapisać się na szkolenia czy odwrotnie? O tym będzie ten fragment bloga.
Zacznijmy od kanonu literatury data science:

• Trevor Hastie (i inni): An Introduction to Statistical Learning: with Applications in R - ta książka jest dobra na początek (wymaga podstawowej znajomości statystyki, ekonometrii i algebry liniowej), zobacz książkę, książka jest oficjalnie dostępna w wersji PDF
• Trevor Hastie (i inni): The Elements of Statistical Learning: Data Mining, Inference, and Prediction, książka jest oficjalnie dostępna w wersji PDF. Ta książka jest bardziej techniczna, wymaga pewnego rozeznania w metodach, a notacja jest trudniejsza. Z drugiej strony oferuje dużo więcej niż tylko zapoznanie z metodami + kody do R.

Ci, którzy wybierają ścieżkę Pythona mają wiele darmowych materiałów do nauki tego języka. Na początek niezły kurs Pythona (podręcznik online + wideo) oferuje Google for Education. Kurs kilku podstawowych pakietów do DS (numpy, matplotlib) jest tutaj, ale to nie wszystko. Brakuje np. standardowo używanych pandas czy scikit-learn.

Znane przysłowie mówi, że czym skorupka za młodu nasiąknie... Data science dopiero zaczynam, ale pracuję z danymi już kilkanaście lat. W praktyce poznałem jak ważne są dobre nawyki:

• Używanie właściwych narzędzi do właściwych celów. Przygotowanie środowiska pracy i koncepcji. Chyba nie wymaga komentarza - przygotuj się dobrze do analiz. Przemyśl metody, sprawdź wiele możliwości. Zastanów się z jakich danych chcesz skorzystać. Może ten projekt lepiej wykonam w Python niż R? Jak poradzę sobie z 60GB plikiem? Które dane nie są mi potrzebne? Jaki chcę output? Może lepiej gdy od razu pomyślę o wykresach - przyda mi się do raportu i prezentacji. Zrób raz, ale kompleksowo, to nie będziesz wracał do tematu piętnaście razy.
• Zdrowa równowaga pomiędzy: "zrobię wszystko sam od podstaw" a "wezmę gotowca". Nie zawsze wszystko trzeba robić samodzielnie. Np. odwracanie macierzy jest doskonale oprogramowane w R a do tego wbudowana funkcja zadziała znacznie szybciej niż kod R (łatwo sprawdzić dodając dwa wektory "wbudowanym" operatorem sumy i pętlą). Przesada w drugą stronę oznacza, że bierzemy tylko to co jest gotowe. Szybko, tanio i wygodnie :) Niestety, w takim przypadku nie wiemy czy działa i w jaki sposób działa. Najprostszy przykład to mediana ze zbioru: 0, 1, 3, 7. Najczęściej wynik będzie średnią z 1 i 3, ale nie zawsze. A 10 percentyl z takich 4 obserwacji? Okazuje się, że jest kilka możliwości, jeśli zbytnio zaufasz gotowcom - otrzymasz niezrozumiały (nieoczekiwany) wynik.
• Czystość kodu. To jest ważne, gdy nie jesteśmy jedynymi czytelnikami/autorami kodu. Nawet jeśli kod jest tylko dla nas, bałagan w kodzie spowoduje, że za rok nie będziemy rozumieli własnej twórczości. Dlatego zachowujmy kod czysty: (1) Nazwy zmiennych (a także klas, funkcji, plików...) odpowiadają temu co zawiera dana zmienna (czyli Page_adress, Sender_name zamiast x1, x2), (2) Używaj komentarzy! Rób to w trakcie pisania kodu, kiedy jeszcze doskonale wiesz po co tak napisałeś/aś, czemu służy dane zmienna. W komentarzach można też napisać o tym co jest jeszcze wymaga poprawy, uzupełnienia (np. "TODO: Dodaj sprawdzenie czy wektor jest niepusty."), (3) Nie komplikuj kodu. Potrójne list comprehension wygląda super mądrze, ale może w tym przypadku pętla (albo częściowo pętla) byłaby lepsza? Przydatne są konwencje kodowania a w dużych projektach wręcz wzorce projektowe.
• Dokumentowanie własnej pracy. Czyli coś więcej niż komentarze (które robi się głównie dla siebie lub własnego teamu). Jeśli jesteś programistą w dużej firmie to zapewne będziesz musiał robić dokumentację na bieżąco (i będziesz z tego rozliczany!). A jeśli nikt Ci nie każe tego robić? Moim zdaniem staraj się robić krótkie notatki z tego co robisz. Może będziesz w przyszłości robił podobny projekt? Albo napiszesz o tym artykuł naukowy czy wpis na blogu? Prędzej czy później przekażesz komuś nie tylko wyniki ale i "wnętrze projektu" - wtedy będzie trzeba conieco opisać, ale po czasie zapomnisz większość swoich genialnych pomysłów. Poszerzasz team? Zamiast tłumaczyć wszystko od zera, możesz dać opis tego co już jest i na tej podstawie wdrażać kolegę/koleżankę do pracy. Trzeba zrobić instrukcję obsługi? Super, mam już większość w swoich notatkach. Chcesz pochwalić się tym już jest zrobione albo dostać wynagrodzenie za ukończony etap projektu? Nie ma problemu, bo zapisywałeś sobie na bieżąco co się działo :) Docenisz to szczególnie kiedy będziesz "z drugiej strony". Zdarza się, że dostajemy dane z fajnym opisem albo przejmujemy projekt z dokumentacją. W bardziej pesymistycznej (realistycznej?) opcji możesz dostać: opis zbyt lakoniczny żeby cokolwiek zrozumieć albo dokumentację w zupełnie nie znanym Ci języku.

Oczywiście to są tylko zajawki, a każdy z tych punktów można rozwinąć, ale tak naprawdę najlepiej spróbować zastosować w praktyce (spróbuj, zobaczy że oszczędzi to trochę czasu i nerwów).
Wreszcie na koniec dwie krótkie refleksje. Same obliczenia to tylko 10% pracy. Większość czasu zajmie Ci zrozumienie danych, wstępna obróbka (usunięcie braków danych, filtracja błędów technicznych - w miejscu gdzie oczekujemy liczby znajduje się tekst albo w bazie brakuje pewnych informacji, weryfikacja logiczna danych - obejrzyj dane, popatrz czy nie ma tam np. ujemnych zarobków albo czy średnia liczba dzieci w gospodarstwie domowym nie odbiega za bardzo od tego co wiemy z ogólnodostępnych danych demograficznych - jeśli tak to dlaczego?, ograniczenie zbioru). W przypadku data science dochodzą jeszcze techniczne wyzwania związane z bardzo dużymi zbiorami danych. Być może będzie trzeba zainstalować jakiś serwer bazodanowy albo zastosować jakiś szybszy algorytm? No, a na koniec trzeba to jeszcze opisać i zrobić prezentację.Teoria też jest ważna. Wszyscy mówią teraz, że studia mają uczyć praktyki, oczekujemy praktycznych rad czy wręcz gotowców. Uwierzcie mi, jestem praktykiem. Ale z czystego lenistwa warto zapoznać się z teorią - przykłady już wkrótce na blogu.

Data science zdominowały R i Python. Który wybrać?

Początkowo nie ma to wielkiego znaczenia (musimy poznać metody, a te w zasadzie nie zależą od implementacji). Problem ten pojawia się gdy chcemy nabrać praktyki, wykonać jakieś ćwiczenia na danych. Poniżej fajne strony w tej kwestii, odniosę się do nich bliżej wkrótce.
R czy Python [datacamp.com]
R czy Python [webhose.io]

W krótkich żołnierskich słowach -- główna różnica pomiędzy R a Py to punkt wyjścia twórców.

• R jest bardziej pakietem statystycznym (najbardziej przypomina Matlab, ale jego przeznaczeniem jest wykonywanie obliczeń - jak w Mathematica, Statistica, Stata, SPSS czy Gretl). Dlatego R domyślnie wyświetla wyniki na ekranie, podstawowym rodzajem danych jest wektor, domyślnie posiada też pakiet DataFrame (dla niewtajemniczonych: daleki odpowienidk arkusza w Excelu).
• Python jest pomyślany jako język programowania, wobec czego niekoniecznie musi być używany do obliczeń (można w nim napisać np. grę komputerową). Oczywiście w ramach pakietu R możemy używać skryptów i funkcji, napisanych w języku R.
• Dzięki dodatkowym bibliotekom, różnice pomiędzy R a Python zmniejszają się. Np. używając biblioteki pandas możemy obrabiać dane podobnie jak w R. Istnieje sporo bliżniaczych (R / Py) bibliotek, np. Keras, NLTK, Selenium, itp.
• Pomiędzy tymi pakietami jest wiele podobieństw. Oba są darmowe (w przeciwieństwie do Matlab), oba mają bogaty zasób bibliotek do data-science. Skrypty w R są interpretowane, podobnie jak programy w Py.

Jeśli bliższe Ci jest programowanie niż algebra czy statystyka - zapewnie będziesz zadowolony z Python (ale z drugiej strony w data-science oba komponenty są nieuniknione: programowanie oraz praca na wzorach i danych).
Jeśli używałeś Matlaba - łatwiej zaczniesz z R (zob. słownik R-Matlab).
Jeśli naturalnym sposobem zapisu jest wektor/macierz i większość operacji będzie wykonywana "wektorowo" - polubisz R.
Jeśli lubisz oglądać dane i na bieżąco wyniki na ekranie - raczej R.
Jeśli Twój program będzie działał na serwerze albo na przenośmym środowisku na USB - znacznie łatwiej to osiągniesz używając Python.

Moim naturalnym punktem wyjścia jest oczywiście praca na danych. Dzięki doświadczeniu w Matlab, kiedy potrzebowałem przesiąść się na R - zajęło mi to kilka dni metodą prób i błędów. Rozpoczęscie obliczeń w Python trwało trochę dłużej, mimo że znałem podstawy programowania. Mimo wszystko -- sam wolę Py i nowe projekty staram się robić w tym języku. Nie oznacza to, że tego co robię nie można zrobić w R! Dla obecnych zastosowań nie wielkich różnic, a osobście podoba mi się zwięzłość Py. Wydaje mi się, że środowisko użytkowników Py zapewnia trochę więcej wsparcia np. na stackoverflow.com.

Oczywiście w pracy zespołowej, nie zawsze mamy wybór. Przykładowo -- trafiam do zespołu, który ma rozpoczęty projekt albo mój szef ma silną preferencję któregoś z podejść. Poza tym polityka bezpieczeństwa firmy może nie pozwalać na instalację R czy Python. Na początek zacznij od tego podejścia, które wolisz, a prędzej czy później dojdziesz do tego, że warto poznać choćby podstawy innych podejść (być może nie tylko z grona R/Py).