🥇Бележки на дата учен: личен обзор на езици за запитвания към данни

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

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

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

В статията ще разгледаме три основни блока типове заявки за данни:

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

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

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

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

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

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

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

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

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

Защо?

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

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

Материали за изучаване:

Добър въводен курс от Станфорд. Всъщност, материалите по релационна алгебра и теория са изключително много — Сoursera, 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 lab - много изследователски анализ на данни, което добре се вписва в ноутбуците - полезно е да го умеете.
Requests - работа с мрежата.
Pyspark - много популярен сред инженерите на данни, вероятно ще ви се наложи да взаимодействате с него или Spark, просто поради тяхната популярност.
*Selenium - много полезен за събиране на данни от сайтове и ресурси, понякога просто по друг начин не може да се получат данните.

Моят основен съвет: учете Python!

Pandas

Нека вземем следния код за пример:

import pandas as pd
df = pd.read_csv("data/dataset.csv")
# Изчислете и преименувайте агрегациите
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'
GROUP BY start_station_name, end_station_name

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

Общо взето, в pySpark виждаме сходен тип трансформация на данни чрез езика на заявките:

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

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

За самия Пайтон изобщо няма проблем да се намерят материали за изучаване. В интернет има огромно количество туториали по pandas, pySpark и курсове по Spark (както и за самия DS). Въобще материалите се намират изключително лесно и ако трябваше да избера един пакет, на който да се фокусирам — това със сигурност щеше да бъде pandas. По свързването DS+Python материалите също са наистина много.

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

Няма малко проекти за обработка и анализ на данни, с които ми се е налагало да работя — това, по същество, са shell скриптове, които извикват код на Пайтон, на Java и самите shell команди. Затова в общи линии можем да разглеждаме пайплайните в bash/zsh/ и др. като вид високоуровнева заявка (разбира се, може да се включат и цикли, но това не е типично за DS код на shell езиците), ето един прост пример — трябваше ми да направя мапинг на QID от Викиданни и пълната връзка към руската и английската вики, за това написах проста заявка от команди в bash и за извода написах прост скрипт на Пайтон, който събрах заедно така:

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 веднага издаваше резултата и го предаваше на постпроцесора (както и при най-първия пример) на Пайтон
вътре постпроцесорът — това е проста машина за състояния, която форматираше извода

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

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

Къде ще се приложи? Почти навсякъде — материалите за изучаване отново са ОГРОМНО количество в мрежата. В частност, ето това моята предишна статия.

R програмиране

Отново читателят може да възкликне — но това е цял език за програмиране! И естествено, ще бъде прав. Въпреки това, обикновено ми се е налагало да се сблъсквам с 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)

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

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

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

www.wikidata.org/wiki/Q42

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

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

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

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

SPARQL

Wiki:
SPARQL (рекурсивен акроним от англ. SPARQL Protocol and RDF Query Language) — език за заявки към данни, представени по модела RDF, както и протокол за предаване на тези заявки и отговори на тях. SPARQL е препоръка на консорциума W3C и една от технологиите на семантичната мрежа..

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

Самата база RDF (Resource Description Framework), върху която се изпълняват SPARQL заявки, е тройка обект, предикат, субект — и заявката избира нужните тройки по указани ограничения в духа: намерете такъв 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").

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

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

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