Kita manggon ing wektu sing nggumunake nalika sampeyan bisa nyambungake sawetara alat open-source kanthi cepet lan gampang, atur kanthi "kesadaran dipateni" miturut saran saka stackoverflow, tanpa nyelidiki "kaping pirang-pirang huruf", lan miwiti padha menyang operasi komersial. Lan nalika sampeyan kudu nganyari / nggedhekake utawa wong ora sengaja reboots saperangan saka mesin - sampeyan Γ©ling sing sawetara jinis ngimpi ala obsessive wis diwiwiti, kabeh wis dadi dramatically rumit ngluwihi pangenalan, ora ana mbalek maneh, mangsa samar lan luwih aman, tinimbang program, breeding tawon lan nggawe keju.
Ora ana apa-apa kolega sing luwih berpengalaman, kanthi sirahe kebak kewan omo lan mulane wis abu-abu, mikir babagan panyebaran paket "kontainer" sing cepet banget ing "kotak" ing puluhan server ing "basa modern" kanthi dhukungan sing dibangun kanggo Asynchronous non-blocking I/O, eseman andhap asor. Lan padha meneng terus maca maneh "wong ps", delve menyang "nginx" kode sumber nganti mripate getihen, lan nulis, nulis, nulis tes unit. Kolega ngerti yen sing paling menarik bakal teka nalika "kabeh iki" siji dina dadi staked ing wayah wengi ing Eve Taun Anyar. Lan mung bakal dibantu dening pangerten sing jero babagan sifat unix, tabel negara TCP / IP sing wis diapalake lan algoritma telusuran dhasar. Kanggo urip maneh sistem nalika lonceng.
Oh ya, aku rada bingung, nanging muga-muga bisa ngaturake kahanan sing dikarepake.
Dina iki aku pengin nuduhake pengalaman kita ing deploying tumpukan trep lan inexpensive kanggo DataLake, kang solves mayoritas tugas analitis ing perusahaan kanggo divisi struktural temen beda.
Sawetara wektu kepungkur, kita ngerti manawa perusahaan saya butuh woh-wohan saka analitik produk lan teknis (ora kalebu icing ing kue ing wangun pembelajaran mesin) lan ngerti tren lan risiko - kita kudu ngumpulake lan nganalisa. liyane lan liyane metrik.
Analisis teknis dhasar ing Bitrix24
Sawetara taun kepungkur, bebarengan karo peluncuran layanan Bitrix24, kita aktif nandur modal wektu lan sumber daya kanggo nggawe platform analitis sing prasaja lan dipercaya sing bakal mbantu cepet ndeleng masalah ing infrastruktur lan ngrancang langkah sabanjure. Mesthine, dianjurake kanggo njupuk alat sing siap digawe sing gampang lan bisa dingerteni. AkibatΓ©, nagios dipilih kanggo ngawasi lan munin kanggo analytics lan visualisasi. Saiki kita duwe ewonan mriksa ing nagios, atusan denah ing munin, lan kolega kita nggunakake kanthi sukses saben dina. Metrik kasebut cetha, grafik kasebut cetha, sistem kasebut wis bisa digunakake kanthi andal sajrone pirang-pirang taun lan tes lan grafik anyar ditambahake kanthi rutin: nalika nindakake layanan anyar, kita nambah sawetara tes lan grafik. Sugeng dalu.
Finger on the Pulse - Advanced Technical Analytics
Kepinginan kanggo nampa informasi babagan masalah "supaya cepet" mimpin kita menyang eksperimen aktif kanthi alat sing prasaja lan bisa dingerteni - pinba lan xhprof.
Pinba ngirim statistik ing paket UDP babagan kacepetan operasi bagean kaca web ing PHP, lan kita bisa ndeleng online ing panyimpenan MySQL (Pinba dilengkapi mesin MySQL dhewe kanggo analytics acara cepet) dhaptar masalah lan nanggapi. wong-wong mau. Lan xhprof kanthi otomatis ngidini kita ngumpulake grafik eksekusi kaca PHP sing paling alon saka klien lan nganalisa apa sing bisa nyebabake iki - kanthi tenang, tuang teh utawa sing luwih kuwat.
Sawetara wektu kepungkur, toolkit iki diisi maneh karo mesin liyane sing cukup prasaja lan bisa dingerteni adhedhasar algoritma indeksasi terbalik, kanthi sampurna dileksanakake ing perpustakaan Lucene legendaris - Elastis / Kibana. Gagasan sing gampang kanggo ngrekam dokumen kanthi pirang-pirang benang dadi indeks Lucene terbalik adhedhasar acara ing log lan telusuran kanthi cepet nggunakake divisi facet ternyata migunani banget.
Senadyan tampilan visualisasi sing rada teknis ing Kibana kanthi konsep tingkat rendah kaya "ember" "mili munggah" lan basa aljabar hubungan sing durung dilalekake, alat kasebut wiwit mbantu kita kanthi apik ing tugas ing ngisor iki:
- Pira kesalahan PHP sing ditindakake klien Bitrix24 ing portal p1 sajrone jam pungkasan lan sing endi? Ngerti, ngapura lan cepet mbenerake.
- Pira jumlah panggilan video sing digawe ing portal ing Jerman sajrone 24 jam sadurunge, kanthi kualitas apa lan ana masalah karo saluran/jaringan kasebut?
- Kepiye fungsi sistem (ekstensi C kanggo PHP), sing disusun saka sumber ing nganyari layanan paling anyar lan diluncurake menyang klien, bisa digunakake? Apa ana segfaults?
- Apa data pelanggan pas karo memori PHP? Apa ana kesalahan babagan ngluwihi memori sing diparengake kanggo pangolahan: "saka memori"? Temokake lan netralake.
Punika conto konkrit. Senadyan tes lengkap lan multi-level, klien, kanthi kasus sing ora standar lan data input sing rusak, nampa kesalahan sing ngganggu lan ora dikarepke, sirine muni lan proses ndandani kanthi cepet diwiwiti:
Kajaba iku, kibana ngidini sampeyan ngatur kabar kanggo acara sing ditemtokake, lan ing wektu sing cendhak alat ing perusahaan wiwit digunakake dening puluhan karyawan saka departemen sing beda-beda - saka dhukungan teknis lan pangembangan nganti QA.
Kegiatan saka departemen apa wae ing perusahaan dadi trep kanggo dilacak lan diukur - tinimbang nganalisa log kanthi manual ing server, sampeyan mung kudu nyiyapake log parsing sapisan lan dikirim menyang kluster elastis kanggo nikmati, umpamane, mikir ing kibana. dashboard jumlah anak kucing sirah loro sing didol dicithak ing printer 3-D kanggo sasi lunar pungkasan.
Analisis Bisnis dhasar
Saben uwong ngerti yen analytics bisnis ing perusahaan asring diwiwiti kanthi nggunakake Excel sing aktif banget. Nanging sing utama iku ora mungkasi ana. Google Analytics berbasis awan uga nambah bahan bakar kanggo geni - sampeyan kanthi cepet mulai terbiasa karo barang sing apik.
Ing perusahaan sing berkembang kanthi harmonis, ana "nabi" saka karya sing luwih intensif kanthi data sing luwih gedhe wiwit katon. Keperluan kanggo laporan sing luwih jero lan multifaceted wiwit katon kanthi rutin, lan liwat upaya wong lanang saka departemen sing beda-beda, sawetara wektu kepungkur ana solusi sing prasaja lan praktis - kombinasi ClickHouse lan PowerBI.
Kanggo wektu sing cukup suwe, solusi fleksibel iki mbantu akeh, nanging mboko sithik pemahaman wiwit teka yen ClickHouse dudu karet lan ora bisa dipoyoki kaya ngono.
Ing kene, penting kanggo ngerti yen ClickHouse, kaya Druid, kaya Vertica, kaya Amazon RedShift (sing adhedhasar postgres), minangka mesin analitis sing dioptimalake kanggo analytics sing cukup trep (jumlah, agregasi, minimal-maksimum kanthi kolom lan sawetara kemungkinan gabung. ), amarga diatur kanggo panyimpenan efisien kolom tabel hubungan, ora kaya MySQL lan database liyane (oriented baris) dikenal kanggo kita.
Intine, ClickHouse mung minangka "database" sing luwih gedhe, kanthi sisipan titik-titik sing ora trep banget (kayata tujuane, kabeh ok), nanging analytics sing nyenengake lan sakumpulan fungsi kuat sing menarik kanggo nggarap data. Ya, sampeyan bisa uga nggawe kluster - nanging sampeyan ngerti manawa palu kuku nganggo mikroskop ora bener lan kita wiwit golek solusi liyane.
Panjaluk python lan analis
Perusahaan kita duwe akeh pangembang sing nulis kode meh saben dina sajrone 10-20 taun ing PHP, JavaScript, C#, C/C++, Java, Go, Rust, Python, Bash. Ana uga akeh administrator sistem experienced sing wis ngalami luwih saka siji bilai pancen luar biasa sing ora pas karo hukum statistik (contone, nalika mayoritas disk ing gropyokan-10 numpes dening serangan kilat kuwat). Ing kahanan kaya mengkono, kanggo dangu ora cetha apa "analis python". Python iku kaya PHP, mung jeneng sing sethitik maneh lan ana sethitik kurang tilak saka zat-ngganti pikiran ing kode sumber interpreter. Nanging, nalika laporan analitis liyane digawe, pangembang sing berpengalaman wiwit ngerti pentinge spesialisasi sempit ing alat kaya numpy, panda, matplotlib, seaborn.
Peran sing nemtokake, paling mungkin, dimainake kanthi tiba-tiba pingsan karyawan saka kombinasi tembung "regresi logistik" lan demonstrasi laporan efektif babagan data gedhe nggunakake, ya, ya, pyspark.
Apache Spark, paradigma fungsional sing cocog karo aljabar relasional, lan kemampuane nggawe kesan kasebut marang pangembang sing wis biasa karo MySQL yen perlu nguatake rangking karo analis sing berpengalaman dadi jelas.
Upaya luwih saka Apache Spark / Hadoop kanggo njupuk lan apa sing ora cocog karo naskah kasebut
Nanging, enggal dadi jelas manawa ana sing ora sistematis karo Spark, utawa mung kudu ngumbah tangan luwih apik. Yen tumpukan Hadoop/MapReduce/Lucene digawe dening programer sing cukup berpengalaman, sing jelas yen sampeyan ndeleng kode sumber ing Jawa utawa gagasan Doug Cutting ing Lucene, banjur Spark, dumadakan, ditulis nganggo basa Scala sing endah, yaiku banget kontroversial saka sudut pandang praktis lan saiki ora berkembang. Lan gulung biasa ing petungan ing kluster Spark amarga karya ora logis lan ora banget transparent karo alokasi memori kanggo ngurangi operasi (akeh tombol teka bebarengan) wis digawe halo watara iku soko sing duwe kamar kanggo tuwuh. Kajaba iku, kahanan kasebut saya tambah akeh amarga akeh port mbukak sing aneh, file sauntara sing tuwuh ing papan sing paling ora dingerteni lan ketergantungan jar - sing nyebabake pangurus sistem duwe perasaan sing wis dikenal wiwit cilik: sengit sengit (utawa mungkin). kudu wisuh tangan nganggo sabun).
AkibatΓ©, kita wis "slamet" sawetara proyek analitis internal sing aktif nggunakake Apache Spark (kalebu Spark Streaming, Spark SQL) lan ekosistem Hadoop (lan sateruse). Senadyan kasunyatan sing liwat wektu kita sinau kanggo nyiapake lan ngawasi "iku" cukup apik, lan "iku" meh mandheg dumadakan nabrak amarga owah-owahan ing alam data lan ora seimbang hashing RDD seragam, kepinginan kanggo njupuk soko wis siap. , dianyari lan diterbitake nang endi wae ing mΓ©ga tansaya kuwat lan kuwat. Ing wektu iki kita nyoba nggunakake perakitan awan siap-siap saka Layanan Web Amazon - lan, salajengipun, nyoba kanggo ngatasi masalah nggunakake. EMR yaiku Apache Spark sing disiapake dening Amazon kanthi piranti lunak tambahan saka ekosistem, kaya sing dibangun Cloudera / Hortonworks.
Panyimpenan file karet kanggo analytics minangka kabutuhan sing penting
Pengalaman "masak" Hadoop / Spark kanthi kobong ing macem-macem bagian awak ora muspra. Kebutuhan kanggo nggawe panyimpenan file siji, murah lan dipercaya sing tahan kanggo kegagalan hardware lan bisa nyimpen file ing macem-macem format saka sistem sing beda-beda lan nggawe conto sing efisien lan efisien wektu kanggo laporan saka data iki saya tambah akeh. cetha.
Aku uga pengin nganyari piranti lunak platform iki ora dadi ngipi elek Taun Anyar kanthi maca jejak Java 20-kaca lan nganalisa log rinci kluster kanthi kilometer kanthi nggunakake Spark History Server lan kaca pembesar backlit. Aku wanted kanggo duwe alat prasaja lan transparent sing ora mbutuhake nyilem biasa ing hood yen panyuwunan MapReduce standar pangembang mandegake kaleksanan nalika buruh data nyuda ambruk saka memori amarga algoritma pemisahan data sumber ora dipilih banget.
Apa Amazon S3 calon kanggo DataLake?
Pengalaman karo Hadoop / MapReduce mulangake manawa kita butuh sistem file sing bisa diukur, dipercaya lan buruh sing bisa diukur ing ndhuwur, "teka" luwih cedhak karo data supaya ora nyopir data liwat jaringan. Buruh kudu bisa maca data ing macem-macem format, nanging luwih becik ora maca informasi sing ora perlu lan bisa nyimpen data luwih dhisik ing format sing trep kanggo para pekerja.
Sawise maneh, gagasan dhasar. Ora ana kepinginan kanggo "nyusun" data gedhe menyang mesin analitis kluster siji, sing bakal cepet-cepet keselak lan sampeyan kudu ngrusak. Aku pengin nyimpen file, mung file, ing format sing bisa dingerteni lan nindakake pitakon analitis sing efektif nggunakake alat sing beda nanging bisa dingerteni. Lan bakal ana luwih akeh file ing macem-macem format. Lan luwih apik kanggo shard ora mesin, nanging data sumber. Kita butuh DataLake sing bisa diperluas lan universal, kita mutusake ...
Apa yen sampeyan nyimpen file ing panyimpenan maya skalabel Amazon S3 sing akrab lan kondhang, tanpa kudu nyiyapake chops dhewe saka Hadoop?
Cetha yen data pribadhi "kurang", nanging kepiye data liyane yen kita njupuk metu lan "nyopir kanthi efektif"?
Ekosistem Cluster-bigdata-analytics saka Amazon Web Services - kanthi tembung sing gampang banget
Miturut pengalaman kita karo AWS, Apache Hadoop / MapReduce wis aktif digunakake ing kana kanggo wektu sing suwe ing macem-macem saos, umpamane ing layanan DataPipeline (Aku iri karo kanca-kancaku, dheweke sinau carane nyiyapake kanthi bener). Ing kene kita nyiyapake serep saka macem-macem layanan saka tabel DynamoDB:
Lan dheweke wis mlaku kanthi rutin ing klompok Hadoop / MapReduce sing dipasang kaya jam tangan nganti pirang-pirang taun saiki. "Setel lan lali":
Sampeyan uga bisa kanthi efektif melu satanisme data kanthi nyiyapake laptop Jupiter ing awan kanggo analis lan nggunakake layanan AWS SageMaker kanggo nglatih lan nyebarake model AI menyang perang. Mangkene apa sing katon kanggo kita:
Lan ya, sampeyan bisa njupuk laptop dhewe utawa analis ing mΓ©ga lan masang menyang kluster Hadoop/Spark, ngetung banjur ngisi kabeh:
Pancen trep kanggo proyek analitis individu lan kanggo sawetara kita wis sukses nggunakake layanan EMR kanggo petungan lan analitik skala gedhe. Apa babagan solusi sistem kanggo DataLake, apa bakal bisa digunakake? Ing wayahe iki kita ana ing verge pangarep-arep lan ora kentekan niat lan nerusake panelusuran.
AWS Glue - rangkep Apache Spark ing steroid
Ternyata AWS duwe versi tumpukan "Hive / Pig / Spark" dhewe. Peran Hive, i.e. Katalog file lan jinise ing DataLake ditindakake dening layanan "Katalog data", sing ora ndhelikake kompatibilitas karo format Apache Hive. Sampeyan kudu nambah informasi menyang layanan iki babagan lokasi file sampeyan lan ing format apa. Data bisa ora mung ing s3, nanging uga ing database, nanging sing ora subyek saka kirim iki. Mangkene carane direktori data DataLake diatur:
File-file kasebut kadhaptar, apik banget. Yen file wis dianyari, kita miwiti crawler kanthi manual utawa ing jadwal, sing bakal nganyari informasi babagan saka tlaga lan nyimpen. Banjur data saka tlaga bisa diproses lan asil diunggah ing ngendi wae. Ing kasus sing paling gampang, kita uga ngunggah menyang s3. Pangolahan data bisa ditindakake ing endi wae, nanging disaranake sampeyan ngatur pangolahan ing kluster Apache Spark nggunakake kemampuan lanjut liwat API AWS Glue. Ing kasunyatan, sampeyan bisa njupuk kode python lawas lan menowo apik nggunakake perpustakaan pyspark lan ngatur eksekusi ing N kelenjar kluster saka sawetara kapasitas karo ngawasi, tanpa ngeduk menyang guts Hadoop lan nyeret wadhah docker-moker lan mbusak konflik dependensi. .
Sawise maneh, gagasan prasaja. Ora perlu ngonfigurasi Apache Spark, sampeyan mung kudu nulis kode python kanggo pyspark, nyoba sacara lokal ing desktop lan banjur mbukak ing kluster gedhe ing mΓ©ga, nemtokake ngendi data sumber lan ing ngendi kanggo nyelehake asil. Kadhangkala iki perlu lan migunani, lan iki carane nyiyapake:
Mangkono, yen sampeyan kudu ngetung soko ing kluster Spark nggunakake data ing s3, kita nulis kode ing python / pyspark, nyoba, lan apik luck kanggo maya.
Kepiye babagan orkestrasi? Apa yen tugas tiba lan ilang? Ya, diusulake kanggo nggawe pipa sing apik ing gaya Babi Apache lan kita malah nyoba, nanging saiki kita mutusake nggunakake orkestrasi sing wis disesuaikan banget ing PHP lan JavaScript (Aku ngerti, ana disonansi kognitif, nanging bisa digunakake, kanggo taun lan tanpa kesalahan).
Format file sing disimpen ing tlaga minangka kunci kinerja
Penting banget kanggo ngerti rong poin penting liyane. Supaya pitakon babagan data file ing tlaga bisa ditindakake kanthi cepet lan kinerja ora mudhun nalika informasi anyar ditambahake, sampeyan kudu:
- Simpen kolom file kanthi kapisah (supaya sampeyan ora kudu maca kabeh baris kanggo ngerti apa sing ana ing kolom kasebut). Kanggo iki, kita njupuk format parket kanthi kompresi
- Penting banget kanggo mecah file menyang folder kaya: basa, taun, sasi, dina, minggu. Mesin sing ngerti jinis sharding iki mung bakal katon ing folder sing dibutuhake, tanpa nyaring kabeh data saurutan.
Ateges, kanthi cara iki, sampeyan nemtokake data sumber ing wangun sing paling efisien kanggo mesin analitis sing digantung ing ndhuwur, sing sanajan ing folder sharded bisa selektif ngetik lan maca mung kolom sing dibutuhake saka file. Sampeyan ora perlu "ngisi" data ing endi wae (panyimpenan mung bakal bledosan) - mung langsung dilebokake ing sistem file kanthi format sing bener. Mesthine, kudu jelas yen nyimpen file csv sing gedhe banget ing DataLake, sing kudu diwaca sepisanan baris dening kluster kanggo ngekstrak kolom, ora dianjurake. Coba pikirake maneh rong poin ing ndhuwur yen durung jelas kenapa kabeh iki kedadeyan.
AWS Athena - jack-in-the-box
Banjur, nalika nggawe tlaga, kita ora sengaja nemoni Amazon Athena. Ujug-ujug ternyata kanthi ati-ati ngatur file log sing gedhe dadi pecahan folder kanthi format kolom (parket) sing bener, sampeyan bisa kanthi cepet nggawe pilihan sing informatif banget lan nggawe laporan TANPA, tanpa kluster Apache Spark/Glue.
Engine Athena powered by data ing s3 adhedhasar legendaris - wakil saka MPP (massive Processing paralel) kulawarga pendekatan kanggo Processing data, njupuk data ngendi iku dumunung, saka s3 lan Hadoop kanggo Cassandra lan file teks biasa. Sampeyan mung kudu njaluk Athena kanggo nglakokake query SQL, banjur kabeh "bisa cepet lan otomatis." Iku penting kanggo Wigati sing Athena "pinter", dadi mung kanggo folder sharded perlu lan maca mung kolom needed ing request.
Rega kanggo panjalukan kanggo Athena uga menarik. We mbayar kanggo . Sing. ora kanggo nomer mesin ing kluster saben menit, nanging ... kanggo data bener mentas ing 100-500 mesin, mung data perlu kanggo ngrampungake request.
Lan mung njaluk kolom sing dibutuhake saka folder sharded sing bener, ternyata layanan Athena biaya kita puluhan dolar saben wulan. Inggih, apik, meh gratis, dibandhingake analytics ing kluster!
Ngomong-ngomong, iki carane kita ngrusak data ing s3:
AkibatΓ©, ing wektu sing cendhak, departemen sing beda banget ing perusahaan, saka keamanan informasi nganti analytics, wiwit aktif nggawe panjalukan menyang Athena lan kanthi cepet, ing sawetara detik, nampa jawaban sing migunani saka data "gedhe" sajrone wektu sing cukup suwe: sasi, setengah taun, lsp. P.
Nanging kita luwih maju lan wiwit pindhah menyang awan kanggo njaluk jawaban : Analyst nulis query SQL ing console menowo, kang ing 100-500 mesin "kanggo dhuwit" ngirim data kanggo s3 lan ngasilake jawaban biasane ing sawetara detik. Nyaman. Lan cepet. Aku isih ora percaya.
AkibatΓ©, wis mutusakΓ© kanggo nyimpen data ing s3, ing format columnar efisien lan karo sharding cukup data menyang folder ... kita nampa DataLake lan mesin analitis cepet lan mirah - kanggo free. Lan dheweke dadi misuwur banget ing perusahaan, amarga ... mangertos SQL lan dianggo pesenan gedhene luwih cepet saka liwat miwiti / mandeg / nyetel kluster. "Lan yen asile padha, kenapa mbayar luwih?"
A panjalukan kanggo Athena katon kaya iki. Yen dikarepake, mesthi, sampeyan bisa mbentuk cukup , nanging kita bakal matesi dhΓ©wΓ© kanggo kelompok prasaja. Ayo ndeleng apa kode respon klien sawetara minggu kepungkur ing log server web lan priksa manawa ora ana kesalahan:
temonan
Sawise ngliwati, ora ngomong dalan sing dawa, nanging nglarani, terus-terusan ngevaluasi risiko lan tingkat kerumitan lan biaya dhukungan, kita nemokake solusi kanggo DataLake lan analytics sing ora bakal mandheg nyenengake kita kanthi kacepetan lan biaya kepemilikan.
Ternyata mbangun DataLake sing efektif, cepet lan murah kanggo ngoperasikake kabutuhan departemen sing beda-beda saka perusahaan kasebut pancen ana ing kemampuan para pangembang sing berpengalaman sing durung nate kerja minangka arsitek lan ora ngerti carane nggambar kothak ing kothak kanthi panah lan ngerti 50 istilah saka ekosistem Hadoop.
Ing wiwitan lelampahan, sirah iki pisah saka akeh zoo alam bΓ©bas mbukak lan ditutup software lan pangerten beban tanggung jawab kanggo turunane. Mung miwiti mbangun DataLake saka alat sing prasaja: nagios/munin -> elastis/kibana -> Hadoop/Spark/s3..., ngumpulake umpan balik lan ngerteni kanthi jero babagan fisika proses sing ditindakake. Kabeh rumit lan murky - menehi mungsuh lan saingan.
Yen sampeyan ora pengin pindhah menyang awan lan seneng ndhukung, nganyari lan patch proyek open-source, sampeyan bisa mbangun skema sing padha karo kita sacara lokal, ing mesin kantor murah karo Hadoop lan Presto ing ndhuwur. Ingkang utama yaiku ora mandheg lan maju, ngitung, goleki solusi sing gampang lan jelas, lan kabeh bakal bisa ditindakake! Good luck kanggo kabeh lan ketemu maneh!
Source: www.habr.com