Po flas nga përvoja ime personale, se ku dhe kur është dashur. Një përmbledhje dhe me theksime, për ta bërë të qartë se çfarë mund të shqyrtoni më tej — por këtu kam vetëm përvojën time subjektive, ndoshta ju do të keni diçka krejtësisht ndryshe.
Pse është e rëndësishme të dini dhe të jeni në gjendje të punoni me gjuhët e kërkesave? Në thelb, në Shkencën e të Dhënave ka disa etapa të rëndësishme në punë dhe më e para dhe më e rëndësishmja (pa të nuk do të funksionojë asgjë!) është mbledhja ose nxjerrja e të dhënave. Shpesh të dhënat ndodhen diku në një formë dhe duhet ‘nxjerrë’ prej andej.
Gjuhet e kërkesave pikërisht lejojnë nxjerrjen e këtyre të dhënave! Dhe sot do të flas për ato gjuhë kërkimesh që më kanë ndihmuar dhe do të tregoj se ku dhe si pikërisht — pse është e nevojshme të mësohet.
Do të ketë tre blloqe të krijuara dhe lloje kërkesash për të dhëna, të cilat do të shqyrtojmë në këtë artikel:
- Gjuha ‘standard’ e kërkesave — ajo që zakonisht kuptohet kur flitet për një gjuhë kërkese, si p.sh., algebra relacional ose SQL.
- Gjuha skriptore e kërkesave: për shembull, gjuhët fantastike të Python-it si pandas, numpy ose skriptimi i shell-it.
- Gjuhet e kërkesave për grafët e njohurive dhe bazat e të dhënave grafike.
Çdo gjë e shkruar këtu është thjesht një eksperiencë personale, ajo që ka qenë e dobishme, me përshkrimin e situatave dhe "pse ka qenë e nevojshme" — secili mund ta provojë se sa të ngjashme mund të ndodhin situata të tilla dhe të përgatitet për to më parë, duke e kuptuar këto gjuhë para se të duhet t'i përdorë ato (në mënyrë urgjente) në një projekt ose madje të shkojë në një projekt ku ato janë të nevojshme.
Gjuhët standarde të pyetjeve
Gjuhët standarde të pyetjeve në atë kuptim, se zakonisht pikërisht për to mendojmë kur flasim për pyetje.
Algebra relacional
Pse na nevojitet sot algebra relacional? Për të pasur një përfaqësim të mirë të asaj që e ndihmon për të kuptuar pse gjuhët e pyetjeve janë të organizuara në një mënyrë të caktuar dhe është e nevojshme të kuptohet thelbi që është në bazë.
Çfarë është algebra relacional?
Përkufizimi formal është: algebra relacional është një sistem i mbyllur operacionesh mbi marrëdhëniet në modelin relacional të të dhënave. Nëse e shikojmë më njerëzisht, është një sistem operacionesh mbi tabela, në mënyrë që rezultati gjithashtu të jetë gjithmonë një tabelë.
Shih të gjitha operacionet relacional në artikulli nga Habr — këtu ne përshkruajmë pse është e nevojshme të dihet dhe ku përdoret.
Pse?
Këtu fillon të kuptosh se çfarë përbëjnë gjuhët e kërkimeve dhe cilat operacione qëndrojnë pas shprehjeve të gjuhëve të caktuara të kërkimeve — zakonisht ofron një kuptim më të thellë të asaj që ndodh dhe si funksionon në gjuhët e kërkimeve.
Marre nga artikulli. Shembulli i operacionit: join, i cili bashkon tabela.
Burime për studim:
. Në përgjithësi, ka shumë materiale mbi algebra relacional dhe teori — Coursera, Udacity. Ka gjithashtu një sasi të madhe materials në internet, përfshirë kurse të mira . Këshilla ime personale: duhet ta kuptoni shumë mirë algebrën relacional — është themeli i gjithçkaje.
SQL
Marre nga të artikullit.
SQL, në thelb, është një implementim i algebrës relacional — me një rezervë të rëndësishme, SQL është deklarativ! Kështu, duke shkruar një kërkesë në gjuhën e algebrës relacional, në fakt thoni se si duhet të llogaritet — ndërsa me SQL, ju përcaktoni se çfarë dëshironi të nxirrni, dhe më pas DBMS gjeneron (efektiv) shprehje në gjuhën e algebrës relacional (ekvivalenca e tyre është e njohur nga ).
Marre nga të artikullit.
Pse?
Baza të dhënash relationale: Oracle, Postgres, SQL Server, etj. janë ende gjerësisht të pranishëm dhe ka një mundësi të madhe që do t'ju duhet të lidheni me to, që do të thotë se do të duhet të lexoni SQL (gjithashtu shumë e mundshme) ose ta shkruani atë (po ashtu, jo e papritur).
Çfarë të lexoni dhe të mësoni
Në të njëjtat lidhje të sipërpërmendura (për algebrën relacional), ka një sasi të jashtëzakonshme materiali, për shembull, .
Meqenëse, çfarë është NoSQL?
«Wshtë e rëndësishme të theksohet se termi “NoSQL” ka një origjinë krejtësisht spontane dhe nuk ka një definicion të njohur për çdo institucion shkencor.» Përkatësisht në Habr.
Në thelb, njerëzit kuptonin se modeli i plotë relational nuk është i nevojshëm për të zgjidhur shumë probleme, sidomos për ata ku, për shembull, performanca është vendimtare dhe disa kërkesa të thjeshta me agregim dominon — aty është kritike të llogaritësh shpejt metrikat dhe t'i shkruash ato në bazë, ndërsa shumica e karakteristikave relacional dukeshin jo vetëm të padobishme, por edhe dëmshme — përse të normalizosh diçka, kur kjo do të prishë atë që është më e rëndësishme për ne (për një detyrë të caktuar) — performancën?
Gjithashtu shpesh janë të nevojshme skemat fleksibile në vend të skemave matematikore fikse të modelit tradicional relacional — dhe kjo e thjeshton dukshëm zhvillimin e aplikacioneve, kur është kritike të përhapim sistemin dhe të fillojmë të punojmë shpejt, duke procesuar rezultatet — ose skema dhe llojet e të dhënave të ruajtur nuk janë aq të rëndësishme.
Për shembull, ne po krijojmë një sistem ekspert dhe duam të ruajmë informacionin mbi një domen të caktuar së bashku me disa meta-informacione — mund të mos e dimë të gjitha fushat dhe thjesht të ruajmë JSON për çdo regjistër — kjo na jep një ambient shumë fleksibël për shtrirjen e modelit të të dhënave dhe iterimin e shpejtë — prandaj në këtë rast, NoSQL do të ishte madje më e preferueshme dhe lexueshme. Një shembull regjistri (nga një nga projektet e mia, ku NoSQL ishte pikërisht aty ku ishte e nevojshme).
{"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}
Mund të lexoni më shumë për NoSQL.
Çfarë të studiojmë?
Këtu është më mirë të analizoni mirë detyrën tuaj, cilat janë veçoritë e saj dhe cilat sisteme NoSQL i përshtaten këtij përshkrimi — dhe pastaj të filloni të studioni këtë sistem.
Gjuha e skriptimit për kërkesa
Së pari, duket se çfarë ka të bëjë Python — është një gjuhë programuese, dhe nuk ka të bëjë fare me kërkesat.
- Pandas është si një thikë shumë funksionale për Shkencën e Të Dhënave, shumë transformime të dhënash, agregime etj. ndodhin në të.
- Numpy — llogaritje vektoriale, matrica dhe algebra lineare aty.
- Scipy — shumë matematikë në këtë paketë, veçanërisht statistikat.
- Jupyter lab — shumë analiza eksploruese të të dhënave që funksionojnë mirë në notebook — është e dobishme të dish.
- Requests — punë me rrjetin.
- Pyspark — shumë popullor mes inxhinierëve të të dhënave, me siguri do t'ju duhet të ndërveproni me këtë ose me Spark, thjesht për shkak të popullaritetit të tyre.
- *Selenium — shumë i dobishëm për mbledhjen e të dhënave nga faqet dhe burimet, ndonjëherë thjesht nuk mund të merrni të dhëna ndryshe.
Këshilli im kryesor: mësoni Python!
Pandas
Le të marrim si shembull kodin e mëposhtëm:
import pandas as pd
df = pd.read_csv(“data/dataset.csv”)
# Llogaritni dhe rinovoni agregimet
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'}))Në thelb, ne shohim se kodi i përshtatet një modeli klasik 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_namePor pjesa e rëndësishme — ky kod është pjesë e skriptit dhe pipeline-it, në të vërtetë ne e integrojmë kërkesat në pipeline-in e Python-it. Në këtë situatë, gjuha e kërkesave na vjen nga libraritë, siç janë Pandas ose pySpark.
Në përgjithësi në pySpark ne shohim një lloj të ngjashëm transformimi të të dhënave përmes gjuhës së kërkesave në shpirtin e:
df.filter(df.trip_type = “return”)
.groupby(“day”)
.agg({duration: 'mean'})
.sort()Ku dhe çfarë të lexojmë
Për Pythonin në përgjithësi të gjejmë materiale për studim. Në rrjet ka një sasi të madhe tutorialesh për , dhe kurse për (si dhe për vetë ). Në përgjithësi, materialet këtu gjenden lehtësisht në Google dhe nëse do të duhet të zgjidhja një paketë, në të cilën do të përqendrohesha — kjo do të ishte pandas, sigurisht. Për lidhjen DS+Python ka shumë materiale gjithashtu. .
Shell si gjuhë e kërkesës
Ka shumë projekte për përpunimin dhe analizimin e të dhënave me të cilat kam punuar — këto janë, në thelb, skripte shell që thërrasin kodin në Python, Java dhe vetë komandat shell. Prandaj, në përgjithësi, mund të merren parasysh pipeline-t në bash/zsh/etc si një kërkesë të nivelit të lartë (sigurisht, mund të shtohen dhe cikle, por kjo nuk është tipike për kodin DS në gjuhët shell), le të sjellim një shembull të thjeshtë — më duheshte të krijoja një mapim të QID nga Wikidata dhe lidhjen e plotë për Wikipedi në rusisht dhe anglisht, për këtë shkrova një kërkesë të thjeshtë nga komandat në bash dhe për të shpallur shkrova një skript të thjeshtë në Python, që i bashkova kështu:
pv “data/latest-all.json.gz” |
unpigz -c |
jq --stream $JQ_QUERY |
python3 scripts/post_process.py "output.csv"
ku
JQ_QUERY = 'select((.[0][1] == "sitelinks" and (.[0][2]=="enwiki" or .[0][2]=="ruwiki") and .[0][3] =="title") or .[0][1] == "id")' Ky ishte, në thelb, i gjithë pipeline-i që krijonte mapimin e nevojshëm; siç e shohim, gjithçka funksiononte në modin e rrjedhës:
- pv filepath — дает прогресс бар на основе размера файла и передает его содержимое дальше
- unpigz -c читал часть архива и отдавал jq
- jq с ключом — stream сразу выдавал результат и передавал его постпроцессору (так же как и с самым первым примером) на питоне
- внутри постпроцессор — это простая машина состояний, которая форматировала вывод
Итого сложный пайплайн работающий в режиме потока на больших данных (0.5TB), без существенных ресурсов и сделан из простого пайплайна и пары тулзов.
Еще один важный совет: умейте хорошо и эффективно работать в терминале и писать на bash/zsh/etc.
Где пригодится? Да почти везде — материалов для изучения опять же ОЧЕНЬ много в сети. В частности, вот моя предыдущая статья.
R scripting
Опять же читатель может воскликнуть — ну это же целый язык программирования! И конечно же, будет прав. Однако, обычно мне приходилось сталкиваться с R всегда в таком контексте, что, по сути, это было очень похоже на язык запросов.
R — это среда статистических вычислений и язык статических вычислений и визуализации (согласно ).
Взято . Кстати, рекомендую, неплохой материал.
Pse duhet një data scientist të dijë R? Të paktën, sepse ekziston një numër i madh njerëzish jashtë IT-së që merren me analizën e të dhënave në R. Kam hasur në këto vende:
- Sektori farmaceutik.
- Biologët.
- Sektori financiar.
- Njerëz të arsimuar vetëm në matematikë që merret me statistikat.
- Modele statistikore të specializuara dhe modele të mësimit të makinerisë (të cilat shpesh gjenden vetëm në versionin autorit si paketë R).
Pse kjo është në fakt një gjuhë kërkese? Në formën në të cilën shpesh paraqitet — kjo në të vërtetë është një kërkesë për krijimin e një modeli, duke përfshirë leximin e të dhënave dhe rregullimin e parametrave të kërkesës (modeleve), si dhe vizualizimin e të dhënave në paketa si ggplot2 — kjo është gjithashtu një formë e shkruar e kërkesave.
Shembuj kërkesash për vizualizim
ggplot(data = beav,
aes(x = id, y = temp,
group = activ, color = activ)) +
geom_line() +
geom_point() +
scale_color_manual(values = c("red", "blue"))Në përgjithësi, shumë ide nga R kanë kaluar në paketat python, si pandas, numpy ose scipy, si dataframe dhe vektorizimi i të dhënave — prandaj shumë gjëra në R do t'ju duken të njohura dhe të përshtatshme.
Burime për të mësuar ka shumë, për shembull, .
Grafikët e njohurive (Knowledge graph)
Këtu kam një përvojë të pakët të zakonshme, sepse më shpesh më pengon të punoj me grafet e njohurisë dhe gjuhët e kërkesave ndaj grafëve. Prandaj, le të kalojmë shpejt mbi bazat, pasi kjo pjesë është pak më ekzotike.
Në bazat klasike relacional, kemi një skemë të rregullt — këtu skema është fleksibile, çdo predikat është në thelb një ‘kolonë’ dhe madje më shumë.
Imagjinoni se do të modelonit një person dhe do të donit të përshkruani gjëra kyçe; për shembull, le të marrim një person konkret, Douglas Adams, dhe do të bazohemi në këtë përshkrim.
Nëse do të kishim përdorur një bazë relacional, do të kishim duhur të krijonim një tabelë të madhe ose tabela të mëdha me një numër të madh kolonash, shumica prej të cilave do të ishin NULL ose të mbushura me ndonjë vlerë të defoltit False, për shembull, në dyshim se shumë prej nesh kanë një regjistër në bibliotekën kombëtare koreane — sigurisht, mund të kishim separuar ato në tabela të veçanta, por kjo në fund do të ishte përpjekje për të modeluar një skemë logjike fleksibile me predikate, duke përdorur një relacional të rregullt.
Prandaj imagjinoni se të gjitha të dhënat ruhen si një grafo apo si shprehje logjike binare dhe uniare.
Ku mund ta hasni këtë? Së pari, duke punuar me , për të mirën e çdo baze të dhënash grafi ose të dhënash të lidhura.
Më poshtë janë gjuhët kryesore të kërkimeve që kam qenë e detyruar të aplikoj dhe me të cilat kam punuar.
SPARQL
Wiki:
SPARQL ( nga SPARQL Protocol and RDF Query Language) — , të paraqitura sipas modelit , si dhe për të transmetuar këto kërkesa dhe përgjigje mbi to. SPARQL është një rekomandim i dhe një nga teknologjitë .
Në të vërtetë, kjo është një gjuhë kërkimesh për predikate logjike uniare dhe binare. Thjesht tregohet se çfarë është e fiksuar në shprehjen logjike dhe çfarë nuk është (shumë thjesht).
Baza e vetë RDF (Resource Description Framework), mbi të cilën kryhen kërkesat SPARQL — është një trio objekt, predikate, subjekt. — dhe kërkesa zgjedh trejat e nevojshme sipas kufizimeve të caktuara, si: gjej një X, të tillë që p_55(X, q_33) është e vërtetë — ku, sigurisht, p_55 është një marrëdhënie me ID 55, dhe q_33 është një objekt me ID 33 (kjo është e gjithë historia, duke lënë mënjanë detaje të ndryshme).
Shembulli i prezantimit të të dhënave:
Imazhe dhe shembuj me vende këtu .
Shembulli i kërkesës bazë
Në fakt, ne duam të gjejmë vlerën e ndryshores ?country, të tillë që për predikatin
member_of, është e vërtetë që member_of(?country,q458), ndërsa q458 është ID e Bashkimit Evropian.
Shembulli i një kërkese SPARQL të vërtetë brenda motorit python:
Në përgjithësi, më ka ndodhur të lexoj SPARQL, e jo ta shkruaj — në një situatë të tillë, me siguri do të ishte një aftësi e dobishme të kuptosh gjuhën, të paktën në një nivel bazik, për të kuptuar si janë nxjerrë të dhënat.
Ka shumë materiale online për të mësuar: për shembull, këtu dhe . Unë zakonisht kërkoj në Google për struktura dhe shembuj specifikë dhe deri tani mjafton.
Gjuhët logjike të kërkesave
Më shumë rreth temës mund të lexoni në artikullin tim . Në këtë pjesë, ne do të përmendim shkurtimisht pse gjuhët logjike janë të përshtatshme për shkrimin e kërkesave. Në thelb, RDF është thjesht një koleksion i deklaratave logjike si p(X) dhe h(X,Y), ndërsa kërkesa logjike ka këtë formë:
output(X) :- country(X), member_of(X,"EU").
Këtu po flasim për krijimin e një predikati të ri output/1 (/1 do të thotë njëanshëm), me kushte që për X është e vërtetë që country(X) — dmth, X është një vend dhe gjithashtu member_of(X,"EU").
Pra, në këtë rast, të dhënat dhe rregullat janë të paraqitura në të njëjtën mënyrë, çka lejon modelimin e lehtë dhe efikas të detyrave.
Ku janë takuar në industri: një projekt i madh me një kompani që shkruan kërkesa në atë gjuhë, si dhe në projektin aktual në bërthamën e sistemit — duket se është diçka shumë ekzotike, megjithatë ndonjëherë ndodh.
Një shembull i një fragmendi kodi në gjuhën logjike që përpunon wikidata:
Burimet: do të përmend disa lidhje për gjuhën moderne të programimit të logjikës Answer Set Programming — rekomandoj të studiohet pikërisht ajo:
Burimi: habr.com
