Notatki analityka danych: spersonalizowany przegląd języków zapytań o dane

Notatki analityka danych: spersonalizowany przegląd języków zapytań o dane
Mówię Ci z własnego doświadczenia, co było przydatne gdzie i kiedy. To przegląd i teza, żeby było jasne, co i gdzie można kopać dalej - ale tutaj mam wyłącznie subiektywne osobiste doświadczenia, może u ciebie wszystko jest zupełnie inne.

Dlaczego znajomość i umiejętność posługiwania się językami zapytań jest ważna? W swojej istocie Data Science składa się z kilku ważnych etapów pracy, a pierwszym i najważniejszym (bez tego na pewno nic nie będzie działać!) jest pozyskanie lub wyodrębnienie danych. Najczęściej dane są gdzieś przechowywane w jakiejś formie i należy je stamtąd „odzyskać”. 

Języki zapytań pozwalają wydobyć właśnie te dane! A dzisiaj opowiem Wam o tych językach zapytań, które mi się przydały oraz opowiem i pokażę gdzie i jak dokładnie – dlaczego warto się uczyć.

Będą trzy główne bloki typów zapytań o dane, które omówimy w tym artykule:

  • „Standardowe” języki zapytań to powszechnie rozumiane języki zapytań, takie jak algebra relacyjna lub SQL.
  • Skryptowe języki zapytań: na przykład Python, pandy, numpy lub skrypty powłoki.
  • Języki zapytań dla grafów wiedzy i grafowych baz danych.

Wszystko, co tu jest napisane, to tylko osobiste doświadczenie, co się przydało, z opisem sytuacji i „dlaczego było to potrzebne” - każdy może spróbować, jak podobne sytuacje mogą się zdarzyć i spróbować przygotować się na nie z wyprzedzeniem, rozumiejąc te języki ​​zanim będziesz musiał (pilnie) aplikować do projektu lub nawet dotrzeć do projektu, w którym są potrzebne.

„Standardowe” języki zapytań

Standardowe języki zapytań są dokładnie w tym sensie, w jakim zwykle o nich myślimy, mówiąc o zapytaniach.

Algebra relacyjna

Dlaczego algebra relacyjna jest dziś potrzebna? Aby dobrze zrozumieć, dlaczego języki zapytań są zbudowane w określony sposób i używać ich świadomie, musisz zrozumieć rdzeń leżący u ich podstaw.

Co to jest algebra relacji?

Formalna definicja jest następująca: algebra relacyjna to zamknięty system operacji na relacjach w relacyjnym modelu danych. Ujmując to trochę bardziej po ludzku, jest to system operacji na tabelach taki, że wynikiem jest zawsze tabela.

Zobacz wszystkie operacje relacyjne w to artykuł od Habr - tutaj opisujemy, dlaczego warto to wiedzieć i gdzie się to przydaje.

Dlaczego?

Zaczęcie rozumienia, o co chodzi w językach zapytań i jakie operacje kryją się za wyrażeniami w określonych językach zapytań, często pozwala na głębsze zrozumienie tego, co i jak działa w językach zapytań.

Notatki analityka danych: spersonalizowany przegląd języków zapytań o dane
Pochodzą z to artykuły. Przykład operacji: Join, która łączy tabele.

Materiały do ​​nauki:

Dobry kurs wprowadzający na Uniwersytecie Stanforda. Ogólnie rzecz biorąc, istnieje wiele materiałów na temat algebry i teorii relacyjnej - Coursera, Udacity. W Internecie jest też ogromna ilość materiałów, w tym dobrych kursy akademickie. Moja osobista rada: musisz bardzo dobrze zrozumieć algebrę relacyjną - to podstawa podstaw.

SQL

Notatki analityka danych: spersonalizowany przegląd języków zapytań o dane
Pochodzą z to artykuły

SQL jest zasadniczo implementacją algebry relacyjnej - z ważnym zastrzeżeniem, SQL jest deklaratywny! Oznacza to, że pisząc zapytanie w języku algebry relacyjnej tak naprawdę mówisz, jak liczyć - ale w SQL określasz, co chcesz wyodrębnić, a wtedy DBMS generuje już (efektywne) wyrażenia w języku algebry relacyjnej (ich równoważność jest nam znana jako Twierdzenie Codda).

