🥇Notatki Data Scientist: osobisty przegląd języków zapytań do danych

Dzielę się osobistym doświadczeniem, co, gdzie i kiedy się przydało. Przeglądowo i zwięźle, aby było jasne, co i gdzie można działać dalej – ale mam tu wyłącznie subiektywne doświadczenie, a u Państwa może być zupełnie inaczej.

Dlaczego ważne jest znać i umieć posługiwać się językami zapytań? W Data Science jest kilka kluczowych etapów pracy, a pierwszym i najważniejszym (bez którego nic nie zadziała!) jest pozyskiwanie lub wydobywanie danych. Najczęściej dane gdzieś w jakiejś formie się znajdują i trzeba je stamtąd 'wydobyć'.

Języki zapytań są właśnie tymi, które umożliwiają wydobycie danych! Dziś opowiem o językach zapytań, które mi się przydały oraz pokażę, gdzie i jak dokładnie – jakie to ma znaczenie w nauce.

Będzie trzy główne bloki typów zapytań do danych, które omówimy w tym artykule:

"Standardowe" języki zapytań – to, co zwykle mamy na myśli, mówiąc o językach zapytań, takie jak algebra relacyjna lub SQL.
Skryptowe języki zapytań: na przykład narzędzia Pythona takie jak pandas, numpy czy skrypty shellowe.
Języki zapytań dla grafów wiedzy i grafowych baz danych.

Wszystko, co tu napisano, to tylko osobiste doświadczenie, co się przydało, z opisem sytuacji oraz 'dlaczego to było potrzebne' – każdy może ocenić, jak podobne sytuacje mogą się u niego zdarzyć i spróbować się do nich przygotować, poznając te języki zanim będą musiali je (w trybie pilnym) zastosować w projekcie lub w ogóle trafić do projektu, gdzie będą potrzebne.

"Standardowe" języki zapytań

Standardowe języki zapytań w tym rozumieniu, że zazwyczaj myślimy o nich, mówiąc o zapytaniach.

Algebra relacyjna

Dlaczego dzisiaj potrzebna jest algebra relacyjna? Aby mieć dobre pojęcie, dlaczego języki zapytań są skonstruowane w określony sposób i świadomie je wykorzystywać, trzeba zrozumieć rdzeń, na którym się opierają.

Co to jest algebra relacyjna?

Formalna definicja brzmi: algebra relacyjna – zamknięty zbiór operacji nad relacjami w relacyjnym modelu danych. Mówiąc bardziej ludzkim językiem, to system operacji na tabelach, w taki sposób, że wynikiem również jest zawsze tabela.

Zobacz wszystkie operacje relacyjne w tego artykuł z Habra — tutaj opisujemy, dlaczego warto wiedzieć i gdzie można to zastosować.

Dlaczego?

Zaczynasz rozumieć, z czego w ogóle składają się języki zapytań i jakie operacje stoją za wyrażeniami konkretnego języka zapytań — często daje to głębsze zrozumienie tego, co i jak działa w językach zapytań.

Zaczerpnięte z tego artykułu. Przykład operacji: join, która łączy tabele.

Materiał do nauki:

Dobry wprowadzający kurs od Stanfordu. W ogóle, materiałów na temat algebry relacyjnej i teorii jest mnóstwo — Coursera, Udacity. Jest także ogromna ilość materiałów online, w tym dobre kursy akademickie. Mój osobisty przekaz: trzeba bardzo dobrze rozumieć algebrę relacyjną — to podstawa podstaw.

SQL

Zaczerpnięte z tego artykułem.

SQL to w zasadzie implementacja algebry relacyjnej — z ważnym zastrzeżeniem, SQL jest deklaratywny! To znaczy, zapisując zapytanie w języku algebry relacyjnej, faktycznie mówisz, jak powinno się liczyć — a w SQL określasz, co chcesz wydobyć, a następnie DBMS generuje (efektywne) wyrażenia w języku algebry relacyjnej (ich równoważność jest znana nam z teorii Codda).

Zaczerpnięte z tego artykułem.

Dlaczego?

