Tulisan ieu mangrupikeun tarjamahan tina tulisan kuring ngeunaan medium - , nu tétéla cukup populér, meureun kusabab kesederhanaan na. Ku alatan éta, kuring megatkeun pikeun nulis dina basa Rusia jeung nambahan saeutik pikeun nyieun jelas ka jalma biasa anu lain spesialis data naon gudang data (DW), sarta naon danau data (Data Lake), sarta kumaha aranjeunna. kumpul bareng.
Naha kuring hayang nulis ngeunaan danau data? Kuring parantos damel sareng data sareng analitik langkung ti 10 taun, sareng ayeuna kuring pasti damel sareng data ageung di Amazon Alexa AI di Cambridge, anu aya di Boston, sanaos kuring cicing di Victoria di Pulo Vancouver sareng sering nganjang ka Boston, Seattle. , sarta Dina Vancouver, sarta sakapeung malah di Moscow, abdi nyarita dina konferensi. Kuring ogé nulis ti jaman ka jaman, tapi kuring nulis utamana dina basa Inggris, sarta kuring geus ditulis , Kuring ogé kudu babagi tren analytics ti Amérika Kalér, sarta kuring kadang nulis dina .
Kuring geus salawasna digarap kalawan gudang data, sarta saprak 2015 kuring mimiti gawé raket jeung Amazon Web Services, sarta umumna switched ka analytics awan (AWS, Azure, GCP). Kuring geus katalungtik évolusi solusi analytics saprak 2007 komo digawé pikeun ngajual gudang data Teradata sarta dilaksanakeun di Sberbank, sarta éta nalika Big Data kalawan Hadoop mucunghul. Sarerea mimiti nyebutkeun yén jaman gudang geus kaliwat tur ayeuna sagalana geus on Hadoop, lajeng aranjeunna mimiti ngobrol ngeunaan Data Lake, deui, yén ayeuna tungtung gudang data geus pasti datang. Tapi untungna (meureun hanjakalna pikeun sabagian anu nyieun loba duit nyetel Hadoop), gudang data teu indit.
Dina artikel ieu kami baris kasampak di naon danau data. Artikel ieu dimaksudkeun pikeun jalma anu boga saeutik atawa euweuh pangalaman jeung gudang data.
Dina gambar éta Lake Bled, ieu téh salah sahiji situ favorit kuring, sanajan kuring aya ngan sakali, Kuring inget eta pikeun sesa hirup abdi. Tapi urang bakal ngobrol ngeunaan tipe séjén danau - a data lake. Panginten seueur anjeun parantos ngupingkeun istilah ieu langkung ti sakali, tapi hiji deui definisi moal ngarugikeun saha waé.
Anu mimiti, ieu mangrupikeun definisi anu paling populér pikeun Data Lake:
"Panyimpen file sadaya jinis data atah anu sayogi pikeun dianalisis ku saha waé dina organisasi" - Martin Fowler.
"Upami anjeun nganggap yén data mart mangrupikeun botol cai - dimurnikeun, dibungkus sareng dibungkus pikeun konsumsi anu gampang, maka danau data mangrupikeun waduk cai anu ageung dina bentuk alami. Pamaké, abdi tiasa ngumpulkeun cai keur diri, teuleum jero, ngajajah "- James Dixon.
Ayeuna urang terang pasti yén danau data ngeunaan analytics, éta ngamungkinkeun urang pikeun nyimpen data anu ageung dina bentuk aslina sareng urang gaduh aksés anu diperyogikeun sareng merenah kana data.
Kuring sering resep nyederhanakeun hal-hal, upami kuring tiasa ngajelaskeun istilah anu kompleks dina kecap-kecap anu saderhana, maka kuring ngartos sorangan kumaha jalanna sareng naon anu diperyogikeun. Hiji poé, kuring keur poking sabudeureun dina galeri poto iPhone, sarta éta dawned on kuring, ieu téh mangrupa danau data nyata, Kuring malah nyieun slide pikeun konferensi:
Sagalana basajan pisan. Kami nyandak poto dina telepon, poto disimpen dina telepon sareng tiasa disimpen ka iCloud (panyimpen file awan). Telepon ogé ngumpulkeun metadata poto: naon anu dipidangkeun, tag geo, waktos. Hasilna, urang tiasa nganggo antarbeungeut iPhone anu ramah-pamaké pikeun milarian poto urang sareng urang ningali indikator, contona, nalika kuring milarian poto nganggo kecap seuneu, kuring mendakan 3 poto kalayan gambar seuneu. Pikeun kuring, ieu sapertos alat Business Intelligence anu jalanna gancang sareng jelas.
Sarta tangtu, urang teu kudu poho ngeunaan kaamanan (otorisasi jeung auténtikasi), disebutkeun data urang bisa kalayan gampang mungkas nepi di domain publik. Aya seueur warta ngeunaan korporasi ageung sareng startup anu datana sayogi umum kusabab lalawora pamekar sareng gagal nuturkeun aturan anu sederhana.
Malah gambar saderhana sapertos ngabantosan urang ngabayangkeun naon éta danau data, bédana tina gudang data tradisional sareng elemen utami:
- Ngamuat Data (Ingestion) mangrupakeun komponén konci tina danau data. Data bisa asup ka gudang data ku dua cara - bets (loading dina interval) jeung streaming (aliran data).
- Panyimpenan file (Panyimpenan) mangrupakeun komponén utama Data Lake. Kami peryogi panyimpen janten gampang skala, dipercaya pisan, sareng béaya rendah. Contona, dina AWS éta S3.
- Katalog jeung Pilarian (Katalog sareng Milarian) - supados urang ngahindarkeun Data Rawa (ieu nalika urang ngalungkeun sadaya data dina hiji tumpukan, teras teu mungkin pikeun dianggo), urang kedah nyiptakeun lapisan metadata pikeun mengklasifikasikan data. ku kituna pamaké bisa kalayan gampang manggihan data, nu maranéhna butuh pikeun analisis. Salaku tambahan, anjeun tiasa nganggo solusi milarian tambahan sapertos ElasticSearch. Pilarian ngabantosan pangguna milarian data anu diperyogikeun ngalangkungan antarmuka anu ramah-pamaké.
- carana ngokolakeun (Prosés) - léngkah ieu tanggung jawab pikeun ngolah sareng ngarobih data. Urang tiasa ngarobih data, ngarobih strukturna, ngabersihan, sareng seueur deui.
- kasalametan (Kaamanan) - Kadé méakkeun waktu dina rarancang kaamanan solusi. Contona, énkripsi data nalika neundeun, ngolah sareng ngamuat. Penting pikeun ngagunakeun metode auténtikasi sareng otorisasi. Tungtungna, alat audit diperyogikeun.
Tina sudut pandang praktis, urang tiasa ngacirian danau data ku tilu atribut:
- Kumpulkeun sareng simpen naon waé - danau data ngandung sakabéh data, duanana data unprocessed atah pikeun sagala periode waktu jeung diolah / data diberesihkeun.
- Jero Scan - danau data ngamungkinkeun pamaké pikeun ngajalajah sareng nganalisis data.
- aksés fléksibel - Danau data nyayogikeun aksés anu fleksibel pikeun data anu béda sareng skénario anu béda.
Ayeuna urang tiasa ngobrol ngeunaan bédana antara gudang data sareng danau data. Biasana jalma nanya:
- Kumaha upami gudang data?
- Naha urang ngagentos gudang data sareng danau data atanapi urang ngalegaan?
- Naha masih tiasa dilakukeun tanpa danau data?
Pondokna, teu aya jawaban anu jelas. Éta sadayana gumantung kana kaayaan spésifik, kaahlian tim sareng anggaran. Salaku conto, migrasi gudang data ka Oracle ka AWS sareng nyiptakeun danau data ku anak perusahaan Amazon - Woot - .
Di sisi anu sanés, padagang Snowflake nyarios yén anjeun henteu kedah mikirkeun danau data, sabab platform datana (dugi ka 2020 éta gudang data) ngamungkinkeun anjeun ngagabungkeun dua danau data sareng gudang data. Kuring henteu acan damel sareng Snowflake, sareng éta mangrupikeun produk unik anu tiasa ngalakukeun ieu. Harga masalahna mangrupikeun masalah sanés.
Kacindekanana, pendapat pribadi kuring nyaéta yén urang masih peryogi gudang data salaku sumber data utama pikeun ngalaporkeun urang, sareng naon waé anu henteu pas urang simpen dina danau data. Sakabeh peran analytics nyaéta nyadiakeun aksés gampang pikeun bisnis keur nyieun kaputusan. Naon waé anu dicarioskeun, pangguna bisnis damel langkung éfisién sareng gudang data tibatan danau data, contona di Amazon - aya Redshift (gudang data analitik) sareng aya Redshift Spectrum/Athena (antarmuka SQL pikeun danau data di S3 dumasar kana Hive / Presto). Sami manglaku ka gudang data analitik modern lianna.
Hayu urang nempo arsitektur gudang data has:
Ieu mangrupikeun solusi klasik. Kami ngagaduhan sistem sumber, nganggo ETL / ELT kami nyalin data kana gudang data analitik sareng sambungkeun kana solusi Business Intelligence (paporit abdi nyaéta Tableau, kumaha upami anjeun?).
Solusi ieu ngagaduhan kalemahan di handap ieu:
- Operasi ETL/ELT merlukeun waktu jeung sumber.
- Sakumaha aturan, mémori pikeun nyimpen data dina gudang data analitik teu mirah (Contona, Redshift, BigQuery, Teradata), saprak urang kudu meuli sakabéh klaster.
- Pamaké bisnis boga aksés ka cleaned tur mindeng aggregated data sarta teu boga aksés ka data atah.
Tangtosna, éta sadayana gumantung kana kasus anjeun. Upami anjeun teu ngagaduhan masalah sareng gudang data anjeun, maka anjeun henteu peryogi danau data pisan. Tapi lamun masalah timbul kalawan kurangna spasi, kakuatan, atawa harga muterkeun hiji peran konci, mangka anjeun bisa mertimbangkeun pilihan hiji danau data. Ieu sababna danau data populer pisan. Ieu conto arsitektur danau data:
Ngagunakeun pendekatan data lake, urang muka data atah kana situ data urang (angkatan atawa streaming), lajeng urang ngolah data sakumaha diperlukeun. Danau data ngamungkinkeun pamaké bisnis nyieun transformasi data sorangan (ETL / ELT) atawa nganalisis data dina solusi Business Intelligence (lamun supir diperlukeun sadia).
Tujuan tina sagala solusi analytics nyaéta pikeun ngalayanan pangguna bisnis. Ku alatan éta, urang kudu salawasna dianggo nurutkeun syarat bisnis. (Di Amazon ieu mangrupikeun salah sahiji prinsip - damel mundur).
Gawe sareng gudang data sareng danau data, urang tiasa ngabandingkeun duanana solusi:
Kacindekan utama anu tiasa ditarik nyaéta yén gudang data henteu bersaing sareng danau data, tapi langkung ngalengkepanana. Tapi terserah anjeun mutuskeun naon anu pas pikeun kasus anjeun. Éta salawasna metot pikeun nyobaan eta diri jeung ngagambar conclusions katuhu.
Abdi ogé hoyong nyarioskeun ka anjeun salah sahiji kasus nalika kuring mimiti nganggo pendekatan data danau. Sagalana rada trivial, Kuring diusahakeun make hiji alat ELT (urang tadi Matillion ETL) jeung Amazon Redshift, solusi kuring digawé, tapi teu cocog sarat.
Abdi peryogi nyandak log wéb, ngarobih aranjeunna sareng agrégat pikeun nyayogikeun data pikeun 2 kasus:
- Tim pamasaran hayang nganalisis aktivitas bot pikeun SEO
- IT hoyong ningali métrik kinerja situs wéb
Saderhana pisan, log saderhana pisan. Ieu conto:
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" "-" "-"Hiji file beuratna 1-4 megabyte.
Tapi aya hiji kasusah. Kami ngagaduhan 7 domain di sakumna dunya, sareng 7000 rébu file didamel dina hiji dinten. Ieu henteu langkung seueur volume, ngan ukur 50 gigabyte. Tapi ukuran klaster Redshift urang ogé leutik (4 titik). Ngamuat hiji file dina cara tradisional nyandak ngeunaan hiji menit. Hartina, masalahna teu direngsekeun langsung. Sareng ieu kasus nalika kuring mutuskeun pikeun ngagunakeun pendekatan danau data. Solusina katingali sapertos kieu:
Éta cukup saderhana (Abdi hoyong dicatet yén kauntungan damel di awan nyaéta kesederhanaan). Kuring dipaké:
- AWS Elastic Map Reduce (Hadoop) pikeun Daya Itung
- AWS S3 salaku gudang file kalawan kamampuhan pikeun encrypt data sarta aksés wates
- Spark salaku kakuatan komputasi InMemory sareng PySpark pikeun logika sareng transformasi data
- Parquet salaku hasil tina Spark
- AWS Glue Crawler salaku kolektor metadata ngeunaan data sareng partisi anyar
- Redshift Spéktrum salaku panganteur SQL ka danau data pikeun pamaké Redshift aya
Kluster EMR+Spark pangleutikna ngolah sakabéh tumpukan file dina 30 menit. Aya kasus séjén pikeun AWS, utamana loba patali jeung Alexa, dimana aya loba data.
Ngan nembe kuring diajar salah sahiji kalemahan danau data nyaéta GDPR. Masalahna nyaéta nalika klien naroskeun pikeun ngahapus sareng datana aya dina salah sahiji file, urang henteu tiasa nganggo Basa Manipulasi Data sareng operasi DELETE sapertos dina database.
Kuring miharep artikel ieu geus netelakeun bédana antara gudang data jeung danau data. Upami anjeun kabetot, abdi tiasa narjamahkeun langkung seueur artikel atanapi artikel profésional anu kuring baca. Sareng ogé nyarioskeun ngeunaan solusi anu kuring damel sareng arsitékturna.
sumber: www.habr.com