HBase arhitektūra: HBase datu modelis un HBase lasīšanas / rakstīšanas mehānisms

HBase arhitektūra

Manā iepriekšējā blogā HBase apmācība , Es paskaidroju, kas ir HBase un tās funkcijas. Es arī pieminēju Facebook Messenger gadījumu izpēti, lai palīdzētu jums labāk sazināties. Tagad tālāk virzāmies uz priekšu mūsu , Es jums izskaidrošu HBase un HBase arhitektūras datu modeli.Pirms doties tālāk, jums arī jāzina, ka HBase ir svarīgs jēdziens, kas veido neatņemamu par Big Data Hadoop sertifikāciju.

Svarīgās tēmas, ar kurām es jūs iepazīstināšu šajā HBase arhitektūras emuārā, ir:

• HBase datu modelis
• HBase arhitektūra un tās komponenti
• HBase rakstīšanas mehānisms
• HBase lasīšanas mehānisms
• HBase veiktspējas optimizācijas mehānismi

Ļaujiet mums vispirms saprast HBase datu modeli. Tas palīdz HBase ātrāk lasīt / rakstīt un meklēt.

HBase arhitektūra: HBase datu modelis

Kā mēs zinām, HBase ir uz kolonnām orientēta NoSQL datu bāze. Lai gan tas izskatās līdzīgs relāciju datu bāzei, kurā ir rindas un kolonnas, taču tā nav relāciju datu bāze. Relāciju datu bāzes ir orientētas uz rindām, bet HBase ir orientētas uz kolonnām. Tātad vispirms ļaujiet mums saprast atšķirību starp kolonnām un rindām orientētām datu bāzēm:

Uz rindu un kolonnām orientētas datu bāzes:

• Uz rindām orientētās datu bāzēs tabulu ieraksti tiek glabāti rindu secībā. Tā kā kolonnu orientētas datu bāzesglabājiet tabulas ierakstus kolonnu secībā, t.i., kolonnas ieraksti tiek glabāti blakus esošās diska vietās.

Lai to labāk izprastu, ņemsim piemēru un ņemsim vērā zemāk esošo tabulu.

Ja šī tabula tiek glabāta uz rindu orientētā datu bāzē. Tas glabās ierakstus, kā parādīts zemāk:

viens,Pols Volkers,ASV,231,Galants,

2, Vins Dīzels,Brazīlija,520,Mustangs

kā izmantot skenera klasi Java

Uz rindām orientētās datu bāzēs dati tiek glabāti, pamatojoties uz rindām vai rindkopām, kā redzat iepriekš.

Kamēr kolonnu orientētās datu bāzēs šie dati tiek glabāti kā:

viens,2, Pols Volkers,Vins Dīzels, ASV,Brazīlija, 231,520, Galants,Mustangs

Uz kolonnām orientētās datu bāzēs visas kolonnu vērtības tiek glabātas kopā, tāpat kā pirmās kolonnas vērtības tiks glabātas kopā, pēc tam otrās kolonnas vērtības tiks glabātas kopā un dati citās kolonnās tiks glabāti līdzīgā veidā.

• Kad datu apjoms ir ļoti liels, piemēram, attiecībā uz petabaitu vai eksabaitu, mēs izmantojam uz kolonnām orientētu pieeju, jo vienas kolonnas dati tiek glabāti kopā un tiem var piekļūt ātrāk.
• Lai gan uz rindām orientētā pieeja salīdzinoši efektīvi apstrādā mazāku rindu un kolonnu skaitu, jo uz rindām orientētā datu bāzu krātuvēs dati ir strukturēts formāts.
• Kad mums jāapstrādā un jāanalizē liels daļēji strukturētu vai nestrukturētu datu kopums, mēs izmantojam kolonnu orientētu pieeju. Piemēram, lietojumprogrammas, kas nodarbojas ar Tiešsaistes analītiskā apstrāde piemēram, datu ieguve, datu glabāšana, lietojumprogrammas, tostarp analīze, utt.
• Tā kā, Tiešsaistes darījumu apstrāde piemēram, banku un finanšu jomās, kas apstrādā strukturētus datus un kurām nepieciešamas darījumu īpašības (ACID īpašības), izmanto uz rindām orientētu pieeju.

HBase tabulās ir šādi komponenti, kas parādīti zemāk esošajā attēlā:

