A kemi nevojë për një liqen të dhënash? Çfarë duhet bërë me depon e të dhënave?

Ky artikull është një përkthim i artikullit tim në medium - Fillimi me Data Lake, e cila doli të ishte mjaft e njohur, ndoshta për shkak të thjeshtësisë së saj. Prandaj, vendosa ta shkruaj në Rusisht dhe të shtoj pak për t'i bërë të qartë një personi të zakonshëm që nuk është specialist i të dhënave se çfarë është një depo e të dhënave (DW), dhe çfarë është një liqen i të dhënave (Liqeni i të dhënave) dhe si ato bashkohuni së bashku.

Pse desha të shkruaj për liqenin e të dhënave? Unë kam punuar me të dhëna dhe analitikë për më shumë se 10 vjet, dhe tani jam duke punuar patjetër me të dhëna të mëdha në Amazon Alexa AI në Kembrixh, që është në Boston, megjithëse jetoj në Victoria në ishullin Vancouver dhe shpesh vizitoj Boston, Seattle , dhe në Vankuver, dhe ndonjëherë edhe në Moskë, flas në konferenca. Edhe unë shkruaj herë pas here, por shkruaj kryesisht në anglisht dhe kam shkruar tashmë disa libra, kam gjithashtu nevojë të ndaj tendencat e analitikës nga Amerika e Veriut dhe ndonjëherë shkruaj telegrameve.

Unë kam punuar gjithmonë me magazinat e të dhënave dhe që nga viti 2015 kam filluar të punoj ngushtë me Shërbimet e Uebit të Amazon, dhe përgjithësisht kam kaluar në analitikën e cloud (AWS, Azure, GCP). Unë kam vëzhguar evolucionin e zgjidhjeve analitike që nga viti 2007 dhe madje kam punuar për shitësin e magazinave të të dhënave Teradata dhe e kam zbatuar atë në Sberbank, dhe atëherë u shfaqën Big Data me Hadoop. Të gjithë filluan të thoshin se epoka e ruajtjes kishte kaluar dhe tani gjithçka ishte në Hadoop, dhe më pas filluan të flisnin përsëri për Data Lake, se tani përfundimi i magazinës së të dhënave kishte ardhur përfundimisht. Por për fat të mirë (ndoshta për fat të keq për disa që fituan shumë para duke ngritur Hadoop), depoja e të dhënave nuk u zhduk.

Në këtë artikull do të shohim se çfarë është një liqen i të dhënave. Ky artikull është menduar për njerëzit që kanë pak ose aspak përvojë me depot e të dhënave.

Ne foto eshte liqeni i Bledit, ky eshte nje nga liqenet e mi te preferuar, edhe pse kam qene vetem nje here, e kam kujtuar gjithe jeten. Por ne do të flasim për një lloj tjetër liqeni - një liqen të dhënash. Ndoshta shumë prej jush kanë dëgjuar tashmë për këtë term më shumë se një herë, por një përkufizim më shumë nuk do të dëmtojë askënd.

Para së gjithash, këtu janë përkufizimet më të njohura të një liqeni të të dhënave:

"Një ruajtje skedarësh e të gjitha llojeve të të dhënave të papërpunuara që është në dispozicion për analizë nga kushdo në organizatë" - Martin Fowler.

"Nëse mendoni se një data mart është një shishe uji - e pastruar, e paketuar dhe e paketuar për konsum të përshtatshëm, atëherë një liqen i të dhënave është një rezervuar i madh uji në formën e tij natyrore. Përdorues, unë mund të mbledh ujë për veten time, të zhytem thellë, të eksploroj” - James Dixon.

Tani e dimë me siguri se një liqen i të dhënave ka të bëjë me analitikën, na lejon të ruajmë sasi të mëdha të dhënash në formën e tij origjinale dhe kemi aksesin e nevojshëm dhe të përshtatshëm në të dhëna.

