Расказваю з асабістага досведу, што дзе і калі спатрэбілася. Аглядна і тэзісна, каб зразумела было, што і куды можна капаць далей - але тут у мяне выключна суб'ектыўны асабісты вопыт, у вас, можа быць, усё зусім па-іншаму.
Чаму важна ведаць і ўмець абыходзіцца з мовамі запытаў? Па сваёй сутнасці ў Data Science ёсць некалькі найважнейшых этапаў працы і самы першы і найважнейшы (без яго ўжо сапраўды нічога працаваць не будзе!) - гэта атрыманне або выманне дадзеных. Часцей за ўсё дадзеныя ў нейкім выглядзе недзе сядзяць і іх трэба адтуль "дастаць".
Мовы запытаў як раз і дазваляюць гэтыя самыя дадзеныя атрымаць! І сёння я раскажу, пра тыя мовы запытаў, якія мне спатрэбіліся і раскажу-пакажу, дзе і як менавіта — навошта яно патрэбна для вывучэння.
Усяго будзе тры асноўныя блокі тыпаў запытаў да дадзеных, якія мы разбяром у дадзеным артыкуле:
- "Стандартныя" мовы запытаў - тое, што звычайна разумеюць, калі кажуць пра мову запытаў, як, напрыклад, рэляцыйная алгебра або SQL.
- Скрыптовыя мовы запытаў: напрыклад, пітонаўскія штучкі pandas, numpy ці shell scripting.
- Мовы запытаў да графаў ведаў і графавых баз даных.
Усё напісанае тут - гэта проста персанальны вопыт, што спатрэбілася, з апісаннем сітуацый і "навошта яно было патрэбна" - кожны можа прымерыць, наколькі падобныя сітуацыі могуць сустрэцца вам і паспрабаваць падрыхтавацца да іх загадзя, разабраўшыся з гэтымі мовамі да таго, як прыйдзецца іх у (тэрміновым парадку) прымяняць на праекце або ўвогуле трапіць на праект, дзе яны патрэбны.
"Стандартныя" мовы запытаў
Стандартныя мовы запытаў менавіта ў тым плане, што звычайна мы менавіта пра іх і думаем, калі гаворым пра запыты.
Рэляцыйная алгебра
Навошта сёння патрэбная рэляцыйная алгебра? Для таго каб мець добрае ўяўленне, чаму мовы запытаў уладкованыя вызначанай выявай і свядома іх выкарыстоўваць трэба разабрацца з ядром, ляжалым у аснове.
Што такое рэляцыйная алгебра?
Фармальнае вызначэнне такое: рэляцыйная алгебра - замкнёная сістэма аперацый над адносінамі ў рэляцыйнай мадэлі дадзеных. Калі крыху больш па-чалавечы, гэта сістэма аперацый над табліцамі, такая што вынікам таксама заўсёды з'яўляецца табліца.
Глядзіце ўсе рэляцыйныя аперацыі ў артыкуле з Хабра - тут жа мы апісваем, навошта трэба ведаць і дзе спатрэбіцца.
Навошта?
Пачынаеш разумець, на што ўвогуле складаюцца мовы запытаў і якія аперацыі стаяць за выразамі канкрэтных моў запытаў — часта дае больш глыбокае разуменне таго, што і як працуе ў мовах запытаў.
Узята з артыкулы. Прыклад аперацыі: join, які аб'ядноўвае табліцы.
Матэрыялы для вывучэння:
. Наогул, матэрыялаў па рэляцыйнай алгебры і тэорыі вельмі шмат – Сoursera, Udacity. Ёсць таксама вялікая колькасць матэрыялаў анлайн, у тым ліку добрых . Мая персанальная рада: трэба разумець рэляцыйную алгебру вельмі добрае — гэта аснова асноў.
SQL
Узята з артыкулы.
SQL - гэта, па сутнасці, імплементацыя рэляцыйнай алгебры - з важнай агаворкай, SQL - дэкларатыўны! Гэта значыць запісваючы запыт на мове рэляцыйнай алгебры, вы фактычна кажаце, як трэба лічыць – а вось з SQL вы задаяце, што жадаеце атрымаць, а далей СКБД ужо генеруе (эфектыўнае) выразы на мове рэляцыйнай алгебры (іх эквівалентнасць вядомая нам пад ).
Узята з артыкулы.
Навошта?
Рэляцыйныя СКБД: Oracle, Postgres, SQL Server, etc – па-ранейшаму фактычна паўсюль і неверагодна вялікі шанец таго, што вам давядзецца з імі ўзаемадзейнічаць, а гэта азначае, што прыйдзецца альбо чытаць SQL (што вельмі верагодна), альбо пісаць на ім ( таксама не малаверагодна).
Што чытаць і вывучаць
Па тых жа спасылках вышэй (пра рэляцыйную алгебру), ёсць неверагодная колькасць матэрыялу, напрыклад, .
Дарэчы, а што такое NoSQL?
"Варта яшчэ раз падкрэсліць, што тэрмін "NoSQL" мае абсалютна стыхійнае паходжанне і не мае агульнапрызнанага вызначэння або навуковай установы за спіной." Адпаведная на Хабры.
Па сутнасці, людзі зразумелі, што поўная рэляцыйная мадэль не патрэбна для вырашэння многіх задач, асабліва для тых, дзе, напрыклад, прынцыповая прадукцыйнасць і дамінуюць пэўныя простыя запыты з агрэгацыяй - там крытычна хутка лічыць метрыкі і пісаць іх у базу, а большасць фіч рэляцыйнай апынуліся не толькі не патрэбныя, але і шкодныя - навошта нармалізоўваць нешта, калі гэта будзе псаваць самае важнае для нас (для некаторай канкрэтнай задачы) - прадукцыйнасць?
Таксама часта патрэбныя гнуткія схемы замест фіксаваных матэматычных схем класічнай рэляцыйнай мадэлі – і гэта неверагодна спрашчае распрацоўку прыкладанняў, калі крытычна разгарнуць сістэму і пачаць працаваць хутка, апрацоўваючы вынікі – ці схема і тыпы захоўваемых дадзеных не так ужо і важныя.
Напрыклад, мы ствараем экспертную сістэму і жадаем захоўваць інфармацыю па вызначаным дамене разам з некаторай метаінфармацыяй - мы можам і не ведаць усіх палёў і банальна захоўваць JSON для кожнага запісу - гэта дае нам вельмі гнуткае асяроддзе для пашырэння мадэлі дадзеных і хуткага итерирования - таму ў такім выпадку NoSQL будзе нават пераважней і чытэльны. Прыклад запісу (з аднаго майго праекту, дзе NoSQL быў прамы тамака, дзе трэба).
{"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}
Падрабязней можна прачытаць пра NoSQL.
Што вывучаць?
Тут хутчэй трэба быць проста добра прааналізаваць сваю задачу, якія ў яе ўласцівасці і якія маюцца NoSQL сістэмы, які б падыходзілі пад гэтае апісанне – і ўжо займацца вывучэннем дадзенай сістэмы.
Скрыптовыя мовы запытаў
Спачатку, здаецца, прычым тут наогул Python – гэта мова праграмавання, а не пра запыты зусім.
- Pandas - гэта прамы швейцарскі нож Data Science, вялікая колькасць трансфармацыі дадзеных, агрэгацыі і тд адбываецца ў ім.
- Numpy - вектарныя вылічэнні, матрыцы і лінейная алгебра там.
- Scipy - шмат матэматыкі ў пакеце гэтым, асабліва статы.
- Jupyter lab - шмат exploratory data analysis добра ўпісваецца ў наўтбукі - карысна ўмець.
- Requests - праца з сеткай.
- Pyspark – вельмі папулярныя сярод інжынераў дадзеных, хутчэй за ўсё, вам давядзецца ўзаемадзейнічаць з гэтай альбо і спаркам, проста ў сілу іх папулярнасці.
- *Selenium - вельмі карысны для збору дадзеных сайтаў і рэсурсаў, часам проста па-іншаму дадзеныя ніяк не атрымаць.
Мая галоўная рада: вучыце Python!
Панды
Возьмем у якасці прыкладу наступны код:
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'}))Па сутнасці, мы бачым, што код упісваецца ў класічны 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Але важная частка — гэты код з'яўляецца частка скрыпту і пайплайну, фактычна мы ўбудоўваем запыты ў Пітонаўскі пайплайн. У дадзенай сітуацыі мова запытаў да нас прыходзіць з бібліятэк, такіх як Pandas ці pySpark.
У цэлым у pySpark мы бачым падобны тып трансфармацыі дадзеных праз мову запытаў у духу:
df.filter(df.trip_type = “return”)
.groupby(“day”)
.agg({duration: 'mean'})
.sort()Дзе і што пачытаць
Па самім пітону наогул знайсці матэрыялы для вывучэння. У сетцы велізарная колькасць цьютарыялаў па , і курсаў па (а таксама па самому ). У цэлым тут матэрыялы пышна гугляцца і калі б мне трэба было абраць адзін пакет, на якім варта сфакусавацца - то гэта быў бы pandas, вядома. Па звязку DS+Python матэрыялаў таксама .
Shell як мова запытаў
Нямала праектаў па апрацоўцы і аналізу дадзеных, з якімі мне даводзілася працаваць – гэта, па сутнасці, shell скрыпты, якія выклікаюць код на пітон, на java і ўласна самі shell каманды. Таму ў цэлым можна разглядаць пайплайны ў баше/zsh/etc, як некаторы высокаўзроўневы запыт (можна туды, вядома, і цыклы запіхаць, але гэта нетыпова для DS кода на шелл мовах), прывядзем просты прыклад – мне трэба было зрабіць мапінг QID вікідаты і поўнай спасылкі на рускую і ангельскую вікі, для гэтага я напісаў просты запыт з каманд у вежы і для высновы напісаў просты скпрыт на пітоне, якія я сабраў разам вось так:
pv “data/latest-all.json.gz” |
unpigz -c |
jq --stream $JQ_QUERY |
python3 scripts/post_process.py "output.csv"
дзе
JQ_QUERY = 'select((.[0][1] == "sitelinks" and (.[0][2]=="enwiki" or .[0][2] =="ruwiki") and .[0][3] =="title") or .[0][1] == "id")' Гэта быў, па сутнасці, увесь пайплайн, які ствараў патрэбны mapping, як мы бачым усё, працавала ў рэжыме патоку:
- pv filepath - дае прагрэс бар на аснове памеру файла і перадае яго змесціва далей
- unpigz -c чытаў частку архіва і аддаваў jq
- jq з ключом - stream адразу выдаваў вынік і перадаваў яго постпрацэсару (гэтак жа як і з самым першым прыкладам) на пітоне
- унутры постпрацэсар – гэта простая машына станаў, якая фарматавала выснову
Разам складаны пайплайн які працуе ў рэжыме струменя на вялікіх дадзеных (0.5TB), без істотных рэсурсаў і зроблены з простага пайплайна і пары тулзаў.
Яшчэ адна важная рада: умейце добра і эфектыўна працаваць у тэрмінале і пісаць на bash/zsh/etc.
Дзе спатрэбіцца? Ды амаль усюды - матэрыялаў для вывучэння зноў жа ВЕЛЬМІ шмат у сеткі. У прыватнасці, вось мой папярэдні артыкул.
R scripting
Ізноў жа чытач можа выклікнуць – ну гэта ж цэлая мова праграмавання! І вядома ж, мае рацыю. Аднак, звычайна мне даводзілася сутыкацца з R заўсёды ў такім кантэксце, што, па сутнасці, гэта было вельмі падобна да мовы запытаў.
R - гэта асяроддзе статыстычных вылічэнняў і мова статычных вылічэнняў і візуалізацыі (згодна ).
Узята . Дарэчы, рэкамендую, нядрэнны матэрыял.
Навошта дата саентысту ведаць R? Прынамсі, таму што ёсць вялізны пласт людзей не з IT, якія займаюцца аналізам дадзеных на R. Мне сустракалася ў наступных месцах:
- Фармацэўтычны сектар.
- Біёлагі.
- Фінансавы сектар.
- Людзі з чыста матэматычнай адукацыяй, якія займаюцца статамі.
- Спецыялізаваныя статыстычныя мадэлі і мадэлі машыннага навучання (якія часта можна знайсці толькі ў аўтарскай версіі ў выглядзе R пакета).
Чаму гэта фактычна мова запытаў? У тым выглядзе, у якім ён часта сустракаецца – гэта фактычна запыт на стварэнне мадэлі, у тым ліку чытанне дадзеных і фіксаванне параметраў запыту (мадэлі), а таксама візуалізацыя дадзеных у такіх пакетах як ggplot2 – гэта таксама форма напісання запытаў.
Прыклад запытаў для візуалізацыі
ggplot(data = beav,
aes(x = id, y = temp,
group = activ, color = activ)) +
geom_line() +
geom_point() +
scale_color_manual(values = c("red", "blue"))У цэлым шматлікія ідэі з R перавандравалі ў пакеты python, такія як pandas, numpy ці scipy, як датафрэймы і вектарызацыі дадзеных - таму ў цэлым вельмі шматлікія рэчы ў R здадуцца вам знаёмымі і зручнымі.
Крыніц для вывучэння шмат, напрыклад, .
Графы ведаў (Knowledge graph)
Тут у мяне ледзь незвычайны досвед, таму што мне ткі даволі часта даводзіцца працаваць з графамі ведаў і мовы запытаў да графаў. Таму толькі коратка пройдземся па асновах, дык гэтая частка крыху больш за экзатычная.
У класічных рэляцыйных базах у нас фіксаваная схема - тут жа схема гнуткая, кожны прэдыкатаў - гэта фактычна «калонка» і нават больш.
Уявіце, што вы б мадэлявалі чалавека і хацелі апісаць ключавыя рэчы, для прыкладу возьмем канкрэтнага чалавека Дугласа Адамса, за аснову возьмем вось гэтае апісанне.
Калі б мы выкарыстоўвалі рэляцыйную базу, нам бы прыйшлося стварыць велізарную табліцу ці табліцы з велізарнай колькасцю калонак, вялікая частка з якіх бы была NULL або запоўненая нейкім дэфолтным False значэннем, напрыклад, ці наўрад у шматлікіх з нас ёсць запіс у нацыянальнай карэйскай бібліятэцы. - Вядома, мы маглі б выносіць іх у асобныя табліцы, але гэта б у канчатковым выніку была б спроба змадэляваць гнуткую лагічную схему з прэдыкатаў, з дапамогай фіксаванай рэляцыйнай.
Таму ўявіце сабе, што ўсе дадзеныя захоўваюцца ў выглядзе графа ці ў выглядзе бінарных і ўнарных лагічных выразаў.
Дзе вы ўвогуле можаце з такім сутыкнуцца? Па-першае, працуючы з , ды і з любымі графавымі базамі дадзеных ці сувязнымі дадзенымі.
Далей ідуць асноўныя мовы запытаў, якія мне даводзілася ўжываць і з якімі даводзілася працаваць.
SPARQL
Wiki:
SPARQL ( ад Пратакол SPARQL і мова запытаў RDF) - , прадстаўленым па мадэлі , а таксама для перадачы гэтых запытаў і адказаў на іх. SPARQL з'яўляецца рэкамендацыяй і адной з тэхналогій .
А рэальна гэта мова запытаў да лагічных унарных і бінарных прэдыкатаў. Вы проста ўмоўна паказваецца, што з'яўляецца фіксаваным у лагічным выразе, а што не (вельмі спрошчана).
Сама база RDF (Resource Description Framework), над якой выконваюцца SPARQL запыты – гэта тройка. object, predicate, subject - і запыт выбірае патрэбныя тройкі па ўказаных абмежаваннях у духу: знайсці такі X, што p_55(X, q_33) дакладна - дзе, зразумела, p_55 - гэта нейкае стаўленне з айди 55, а q_33 - гэта аб'ект з айди 33 (вось і ўвесь сказ, зноў жа апускаючы разнастайныя дэталі).
Прыклад прадстаўлення даных:
Малюнкі і прыклад з краінамі вось .
Прыклад базавага запыту
Фактычна мы хочам знайсці значэнне зменнай? country, такі што для прэдыката
member_of, дакладна, што member_of(?country,q458), а q458 - гэта ID еўрапейскага саюза.
Прыклад рэальнага запыту SPARQL ўнутры рухавічка python:
Як правіла, мне даводзілася чытаць SPARQL, а не пісаць – у такой сітуацыі, хутчэй за ўсё, гэта будзе карысным навыкам разумець мову хаця б на базавым узроўні, каб зразумець, як менавіта здабываюцца дадзеныя.
Анлайн шмат матэрыялаў для вывучэння: напрыклад, вось и . Сам звычайна гуглю пэўныя канструкцыі і прыклады і пакуль хапае.
Лагічныя мовы запытаў
Падрабязней па тэме можна прачытаць у маім артыкуле . А тут мы толькі коратка разбяром, чаму лагічныя мовы добра падыходзяць для напісання запытаў. У сутнасці, RDF гэта проста набор выгляду лагічных сцвярджэнняў выгляду p(X) і h(X,Y), а лагічны запыт мае наступны выгляд:
output(X) :- country(X), member_of(X,“EU”).
Тут мы кажам, аб стварэнні новага прэдыката output/1 (/1 - значыць унарны), пры ўмове, што для X дакладна, што country(X) - г.зн., Х - гэта краіна і таксама member_of(X,“EU ”).
Гэта значыць, у нас і дадзеныя, і правілы ў такім выпадку прадстаўлены наогул аднолькава, што дазваляе вельмі лёгка і добра мадэляваць задачы.
Дзе сустракаліся ў індустрыі: цэлы вялікі праект з кампаніяй, якая піша на такой мове запыты, а таксама на бягучым праекце ў ядры сістэмы - здавалася б, рэч даволі экзатычная, аднак часам сустракаецца.
Прыклад фрагмента кода на лагічнай мове, які апрацоўвае wikidata:
Матэрыялы: прывяду тут парачку спасылак на сучасную лагічную мову праграмавання Answer Set Programming – рэкамендую вывучаць менавіта яго:
Крыніца: habr.com