El mercat de la informàtica distribuïda i el big data, segons , està creixent al 18-19% anual. Això vol dir que la qüestió de triar programari per a aquests propòsits segueix sent rellevant. En aquest post, començarem per què necessitem la informàtica distribuïda, ens atendrem amb més detall en l'elecció del programari, parlarem de l'ús de Hadoop amb Cloudera i, finalment, parlarem de l'elecció del maquinari i com afecta el rendiment. de diferents maneres.
Per què necessitem la informàtica distribuïda en el negoci normal? Tot és senzill i complicat alhora. Simple - perquè en la majoria dels casos realitzem càlculs relativament senzills per unitat d'informació. Difícil, perquè hi ha molta informació d'aquest tipus. Molts. Com a conseqüència, s'ha de fer . Per tant, els casos d'ús són força universals: els càlculs es poden aplicar allà on es requereixi per tenir en compte un gran nombre de mètriques en una matriu de dades encara més gran.
Un exemple recent: Dodo Pizza a partir d'una anàlisi de la base de comandes dels clients, que a l'hora de triar una pizza amb cobertura arbitraria, els usuaris solen operar amb només sis jocs bàsics d'ingredients més un parell d'atzars. En conseqüència, la pizzeria va ajustar les compres. A més, va poder recomanar millor als usuaris productes addicionals oferts en l'etapa de la comanda, fet que va augmentar els beneficis.
Un altre exemple: La mercaderia va permetre a H&M reduir un 40% l'assortiment a les botigues individuals, tot mantenint el nivell de vendes. Això s'aconseguia excloent les posicions de mala venda i en els càlculs es va tenir en compte l'estacionalitat.
Selecció d'eines
L'estàndard del sector per a aquest tipus d'informàtica és Hadoop. Per què? Perquè Hadoop és un marc excel·lent i ben documentat (el mateix Habr ofereix molts articles detallats sobre aquest tema), que s'acompanya de tot un conjunt d'utilitats i biblioteques. Podeu enviar grans conjunts de dades tant estructurades com no estructurades com a entrada, i el propi sistema les distribuirà entre la potència de càlcul. A més, aquestes mateixes capacitats es poden augmentar o desactivar en qualsevol moment, la mateixa escalabilitat horitzontal en acció.
El 2017, la influent consultora Gartner que Hadoop aviat quedarà obsolet. El motiu és bastant banal: els analistes creuen que les empreses migraran massivament al núvol, ja que allà podran pagar en funció de l'ús de la potència informàtica. El segon factor important suposadament capaç d'"enterrar" Hadoop és la velocitat de treball. Perquè opcions com Apache Spark o Google Cloud DataFlow són més ràpides que el MapReduce subjacent a Hadoop.
Hadoop es basa en diversos pilars, els més destacats són les tecnologies MapReduce (un sistema de distribució de dades per a càlculs entre servidors) i el sistema de fitxers HDFS. Aquest últim està específicament dissenyat per emmagatzemar informació distribuïda entre nodes del clúster: cada bloc d'una mida fixa es pot col·locar en diversos nodes i, gràcies a la replicació, el sistema és resistent a fallades de nodes individuals. En lloc d'una taula de fitxers, s'utilitza un servidor especial anomenat NameNode.
La il·lustració següent mostra com funciona MapReduce. A la primera etapa, les dades es divideixen segons un atribut determinat, a la segona etapa es distribueixen per potència de càlcul, a la tercera etapa es fa el càlcul.
MapReduce va ser creat originalment per Google per a les necessitats de la seva cerca. Aleshores MapReduce va entrar al codi lliure i Apache es va fer càrrec del projecte. Bé, Google va migrar gradualment a altres solucions. Un matís interessant: de moment, Google té un projecte anomenat Google Cloud Dataflow, posicionat com el següent pas després d'Hadoop, com a substitut ràpid.
Una mirada més propera mostra que Google Cloud Dataflow es basa en una variació d'Apache Beam, mentre que Apache Beam inclou el marc Apache Spark ben documentat, que ens permet parlar gairebé a la mateixa velocitat d'execució de la solució. Bé, Apache Spark funciona bé al sistema de fitxers HDFS, que us permet desplegar-lo als servidors Hadoop.
Afegiu aquí el volum de documentació i solucions ja fetes per a Hadoop i Spark contra Google Cloud Dataflow i l'elecció de l'eina es farà evident. A més, els enginyers poden decidir per ells mateixos quin codi, sota Hadoop o Spark, executaran, centrant-se en la tasca, l'experiència i les qualificacions.
Servidor local o al núvol
La tendència cap a la transició general al núvol fins i tot ha donat lloc a un terme tan interessant com Hadoop-as-a-service. En aquest escenari, l'administració dels servidors connectats ha esdevingut molt important. Perquè, per desgràcia, malgrat la seva popularitat, Hadoop pur és una eina força difícil de configurar, ja que s'ha de fer molt a mà. Per exemple, podeu configurar servidors individualment, supervisar-ne el rendiment i ajustar molts paràmetres. En general, treballeu per a un aficionat i hi ha una gran possibilitat d'enganxar-vos en algun lloc o perdre's alguna cosa.
Per tant, s'han tornat molt populars diverses distribucions, que inicialment estan equipades amb eines de desplegament i administració convenients. Una de les distribucions més populars que admet Spark i facilita les coses és Cloudera. Té versions tant de pagament com gratuïtes, i en aquesta última, totes les funcionalitats principals estan disponibles, i sense limitar el nombre de nodes.
Durant la configuració, Cloudera Manager es connectarà mitjançant SSH als vostres servidors. Un punt interessant: a l'hora d'instal·lar, és millor especificar que ho faci l'anomenat parcel·les: paquets especials, cadascun dels quals conté tots els components necessaris configurats per funcionar entre si. De fet, aquesta és una versió tan millorada del gestor de paquets.
Després de la instal·lació, obtenim una consola de gestió de clúster, on podeu veure la telemetria dels clústers, els serveis instal·lats, a més podeu afegir/eliminar recursos i editar la configuració del clúster.
Com a resultat, el tall d'aquest coet apareix davant vostre, que us portarà al futur brillant de BigData. Però abans de dir "anem", avancem ràpidament sota el capó.
requisits de maquinari
A la seva pàgina web, Cloudera esmenta diferents configuracions possibles. Els principis generals pels quals es construeixen es mostren a la il·lustració:
MapReduce pot desdibuixar aquesta imatge optimista. Si tornem a mirar el diagrama de la secció anterior, queda clar que, en gairebé tots els casos, un treball de MapReduce pot arribar a un coll d'ampolla en llegir dades del disc o la xarxa. Això també es nota al blog de Cloudera. Com a resultat, per a qualsevol càlcul ràpid, inclòs mitjançant Spark, que s'utilitza sovint per a càlculs en temps real, la velocitat d'E/S és molt important. Per tant, quan s'utilitza Hadoop, és molt important que les màquines equilibrades i ràpides entrin al clúster, que, per dir-ho suaument, no sempre es proporciona a la infraestructura del núvol.
L'equilibri en la distribució de càrrega s'aconsegueix mitjançant l'ús de la virtualització Openstack en servidors amb potents CPU multinúclis. Als nodes de dades se'ls assignen els seus propis recursos de processador i determinats discs. En la nostra solució Motor Atos Codex Data Lake s'aconsegueix una virtualització àmplia, per això guanyem tant pel que fa al rendiment (es minimitza l'impacte de la infraestructura de xarxa) com al TCO (s'eliminen els servidors físics addicionals).
En el cas d'utilitzar servidors BullSequana S200, obtenim una càrrega molt uniforme, desproveïda d'alguns colls d'ampolla. La configuració mínima inclou 3 servidors BullSequana S200, cadascun amb dos JBOD, a més de S200 addicionals que contenen quatre nodes de dades es connecten opcionalment. Aquí teniu un exemple de càrrega en una prova TeraGen:
Les proves amb diferents volums de dades i valors de replicació mostren els mateixos resultats pel que fa a la distribució de càrrega entre els nodes del clúster. A continuació es mostra un gràfic de la distribució de l'accés al disc per proves de rendiment.
Els càlculs es basen en una configuració mínima de 3 servidors BullSequana S200. Inclou 9 nodes de dades i 3 nodes mestres, així com màquines virtuals reservades en cas de desplegament de protecció basada en la virtualització OpenStack. Resultat de la prova TeraSort: la mida de bloc de 512 MB d'un factor de replicació de tres amb xifratge és de 23,1 minuts.
Com es pot ampliar el sistema? Hi ha disponibles diversos tipus d'extensions per al Data Lake Engine:
- Nodes de dades: per cada 40 TB d'espai utilitzable
- Nodes analítics amb la possibilitat d'instal·lar una GPU
- Altres opcions en funció de les necessitats del negoci (per exemple, si necessiteu Kafka i similars)
El complex Atos Codex Data Lake Engine inclou tant els propis servidors com el programari preinstal·lat, inclòs el kit Cloudera amb llicència; Hadoop mateix, OpenStack amb màquines virtuals basades en el nucli RedHat Enterprise Linux, replicació de dades i sistemes de còpia de seguretat (incloent l'ús d'un node de còpia de seguretat i Cloudera BDR - Backup and Disaster Recovery). Atos Codex Data Lake Engine és la primera solució de virtualització certificada .
Si esteu interessats en els detalls, estarem encantats de respondre les nostres preguntes als comentaris.
Font: www.habr.com