Naon husus ngeunaan Cloudera jeung kumaha carana masak eta

Pasar pikeun komputasi disebarkeun sarta data badag, nurutkeun statistik, tumuwuh ku 18-19% per taun. Ieu ngandung harti yén masalah milih parangkat lunak pikeun tujuan ieu tetep relevan. Dina postingan ieu, urang mimitian ku naha komputasi anu disebarkeun diperyogikeun, langkung rinci ngeunaan milih parangkat lunak, ngobrol ngeunaan ngagunakeun Hadoop nganggo Cloudera, sareng tungtungna ngobrol ngeunaan milih hardware sareng kumaha mangaruhan kinerja dina sababaraha cara.

Naon husus ngeunaan Cloudera jeung kumaha carana masak eta
Naha komputasi disebarkeun diperyogikeun dina bisnis biasa? Sadayana di dieu saderhana sareng rumit dina waktos anu sami. Basajan - sabab dina kalolobaan kasus urang ngalakukeun itungan anu saderhana per unit inpormasi. Éta hésé sabab aya seueur inpormasi sapertos kitu. Loba pisan. Akibatna, perlu ngolah terabytes data dina 1000 threads. Ku kituna, kasus pamakéan anu cukup universal: itungan bisa dipaké dimana wae nu diperlukeun pikeun tumut kana akun angka nu gede ngarupakeun metrics dina Asép Sunandar Sunarya malah leuwih badag data.

Salah sahiji conto panganyarna: ranté pizzeria Dodo Pizza ditangtukeun dumasar kana analisa database pesenan customer, yén lamun milih pizza kalawan topping acak, pamaké biasana beroperasi kalawan ukur genep sét bahan dasar ditambah sababaraha acak. Luyu sareng ieu, pizzeria nyaluyukeun pameseranana. Salaku tambahan, anjeunna tiasa langkung saé nyarankeun produk tambahan anu ditawarkeun ka pangguna dina tahap pesenan, anu ningkatkeun kauntungan.

Hiji conto deui: analisa item produk diwenangkeun H&M toko ngurangan campuran di toko individu ku 40%, bari ngajaga tingkat jualan. Hal ieu dihontal ku ngaluarkeun barang-barang anu jual anu kirang, sareng musiman dipertimbangkeun dina itungan.

Pilihan alat

Standar industri pikeun jinis komputasi ieu nyaéta Hadoop. Naha? Kusabab Hadoop mangrupa alus teuing, kerangka well-documented (Habr sarua nyadiakeun loba artikel lengkep dina topik ieu), nu dipirig ku sakabeh susunan Utiliti jeung perpustakaan. Anjeun tiasa input set badag duanana data terstruktur jeung teu terstruktur, sarta sistem sorangan bakal ngadistribusikaeun eta diantara kakuatan komputasi. Sumawona, kamampuan anu sami ieu tiasa dironjatkeun atanapi ditumpurkeun iraha waé - éta skalabilitas horizontal anu sami dina aksi.

Dina 2017, pausahaan konsultan boga pangaruh Gartner disimpulkeunyén Hadoop baris geura-giru jadi leungit. Alesanna rada banal: analis yakin yén perusahaan bakal migrasi sacara masal ka méga, sabab di dinya aranjeunna tiasa mayar nalika ngagunakeun kakuatan komputasi. Faktor penting kadua anu tiasa "ngubur" Hadoop nyaéta lajuna. Kusabab pilihan sapertos Apache Spark atanapi Google Cloud DataFlow langkung gancang tibatan MapReduce, anu ngadasarkeun Hadoop.

Hadoop aya dina sababaraha pilar, anu paling kasohor nyaéta téknologi MapReduce (sistem pikeun ngadistribusikaeun data pikeun itungan antara server) sareng sistem file HDFS. Anu terakhir dirancang khusus pikeun nyimpen inpormasi anu disebarkeun antara titik kluster: unggal blok ukuran tetep tiasa ditempatkeun dina sababaraha titik, sareng hatur nuhun kana réplikasi, sistemna tahan kana gagalna titik individu. Gantina tabel file, server husus disebut NameNode dipaké.

