ProHoster >> Blog >> Administrimi >> Na na duhet li njĂ« liqen tĂ« dhĂ«nash? ÇfarĂ« tĂ« bĂ«jmĂ« me deponinĂ« e tĂ« dhĂ«nave?

Na na duhet li njĂ« liqen tĂ« dhĂ«nash? ÇfarĂ« tĂ« bĂ«jmĂ« me deponinĂ« e tĂ« dhĂ«nave?

Ky Ă«shtĂ« njĂ« artikull pĂ«rkthim i artikullit tim nĂ« medium — Fillimi me Liqenin e TĂ« DhĂ«nave, i cili u bĂ« mjaft popullor, ndoshta pĂ«r shkak tĂ« thjeshtĂ«sisĂ« sĂ« tij. Prandaj, vendosa ta shkruaj atĂ« nĂ« gjuhĂ«n shqipe dhe ta pasuroj pak, nĂ« mĂ«nyrĂ« qĂ« njĂ« person i zakonshĂ«m, qĂ« nuk Ă«shtĂ« specialist nĂ« punĂ«n me tĂ« dhĂ«nat, tĂ« kuptojĂ« se çfarĂ« Ă«shtĂ« njĂ« depo e tĂ« dhĂ«nave (DW), çfarĂ« Ă«shtĂ« njĂ« liqen tĂ« dhĂ«nash (Data Lake), dhe si bashkĂ«jetojnĂ« ato.

Pse vendosa të shkruaj për liqenin e të dhënave? Kam punuar me të dhëna dhe analitikë për më shumë se 10 vjet, dhe tani po punoj me të dhëna të mëdha në Amazon Alexa AI në Cambridge, që është në Boston, përkundër faktit që jetoj në Victoria në ishullin Vancouver dhe shpesh qëndroj në Boston, Seattle, dhe Vancouver, dhe ndonjëherë madje flas në Moskë në konferenca. Gjithashtu, herë pas here shkrimi është një aktivitet i imi, por zakonisht shkruaj në anglisht, dhe kam shkruar tashmë disa libra, gjithashtu kam një nevojë për të ndarë trendet e analitikës nga Amerika Veriore, dhe ndonjëherë shkruaj në Telegram.

Unë gjithmonë kam punuar me depo të dhënash, dhe që nga viti 2015 kam filluar të punoj ngushtë me Amazon Web Services, madje kalova plotësisht në analizën në re (AWS, Azure, GCP). Kam vëzhguar evolucionin e zgjidhjeve për analizë që nga viti 2007 dhe vetë kam punuar për një ofrues depo të dhënash si Teradata dhe e kam implementuar atë në Sberbank. Atëherë doli Big Data me Hadoop. Të gjithë filluan të flasin se epoka e depozita kishte përfunduar dhe tani të gjithë ishin te Hadoop, dhe pastaj filluan të flisnin për Data Lake, përsëri duke thënë se tani përfundimisht depoja e dhënash kishte vdekur. Por për fat të mirë (ndoshta për disa të pafat që fitonin shumë para duke konfiguruar Hadoop), depa e dhënash nuk ka zhdukur.

Në këtë artikull do të shqyrtojmë se çfarë është një liqen të dhënash. Artikulli është i destinuar për njerëz me pak përvojë në depozitë të dhënash ose që nuk kanë fare.

Na na duhet li njĂ« liqen tĂ« dhĂ«nash? ÇfarĂ« tĂ« bĂ«jmĂ« me deponinĂ« e tĂ« dhĂ«nave?

NĂ« imazhin Ă«shtĂ« liqeni Bled, njĂ« nga liqenet e mia tĂ« preferuara, ndonĂ«se kam qenĂ« vetĂ«m njĂ« herĂ« atje, por e mbaj mend pĂ«r gjithĂ« jetĂ«n. Por do tĂ« flasim pĂ«r njĂ« lloj tjetĂ«r liqeni — liqenin e tĂ« dhĂ«nave. Mund tĂ« keni dĂ«gjuar disa herĂ« pĂ«r kĂ«tĂ« termin, por njĂ« pĂ«rcaktim tjetĂ«r nuk do tĂ« dĂ«mtonte askĂ«nd.

Së pari, ja disa nga përcaktimet më popullore të Liqenit të Dhënave:

«arkiv i tĂ« dhĂ«nash tĂ« tĂ« gjitha llojeve tĂ« tĂ« dhĂ«nave tĂ« papĂ«rpunuara, tĂ« cilat janĂ« tĂ« arritshme pĂ«r analizĂ« nga kushdo nĂ« organizatë» — Martin Fowler.