Relacyjne DBMS: Oracle, Postgres, SQL Server, itd. — nadal są praktycznie wszędzie i istnieje ogromne prawdopodobieństwo, że przyjdzie Ci z nimi współpracować, co oznacza, że będziesz musiał albo czytać SQL (co jest bardzo prawdopodobne), albo pisać w nim (też nie jest to mało prawdopodobne).

Co czytać i studiować

Na tych samych linkach powyżej (o algebrze relacyjnej) jest niewiarygodna ilość materiałów, na przykład ten.

Przy okazji, czym jest NoSQL?

„Należy jeszcze raz podkreślić, że termin „NoSQL” ma całkowicie spontaniczne pochodzenie i nie ma uznanego definicji ani instytucji naukowej za sobą.” Odpowiednie artykuł na Habrze.

W zasadzie, ludzie zrozumieli, że pełny model relacyjny nie jest potrzebny do rozwiązania wielu problemów, szczególnie tam, gdzie, na przykład, kluczowa jest wydajność i dominują określone proste zapytania z agregacją — tam krytycznie ważne jest szybkie liczenie metryk i zapisywanie ich w bazie, a większość cech relacyjnych okazała się nie tylko niepotrzebna, ale wręcz szkodliwa — po co normalizować coś, jeśli to popsuje to, co jest dla nas najważniejsze (w przypadku konkretnego zadania) — wydajność?

Często potrzebne są elastyczne schematy zamiast sztywnych schematów matematycznych klasycznego modelu relacyjnego — i to znacznie upraszcza rozwój aplikacji, gdy kluczowe jest szybkie wdrożenie systemu i rozpoczęcie pracy, przetwarzając wyniki — lub schemat i typy przechowywanych danych nie są aż tak ważne.

