Ang artikulong ito ay pagsasalin ng aking artikulo sa medium - , na naging sikat, marahil dahil sa pagiging simple nito. Samakatuwid, nagpasya akong isulat ito sa Russian at magdagdag ng kaunti upang gawing malinaw sa isang ordinaryong tao na hindi isang espesyalista sa data kung ano ang data warehouse (DW), at kung ano ang data lake (Data Lake), at kung paano sila magkakasama .
Bakit ko gustong magsulat tungkol sa data lake? Mahigit 10 taon na akong nagtatrabaho gamit ang data at analytics, at ngayon ay tiyak na nagtatrabaho ako gamit ang malaking data sa Amazon Alexa AI sa Cambridge, na nasa Boston, bagama't nakatira ako sa Victoria sa Vancouver Island at madalas na bumibisita sa Boston, Seattle , at Sa Vancouver, at kung minsan kahit sa Moscow, nagsasalita ako sa mga kumperensya. Nagsusulat din ako paminsan-minsan, ngunit nagsusulat ako higit sa lahat sa Ingles, at nagsulat na ako , kailangan ko ring magbahagi ng mga trend ng analytics mula sa North America, at kung minsan ay nagsusulat ako .
Palagi akong nagtatrabaho sa mga warehouse ng data, at mula noong 2015 nagsimula akong magtrabaho nang malapit sa Amazon Web Services, at sa pangkalahatan ay lumipat sa cloud analytics (AWS, Azure, GCP). Naobserbahan ko ang ebolusyon ng mga solusyon sa analytics mula noong 2007 at nagtrabaho pa ako para sa vendor ng data warehouse na Teradata at ipinatupad ito sa Sberbank, at doon lumitaw ang Big Data with Hadoop. Ang bawat tao'y nagsimulang sabihin na ang panahon ng imbakan ay lumipas at ngayon ang lahat ay nasa Hadoop, at pagkatapos ay nagsimula silang pag-usapan ang tungkol sa Data Lake, muli, na ngayon ay tiyak na dumating ang katapusan ng data warehouse. Ngunit sa kabutihang palad (marahil sa kasamaang-palad para sa ilan na gumawa ng maraming pera sa pag-set up ng Hadoop), ang data warehouse ay hindi nawala.
Sa artikulong ito titingnan natin kung ano ang data lake. Ang artikulong ito ay inilaan para sa mga taong may kaunti o walang karanasan sa mga warehouse ng data.
Sa larawan ay Lake Bled, isa ito sa mga paborito kong lawa, bagamat isang beses lang ako nandoon, naalala ko ito sa buong buhay ko. Ngunit pag-uusapan natin ang tungkol sa isa pang uri ng lawa - isang lawa ng data. Marahil marami sa inyo ang nakarinig na tungkol sa terminong ito nang higit sa isang beses, ngunit ang isa pang kahulugan ay hindi makakasama sa sinuman.
Una sa lahat, narito ang pinakasikat na mga kahulugan ng Data Lake:
"isang file storage ng lahat ng uri ng raw data na available para sa pagsusuri ng sinuman sa organisasyon" - Martin Fowler.
"Kung sa tingin mo na ang isang data mart ay isang bote ng tubig - nilinis, nakabalot at nakabalot para sa maginhawang pagkonsumo, kung gayon ang isang data lake ay isang malaking reservoir ng tubig sa natural nitong anyo. Mga gumagamit, maaari akong kumuha ng tubig para sa aking sarili, sumisid nang malalim, mag-exploreβ - James Dixon.
Ngayon, sigurado na kaming alam na ang isang data lake ay tungkol sa analytics, nagbibigay-daan ito sa amin na mag-imbak ng malaking halaga ng data sa orihinal nitong anyo at mayroon kaming kinakailangan at maginhawang pag-access sa data.
Madalas kong gustong pasimplehin ang mga bagay, kung maipaliwanag ko ang isang kumplikadong termino sa mga simpleng salita, pagkatapos ay naiintindihan ko para sa aking sarili kung paano ito gumagana at kung ano ang kailangan nito. Isang araw, naglibot ako sa gallery ng larawan ng iPhone, at napagtanto ko, ito ay isang tunay na lawa ng data, gumawa pa ako ng slide para sa mga kumperensya:
Napakasimple ng lahat. Kumuha kami ng larawan sa telepono, naka-save ang larawan sa telepono at maaaring i-save sa iCloud (cloud file storage). Kinokolekta din ng telepono ang metadata ng larawan: kung ano ang ipinapakita, geo tag, oras. Bilang isang resulta, maaari naming gamitin ang user-friendly na interface ng iPhone upang mahanap ang aming larawan at kahit na nakikita namin ang mga tagapagpahiwatig, halimbawa, kapag naghanap ako ng mga larawan na may salitang apoy, nakakita ako ng 3 larawan na may larawan ng apoy. Para sa akin, ito ay parang isang tool sa Business Intelligence na gumagana nang napakabilis at malinaw.
At siyempre, hindi natin dapat kalimutan ang tungkol sa seguridad (awtorisasyon at pagpapatunay), kung hindi, ang ating data ay madaling mapunta sa pampublikong domain. Maraming balita tungkol sa malalaking korporasyon at mga startup na ang data ay naging available sa publiko dahil sa kapabayaan ng mga developer at hindi pagsunod sa mga simpleng panuntunan.
Kahit na ang gayong simpleng larawan ay nakakatulong sa atin na isipin kung ano ang data lake, ang mga pagkakaiba nito mula sa isang tradisyunal na data warehouse at ang mga pangunahing elemento nito:
- Loading data (Ingestion) ay isang mahalagang bahagi ng data lake. Maaaring pumasok ang data sa warehouse ng data sa dalawang paraan - batch (naglo-load sa mga pagitan) at streaming (daloy ng data).
- Imbakan ng file (Storage) ay ang pangunahing bahagi ng Data Lake. Kailangan namin ang storage na madaling scalable, lubos na maaasahan, at mura. Halimbawa, sa AWS ito ay S3.
- Catalog at Paghahanap (Catalog at Search) - upang maiwasan natin ang Data Swamp (ito ay kapag itinapon natin ang lahat ng data sa isang pile, at pagkatapos ay imposibleng magtrabaho kasama ito), kailangan nating lumikha ng metadata layer upang maiuri ang data upang madaling mahanap ng mga user ang data, na kailangan nila para sa pagsusuri. Bilang karagdagan, maaari kang gumamit ng mga karagdagang solusyon sa paghahanap tulad ng ElasticSearch. Tinutulungan ng paghahanap ang user na mahanap ang kinakailangang data sa pamamagitan ng user-friendly na interface.
- Pagproseso (Proseso) - ang hakbang na ito ay responsable para sa pagproseso at pagbabago ng data. Maaari naming baguhin ang data, baguhin ang istraktura nito, linisin ito, at marami pang iba.
- katiwasayan (Seguridad) - Mahalagang gumugol ng oras sa disenyo ng seguridad ng solusyon. Halimbawa, ang pag-encrypt ng data sa panahon ng pag-iimbak, pagproseso at paglo-load. Mahalagang gumamit ng mga paraan ng pagpapatunay at awtorisasyon. Sa wakas, kailangan ang isang tool sa pag-audit.
Mula sa praktikal na pananaw, mailalarawan natin ang isang lawa ng data sa pamamagitan ng tatlong katangian:
- Mangolekta at mag-imbak ng kahit ano β ang data lake ay naglalaman ng lahat ng data, parehong hilaw na hindi naprosesong data para sa anumang yugto ng panahon at naproseso/nalinis na data.
- Deep Scan β nagbibigay-daan ang isang data lake sa mga user na galugarin at suriin ang data.
- Flexible na pag-access β Ang data lake ay nagbibigay ng flexible na access para sa iba't ibang data at iba't ibang mga sitwasyon.
Ngayon ay maaari nating pag-usapan ang pagkakaiba sa pagitan ng isang data warehouse at isang data lake. Karaniwang tinatanong ng mga tao:
- Paano ang data warehouse?
- Pinapalitan ba natin ang data warehouse ng data lake o pinapalawak ba natin ito?
- Posible pa bang gawin nang walang data lake?
Sa madaling salita, walang malinaw na sagot. Ang lahat ay nakasalalay sa tiyak na sitwasyon, ang mga kasanayan ng koponan at ang badyet. Halimbawa, ang paglipat ng data warehouse sa Oracle sa AWS at paggawa ng data lake ng isang subsidiary ng Amazon - Woot - .
Sa kabilang banda, sinabi ng vendor na Snowflake na hindi mo na kailangang mag-isip tungkol sa isang data lake, dahil ang kanilang data platform (hanggang 2020 ay isang data warehouse) na nagbibigay-daan sa iyong pagsamahin ang parehong data lake at isang data warehouse. Hindi pa ako gaanong nagtrabaho sa Snowflake, at ito ay talagang isang natatanging produkto na kayang gawin ito. Ang presyo ng isyu ay ibang usapin.
Bilang konklusyon, ang aking personal na opinyon ay kailangan pa rin namin ng data warehouse bilang pangunahing pinagmumulan ng data para sa aming pag-uulat, at anumang hindi akma ay iniimbak namin sa isang data lake. Ang buong tungkulin ng analytics ay magbigay ng madaling pag-access para sa negosyo upang makagawa ng mga desisyon. Anuman ang maaaring sabihin, ang mga gumagamit ng negosyo ay gumagana nang mas mahusay sa isang data warehouse kaysa sa isang data lake, halimbawa sa Amazon - mayroong Redshift (analytical data warehouse) at mayroong Redshift Spectrum/Athena (SQL interface para sa isang data lake sa S3 batay sa Hive/Presto). Ang parehong naaangkop sa iba pang modernong analytical data warehouses.
Tingnan natin ang isang tipikal na arkitektura ng data warehouse:
Ito ay isang klasikong solusyon. Mayroon kaming mga source system, gamit ang ETL/ELT kinokopya namin ang data sa isang analytical data warehouse at ikinonekta ito sa isang solusyon sa Business Intelligence (paborito ko ang Tableau, paano ang sa iyo?).
Ang solusyon na ito ay may mga sumusunod na kawalan:
- Ang mga operasyon ng ETL/ELT ay nangangailangan ng oras at mapagkukunan.
- Bilang panuntunan, hindi mura ang memory para sa pag-iimbak ng data sa isang analytical data warehouse (halimbawa, Redshift, BigQuery, Teradata), dahil kailangan nating bumili ng isang buong cluster.
- Ang mga user ng negosyo ay may access sa malinis at madalas na pinagsama-samang data at walang access sa raw data.
Siyempre, ang lahat ay nakasalalay sa iyong kaso. Kung wala kang problema sa iyong data warehouse, hindi mo na kailangan ng data lake. Ngunit kapag may mga problemang lumitaw sa kakulangan ng espasyo, kapangyarihan, o presyo ay gumaganap ng isang mahalagang papel, maaari mong isaalang-alang ang opsyon ng isang data lake. Ito ang dahilan kung bakit napakapopular ang data lake. Narito ang isang halimbawa ng arkitektura ng data lake:
Gamit ang diskarte sa data lake, naglo-load kami ng raw data sa aming data lake (batch o streaming), pagkatapos ay pinoproseso namin ang data kung kinakailangan. Ang data lake ay nagbibigay-daan sa mga user ng negosyo na gumawa ng sarili nilang mga pagbabago sa data (ETL/ELT) o magsuri ng data sa mga solusyon sa Business Intelligence (kung available ang kinakailangang driver).
Ang layunin ng anumang solusyon sa analytics ay upang pagsilbihan ang mga user ng negosyo. Samakatuwid, dapat tayong palaging magtrabaho ayon sa mga kinakailangan sa negosyo. (Sa Amazon ito ay isa sa mga prinsipyo - nagtatrabaho pabalik).
Paggawa gamit ang isang data warehouse at isang data lake, maaari naming ihambing ang parehong mga solusyon:
Ang pangunahing konklusyon na maaaring iguguhit ay ang data warehouse ay hindi nakikipagkumpitensya sa data lake, ngunit sa halip ay pinupunan ito. Ngunit nasa sa iyo na magpasya kung ano ang tama para sa iyong kaso. Palaging kawili-wiling subukan ito sa iyong sarili at gumawa ng mga tamang konklusyon.
Gusto ko ring sabihin sa iyo ang isa sa mga kaso noong nagsimula akong gumamit ng diskarte sa data lake. Ang lahat ay medyo walang halaga, sinubukan kong gumamit ng ELT tool (mayroon kaming Matillion ETL) at Amazon Redshift, gumana ang aking solusyon, ngunit hindi umangkop sa mga kinakailangan.
Kailangan kong kumuha ng mga web log, baguhin ang mga ito at pagsama-samahin ang mga ito upang magbigay ng data para sa 2 kaso:
- Gusto ng marketing team na suriin ang aktibidad ng bot para sa SEO
- Nais ng IT na tingnan ang mga sukatan ng pagganap ng website
Napakasimple, napakasimpleng mga log. Narito ang isang halimbawa:
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" "-" "-"Ang isang file ay tumitimbang ng 1-4 megabytes.
Ngunit may isang kahirapan. Mayroon kaming 7 domain sa buong mundo, at 7000 libong file ang nalikha sa isang araw. Ito ay hindi mas maraming volume, 50 gigabytes lamang. Ngunit ang laki ng aming Redshift cluster ay maliit din (4 na node). Humigit-kumulang isang minuto ang pag-load ng isang file sa tradisyonal na paraan. Iyon ay, ang problema ay hindi nalutas nang direkta. At ito ang kaso noong nagpasya akong gamitin ang diskarte sa data lake. Ang solusyon ay mukhang ganito:
Ito ay medyo simple (Gusto kong tandaan na ang bentahe ng pagtatrabaho sa cloud ay pagiging simple). ginamit ko:
- AWS Elastic Map Reduce (Hadoop) para sa Compute Power
- AWS S3 bilang imbakan ng file na may kakayahang mag-encrypt ng data at limitahan ang pag-access
- Spark bilang InMemory computing power at PySpark para sa logic at pagbabago ng data
- Parquet bilang resulta ng Spark
- AWS Glue Crawler bilang isang metadata collector tungkol sa bagong data at mga partisyon
- Redshift Spectrum bilang isang interface ng SQL sa lawa ng data para sa mga kasalukuyang gumagamit ng Redshift
Pinoproseso ng pinakamaliit na EMR+Spark cluster ang buong stack ng mga file sa loob ng 30 minuto. Mayroong iba pang mga kaso para sa AWS, lalo na maraming nauugnay sa Alexa, kung saan mayroong maraming data.
Kamakailan lang nalaman ko ang isa sa mga disadvantage ng isang data lake ay ang GDPR. Ang problema ay kapag hiniling ng kliyente na tanggalin ito at ang data ay nasa isa sa mga file, hindi namin magagamit ang Data Manipulation Language at DELETE na operasyon tulad ng sa isang database.
Umaasa ako na ang artikulong ito ay nilinaw ang pagkakaiba sa pagitan ng isang data warehouse at isang data lake. Kung interesado ka, maaari kong isalin ang higit pa sa aking mga artikulo o artikulo ng mga propesyonal na nabasa ko. At sabihin din ang tungkol sa mga solusyon na pinagtatrabahuhan ko at ang kanilang arkitektura.
Pinagmulan: www.habr.com