«NĂ«se mendoni se njĂ« vitrinĂ« tĂ« dhĂ«nash Ă«shtĂ« njĂ« shishe uji — tĂ« pastruar, tĂ« paketuar dhe tĂ« mbushur pĂ«r pĂ«rdorim tĂ« lehtĂ«, atĂ«herĂ« njĂ« liqen tĂ« dhĂ«nash pĂ«r ne Ă«shtĂ« njĂ« reservoir i madh me ujĂ« nĂ« formĂ«n e tij natyrale. PĂ«rdoruesit mund tĂ« marrin ujĂ« pĂ«r vete, tĂ« zhytĂ«n nĂ« thellĂ«si, tĂ« eksplorojnë» — James Dixon.

Tani ne me siguri e dimë se liqeni i të dhënave ka të bëjë me analitikën, ai na lejon të ruajmë sasi të mëdha të dhënash në formën e tyre origjinale dhe kemi qasje të nevojshme dhe të lehtë në të dhënat.

Unë shpesh e dua të thjeshtoj gjërat; nëse mund të shpjegoj një term të komplikuar me fjalë të thjeshta, do të thotë se e kam kuptuar si funksionon dhe për çfarë është e nevojshme. Një herë, duke kërkuar në iPhone tim në galerinë e fotove, më erdhi në mendje, kjo është pikërisht një liqen të dhënash, madje kam bërë një slide për konferenca:

Na na duhet li njĂ« liqen tĂ« dhĂ«nash? ÇfarĂ« tĂ« bĂ«jmĂ« me deponinĂ« e tĂ« dhĂ«nave?

E gjitha është shumë e thjeshtë. Ne bëjmë një fotografi me telefon, fotografia ruhet në telefon dhe mund të ruhen në iCloud (ruajtje skedari në re). Gjithashtu telefoni mbledh meta të dhëna për fotografitë: çfarë është paraqitur, gjeo-shënimi, koha. Si rezultat, mund të përdorim ndërfaqen e përshtatshme të iPhone-it për të gjetur fotografinë tonë dhe madje shohim tregues, për shembull, kur kërkoj fotografi me fjalën zjarr (fire), gjej 3 fotografi me pamjen e një zjarri. Për mua, kjo është si një mjet Business Intelligence, që funksionon shumë shpejt dhe saktë.

Sigurisht, nuk duhet të harrojmë për sigurinë (autorizimin dhe autentikimin), ndryshe të dhënat tona mund të kalojnë lehtë në akses publik. Ka shumë lajmë për korporata të mëdha dhe startup-e, të cilat kanë pasur të dhënat e tyre në akses publik për shkak të moskujdesit të zhvilluesve dhe mosrespektimit të rregullave të thjeshta.