Shpesh më pëlqen t'i thjeshtoj gjërat, nëse mund të shpjegoj një term kompleks me fjalë të thjeshta, atëherë e kuptoj vetë se si funksionon dhe për çfarë nevojitet. Një ditë, po vërtita në galerinë e fotografive të iPhone, dhe më ra në sy, ky është një liqen i vërtetë i të dhënave, madje bëra një rrëshqitje për konferenca:

Gjithçka është shumë e thjeshtë. Ne bëjmë një foto në telefon, fotografia ruhet në telefon dhe mund të ruhet në iCloud (ruajtje e skedarëve në renë kompjuterike). Telefoni mbledh gjithashtu të dhëna meta të fotografive: atë që shfaqet, etiketën gjeografike, kohën. Si rezultat, ne mund të përdorim ndërfaqen miqësore të iPhone për të gjetur foton tonë dhe madje shohim tregues, për shembull, kur kërkoj foto me fjalën zjarr, gjej 3 foto me imazhin e zjarrit. Për mua, ky është tamam si një mjet Business Intelligence që funksionon shumë shpejt dhe saktë.

Dhe sigurisht, nuk duhet të harrojmë sigurinë (autorizimin dhe vërtetimin), përndryshe të dhënat tona mund të përfundojnë lehtësisht në domenin publik. Ka shumë lajme për korporatat e mëdha dhe startup-et, të dhënat e të cilave u bënë publike për shkak të neglizhencës së zhvilluesve dhe moszbatimit të rregullave të thjeshta.

Edhe një pamje kaq e thjeshtë na ndihmon të imagjinojmë se çfarë është një liqen i të dhënave, ndryshimet e tij nga një magazinë tradicionale e të dhënave dhe elementët kryesorë të tij:

