Artikel iki minangka terjemahan saka artikelku ing medium - , sing dadi cukup populer, mbokmenawa amarga kesederhanaan. Mulane, aku mutusaké kanggo nulis ing basa Rusia lan nambah sethitik kanggo nggawe cetha kanggo wong biasa sing dudu spesialis data apa data warehouse (DW), lan apa data lake (Data Lake), lan carane padha. kumpul bareng.
Napa aku pengin nulis babagan data lake? Aku wis nggarap data lan analytics luwih saka 10 taun, lan saiki aku mesthi nggarap data gedhe ing Amazon Alexa AI ing Cambridge, yaiku ing Boston, sanajan aku manggon ing Victoria ing Pulo Vancouver lan asring ngunjungi Boston, Seattle. , lan Ing Vancouver, lan kadhangkala malah ing Moskow, aku ngomong ing konferensi. Aku uga nulis saka wektu kanggo wektu, nanging aku nulis utamané ing Inggris, lan aku wis nulis , Aku uga kudu nuduhake tren analytics saka Amerika Utara, lan aku kadhangkala nulis ing .
Aku tansah kerja karo gudang data, lan wiwit taun 2015, aku wiwit kerja rapet karo Amazon Web Services, lan umume ngalih menyang analytics awan (AWS, Azure, GCP). Aku wis diamati évolusi saka solusi analytics wiwit 2007 lan malah makarya kanggo data warehouse vendor Teradata lan dipun ginakaken ing Sberbank, lan nalika Big Data karo Hadoop muncul. Saben uwong wiwit ngomong yen jaman panyimpenan wis liwati lan saiki kabeh ana ing Hadoop, banjur wiwit ngomong babagan Data Lake, maneh, yen saiki wis rampung gudang data. Nanging untunge (mungkin sayangé kanggo sawetara sing nggawe akeh dhuwit kanggo nyetel Hadoop), gudang data ora ilang.
Ing artikel iki kita bakal nliti apa data lake. Artikel iki ditujokake kanggo wong sing duwe pengalaman sethithik utawa ora ana ing gudang data.
Ing gambar iku Lake Bled, iki salah siji saka tlaga favorit, sanajan aku ana mung sapisan, Aku elinga kanggo liyane gesang kawula. Nanging kita bakal ngomong babagan jinis tlaga liyane - data lake. Mbok menawa akeh sing wis krungu bab istilah iki luwih saka sapisan, nanging definisi liyane ora bakal cilaka sapa.
Kaping pisanan, iki minangka definisi Data Lake sing paling populer:
"simpenan file kabeh jinis data mentah sing kasedhiya kanggo dianalisis dening sapa wae ing organisasi" - Martin Fowler.
"Yen sampeyan mikir yen data mart minangka botol banyu - diresiki, dikemas lan dikemas kanggo konsumsi sing trep, mula tlaga data minangka reservoir banyu sing gedhe banget ing wangun alami. Pangguna, aku bisa ngumpulake banyu kanggo awake dhewe, nyilem jero, njelajah ”- James Dixon.
Saiki kita ngerti manawa tlaga data babagan analytics, ngidini kita nyimpen akeh data ing wangun asli lan kita duwe akses sing perlu lan trep kanggo data kasebut.
Aku kerep seneng nyederhanakake samubarang, yen aku bisa nerangake istilah sing rumit kanthi tembung sing prasaja, mula aku ngerti dhewe carane kerjane lan apa sing dibutuhake. Sawijining dina, aku ngubengi galeri foto iPhone, lan aku ngerti, iki tlaga data nyata, aku malah nggawe slide kanggo konferensi:
Kabeh iku prasaja banget. Kita njupuk foto ing telpon, foto disimpen ing telpon lan bisa disimpen menyang iCloud (panyimpenan file awan). Telpon uga ngumpulake metadata foto: apa sing ditampilake, tag geo, wektu. Akibaté, kita bisa nggunakake antarmuka pangguna-loropaken saka iPhone kanggo nemokake foto kita lan kita malah ndeleng pratondho, contone, nalika aku nggoleki foto karo tembung geni, aku nemokake 3 foto karo gambar geni. Kanggo kula, iki kaya alat Business Intelligence sing bisa digunakake kanthi cepet lan cetha.
Lan mesthi, kita ora kudu lali babagan keamanan (wewenang lan otentikasi), yen ora, data kita bisa gampang ana ing domain umum. Ana akeh kabar babagan perusahaan gedhe lan startup sing data dadi kasedhiya kanggo publik amarga kelalaian para pangembang lan gagal ngetutake aturan sing prasaja.
Malah gambar sing prasaja mbantu kita mbayangno apa tlaga data, bedane saka gudang data tradisional lan unsur utama:
- Loading Data (Ingestion) minangka komponèn kunci saka tlaga data. Data bisa mlebu ing gudang data kanthi rong cara - batch (munggah kanthi interval) lan streaming (aliran data).
- Panyimpenan file (Panyimpenan) minangka komponen utama Data Lake. Kita butuh panyimpenan supaya gampang diukur, bisa dipercaya, lan murah. Contone, ing AWS iku S3.
- Katalog lan Panelusuran (Katalog lan Panelusuran) - supaya kita bisa ngindhari Data Swamp (iki nalika kita mbucal kabeh data ing siji tumpukan, banjur ora bisa digunakake), kita kudu nggawe lapisan metadata kanggo klasifikasi data. supaya pangguna bisa gampang golek data, kang padha perlu kanggo analisis. Kajaba iku, sampeyan bisa nggunakake solusi telusuran tambahan kayata ElasticSearch. Panelusuran mbantu pangguna nemokake data sing dibutuhake liwat antarmuka sing ramah pangguna.
- Processing (Proses) - langkah iki tanggung jawab kanggo ngolah lan ngowahi data. Kita bisa ngowahi data, ngganti struktur, ngresiki, lan liya-liyane.
- Keamanan (Keamanan) - Iku penting kanggo nglampahi wektu ing desain keamanan solusi. Contone, enkripsi data sajrone panyimpenan, pangolahan lan loading. Penting kanggo nggunakake cara otentikasi lan wewenang. Pungkasan, alat audit dibutuhake.
Saka sudut pandang praktis, kita bisa menehi ciri tlaga data kanthi telung atribut:
- Nglumpukake lan nyimpen apa wae - tlaga data ngemot kabeh data, data mentah sing durung diproses kanggo wektu apa wae lan data sing wis diproses / diresiki.
- Deep Scan - tlaga data ngidini pangguna njelajah lan nganalisa data.
- Akses fleksibel - Tlaga data nyedhiyakake akses fleksibel kanggo macem-macem data lan skenario sing beda.
Saiki kita bisa ngomong babagan bedane data warehouse lan data lake. Biasane wong takon:
- Apa babagan gudang data?
- Apa kita ngganti gudang data kanthi tlaga data utawa kita nggedhekake?
- Apa isih bisa ditindakake tanpa data lake?
Ing cendhak, ora ana jawaban sing jelas. Iku kabeh gumantung ing kahanan tartamtu, skills saka tim lan budget. Contone, migrasi gudang data menyang Oracle menyang AWS lan nggawe tlaga data dening anak perusahaan Amazon - Woot - .
Ing sisih liya, vendor Snowflake ujar manawa sampeyan ora perlu mikir babagan tlaga data, amarga platform data kasebut (nganti taun 2020 minangka gudang data) ngidini sampeyan nggabungake tlaga data lan gudang data. Aku wis ora kerjo akeh karo Snowflake, lan iku saestu produk unik sing bisa nindakake iki. Rega saka masalah iku prakara liyane.
Pungkasane, panemuku pribadi yaiku kita isih butuh gudang data minangka sumber data utama kanggo laporan, lan apa wae sing ora cocog kita simpen ing tlaga data. Peran kabeh analytics yaiku nyedhiyakake akses gampang kanggo bisnis nggawe keputusan. Apa wae sing bisa dikandhakake, pangguna bisnis bisa luwih efisien karo gudang data tinimbang tlaga data, umpamane ing Amazon - ana Redshift (gudang data analitik) lan ana Redshift Spectrum/Athena (antarmuka SQL kanggo tlaga data ing S3 adhedhasar Hive/Presto). Padha ditrapake kanggo gudang data analitis modern liyane.
Ayo ndeleng arsitektur gudang data sing khas:
Iki minangka solusi klasik. Kita duwe sistem sumber, nggunakake ETL / ELT, kita nyalin data menyang gudang data analitis lan nyambung menyang solusi Business Intelligence (favoritku yaiku Tableau, kepiye sampeyan?).
Solusi iki nduweni kekurangan ing ngisor iki:
- Operasi ETL/ELT mbutuhake wektu lan sumber daya.
- Minangka aturan, memori kanggo nyimpen data ing gudang data analitis ora mirah (contone, Redshift, BigQuery, Teradata), awit kita kudu tuku kabeh kluster.
- Pangguna bisnis duwe akses menyang data sing diresiki lan asring dikumpulake lan ora duwe akses menyang data mentah.
Mesthi, kabeh gumantung ing kasus sampeyan. Yen sampeyan ora duwe masalah karo gudang data, mula sampeyan ora butuh data lake. Nanging yen ana masalah amarga kekurangan ruang, daya, utawa rega duwe peran penting, mula sampeyan bisa nimbang pilihan tlaga data. Iki sebabe tlaga data populer banget. Punika conto arsitektur data lake:
Nggunakake pendekatan data lake, kita mbukak data mentah menyang data lake (batch utawa streaming), banjur ngolah data yen perlu. Data lake ngidini pangguna bisnis nggawe transformasi data dhewe (ETL / ELT) utawa nganalisa data ing solusi Business Intelligence (yen driver sing dibutuhake kasedhiya).
Tujuan saka solusi analytics yaiku kanggo nglayani pangguna bisnis. Mulane, kita kudu tansah makarya miturut syarat bisnis. (Ing Amazon iki minangka salah sawijining prinsip - kerja mundur).
Nggarap data warehouse lan data lake, kita bisa mbandhingake loro solusi kasebut:
Kesimpulan utama sing bisa ditarik yaiku data warehouse ora saingan karo data lake, nanging nglengkapi. Nanging sampeyan kudu mutusake apa sing cocog kanggo kasus sampeyan. Iku tansah menarik kanggo nyoba dhewe lan nggawe kesimpulan sing bener.
Aku uga pengin ngandhani salah sawijining kasus nalika miwiti nggunakake pendekatan data lake. Kabeh iku cukup ora pati penting, Aku nyoba kanggo nggunakake alat ELT (kita wis Matillion ETL) lan Amazon Redshift, solusi sandi makarya, nanging ora cocog karo syarat.
Aku kudu njupuk log web, ngowahi lan nglumpukake kanggo nyedhiyakake data kanggo 2 kasus:
- Tim marketing pengin nganalisa aktivitas bot kanggo SEO
- IT pengin ndeleng metrik kinerja situs web
Prasaja banget, log banget prasaja. Iki contone:
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" "-" "-"Siji file bobote 1-4 megabyte.
Nanging ana siji kangelan. Kita duwe 7 domain ing saindenging jagad, lan 7000 ewu file digawe sajrone sedina. Iki ora luwih volume, mung 50 gigabyte. Nanging ukuran kluster Redshift kita uga cilik (4 simpul). Ngunggah siji file kanthi cara tradisional njupuk kira-kira sak menit. Tegese, masalah kasebut ora ditanggulangi langsung. Lan iki kedadeyan nalika aku mutusake nggunakake pendekatan data lake. Solusi katon kaya iki:
Iku cukup prasaja (Aku pengin Wigati sing kauntungan saka makarya ing maya punika gamblang). Tak nggo:
- AWS Elastic Map Reduce (Hadoop) kanggo Compute Power
- AWS S3 minangka panyimpenan file kanthi kemampuan kanggo ndhelik data lan matesi akses
- Spark minangka daya komputasi InMemory lan PySpark kanggo logika lan transformasi data
- Parket minangka asil saka Spark
- AWS Glue Crawler minangka kolektor metadata babagan data lan partisi anyar
- Redshift Spectrum minangka antarmuka SQL menyang tlaga data kanggo pangguna Redshift sing ana
Kluster EMR+Spark sing paling cilik ngolah tumpukan file sajrone 30 menit. Ana kasus liyane kanggo AWS, utamane akeh sing gegandhengan karo Alexa, ing ngendi ana akeh data.
Mung bubar aku sinau salah siji saka cacat saka data lake punika GDPR. Masalahe yaiku nalika klien njaluk mbusak lan data kasebut ana ing salah sawijining file, kita ora bisa nggunakake Basa Manipulasi Data lan operasi DELETE kaya ing database.
Mugi artikel iki wis njlentrehake prabédan antarane data warehouse lan data lake. Yen sampeyan kasengsem, aku bisa nerjemahake luwih akeh artikel utawa artikel profesional sing dakwaca. Lan uga nyritakake babagan solusi sing dakgarap lan arsitekture.
Source: www.habr.com