Ilustrasi di handap ieu nunjukkeun kumaha jalanna MapReduce. Dina tahap kahiji, data dibagi dumasar kana kriteria nu tangtu, dina tahap kadua disebarkeun nurutkeun daya komputasi, sarta dina tahap katilu itungan lumangsung.

Naon husus ngeunaan Cloudera jeung kumaha carana masak eta
MapReduce asalna dijieun ku Google pikeun kaperluan pilarian na. Lajeng MapReduce indit kode bébas, sarta Apache ngambil alih proyek. Nya, Google laun-laun hijrah ka solusi anu sanés. Tidbit metot: Google ayeuna boga proyék disebut Google Cloud Dataflow, diposisikan salaku lengkah saterusna sanggeus Hadoop, salaku gaganti gancang pikeun eta.

Titingalian anu langkung caket nunjukkeun yén Google Cloud Dataflow didasarkeun kana variasi Apache Beam, sedengkeun Apache Beam kalebet kerangka Apache Spark anu didokumentasikeun saé, anu ngamungkinkeun urang ngobrol ngeunaan laju palaksanaan solusi anu ampir sami. Nya, Apache Spark tiasa dianggo sampurna dina sistem file HDFS, anu ngamungkinkeun éta disebarkeun dina server Hadoop.

Tambihkeun di dieu volume dokuméntasi sareng solusi anu siap pikeun Hadoop sareng Spark versus Google Cloud Dataflow, sareng pilihan alat janten atra. Sumawona, insinyur tiasa mutuskeun sorangan kode mana - pikeun Hadoop atanapi Spark - aranjeunna kedah ngajalankeun, fokus kana tugas, pangalaman sareng kualifikasi.

Awan atawa server lokal

Tren nuju transisi umum ka awan malah parantos nyababkeun istilah anu pikaresepeun sapertos Hadoop-as-a-service. Dina skenario kitu, administrasi server disambungkeun jadi pohara penting. Kusabab, sayangna, sanaos popularitasna, Hadoop murni mangrupikeun alat anu sesah pikeun dikonpigurasikeun, sabab seueur anu kedah dilakukeun sacara manual. Contona, ngonpigurasikeun server individual, ngawas kinerja maranéhanana, sarta taliti ngonpigurasikeun loba parameter. Sacara umum, karyana pikeun amatir sareng aya kasempetan anu ageung pikeun ngaco ka mana waé atanapi leungit hiji hal.

Ku alatan éta, rupa-rupa kit distribution, nu mimitina dilengkepan deployment merenah tur alat administrasi, geus jadi pohara populér. Salah sahiji distribusi anu pang populerna anu ngadukung Spark sareng ngajantenkeun sadayana gampang nyaéta Cloudera. Éta ngagaduhan vérsi anu mayar sareng gratis - sareng anu terakhir sadayana fungsionalitas dasar sayogi, tanpa ngawatesan jumlah titik.

Naon husus ngeunaan Cloudera jeung kumaha carana masak eta

Salila setelan, Cloudera Manager bakal nyambung via SSH ka server anjeun. Hiji titik metot: lamun masang, eta leuwih hade pikeun nangtukeun yén éta dipigawé ku nu disebut parsels: bungkusan husus, nu masing-masing ngandung sakabéh komponén perlu ngonpigurasi pikeun gawé babarengan. Intina ieu mangrupikeun vérsi anu langkung saé tina manajer pakét.

Saatos instalasi, kami nampi konsol manajemén klaster, dimana anjeun tiasa ningali telemétri klaster, jasa dipasang, tambah anjeun bisa nambahkeun / nyoplokkeun sumberdaya tur ngédit konfigurasi klaster.

Naon husus ngeunaan Cloudera jeung kumaha carana masak eta

Hasilna, kabin rokét anu bakal mawa anjeun kana masa depan caang BigData muncul di hareup anjeun. Tapi sateuacan urang nyarios "hayu," hayu urang ngalih handapeun tiung.

