Ky Ă«shtĂ« njĂ« artikull i pĂ«rkthyer nga artikulli im nĂ« medium â , qĂ« rezultoi tĂ« ishte mjaft popullor, ndoshta pĂ«r shkak tĂ« thjeshtĂ«sisĂ« sĂ« tij. Prandaj, vendosa ta shkruaj nĂ« shqip dhe ta pasuroj pak, nĂ« mĂ«nyrĂ« qĂ« njĂ« person i zakonshĂ«m, i cili nuk Ă«shtĂ« specialist nĂ« punĂ«n me tĂ« dhĂ«na, tĂ« kuptojĂ« se çfarĂ« Ă«shtĂ« njĂ« depo tĂ« dhĂ«nash (DW), çfarĂ« Ă«shtĂ« njĂ« liqen tĂ« dhĂ«nash (Data Lake), dhe si bashkĂ«jetojnĂ« ato sĂ« bashku.
Pse vendosa të shkruaj për liqenin e të dhënave? Kam punuar me të dhëna dhe analizë për më shumë se 10 vjet, dhe tani po punoj me të dhëna të mëdha në Amazon Alexa AI në Kembrixh, që ndodhet në Boston, ndonëse unë vetë jetoj në Viktori në ishullin Vancouver dhe shpesh vizitoj Bostonin, Siattlin dhe Vancouverin, dhe ndonjëherë madje edhe në Moskë për të folur në konferenca. Gjithashtu, nga koha në kohë shkruaj, por kryesisht në anglisht, dhe kam shkruar tashmë , gjithashtu kam një nevojë për të ndarë trendet e analizës nga Amerika e Veriut dhe ndonjëherë shkruaj në .
Kam punuar gjithmonë me depo të dhënash, dhe që nga viti 2015 kam filluar të punoj ngushtë me Amazon Web Services, madje kam kaluar në analizën cloud (AWS, Azure, GCP). Kam vëzhguar evolucioni i zgjidhjeve për analizë që nga viti 2007 dhe madje kam punuar te një ofrues depo të dhënash, Teradata, dhe e kam implementuar atë në Sberbank, kur atëherë nisi era e Big Data me Hadoop. Të gjithë filluan të thonë se era e depozita përfundoi dhe tani gjithçka është në Hadoop, dhe më vonë filluan të flisnin për Data Lake, sërish duke thënë se tani me siguri i ka ardhur fundi depozitës së të dhënave. Por për fat të mirë (ndoshta për disa fatkeqësi, ata që fitonin shumë para nga konfigurimi i Hadoop), depozitë e të dhënave nuk iku.
Në këtë artikel do të shqyrtojmë se çfarë është një liqen të dhënash. Artikulli është i destinuar për njerëzit, të cilët kanë pak përvojë me depo të dhënash ose nuk kanë fare.
NĂ« imazh Ă«shtĂ« liqeni Bled, njĂ« nga liqenet e mia tĂ« preferuara, ndonĂ«se kam qenĂ« aty vetĂ«m njĂ«herĂ«, por e mbajta mend gjatĂ« gjithĂ« jetĂ«s. Por ne do tĂ« flasim pĂ«r njĂ« tip tjetĂ«r liqeni â liqeni i tĂ« dhĂ«nave. Ndoshta shumĂ« prej jush kanĂ« dĂ«gjuar tashmĂ« kĂ«tĂ« term, por njĂ« pĂ«rcaktim tjetĂ«r nuk do tĂ« dĂ«mtonte askĂ«nd.
Para së gjithash, ja përcaktimet më të njohura të Liqenit të Të Dhënave:
«depo e skedarĂ«ve tĂ« tĂ« gjitha llojeve tĂ« tĂ« dhĂ«nave tĂ« papĂ«rpunuara, qĂ« janĂ« tĂ« arritshme pĂ«r analizĂ« nga kushdo nĂ« organizatë» â Martin Fowler.
«NĂ«se mendoni se njĂ« liqen tĂ« dhĂ«nash Ă«shtĂ« si njĂ« shishe uji â tĂ« pastruar, tĂ« paketuar dhe tĂ« ndarĂ« pĂ«r pĂ«rdorim tĂ« pĂ«rshtatshĂ«m, atĂ«herĂ« liqeni i tĂ« dhĂ«nave Ă«shtĂ« njĂ« rezervuar i madh me ujĂ« nĂ« formĂ«n e tij natyrore. PĂ«rdoruesit mund tĂ« marrin ujĂ« pĂ«r veten, tĂ« zhytin thellĂ«, tĂ« eksplorojnë» â James Dickson.
Tani ne e dimë saktësisht se liqeni i të dhënave është për analizën, ai na lejon të ruajmë sasi të mëdha të dhënash në formën e tyre origjinale dhe kemi akses të nevojshëm dhe të përshtatshëm në të dhënat.
Unë shpesh e dua ta thjeshtoj gjërat, nëse mund të përshkruaj një term të ndërlikuar me fjalë të thjeshta, do të thotë se e kam kuptuar si funksionon dhe për çfarë është e nevojshme. Njëherë, duke përshkruar në iPhone në galerinë e fotografive, më erdhi ndriçimi, kështu që është një liqen të dhënash i vërtetë, madje bëra një slajd për konferenca:
E gjithçka është shumë e thjeshtë. Ne bëjmë një fotografi me telefon, fotografia ruhet në telefon dhe mund të ruhet në iCloud (ruajtja e skedarëve në re). Gjithashtu, telefoni grumbullon metadata të fotografisë: çfarë është e paraqitur, gjeoetiketa, koha. Si rezultat, ne mund të përdorim ndërfaqen e përshtatshme të iPhone për të gjetur fotografinë tonë dhe madje shohim treguesit, për shembull, kur kërkoj fotografitë me fjalën zjarr (fire), unë gjej 3 fotografi me imazhin e zjarrit. Për mua, është thjesht si një mjet Business Intelligence që funksionon shumë shpejt dhe saktë.
Dhe sigurisht, nuk duhet të harrojmë për sigurinë (autorizimin dhe autentikimin), përndryshe të dhënat tona mund të përfundojnë lehtësisht në akses të hapur. Ka shumë lajme për korporata të mëdha dhe startup-e, të cilat të dhënat e tyre përfunduan në akses të hapur për shkak të neglizhencës së zhvilluesve dhe mosrespektimit të rregullave të thjeshta.
Madje një imazh kaq i thjeshtë na ndihmon të kuptojmë se çfarë është një liqen të dhënash, dallimet e tij nga magazina tradicionale e të dhënave dhe elementet e tij kryesore:
- Ngarkimi i tĂ« dhĂ«nave (Ingestion) â komponenti kyç i liqenit tĂ« tĂ« dhĂ«nave. TĂ« dhĂ«nat mund tĂ« futen nĂ« magazinĂ«n e tĂ« dhĂ«nave nĂ« dy mĂ«nyra â batch (ngarkesĂ« me intervale) dhe streaming (rrjedhĂ« tĂ« dhĂ«nash).
- Ruajtja e skedarĂ«ve (Storage) â komponenti kryesor i Liqenit tĂ« TĂ« DhĂ«nave. Na nevojitet qĂ« magazina tĂ« jetĂ« e lehtĂ« pĂ«r t'u zgjeruar, jashtĂ«zakonisht e besueshme dhe me kosto tĂ« ulĂ«t. PĂ«r shembull, nĂ« AWS kjo Ă«shtĂ« S3.
- Katalogu dhe KĂ«rkimi (Katalogu dhe KĂ«rkimi) â pĂ«r tĂ« shmangur BolotĂ«n e TĂ« DhĂ«nave (kur ne grumbullojmĂ« tĂ« gjitha tĂ« dhĂ«nat nĂ« njĂ« vend dhe pastaj Ă«shtĂ« e pamundur tĂ« punojmĂ« me to), ne duhet tĂ« krijojmĂ« njĂ« shtresĂ« tĂ« metadatat pĂ«r klasifikimin e tĂ« dhĂ«nave, nĂ« mĂ«nyrĂ« qĂ« pĂ«rdoruesit tĂ« mund ta gjejnĂ« lehtĂ«sisht informacionin e nevojshĂ«m pĂ«r analizĂ«. SĂ« additional, mund tĂ« pĂ«rdorim zgjidhje tĂ« tjera kĂ«rkimi, si ElasticSearch. KĂ«rkimi ndihmon pĂ«rdoruesin tĂ« kĂ«rkojĂ« tĂ« dhĂ«nat e nevojshme pĂ«rmes njĂ« ndĂ«rfaqeje tĂ« pĂ«rshtatshme.
- PĂ«rgjigje (Procesi) â ky hap Ă«shtĂ« pĂ«rgjegjĂ«s pĂ«r pĂ«rpunimin dhe transformimin e tĂ« dhĂ«nave. Ne mund tĂ« transformojmĂ« tĂ« dhĂ«nat, tĂ« ndryshojmĂ« strukturat e tyre, t'i pastrojmĂ« dhe shumĂ« mĂ« tepĂ«r.
- Siguria (Siguria) â Ă«shtĂ« e rĂ«ndĂ«sishme tĂ« shpenzohet kohĂ« pĂ«r dizajnimin e sigurisĂ« sĂ« zgjidhjes. PĂ«r shembull, kriptimi i tĂ« dhĂ«nave gjatĂ« magazinimit, pĂ«rpunimit dhe ngarkimit. ĂshtĂ« e rĂ«ndĂ«sishme tĂ« pĂ«rdoren metoda tĂ« autentifikimit dhe autorizimit. NĂ« pĂ«rfundim, nevojitet njĂ« mjet auditimi.
Nga një pikëpamje praktike, ne mund ta karakterizojmë liqenin e të dhënave me tre atribute:
- Mblidhni dhe ruani gjithçka â liqeni i tĂ« dhĂ«nave pĂ«rmban tĂ« gjitha tĂ« dhĂ«nat, si tĂ« dhĂ«na tĂ« papĂ«rpunuara pĂ«r çdo periudhĂ« kohe, ashtu edhe tĂ« dhĂ«na tĂ« pĂ«rpunuara/tĂ« pastruara.
- Analiza e thellĂ« â liqeni i tĂ« dhĂ«nave u lejon pĂ«rdoruesve tĂ« eksploros dhe tĂ« analizojnĂ« tĂ« dhĂ«nat.
- Qasje fleksibile â liqeni i tĂ« dhĂ«nave ofron qasje fleksibile pĂ«r tĂ« dhĂ«na tĂ« ndryshme dhe pĂ«r skenarĂ« tĂ« ndryshĂ«m.
Tani mund të flasim për ndryshimin mes magazinës së të dhënave dhe liqenit të të dhënave. Zakonisht, njerëzit pyesin:
- Po përsa i përket magazinës së të dhënave?
- A e zëvendësojmë magazinën e të dhënave me liqenin e të dhënave apo e zgjerojmë atë?
- A mund të shkojmë pa liqenin e të dhënave?
NĂ«se do tĂ« flasim shkurt, nuk ka njĂ« pĂ«rgjigje tĂ« qartĂ«. Ădo gjĂ« varet nga situata specifike, aftĂ«sitĂ« nĂ« ekip dhe buxheti. PĂ«r shembull, migrohet magazina e tĂ« dhĂ«nave nĂ« Oracle nĂ« AWS dhe krijimi i liqenit tĂ« tĂ« dhĂ«nave nga njĂ« kompani nĂ«nshkruese e Amazon â Woot â .
Nga ana tjetĂ«r, ofruesi Snowflake deklaron se nuk ka nevojĂ« tĂ« mendoni mĂ« pĂ«r liqenin e tĂ« dhĂ«nave, pasi platforma e tij tĂ« dhĂ«nash (deri nĂ« 2020 ishte magazina e tĂ« dhĂ«nave) ju lejon tĂ« kombinoni si liqenin e tĂ« dhĂ«nave ashtu edhe magazinĂ«n e tĂ« dhĂ«nave. Kam punuar pak me Snowflake, dhe Ă«shtĂ« vĂ«rtet njĂ« produkt unik qĂ« mund ta bĂ«jĂ« kĂ«tĂ«. Ămimi Ă«shtĂ« njĂ« çështje tjetĂ«r.
NĂ« pĂ«rfundim, mendimi im personal Ă«shtĂ« se na nevojitet akoma njĂ« depo e dhĂ«nash si burim kryesor tĂ« dhĂ«nash pĂ«r raportimin tonĂ«, dhe gjithçka qĂ« nuk pĂ«rfshihet, e ruajmĂ« nĂ« liqenin e tĂ« dhĂ«nave. Roli i analitikĂ«s Ă«shtĂ« tĂ« ofrojĂ« qasje tĂ« lehtĂ« pĂ«r biznesin pĂ«r marrjen e vendimeve. Siç do tĂ« donim, pĂ«rdoruesit e biznesit punojnĂ« mĂ« efikasht me depo tĂ« dhĂ«nash sesa me liqenin e tĂ« dhĂ«nave, pĂ«r shembull nĂ« Amazon â kemi Redshift (depo analitike e tĂ« dhĂ«nave) dhe Redshift Spectrum/Athena (interfaci SQL pĂ«r liqenin e tĂ« dhĂ«nave nĂ« S3 mbi bazĂ«n e Hive/Presto). E njĂ«jta gjĂ« i referohet depozita moderne tĂ« tĂ« dhĂ«nave analitike.
Le të shqyrtojmë arkitekturën tipike të depozitës së të dhënave:
Kjo është një zgjidhje klasike. Ne kemi sistemet burimore, me ndihmën e ETL/ELT ne kopjojmë të dhënat në depo të dhënash analitike dhe i lidhim me zgjidhjen e Business Intelligence (preferenca ime është Tableau, e juaja?).
Kjo zgjidhje ka këto disavantazhe:
- Operacionet ETL/ELT kërkojnë kohë dhe burime.
- Si rregull, kuadri për ruajtjen e të dhënave në depo të dhënash analitike nuk është i lirë (për shembull Redshift, BigQuery, Teradata), pasi ne duhet të blejmë një klaster të tërë.
- Përdoruesit e biznesit kanë qasje në të dhënat e pastruara dhe shpesh të agreguara dhe nuk kanë mundësi të marrin të dhëna të papërpunuara.
Sigurisht, gjithçka varet nga rasti juaj. Nëse nuk keni probleme me depozitat tuaja të dhënash, atëherë nuk keni nevojë për një liqen të dhënash. Por kur paraqiten problemet me mungesën e hapësirës, fuqisë ose kostoja ka një rol kyç, atëherë mund të shqyrtoni mundësinë e një liqeni të dhënash. Kjo është arsyeja pse, liqeni i të dhënave është shumë popullor. Ja një shembull i arkitekturës së liqenit të të dhënave:
Duke përdorur qasjen e liqenit të të dhënave, ne ngarkojmë të dhënat e papërpunuara në liqenin tonë të të dhënave (batch ose streaming), dhe më pas procesojmë të dhënat sipas nevojës. Liqeni i të dhënave lejon që përdoruesit e biznesit të krijojnë transformimet e tyre të dhënave (ETL/ELT) ose të analizojnë të dhënat në zgjidhjet e Business Intelligence (nëse ka drejtuesin e nevojshëm).
QĂ«llimi i çdo zgjidhjeje analitike Ă«shtĂ« tĂ« shĂ«rbejĂ« pĂ«r pĂ«rdoruesit e biznesit. Prandaj ne gjithmonĂ« duhet tĂ« punojmĂ« nga kĂ«rkesat e biznesit. (NĂ« Amazon, ky Ă«shtĂ« njĂ« nga parimet â punimi mbrapsht).
Duke punuar dhe me depozitën e dhënave dhe me liqenin e të dhënave, ne mund të krahasojmë të dyja zgjidhjet:
Konkluzioni kryesor që mund të bëhet është se depoja e të dhënave nuk konkuron me liqenin e të dhënave, përkundrazi, e plotëson atë. Por kjo është në dorën tuaj se çfarë i përshtatet rastit tuaj. Gjithmonë është interesante ta provosh vetë dhe të bësh përfundime të sakta.
Dua gjithashtu të flas për një nga rastet kur fillova të përdor qasjen e liqenit të të dhënave. E gjithë kjo është mjaft banale, përpiqesha të përdorja një mjet ELT (ne kishim Matillion ETL) dhe Amazon Redshift, zgjidhja ime funksionoi, por nuk përmbushte kërkesat.
Më nevojitej të merrja log-et e uebit, t'i transformoja dhe t'i agregoja, për të ofruar të dhëna për dy raste:
- Ekipa e marketingut donte të analizonin aktivitetin e botëve për SEO
- IT-i donte të shikonte metrikat e funksionimit të faqeve të internetit
Log-e shumë të thjeshta, mjaft të thjeshta. Ja një shembull:
https 2018-07-02T22:23:00.186641Z app/my-loadbalancer/50dc6c495c0c9188
192.168.131.39:2817 10.0.0.1:80 0.086 0.048 0.037 200 200 0 57
"GET https://www.example.com:443/ HTTP/1.1" "curl/7.46.0" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2
arn:aws:elasticloadbalancing:us-east-2:123456789012:targetgroup/my-targets/73e2d6bc24d8a067
"Root=1-58337281-1d84f3d73c47ec4e58577259" "www.example.com" "arn:aws:acm:us-east-2:123456789012:certificate/12345678-1234-1234-1234-123456789012"
1 2018-07-02T22:22:48.364000Z "authenticate,forward" "-" "-"Një skedar peshoi 1-4 megabajt.
Por kishte një vështirësi. Ne kishim 7 domain në mbarë botën, dhe në një ditë krijoheshin 7000 skedarë. Kjo nuk ishte një volum shumë i madh, gjithçka 50 gigabajt. Por madhësia e klasterit tonë Redshift ishte gjithashtu e vogël (4 nod). Ngarkimi në mënyrë tradicionale i një skedari merrte rreth një minutë. Pra, në mënyrë të drejtpërdrejtë, problemi nuk zgjidhej. Dhe kjo ishte ajo herë që vendosa të përdor qasjen e liqenit të të dhënave. Zgjidhja dukej përafërsisht kështu:
Ishte mjaft e thjeshtë (dua të theksoj se përparësia e punës në re është thjeshtësia). Unë përdora:
- AWS Elastic Map Reduce (Hadoop) si kapacitet llogaritës
- AWS S3 si depo e skedave me mundësi për kriptimin e të dhënave dhe ndarjen e aksesit
- Spark si kapacitet llogaritës InMemory dhe PySpark për logjikën dhe transformimin e të dhënave
- Parquet si rezultat i punës së Spark
- AWS Glue Crawler si mbledhës i metadatumit për të dhëna të reja dhe partitë
- Redshift Spectrum si ndërfaqe SQL për liqenin e të dhënave për përdoruesit ekzistues të Redshift
Klasteri më i vogël EMR+Spark përpunoi të gjithë grupin e skedarëve për 30 minuta. Ka dhe raste të tjera për AWS, sidomos shumë të lidhura me Alexa, ku ka shumë të dhëna.
KohĂ« mĂ« parĂ« mĂ«sova njĂ« nga disavantazhet e liqenit tĂ« tĂ« dhĂ«nave â Ă«shtĂ« GDPR. Problemi Ă«shtĂ« se kur klienti kĂ«rkon ta fshijĂ«, ndĂ«rsa tĂ« dhĂ«nat gjenden nĂ« njĂ« nga skedarĂ«t, nuk mund tĂ« pĂ«rdorim Data Manipulation Language dhe operacionin DELETE si nĂ« njĂ« bazĂ« tĂ« dhĂ«nash.
Shpresoj se artikulli sqaroi ndryshimin midis depozitës së të dhënave dhe liqenit të të dhënave. Nëse ishte interesante, mund të përkthej edhe artikujt e mi ose artikujt e profesionistëve që lexoj. Po ashtu mund të flas për zgjidhjet me të cilat punoj dhe arkitekturën e tyre.
Burimi: habr.com
