Бележки на специалиста по данни: Персонализиран преглед на езиците за заявка на данни

От личен опит ви казвам кое къде и кога е било полезно. Това е преглед и теза, така че да е ясно какво и къде можете да копаете по-нататък - но тук имам изключително субективен личен опит, може би всичко е съвсем различно за вас.

Защо е важно да знаете и да можете да използвате езици за заявки? В основата си Data Science има няколко важни етапа на работа, като първият и най-важен (без него със сигурност нищо няма да работи!) е получаването или извличането на данни. Най-често данните се намират някъде под някаква форма и трябва да бъдат „извлечени“ от там. 

Езиците за заявки ви позволяват да извличате точно тези данни! И днес ще ви разкажа за тези езици за заявки, които ми бяха полезни и ще ви кажа и покажа къде и как точно - защо е необходимо да се изучава.

Ще има три основни блока от типове заявки за данни, които ще обсъдим в тази статия:

• „Стандартните“ езици за заявки са това, което обикновено се разбира, когато говорим за език за заявки, като релационна алгебра или SQL.
• Скриптови езици за заявки: например, Python неща pandas, numpy или скриптове на shell.
• Езици за заявки за графики на знания и бази данни с графики.

Всичко написано тук е само личен опит, това, което беше полезно, с описание на ситуациите и „защо беше необходимо“ - всеки може да опита как подобни ситуации могат да се случат на пътя ви и да се опита да се подготви за тях предварително, като разбере тези езици ​преди да трябва да кандидатствате (спешно) по проект или дори да стигнете до проект, където са необходими.

"Стандартни" езици за заявки

Стандартните езици за заявки са точно в смисъла, в който обикновено мислим за тях, когато говорим за заявки.

Релационна алгебра

Защо е необходима релационната алгебра днес? За да разберете добре защо езиците за заявки са структурирани по определен начин и да ги използвате съзнателно, трябва да разберете същността, която е в основата им.

Какво е релационна алгебра?

Формалната дефиниция е следната: релационната алгебра е затворена система от операции върху релации в релационен модел на данни. Казано малко по-човешки, това е система от операции върху таблици, така че резултатът винаги да е таблица.

Вижте всички релационни операции в това статия от Habr - тук описваме защо трябва да знаете и къде е полезно.

Защо?

Започването да разбирате какво представляват езиците за заявки и какви операции стоят зад изразите в конкретни езици за заявки често дава по-задълбочено разбиране на това какво работи в езиците за заявки и как.

Взето от това статии. Пример за операция: join, която обединява таблици.

Материали за изследване:

Добър въвеждащ курс от Станфорд. Като цяло има много материали по релационна алгебра и теория - Coursera, Udacity. Има също огромно количество материали онлайн, включително добри академични курсове. Моят личен съвет: трябва много добре да разбирате релационната алгебра - това е основата на основите.

SQL

Взето от това статия.

SQL по същество е имплементация на релационна алгебра - с важно предупреждение, SQL е декларативен! Тоест, когато пишете заявка на езика на релационната алгебра, вие всъщност казвате как да изчислите - но със SQL указвате какво искате да извлечете и тогава СУБД вече генерира (ефективни) изрази на езика на релационната алгебра (техния еквивалентността ни е известна като Теорема на Код).

Взето от това статия.

Защо?

Релационни СУБД: Oracle, Postgres, SQL Server и т.н. все още са почти навсякъде и има невероятно голям шанс да се наложи да взаимодействате с тях, което означава, че или ще трябва да четете 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 - много проучвателни анализи на данни се вписват добре в лаптопи - полезно е да се знае.
• Заявки - работа с мрежата.
• Pyspark е много популярен сред инженерите на данни, най-вероятно ще трябва да взаимодействате с този или Spark, просто поради тяхната популярност.
• *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

Но важната част е, че този код е част от скрипта и конвейера; всъщност ние вграждаме заявки в конвейера на Python. В тази ситуация езикът на заявките идва при нас от библиотеки като Pandas или pySpark.

Като цяло в pySpark виждаме подобен тип трансформация на данни чрез език за заявки в духа на:

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

Къде и какво да чета

На самия Python като цяло не е проблем намерете материали за изучаване. Има огромен брой уроци онлайн панди, pySpark и курсове по Искра (а също и сам по себе си DS). Като цяло съдържанието тук е страхотно за гугъл и ако трябва да избера един пакет, върху който да се съсредоточа, това ще бъдат панди, разбира се. По отношение на комбинацията от DS+Python материали също много.

Shell като език за заявки

Доста проекти за обработка и анализ на данни, с които съм работил, са всъщност шел скриптове, които извикват код в Python, Java и самите шел команди. Следователно, като цяло, можете да разглеждате тръбопроводите в bash/zsh/etc като някакъв вид заявка от високо ниво (можете, разбира се, да поставите цикли там, но това не е типично за DS код в езиците на обвивката), нека дадем прост пример - трябваше да направя QID картографиране на уикиданни и пълни връзки към руските и английските уикита, за това написах проста заявка от командите в bash и за изхода написах прост скрипт в Python, който събрани така:

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")' 

Това всъщност беше целият тръбопровод, който създаде необходимото картографиране; както виждаме, всичко работи в поточен режим:

• pv filepath - дава лента за напредъка въз основа на размера на файла и предава съдържанието му нататък
• unpigz -c прочете част от архива и го даде на jq
• jq с ключа - stream незабавно създаде резултата и го предаде на постпроцесора (същото като в първия пример) в Python
• вътрешно, постпроцесорът беше проста държавна машина, която форматира изхода 

