Ik vertel je uit persoonlijke ervaring wat waar en wanneer nuttig was. Het is een overzicht en een scriptie, zodat het duidelijk is wat en waar je verder kunt graven - maar hier heb ik uitsluitend subjectieve persoonlijke ervaring, misschien is alles compleet anders voor jou.
Waarom is het belangrijk om zoektalen te kennen en te kunnen gebruiken? In de kern kent Data Science verschillende belangrijke werkfasen, en de allereerste en belangrijkste (zonder dit zal niets werken!) is het verkrijgen of extraheren van gegevens. Meestal zitten de gegevens ergens in een of andere vorm en moeten ze van daaruit worden ‘opgehaald’.
Met querytalen kunt u juist deze gegevens extraheren! En vandaag zal ik je vertellen over de zoektalen die nuttig voor mij zijn geweest en ik zal je vertellen en laten zien waar en hoe precies - waarom het nodig is om te studeren.
Er zijn drie hoofdblokken met typen gegevensquery's, die we in dit artikel zullen bespreken:
- 'Standaard'-querytalen zijn wat algemeen wordt begrepen als het over een querytaal gaat, zoals relationele algebra of SQL.
- Scriptingquerytalen: bijvoorbeeld Python-dingen, panda's, numpy- of shell-scripting.
- Querytalen voor kennisgrafieken en grafiekendatabases.
Alles wat hier geschreven is, is slechts een persoonlijke ervaring, wat nuttig was, met een beschrijving van situaties en “waarom het nodig was” - iedereen kan uitproberen hoe soortgelijke situaties op je pad kunnen komen en proberen je er van tevoren op voor te bereiden door deze talen te begrijpen voordat je (dringend) moet solliciteren op een project of zelfs maar op een project moet komen waar ze nodig zijn.
"Standaard" querytalen
Standaard zoektalen zijn precies in de zin dat we er meestal aan denken als we het over zoekopdrachten hebben.
Relationele algebra
Waarom is relationele algebra vandaag de dag nodig? Om goed te begrijpen waarom zoektalen op een bepaalde manier zijn gestructureerd en deze bewust te gebruiken, moet je de kern begrijpen die eraan ten grondslag ligt.
Wat is relationele algebra?
De formele definitie is als volgt: relationele algebra is een gesloten systeem van bewerkingen op relaties in een relationeel datamodel. Om het wat menselijker te zeggen: dit is een systeem van bewerkingen op tabellen, zodat het resultaat altijd een tabel is.
Bekijk alle relationele bewerkingen in artikel van Habr - hier beschrijven we waarom je het moet weten en waar het van pas komt.
Waarom?
Als u begint te begrijpen waar het bij querytalen om draait en welke bewerkingen er achter expressies in specifieke querytalen schuilgaan, krijgt u vaak een dieper inzicht in wat in querytalen werkt en hoe.
Genomen van Lidwoord. Een voorbeeld van een bewerking: join, waarmee tabellen worden samengevoegd.
Materialen voor studie:
. Over het algemeen zijn er veel materialen over relationele algebra en theorie - Coursera, Udacity. Er is ook een enorme hoeveelheid materiaal online, inclusief goed . Mijn persoonlijk advies: je moet relationele algebra heel goed begrijpen - dit is de basis van de basis.
SQL
Genomen van artikelen.
SQL is in wezen een implementatie van relationele algebra - met een belangrijk voorbehoud: SQL is declaratief! Dat wil zeggen, wanneer je een query schrijft in de taal van de relationele algebra, zeg je eigenlijk hoe je moet berekenen - maar met SQL specificeer je wat je wilt extraheren, en dan genereert het DBMS al (effectieve) uitdrukkingen in de taal van de relationele algebra (hun gelijkwaardigheid is bij ons bekend als ).
Genomen van artikelen.
Waarom?
Relationele DBMS's: Oracle, Postgres, SQL Server, enz. zijn nog steeds vrijwel overal en de kans is ongelooflijk groot dat u ermee moet communiceren, wat betekent dat u SQL moet lezen (wat zeer waarschijnlijk is) of het moet schrijven ( ook niet onwaarschijnlijk).
Wat te lezen en te studeren
Volgens dezelfde links hierboven (over relationele algebra) is er bijvoorbeeld een ongelooflijke hoeveelheid materiaal: .
Trouwens, wat is NoSQL?
“Het is de moeite waard om nogmaals te benadrukken dat de term ‘NoSQL’ een absoluut spontane oorsprong heeft en geen algemeen aanvaarde definitie of wetenschappelijke instelling achter zich heeft.” Overeenkomend op Habr.
In feite realiseerden mensen zich dat een volledig relationeel model niet nodig is om veel problemen op te lossen, vooral niet voor die problemen waarbij bijvoorbeeld de prestaties van cruciaal belang zijn en bepaalde eenvoudige query's met aggregatie domineren - waar het van cruciaal belang is om snel metrieken te berekenen en deze naar de computer te schrijven. database, en de meeste functies zijn relationeel, bleken niet alleen onnodig, maar ook schadelijk te zijn - waarom iets normaliseren als het het belangrijkste voor ons (voor een bepaalde taak) zou bederven: productiviteit?
Ook zijn vaak flexibele schema's nodig in plaats van de vaste wiskundige schema's van het klassieke relationele model - en dit vereenvoudigt de ontwikkeling van applicaties ongelooflijk wanneer het van cruciaal belang is om het systeem in te zetten en snel aan de slag te gaan, de resultaten te verwerken - of het schema en de soorten opgeslagen gegevens zijn niet zo belangrijk.
We zijn bijvoorbeeld een expertsysteem aan het maken en willen informatie over een specifiek domein opslaan, samen met wat meta-informatie. Het kan zijn dat we niet alle velden kennen en eenvoudigweg JSON voor elk record opslaan. Dit geeft ons een zeer flexibele omgeving voor het uitbreiden van de gegevens. model en snel itererend - dus in dit geval zal NoSQL zelfs de voorkeur en beter leesbaar zijn. Voorbeeldinvoer (uit een van mijn projecten waar NoSQL precies was waar het nodig was).
{"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}
Je kunt meer lezen over NoSQL.
Wat te studeren?
Hier hoeft u alleen maar uw taak grondig te analyseren, welke eigenschappen deze heeft en welke NoSQL-systemen beschikbaar zijn die aan deze beschrijving zouden voldoen - en dan dit systeem te gaan bestuderen.
Querytalen voor scripting
In eerste instantie lijkt het erop wat Python er in het algemeen mee te maken heeft: het is een programmeertaal en helemaal niet over vragen.
- Pandas is letterlijk een Zwitsers zakmes van Data Science; er gebeurt een enorme hoeveelheid datatransformatie, aggregatie, etc. in.
- Numpy - vectorberekeningen, matrices en lineaire algebra daar.
- Scipy - er zit veel wiskunde in dit pakket, vooral statistieken.
- Jupyter lab - veel verkennende data-analyse past goed in laptops - handig om te weten.
- Verzoeken - werken met het netwerk.
- Pyspark is erg populair onder data-ingenieurs, hoogstwaarschijnlijk zul je hiermee of Spark moeten communiceren, simpelweg vanwege hun populariteit.
- *Selenium - erg handig voor het verzamelen van gegevens van sites en bronnen, soms is er gewoon geen andere manier om de gegevens te verkrijgen.
Mijn belangrijkste advies: leer Python!
Pandas
Laten we de volgende code als voorbeeld nemen:
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'}))In wezen zien we dat de code in het klassieke SQL-patroon past.
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_nameMaar het belangrijkste is dat deze code deel uitmaakt van het script en de pijplijn; in feite zijn we queries aan het insluiten in de Python-pijplijn. In deze situatie komt de querytaal naar ons toe vanuit bibliotheken zoals Pandas of pySpark.
Over het algemeen zien we in pySpark een soortgelijk type gegevenstransformatie via een querytaal in de geest van:
df.filter(df.trip_type = “return”)
.groupby(“day”)
.agg({duration: 'mean'})
.sort()Waar en wat te lezen
Over Python zelf in het algemeen materiaal vinden om te bestuderen. Er zijn een groot aantal tutorials online , en cursussen aan (en ook op zichzelf ). Over het algemeen is de inhoud hier geweldig om te googlen, en als ik één pakket zou moeten kiezen om me op te concentreren, zouden het natuurlijk panda's zijn. Ook wat betreft de combinatie van DS+Python-materialen .
Shell als querytaal
Een flink aantal gegevensverwerkings- en analyseprojecten waarmee ik heb gewerkt, zijn in feite shell-scripts die code in Python, Java en de shell-opdrachten zelf aanroepen. Daarom kun je pijplijnen in bash/zsh/etc in het algemeen beschouwen als een soort query op hoog niveau (je kunt er natuurlijk lussen in stoppen, maar dit is niet typisch voor DS-code in shell-talen), laten we geven een eenvoudig voorbeeld - ik moest een QID-toewijzing van wikidata en volledige links naar de Russische en Engelse wiki's doen, hiervoor schreef ik een eenvoudig verzoek van de commando's in de bash en voor de uitvoer schreef ik een eenvoudig script in Python, dat ik als volgt in elkaar gezet:
pv “data/latest-all.json.gz” |
unpigz -c |
jq --stream $JQ_QUERY |
python3 scripts/post_process.py "output.csv"
waar
JQ_QUERY = 'select((.[0][1] == "sitelinks" and (.[0][2]=="enwiki" or .[0][2] =="ruwiki") and .[0][3] =="title") or .[0][1] == "id")' Dit was in feite de hele pijplijn die de vereiste mapping creëerde; zoals we zien werkte alles in de streammodus:
- pv bestandspad - geeft een voortgangsbalk op basis van de bestandsgrootte en geeft de inhoud door
- unpigz -c las een deel van het archief en gaf het aan jq
- jq met de key - stream produceerde onmiddellijk het resultaat en gaf het door aan de postprocessor (hetzelfde als bij het allereerste voorbeeld) in Python
- intern was de postprocessor een eenvoudige statusmachine die de uitvoer formatteerde
In totaal een complexe pijplijn die in flow-modus werkt op grote data (0.5 TB), zonder noemenswaardige middelen en gemaakt van een eenvoudige pijplijn en een paar tools.
Nog een belangrijke tip: goed en effectief kunnen werken in de terminal en bash/zsh/etc kunnen schrijven.
Waar zal het nuttig zijn? Ja, bijna overal - nogmaals, er is VEEL materiaal om te bestuderen op internet. In het bijzonder hier mijn vorige artikel.
R-scripting
Nogmaals, de lezer zou kunnen uitroepen: dit is een hele programmeertaal! En natuurlijk zal hij gelijk hebben. Meestal kwam ik R echter in een dergelijke context tegen dat het in feite sterk leek op een querytaal.
R is een statistische computeromgeving en taal voor statisch computergebruik en visualisatie (volgens ).
genomen . Trouwens, ik raad het aan, goed materiaal.
Waarom moet een datawetenschapper R kennen? Althans, want er zit een enorme laag niet-IT-mensen die data analyseren in R. Ik kwam het op de volgende plekken tegen:
- Farmaceutische sector.
- Biologen.
- Financiële sector.
- Mensen met een puur wiskundige opleiding die zich met statistiek bezighouden.
- Gespecialiseerde statistische modellen en machine learning-modellen (die vaak alleen in de auteursversie als R-pakket te vinden zijn).
Waarom is het eigenlijk een querytaal? In de vorm waarin het vaak wordt aangetroffen, is het feitelijk een verzoek om een model te maken, inclusief het lezen van gegevens en het repareren van query(model)parameters, evenals het visualiseren van gegevens in pakketten zoals ggplot2 - dit is ook een vorm van het schrijven van query's .
Voorbeeldquery's voor visualisatie
ggplot(data = beav,
aes(x = id, y = temp,
group = activ, color = activ)) +
geom_line() +
geom_point() +
scale_color_manual(values = c("red", "blue"))Over het algemeen zijn veel ideeën van R gemigreerd naar Python-pakketten zoals panda's, numpy of scipy, zoals dataframes en datavectorisatie - dus over het algemeen zullen veel dingen in R u bekend en handig voorkomen.
Er zijn veel bronnen om te bestuderen, bijvoorbeeld .
Kennisgrafieken
Hier heb ik een enigszins ongebruikelijke ervaring, omdat ik vrij vaak moet werken met kennisgrafieken en zoektalen voor grafieken. Laten we daarom kort de basisbeginselen bespreken, aangezien dit deel iets exotischer is.
In klassieke relationele databases hebben we een vast schema, maar hier is het schema flexibel, elk predikaat is eigenlijk een ‘kolom’ en zelfs meer.
Stel je voor dat je een persoon aan het modelleren was en belangrijke dingen wilde beschrijven. Laten we bijvoorbeeld een specifieke persoon nemen, Douglas Adams, en deze beschrijving als basis gebruiken.
Als we een relationele database zouden gebruiken, zouden we een enorme tabel of tabellen moeten maken met een groot aantal kolommen, waarvan de meeste NULL zouden zijn of gevuld zouden zijn met een standaard False-waarde. Het is bijvoorbeeld onwaarschijnlijk dat velen van ons een vermelding in de Koreaanse nationale bibliotheek - we zouden ze natuurlijk in aparte tabellen kunnen plaatsen, maar dit zou uiteindelijk een poging zijn om een flexibel logisch circuit te modelleren met predikaten met behulp van een vast relationeel circuit.
Stel je dus voor dat alle gegevens worden opgeslagen als een grafiek of als binaire en unaire Booleaanse uitdrukkingen.
Waar kun je dit überhaupt tegenkomen? In de eerste plaats werken met , en met alle grafische databases of verbonden gegevens.
Hieronder volgen de belangrijkste querytalen die ik heb gebruikt en waarmee ik heb gewerkt.
SPARQL
wiki:
SPARQL ( van SPARQL-protocol en RDF-zoektaal) - , vertegenwoordigd door het model En om deze verzoeken door te geven en erop te reageren. SPARQL is een aanbeveling en een van de technologieën .
Maar in werkelijkheid is het een zoektaal voor logische unaire en binaire predikaten. U specificeert eenvoudigweg voorwaardelijk wat vaststaat in een Booleaanse expressie en wat niet (zeer vereenvoudigd).
De RDF-basis (Resource Description Framework) zelf, waarop SPARQL-query's worden uitgevoerd, is drievoudig object, predicate, subject - en de query selecteert de vereiste triples volgens de gespecificeerde beperkingen in de geest: vind een X zodat p_55(X, q_33) waar is - waarbij p_55 natuurlijk een soort relatie is met ID 55, en q_33 een object met ID 33 (hier en het hele verhaal, opnieuw met weglating van allerlei details).
Voorbeeld van gegevenspresentatie:
Foto's en voorbeeld met landen hier .
Basisqueryvoorbeeld
In feite willen we de waarde van de variabele ?land zodanig vinden dat deze voor het predikaat geldt
member_of, het is waar dat member_of(?country,q458) en q458 de ID van de Europese Unie zijn.
Een voorbeeld van een echte SPARQL-query in de Python-engine:
Normaal gesproken moest ik SPARQL lezen in plaats van schrijven - in die situatie zou het waarschijnlijk een nuttige vaardigheid zijn om de taal op zijn minst op een basisniveau te begrijpen om precies te begrijpen hoe gegevens worden opgehaald.
Er is veel materiaal om online te bestuderen: bijvoorbeeld hier и . Meestal google ik specifieke ontwerpen en voorbeelden en dat is voor nu genoeg.
Logische querytalen
Meer over dit onderwerp kun je lezen in mijn artikel . En hier zullen we slechts kort onderzoeken waarom logische talen goed geschikt zijn voor het schrijven van zoekopdrachten. In wezen is RDF slechts een reeks logische instructies van de vorm p(X) en h(X,Y), en een logische query heeft de volgende vorm:
output(X) :- country(X), member_of(X,“EU”).
Hier hebben we het over het creëren van een nieuw predikaat output/1 (/1 betekent unair), op voorwaarde dat voor X waar is dat land(X) - d.w.z. X is een land en ook lid_van(X,"EU ").
Dat wil zeggen dat in dit geval zowel de gegevens als de regels op dezelfde manier worden gepresenteerd, waardoor we problemen heel gemakkelijk en goed kunnen modelleren.
Waar hebben jullie elkaar ontmoet in de branche?: een heel groot project met een bedrijf dat zoekopdrachten in een dergelijke taal schrijft, evenals over het huidige project in de kern van het systeem - het lijkt erop dat dit nogal exotisch is, maar soms gebeurt het.
Een voorbeeld van een codefragment in een logische taal die wikidata verwerkt:
Materialen: Ik geef hier een paar links naar de moderne logische programmeertaal Answer Set Programming - ik raad aan deze te bestuderen:
Bron: www.habr.com