Madje një figurë kaq e thjeshtë, na ndihmon të paraqesim se çfarë është një liqen të dhënash, dallimet e tij nga një depo tradicionale të dhënash dhe elementët e tij kryesorë:

  1. Ngarkimi i tĂ« dhĂ«nave (Ingestion) — komponenti kyç i liqenit tĂ« tĂ« dhĂ«nave. TĂ« dhĂ«nat mund tĂ« hyjnĂ« nĂ« ruajtjen e tĂ« dhĂ«nave nĂ« dy mĂ«nyra — batch (ngarkimi nĂ« intervale) dhe streaming (rrjedha e tĂ« dhĂ«nave).
  2. Ruajtja e skedarĂ«ve (Storage) — komponenti kryesor i Liqenit tĂ« TĂ« DhĂ«nave. Na nevojitet njĂ« ruajtje e shkallĂ«zueshme lehtĂ«sisht, jashtĂ«zakonisht e besueshme dhe me kosto tĂ« ulĂ«t. PĂ«r shembull, nĂ« AWS kjo Ă«shtĂ« S3.
  3. Katalogu dhe KĂ«rkimi (Catalog and Search) — pĂ«r tĂ« shmangur Bllokimin e TĂ« DhĂ«nave (kur ngremĂ« tĂ« gjitha tĂ« dhĂ«nat nĂ« njĂ« vend dhe mĂ« pas Ă«shtĂ« e pamundur tĂ« punojmĂ« me to), na nevojitet tĂ« krijojmĂ« njĂ« shtresĂ« metadatat pĂ«r klasifikimin e tĂ« dhĂ«nave, nĂ« mĂ«nyrĂ« qĂ« pĂ«rdoruesit tĂ« mund tĂ« gjejnĂ« lehtĂ«sisht tĂ« dhĂ«nat qĂ« u nevojiten pĂ«r analizĂ«. PĂ«r mĂ« tepĂ«r, mund tĂ« pĂ«rdoren zgjidhje tĂ« tjera pĂ«r kĂ«rkim, si ElasticSearch. KĂ«rkimi e ndihmon pĂ«rdoruesin qĂ« tĂ« gjejĂ« tĂ« dhĂ«nat e nevojshme pĂ«rmes njĂ« ndĂ«rfaqeje miqĂ«sore.
  4. PĂ«rpunimi (Process) — ky hap merret me pĂ«rpunimin dhe transformimin e tĂ« dhĂ«nave. Ne mund tĂ« transformojmĂ« tĂ« dhĂ«nat, tĂ« ndryshojmĂ« strukturat e tyre, t'i pastroni dhe shumĂ« mĂ« tepĂ«r.
  5. Siguria (Siguria) — Ă«shtĂ« e rĂ«ndĂ«sishme tĂ« investoni kohĂ« nĂ« dizajnin e zgjidhjeve tĂ« sigurisĂ«. PĂ«r shembull, enkriptimi i tĂ« dhĂ«nave gjatĂ« ruajtjes, pĂ«rpunimit dhe ngarkimit. ËshtĂ« e rĂ«ndĂ«sishme tĂ« pĂ«rdoren metoda autentikimi dhe autorizimi. NĂ« pĂ«rfundim, nevojitet njĂ« mjet auditimi.

Nga një pikëpamje praktike, ne mund të karakterizojmë liqenin e të dhënave me tre atribute:

  1. 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.
  2. Analiza e thellĂ« — liqeni i tĂ« dhĂ«nave u lejon pĂ«rdoruesve tĂ« eksplorojnĂ« dhe analizojnĂ« tĂ« dhĂ«nat.
  3. Akses fleksibĂ«l — liqeni i tĂ« dhĂ«nave siguron akses fleksibĂ«l pĂ«r tĂ« dhĂ«na tĂ« ndryshme dhe pĂ«r skenarĂ« tĂ« ndryshĂ«m.

Tani mund të flasim për ndarjen midis depozitës së të dhënave dhe liqenit të të dhënave. Zakonisht, njerëzit pyesin:

  • Por, çfarĂ« ndodh me depozitĂ«n e tĂ« dhĂ«nave?
  • A e zĂ«vendĂ«sojmĂ« depozitĂ«n e tĂ« dhĂ«nave me liqenin e tĂ« dhĂ«nave apo e zgjedhim atĂ«?
  • A Ă«shtĂ« e mundur tĂ« shmangim pĂ«rdorimin e liqenit tĂ« tĂ« dhĂ«nave?

NĂ«se flasim shkurt, nuk ka njĂ« pĂ«rgjigje tĂ« saktĂ«. Gjithçka varet nga situata specifike, aftĂ«sitĂ« nĂ« ekip dhe buxheti. PĂ«r shembull, migrimi i depozitĂ«s sĂ« tĂ« dhĂ«nave nĂ« Oracle nĂ« AWS dhe krijimi i njĂ« liqeni tĂ« dhĂ«nash nga njĂ« kompani nĂ«nshkruar e Amazon — Woot — Historia jonĂ« e liqenit tĂ« tĂ« dhĂ«nave: Si Woot.com ndĂ«rtuar njĂ« liqen tĂ« dhĂ«nash pa serverĂ« nĂ« AWS.

Nga ana tjetĂ«r, shpallĂ«si Snowflake pretendon se nuk keni mĂ« nevojĂ« tĂ« mendoni pĂ«r liqenin e tĂ« dhĂ«nave, pasi platforma e tyre tĂ« dhĂ«nash (deri nĂ« vitin 2020, kĂ«tĂ« e quanin depo tĂ« dhĂ«nash) ju lejon tĂ« kombinoni dhe liqenin e tĂ« dhĂ«nave dhe depozitĂ«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 i cĂ«shtjes, Ă«shtĂ« njĂ« çështje tjetĂ«r.

