Hajautetun tietojenkäsittelyn ja big datan markkinat mukaan
Miksi tarvitsemme hajautettua tietojenkäsittelyä tavallisessa liiketoiminnassa? Kaikki on yhtä aikaa yksinkertaista ja monimutkaista. Yksinkertainen - koska useimmissa tapauksissa suoritamme suhteellisen yksinkertaisia laskelmia tietoyksikköä kohden. Vaikeaa - koska tällaista tietoa on paljon. Niin monta. Tämän seurauksena on pakko
Yksi tuore esimerkki: Dodo Pizza
Toinen esimerkki:
Työkalun valinta
Tällaisten tietojenkäsittelyn alan standardi on Hadoop. Miksi? Koska Hadoop on erinomainen, hyvin dokumentoitu kehys (sama Habr julkaisee monia yksityiskohtaisia artikkeleita tästä aiheesta), johon liittyy koko joukko apuohjelmia ja kirjastoja. Voit lähettää syötteeksi suuria joukkoja sekä strukturoitua että strukturoimatonta dataa, ja järjestelmä itse jakaa ne laskentatehon kesken. Lisäksi näitä samoja kapasiteettia voidaan lisätä tai poistaa käytöstä milloin tahansa - sama horisontaalinen skaalautuvuus toiminnassa.
Vuonna 2017 vaikutusvaltainen konsulttiyritys Gartner
Hadoop perustuu useisiin pilareihin, joista merkittävimmät ovat MapReduce-tekniikat (järjestelmä tietojen jakamiseen laskelmia varten palvelimien välillä) ja HDFS-tiedostojärjestelmä. Jälkimmäinen on suunniteltu erityisesti tallentamaan klusterisolmujen välillä hajautettua tietoa: jokainen kiinteän kokoinen lohko voidaan sijoittaa useisiin solmuihin, ja replikoinnin ansiosta järjestelmä kestää yksittäisten solmujen vikoja. Tiedostotaulukon sijasta käytetään erityistä palvelinta nimeltä NameNode.
Alla oleva kuva näyttää, kuinka MapReduce toimii. Ensimmäisessä vaiheessa tiedot jaetaan tietyn attribuutin mukaan, toisessa vaiheessa se jaetaan laskentatehon mukaan, kolmannessa vaiheessa tapahtuu laskenta.
MapReducen loi alun perin Google hakuja varten. Sitten MapReduce siirtyi ilmaiseen koodiin, ja Apache otti projektin haltuunsa. No, Google siirtyi vähitellen muihin ratkaisuihin. Mielenkiintoinen vivahde: Googlella on tällä hetkellä Hadoopin jälkeen seuraavana askeleena Google Cloud Dataflow -niminen projekti sen nopeaksi korvaajaksi.
Tarkempi tarkastelu osoittaa, että Google Cloud Dataflow perustuu Apache Beamin muunnelmaan, kun taas Apache Beam sisältää hyvin dokumentoidun Apache Spark -kehyksen, jonka avulla voimme puhua lähes samasta ratkaisun suoritusnopeudesta. No, Apache Spark toimii hyvin HDFS-tiedostojärjestelmässä, jonka avulla voit ottaa sen käyttöön Hadoop-palvelimilla.
Lisää tähän joukko dokumentteja ja valmiita ratkaisuja Hadoopille ja Sparkille Google Cloud Dataflow -palvelua vastaan, niin työkalun valinta tulee ilmeiseksi. Lisäksi insinöörit voivat itse päättää, minkä koodin - Hadoopin tai Sparkin alla - he suorittavat, keskittyen tehtävään, kokemukseen ja pätevyyteen.
Pilvi tai paikallinen palvelin
Suuntaus kohti yleistä pilveen siirtymistä on synnyttänyt jopa niin mielenkiintoisen termin kuin Hadoop-as-a-service. Tällaisessa tilanteessa yhdistettyjen palvelimien hallinnasta on tullut erittäin tärkeää. Koska valitettavasti suosiosta huolimatta puhdas Hadoop on melko vaikea konfiguroida työkalu, koska sinun on tehtävä paljon käsin. Voit esimerkiksi määrittää palvelimet yksitellen, valvoa niiden suorituskykyä ja hienosäätää monia parametreja. Yleensä työskentele amatöörille ja on suuri mahdollisuus mennä johonkin pieleen tai missata jotain.
Siksi eri jakeluista on tullut erittäin suosittuja, jotka on alun perin varustettu kätevillä käyttöönotto- ja hallintatyökaluilla. Yksi suosituimmista jakeluista, joka tukee Sparkia ja tekee asioista helppoa, on Cloudera. Sillä on sekä maksullisia että ilmaisia versioita - ja jälkimmäisessä kaikki tärkeimmät toiminnot ovat käytettävissä, ja solmujen määrää rajoittamatta.
Asennuksen aikana Cloudera Manager muodostaa yhteyden palvelimiisi SSH:n kautta. Mielenkiintoinen kohta: asennuksen yhteydessä on parempi määrittää, että sen suorittaa ns paketteja: erikoispaketit, joista jokainen sisältää kaikki tarvittavat komponentit, jotka on määritetty toimimaan keskenään. Itse asiassa tämä on niin parannettu versio paketinhallinnasta.
Asennuksen jälkeen saamme klusterinhallintakonsolin, jossa näet klustereiden telemetrian, asennetut palvelut sekä voit lisätä/poistaa resursseja ja muokata klusterin kokoonpanoa.
Tämän seurauksena tuon raketin leikkaus näkyy edessäsi, mikä vie sinut BigDatan valoisaan tulevaisuuteen. Mutta ennen kuin sanomme "mennään", kelataanpa konepellin alle.
laitteistovaatimukset
Cloudera mainitsee verkkosivuillaan erilaisia mahdollisia kokoonpanoja. Yleiset periaatteet, joiden mukaan ne on rakennettu, näkyvät kuvassa:
MapReduce voi hämärtää tämän optimistisen kuvan. Kun tarkastellaan uudelleen edellisen osan kaaviota, käy selväksi, että melkein kaikissa tapauksissa MapReduce-työ voi osua pullonkaulan lukemiseen levyltä tai verkosta. Tämä mainitaan myös Cloudera-blogissa. Tämän seurauksena I/O-nopeus on erittäin tärkeä kaikissa nopeissa laskelmissa, mukaan lukien Sparkissa, jota usein käytetään reaaliaikaisiin laskelmiin. Siksi Hadoopia käytettäessä on erittäin tärkeää, että klusteriin pääsevät tasapainoiset ja nopeat koneet, joita ei lievästi sanottuna aina tarjota pilviinfrastruktuurissa.
Tasapaino kuormituksen jakautumisessa saavutetaan käyttämällä Openstack-virtualisointia palvelimilla, joissa on tehokkaat moniytimiset prosessorit. Datasolmuille on allokoitu omat prosessoriresurssit ja tietyt levyt. Meidän ratkaisussamme Atos Codex Data Lake -moottori saavutetaan laaja virtualisointi, minkä vuoksi voitamme sekä suorituskyvyn (verkkoinfrastruktuurin vaikutus minimoituu) että TCO:n (ylimääräiset fyysiset palvelimet eliminoituvat).
BullSequana S200 -palvelimia käytettäessä saamme erittäin tasaisen kuormituksen, josta puuttuu joitain pullonkauloja. Vähimmäiskokoonpano sisältää 3 BullSequana S200 -palvelinta, joissa kussakin on kaksi JBOD:tä, sekä lisä-S200, jotka sisältävät neljä datasolmua, on valinnaisesti kytkettynä. Tässä on esimerkkikuorma TeraGen-testissä:
Testit erilaisilla tietomäärillä ja replikointiarvoilla näyttävät samat tulokset kuormituksen jakautumisessa klusterin solmujen välillä. Alla on kaavio levykäytön jakautumisesta suorituskykytesteillä.
Laskelmat perustuvat vähintään kolmen BullSequana S3 -palvelimen kokoonpanoon. Se sisältää 200 datasolmua ja 9 pääsolmua sekä varatut virtuaalikoneet OpenStack Virtualisointiin perustuvan suojauksen käyttöönoton tapauksessa. TeraSort-testin tulos: 3 Mt:n lohkokoko replikointikertoimella kolme salauksella on 512 minuuttia.
Miten järjestelmää voidaan laajentaa? Data Lake Enginelle on saatavana erilaisia laajennuksia:
- Datasolmut: jokaista 40 TB käytettävissä olevaa tilaa kohti
- Analyyttiset solmut, joilla on mahdollisuus asentaa GPU
- Muut vaihtoehdot liiketoiminnan tarpeista riippuen (esimerkiksi jos tarvitset Kafkaa ja vastaavia)
Atos Codex Data Lake Engine -kompleksi sisältää sekä itse palvelimet että esiasennetut ohjelmistot, mukaan lukien Cloudera-sarjan lisenssillä; Itse Hadoop, OpenStack RedHat Enterprise Linux -ytimeen pohjautuvilla virtuaalikoneilla, tietojen replikointi- ja varmuuskopiointijärjestelmät (mukaan lukien varmuuskopiosolmun ja Cloudera BDR:n käyttäminen - Backup and Disaster Recovery). Atos Codex Data Lake Engine on ensimmäinen virtualisointiratkaisu, joka on sertifioitu
Jos olet kiinnostunut yksityiskohdista, vastaamme mielellämme kysymyksiimme kommenteissa.
Lähde: will.com