Na przykład, tworzymy system ekspertowy i chcemy przechowywać informacje z określonej dziedziny razem z pewnymi metadanymi — możemy nie znać wszystkich pól i po prostu przechowywać JSON dla każdego wpisu — to daje nam bardzo elastyczne środowisko do rozszerzania modelu danych i szybkiego iterowania — dlatego w takim przypadku NoSQL będzie nawet bardziej preferowany i czytelny. Przykład wpisu (z jednego mojego projektu, gdzie 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żna przeczytać więcej tutaj o NoSQL.

Co studiować?

Tutaj należy po prostu dobrze przeanalizować swoje zadanie, jakie ma właściwości i jakie systemy NoSQL pasują do tego opisu — a potem zacząć studiowanie danego systemu.

Języki zapytań skryptowych

Na początku wydaje się, że Python nie ma w ogóle związku — to język programowania, a nie o zapytaniach.

Pandas to jak szwajcarski nóż Data Science, ogromna ilość transformacji danych, agregacji itd. dzieje się w nim.
Numpy — obliczenia wektorowe, macierze i algebra liniowa.
Scipy — dużo matematyki w tym pakiecie, szczególnie statystyki.
Jupyter lab — dużo eksploracyjnej analizy danych dobrze pasuje do notatników — warto to umieć.
Requests — praca z siecią.
Pyspark — bardzo popularny wśród inżynierów danych, prawdopodobnie będziesz musiał korzystać z tej lub Sparka, po prostu z powodu ich popularności.
*Selenium — bardzo przydatny do zbierania danych ze stron i zasobów, czasami po prostu inaczej danych nie da się uzyskać.

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

Pandas

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

import pandas as pd
df = pd.read_csv("data/dataset.csv")
# Oblicz i zmień nazwy agregacji
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'}))

W zasadzie widzimy, że kod wpisuje się w klasyczny wzór SQL.

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

Jednak ważną częścią jest to, że ten kod jest częścią skryptu i pipeline'u, w praktyce wbudowujemy zapytania w Pythonowy pipeline. W tej sytuacji język zapytań dochodzi do nas z bibliotek, takich jak Pandas lub pySpark.

Ogólnie w pySpark widzimy podobny typ transformacji danych przez język zapytań w duchu:

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

Gdzie i co przeczytać

Na temat samego Pythona w ogóle nie ma problemu znaleźć materiały do nauki. W sieci jest ogromna ilość tutoriali dotyczących pandas, pySpark oraz kursów o Spark (a także o samym DS). Generalnie materiały te świetnie guglają się, a jeśli miałbym wybrać jeden pakiet, na którym warto się skupić — to byłby to oczywiście pandas. W zakresie DS + Python również jest bardzo dużo.

Shell jako język zapytań

Nie mało projektów związanych z przetwarzaniem i analizą danych, z którymi miałem do czynienia — to w zasadzie skrypty shellowe, które wywołują kod w Pythonie, w Javie i same komendy shellowe. Dlatego w ogóle można rozpatrywać pipeline'y w bashu/zsh/itd. jako pewnego rodzaju zapytanie na wyższym poziomie (można tam oczywiście włożyć również pętle, ale to jest nietypowe dla kodu DS w językach shellowych), przytoczę prosty przykład — musiałem stworzyć mapowanie QID z wikidat i pełnego linku do rosyjskiej i angielskiej wiki, w tym celu napisałem proste zapytanie z komend w bashu, a do wyjścia stworzyłem prosty skrypt w Pythonie, które złożyłem razem 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")'

To był właściwie cały pipeline, który stworzył potrzebne mapowanie, jak widzimy, wszystko działało w trybie strumieniowym:

pv filepath — daje pasek postępu na podstawie rozmiaru pliku i przekazuje jego zawartość dalej
unpigz -c czytał część archiwum i oddawał jq
jq z kluczem — stream od razu wydawał wynik i przekazywał go do postprocesora (tak jak w pierwszym przykładzie) w Pythonie
wewnątrz postprocesora — to prosta maszyna stanów, która formatowała wynik

Wynikowy złożony pipeline działający w trybie strumieniowym na dużych danych (0,5 TB), bez znaczących zasobów i stworzony z prostego pipeline'a oraz kilku narzędzi.

Kolejna ważna rada: naucz się dobrze i efektywnie pracować w terminalu oraz pisać w bashu/zsh/etc.

Gdzie to się przyda? Prawie wszędzie – materiałów do nauki znów jest BARDZO dużo w sieci. W szczególności, oto ten mój wcześniejszy artykuł.

R scripting

Czytelnicy mogą zawołać – no, to cały język programowania! I oczywiście mają rację. Jednak zazwyczaj spotykałem się z R w kontekście, w którym w zasadzie przypominało to język zapytań.

R to środowisko do obliczeń statystycznych oraz język obliczeń statystycznych i wizualizacji (zgodnie z tym).

Zalecam stąd. Swoją drogą, to dobry materiał.

Dlaczego data scientist powinien znać R? Przynajmniej dlatego, że istnieje ogromna grupa ludzi spoza IT, którzy zajmują się analizą danych w R. Spotkałem ich w następujących sektorach:

Sekret farmaceutyczny.
Biolodzy.
Sektor finansowy.
Ludzie z czysto matematycznym wykształceniem, zajmujący się statystyką.
Specjalistyczne modele statystyczne i modele uczenia maszynowego (które często można znaleźć tylko w autorskich wersjach w postaci pakietu R).

Dlaczego to właściwie język zapytań? W formie, w jakiej się go często spotyka – to w zasadzie zapytanie o stworzenie modelu, w tym odczyt danych i ustalanie parametrów zapytania (modeli), a także wizualizacja danych w takich pakietach jak ggplot2 – to też forma pisania zapytań.

Przykład zapytań 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 wiele pomysłów z R przeniosło się do pakietów python, takich jak pandas, numpy czy scipy, w postaci ram danych i wektoryzacji danych – dlatego w ogóle wiele rzeczy w R wydaje się znajomych i wygodnych.

Jest wiele źródeł do nauki, na przykład ten.

Wykresy wiedzy (Knowledge graph)

Tutaj mam nieco nietypowe doświadczenie, ponieważ często muszę pracować z wykresami wiedzy oraz językami zapytań do wykresów. Dlatego przejdźmy krótko przez podstawy, ta część jest nieco bardziej egzotyczna.

W klasycznych relacyjnych bazach danych mamy sztywną strukturę — tutaj struktura jest elastyczna, każdy predykat to właściwie 'kolumna' i jeszcze więcej.

Wyobraźcie sobie, że modelujecie człowieka i chcielibyście opisać kluczowe cechy, weźmiemy konkretną osobę, Douglasa Adamsa, jako przykład opisu.

www.wikidata.org/wiki/Q42

Gdybyśmy używali bazy relacyjnej, musielibyśmy stworzyć ogromną tabelę lub tabele z ogromną liczbą kolumn, z których większość byłaby NULL lub wypełniona jakąś domyślną wartością False, na przykład, niewielu z nas ma wpis w krajowej bibliotece koreańskiej — oczywiście, moglibyśmy wyodrębnić je do oddzielnych tabel, ale w końcu byłoby to próba odwzorowania elastycznej logiki schematu za pomocą sztywnej relacyjnej.

Dlatego wyobraźcie sobie, że wszystkie dane są przechowywane w postaci grafu lub w postaci binarnych i unarnych wyrażeń logicznych.

Gdzie w ogóle można się z tym spotkać? Przede wszystkim pracując z danymi wikimi, a także z wszelkimi grafowymi bazami danych lub danymi powiązanymi.

Dalej przedstawiam główne języki zapytań, które miałem okazję stosować i z którymi miałem do czynienia.

SPARQL

Wiki:
SPARQL (rekursywny akronim od ang. SPARQL Protocol and RDF Query Language) — język zapytań do danych, przedstawionych w modelu RDF, a także protokół do przesyłania tych zapytań i odpowiedzi na nie. SPARQL jest rekomendacją organizacji W3C i jedną z technologii semantycznej sieci.

Tak naprawdę jest to język zapytań do unarnych i binarnych predykatów logicznych. W zasadzie wskazujecie, co jest stałe w wyrażeniu logicznym, a co nie (bardzo uproszczone).

Sama baza RDF (Resource Description Framework), nad którą wykonywane są zapytania SPARQL — to trójka obiekt, predykat, podmiot — a zapytanie wybiera odpowiednie trójki zgodnie z określonymi ograniczeniami w duchu: znajdź takie X, że p_55(X, q_33) jest prawdziwe — gdzie oczywiście p_55 to jakieś odniesienie z id 55, a q_33 to obiekt z id 33 (to wszystko, omijając wszelkie szczegóły).

Przykład przedstawienia danych:

Obrazki i przykład z krajami tutaj stąd.

Przykład podstawowego zapytania

W zasadzie chcemy znaleźć wartość zmiennej ?country, taką że dla predykatu
member_of, jest prawdą, że member_of(?country,q458), a q458 to ID Unii Europejskiej.

Przykład rzeczywistego zapytania SPARQL w silniku python:

Z reguły musiałem czytać SPARQL, a nie pisać — w takiej sytuacji umiejętność zrozumienia języka przynajmniej na podstawowym poziomie z pewnością będzie przydatna, aby pojąć, w jaki sposób dane są wydobywane.

W Internecie jest wiele materiałów do nauki: na przykład tutaj ten i ten. Zwykle googluję konkretne konstrukcje i przykłady i jak na razie to wystarcza.

Języki zapytań logicznych

Szczegóły na ten temat można znaleźć w moim artykule tutaj. A tutaj krótkie omówienie, dlaczego języki logiczne dobrze nadają się do pisania zapytań. W zasadzie RDF to po prostu zbiór logicznych asercji w postaci p(X) i h(X,Y), a zapytanie logiczne ma następujący wygląd:

output(X) :- country(X), member_of(X, "EU").

Tutaj mówimy o utworzeniu nowego predykatu output/1 ( /1 oznacza unarny), pod warunkiem, że dla X prawdziwe jest, że country(X) — tzn. X to kraj i jednocześnie member_of(X, "EU").

To znaczy, że mamy zarówno dane, jak i zasady w takim przypadku przedstawione w zasadzie w ten sam sposób, co pozwala na bardzo łatwe i dobre modelowanie zadań.

Gdzie spotykano się w branży: duży projekt z firmą, która pisze zapytania w tym języku, a także aktualny projekt w jądrze systemu — wydaje się to dość egzotyczne, jednak czasami się zdarza.

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