NĂ« pĂ«rfundim, mendimi im personal Ă«shtĂ« se na nevojitet ende njĂ« depo e dhĂ«nash si burimi kryesor i tĂ« dhĂ«nave pĂ«r raportimet tona, dhe gjithçka qĂ« nuk pĂ«rshtatet, e ruajmĂ« nĂ« liqenin e tĂ« dhĂ«nave. Roli i analizĂ«s Ă«shtĂ« tĂ« ofrojĂ« akses tĂ« lehtĂ« pĂ«r biznesin nĂ« mĂ«nyrĂ« qĂ« tĂ« bĂ«jĂ« vendime. MĂ« nĂ« fund, pĂ«rdoruesit e biznesit punojnĂ« mĂ« efektivisht me njĂ« depo tĂ« dhĂ«nash sesa me njĂ« liqen tĂ« dhĂ«nash; pĂ«r shembull nĂ« Amazon — kemi Redshift (depotĂ« analitike tĂ« tĂ« dhĂ«nave) dhe Redshift Spectrum/Athena (ndĂ«rfaqja SQL pĂ«r liqenin e tĂ« dhĂ«nave nĂ« S3 mbi bazĂ«n e Hive/Presto). TĂ« njĂ«jtĂ«n gjĂ« vlen edhe pĂ«r depo tĂ« tjera moderne analitike tĂ« tĂ« dhĂ«nave.

Le të shqyrtojmë arkitekturën tipike të depoit të dhënave:

Na na duhet li njĂ« liqen tĂ« dhĂ«nash? ÇfarĂ« tĂ« bĂ«jmĂ« me deponinĂ« e tĂ« dhĂ«nave?

Kjo është një zgjidhje klasike. Kemi sistemet burim, me ndihmën e ETL/ELT kopjojmë të dhënat në depotë analitike të të dhënave dhe i lidhim me zgjidhjen e Business Intelligence (e imja e preferuar është Tableau, dhe e juaja?).

Kjo zgjidhje ka këto disavantazhe:

  • Operacionet ETL/ELT kĂ«rkojnĂ« kohĂ« dhe burime.
  • Si rregull, memoria pĂ«r ruajtjen e tĂ« dhĂ«nave nĂ« depo analitike tĂ« tĂ« dhĂ«nave nuk Ă«shtĂ« e lirĂ« (pĂ«r shembull Redshift, BigQuery, Teradata), pasi duhet tĂ« blejmĂ« njĂ« kluster tĂ« tĂ«rĂ«.
  • PĂ«rdoruesit e biznesit kanĂ« qasje nĂ« tĂ« dhĂ«na tĂ« pastra dhe shpesh tĂ« akumuara, por nuk kanĂ« mundĂ«si tĂ« marrin tĂ« dhĂ«na tĂ« papĂ«rpunuara.

Natyrisht, gjithçka varet nga rasti juaj. Nëse nuk keni probleme me ruajtjen e të dhënave, atëherë nuk keni nevojë për një liqen të dhënash. Por kur lindin probleme me mungesën e hapësirës, kapacitetit, ose kostoja është një faktor kyç, atëherë mund të shqyrtoni mundësinë e një liqeni të dhënash. Pikërisht për këtë, liqeni i të dhënave është shumë popullor. Këtu është një shembull i arkitekturës së liqenit të të dhënave:
Na na duhet li njĂ« liqen tĂ« dhĂ«nash? ÇfarĂ« tĂ« bĂ«jmĂ« me deponinĂ« e tĂ« dhĂ«nave?
Duke përdorur qasjen e liqenit të të dhënave, ne ngarkojmë të dhëna të papërpunuara në liqenin tonë të të dhënave (në grup ose në rrjedhje), dhe më pas i përpunojmë të dhënat sipas nevojës. Liqeni i të dhënave lejon përdoruesit e biznesit të krijojnë transformime të tyre të të dhënave (ETL/ELT) ose të analizojnë të dhënat në zgjidhje të Inteligjencës Biznesore (nëse ka drejtorin e nevojshëm).

QĂ«llimi i çdo zgjidhjeje analitike Ă«shtĂ« tĂ« shĂ«rbejĂ« pĂ«rdoruesve tĂ« biznesit. Prandaj, ne duhet gjithmonĂ« tĂ« punojmĂ« sipas kĂ«rkesave tĂ« biznesit. (NĂ« Amazon, kjo Ă«shtĂ« njĂ« nga parimet — punimi nga prapa).

Duke punuar si me ruajtjen e të dhënave ashtu edhe me liqenin e të dhënave, ne mund të krahasojmë të dyja zgjidhjet:

Na na duhet li njĂ« liqen tĂ« dhĂ«nash? ÇfarĂ« tĂ« bĂ«jmĂ« me deponinĂ« e tĂ« dhĂ«nave?

