{"id":33630,"date":"2019-10-31T21:53:49","date_gmt":"2019-10-31T18:53:49","guid":{"rendered":"https:\/\/prohoster.info\/blog\/chto-osobennogo-v-cloudera-i-kak-ee-gotovit\/"},"modified":"2019-10-31T21:53:49","modified_gmt":"2019-10-31T18:53:49","slug":"chto-osobennogo-v-cloudera-i-kak-ee-gotovit","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/chto-osobennogo-v-cloudera-i-kak-ee-gotovit","title":{"rendered":"Hvad er s\u00e6rligt ved Cloudera, og hvordan tilbereder man det.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Markedet for distribueret computing og big data vokser, hvis man skal tro statistikkerne<\/a><\/noindex>, med 18-19% om \u00e5ret. Det betyder, at sp\u00f8rgsm\u00e5let om valg af software til disse form\u00e5l stadig er relevant. I dette indl\u00e6g vil vi starte med, hvorfor distribueret computing er n\u00f8dvendigt, se n\u00e6rmere p\u00e5 valget af software, fort\u00e6lle om anvendelsen af Hadoop ved hj\u00e6lp af Cloudera, og til sidst diskutere valg af hardware og hvordan det p\u00e5virker ydeevnen p\u00e5 forskellige m\u00e5der.<\/p>\n

\"Hvad<\/a><\/noindex>
\nHvorfor er distribueret computing n\u00f8dvendigt i almindelig forretning? Her er svaret b\u00e5de enkelt og kompliceret. Enkelt \u2014 fordi vi i de fleste tilf\u00e6lde udf\u00f8rer relativt enkle beregninger pr. enhed information. Kompliceret \u2014 fordi der er s\u00e5 meget information. Rigtig meget. Som f\u00f8lge heraf skal vi behandle terabytes af data i 1000 str\u00f8mme.<\/a><\/noindex>Dermed er anvendelsesscenarierne ret universelle: beregninger kan anvendes overalt, hvor der er behov for at tage h\u00f8jde for et stort antal metric p\u00e5 et endnu st\u00f8rre datas\u00e6t.<\/p>\n

Et af de seneste eksempler er Dodo Pizza-k\u00e6den at de celler, der findes der, er makrofager, en del af immunsystemet. Flere m\u00e5neder senere fremlagde David Dickman og Le-Cing Wu<\/a><\/noindex> der har tilpasset indk\u00f8b baseret p\u00e5 analysen af kundernes ordredata, som viser, at brugerne normalt kun arbejder med seks grundl\u00e6ggende s\u00e6t ingredienser plus nogle tilf\u00e6ldige, n\u00e5r de v\u00e6lger en pizza med vilk\u00e5rlig topping. Desuden har det gjort det lettere for dem at anbefale ekstra varer til brugerne under bestillingsprocessen, hvilket har \u00f8get indtjeningen.<\/p>\n

Et andet eksempel: af deciderede enoghalvtredsere siger os, at kun 20% af dem blev grundlagt af \u00e9n person. Men er det v\u00e6rd at tage h\u00f8jde for denne v\u00e6rdi, n\u00e5r hver milliard-dollar virksomhed er en unik og uforlignelig historie? Desuden er en stor statistisk stikpr\u00f8ve altid mere pr\u00e6cis. M\u00f8det er nedbrudt.<\/a><\/noindex> produktpositioner har gjort det muligt for H&M at reducere sortimentet i enkelte butikker med 40%, mens salget er forblevet p\u00e5 samme niveau. Dette blev opn\u00e5et ved at udelukke produkter, der s\u00e6lger d\u00e5rligt, hvor der ogs\u00e5 blev taget hensyn til s\u00e6sonbestemthed.<\/p>\n

Valg af v\u00e6rkt\u00f8j<\/h2>\n

\nDen industrielle standard for denne slags beregning er Hadoop. Hvorfor? Fordi Hadoop er et fremragende, veldokumenteret framework (selv Habr udgiver mange detaljerede artikler om emnet), som kommer med et s\u00e6t v\u00e6rkt\u00f8jer og biblioteker. Du kan indtaste enorme m\u00e6ngder b\u00e5de strukturerede og ustrukturerede data, og systemet vil selv fordele dem mellem de beregningsm\u00e6ssige ressourcer. Disse ressourcer kan desuden tilf\u00f8jes eller fjernes n\u00e5r som helst \u2014 den horisontale skalerbarhed i aktion. <\/p>\n

I 2017 indgik det indflydelsesrige konsulentfirma Gartner at<\/a><\/noindex>, at Hadoop snart vil udd\u00f8. \u00c5rsagen er temmelig banal: analytikere mener, at virksomheder vil migrere massivt til skyen, da de d\u00e9r kan betale for faktisk brug af beregningskapacitet. Den anden vigtige faktor, der angiveligt kan \"begrave\" Hadoop, er hastigheden. Fordi l\u00f8sninger som Apache Spark eller Google Cloud DataFlow arbejder hurtigere end MapReduce, som er grundlaget for Hadoop.<\/p>\n

Hadoop hviler p\u00e5 flere s\u00f8jler, hvoraf de mest markante er teknologierne MapReduce (et distribueret datasystem til beregninger mellem servere) og filsystemet HDFS. Det sidste er specielt designet til at lagre information fordelt mellem klyngens noder: hver blok af fast st\u00f8rrelse kan lagres p\u00e5 flere noder, og takket v\u00e6re replikation opretholdes systemets robusthed over for fejl p\u00e5 enkelte noder. I stedet for en filtabel bruges en specialiseret server, kaldet NameNode.<\/p>\n

P\u00e5 illustrationen nedenfor vises skemaet for arbejdet med MapReduce. I det f\u00f8rste trin opdeles dataene efter et bestemt kriterium, i det andet distribueres de efter beregningskapaciteter, og i det tredje sker beregningen. <\/p>\n

\"Hvad
\nMapReduce blev oprindeligt skabt af Google til deres s\u00f8gesystem. Senere blev MapReduce \u00e5bnet som open source, og Apache tog over projektet. Google migrerede gradvis til andre l\u00f8sninger. En interessant detalje: i \u00f8jeblikket har Google et projekt ved navn Google Cloud Dataflow, der markedsf\u00f8res som det n\u00e6ste skridt efter Hadoop, som en hurtig erstatning.<\/p>\n

Ved n\u00e6rmere eftersyn ses det, at Google Cloud Dataflow er baseret p\u00e5 en variant af Apache Beam, hvor Apache Beam indeholder et vel-dokumenteret framework, Apache Spark, hvilket g\u00f8r, at man kan tale om praktisk talt samme hastighed ved udf\u00f8relse af l\u00f8sninger. Og Apache Spark fungerer fremragende p\u00e5 HDFS-filsystemet, hvilket muligg\u00f8r deployment p\u00e5 Hadoop-servere.<\/p>\n

Lad os tilf\u00f8je m\u00e6ngden af dokumentation og f\u00e6rdige l\u00f8sninger for Hadoop og Spark mod Google Cloud Dataflow, og valget af v\u00e6rkt\u00f8jet bliver \u00e5benbart. Ydermere kan ingeni\u00f8rer selv beslutte, hvilken kode \u2014 til Hadoop eller Spark \u2014 de vil udf\u00f8re, baseret p\u00e5 opgaven, erfaring og kvalifikation.<\/p>\n

Skyen eller lokal server<\/h2>\n

\nTendensen mod den generelle overgang til skyen har skabt et interessant begreb som Hadoop-as-a-service. I dette scenarie er administrationen af de tilsluttede servere blevet meget vigtig. For desv\u00e6rre, p\u00e5 trods af sin popularitet, er ren Hadoop et ret komplekst v\u00e6rkt\u00f8j at ops\u00e6tte, da der er mange ting, der skal g\u00f8res manuelt. For eksempel skal serverne konfigureres individuelt, overv\u00e5ges, og mange parametre skal indstilles omhyggeligt. Generelt er det noget for entusiaster, og der er en stor risiko for at lave fejl eller overse noget.<\/p>\n

Derfor har forskellige distributioner f\u00e5et stor popularitet, som oprindeligt leveres med brugervenlige deployments- og administrationsv\u00e6rkt\u00f8jer. En af de mest popul\u00e6re distributioner, som underst\u00f8tter Spark og forenkler det hele, er Cloudera. Den har b\u00e5de betalte og gratis versioner - og i den gratis version er al den grundl\u00e6ggende funktionalitet tilg\u00e6ngelig, uden begr\u00e6nsninger p\u00e5 antallet af noder. <\/p>\n

\"Hvad
\n
\nUnder ops\u00e6tningen vil Cloudera Manager oprette SSH-forbindelser til dine servere. Et interessant punkt er, at det under installationen er bedst at angive, at den skal udf\u00f8res med s\u00e5kaldte parceller<\/i>: specielle pakker, der hver indeholder alle de n\u00f8dvendige komponenter, konfigureret til at arbejde sammen. I bund og grund er det en forbedret version af en pakkemanager.<\/p>\n

Efter installationen f\u00e5r vi et clusters kontrolpanel, hvor man kan se telemetri for klyngerne, installerede tjenester, plus at du kan tilf\u00f8je\/fjerne ressourcer og redigere klyngens konfiguration. <\/p>\n

\"Hvad
\n
\nResultatet er, at du st\u00e5r over for sk\u00e6ringen af den raket, der vil f\u00f8re dig til BigData's lysere fremtid. Men f\u00f8r vi siger \u00ablad os g\u00e5\u00bb, lad os kigge under motorhjelmen.<\/p>\n

Krav til hardware<\/h2>\n

\nP\u00e5 deres hjemmeside n\u00e6vner Cloudera forskellige mulige konfigurationer. De generelle principper, som de bygger p\u00e5, er vist i illustrationen:<\/p>\n

\"Hvad
\nEt optimistisk scenarie kan blive skadet af MapReduce. Hvis man ser n\u00e6rmere p\u00e5 diagrammet fra det foreg\u00e5ende afsnit, bliver det tydeligt, at n\u00e6sten alle gange kan en MapReduce-opgave st\u00f8de p\u00e5 et 'flaskehals' problem, n\u00e5r data l\u00e6ses fra disken eller nettet. Dette er ogs\u00e5 n\u00e6vnt i Clouderas blog. Derfor er ind- og udgangshastighed meget vigtig for hurtige beregninger, herunder via Spark, som ofte anvendes til realtidsberegninger. Derfor er det vigtigt, n\u00e5r man bruger Hadoop, at der findes balancerede og hurtige maskiner i klyngen, hvilket ikke altid kan garanteres i cloud-infrastrukturen.<\/p>\n

Balancen i belastningsfordelingen opn\u00e5s ved at bruge Openstack-virtualisering p\u00e5 servere med kraftige multikern CPU'er. Data-noderne tildeles deres egne processorressourcer og specifikke diske. I vores l\u00f8sning Atos Codex Data Lake Engine<\/i> opn\u00e5s omfattende virtualisering, hvilket giver os fordele b\u00e5de i forhold til ydeevne (netv\u00e6rksinfrastrukturen har minimal indflydelse) og TCO (un\u00f8dvendige fysiske servere elimineres).<\/p>\n

\"Hvad
\nVed brug af BullSequana S200-servere opn\u00e5r vi en j\u00e6vnere belastning, som mangler visse flaskehalse. Den minimale konfiguration inkluderer 3 BullSequana S200-servere, hver med to JBOD, plus yderligere S200-servere kan tilsluttes som option, som indeholder fire data-noder hver. Her er et eksempel p\u00e5 belastning i TeraGen-testen:<\/p>\n

\"Hvad
\n
\nTest med forskellige datam\u00e6ngder og replikationsv\u00e6rdier viser ens resultater med hensyn til belastningsfordeling mellem klyngens noder. Nedenfor er et diagram, der viser diskadgangsfordeling under performance-tests.<\/p>\n

\"Hvad
\n
\nBeregnede resultater er baseret p\u00e5 den minimale konfiguration best\u00e5ende af 3 BullSequana S200-servere. Den inkluderer 9 datanoder og 3 prim\u00e6re noder samt reserverede virtuelle maskiner til potentiel implementering af beskyttelse baseret p\u00e5 OpenStack Virtualization. TeraSort-testresultatet: blokst\u00f8rrelse 512 MB med en replikationsfaktor p\u00e5 tre og kryptering tager 23,1 minutter.<\/p>\n

Hvordan kan systemet udvides? Der er forskellige former for udvidelser til Data Lake Engine:<\/p>\n