Като цяло сложен конвейер, работещ в режим на поток върху големи данни (0.5TB), без значителни ресурси и направен от прост конвейер и няколко инструмента.

Друг важен съвет: можете да работите добре и ефективно в терминала и да пишете bash/zsh/etc.

Къде ще бъде полезно? Да, почти навсякъде - отново има МНОГО материали за изучаване в интернет. По-специално тук това предишната ми статия.

R скриптове

Отново читателят може да възкликне - ами това е цял програмен език! И разбира се, той ще бъде прав. Обикновено обаче срещах R в такъв контекст, че всъщност беше много подобен на език за заявки.

R е статистическа изчислителна среда и език за статично изчисление и визуализация (според това).

взета следователно. Между другото, препоръчвам го, добър материал.

Защо един учен по данни трябва да знае R? Най-малкото, защото има огромен слой от не-ИТ хора, които анализират данни в 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 ще ви се сторят познати и удобни.

Има много източници за изучаване, напр. това.

Графики на знания

Тук имам малко необичаен опит, защото доста често трябва да работя с графи на знания и езици за заявки за графики. Затова нека накратко да прегледаме основите, тъй като тази част е малко по-екзотична.

В класическите релационни бази данни имаме фиксирана схема, но тук схемата е гъвкава, всеки предикат всъщност е „колона“ и дори повече.

Представете си, че моделирате човек и искате да опишете ключови неща, например, нека вземем конкретен човек, Дъглас Адамс, и да използваме това описание като основа.

www.wikidata.org/wiki/Q42

Ако използвахме релационна база данни, ще трябва да създадем огромна таблица или таблици с огромен брой колони, повечето от които биха били NULL или запълнени с някаква стойност по подразбиране False, например, малко вероятно е много от нас да имат запис в корейската национална библиотека - разбира се, бихме могли да ги поставим в отделни таблици, но това в крайна сметка би било опит за моделиране на гъвкава логическа верига с предикати, използвайки фиксирана релационна.

Представете си, че всички данни се съхраняват като графика или като двоични и унарни булеви изрази.

Къде изобщо можете да срещнете това? Първо, работата с уики даннии с всякакви бази данни с графики или свързани данни.

Следните са основните езици за заявки, които съм използвал и с които съм работил.

SPARQL

Wiki:
SPARQL (рекурсивен акроним от Инж. Протокол SPARQL и език за заявки RDF) - език за заявка на данни, представен от модела RDFИ протокол да предава тези искания и да отговаря на тях. SPARQL е препоръка Консорциум W3C и една от технологиите семантична мрежа.

Но в действителност това е език за заявки за логически унарни и двоични предикати. Вие просто условно определяте какво е фиксирано в булев израз и какво не (много опростено).

Самата RDF (Resource Description Framework) база, върху която се изпълняват SPARQL заявки, е тройна object, predicate, subject - и заявката избира необходимите тройки според посочените ограничения в духа: намерете X, така че p_55(X, q_33) да е вярно - където, разбира се, p_55 е някакъв вид връзка с ID 55, а q_33 е обект с ID 33 (тук и цялата история, като отново пропускаме всякакви подробности).

Пример за представяне на данни:

Снимки и пример с държави тук следователно.

Пример за основна заявка

Всъщност ние искаме да намерим стойността на променливата ?country, така че за предиката
member_of, вярно е, че member_of(?country,q458) и q458 е ID на Европейския съюз.

Пример за истинска SPARQL заявка в двигателя на python:

Обикновено трябваше да чета SPARQL, вместо да го пиша - в тази ситуация вероятно би било полезно умение да разбирам езика поне на основно ниво, за да разбера точно как се извличат данни. 

Има много материали за изучаване онлайн: например тук това и това. Обикновено търся в Google конкретни дизайни и примери и това е достатъчно за сега.

Логически езици за заявки

Можете да прочетете повече по темата в моята статия тук. И тук само накратко ще разгледаме защо логическите езици са много подходящи за писане на заявки. По същество RDF е просто набор от логически изрази във формата p(X) и h(X,Y), а логическата заявка има следната форма:

output(X) :- country(X), member_of(X,“EU”).

Тук говорим за създаване на нов предикат output/1 (/1 означава унарен), при условие че за X е вярно, че country(X) - т.е. X е държава и също така member_of(X,"EU").

Тоест в случая и данните, и правилата са представени по един и същи начин, което ни позволява много лесно и добре да моделираме проблемите.

Къде се срещнахте в индустрията?: цял голям проект с компания, която пише заявки на такъв език, както и върху текущия проект в ядрото на системата - изглежда, че това е доста екзотично нещо, но понякога се случва.

Пример за кодов фрагмент в логически език, обработващ уикиданни:

Материали: Тук ще дам няколко връзки към съвременния език за логическо програмиране Answer Set Programming - препоръчвам да го изучавате:

• http://peace.eas.asu.edu/aaai12tutorial/asp-tutorial-aaai.pdf
• http://ceur-ws.org/Vol-1145/tutorial1.pdf
• https://www.youtube.com/watch?v=gVQ0bP8zyHw
• https://www.youtube.com/watch?v=kdcd7Je2glc
• https://potassco.org/book/
• http://potassco.sourceforge.net/teaching.html
• https://www.cs.uni-potsdam.de/~torsten/Potassco/Tutorials/fmcad12.pdf

Източник: www.habr.com