Notatki analityka danych: spersonalizowany przegląd języków zapytań o dane
Pochodzą z to artykuły

Dlaczego?

Relacyjne systemy DBMS: Oracle, Postgres, SQL Server itp. są nadal praktycznie wszędzie i istnieje niewiarygodnie duża szansa, że ​​będziesz musiał z nimi współdziałać, co oznacza, że ​​będziesz musiał albo przeczytać SQL (co jest bardzo prawdopodobne), albo go napisać ( też nie jest to mało prawdopodobne).

Co czytać i studiować

Według tych samych linków powyżej (o algebrze relacyjnej) istnieje niesamowita ilość materiału, na przykład to.

Swoją drogą, czym jest NoSQL?

„Warto jeszcze raz podkreślić, że termin „NoSQL” ma całkowicie spontaniczne pochodzenie i nie stoi za nim żadna ogólnie przyjęta definicja ani instytucja naukowa.” Odpowiedni artykuł na Habr.

Tak naprawdę ludzie zdali sobie sprawę, że do rozwiązania wielu problemów nie jest potrzebny pełny model relacyjny, szczególnie w tych, w których na przykład wydajność jest krytyczna i dominują pewne proste zapytania z agregacją – gdzie krytyczne jest szybkie obliczanie metryk i zapisywanie ich w baza danych, a większość funkcji ma charakter relacyjny, okazała się nie tylko niepotrzebna, ale i szkodliwa - po co normalizować coś, jeśli zepsuje nam to, co dla nas najważniejsze (dla jakiegoś konkretnego zadania) - produktywność?

Ponadto często potrzebne są elastyczne schematy zamiast ustalonych schematów matematycznych klasycznego modelu relacyjnego – co niesamowicie upraszcza tworzenie aplikacji, gdy krytyczne jest wdrożenie systemu i szybkie rozpoczęcie pracy, przetwarzanie wyników – lub schemat i typy przechowywanych danych nie są aż tak ważne.

Przykładowo tworzymy system ekspertowy i chcemy przechowywać informacje o konkretnej domenie wraz z pewnymi metainformacjami - możemy nie znać wszystkich pól i po prostu przechowywać JSON dla każdego rekordu - daje nam to bardzo elastyczne środowisko do rozbudowy danych model i szybkie iterowanie - tak w tym przypadku NoSQL będzie jeszcze preferowany i bardziej czytelny. Przykładowy wpis (z jednego z moich projektów, w którym NoSQL był dokładnie tam, gdzie był potrzebny).

{"en_wikipedia_url":"https://en.wikipedia.org/wiki/Johnny_Cash",
"ru_wikipedia_url":"https://ru.wikipedia.org/wiki/?curid=301643",
"ru_wiki_pagecount":149616,
"entity":[42775,"Джонни Кэш","ru"],
"en_wiki_pagecount":2338861}

Możesz przeczytać więcej tutaj o NoSQLu.

Co studiować?

Tutaj raczej wystarczy dokładnie przeanalizować swoje zadanie, jakie ma właściwości i jakie są dostępne systemy NoSQL, które pasowałyby do tego opisu - a następnie zacząć studiować ten system.

Skryptowe języki zapytań

Na pierwszy rzut oka wydaje się, co ma z tym wspólnego Python w ogóle – to język programowania, a nie o zapytaniach w ogóle.

Notatki analityka danych: spersonalizowany przegląd języków zapytań o dane

  • Pandy to dosłownie szwajcarski scyzoryk data science, zachodzi w nim ogromna ilość transformacji, agregacji danych itp.
  • Numpy - tam obliczenia wektorowe, macierze i algebra liniowa.
  • Scipy - w tym pakiecie jest dużo matematyki, zwłaszcza statystyk.
  • Laboratorium Jupyter - wiele eksploracyjnych analiz danych dobrze pasuje do laptopów - warto wiedzieć.
  • Żądania - praca z siecią.
  • Pyspark jest bardzo popularny wśród inżynierów danych, najprawdopodobniej będziesz musiał wchodzić w interakcję z tym lub Sparkiem, po prostu ze względu na ich popularność.
  • *Selen - bardzo przydatny do zbierania danych z witryn i zasobów, czasami po prostu nie ma innego sposobu na uzyskanie danych.

