Urang hirup dina waktos anu luar biasa nalika anjeun tiasa gancang sareng gampang nyambungkeun sababaraha alat open-source anu siap-siap, atur sareng "kasadaran dipareuman" anjeun numutkeun naséhat stackoverflow, tanpa ngagali kana "sababaraha hurup", sareng peluncuran. aranjeunna kana operasi komérsial. Sareng nalika anjeun kedah ngapdet / ngalegaan atanapi aya anu ngahaja reboot sababaraha mesin - anjeun sadar yén sababaraha jinis impian anu obsesip parantos dimimitian dina kanyataan, sadayana ujug-ujug janten langkung pajeulit di luar pangakuan, teu aya anu balik deui, masa depan samar. tur leuwih aman, tinimbang programming, breed lebah sarta ngalakukeun kéju.
Henteu ngan ukur kolega anu langkung berpengalaman, kalayan sirahna kutup sareng ku kituna parantos kulawu, mikirkeun panyebaran bungkus "wadah" anu luar biasa gancang dina "kubus" dina puluhan server dina "basa modéren" kalayan dukungan anu diwangun pikeun Asynchronous non-blocking I / O, seuri modestly. Jeung maranéhna cicingeun neruskeun ulang maca "lalaki ps", delve kana "nginx" kode sumber dugi panon maranéhna getihan, jeung nulis, nulis, nulis tés Unit. Kolega anjeun terang yén hal anu paling pikaresepeun bakal sumping nalika "sadayana ieu" hiji dinten janten staked wengi dina Hawa Taun Anyar. Jeung maranéhna ngan bakal mantuan ku pamahaman jero ngeunaan alam unix, TCP / IP tabel kaayaan memorized sarta algoritma asihan-search dasar. Pikeun ngahirupkeun deui sistem nalika hurung.
Oh enya, kuring meunang saeutik kacau, tapi kuring miharep kuring junun nepikeun kaayaan diantisipasi.
Dinten abdi hoyong bagikeun pangalaman urang dina deploying tumpukan merenah tur murah pikeun DataLake, nu solves mayoritas tugas analitik di parusahaan keur divisi struktural lengkep béda.
Sababaraha waktu ka tukang, urang datang ka pamahaman yén pausahaan beuki butuh bungbuahan duanana produk na analytics teknis (teu nyebut icing on jajan dina bentuk learning mesin) jeung ngartos tren na resiko - urang kudu ngumpulkeun jeung nganalisis. beuki loba metrics.
Analisis téknis dasar dina Bitrix24
Sababaraha taun ka pengker, sakaligus sareng peluncuran jasa Bitrix24, kami aktip investasi waktos sareng sumber dina nyiptakeun platform analitik anu sederhana sareng dipercaya anu bakal ngabantosan gancang ningali masalah dina infrastruktur sareng ngarencanakeun léngkah salajengna. Tangtosna, éta sasaena nyandak alat anu siap-siap anu saderhana sareng kaharti-gancang. Hasilna, nagios dipilih pikeun ngawaskeun sareng munin pikeun analytics sareng visualisasi. Ayeuna kami gaduh rébuan cék di nagios, ratusan grafik di munin, sareng kolega kami nganggo éta suksés unggal dinten. Métrikna écés, grafikna écés, sistemna parantos tiasa dianggo reliably salami sababaraha taun sareng tés sareng grafik énggal-énggal ditambihan ka dinya: nalika urang nempatkeun jasa énggal, urang nambihan sababaraha tés sareng grafik. Sing salamet.
Ramo dina Pulse - Advanced Téknis Analytics
Kahayang pikeun nampi inpormasi ngeunaan masalah "gancang-gancang" nyababkeun urang kana ékspérimén aktip kalayan alat anu sederhana sareng kaharti - pinba sareng xhprof.
Pinba dikirim kami statistik dina pakét UDP ngeunaan laju operasi bagéan kaca web di PHP, sarta kami bisa ningali online di gudang MySQL (Pinba hadir kalawan mesin MySQL sorangan pikeun analytics acara gancang) daptar pondok tina masalah jeung ngabales aranjeunna. Sareng xhprof otomatis ngijinkeun kami pikeun ngumpulkeun grafik palaksanaan halaman PHP anu paling laun ti klien sareng nganalisis naon anu tiasa ngakibatkeun ieu - tenang, tuang tea atanapi anu langkung kuat.
Sababaraha waktu ka tukang, toolkit ieu replenished kalawan mesin sejen cukup basajan tur kaharti dumasar kana algoritma indexing sabalikna, sampurna dilaksanakeun dina perpustakaan Lucene legendaris - elastis / Kibana. Gagasan saderhana pikeun ngarékam dokumén multi-threaded kana indéks Lucene tibalik dumasar kana kajadian dina log sareng panéangan gancang ngaliwatan éta nganggo divisi facet tétéla mangpaat pisan.
Sanaos tampilan visualisasi anu rada téknis di Kibana kalayan konsép tingkat rendah sapertos "ember" "ngalir ka luhur" sareng basa anu diciptakeun deui tina aljabar relasional anu teu acan hilap lengkep, alat éta mimiti ngabantosan urang dina tugas-tugas di handap ieu:
- Sabaraha kasalahan PHP anu dipiboga ku klien Bitrix24 dina portal p1 dina jam terakhir sareng anu mana? Ngartos, ngahampura sareng gancang ngabenerkeun.
- Sabaraha telepon pidéo dilakukeun dina portal di Jerman dina 24 jam sateuacana, kalayan kualitas naon sareng aya kasusah dina saluran / jaringan?
- Kumaha ogé fungsionalitas sistem (extension C kami pikeun PHP), disusun tina sumber dina update ladenan panganyarna na digulung kaluar ka klien, jalan? Aya segfaults?
- Naha data palanggan pas kana mémori PHP? Dupi aya kasalahan ngeunaan ngaleuwihan mémori disadiakeun pikeun prosés: "kaluar memori"? Panggihan tur neutralize.
Ieu conto konkret. Sanaos tés lengkep sareng multi-tingkat, klien, kalayan kasus anu teu standar sareng data input anu ruksak, nampi kasalahan anu ngaganggu sareng teu kaduga, sirineu disada sareng prosés ngalereskeunana gancang:
Salaku tambahan, kibana ngamungkinkeun anjeun pikeun ngatur béwara pikeun acara anu ditangtukeun, sareng dina waktos anu singget alat di perusahaan mimiti dianggo ku puluhan karyawan ti departemén anu béda - tina dukungan téknis sareng pamekaran ka QA.
Kagiatan departemén mana wae dina parusahaan geus jadi merenah pikeun ngalacak jeung ngukur - tinimbang nganalisa log sacara manual dina server, anjeun ngan perlu nyetél parsing log sakali sarta ngirimkeunana ka klaster elastis pikeun ngarasakeun, contona, contemplating dina kibana. dasbor jumlah anak ucing dua sirah dijual dicitak dina printer 3-D pikeun bulan lunar panungtungan.
Analytics Usaha Dasar
Sadayana terang yén analitik bisnis di perusahaan sering dimimitian ku panggunaan anu aktip pisan, leres, Excel. Tapi hal utama anu teu aya tungtungna. Google Analytics dumasar-awan ogé nambihan suluh kana seuneu - anjeun gancang ngawitan ngabiasakeun barang anu saé.
Dina parusahaan urang harmoniously ngembang, di ditu di dieu "nabi" gawé leuwih intensif kalayan data nu leuwih gede mimiti muncul. Kabutuhan pikeun laporan leuwih teleb tur multifaceted mimiti némbongan rutin, sarta ngaliwatan usaha guys ti departemén béda, sababaraha waktu ka tukang geus diatur solusi basajan tur praktis - kombinasi ClickHouse na PowerBI.
Pikeun lila, leyuran fléksibel ieu mantuan pisan, tapi saeutik demi saeutik pamahaman mimiti datangna yén ClickHouse teu karét sarta teu bisa moyok kawas éta.
Di dieu hal anu penting pikeun ngarti ogé yén ClickHouse, kawas Druid, kawas Vertica, kawas Amazon RedShift (anu dumasar kana postgres), mangrupakeun mesin analitik dioptimalkeun pikeun analytics cukup merenah (sums, aggregations, minimum-maksimum ku kolom jeung sababaraha kamungkinan ngagabung. ), sabab diatur pikeun neundeun efisien kolom tabel relational, teu kawas MySQL sarta séjén (baris-berorientasi) database dipikawanoh ku urang.
Intina, ClickHouse ngan ukur "database" anu langkung ageung, kalayan sisipan titik-demi-titik anu teu merenah (éta kumaha tujuanana, sadayana henteu kunanaon), tapi analitik anu pikaresepeun sareng sakumpulan fungsi anu kuat anu pikaresepeun pikeun damel sareng data. Leres, anjeun malah tiasa nyiptakeun kluster - tapi anjeun ngartos yén palu kuku nganggo mikroskop henteu leres-leres leres sareng urang mimiti milarian solusi anu sanés.
Paménta pikeun python sareng analis
Perusahaan kami ngagaduhan seueur pamekar anu nyerat kode ampir unggal dinten salami 10-20 taun dina PHP, JavaScript, C #, C / C ++, Java, Go, Rust, Python, Bash. Aya ogé loba administrator sistem ngalaman anu ngalaman leuwih ti hiji musibah kacida luar biasa nu teu cocog kana hukum statistik (contona, nalika mayoritas disk dina razia-10 ancur ku serangan kilat kuat). Dina kaayaan kitu, geus lila teu jelas naon "analis python". Python téh kawas PHP, ngan ngaranna téh saeutik deui jeung aya saeutik kirang ngambah zat-ngarobah pikiran dina kode sumber juru urang. Sanajan kitu, sakumaha beuki loba laporan analitik dijieun, pamekar ngalaman mimiti beuki ngarti pentingna Spésialisasi sempit dina parabot kawas numpy, pandas, matplotlib, seaborn.
Peran decisive, paling dipikaresep, ieu dicoo ku pingsan ngadadak karyawan tina kombinasi kecap "regresi logistik" jeung démo ngalaporkeun éféktif dina data badag ngagunakeun, enya, enya, pyspark.
Apache Spark, paradigma fungsionalna dimana aljabar relasional pas sampurna, sareng kamampuanana ngajantenkeun gambaran sapertos kitu dina pamekar anu biasa MySQL yén kabutuhan pikeun nguatkeun jajaran sareng analis anu berpengalaman janten jelas.
usaha salajengna tina Apache Spark / Hadoop nyandak off jeung naon teu balik rada nurutkeun naskah
Sanajan kitu, eta geura-giru jadi jelas yén hal éta systemically teu pas jeung Spark, atawa ngan saukur perlu ngumbah leungeun Anjeun hadé. Upami tumpukan Hadoop/MapReduce/Lucene didamel ku programer anu cukup berpengalaman, anu écés upami anjeun ningal sacara saksama kode sumber di Java atanapi ideu Doug Cutting di Lucene, maka Spark, ujug-ujug, ditulis dina basa Scala anu aheng, nyaéta. kontroversial pisan tina sudut pandang praktis sareng ayeuna henteu berkembang. Jeung serelek biasa dina itungan dina klaster Spark alatan karya teu logis tur teu pisan transparan jeung alokasi memori pikeun ngurangan operasi (loba konci anjog sakaligus) geus dijieun halo sabudeureun eta hal anu boga kamar tumuwuh. Salaku tambahan, kaayaan ieu diperparah ku sajumlah ageung palabuhan kabuka anu aneh, file samentawis tumbuh di tempat anu paling teu kaharti sareng katergantungan jar - anu nyababkeun pangurus sistem gaduh hiji perasaan anu dipikanyaho ti budak leutik: hatred galak (atanapi meureun. aranjeunna kedah ngumbah leungeun ku sabun).
Hasilna, urang geus "salamet" sababaraha proyék analitik internal nu aktip ngagunakeun Apache Spark (kaasup Spark Streaming, Spark SQL) jeung ékosistem Hadoop (jeung saterusna jeung saterusna). Sanaos kanyataan yén kana waktosna urang diajar nyiapkeun sareng ngawas "éta" lumayan, sareng "éta" praktis lirén ujug-ujug nabrak kusabab parobihan sifat data sareng henteu saimbangna hashing RDD seragam, kahayang pikeun nyandak anu parantos siap. , diropéa sarta dikaluarkeun wae di awan tumuwuh kuat tur kuat. Dina waktos ieu kami nyobian nganggo rakitan awan siap-siap tina Amazon Web Services - jeung, saterusna, diusahakeun ngajawab masalah ngagunakeun eta. EMR mangrupikeun Apache Spark anu disiapkeun ku Amazon kalayan parangkat lunak tambahan tina ékosistem, sapertos Cloudera / Hortonworks ngawangun.
Panyimpen file karét pikeun analytics mangrupikeun kabutuhan anu mendesak
Pangalaman "masak" Hadoop/Spark kalawan kaduruk ka sagala rupa bagian awak teu sia-sia. Kabutuhan pikeun nyiptakeun panyimpen file tunggal, murah sareng dipercaya anu bakal tahan kana kagagalan hardware sareng dimana kamungkinan pikeun nyimpen file dina format anu béda tina sistem anu béda-béda sareng ngadamel conto anu épisién sareng éfisién waktos pikeun laporan tina data ieu janten langkung seueur. jelas.
Kuring ogé miharep yén ngamutahirkeun software tina platform ieu teu robah jadi ngimpina Taun Anyar urang ku maca 20-kaca ngambah Java sarta analisa log detil kilométer-lila tina klaster ngagunakeun Spark Sajarah Server jeung kaca pembesar backlit. Kuring hayang boga alat basajan tur transparan nu teu merlukeun diving biasa handapeun tiung lamun pamundut MapReduce baku pamekar urang dieureunkeun executing nalika worker ngurangan data murag kaluar tina memori alatan algoritma partitioning data sumber teu dipilih pisan ogé.
Naha Amazon S3 calon DataLake?
Pangalaman sareng Hadoop / MapReduce ngajarkeun urang yén urang peryogi sistem file anu tiasa scalable, tiasa dipercaya sareng pagawe anu tiasa skala di luhurna, "datang" langkung caket kana data supados henteu ngadorong data kana jaringan. Pagawe kedah tiasa maca data dina format anu béda, tapi langkung saé henteu maca inpormasi anu teu dipikabutuh sareng tiasa nyimpen data sateuacanna dina format anu cocog pikeun pagawé.
Sakali deui, ide dasar. Teu aya kahayang pikeun "tuang" data badag kana mesin analitik klaster tunggal, nu sooner atanapi engké bakal cuk jeung anjeun kudu beling eta awon. Abdi hoyong nyimpen file, ngan file, dina format kaharti jeung ngalakukeun queries analitik éféktif dina aranjeunna ngagunakeun parabot béda tapi kaharti. Sareng bakal aya langkung seueur file dina format anu béda. Tur éta hadé mun beling teu mesin, tapi data sumber. Kami peryogi DataLake anu tiasa diperpanjang sareng universal, kami mutuskeun ...
Kumaha upami anjeun nyimpen file dina panyimpenan awan scalable anu akrab sareng terkenal Amazon S3, tanpa kedah nyiapkeun chops anjeun nyalira tina Hadoop?
Ieu jelas yén data pribadi "rendah", tapi kumaha upami data sejenna lamun urang nyandak eta kaluar aya na "ngajalankeun eta éféktif"?
Cluster-bigdata-analytics ékosistem Amazon Web Services - dina kecap basajan pisan
Ditilik ku pangalaman urang sareng AWS, Apache Hadoop / MapReduce parantos lami dianggo di dinya dina sababaraha saos, contona dina jasa DataPipeline (Kuring sirik ka kolega kuring, aranjeunna diajar kumaha nyiapkeunna leres). Di dieu urang nyetél cadangan tina jasa béda ti tabel DynamoDB:
Sareng aranjeunna parantos ngajalankeun rutin dina klaster Hadoop / MapReduce anu dipasang sapertos jam jam sababaraha taun ayeuna. "Setel sareng hilap":
Anjeun ogé tiasa sacara efektif kalibet dina satanisme data ku cara nyetél laptop Jupiter dina méga pikeun analis sareng nganggo jasa AWS SageMaker pikeun ngalatih sareng nyebarkeun modél AI kana perang. Kieu kumaha rupana pikeun urang:
Sareng enya, anjeun tiasa nyandak laptop pikeun diri atanapi analis dina awan sareng ngagantelkeun kana kluster Hadoop / Spark, laksanakeun itungan teras kuku sadayana:
Nyaan merenah pikeun proyék analitik individu sareng pikeun sababaraha urang parantos suksés ngagunakeun jasa EMR pikeun itungan sareng analitik skala ageung. Kumaha upami solusi sistem pikeun DataLake, bakal tiasa dianggo? Dina momen ieu kami dina verge harepan jeung asa sarta nuluykeun pilarian.
AWS Glue - rangkep rapih Apache Spark on stéroid
Tétéla yén AWS boga versi sorangan tina tumpukan "Hive / Babi / Spark". Peran Hive, i.e. Katalog file sareng jinisna di DataLake dilakukeun ku jasa "Katalog Data", anu henteu nyumputkeun kasaluyuanna sareng format Apache Hive. Anjeun kedah nambihan inpormasi kana jasa ieu ngeunaan dimana file anjeun ayana sareng dina format naon éta. Data bisa jadi teu ngan di s3, tapi ogé dina database, tapi teu subyek pos ieu. Kieu kumaha diréktori data DataLake urang diatur:
Filena didaptarkeun, saé. Lamun file geus diropéa, urang ngajalankeun crawlers boh sacara manual atawa dina jadwal, nu bakal ngamutahirkeun informasi ngeunaan eta ti danau sarta simpen aranjeunna. Teras data ti situ tiasa diolah sareng hasilna diunggah dimana waé. Dina kasus pangbasajanna, urang ogé unggah ka s3. Ngolah data tiasa dilakukeun dimana waé, tapi disarankeun yén anjeun ngonpigurasikeun pamrosésan dina kluster Apache Spark nganggo kamampuan canggih ngalangkungan API AWS Glue. Nyatana, anjeun tiasa nyandak kode python anu lami sareng akrab nganggo perpustakaan pyspark sareng ngonpigurasikeun palaksanaanna dina titik N tina gugusan sababaraha kapasitas kalayan ngawaskeun, tanpa ngagali kana nyali Hadoop sareng nyered wadah docker-moker sareng ngaleungitkeun konflik kagumantungan. .
Sakali deui, gagasan basajan. Teu perlu ngonpigurasikeun Apache Spark, anjeun ngan perlu nulis kode python pikeun pyspark, nguji éta lokal dina desktop Anjeun lajeng ngajalankeun eta dina klaster badag dina awan, nangtukeun mana data sumber na dimana nempatkeun hasilna. Kadang-kadang ieu perlu sareng mangpaat, sareng ieu kumaha urang nyetélana:
Ku kituna, lamun perlu ngitung hal dina klaster Spark ngagunakeun data dina s3, urang nulis kode dina python / pyspark, nguji éta, sarta alus tuah ka awan.
Kumaha upami orkestrasi? Kumaha upami tugasna murag sareng ngaleungit? Leres, diusulkeun ngadamel pipa anu saé dina gaya Babi Apache sareng urang nyobian aranjeunna, tapi pikeun ayeuna urang mutuskeun pikeun ngagunakeun orkestrasi anu disaluyukeun sacara jero dina PHP sareng JavaScript (abdi ngartos, aya disonansi kognitif, tapi tiasa dianggo, pikeun taun sareng tanpa kasalahan).
Format file anu disimpen di danau mangrupikeun konci pikeun pagelaran
Penting pisan pikeun ngartos dua deui titik konci. Supados queries on data file di danau bisa dieksekusi sagancangna tur kinerja teu nguraikeun lamun informasi anyar ditambahkeun, Anjeun kudu:
- Simpen kolom file sacara misah (ku kituna anjeun henteu kedah maca sadaya garis pikeun ngartos naon anu aya dina kolom). Pikeun ieu kami nyandak format parquet kalayan komprési
- Penting pisan pikeun ngabagi file kana polder sapertos: basa, taun, bulan, dinten, minggu. Mesin anu ngartos jinis sharding ieu ngan ukur ningali kana polder anu diperyogikeun, tanpa ngayak sadaya data sakaligus.
Intina, ku cara ieu, anjeun iklaskeun data sumber dina bentuk anu paling éfisién pikeun mesin analitik anu digantung di luhur, anu bahkan dina polder beling tiasa selektif ngalebetkeun sareng maca ngan ukur kolom anu diperyogikeun tina file. Anjeun teu kedah "ngeusian" data di mana waé (panyimpenan ngan saukur ngabeledug) - ngan langsung sacara bijaksana nempatkeun éta dina sistem file dina format anu leres. Tangtosna, kedah jelas di dieu yén nyimpen file csv anu ageung di DataLake, anu kedah dibaca heula baris demi baris ku klaster supados nimba kolom, henteu disarankeun pisan. Pikirkeun deui dua poin di luhur upami éta henteu acan écés naha sadayana ieu kajantenan.
AWS Athena - jack-in-the-box
Teras, nalika nyiptakeun danau, urang teu kahaja mendakan Amazon Athena. Ujug-ujug tétéla yén ku sacara saksama nyusun file log ageung urang kana beling polder dina format kolom (parquet) anu leres, anjeun tiasa gancang pisan ngadamel pilihan anu informatif ti aranjeunna sareng ngawangun laporan TANPA, tanpa kluster Apache Spark/Glue.
Mesin Athena Powered by data dina s3 dumasar kana legendaris - wawakil MPP (prosés paralel masif) kulawarga pendekatan ngolah data, nyandak data dimana eta perenahna, ti s3 na Hadoop mun Cassandra jeung file téks biasa. Anjeun ngan ukur kedah naroskeun ka Athena pikeun ngalaksanakeun pamundut SQL, teras sadayana "jalanna gancang sareng otomatis." Kadé dicatet yén Athena nyaeta "pinter", eta mana ngan ka polder sharded perlu jeung maca ngan kolom diperlukeun dina pamundut nu.
Harga pikeun pamundut ka Athena ogé pikaresepeun. Urang mayar . Jelema. teu keur Jumlah mesin dina klaster per menit, tapi ... pikeun data sabenerna discan on 100-500 mesin, ngan data diperlukeun pikeun ngalengkepan pamundut nu.
Sareng ku ngan ukur nyuhunkeun kolom anu diperyogikeun tina polder anu leres-leres, tétéla yén jasa Athena ngarugikeun urang puluhan dolar sabulan. Nya, saé, ampir gratis, dibandingkeun sareng analitik dina klaster!
Ku jalan kitu, ieu kumaha urang ngabagi data dina s3:
Hasilna, dina waktu anu singget, departemén lengkep beda di pausahaan, ti kaamanan informasi ka analytics, mimiti aktip nyieun requests ka Athena jeung gancang, dina sababaraha detik, narima jawaban mangpaat tina data "badag" dina période cukup lila: bulan, satengah taun, jsb P.
Tapi urang indit salajengna jeung mimiti indit ka awan pikeun jawaban : analis nulis query SQL dina konsol akrab, nu dina 100-500 mesin "pikeun pennies" ngirimkeun data ka s3 sarta mulih jawaban biasana dina sababaraha detik. Sreg. Jeung gancang. Kuring masih teu percaya.
Hasilna, sanggeus mutuskeun pikeun nyimpen data dina s3, dina format columnar efisien sarta kalawan sharding lumrah data kana polder ... kami nampi DataLake sarta mesin analitik gancang tur mirah - haratis. Sareng anjeunna janten populer pisan di perusahaan, sabab ... understands SQL sarta gawéna pesenan gedena leuwih gancang ti ngaliwatan ngamimitian / eureun / nyetel klaster. "Sareng upami hasilna sami, naha mayar langkung?"
Paménta ka Athena siga kieu. Upami hoyong, tangtosna, anjeun tiasa ngabentuk cukup , tapi urang bakal ngawatesan diri kana grup basajan. Hayu urang tingali naon kode réspon klien tadi sababaraha minggu ka tukang dina log pangladén wéb sareng pastikeun teu aya kasalahan:
papanggihan
Ngaliwatan, teu ngomong panjang, tapi jalur nyeri, terus adequately assessing resiko na tingkat pajeulitna sarta biaya rojongan, kami manggihan solusi pikeun DataLake na analytics nu pernah ceases mangga urang duanana speed na biaya kapamilikan.
Tétéla yén ngawangun DataLake anu efektif, gancang sareng murah pikeun ngoperasikeun kabutuhan departemén perusahaan anu béda-béda lengkep dina kamampuan pamekar malah ngalaman anu henteu pernah damel salaku arsiték sareng henteu terang kumaha ngagambar kuadrat dina kuadrat. panah jeung nyaho 50 istilah ti ekosistem Hadoop.
Dina awal perjalanan, sirah kuring ieu beulah tina loba kebon binatang liar software kabuka sarta ditutup sarta pamahaman beungbeurat tanggung jawab ka turunan. Ngan ngamimitian ngawangun DataLake anjeun tina parabot basajan: nagios / munin -> elastis / kibana -> Hadoop / Spark / s3 ..., ngumpulkeun eupan balik sarta deeply pamahaman fisika prosés lumangsung. Sagalana rumit sarta murky - masihan ka musuh jeung pesaing.
Upami anjeun henteu hoyong angkat ka awan sareng resep ngadukung, ngapdet sareng nambal proyék sumber terbuka, anjeun tiasa ngawangun skéma anu sami sareng urang lokal, dina mesin kantor anu murah sareng Hadoop sareng Presto di luhur. Hal utama henteu eureun sareng maju, cacah, milarian solusi anu saderhana sareng jelas, sareng sadayana pasti bakal jalan! Good tuah ka dulur jeung ningali anjeun deui!
sumber: www.habr.com