Makala hii ni tafsiri ya makala yangu kuhusu medium - , ambayo iligeuka kuwa maarufu kabisa, labda kwa sababu ya unyenyekevu wake. Kwa hivyo, niliamua kuiandika kwa Kirusi na kuongeza kidogo ili kuweka wazi kwa mtu wa kawaida ambaye sio mtaalamu wa data ghala la data (DW) ni nini, na ziwa la data ni nini (Ziwa la data), na jinsi wanavyofanya. kupata pamoja.
Kwa nini nilitaka kuandika kuhusu ziwa data? Nimekuwa nikifanya kazi na data na uchanganuzi kwa zaidi ya miaka 10, na sasa hakika ninafanya kazi na data kubwa katika Amazon Alexa AI huko Cambridge, ambayo iko Boston, ingawa ninaishi Victoria kwenye Kisiwa cha Vancouver na mara nyingi hutembelea Boston, Seattle. , na Huko Vancouver, na wakati mwingine hata huko Moscow, ninazungumza kwenye mikutano. Pia ninaandika mara kwa mara, lakini ninaandika hasa kwa Kiingereza, na tayari nimeandika , pia nina haja ya kushiriki mienendo ya uchanganuzi kutoka Amerika Kaskazini, na wakati mwingine mimi huandika .
Nimekuwa nikifanya kazi na ghala za data kila wakati, na tangu 2015 nilianza kufanya kazi kwa karibu na Huduma za Wavuti za Amazon, na kwa ujumla nikabadilisha uchanganuzi wa wingu (AWS, Azure, GCP). Nimeona mageuzi ya ufumbuzi wa uchanganuzi tangu 2007 na hata nilifanya kazi kwa muuzaji wa ghala la data Teradata na kuitekeleza katika Sberbank, na ndipo Data Kubwa na Hadoop ilionekana. Kila mtu alianza kusema kwamba zama za kuhifadhi zimepita na sasa kila kitu kilikuwa kwenye Hadoop, na kisha wakaanza kuzungumza juu ya Ziwa la Data, tena, kwamba sasa mwisho wa ghala la data ulikuwa umefika. Lakini kwa bahati nzuri (labda kwa bahati mbaya kwa wengine ambao walipata pesa nyingi kuanzisha Hadoop), ghala la data halikuondoka.
Katika makala hii tutaangalia ziwa la data ni nini. Nakala hii imekusudiwa watu ambao hawana uzoefu mdogo au hawana kabisa na maghala ya data.
Pichani ni Lake Bled, hili ni moja kati ya ziwa ninalolipenda japo niliwahi kufika hapo mara moja tu, nililikumbuka maisha yangu yote. Lakini tutazungumza juu ya aina nyingine ya ziwa - ziwa la data. Labda wengi wenu tayari wamesikia juu ya neno hili zaidi ya mara moja, lakini ufafanuzi mmoja zaidi hautamdhuru mtu yeyote.
Kwanza kabisa, hapa kuna ufafanuzi maarufu zaidi wa Ziwa la Data:
"hifadhi ya faili ya aina zote za data mbichi ambayo inapatikana kwa uchambuzi na mtu yeyote katika shirika" - Martin Fowler.
"Ikiwa unafikiria kuwa duka la data ni chupa ya maji - iliyosafishwa, iliyofungwa na kufungwa kwa matumizi rahisi, basi ziwa la data ni hifadhi kubwa ya maji katika hali yake ya asili. Watumiaji, ninaweza kujikusanyia maji, kupiga mbizi ndani kabisa, kuchunguzaβ - James Dixon.
Sasa tunajua kwa hakika kwamba ziwa la data linahusu uchanganuzi, huturuhusu kuhifadhi kiasi kikubwa cha data katika umbo lake la asili na tuna ufikiaji muhimu na unaofaa kwa data.
Mara nyingi napenda kurahisisha mambo, ikiwa ninaweza kuelezea neno ngumu kwa maneno rahisi, basi ninaelewa mwenyewe jinsi inavyofanya kazi na nini inahitajika. Siku moja, nilikuwa nikizunguka kwenye nyumba ya sanaa ya picha ya iPhone, na ikanijia, hili ni ziwa la data halisi, hata nilitengeneza slaidi kwa mikutano:
Kila kitu ni rahisi sana. Tunachukua picha kwenye simu, picha imehifadhiwa kwenye simu na inaweza kuhifadhiwa kwenye iCloud (hifadhi ya faili ya wingu). Simu pia hukusanya metadata ya picha: kinachoonyeshwa, tagi ya kijiografia, wakati. Kama matokeo, tunaweza kutumia kiolesura cha mtumiaji-kirafiki cha iPhone kupata picha yetu na hata tunaona viashiria, kwa mfano, ninapotafuta picha na neno moto, ninapata picha 3 zilizo na picha ya moto. Kwangu mimi, hii ni kama zana ya Ujasusi wa Biashara ambayo inafanya kazi haraka na kwa usahihi.
Na bila shaka, hatupaswi kusahau kuhusu usalama (idhini na uthibitishaji), vinginevyo data yetu inaweza kuishia kwa urahisi kwenye kikoa cha umma. Kuna habari nyingi kuhusu mashirika makubwa na waanzilishi ambao data yao ilipatikana hadharani kwa sababu ya uzembe wa watengenezaji na kushindwa kufuata sheria rahisi.
Hata picha rahisi kama hii inatusaidia kufikiria ziwa la data ni nini, tofauti zake kutoka kwa ghala la jadi la data na vitu vyake kuu:
- Inapakia Data (Kumeza) ni sehemu muhimu ya ziwa la data. Data inaweza kuingia kwenye ghala la data kwa njia mbili - kundi (kupakia kwa vipindi) na kusambaza (mtiririko wa data).
- Hifadhi ya faili (Hifadhi) ndio sehemu kuu ya Ziwa la Data. Tulihitaji hifadhi iwe rahisi kuongezwa, kutegemewa sana na kwa gharama ya chini. Kwa mfano, katika AWS ni S3.
- Katalogi na Utafutaji (Orodha na Utaftaji) - ili tuepuke Dimbwi la data (hii ni wakati tunatupa data yote kwenye rundo moja, na kisha haiwezekani kufanya kazi nayo), tunahitaji kuunda safu ya metadata kuainisha data. ili watumiaji waweze kupata data kwa urahisi, ambayo wanahitaji kwa uchambuzi. Zaidi ya hayo, unaweza kutumia suluhu za ziada za utafutaji kama vile ElasticSearch. Utafutaji humsaidia mtumiaji kupata data inayohitajika kupitia kiolesura kinachofaa mtumiaji.
- Matayarisho (Mchakato) - hatua hii inawajibika kwa usindikaji na kubadilisha data. Tunaweza kubadilisha data, kubadilisha muundo wake, kuitakasa, na mengi zaidi.
- usalama (Usalama) - Ni muhimu kutumia muda juu ya muundo wa usalama wa suluhisho. Kwa mfano, usimbuaji data wakati wa kuhifadhi, usindikaji na upakiaji. Ni muhimu kutumia njia za uthibitishaji na uidhinishaji. Hatimaye, chombo cha ukaguzi kinahitajika.
Kwa mtazamo wa vitendo, tunaweza kuainisha ziwa la data kwa sifa tatu:
- Kusanya na kuhifadhi chochote - ziwa la data lina data zote, data mbichi ambayo haijachakatwa kwa muda wowote na data iliyochakatwa/iliyosafishwa.
- Deep Scan - ziwa la data huruhusu watumiaji kuchunguza na kuchambua data.
- Ufikiaji rahisi - Ziwa la data hutoa ufikiaji rahisi wa data tofauti na hali tofauti.
Sasa tunaweza kuzungumza juu ya tofauti kati ya ghala la data na ziwa la data. Kawaida watu huuliza:
- Vipi kuhusu ghala la data?
- Je, tunabadilisha ghala la data na kuweka ziwa la data au tunalipanua?
- Bado inawezekana kufanya bila ziwa la data?
Kwa kifupi, hakuna jibu wazi. Yote inategemea hali maalum, ujuzi wa timu na bajeti. Kwa mfano, kuhamisha ghala la data hadi Oracle hadi AWS na kuunda ziwa la data na kampuni tanzu ya Amazon - Woot - .
Kwa upande mwingine, muuzaji Snowflake anasema kuwa hauitaji tena kufikiria juu ya ziwa la data, kwani jukwaa lao la data (hadi 2020 lilikuwa ghala la data) hukuruhusu kuchanganya ziwa la data na ghala la data. Sijafanya kazi sana na Snowflake, na kwa kweli ni bidhaa ya kipekee inayoweza kufanya hivi. Bei ya suala ni suala jingine.
Kwa kumalizia, maoni yangu ya kibinafsi ni kwamba bado tunahitaji ghala la data kama chanzo kikuu cha data ya kuripoti kwetu, na chochote kisichofaa tunahifadhi katika ziwa la data. Jukumu zima la uchanganuzi ni kutoa ufikiaji rahisi kwa biashara kufanya maamuzi. Chochote mtu anaweza kusema, watumiaji wa biashara hufanya kazi kwa ufanisi zaidi na ghala la data kuliko ziwa la data, kwa mfano huko Amazon - kuna Redshift (ghala la data ya uchambuzi) na kuna Redshift Spectrum/Athena (kiolesura cha SQL cha ziwa la data katika S3 kulingana na Mzinga/Presto). Vile vile hutumika kwa maghala mengine ya kisasa ya data ya uchambuzi.
Wacha tuangalie usanifu wa kawaida wa ghala la data:
Hii ni suluhisho la classic. Tuna mifumo ya chanzo, kwa kutumia ETL/ELT tunanakili data kwenye ghala la data ya uchanganuzi na kuiunganisha kwenye suluhisho la Business Intelligence (ninachopenda zaidi ni Tableau, vipi kuhusu yako?).
Suluhisho hili lina hasara zifuatazo:
- Shughuli za ETL/ELT zinahitaji wakati na rasilimali.
- Kama sheria, kumbukumbu ya kuhifadhi data kwenye ghala la data ya uchambuzi sio nafuu (kwa mfano, Redshift, BigQuery, Teradata), kwani tunahitaji kununua nguzo nzima.
- Watumiaji wa biashara wanaweza kufikia data iliyosafishwa na iliyojumlishwa mara nyingi na hawana ufikiaji wa data ghafi.
Bila shaka, yote inategemea kesi yako. Ikiwa huna matatizo na ghala lako la data, basi huhitaji ziwa la data hata kidogo. Lakini matatizo yanapotokea na ukosefu wa nafasi, nguvu, au bei ina jukumu muhimu, basi unaweza kuzingatia chaguo la ziwa la data. Hii ndiyo sababu ziwa data ni maarufu sana. Hapa kuna mfano wa usanifu wa ziwa la data:
Kwa kutumia mbinu ya ziwa la data, tunapakia data mbichi kwenye ziwa letu la data (bechi au utiririshaji), kisha tunachakata data inavyohitajika. Ziwa la data huruhusu watumiaji wa biashara kuunda mabadiliko yao ya data (ETL/ELT) au kuchanganua data katika suluhu za Business Intelligence (ikiwa kiendeshi kinachohitajika kinapatikana).
Lengo la suluhisho lolote la uchanganuzi ni kuwahudumia watumiaji wa biashara. Kwa hiyo, lazima tufanye kazi kulingana na mahitaji ya biashara. (Huko Amazon hii ni moja ya kanuni - kufanya kazi nyuma).
Kufanya kazi na ghala la data na ziwa la data, tunaweza kulinganisha suluhisho zote mbili:
Hitimisho kuu ambalo linaweza kutolewa ni kwamba ghala la data halishindani na ziwa la data, lakini badala yake linaikamilisha. Lakini ni juu yako kuamua ni nini kinachofaa kwa kesi yako. Daima ni ya kuvutia kujaribu mwenyewe na kuteka hitimisho sahihi.
Ningependa pia kukuambia moja ya kesi nilipoanza kutumia mbinu ya ziwa la data. Kila kitu ni kidogo sana, nilijaribu kutumia zana ya ELT (tulikuwa na Matillion ETL) na Amazon Redshift, suluhisho langu lilifanya kazi, lakini haikufaa mahitaji.
Nilihitaji kuchukua kumbukumbu za wavuti, kuzibadilisha na kuzikusanya ili kutoa data kwa kesi 2:
- Timu ya uuzaji ilitaka kuchambua shughuli za bot kwa SEO
- IT ilitaka kuangalia vipimo vya utendaji wa tovuti
Rahisi sana, magogo rahisi sana. Hapa kuna mfano:
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" "-" "-"Faili moja ilikuwa na uzito wa megabaiti 1-4.
Lakini kulikuwa na ugumu mmoja. Tulikuwa na vikoa 7 kote ulimwenguni, na faili elfu 7000 ziliundwa kwa siku moja. Hii sio kiasi zaidi, ni gigabytes 50 tu. Lakini saizi ya nguzo yetu ya Redshift pia ilikuwa ndogo (nodi 4). Kupakia faili moja kwa njia ya kitamaduni kulichukua takriban dakika moja. Hiyo ni, shida haikutatuliwa moja kwa moja. Na hii ndio kesi wakati niliamua kutumia mbinu ya ziwa la data. Suluhisho lilionekana kama hii:
Ni rahisi sana (nataka kumbuka kuwa faida ya kufanya kazi kwenye wingu ni unyenyekevu). Nilitumia:
- Kupunguza kwa Ramani ya AWS Elastiki (Hadoop) kwa Nguvu ya Kuhesabu
- AWS S3 kama hifadhi ya faili yenye uwezo wa kusimba data kwa njia fiche na kudhibiti ufikiaji
- Spark kama nguvu ya kompyuta ya InMemory na PySpark kwa mantiki na mabadiliko ya data
- Parquet kama matokeo ya Spark
- AWS Glue Crawler kama mkusanyaji wa metadata kuhusu data na kizigeu kipya
- Redshift Spectrum kama kiolesura cha SQL kwa ziwa la data kwa watumiaji waliopo wa Redshift
Kundi ndogo zaidi la EMR+Spark lilichakata rundo lote la faili kwa dakika 30. Kuna matukio mengine ya AWS, hasa mengi yanayohusiana na Alexa, ambapo kuna data nyingi.
Hivi majuzi nilijifunza moja ya ubaya wa ziwa la data ni GDPR. Shida ni wakati mteja anauliza kuifuta na data iko kwenye faili moja, hatuwezi kutumia Lugha ya Kudanganya Data na operesheni ya KUFUTA kama kwenye hifadhidata.
Natumai nakala hii imefafanua tofauti kati ya ghala la data na ziwa la data. Ikiwa ulipendezwa, naweza kutafsiri makala zangu zaidi au makala za wataalamu nilizosoma. Na pia niambie juu ya suluhisho ninazofanya kazi nazo na usanifu wao.
Chanzo: mapenzi.com