• Galdi : Dati tiek glabāti tabulas formātā HBase. Bet šeit tabulas ir uz kolonnām orientētā formātā.
• Rinda Atslēga : Rindu taustiņus izmanto, lai meklētu ierakstus, kas ātri veic meklēšanu. Jums būtu interesanti zināt, kā? Es to paskaidrošu šajā emuārā esošajā arhitektūras daļā.
• Sleja Ģimenes : Kolonnu saimē tiek apvienotas dažādas kolonnas. Šīs kolonnu saimes tiek glabātas kopā, kas padara meklēšanas procesu ātrāku, jo datiem, kas pieder tai pašai kolonnu saimei, var piekļūt kopā vienā meklēšanā.
• Sleja Kvalifikācijas : Katras kolonnas nosaukums ir pazīstams kā tās slejas kvalifikators.
• Šūna : Dati tiek glabāti šūnās. Dati tiek izmesti šūnās, kuras īpaši identificē pēc rindu un kolonnu kvalifikatoriem.
• Laika zīmogs : Laika zīmogs ir datuma un laika kombinācija. Ikreiz, kad tiek glabāti dati, tie tiek glabāti ar laika zīmogu. Tas atvieglo konkrētas datu versijas meklēšanu.

Vienkāršākā un saprotošākā veidā mēs varam teikt, ka HBase sastāv no:

• Galdu komplekts
• Katra tabula ar kolonnu grupām un rindām
• Rindas atslēga HBase darbojas kā primārā atslēga.
• Jebkura piekļuve HBase tabulām izmanto šo primāro atslēgu
• Katrs kolonnas kvalifikators, kas atrodas HBase, apzīmē atribūtu, kas atbilst objektam, kas atrodas šūnā.

Tagad, kad jūs zināt par HBase datu modeli, ļaujiet mums redzēt, kā šis datu modelis atbilst HBase arhitektūrai un padara to piemērotu lielai glabāšanai un ātrākai apstrādei.

HBase arhitektūra: HBase arhitektūras komponenti

HBase ir trīs galvenie komponenti, t.i., HMaster serveris , HBase reģiona serveris, reģioni un Zoodārza sargs .

Zemāk redzamais attēls izskaidro HBase arhitektūras hierarhiju. Parunāsim par katru atsevišķi.

Pirms došanās uz HMaster mēs sapratīsim reģionus, jo visi šie serveri (HMaster, Region Server, Zookeeper) ir izvietoti, lai koordinētu un pārvaldītu reģionus un veiktu dažādas darbības reģionos. Tāpēc jums būtu interesanti uzzināt, kas ir reģioni un kāpēc tie ir tik svarīgi?

HBase arhitektūra: Novads

Reģionā ir visas rindas starp sākuma un beigu atslēgu, kas piešķirtas šim reģionam. HBase tabulas var sadalīt vairākos reģionos tādā veidā, ka visas kolonnu saimes kolonnas tiek glabātas vienā reģionā. Katrā reģionā rindas ir sakārtotas secībā.

Daudzi reģioni tiek piešķirti a Reģiona serveris , kas ir atbildīgs par lasīšanas un rakstīšanas darbību apstrādi, pārvaldību, izpildi šajā reģionu kopā.

Tātad, secinot vienkāršāk:

• Tabulu var iedalīt vairākos reģionos. Reģions ir sakārtots rindu diapazons, kurā tiek glabāti dati starp sākuma atslēgu un beigu atslēgu.
• Reģiona noklusējuma lielums ir 256 MB, ko var konfigurēt atbilstoši vajadzībām.
• Reģionu grupu klientiem apkalpo reģiona serveris.
• Reģiona serveris klientam var apkalpot aptuveni 1000 reģionus.

Tagad, sākot no hierarhijas augšdaļas, vispirms es vēlos jums paskaidrot par HMaster Server, kas darbojas līdzīgi kā NameNode HDFS . Pēc tam, pārejot uz leju hierarhijā, es jūs aizvedīšu caur ZooKeeper un Region Server.

HBase arhitektūra: HMaster

Tāpat kā šajā attēlā, jūs varat redzēt, kā HMaster apstrādā reģiona servera kolekciju, kas atrodas DataNode. Ļaujiet mums saprast, kā HMaster to dara.

