Személyes tapasztalatból mondom, hogy hol és mikor volt hasznos. Ez egy áttekintés és tézis, hogy világos legyen, mit és hol lehet tovább ásni - de itt kizárólag szubjektív személyes tapasztalataim vannak, lehet, hogy neked minden teljesen más.
Miért fontos a lekérdező nyelvek ismerete és használatának ismerete? A Data Science lényegében több fontos munkaszakaszból áll, és a legelső és legfontosabb (enélkül biztosan semmi sem fog működni!) az adatok megszerzése vagy kinyerése. Leggyakrabban az adatok valamilyen formában ott vannak valahol, és onnan kell „visszakeresni”.
A lekérdezési nyelvek lehetővé teszik ezeknek az adatoknak a kinyerését! És ma elmondom azokról a lekérdező nyelvekről, amelyek hasznosak voltak számomra, és elmondom és megmutatom, hol és hogyan pontosan - miért van szükség a tanulásra.
Az adatlekérdezési típusoknak három fő blokkja lesz, amelyeket ebben a cikkben tárgyalunk:
- A "szabványos" lekérdezési nyelvek általában értendők, amikor lekérdezési nyelvről beszélünk, mint például a relációs algebra vagy az SQL.
- Parancsfájl-lekérdezési nyelvek: például Python dolgok pandas, numpy vagy shell scripting.
- Lekérdezési nyelvek tudásgráfokhoz és gráf adatbázisokhoz.
Az itt leírtak csak egy személyes tapasztalat, ami hasznos volt, helyzetleírásokkal és „miért volt rá szükség” – mindenki kipróbálhatja, hogy miként jöhetnek rá hasonló helyzetek, és megpróbálhat előre felkészülni ezekre a nyelvek megértésével mielőtt (sürgősen) jelentkeznie kell egy projektre, vagy akár olyan projekthez is eljutnia, ahol szükség van rájuk.
"Szabványos" lekérdezési nyelvek
A szabványos lekérdezési nyelvek pontosan abban az értelemben, hogy általában gondolunk rájuk, amikor lekérdezésekről beszélünk.
Relációs algebra
Miért van szükség ma a relációs algebrára? Ahhoz, hogy jól megértsük, miért vannak a lekérdező nyelvek felépítése egy bizonyos módon, és hogy ezeket tudatosan használja, meg kell értenie a mögöttes lényeget.
Mi a relációs algebra?
A formális definíció a következő: a relációs algebra egy relációs adatmodellben lévő relációkra vonatkozó zárt műveletrendszer. Kicsit emberibben fogalmazva ez egy olyan táblákon végzett műveletrendszer, amelynek eredménye mindig egy táblázat.
Az összes relációs művelet megtekintése itt cikk a Habr-tól – itt leírjuk, miért kell tudnod, és hol jön jól.
Miért?
Ha elkezdi megérteni, hogy a lekérdezési nyelvek miről szólnak, és milyen műveletek állnak a kifejezések mögött bizonyos lekérdezési nyelveken, gyakran mélyebb megértést tesz lehetővé arról, hogy mi és hogyan működik a lekérdezési nyelveken.
Vett cikkeket. Példa egy műveletre: join, amely táblákat egyesít.
A tanuláshoz szükséges anyagok:
. Általában sok anyag létezik a relációs algebráról és az elméletről - Coursera, Udacity. Az interneten is hatalmas mennyiségű anyag található, köztük jó is . Személyes tanácsom: nagyon jól kell értened a relációs algebrát – ez az alapok alapja.
SQL
Vett cikket.
Az SQL lényegében a relációs algebra megvalósítása – egy fontos figyelmeztetéssel, az SQL deklaratív! Vagyis amikor a relációs algebra nyelvén ír le egy lekérdezést, akkor tulajdonképpen megmondja, hogyan kell számolni - de az SQL-nél megadod, hogy mit akarsz kivonni, és akkor a DBMS már generál (hatékony) kifejezéseket a relációs algebra nyelvén (azokat az ekvivalenciát úgy ismerjük ).
Vett cikket.
Miért?
Relációs DBMS-ek: Az Oracle, Postgres, SQL Server stb. még mindig gyakorlatilag mindenhol megtalálhatók, és hihetetlenül nagy az esélye annak, hogy kapcsolatba kell lépnie velük, ami azt jelenti, hogy vagy olvasnia kell az SQL-t (ami nagyon valószínű), vagy meg kell írnia ( sem valószínűtlen).
Mit kell olvasni és tanulni
Ugyanezen fenti linkek szerint (a relációs algebráról) hihetetlen mennyiségű anyag van pl. .
Egyébként mi az a NoSQL?
„Érdemes még egyszer hangsúlyozni, hogy a „NoSQL” kifejezés abszolút spontán eredetű, és nincs mögötte általánosan elfogadott definíció vagy tudományos intézmény.” Megfelelő a Habr.
Valójában az emberek rájöttek, hogy sok probléma megoldásához nincs szükség teljes relációs modellre, különösen azoknál, ahol például a teljesítmény kritikus, és bizonyos egyszerű, összesítéssel rendelkező lekérdezések dominálnak – ahol kritikus a metrikák gyors kiszámítása és a adatbázis, és a legtöbb szolgáltatás relációs, kiderült, hogy nem csak felesleges, de káros is - minek normalizálni valamit, ha az elrontja a számunkra legfontosabbat (valamilyen konkrét feladatnál) - a termelékenységet?
Ezenkívül gyakran szükség van rugalmas sémákra a klasszikus relációs modell rögzített matematikai sémái helyett - és ez hihetetlenül leegyszerűsíti az alkalmazásfejlesztést, amikor kritikus a rendszer telepítése és a gyors munka megkezdése, az eredmények feldolgozása - vagy a tárolt adatok sémája és típusai. nem olyan fontosak.
Például egy szakértői rendszert hozunk létre, és egy adott tartományra vonatkozó információkat szeretnénk tárolni néhány metainformáció mellett - előfordulhat, hogy nem ismerjük az összes mezőt, és egyszerűen tároljuk a JSON-t minden rekordhoz - ez nagyon rugalmas környezetet biztosít számunkra az adatok bővítéséhez. modell és gyorsan iteráló - így ebben az esetben a NoSQL még előnyösebb és olvashatóbb lesz. Példabejegyzés (az egyik projektemből, ahol a NoSQL pont ott volt, ahol kellett).
{"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}
Olvass tovább a NoSQL-ről.
Mit kell tanulni?
Itt inkább csak alaposan ki kell elemeznie a feladatát, milyen tulajdonságai vannak, és milyen NoSQL-rendszerek állnak rendelkezésre, amelyek megfelelnek ennek a leírásnak – majd elkezdi tanulmányozni ezt a rendszert.
Scripting Query Languages
Eleinte úgy tűnik, mi köze van a Python-hoz általában - ez egy programozási nyelv, és egyáltalán nem a lekérdezésekről szól.
- A Pandas a szó szoros értelmében a svájci adattudomány bicskája, hatalmas mennyiségű adatátalakítás, aggregáció stb. történik benne.
- Numpy - vektorszámítások, mátrixok és lineáris algebra ott.
- Scipy – sok matematika van ebben a csomagban, főleg statisztika.
- Jupyter labor – a sok feltáró adatelemzés jól illeszkedik a laptopokhoz – hasznos tudni.
- Kérések - a hálózattal való együttműködés.
- A Pyspark nagyon népszerű az adatmérnökök körében, valószínűleg ezzel vagy a Sparkkal kell kapcsolatba lépnie, egyszerűen a népszerűségük miatt.
- *Szelén – nagyon hasznos a webhelyekről és erőforrásokról való adatgyűjtéshez, néha egyszerűen nincs más mód az adatok beszerzésére.
Fő tanácsom: tanuld meg a Python-t!
pandák
Vegyük példaként a következő kódot:
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'}))Lényegében azt látjuk, hogy a kód illeszkedik a klasszikus SQL-mintába.
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_nameDe az a fontos, hogy ez a kód része a szkriptnek és a folyamatnak; valójában lekérdezéseket ágyazunk be a Python folyamatba. Ebben a helyzetben a lekérdezési nyelv olyan könyvtárakból érkezik hozzánk, mint a Pandas vagy a pySpark.
Általában a pySparkban hasonló típusú adatátalakítást látunk egy lekérdezési nyelven keresztül, a következő szellemben:
df.filter(df.trip_type = “return”)
.groupby(“day”)
.agg({duration: 'mean'})
.sort()Hol és mit érdemes olvasni
Magán a Pythonon általában tanulni való anyagokat találni. Rengeteg oktatóanyag található az interneten , és tanfolyamok tovább (és önmagában is ). Összességében az itteni tartalom kiválóan alkalmas a guglizáshoz, és ha egy csomagot kellene választanom, amire koncentrálnom kellene, az természetesen pandák lennének. Ami a DS+Python anyagok kombinációját illeti, szintén .
Shell mint lekérdezési nyelv
Jó néhány adatfeldolgozó és elemző projekt, amellyel dolgoztam, valójában shell-szkriptek, amelyek Pythonban, Java-ban kódot hívnak meg, és magukat a shell-parancsokat. Ezért általában a bash/zsh/etc-ben lévő pipeline-eket tekinthetjük valamiféle magas szintű lekérdezésnek (természetesen lehet hurkot tömni oda, de ez nem jellemző a shell nyelvekben a DS kódokra), adjuk meg egy egyszerű példa - el kellett végeznem a wikidata QID leképezését és az orosz és angol wikikre mutató teljes hivatkozásokat, ehhez írtam egy egyszerű kérést a bash parancsaiból, a kimenethez pedig egy egyszerű szkriptet írtam Pythonban, amit így összerakni:
pv “data/latest-all.json.gz” |
unpigz -c |
jq --stream $JQ_QUERY |
python3 scripts/post_process.py "output.csv"
ahol
JQ_QUERY = 'select((.[0][1] == "sitelinks" and (.[0][2]=="enwiki" or .[0][2] =="ruwiki") and .[0][3] =="title") or .[0][1] == "id")' Valójában ez volt a teljes csővezeték, amely létrehozta a szükséges leképezést; mint látjuk, minden működött áramlási módban:
- pv filepath – folyamatjelző sávot ad a fájl mérete alapján, és továbbítja a tartalmát
- unpigz -c elolvasta az archívum egy részét, és átadta a jq-nak
- jq a kulccsal - stream azonnal elkészítette az eredményt, és átadta az utófeldolgozónak (ugyanúgy, mint a legelső példánál) Pythonban
- belsőleg az utófeldolgozó egy egyszerű állapotgép volt, amely formázta a kimenetet
Összességében egy összetett, áramlási módban működő, nagy adatmennyiséggel (0.5 TB) működő pipeline, jelentős erőforrások nélkül, egyszerű pipeline-ból és néhány eszközből.
Még egy fontos tipp: tudj jól és hatékonyan dolgozni a terminálban és írj bash/zsh/stb.
Hol lesz hasznos? Igen, szinte mindenhol – ismét rengeteg anyagot lehet tanulmányozni az interneten. Különösen itt előző cikkem.
R szkriptelés
Az olvasó ismét felkiálthat – hát ez egy egész programozási nyelv! És persze igaza lesz. Az R-rel azonban általában olyan kontextusban találkoztam, hogy valójában nagyon hasonlított egy lekérdező nyelvhez.
Az R egy statisztikai számítási környezet és nyelv statikus számításokhoz és vizualizációhoz (a szerint ).
vett . Egyébként ajánlom, jó anyag.
Miért kell egy adattudósnak tudnia az R-t? Legalábbis azért, mert a nem informatikusok hatalmas rétege elemzi az adatokat az R-ben. A következő helyeken bukkantam rá:
- Gyógyszerszektor.
- Biológusok.
- Pénzügyi szektor.
- Tisztán matematikai végzettséggel rendelkező emberek, akik statisztikákkal foglalkoznak.
- Speciális statisztikai modellek és gépi tanulási modellek (amelyek gyakran csak a szerző verziójában találhatók meg R-csomagként).
Miért ez valójában egy lekérdezési nyelv? A gyakran előforduló formában valójában egy modell létrehozására irányuló kérés, beleértve az adatok beolvasását és a lekérdezési (modell) paraméterek rögzítését, valamint az adatok megjelenítését olyan csomagokban, mint a ggplot2 - ez is a lekérdezések írásának egyik formája. .
Példa lekérdezések a vizualizációhoz
ggplot(data = beav,
aes(x = id, y = temp,
group = activ, color = activ)) +
geom_line() +
geom_point() +
scale_color_manual(values = c("red", "blue"))Általánosságban elmondható, hogy az R-ből sok ötlet python-csomagokba költözött, mint például a pandas, a numpy vagy a scipy, mint például az adatkeretek és az adatvektorizálás – így általában az R-ben sok dolog ismerősnek és kényelmesnek tűnik az Ön számára.
Számos forrást érdemes tanulmányozni, pl. .
Tudásgrafikonok
Itt van egy kicsit szokatlan tapasztalatom, mert elég gyakran kell tudásgráfokkal és grafikonokhoz lekérdező nyelvekkel dolgoznom. Ezért csak röviden menjünk az alapokra, mivel ez a rész egy kicsit egzotikusabb.
A klasszikus relációs adatbázisokban fix sémánk van, de itt a séma rugalmas, minden predikátum valójában egy „oszlop” és még több.
Képzelje el, hogy egy személyt modellezett, és kulcsfontosságú dolgokat szeretne leírni, például vegyünk egy konkrét személyt, Douglas Adamst, és használja ezt a leírást alapul.
Ha relációs adatbázist használunk, akkor hatalmas táblát vagy táblákat kellene létrehoznunk hatalmas számú oszloppal, amelyek többsége NULL lenne, vagy valamilyen alapértelmezett False értékkel lenne kitöltve, például nem valószínű, hogy sokunknak van egy bejegyzés a Koreai Nemzeti Könyvtárban – természetesen külön táblázatokba is rakhatnánk őket, de ez végső soron egy kísérlet lenne egy rugalmas logikai áramkör modellezésére predikátumokkal egy rögzített relációs egységgel.
Tehát képzeljük el, hogy minden adat gráfként vagy bináris és unáris logikai kifejezésként van tárolva.
Hol lehet egyáltalán találkozni ezzel? Először is, dolgozni , és bármilyen grafikon adatbázissal vagy csatlakoztatott adattal.
Az alábbiak azok a fő lekérdezési nyelvek, amelyeket használtam és amelyekkel dolgoztam.
SPARQL
Wiki:
SPARQL ( -tól SPARQL protokoll és RDF lekérdezési nyelv) - , amelyet a modell képvisel És hogy továbbítsa ezeket a kéréseket és válaszoljon rájuk. A SPARQL egy ajánlás és az egyik technológia .
De valójában ez egy lekérdezési nyelv a logikai unáris és bináris predikátumokhoz. Egyszerűen feltételesen megadja, hogy mi rögzítve van egy logikai kifejezésben és mi nem (nagyon leegyszerűsítve).
Maga az RDF (Resource Description Framework) bázis, amelyen a SPARQL lekérdezések futnak, egy hármas object, predicate, subject - és a lekérdezés szellemében kiválasztja a szükséges hármasokat a megadott korlátozásoknak megfelelően: keressen egy X-et úgy, hogy a p_55(X, q_33) igaz legyen - ahol természetesen p_55 valamilyen reláció az 55-ös azonosítóval, a q_33 pedig egy 33-as azonosítójú objektum (itt és az egész sztori, megint mindenféle részlet kihagyásával).
Példa az adatok bemutatására:
Képek és példa országokkal itt .
Alapvető lekérdezési példa
Valójában meg akarjuk találni az ?ország változó értékét úgy, hogy a predikátumhoz
tag_of, igaz, hogy a member_of(?country,q458) és a q458 az Európai Unió azonosítója.
Példa egy valódi SPARQL lekérdezésre a python motoron belül:
Általában inkább olvasnom kellett a SPARQL-t, mint írni – ebben a helyzetben valószínűleg hasznos készség lenne legalább alapszinten megérteni a nyelvet, hogy pontosan megértsem, hogyan kell lekérni az adatokat.
Rengeteg anyagot lehet tanulmányozni online: például itt и . Általában konkrét terveket és példákat keresek a google-ban, és ez most elég.
Logikai lekérdezési nyelvek
A témáról bővebben a cikkemben olvashat . És itt csak röviden megvizsgáljuk, hogy a logikai nyelvek miért alkalmasak lekérdezések írására. Lényegében az RDF csupán p(X) és h(X,Y) formájú logikai utasítások halmaza, és a logikai lekérdezésnek a következő alakja van:
output(X) :- country(X), member_of(X,“EU”).
Itt egy új predikátum output/1 létrehozásáról beszélünk (/1 jelentése unáris), feltéve, hogy X-re igaz, hogy ország(X) - azaz X egy ország és egyben tagja is(X,"EU ").
Vagyis ebben az esetben az adatok és a szabályok is egyformán jelennek meg, ami nagyon egyszerűen és jól teszi lehetővé a problémák modellezését.
Hol találkoztál a szakmában?: egy egész nagy projekt egy olyan céggel, amely ilyen nyelven ír le lekérdezéseket, valamint a rendszer magjában lévő aktuális projektről - úgy tűnik, ez elég egzotikus dolog, de néha előfordul.
Példa kódrészletre egy logikai nyelvi feldolgozó wikidatában:
Anyagok: Itt adok pár linket a modern logikai programozási nyelvhez, az Answer Set Programming - ajánlom tanulmányozását:
Forrás: will.com