Moja główna rada: naucz się Pythona!

Pandy

Weźmy jako przykład następujący kod:

import pandas as pd
df = pd.read_csv(“data/dataset.csv”)
# Calculate and rename aggregations
all_together = (df[df[‘trip_type’] == “return”]
    .groupby(['start_station_name','end_station_name'])
                  	    .agg({'trip_duration_seconds': [np.size, np.mean, np.min, np.max]})
                           .rename(columns={'size': 'num_trips', 
           'mean': 'avg_duration_seconds',    
           'amin': min_duration_seconds', 
           ‘amax': 'max_duration_seconds'}))

Zasadniczo widzimy, że kod pasuje do klasycznego wzorca SQL.

SELECT start_station_name, end_station_name, count(trip_duration_seconds) as size, …..
FROM dataset
WHERE trip_type = ‘return’
GROUPBY start_station_name, end_station_name

Ale ważne jest to, że ten kod jest częścią skryptu i potoku; w rzeczywistości osadzamy zapytania w potoku Pythona. W tej sytuacji język zapytań przychodzi do nas z bibliotek takich jak Pandas czy pySpark.

Generalnie w pySparku widzimy podobny rodzaj transformacji danych poprzez język zapytań w duchu:

df.filter(df.trip_type = “return”)
  .groupby(“day”)
  .agg({duration: 'mean'})
  .sort()

Gdzie i co czytać

Ogólnie o samym Pythonie nie ma problemu znaleźć materiały do ​​nauki. W Internecie dostępna jest ogromna liczba tutoriali pandy, pySpark i kursy na Iskra (a także samodzielnie DS). Ogólnie rzecz biorąc, zawartość tutaj świetnie nadaje się do wyszukiwania w Google, a jeśli miałbym wybrać jeden pakiet, na którym się skupię, byłyby to oczywiście pandy. Jeśli chodzi również o kombinację materiałów DS + Python bardzo.

Shell jako język zapytań

Sporo projektów przetwarzania i analizy danych, nad którymi pracowałem, to w rzeczywistości skrypty powłoki wywołujące kod w Pythonie, Javie i same polecenia powłoki. Dlatego ogólnie rzecz biorąc, potoki w bash/zsh/etc można traktować jako rodzaj zapytania wysokiego poziomu (można tam oczywiście wrzucać pętle, ale nie jest to typowe dla kodu DS w językach powłoki), dajmy na to prosty przykład - musiałem wykonać mapowanie QID wikidanych i pełne linki do rosyjskich i angielskich wiki, w tym celu napisałem proste żądanie z poleceń w bashu, a na wyjściu napisałem prosty skrypt w Pythonie, który ja połączyć tak:

pv “data/latest-all.json.gz” | 
unpigz -c  | 
jq --stream $JQ_QUERY | 
python3 scripts/post_process.py "output.csv"

gdzie

JQ_QUERY = 'select((.[0][1] == "sitelinks" and (.[0][2]=="enwiki" or .[0][2] =="ruwiki") and .[0][3] =="title") or .[0][1] == "id")' 

W rzeczywistości był to cały potok, który utworzył wymagane mapowanie; jak widzimy, wszystko działało w trybie strumieniowym:

  • pv filepath - wyświetla pasek postępu w oparciu o rozmiar pliku i przekazuje jego zawartość dalej
  • unpigz -c przeczytał część archiwum i przekazał ją jq
  • jq za pomocą klucza - strumień natychmiast wygenerował wynik i przekazał go do postprocesora (tak samo jak w pierwszym przykładzie) w Pythonie
  • wewnętrznie postprocesor był prostą maszyną stanu, która formatowała dane wyjściowe 

W sumie złożony potok pracujący w trybie przepływowym na dużych danych (0.5 TB), bez znaczących zasobów i wykonany z prostego potoku i kilku narzędzi.

Kolejna ważna wskazówka: umiej dobrze i efektywnie pracować w terminalu i pisać bash/zsh/etc.

Gdzie się przyda? Tak, prawie wszędzie – znowu jest DUŻO materiałów do nauki w Internecie. W szczególności tutaj to mój poprzedni artykuł.

Skrypty R

Znów czytelnik może zawołać – cóż, to jest cały język programowania! I oczywiście będzie miał rację. Zwykle jednak spotykałem się z R w takim kontekście, że w rzeczywistości był on bardzo podobny do języka zapytań.

R to środowisko obliczeń statystycznych i język do obliczeń statycznych i wizualizacji (wg to).

Notatki analityka danych: spersonalizowany przegląd języków zapytań o dane
zajęty stąd. Swoją drogą polecam, dobry materiał.

Dlaczego analityk danych musi znać język R? Przynajmniej dlatego, że istnieje ogromna warstwa osób spoza branży IT, które analizują dane w R. Spotkałem się z tym w następujących miejscach:

  • Sektor farmaceutyczny.
  • Biolodzy.
  • Sektor finansowy.
  • Osoby z wykształceniem czysto matematycznym zajmujące się statystyką.
  • Specjalistyczne modele statystyczne i modele uczenia maszynowego (które często można spotkać jedynie w wersji autorskiej jako pakiet R).

Dlaczego właściwie jest to język zapytań? W formie w jakiej często się spotykamy, jest to właściwie żądanie stworzenia modelu, obejmujące odczytanie danych i ustalenie parametrów zapytania (modelu), a także wizualizację danych w pakietach typu ggplot2 - jest to również forma pisania zapytań .

Przykładowe zapytania do wizualizacji

ggplot(data = beav, 
       aes(x = id, y = temp, 
           group = activ, color = activ)) +
  geom_line() + 
  geom_point() +
  scale_color_manual(values = c("red", "blue"))

Ogólnie rzecz biorąc, wiele pomysłów z R zostało przeniesionych do pakietów Pythona, takich jak pandas, numpy lub scipy, takich jak ramki danych i wektoryzacja danych - więc ogólnie wiele rzeczy w R będzie ci się wydawać znajome i wygodne.

Źródeł, z których warto skorzystać, jest wiele, np. to.

Wykresy wiedzy

Tutaj mam nieco nietypowe doświadczenie, ponieważ dość często muszę pracować z wykresami wiedzy i językami zapytań o wykresy. Dlatego omówmy krótko podstawy, ponieważ ta część jest nieco bardziej egzotyczna.

W klasycznych relacyjnych bazach danych mamy stały schemat, ale tutaj schemat jest elastyczny, każdy predykat jest tak naprawdę „kolumną” i nawet więcej.

Wyobraź sobie, że modelujesz osobę i chcesz opisać najważniejsze rzeczy, na przykład weźmy konkretną osobę, Douglasa Adamsa, i wykorzystajmy ten opis jako podstawę.

Notatki analityka danych: spersonalizowany przegląd języków zapytań o dane
www.wikidata.org/wiki/Q42

Gdybyśmy korzystali z relacyjnej bazy danych, musielibyśmy stworzyć ogromną tabelę lub tabele z ogromną liczbą kolumn, z których większość miałaby wartość NULL lub była wypełniona jakąś domyślną wartością False, na przykład jest mało prawdopodobne, aby wielu z nas miało wpis w koreańskiej bibliotece narodowej – oczywiście moglibyśmy umieścić je w osobnych tabelach, ale docelowo byłaby to próba modelowania elastycznego obwodu logicznego z predykatami przy użyciu stałego układu relacyjnego.

Notatki analityka danych: spersonalizowany przegląd języków zapytań o dane
Wyobraź sobie więc, że wszystkie dane są przechowywane w postaci wykresu lub binarnych i jednoargumentowych wyrażeń boolowskich.

Gdzie w ogóle można się z tym spotkać? Po pierwsze, praca z wiki danychoraz z dowolnymi bazami danych grafów lub połączonymi danymi.

Poniżej znajdują się główne języki zapytań, z których korzystałem i z którymi pracowałem.

SPARQL

Wiki:
SPARQL (skrót rekurencyjny od Inż. Protokół SPARQL i język zapytań RDF) - język zapytań o dane, reprezentowany przez model RDFa także protokół do przekazywania tych żądań i odpowiadania na nie. SPARQL jest rekomendacją Konsorcjum W3C i jedna z technologii sieć semantyczna.

Ale w rzeczywistości jest to język zapytań dla logicznych predykatów jednoargumentowych i binarnych. Po prostu warunkowo określasz, co jest ustalone w wyrażeniu boolowskim, a co nie (bardzo uproszczone).

Sama baza RDF (Resource Opis Framework), na podstawie której wykonywane są zapytania SPARQL, jest potrójna object, predicate, subject - i zapytanie wybiera wymagane trójki zgodnie z określonymi ograniczeniami w duchu: znajdź X taki, że p_55(X, q_33) jest prawdziwe - gdzie oczywiście p_55 jest jakąś relacją z ID 55, a q_33 jest obiekt o ID 33 (tutaj i cała historia, znowu pomijając wszelkie szczegóły).

Przykład prezentacji danych:

Notatki analityka danych: spersonalizowany przegląd języków zapytań o dane
Zdjęcia i przykład z krajami tutaj stąd.

Podstawowy przykład zapytania

Notatki analityka danych: spersonalizowany przegląd języków zapytań o dane

W rzeczywistości chcemy znaleźć taką wartość zmiennej „kraj” dla predykatu
member_of, prawdą jest, że member_of(?country,q458) i q458 to identyfikator Unii Europejskiej.

Przykład prawdziwego zapytania SPARQL wewnątrz silnika Pythona:

Notatki analityka danych: spersonalizowany przegląd języków zapytań o dane

Zwykle musiałem czytać SPARQL, zamiast go pisać - w takiej sytuacji prawdopodobnie przydatna byłaby umiejętność zrozumienia języka przynajmniej na podstawowym poziomie, aby dokładnie zrozumieć, w jaki sposób pobierane są dane. 

W Internecie jest mnóstwo materiałów do przestudiowania: na przykład tutaj to и to. Zwykle wyszukuję w Google konkretne projekty i przykłady i na razie mi wystarczy.

Logiczne języki zapytań

Więcej na ten temat możesz przeczytać w moim artykule tutaj. I tutaj sprawdzimy tylko pokrótce, dlaczego języki logiczne dobrze nadają się do pisania zapytań. Zasadniczo RDF to po prostu zbiór instrukcji logicznych w postaci p(X) i h(X,Y), a zapytanie logiczne ma następującą postać:

output(X) :- country(X), member_of(X,“EU”).

Tutaj mówimy o utworzeniu nowego predykatu wyjściowego/1 (/1 oznacza jednoargumentowy), pod warunkiem, że dla X prawdą jest, że kraj(X) - czyli X jest krajem, a także członkiem(X,„UE”).

Oznacza to, że w tym przypadku zarówno dane, jak i reguły są prezentowane w ten sam sposób, co pozwala bardzo łatwo i dobrze modelować problemy.

Gdzie spotkaliście się w branży?: cały duży projekt z firmą piszącą zapytania w takim języku, jak i na bieżącym projekcie w rdzeniu systemu - wydawałoby się, że to dość egzotyczna sprawa, ale czasem się zdarza.

Przykład fragmentu kodu w języku logicznym przetwarzającym dane wiki:

Notatki analityka danych: spersonalizowany przegląd języków zapytań o dane

Materiały: Podam tutaj kilka linków do współczesnego logicznego języka programowania Answer Set Programming - polecam go przestudiować:

Notatki analityka danych: spersonalizowany przegląd języków zapytań o dane

Źródło: www.habr.com

Dodaj komentarz