• HBase HMaster veic DDL darbības (izveido un izdzēš tabulas) un piešķir reģionus reģionu serveriem, kā redzat iepriekš redzamajā attēlā.
• Tas koordinē un pārvalda reģiona serveri (līdzīgi kā NameNode pārvalda DataNode HDFS).
• Sākotnēji tas piešķir reģionus reģionālajiem serveriem un atjaunošanas un slodzes līdzsvarošanas laikā reģionus piešķir reģionu serveriem.
• Tas uzrauga visus reģiona servera gadījumus klasterī (ar Zookeeper palīdzību) un veic atkopšanas darbības ikreiz, kad kāds reģiona serveris nedarbojas.
• Tas nodrošina saskarni tabulu izveidei, dzēšanai un atjaunināšanai.

HBase ir izplatīta un milzīga vide, kur tikai ar HMaster nepietiek, lai visu pārvaldītu. Tātad, jūs domājat, kas palīdz HMaster pārvaldīt šo milzīgo vidi? Šeit ZooKeeper nonāk attēlā. Pēc tam, kad būsim sapratuši, kā HMaster pārvalda HBase vidi, mēs sapratīsim, kā Zookeeper palīdz HMaster pārvaldīt vidi.

HBase arhitektūra: ZooKeeper - koordinators

Šis zemāk esošais attēls izskaidro ZooKeeper koordinācijas mehānismu.

• Zookeeper darbojas kā koordinators HBase izplatītajā vidē. Tas palīdz saglabāt servera stāvokli klastera iekšienē, sazinoties caur sesijām.
• Katrs reģiona serveris kopā ar HMaster Server regulāri sūta sirdsdarbību Zookeeper un pārbauda, ​​kurš serveris ir dzīvs un pieejams, kā minēts iepriekš redzamajā attēlā. Tas nodrošina arī servera kļūmes paziņojumus, lai varētu izpildīt atkopšanas pasākumus.
• Atsaucoties uz iepriekš redzamo attēlu, ir redzams neaktīvs serveris, kas darbojas kā aktīvā servera dublējums. Ja aktīvais serveris neizdodas, tas nāk glābšanai.
• Aktīvais HMaster sūta sirdsdarbību Zookeeper, bet neaktīvais HMaster klausās aktīvā HMaster paziņojumus. Ja aktīvais HMaster neizdodas nosūtīt sirdsdarbību, sesija tiek izdzēsta un neaktīvais HMaster kļūst aktīvs.
• Ja reģiona serverim neizdodas nosūtīt sirdsdarbību, sesijas termiņš ir beidzies, un par to tiek paziņots visiem klausītājiem. Tad HMaster veic piemērotas atkopšanas darbības, kuras mēs apspriedīsim vēlāk šajā emuārā.
• Zookeeper uztur arī .META Server ceļu, kas palīdz jebkuram klientam meklēt jebkuru reģionu. Vispirms klientam ir jāpārbauda .META Server, kuram reģiona serverim pieder reģions, un tas iegūst šī reģiona servera ceļu.

Kad es runāju par .META serveri, ļaujiet man vispirms jums paskaidrot, kas ir .META serveris? Tātad, jūs varat viegli saistīt ZooKeeper un .META Server darbu kopā. Vēlāk, kad es jums šajā blogā izskaidrošu HBase meklēšanas mehānismu, es paskaidrošu, kā šie divi darbojas sadarbībā.

HBase arhitektūra: Meta tabula

• META tabula ir īpaša HBase kataloga tabula. Tas uztur visu reģionu serveru sarakstu HBase atmiņas sistēmā, kā redzat iepriekš redzamajā attēlā.
• Aplūkojot redzamo skaitli, .META fails uztur tabulu atslēgu un vērtību veidā. Atslēga apzīmē reģiona sākuma atslēgu un tā ID, savukārt vērtība satur reģiona servera ceļu.

Kā es jau apspriedu, reģiona serveris un tā funkcijas, kamēr es jums izskaidroju reģionus, tagad mēs virzāmies lejup pa hierarhiju, un es pievērsīšos reģiona servera komponentam un to funkcijām. Vēlāk es apspriedīšu meklēšanas, lasīšanas, rakstīšanas mehānismu un sapratīšu, kā visi šie komponenti darbojas kopā.

HBase arhitektūra: Reģiona servera komponenti

Šajā zemāk redzamajā attēlā ir redzami reģiona servera komponenti. Tagad es tos apspriedīšu atsevišķi.

Reģiona serveris uztur dažādus reģionus, kas darbojas augšdaļā . Reģiona servera sastāvdaļas ir:

• WAL: Kā jūs varat secināt no iepriekš minētā attēla, Write Ahead Log (WAL) ir fails, kas pievienots katram reģiona serverim izplatītajā vidē. WAL glabā jaunos datus, kas nav saglabāti vai piešķirti pastāvīgai glabāšanai. To izmanto, ja datu kopas nav iespējams atgūt.
• Bloķēt kešatmiņu: No iepriekš minētā attēla ir skaidri redzams, ka bloka kešatmiņa atrodas reģiona servera augšdaļā. Tas glabā atmiņā bieži nolasītos datus. Ja BlockCache dati ir nesen izmantoti, šie dati tiek noņemti no BlockCache.
• MemStore: Tā ir rakstīšanas kešatmiņa. Pirms ienākšanas diskā vai pastāvīgajā atmiņā, visi ienākošie dati tiek glabāti. Katrai reģiona kolonnu saimei ir viena MemStore. Kā redzat attēlā, reģionam ir vairāki MemStores, jo katrā reģionā ir vairākas kolonnu ģimenes. Pirms nodošanas diskā dati tiek sakārtoti leksikogrāfiskā secībā.
• HFails: No iepriekš redzamā attēla var redzēt, ka HFile tiek glabāta HDFS. Tādējādi tas glabā faktiskās šūnas diskā. MemStore nodod datus HFile, kad MemStore lielums pārsniedz.

Tagad, kad mēs zinām galvenos un mazākos HBase arhitektūras komponentus, es paskaidrošu mehānismu un viņu sadarbības centienus šajā jomā. Neatkarīgi no tā, vai tas ir lasījums vai rakstīšana, vispirms ir jāmeklē, kur lasīt vai kur rakstīt failu. Tātad, sapratīsim šo meklēšanas procesu, jo tas ir viens no mehānismiem, kas padara HBase ļoti populāru.

HBase arhitektūra: Kā meklēšana tiek inicializēta HBase?

Kā jūs zināt, Zookeeper saglabā META galda atrašanās vietu. Ikreiz, kad klients tuvojas HBase lasīšanas vai rakstīšanas pieprasījumiem, notiek šāda darbība:

1. META tabulas atrašanās vietu klients izgūst no ZooKeeper.
2. Pēc tam klients pieprasa atbilstošās rindas atslēgas reģiona servera atrašanās vietu no tabulas META, lai tai piekļūtu. Klients saglabā šo informāciju kešatmiņā ar META tabulas atrašanās vietu.
3. Tad tā iegūs rindas atrašanās vietu, pieprasot no attiecīgā reģiona servera.

Nākotnes atsaucēm klients izmanto kešatmiņu, lai izgūtu META tabulas atrašanās vietu un iepriekš izlasītu rindas atslēgas reģiona serveri. Tad klients nenorādīs uz META tabulu, kamēr un ja nav garām, jo ​​reģions ir pārvietots vai pārvietots. Tad tas atkal pieprasīs META serverim un atjauninās kešatmiņu.

Kā katru reizi, klienti netērē laiku, atgūstot reģiona servera atrašanās vietu no META Server, tādējādi tas ietaupa laiku un padara meklēšanas procesu ātrāku. Tagad ļaujiet man pastāstīt, kā HBase notiek rakstīšana. Kādas ir tajā iesaistītās sastāvdaļas un kā tās ir iesaistītas?

HBase arhitektūra: HBase Write Mehānisms

Šis zemāk esošais attēls izskaidro HBase rakstīšanas mehānismu.

Rakstīšanas mehānisms secīgi iziet šādu procesu (skatiet iepriekšējo attēlu):

1. darbība: Ikreiz, kad klientam ir rakstīšanas pieprasījums, klients raksta datus WAL (Write Ahead Log).

• Labojumi pēc tam tiek pievienoti WAL faila beigās.
• Šis WAL fails tiek uzturēts katrā reģiona serverī, un reģions serveris to izmanto, lai atgūtu datus, kas nav piesaistīti diskam.

2. darbība: Kad dati ir ierakstīti WAL, tie tiek kopēti MemStore.

3. solis: Kad dati ir ievietoti MemStore, klients saņem apstiprinājumu.

4. solis: Kad MemStore sasniedz slieksni, tas izmet vai nodod datus HFile.

Tagad ļaujiet mums dziļi ienirt un saprast, kā MemStore veicina rakstīšanas procesu un kādas ir tā funkcijas?