Gjetja kryesore qĂ« mund tĂ« bĂ«het Ă«shtĂ« se ruajtja e tĂ« dhĂ«nave nuk konkurron me liqenin e tĂ« dhĂ«nave, por e plotĂ«son atĂ«. MegjithatĂ«, Ă«shtĂ« pĂ«rgjegjĂ«sia juaj tĂ« vendosni se çfarĂ« Ă«shtĂ« mĂ« e pĂ«rshtatshme pĂ«r rastin tuaj. ËshtĂ« gjithmonĂ« interesante ta provosh vetĂ« dhe tĂ« bĂ«sh pĂ«rfundime tĂ« sakta.

Dëshiroj gjithashtu të flas për një nga rastet kur fillova të përdor këtë qasje të liqenit të të dhënave. Gjithçka ishte mjaft e thjeshtë; përpiqesha të përdorja një mjet ELT (kishim Matillion ETL) dhe Amazon Redshift, zgjidhja ime funksiononte, por nuk përmbushte kërkesat.

Më nevojitej të merrja log-et e web-it, t'i transformoja dhe t'i aggregoja për të ofruar të dhënat për dy raste:

  1. Ekipa e marketingut dëshironte të analizonte aktivitetin e botëve për SEO.
  2. IT dëshiroi të shihte metrikat e punës së faqeve.

Log-et ishin shumë 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 kishte peshën 1-4 megabajt.

Por ishte një vështirësi. Ne kishim 7 domain-e në të gjithë botën, dhe në një ditë krijoheshin 7000 skedarë. Kjo nuk ishte shumë, vetëm 50 gigabajt. Por madhësia e klasterit tonë Redshift ishte gjithashtu e vogël (4 nodo). Ngarkimi në mënyrën tradicionale të një skedari merrte rreth një minutë. Domethënë, problemi nuk zgjidhej drejtpërdrejt. Dhe ky ishte rasti kur vendosa të përdor qasjen e liqenit të të dhënave. Zgjidhja dukej kështu:

Na na duhet li njĂ« liqen tĂ« dhĂ«nash? ÇfarĂ« tĂ« bĂ«jmĂ« me deponinĂ« e tĂ« dhĂ«nave?

është mjaft e thjeshtë (dua të theksoj se përparësia e punës në cloud është thjeshtësia). Unë përdora:

  • AWS Elastic Map Reduce (Hadoop) si burim llogaritĂ«s
  • AWS S3 si storage skedarĂ«sh me mundĂ«si pĂ«r enkriptimin e tĂ« dhĂ«nave dhe kufizimin e aksesit
  • Spark si burim llogaritĂ«s nĂ« memorie dhe PySpark pĂ«r logjikĂ«n dhe transformimin e tĂ« dhĂ«nave
  • Parquet si rezultati i punĂ«s sĂ« Spark
  • AWS Glue Crawler si mbledhĂ«s metadata pĂ«r tĂ« dhĂ«na dhe pjesĂ« tĂ« reja
  • 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ë partinë e skedarëve brenda 30 minutash. Ka edhe raste të tjera për AWS, veçanërisht shumë që lidhen me Alexa, ku ka shumë të dhëna.

Pak mĂ«sova njĂ« nga disavantazhet e liqenit tĂ« tĂ« dhĂ«nave — Ă«shtĂ« GDPR. Problemi Ă«shtĂ« se kur klienti kĂ«rkon tĂ« fshihet, dhe tĂ« dhĂ«nat ndodhen nĂ« njĂ« nga skedarĂ«t, ne nuk mund ta pĂ«rdorim Data Manipulation Language dhe operacionin DELETE si nĂ« njĂ« bazĂ« tĂ« dhĂ«nash.

Shpresoj se ky artikull sqaroi dallimin midis një depozite të dhënash dhe një liqeni të të dhënave. Nëse ishte interesante, mund të përkthej edhe artikujt e mi të tjerë ose artikuj profesionistësh që lexoj. Gjithashtu, mund të flas për zgjidhje me të cilat punoj dhe arkitekturën e tyre.

Burimi: habr.com

Bli njĂ« hosting tĂ« besueshĂ«m pĂ«r faqet me mbrojtje DDoS, VPS VDS serverĂ« đŸ”„ Bli njĂ« hosting tĂ« besueshĂ«m pĂ«r faqet me mbrojtje DDoS, VPS VDS serverĂ« | ProHoster