Ang merkado para sa distributed computing at malaking data, ayon sa , ay lumalaki sa 18-19% bawat taon. Nangangahulugan ito na ang isyu ng pagpili ng software para sa mga layuning ito ay nananatiling may kaugnayan. Sa post na ito, magsisimula tayo sa kung bakit kailangan natin ng distributed computing, tatalakayin natin nang mas detalyado ang pagpili ng software, pag-uusapan natin ang paggamit ng Hadoop sa Cloudera, at sa wakas ay pag-uusapan natin ang pagpili ng hardware at kung paano ito nakakaapekto sa pagganap sa iba't ibang paraan.
Bakit kailangan natin ng distributed computing sa ordinaryong negosyo? Ang lahat ay simple at kumplikado sa parehong oras. Simple - dahil sa karamihan ng mga kaso nagsasagawa kami ng medyo simpleng mga kalkulasyon sa bawat yunit ng impormasyon. Mahirap - dahil maraming ganoong impormasyon. Ang dami. Bilang kinahinatnan, ito ay dapat . Kaya, ang mga kaso ng paggamit ay medyo pangkalahatan: ang mga kalkulasyon ay maaaring ilapat saanman kinakailangan na isaalang-alang ang isang malaking bilang ng mga sukatan sa isang mas malaking hanay ng data.
Isang kamakailang halimbawa: Dodo Pizza batay sa pagsusuri sa base ng order ng customer, na kapag pumipili ng pizza na may mga arbitrary na toppings, karaniwang tumatakbo ang mga user gamit ang anim na pangunahing hanay ng mga sangkap kasama ang ilang random na mga sangkap. Alinsunod dito, inayos ng pizzeria ang mga pagbili. Bilang karagdagan, nagawa nitong mas mahusay na magrekomenda ng mga karagdagang produkto na inaalok sa yugto ng order sa mga user, na nagpapataas ng kita.
Isa pang halimbawa: pinahintulutan ng merchandise ang H&M na bawasan ang assortment sa mga indibidwal na tindahan ng 40%, habang pinapanatili ang antas ng mga benta. Nakamit ito sa pamamagitan ng pagbubukod ng mga hindi magandang posisyon sa pagbebenta, at ang seasonality ay isinasaalang-alang sa mga kalkulasyon.
Pagpili ng tool
Ang pamantayan sa industriya para sa ganitong uri ng computing ay Hadoop. Bakit? Dahil ang Hadoop ay isang mahusay, well-documented na framework (ang parehong Habr ay nagbibigay ng maraming detalyadong artikulo sa paksang ito), na sinamahan ng isang buong hanay ng mga utility at library. Maaari kang magsumite ng malalaking set ng parehong structured at unstructured na data bilang input, at ang system mismo ang magpapamahagi sa kanila sa pagitan ng computing power. Bukod dito, ang parehong mga kapasidad na ito ay maaaring madagdagan o ma-disable anumang oras - ang parehong pahalang na scalability sa pagkilos.
Noong 2017, ang maimpluwensyang kumpanya sa pagkonsulta na Gartner na ang Hadoop ay malapit nang maging laos. Ang dahilan ay medyo banal: naniniwala ang mga analyst na ang mga kumpanya ay malawakang lilipat sa cloud, dahil doon sila makakapagbayad batay sa paggamit ng kapangyarihan sa pag-compute. Ang pangalawang mahalagang kadahilanan na sinasabing may kakayahang "ilibing" si Hadoop ay ang bilis ng trabaho. Dahil ang mga opsyon tulad ng Apache Spark o Google Cloud DataFlow ay mas mabilis kaysa sa MapReduce na pinagbabatayan ng Hadoop.
Ang Hadoop ay nakasalalay sa ilang mga haligi, ang pinaka-kapansin-pansin ay ang mga teknolohiya ng MapReduce (isang sistema para sa pamamahagi ng data para sa mga kalkulasyon sa pagitan ng mga server) at ang HDFS file system. Ang huli ay partikular na idinisenyo upang mag-imbak ng impormasyon na ipinamahagi sa pagitan ng mga cluster node: ang bawat bloke ng isang nakapirming laki ay maaaring ilagay sa ilang mga node, at salamat sa pagtitiklop, ang system ay lumalaban sa mga pagkabigo ng mga indibidwal na node. Sa halip na isang file table, isang espesyal na server na tinatawag na NameNode ang ginagamit.
Ipinapakita ng ilustrasyon sa ibaba kung paano gumagana ang MapReduce. Sa unang yugto, ang data ay nahahati ayon sa isang tiyak na katangian, sa pangalawang yugto ito ay ipinamamahagi sa pamamagitan ng kapangyarihan ng pag-compute, sa ikatlong yugto ang pagkalkula ay nagaganap.
Ang MapReduce ay orihinal na nilikha ng Google para sa mga pangangailangan ng paghahanap nito. Pagkatapos ay napunta ang MapReduce sa libreng code, at kinuha ng Apache ang proyekto. Well, unti-unting lumipat ang Google sa iba pang mga solusyon. Isang kawili-wiling nuance: sa ngayon, may proyekto ang Google na tinatawag na Google Cloud Dataflow, na nakaposisyon bilang susunod na hakbang pagkatapos ng Hadoop, bilang mabilis na kapalit nito.
Ang mas malapitang pagtingin ay nagpapakita na ang Google Cloud Dataflow ay nakabatay sa isang variation ng Apache Beam, habang kasama sa Apache Beam ang well-documented Apache Spark framework, na nagbibigay-daan sa amin na pag-usapan ang halos parehong bilis ng pagpapatupad ng solusyon. Well, gumagana nang maayos ang Apache Spark sa HDFS file system, na nagbibigay-daan sa iyong i-deploy ito sa mga server ng Hadoop.
Idagdag dito ang dami ng dokumentasyon at mga handa na solusyon para sa Hadoop at Spark laban sa Google Cloud Dataflow, at nagiging malinaw ang pagpili ng tool. Bukod dito, ang mga inhinyero ay maaaring magpasya para sa kanilang sarili kung aling code - sa ilalim ng Hadoop o Spark - sila ay isasagawa, na nakatuon sa gawain, karanasan at mga kwalipikasyon.
Cloud o lokal na server
Ang kalakaran patungo sa pangkalahatang paglipat sa cloud ay nagbunga pa ng isang kawili-wiling termino bilang Hadoop-as-a-service. Sa ganitong sitwasyon, ang pangangasiwa ng mga konektadong server ay naging napakahalaga. Dahil, sayang, sa kabila ng katanyagan nito, ang dalisay na Hadoop ay isang medyo mahirap na tool upang i-configure, dahil kailangan mong gumawa ng maraming sa pamamagitan ng kamay. Halimbawa, maaari mong i-configure ang mga server nang paisa-isa, subaybayan ang kanilang pagganap, at i-fine-tune ang maraming mga parameter. Sa pangkalahatan, magtrabaho para sa isang baguhan at may malaking pagkakataon na masiraan ng loob sa isang lugar o makaligtaan ang isang bagay.
Samakatuwid, ang iba't ibang mga pamamahagi ay naging napakapopular, na sa una ay nilagyan ng maginhawang pag-deploy at mga tool sa pangangasiwa. Ang isa sa mga mas sikat na pamamahagi na sumusuporta sa Spark at ginagawang madali ang mga bagay ay Cloudera. Mayroon itong parehong bayad at libreng mga bersyon - at sa huli, ang lahat ng pangunahing pag-andar ay magagamit, at nang hindi nililimitahan ang bilang ng mga node.
Sa panahon ng pag-setup, kokonekta ang Cloudera Manager sa pamamagitan ng SSH sa iyong mga server. Isang kawili-wiling punto: kapag nag-i-install, mas mahusay na tukuyin na ito ay isinasagawa ng tinatawag na mga parsela: mga espesyal na pakete, ang bawat isa ay naglalaman ng lahat ng kinakailangang sangkap na na-configure upang gumana sa isa't isa. Sa katunayan, ito ay isang pinahusay na bersyon ng manager ng package.
Pagkatapos ng pag-install, makakakuha kami ng cluster management console, kung saan makikita mo ang telemetry para sa mga cluster, mga naka-install na serbisyo, at maaari kang magdagdag / mag-alis ng mga mapagkukunan at i-edit ang configuration ng cluster.
Bilang resulta, ang pagputol ng rocket na iyon ay lalabas sa harap mo, na magdadala sa iyo sa magandang kinabukasan ng BigData. Pero bago natin sabihing "tara na", fast forward muna tayo sa ilalim ng hood.
mga kinakailangan sa hardware
Sa kanilang website, binanggit ng Cloudera ang iba't ibang posibleng configuration. Ang pangkalahatang mga prinsipyo kung saan sila ay binuo ay ipinapakita sa ilustrasyon:
Maaaring malabo ng MapReduce ang optimistikong larawang ito. Sa muling pagtingin sa diagram sa nakaraang seksyon, nagiging malinaw na sa halos lahat ng kaso, ang isang MapReduce na trabaho ay maaaring tumama sa isang bottleneck kapag nagbabasa ng data mula sa disk o network. Ito ay nabanggit din sa Cloudera blog. Bilang resulta, para sa anumang mabilis na mga kalkulasyon, kabilang ang sa pamamagitan ng Spark, na kadalasang ginagamit para sa real-time na mga kalkulasyon, ang bilis ng I / O ay napakahalaga. Samakatuwid, kapag gumagamit ng Hadoop, napakahalaga na ang balanse at mabilis na mga makina ay makapasok sa cluster, na, sa madaling sabi, ay hindi palaging ibinibigay sa imprastraktura ng ulap.
Ang balanse sa pamamahagi ng load ay nakakamit sa pamamagitan ng paggamit ng Openstack virtualization sa mga server na may malalakas na multi-core na CPU. Ang mga node ng data ay inilalaan ng kanilang sariling mga mapagkukunan ng processor at ilang mga disk. Sa aming solusyon Atos Codex Data Lake Engine malawak na virtualization ang nakakamit, kaya naman panalo tayo pareho sa performance (nababawasan ang epekto ng imprastraktura ng network) at TCO (tinatanggal ang mga sobrang pisikal na server).
Sa kaso ng paggamit ng mga server ng BullSequana S200, nakakakuha kami ng isang napaka-unipormeng load, na wala ng ilan sa mga bottleneck. Kasama sa minimum na configuration ang 3 BullSequana S200 server, bawat isa ay may dalawang JBOD, kasama ang karagdagang mga S200 na naglalaman ng apat na data node ay opsyonal na konektado. Narito ang isang halimbawa ng pag-load sa isang pagsubok na TeraGen:
Ang mga pagsubok na may iba't ibang dami ng data at mga halaga ng pagtitiklop ay nagpapakita ng parehong mga resulta sa mga tuntunin ng pamamahagi ng pagkarga sa mga cluster node. Nasa ibaba ang isang graph ng pamamahagi ng disk access sa pamamagitan ng mga pagsubok sa pagganap.
Ang mga kalkulasyon ay batay sa isang minimum na configuration ng 3 BullSequana S200 server. Kabilang dito ang 9 na data node at 3 master node, pati na rin ang mga nakareserbang virtual machine kung sakaling magkaroon ng proteksyon batay sa OpenStack Virtualization. Resulta ng pagsubok ng TeraSort: 512 MB block size ng replication factor ng tatlo na may encryption ay 23,1 minuto.
Paano mapapalawak ang sistema? Available ang iba't ibang uri ng extension para sa Data Lake Engine:
- Mga node ng data: para sa bawat 40 TB ng magagamit na espasyo
- Analytic node na may kakayahang mag-install ng GPU
- Iba pang mga opsyon depende sa mga pangangailangan ng negosyo (halimbawa, kung kailangan mo ng Kafka at mga katulad nito)
Kasama sa Atos Codex Data Lake Engine complex ang mga server mismo at paunang naka-install na software, kasama ang Cloudera kit na may lisensya; Ang Hadoop mismo, ang OpenStack na may mga virtual machine batay sa kernel ng RedHat Enterprise Linux, pagtitiklop ng data at mga backup system (kabilang ang paggamit ng backup node at Cloudera BDR - Backup at Disaster Recovery). Ang Atos Codex Data Lake Engine ay ang unang solusyon sa virtualization na na-certify .
Kung interesado ka sa mga detalye, ikalulugod naming sagutin ang aming mga tanong sa mga komento.
Pinagmulan: www.habr.com