syarat hardware

Dina situs wébna, Cloudera nyarioskeun sababaraha konfigurasi anu mungkin. Prinsip-prinsip umum pikeun ngawangun aranjeunna dipidangkeun dina ilustrasi:

Naon husus ngeunaan Cloudera jeung kumaha carana masak eta
MapReduce tiasa ngaburkeun gambar optimis ieu. Upami anjeun ningali deui diagram tina bagian sateuacana, janten jelas yén ampir sadaya kasus, padamelan MapReduce tiasa mendakan bottleneck nalika maca data tina disk atanapi tina jaringan. Ieu ogé dicatet dina blog Cloudera. Hasilna, pikeun sagala itungan gancang, kaasup ngaliwatan Spark, nu mindeng dipaké pikeun real-time itungan, I / O speed pohara penting. Ku alatan éta, nalika ngagunakeun Hadoop, éta penting pisan yén klaster ngawengku mesin saimbang tur gancang, nu, mun nempatkeun eta mildly, teu salawasna ensured dina infrastruktur awan.

Kasaimbangan dina distribusi beban kahontal ngaliwatan pamakéan virtualization Openstack on server kalawan CPUs multi-core kuat. Titik data dialokasikeun sumberdaya prosesor sorangan sareng disk khusus. Dina kaputusan urang Atos Codex Data Lake Engine Virtualization lega kahontal, naha urang nguntungkeun boh tina segi kinerja (dampak infrastruktur jaringan diminimalkeun) sareng di TCO (server fisik tambahan dileungitkeun).

Naon husus ngeunaan Cloudera jeung kumaha carana masak eta
Nalika nganggo server BullSequana S200, kami nampi beban anu seragam, teu aya sababaraha bottlenecks. Konfigurasi minimum ngawengku 3 server BullSequana S200, unggal dua JBODs, ditambah tambahan S200s ngandung opat titik data disambungkeun optionally. Ieu conto beban dina tés TeraGen:

Naon husus ngeunaan Cloudera jeung kumaha carana masak eta

Tés kalayan volume data anu béda sareng nilai réplikasi nunjukkeun hasil anu sami dina hal distribusi beban antara titik kluster. Di handap ieu grafik distribusi aksés disk ku tés kinerja.

Naon husus ngeunaan Cloudera jeung kumaha carana masak eta

Itungan anu dipigawé dumasar kana konfigurasi minimum 3 server BullSequana S200. Éta kalebet 9 titik data sareng 3 titik master, ogé mesin virtual anu dicadangkeun upami panyebaran panyalindungan dumasar kana OpenStack Virtualization. Hasil tés TeraSort: ukuran blok 512 MB faktor réplikasi sarua jeung tilu jeung énkripsi nyaéta 23,1 menit.

Kumaha sistem bisa dimekarkeun? Aya sababaraha jinis ekstensi anu sayogi pikeun Data Lake Engine:

  • Titik data: pikeun unggal 40 TB rohangan anu tiasa dianggo
  • titik analitik kalawan kamampuhan pikeun masang GPU a
  • Pilihan séjén gumantung kana kabutuhan bisnis (contona, upami anjeun peryogi Kafka sareng anu sanésna)

Naon husus ngeunaan Cloudera jeung kumaha carana masak eta

The Atos Codex Data Lake Engine ngawengku duanana server sorangan jeung software tos dipasang, kaasup kit Cloudera dilisensikeun; Hadoop sorangan, OpenStack sareng mesin virtual dumasar kana kernel RedHat Enterprise Linux, réplikasi data sareng sistem cadangan (kalebet nganggo titik cadangan sareng Cloudera BDR - Cadangan sareng Pamulihan Bencana). Atos Codex Data Lake Engine janten solusi virtualisasi munggaran anu disertipikasi Cloudera.

Upami anjeun resep kana detil, kami bakal resep ngajawab patarosan kami dina koméntar.

sumber: www.habr.com

Tambahkeun komentar