HBase Write Mehānisms- MemStore

• MemStore vienmēr tajā saglabātos datus atjaunina leksikogrāfiskā secībā (secīgi vārdnīcas veidā) kā sakārtotas KeyValues. Katrai kolonnu saimei ir viena MemStore, un tādējādi atjauninājumi tiek glabāti sakārtoti katrai kolonnu saimei.
• Kad MemStore sasniedz slieksni, tas visus datus sakārtotā veidā izgāž jaunā HFile. Šis HFile tiek glabāts HDFS. HBase katrai kolonnu saimei satur vairākus HF failus.
• Laika gaitā HFile skaits pieaug, kad MemStore izgāž datus.
• MemStore arī saglabā pēdējo rakstīto kārtas numuru, tāpēc gan Master Server, gan MemStore zina, ka tas, kas līdz šim ir izdarīts, un no kā sākt. Sākoties reģionam, tiek nolasīts pēdējais kārtas numurs, un no šī numura sākas jauni labojumi.

Kā es vairākkārt apspriedu, ka HFile ir galvenā pastāvīgā krātuve HBase arhitektūrā. Visbeidzot, visi dati tiek piešķirti HFile, kas ir HBase pastāvīgā krātuve. Tādējādi apskatīsim HFile īpašības, kas padara to ātrāku meklēšanai, lasot un rakstot.

HBase arhitektūra: HBase Write Mehānisms- HFile

• Raksti tiek secīgi ievietoti diskā. Tāpēc diska lasīšanas un rakstīšanas galvas kustība ir ļoti mazāka. Tas padara rakstīšanas un meklēšanas mehānismu ļoti ātru.
• HFile indeksi tiek ielādēti atmiņā ikreiz, kad tiek atvērts HFile. Tas palīdz atrast ierakstu vienā meklējumā.
• Piekabe ir rādītājs, kas norāda uz HFile meta bloku. Tas ir rakstīts izdarītās lietas beigās. Tajā ir informācija par laika zīmoga un ziedēšanas filtriem.
• Blūma filtrs palīdz meklēt atslēgas vērtību pārus, tas izlaiž failu, kurā nav nepieciešamās rindas atslēgas. Laika zīmogs palīdz arī meklēt faila versiju, tas palīdz izlaist datus.

Pēc tam, kad esat pārzinājis rakstīšanas mehānismu un dažādu komponentu lomu, lai ātrāk rakstītu un meklētu. Es jums paskaidrošu, kā lasīšanas mehānisms darbojas HBase arhitektūras iekšienē? Tad mēs pāriet uz mehānismiem, kas palielina HBase veiktspēju, piemēram, blīvēšanu, reģiona sadalīšanu un atkopšanu.

HBase arhitektūra: Izlasiet mehānismu

Kā tika apspriests mūsu meklēšanas mehānismā, vispirms klients izgūst reģiona servera atrašanās vietu no .META Server, ja klientam tās nav kešatmiņā. Tad tas veic secīgas darbības šādi:

• Lai lasītu datus, skeneris vispirms meklē šūnu Row bloķēšanas kešatmiņā. Šeit tiek saglabāti visi nesen izlasītie atslēgu vērtību pāri.
• Ja skeneris neatrod nepieciešamo rezultātu, tas pāriet uz MemStore, jo mēs zinām, ka tā ir rakstīšanas kešatmiņa. Tur tā meklē jaunākos rakstītos failus, kas vēl nav ievietoti HFile failā.
• Beidzot, tā izmantos ziedēšanas filtrus un bloķēs kešatmiņu, lai ielādētu datus no HFile.

Līdz šim esmu apspriedis HBase meklēšanas, lasīšanas un rakstīšanas mehānismu. Tagad mēs aplūkosim HBase mehānismu, kas ļauj ātri meklēt, lasīt un rakstīt HBase. Pirmkārt, mēs sapratīsim Blīvēšana , kas ir viens no šiem mehānismiem.

HBase arhitektūra: Blīvēšana

HBase apvieno HFiles, lai samazinātu glabāšanu un samazinātu lasīšanai nepieciešamo disku meklējumu skaitu. Šo procesu sauc blīvēšana . Blīvēšana izvēlas dažus HF failus no reģiona un tos apvieno. Kā redzams iepriekš redzamajā attēlā, ir divu veidu blīvēšana.