1. Ngarkimi i të dhënave (Gëlltitja) është një komponent kyç i liqenit të të dhënave. Të dhënat mund të hyjnë në magazinën e të dhënave në dy mënyra - grumbull (ngarkimi në intervale) dhe transmetimi (rrjedha e të dhënave).
2. Ruajtja e skedarëve (Magazinimi) është komponenti kryesor i Liqenit të të Dhënave. Ne kishim nevojë që ruajtja të ishte lehtësisht e shkallëzueshme, jashtëzakonisht e besueshme dhe me kosto të ulët. Për shembull, në AWS është S3.
3. Katalogu dhe Kërkimi (Katalogu dhe Kërkimi) - në mënyrë që ne të shmangim kënetën e të dhënave (kjo është kur i hedhim të gjitha të dhënat në një grumbull, dhe më pas është e pamundur të punohet me të), duhet të krijojmë një shtresë metadata për të klasifikuar të dhënat 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ërdorni zgjidhje shtesë kërkimi si ElasticSearch. Kërkimi ndihmon përdoruesin të gjejë të dhënat e kërkuara përmes një ndërfaqeje miqësore për përdoruesit.
4. Përpunim (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ë strukturën e tyre, t'i pastrojmë ato dhe shumë më tepër.
5. siguri (Siguria) - Është e rëndësishme të shpenzoni kohë në hartimin e sigurisë së zgjidhjes. Për shembull, enkriptimi i të dhënave gjatë ruajtjes, përpunimit dhe ngarkimit. Është e rëndësishme të përdoren metodat e vërtetimit dhe autorizimit. Së fundi, nevojitet një mjet auditimi.

Nga pikëpamja praktike, ne mund të karakterizojmë një liqen të dhënash nga tre atribute:

1. Mblidhni dhe ruani çdo gjë — liqeni i të dhënave përmban të gjitha të dhënat, si të dhëna të papërpunuara të papërpunuara për çdo periudhë kohore ashtu edhe të dhëna të përpunuara/të pastruara.
2. Skanim i thellë — një liqen i të dhënave i lejon përdoruesit të eksplorojnë dhe analizojnë të dhënat.
3. Akses fleksibël — Liqeni i të dhënave ofron akses fleksibël për të dhëna të ndryshme dhe skenarë të ndryshëm.

Tani mund të flasim për ndryshimin midis një depoje të dhënash dhe një liqeni të dhënash. Zakonisht njerëzit pyesin:

• Po në lidhje me magazinën e të dhënave?
• A po e zëvendësojmë magazinën e të dhënave me një liqen të dhënash apo po e zgjerojmë?
• A është ende e mundur të bëhet pa një liqen të dhënash?

Me pak fjalë, nuk ka një përgjigje të qartë. Gjithçka varet nga situata specifike, aftësitë e ekipit dhe buxheti. Për shembull, migrimi i një depoje të dhënash në Oracle në AWS dhe krijimi i një liqeni të dhënash nga një filial i Amazon - Woot - Historia jonë e liqenit të të dhënave: Si Woot.com ndërtoi një liqen të dhënash pa server në AWS.

Nga ana tjetër, shitësi Snowflake thotë se nuk keni më nevojë të mendoni për një liqen të dhënash, pasi platforma e tyre e të dhënave (deri në vitin 2020 ishte një depo të dhënash) ju lejon të kombinoni si një liqen të dhënash ashtu edhe një magazinë të dhënash. Unë nuk kam punuar shumë me Snowflake, dhe është me të vërtetë një produkt unik që mund ta bëjë këtë. Çmimi i emetimit është tjetër çështje.

Si përfundim, mendimi im personal është se ne kemi ende nevojë për një magazinë të dhënash si burimin kryesor të të dhënave për raportimin tonë dhe çdo gjë që nuk përshtatet e ruajmë në një liqen të dhënash. I gjithë roli i analitikës është të sigurojë qasje të lehtë për biznesin për të marrë vendime. Çfarëdo që mund të thuhet, përdoruesit e biznesit punojnë në mënyrë më efikase me një depo të dhënash sesa një liqen të dhënash, për shembull në Amazon - ekziston Redshift (magazina analitike e të dhënave) dhe ka Redshift Spectrum/Athena (ndërfaqja SQL për një liqen të dhënash në S3 bazuar në zgjua/Presto). E njëjta gjë vlen edhe për depot e tjera moderne të të dhënave analitike.

Le të shohim një arkitekturë tipike të depove të të dhënave:

Kjo është një zgjidhje klasike. Ne kemi sisteme burimore, duke përdorur ETL/ELT ne kopjojmë të dhënat në një depo të dhënash analitike dhe i lidhim me një zgjidhje Business Intelligence (e preferuara ime është Tableau, po e juaja?).

Kjo zgjidhje ka disavantazhet e mëposhtme:

• Operacionet ETL/ELT kërkojnë kohë dhe burime.
• Si rregull, memoria për ruajtjen e të dhënave në një depo të dhënash analitike nuk është e lirë (për shembull, Redshift, BigQuery, Teradata), pasi duhet të blejmë një grup të tërë.
• Përdoruesit e biznesit kanë qasje në të dhëna të pastruara dhe shpesh të grumbulluara dhe nuk kanë qasje në të dhëna të papërpunuara.

Sigurisht, gjithçka varet nga rasti juaj. Nëse nuk keni probleme me magazinën tuaj të të dhënave, atëherë nuk keni nevojë fare për një liqen të dhënash. Por kur problemet lindin me mungesën e hapësirës, ​​fuqisë ose çmimit luan një rol kyç, atëherë mund të merrni parasysh opsionin e një liqeni të dhënash. Kjo është arsyeja pse liqeni i të dhënave është shumë i popullarizuar. Këtu është një shembull i një arkitekture të liqenit të 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 (batch ose streaming), më pas i përpunojmë të dhënat sipas nevojës. Liqeni i të dhënave u lejon përdoruesve të biznesit të krijojnë transformimet e tyre të të dhënave (ETL/ELT) ose të analizojnë të dhënat në zgjidhjet e Inteligjencave të Biznesit (nëse është i disponueshëm drejtuesi i nevojshëm).

Qëllimi i çdo zgjidhjeje analitike është t'u shërbejë përdoruesve të biznesit. Prandaj, ne duhet të punojmë gjithmonë sipas kërkesave të biznesit. (Në Amazon ky është një nga parimet - të punosh mbrapsht).

Duke punuar si me një depo të dhënash ashtu edhe me një liqen të dhënash, ne mund të krahasojmë të dyja zgjidhjet:

Përfundimi kryesor që mund të nxirret është se magazina e të dhënave nuk konkurron me liqenin e të dhënave, por përkundrazi e plotëson atë. Por varet nga ju që të vendosni se çfarë është e duhura për rastin tuaj. Është gjithmonë interesante ta provosh vetë dhe të nxjerrësh përfundimet e duhura.

Do të doja t'ju tregoja gjithashtu një nga rastet kur fillova të përdor metodën e të dhënave të liqenit. Gjithçka është mjaft e parëndësishme, u përpoqa të përdor një mjet ELT (ne kishim Matillion ETL) dhe Amazon Redshift, zgjidhja ime funksionoi, por nuk i përshtatej kërkesave.

Më duhej të merrja regjistrat e uebit, t'i transformoja dhe t'i grumbulloja për të siguruar të dhëna për 2 raste:

1. Ekipi i marketingut donte të analizonte aktivitetin e robotëve për SEO
2. IT dëshironte të shikonte matjet e performancës së faqes në internet

Shkrime shumë të thjeshta, 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 peshonte 1-4 megabajt.

Por kishte një vështirësi. Ne kishim 7 domene në mbarë botën dhe 7000 mijë skedarë u krijuan në një ditë. Ky nuk është shumë më tepër vëllim, vetëm 50 gigabajt. Por madhësia e grupit tonë Redshift ishte gjithashtu e vogël (4 nyje). Ngarkimi i një skedari në mënyrën tradicionale zgjati rreth një minutë. Domethënë, problemi nuk u zgjidh kokë më kokë. Dhe ky ishte rasti kur vendosa të përdor qasjen e liqenit të të dhënave. Zgjidhja dukej diçka si kjo:

Është mjaft e thjeshtë (dua të vërej se avantazhi i punës në cloud është thjeshtësia). Une e perdora:

• AWS Elastic Map Reduce (Hadoop) për fuqinë llogaritëse
• AWS S3 si ruajtje e skedarëve me aftësinë për të kriptuar të dhënat dhe për të kufizuar aksesin
• Spark si fuqi informatike InMemory dhe PySpark për logjikën dhe transformimin e të dhënave
• Parket si rezultat i Spark
• AWS Glue Crawler si një mbledhës meta të dhënash rreth të dhënave dhe ndarjeve të reja
• Redshift Spectrum si një ndërfaqe SQL në liqenin e të dhënave për përdoruesit ekzistues të Redshift

Grupi më i vogël EMR+Spark përpunoi të gjithë grumbullin e skedarëve në 30 minuta. Ka raste të tjera për AWS, veçanërisht shumë që lidhen me Alexa, ku ka shumë të dhëna.

Kohët e fundit mësova se një nga disavantazhet e një liqeni të dhënash është GDPR. Problemi është kur klienti kërkon ta fshijë dhe të dhënat janë në një nga skedarët, ne nuk mund të përdorim gjuhën e manipulimit të të dhënave dhe funksionin DELETE si në një bazë të dhënash.

Shpresoj se ky artikull ka sqaruar ndryshimin midis një depoje të dhënash dhe një liqeni të dhënash. Nëse jeni të interesuar, unë mund të përkthej më shumë nga artikujt e mi ose artikuj të profesionistëve që kam lexuar. Dhe gjithashtu tregoni për zgjidhjet me të cilat punoj dhe arkitekturën e tyre.

Burimi: www.habr.com