1. Neliela blīvēšana : HBase automātiski izvēlas mazākus HF failus un iesaka tos lielākiem HF failiem, kā parādīts iepriekšējā attēlā. To sauc par nelielu blīvēšanu. Tas veic sapludināšanas kārtojumu, lai mazākiem HF failiem piešķirtu lielākus HF failus. Tas palīdz uzglabāšanas vietas optimizācijā.
2. Galvenais blīvējums: Kā parādīts iepriekš redzamajā attēlā, lielākajā blīvēšanā HBase apvieno un no jauna pievieno reģiona mazākos HF failus jaunam HFile. Šajā procesā vienas un tās pašas kolonnu grupas tiek ievietotas kopā jaunajā HFile. Šajā procesā tā nomet dzēsto un izbeigušos šūnu. Tas palielina lasīšanas veiktspēju.

Bet šī procesa laikā ievades un izvades diski un tīkla trafiks var būt pārslogoti. Tas ir pazīstams kā rakstīt pastiprinājumu . Tātad, tas parasti tiek plānots zemas maksimālās slodzes laikā.

Tagad vēl viens veiktspējas optimizācijas process, par kuru es runāšu, ir Splitas reģions . Tas ir ļoti svarīgi slodzes līdzsvarošanai.

savienības klauzula ir pieradusi

HBase arhitektūra: Splitas reģions

Zemāk redzamais attēls ilustrē reģiona sadalīšanas mehānismu.

Ikreiz, kad reģions kļūst liels, tas tiek sadalīts divos bērnu reģionos, kā parādīts iepriekšējā attēlā. Katrs reģions ir tieši puse no vecāku reģiona. Tad par šo sadalījumu tiek ziņots HMaster. To apstrādā tas pats reģiona serveris, līdz HMaster tos piešķir jaunam reģiona serverim slodzes līdzsvarošanai.

Visbeidzot, pārejot uz leju, es paskaidrošu, kā HBase atgūst datus pēc kļūmes. Kā mēs to zinām Kļūmju atkopšana ir ļoti svarīga HBase iezīme, tāpēc dariet mums zināmu, kā HBase atgūst datus pēc kļūmes.

HBase arhitektūra: HBase avārija un datu atkopšana

• Ikreiz, kad kāda reģiona serveris neizdodas, ZooKeeper paziņo HMaster par kļūmi.
• Tad HMaster sadala un sadala avarējušā reģiona servera reģionus daudziem aktīviem reģionu serveriem. Lai atgūtu neizdevušā reģiona servera MemStore datus, HMaster izplata WAL visiem reģiona serveriem.
• Katrs reģiona serveris atkārtoti izpilda WAL, lai izveidotu MemStore šī neizdevušā reģiona kolonnu saimei.
• Dati tiek rakstīti hronoloģiskā secībā (savlaicīgi) WAL. Tāpēc atkārtoti izpildīt šo WAL nozīmē veikt visas izmaiņas, kas tika veiktas un saglabātas MemStore failā.
• Tātad, pēc tam, kad visi reģiona serveri ir izpildījuši WAL, tiek atjaunoti visas kolonnu saimes MemStore dati.

Es ceru, ka šis emuārs būtu palīdzējis jums izprast HBase datu modeli un HBase arhitektūru. Ceru, ka jums patika. Tagad jūs varat saistīties ar HBase funkcijām (kuras es paskaidroju iepriekšējā HBase apmācība emuārs) ar HBase Architecture un saprast, kā tā darbojas iekšēji. Tagad, kad jūs zināt HBase teorētisko daļu, jums vajadzētu pāriet uz praktisko daļu. Paturot to prātā, mūsu nākamais emuārs paskaidros paraugu HBase POC .

Tagad, kad esat sapratis HBase arhitektūru, pārbaudiet Autors: Edureka, uzticams tiešsaistes mācību uzņēmums ar vairāk nekā 250 000 apmierinātu izglītojamo tīklu visā pasaulē. Edureka Big Data Hadoop sertifikācijas apmācības kurss palīdz izglītojamajiem kļūt par HDFS, dzijas, MapReduce, Pig, Hive, HBase, Oozie, Flume un Sqoop ekspertiem, izmantojot reāllaika lietošanas gadījumus mazumtirdzniecības, sociālo mediju, aviācijas, tūrisma, finanšu jomā.

Vai mums ir jautājums? Lūdzu, pieminējiet to komentāru sadaļā, un mēs ar jums sazināsimies.