Cloudera Bewegende Gemiddelde

Ek het gestruikel oor hierdie artikel: wat noem hoe om bewegende gemiddelde te bereken met behulp van Hadoop. Let daarop dat al die rekords vir 'n belangrike gesorteer moet word en dan verminder. Nou aanvaar dat die rekords vir 'n spesifieke sleutel is versprei oor die hele skerwe van Mongo cluster. In so 'n geval, sal dit moontlik wees om die bewegende gemiddelde Ek verstaan ​​dat Mongo nie die kaart te verminder by elke node bereken. Die eerste vereiste om hierdie probleem op te los, is om seker te maak al die straal vir 'n kaart verminder in 'n enkele verminder fase. As dit die geval is, dan Mongo Map Verminder sal nooit in staat wees om sulke probleme op te los. Is daar 'n paar basiese misverstand Ook, met miljarde rye, en petabytes van data, hoekom is dit dat Hadoop Verminder fase nie die geval ongeluk uit die geheue, aangesien dit te doen het met ten minste 'n paar eetlepels van gekarteer data. gevra 16 Mei 13 aan 07:31 Kan jy verduidelik waarom Hadoop doesn39t ongeluk uit geheue vir sodanige berekening Van my verstand, al die verminder sal gebeur op een knoop, waar al die rekords vir 'n sleutelrol sal verminder. Dit moet lei tot groot geheue oorhoofse op daardie knoop, aangesien eetlepels van data moet daar teenwoordig wees. Hoe Hadoop hanteer so 'n groot hoeveelheid data ndash P. Prasad 16 Mei 13 aan 08:29 Ek glo dat, in teenstelling met MongoDB, hadoop, net soos SQL wanneer die verwerking van 'n groot deel, sal uitskryf dinge te skyf en lees net wat nodig is met die bedryfstelsel gebruik van ruil as 'n tydelike geheue houer vir sekere dinge waarskynlik. MongoDB doen meer in ram om voor te skryf na die skyf as sodanig sal maklik borgtog uit ndash Sammaye 16 Mei 13 aan 8: 37Cloudera Jobs in Londen Die tabel hieronder kyk na die statistieke vir kennis en ervaring van Cloudera produkte en / of dienste in IT werk geadverteer vir die streek Londen. Ingesluit is 'n gids tot die salarisse wat aangebied word in IT werk wat Cloudera het aangehaal oor die 3 maande tot 13 Oktober 2016 met 'n vergelyking met dieselfde tydperk in die vorige 2 jaar. Die onderstaande figure verteenwoordig die IT arbeidsmark in die algemeen en is nie verteenwoordigend van salarisse binne Cloudera, Inc. 3 maande tot 13 Oktober 2016 in dieselfde tydperk 2015 Cloudera Jobs vraag Trend in Londen die vraag tendens van werk advertensies in die hele streek Londen met verwysing na Cloudera as 'n proporsie van alle IT bane met 'n wedstryd in die kategorie Ondernemers. Cloudera Salaris Trend in Londen Hierdie grafiek gee die 3-maande bewegende gemiddelde vir salarisse in permanente poste IT verwysing Cloudera in die hele streek Londen aangehaal. Cloudera Salaris Histogram in Londen Hierdie grafiek gee 'n salaris histogram vir IT werk met verwysing na Cloudera in die hele streek Londen oor die 3 maande tot 13 Oktober 2016. Cloudera Job Locations in Londen Die tabel hieronder kyk na die vraag en bied 'n gids tot die mediaan salarisse aangehaal in IT werk met verwysing na Cloudera binne die streek Londen oor die 3 maande tot 13 Oktober 2016. die kolom posisie Change gee 'n aanduiding van die verandering in vraag in elke plek wat gebaseer is op die dieselfde tydperk 3 maande verlede jaar. Plek (Klik sien gedetailleerde statistieke en tendense) Rang Verandering op dieselfde tydperk verlede jaar ooreenstem Permanente IT Job advertensies Mediaan Salaris Laaste 3 MonthsCloudera Engineering blog Eenvoudige bewegende gemiddelde, Sekondêre vere en MapReduce (Deel 3) Dit is die finale stuk om 'n drie deel blog reeks. As jy wil graag die vorige dele van hierdie reeks te besigtig gebruik asseblief die volgende skakel: Voorheen het ek verduidelik hoe om Excel en R te gebruik as die analise-instrumente om die Eenvoudige bewegende gemiddelde van 'n klein stel voorraad sluitingstyd pryse te bereken. In hierdie laaste stukkie van die drie deel blog reeks, sal ek delf in die gebruik van MapReduce om die Eenvoudige bewegende gemiddelde van ons klein monster datastel te vind. Dan sal ek jou wys hoe die gebruik van dieselfde kode, sal jy in staat wees om die Eenvoudige bewegende gemiddelde van elke eindvoorraad prys sedert 1980. Down die konijnenhol Met Hadoop In die bogenoemde voorbeelde te bereken ons het 'n blik op die berekening van die eenvoudige bewegende gemiddelde van 'n relatief klein bedrag van data. Vir baie van analise, Excel en R is baie doeltreffende instrumente, maar as ons volgens skaal teenoor GB, terabyte en petabyte data winkels loop ons in 'n paar probleme met data plek, skyf spoed, en die verwerking spoed. Om te illustreer hierdie faktore kan neem 'n mitiese masjien wat 'n enkele 1 petabyte skyf, wat insgelyks vandag bedryf op skyf spoed gehad. Vir die doeleindes van hierdie voorbeeld goed gebruik 'n lees spoed van 40 MB / s. Kom ons sê dat sy ons taak om te scan deur hierdie data en produseer 'n eenvoudige bewegende gemiddelde, het die verwerker nie belemmer die berekening, en ons kan 'n bewegende berekening venster deur die data in stand te hou by die volle 40 MB / s. Kom ons ook aanvaar dat die data wat voorheen gesorteer en ons het net 'n sekwensiële scan hierdie gemaksimaliseer die data deurvloeikoers van die skyf te voer en dit kan konsekwent lewer 40MB / s om die verwerking pyplyn. Op grond van Jeff Dekane 12 Nommers Elke ingenieur moet weet skuif is dit 'n geloofwaardige opstel. Op hierdie deurset ons eenvoudig bewegende gemiddelde berekening van 1 petabyte data rondom 310 dae sou neem om te voltooi. Vir die meeste gevalle hierdie operasionele koste, in terme van tyd, maak dit onredelik om te oorweeg. Gelukkig het die meganika van HDFS en MapReduce versag hierdie faktore soos dat ons hierdie probleem 'n lineêre tyd en kapitaal funksie om ons te help besluit oor die aantal masjiene wat ons wil uit te voer om hierdie eenvoudige bewegende gemiddelde scan doeltreffend onderneem kan maak. In die bogenoemde eenvoudige bewegende gemiddelde voorbeeld nagelaat het ons aan die beperkings van mening: Bewaring van die petabyte data op nie-mitiese hardeware. Sorteer die petabyte data. Met inagneming van hardeware mislukking tydens die 310 dae van die verwerking tyd. Tipies, moet tydreekse aansoeke om die data te scan op 'n sekere punt, wat groot berge skep om te klim, as ons wil groot Tomes van tydreeksdata te benader in vandag se stelsels. Was aangesien multi-terabyte en multi-petabyte data bronne in die tydreeks domein elke dag, insluitend en in elk van hierdie domeine die bogenoemde scenario is 'n baie groot uitdaging aan te pak. HDFS los die stoor en mislukking kwessies hierbo, maar wat oor die sortering en verwerking kwessies Sortering groot hoeveelhede data op sigself is 'n nie-triviale probleem, maar is toeganklik met 'n paar truuks in MapReduce. Kom ons neem 'n blik op die werklike MapReduce kode wat ons kan aflaai om saam te stel en vervaardig ons eie haalbare eenvoudige bewegende gemiddelde, 'n paar van hierdie pyn punte op te los. Eenvoudige bewegende gemiddelde in MapReduce Tipies n MapReduce aansoek is saamgestel uit twee funksies: (jy raai dit al) 'n kaart funksie en 'n vermindering van funksie. In die wêreld van die Java-programmeertaal te skep ons 'n kaart klas en 'n vermindering van die klas, elk met erwe metodes nuttig vir hul respek doeleindes. Ons gebruik die MapReduce ontwikkeling model, want dit is gebou om concurrency probleme in ons algoritmes te versag en ons kry ons skaalbare parallelisme relatief pynloos. Die kaart funksie kan kode wat 'n per-sleutel-waarde paar werking tree betrek, maar sy belangrikste logiese operasie is om groep data deur sleutels. 'N baie maklike manier om te dink oor 'n kaart funksie is om te dink aan dit as 'n logiese projeksie van die data of 'n groep deur klousule. Die funksie verminder word gebruik om hierdie groepe (individueel) te neem en uit te voer 'n proses oor die waardes wat saam gegroepeer. Gemeenskaplike bedrywighede in te verminder funksies sluit in: In ons eenvoudig bewegende gemiddelde voorbeeld egter dit nie ons werk op 'n per waarde basis spesifiek nie doen wat ons produseer 'n gemiddelde oor al die waardes. Ons werking in totaal sin behels 'n gly venster, wat sy bedrywighede verrig op 'n subset van die data by elke stap. Ons moet ook van mening dat die punte in ons tydreeksdata nie gewaarborg om te kom op die verminder ten einde en moet sorted8211mentioned is in die vorige afdelings. Dit is omdat met verskeie kaart funksies lees verskeie afdelings van die bron data MapReduce nie 'n bevel te lê op die sleutel-waarde pare wat saam in die standaard partisie is gegroepeer en sorteer skemas. Daar is die scenario waar ons Gepartitioneerd data het gesorteer, maar ter wille van hierdie voorbeeld gaan om te gaan met die meer tuin-verskeidenheid ongesorteerde tydreeksdata. Kom ons neem 'n eerste pas by die manier waarop ons hierdie MapReduce eenvoudige bewegende gemiddelde werk kan ontwerp. Ons wil groep is almal uit Een aandele aangepas naby waardes saam sodat ons die eenvoudige bewegende gemiddelde operasie kan aansoek doen oor die gesorteerde tydreeksdata. Ons wil elke keer reeks sleutel waarde paar ingesleutel op 'n beurs simbool om groep hierdie waardes saam te stoot. In die vermindering van fase kan ons 'n operasie, hier die eenvoudige bewegende gemiddelde, oor die data uit te voer. Sedert die data meer as waarskynlik nie sal kom by die reducer in gesorteerde volgorde goed nodig het om die data te sorteer voordat ons die eenvoudige bewegende gemiddelde kan bereken. 'N Algemene manier om data te sorteer is om die data in die geheue in 'n datastruktuur laai soos een wal, baie soos hoe dit gedoen word in 'n normale Java program. In hierdie geval is goed gebruik Javas prioriteit tou klas om ons data te sorteer. Ons moet ook die hoeveelheid geheue wat gebruik word deur die inkomende tydreeksdata te oorweeg tydens sortering aangesien dit 'n beperkende faktor van hoeveel data wat ons kan sorteer. In hierdie ontwerp moet ons al die tydreeksdata te laai voordat ons verwerking kan begin en as die hoeveelheid data te sorteer die beskikbare hoop grootte oorskry het ons 'n probleem. 'N Voorbeeld hiervan implementering word gehuisves by GitHub: Om hierdie kode op jou eie Hadoop cluster hardloop, aflaai CDH van Cloudera en die opstel van 'n pseudo versprei cluster 8211which is 'n enkele nodus van Hadoop. - Pseudo versprei modus is 'n goeie manier om te probeer kode met Hadoop. Volgende aflaai en stel die bewegende gemiddelde kode in 'n pot. Om die kode direk vanaf GitHub (in die dop in MacOSX, ssh terminale venster in Linux, of MINGW32 vir win32) aflaai we8217ll gebruik die opdrag: Ons eerste pas is 'n ordentlike oplossing, maar is beperk deur ons Java Virtual Machine (JVM) kind hoop grootte en ons neem tyd om die data onsself met die hand te sorteer. Met 'n paar ontwerp veranderinge, kan ons albei van hierdie kwessies met behulp van 'n paar inherente eienskappe van MapReduce los. Eerstens wil ons om te kyk na die geval van sortering die data in die geheue op elke reducer. Tans het ons seker maak dat ons nooit meer inligting stuur na 'n enkele reducer as kan inpas in die geheue. Die manier waarop ons dit tans beheer is aan elke reducer kind JVM meer hoop en / of om ons tydreeksdata verder verdeel in die kaart fase gee. In hierdie geval wed partisie verder deur tyd, breek ons ​​data in kleiner vensters van tyd. In teenstelling met skeiding van die data te bevorder, 'n ander benadering tot hierdie probleem is om voorsiening te maak Hadoop om die data vir ons in whats die shuffle fase van MapReduce genoem sorteer. As die data arriveer by 'n reducer reeds in gesorteerde volgorde kan ons ons geheue voetspoor te verminder en die vermindering van die aantal loops deur die data deur net te kyk na die volgende N monsters vir elke eenvoudige bewegende gemiddelde berekening. Dit bring ons by die belangrike aspek van hierdie artikel, wat die skud sekondêre soort werktuigkundige genoem. Sorteer is iets wat ons kan laat Hadoop doen vir ons en Hadoop het bewys redelik goed op sorteer groot hoeveelhede data, die wen van die Gray kompetisie Sorteer in 2008. In die gebruik van die sekondêre soort werktuigkundige kan ons beide ons hoop op te los te wees en kwessies redelik eenvoudig sorteer en doeltreffend. Oor na sekondêre soort diens in ons kode, moet ons die sleutel 'n samestelling van die natuurlike sleutel en die natuurlike waarde maak. Onder in figuur-1 sien ons 'n diagram van hoe dit visueel sal kyk. Figuur-1: Saamgestelde Sleutel Diagram Die Saamgestelde Sleutel gee Hadoop die nodige inligting in die shuffle om 'n soort nie net op die 8220stock symbol8221, maar op die tyd stempel te voer sowel. Die klas wat die Saamgestelde sleutels sorteer staan ​​bekend as die sleutel vergelyker of hier 8220CompositeKeyComparator8221. Die sleutel vergelyker moet deur die saamgestelde sleutel, wat is die kombinasie van die natuurlike sleutel en die natuurlike waarde bestel. Ons kan sien hieronder in Figuur-2 waar 'n abstrakte weergawe van sekondêre soort word uitgevoer op 'n saamgestelde sleutel van 2 heelgetalle. Figuur-2: CompositeKeyComparator sorteer Saamgestelde sleutels (sleutels heelgetalle). In Figuur 3 hieronder sien ons 'n meer realistiese voorbeeld waar we8217ve die Saamgestelde Sleutel verander na 'n beurs simbool string (K1) en 'n tyd stempel het (K2, vertoon as 'n datum nie, maar in die kode is 'n lang in MS). voorraad symbol8221 (natuurlike sleutel) en 8220K2:: tyd stamp8221 (sekondêre sleutel) Die diagram het die K / V pare deur beide 8220K1 gesorteer. Figuur 3: CompositeKeyComparator by die werk op ons saamgestelde sleutels. Saamgestelde sleutel nou verteenwoordig met 'n string beurs simbool (K1) en 'n datum (K2). Sodra we8217ve ons data gesorteer op die saamgestelde sleutel, moet ons nou om die data te verdeel vir die vermindering van fase. In Figuur-4 hieronder sien ons hoe die data van figuur-3 hierbo is verdeel met die NaturalKeyPartitioner. Figuur-4: Verdeling van die natuurlike sleutel met die NaturalKeyPartitioner. Sodra we8217ve ons data verdeel die reducers kan nou begin die aflaai van die verdeling lêers en begin om hul saam te smelt fase. INF figuur-5 hieronder sien ons hoe die groepering vergelyker, of NaturalKeyGroupingComparator, word gebruik om seker 'n verminder () oproep maak sien net die logiese gegroepeerde data bedoel vir daardie saamgestelde sleutel. Figuur-5: Groepering Comparator samesmelting partisie lêers. Die partisioneerder en groepering vergelyker vir die saamgestelde sleutel in ag moet neem slegs die natuurlike sleutel vir verdeling en groepering. Hier is 'n kort beskrywing van die Eenvoudige bewegende gemiddelde kode wat verander na die sekondêre soort gebruik en word gehuisves op GitHub. As jy sal kennis, die name van die klasse ten nouste ooreenstem met die terminologie wat gebruik word in die diagramme hierbo en in Tom Blankes Hadoop: The Definitive Guide (hoofstuk 8 MapReduce funksies) ten einde die kode makliker om te verstaan. NaturalKey 8211 wat jy normaalweg sou gebruik as die sleutel of 'n groep deur operateur. In hierdie geval is die natuurlike Sleutel is die groep of beurs simbool as wat ons nodig het om groep potensieel ongesorteerde voorraad data voor ons dit kan sorteer en bereken die eenvoudige bewegende gemiddelde. Saamgestelde Sleutel 8211 'n sleutel wat is 'n kombinasie van die natuurlike sleutel en die natuurlike waarde wat ons wil uit te sorteer deur. 5 antwoorde op ldquo Eenvoudige bewegende gemiddelde, Sekondêre vere en MapReduce (Deel 3) rdquo Cool truuk met die skeuring sorteer / partisioneerder. Sover ek kan sê dit werk baie goed totdat die reeks baie lang geword (dink 30 jaar van bosluis-vlak data) 8211 lyk soos skeiding deur tyd kan baie lastig wees. Weet jy van enigiets gebou in hadoop soos 'n 8220overlapping partitioner8221 wat dieselfde data verskeie partisies Ek het geëksperimenteer met mappers dat waardes dupliseer oor verskeie sleutels kan spoeg, maar ek wonder of there8217s n meer konvensionele manier om dit te doen. Evan, Jy is dood op die grootte van die data in 'n enkele keyspace. Ek dieselfde probleem getref by die werk op die openPDC projek vir die NERC: Een sensor kan letterlik miljarde punte in 'n baie kort tyd, so vir prototipe werk ons ​​slaggereed dinge om 'n enkele dag (3,600,000ms): In 'n meer komplekse weergawe ek sou gebruik het oorvleuelende tydgleuwe so die kartograaf voldoende data van aangrensende keyspaces sou kry om 'n enkele venster lengte dek. Vir nou I8217d sê jy is op die regte pad met die dubbele waardes. Ek weet dit is nie verwant aan bewegende gemiddeldes, maar hoe akkuraat was die SAX tydreekse wat ooreenstem gebruik in PDC Ek so iets (behalwe die gebruik van die MapReduce API 2) geïmplementeer word, en in die loop van die funksie te verminder (), wanneer die. volgende metode () is 'n beroep op die Iterator, kry ons 'n nuwe waarde, maar die sleutel ook wonderbaarlik verander. Inteendeel, die deel van die saamgestelde sleutel wat nie gebruik word as 'n natuurlike sleutel (die tyd stempel in hierdie voorbeeld) veranderinge. Dit was nogal verbasend. Hoe gebeur dit Post navigasie aanvaarding Apache Hadoop in die Federale GovernmentCloudera Engineering Blog Eenvoudige bewegende gemiddelde, Sekondêre vere en MapReduce (Deel 1) Intro In hierdie drie deel blog reeks Ek wil 'n blik op hoe ons 'n Eenvoudige bewegende gemiddelde sou doen neem met MapReduce en Apache Hadoop. Hierdie reeks is bedoel om te wys hoe om 'n gemeenskaplike Excel of R funksie vertaal in MapReduce Java kode met gepaardgaande werkende kode en data om mee te speel. Die meeste ontleders kan 'n paar maande van voorraad data te neem en te produseer 'n Excel spreiblad dat 'n bewegende gemiddelde wys, maar om dit te doen in Hadoop dalk 'n meer uitdagende taak. Hoewel tydreekse as 'n onderwerp word redelik goed verstaan, ek wou die benadering van die gebruik van 'n eenvoudige onderwerp om te wys hoe dit vertaal in 'n kragtige parallel aansoek dat die eenvoudige bewegende gemiddelde kan bereken vir 'n klomp aandele gelyktydig met MapReduce en Hadoop neem. Ek wil ook die onderliggende werktuigkundige van die gebruik van die 147secondary sort148 tegniek met Hadoop146s MapReduce shuffle fase, wat we146ll sien demonstreer is van toepassing op 'n baie verskillende aansoek gebiede soos finansies, sensor, en genomiese data. Hierdie artikel moet toeganklik aan die beginner Hadoop programmeerder wat 'n bietjie van MapReduce in Java gedoen en is op soek na 'n bietjie meer uitdagend MapReduce aansoek te hack op wees. In die geval you8217re nie baie vertroud is met Hadoop, here8217s agtergrondinligting en CDH. Die kode in hierdie voorbeeld word gehuisves op GitHub en gedokumenteer om te illustreer hoe die verskillende komponente saamwerk om die sekondêre soort effek te bereik. Een van die doelwitte van hierdie artikel is om hierdie kode word relatief basiese en toeganklik deur die meeste programmeerders. So let146s neem 'n vinnige blik op wat tydreeksdata is en waar dit in diens van die vinnig opkomende wêreld van grootskaalse data. Wat is tydreeksdata tydreeksdata word gedefinieer as 'n reeks van data punte tipies gemeet teen opeenvolgende kere gespasieer op eenvormige tyd intervalle. Tydreeksdata is tipies gesien in statistiek, seinprosessering, en finansies saam met ander velde. Voorbeelde van tydreeksdata is die daaglikse aangepaste naby prys van 'n voorraad op die NYSE of sensor lesings op 'n kragnetwerk voorkom 30 keer per sekonde. Tydreeks as 'n algemene klas van probleme het gewoonlik woonagtig in die wetenskaplike en finansiële gebiede. As gevolg van die voortdurende ontploffing van beskikbare data, tydreeksdata steeds meer algemeen oor 'n wyer strook van nywerhede. Tyd Reeks sensors word ubiquitously geïntegreer in plekke soos: It146s ook getoon dat vorms in beelde kan ontbind word in tydreeksdata wat toelaat dat die vorms te draai en skaal invariansie toelaat vir makliker vergelyking te bereik. Nog 'n sektor wat plofbare groei in die bedrag van tydreeksdata geproduseer is die genomiese en Bioinformatiese gebied. We146re sien die koste om die menslike genoom-volgorde voortgaan om vinnig te verminder. verskuiwing druk om die berging en verwerking van tegnologie vir die genome. Genoom data in die teks verteenwoordiging (GATC) kan voorgestel word as tydreekse en dus hierdie probleme is toeganklik deur alle tegnieke om tydreekse verwerking betrokke. Tydreeks verwerking onderliggend paar tegnieke wat gebruik word in die genoom domein soos 147motif vind 148 wat op dieselfde manier as die 147median string 148 probleem benader kan word. Die begrip van hoe ons tradisionele benaderings tot hierdie tyd reeks probleme kan refactor wanneer die skryf in MapReduce kan potensieel in staat stel om die verwerking en ontleding tegnieke te verbeter in 'n tydige wyse. Die finansiële sektor het 'n lang belangstel in tydreeksdata en het programmeertale soos R in diens geneem om deel te help met hierdie probleem. Die R programmeringstaal is spesifiek geskep vir hierdie klas van data8211as getoon in die R voorbeeld hieronder. So, hoekom sou 'n sektor te skep 'n programmeertaal wat spesifiek vir een klas van data wanneer tegnologie soos RDBMS bestaan ​​vir dekades in werklikheid, huidige RDBMS tegnologie beperkings wanneer die hantering van tydreeksdata hoë-resolusie. Hierdie beperkende faktore sluit in: Hoë-frekwensie tydreeksdata kom uit 'n verskeidenheid bronne kan groot hoeveelhede data in 'n baie kort tydjie RDBMS8217s skep geneig om nie soos die stoor en kruip miljarde rye. Nie versprei RDBMS8217s is geneig om nie soos opskaling in die honderde GB146s, wat nog te sê TB146s of PB146s. RDBMS8217s wat kan skaal in die arenas is geneig om baie duur te wees, of vereis dat groot hoeveelhede gespesialiseerde hardeware Probleme met RDBMS8217s navrae op 'n hoë resolusie tydreeksdata: Om tydreeksdata hoë resolusie met 'n RDBMS verwerk we8217d moet 'n analitiese totaal funksie gebruik in tandem met bewegende venster predicaten (ex: die 8220OVER8221 klousule) wat lei tot vinnig toenemende hoeveelhede werk om te doen as die korrelig van tydreeksdata kry fyner. Navraag resultate is nie perfek kommuteerbaar en kan dit nie doen veranderlike stap gly vensters (ex: stap 5 sekondes per venster skuif) sonder beduidende onnodige intermediêre werk of nie-standaard SQL funksies. Navrae oor RDBMS vir tydreekse vir sekere tegnieke kan ongemaklik wees en is geneig om te vroeg die onderverdeling van die data en duur rekonstruksie benodig tydens die verwerking van (byvoorbeeld: Data-ontginning, iSAX ontbindings) As gevolg van die bogenoemde faktore, met groot hoeveelhede van tydreeksdata RDBMS prestasie afbreek terwyl skaal. Die meeste eenvoudige tydreekse berekeninge uitgevoer met everyone146s gunsteling analise-instrument: die sigblad. Maar wanneer ons dit nodig om te kyk na data wat buite die 65K ry limiet van Excel hoe ons benadering nie ontwikkel soos ons ook ons ​​data vergroot In hierdie artikel we146ll stop om 'n blik op die betrokke wanneer skalering data kwessies neem voordat ons spring in MapReduce en hoe Hadoop benaderings dinge. Let146s begin met 'n eenvoudige bewegende gemiddelde op 'n klein voorbeeld van data in Excel. We146ll vorder op dieselfde voorbeeld in R en dan we146ll werk ons ​​pad in die rigting van 'n volwaardige MapReduce aansoek in Java (kode ingesluit). Sodra ons het ons voorbeeld van die data en werk met MapReduce, we146ll bereken die eenvoudige bewegende gemiddelde van alle aandele op die NYSE vanaf 1970 tot die hede in 'n keer, sonder om enige kode. Eenvoudige bewegende gemiddelde N Eenvoudige bewegende gemiddelde is die reeks van ongeweegde gemiddeldes in 'n subset van tydreeksdata punte as 'n gly venster vorder oor die tydreeksdata stel. Elke keer as die venster geskuif herbereken ons die gemiddeld van die punte in die venster. Dit produseer 'n stel getalle wat die finale bewegende gemiddelde. Tipies die bewegende gemiddelde tegniek word gebruik met tydreeks te tendense langer termyn na vore te bring of glad kort termyn geraas. Bewegende gemiddeldes is soortgelyk aan 'n lae slaagsyfer filters in seinverwerking en wiskundig word beskou as 'n soort van konvolusie. In ander terme, neem ons 'n venster en vul dit in 'n eerste in eerste uit (EIEU) wyse met tydreeksdata punte totdat ons het N punte daarin. Ons neem dan die gemiddelde van hierdie punte en voeg dit by ons antwoord lys. Ons skuif ons venster na vore gebring deur M datapunte en weer neem die gemiddelde van die datapunte in die venster. Hierdie proses word herhaal totdat die venster kan nie meer gevul word op watter punt die berekening voltooi. Nou dat ons 'n algemene idee van wat ons is op soek na, let146s 'n blik op 'n paar maniere om 'n eenvoudige bewegende gemiddelde doen. Kom in dele 2 en 3 van hierdie blog reeks we8217ll die leser van eenvoudige bewegende gemiddelde te neem in Excel, deur R, en dan in 'n werklike voorbeeld met kode van eenvoudige bewegende gemiddelde in MapReduce. 3 antwoorde op ldquo Eenvoudige bewegende gemiddelde, Sekondêre vere en MapReduce (Deel 1) rdquo 'n bietjie hier is 8211 R nie spesifiek geskep om tydreeksdata te hanteer in die finansiële dienste bedryf nitpick. Dit is die open source implementering van die 8220S8221 programmeertaal wat geskep is as 'n algemene doel statistiese programmeertaal. Persoonlik vind ek R8217s hantering van tydreeksdata redelik swak in vergelyking met ander analitiese stelsels I8217ve gebruik. (Don8217t my verkeerd verstaan, I8217m 'n groot-time R fan en gebruikers.) Tweede 8211 na jare van die werk met en die bestudering van hierdie dinge, my geloof is wat fundamenteel RDBMS8217s is kreupel wanneer dit kom by te kyk na tydreeksdata omdat hulle staatmaak op versamelingsleer. Stelle is natuurlik ongeordende, terwyl tyd dimensies het 'n baie duidelike natuurlike orde. Die geordende aard van stelle maak die wiskunde uitwerk mooi ten gunste van RDBMS vir transaksionele verwerking, maar minder so vir analitiese verwerking. Al wat gesê het: I8217m regtig uit daarna om te sien hoe time-reeks analise in Hadoop Evan As jy sê dat jy ander analytics sterker as R vir tydreekse, kan jy deel watter. Dit sal goed wees om notas te vergelyk. Jay Gee jy om die toevoeging van die skakels na deel 2 en 3 Ek het 'n voorbeeld waar die kartograaf versamel al die data en tydens die vermindering fase die waardes is bereken. As jy 'n eenvoudige bewegende gemiddelde (SMA) is dit 'n goeie oplossing. Dit begin om te ly as jy 'n back testing implementeer op 'n GARCH (1, 1) meer as 3000 datapunte. Post navigasie Vermy Vol GCS in Apache HBase met MemStore-Plaaslike Toekenning Buffers: Deel 3 Eenvoudige bewegende gemiddelde, Sekondêre vere en MapReduce (Deel 2) Ons blyk te wees 'n probleem waar die hele dag NAMENODERPCLATENCY waarskuwings sal dan duidelike reg na aanleiding gee. Dit is een van vanoggend: NAMENODERPCLATENCY het slegte geword: Die bewegende gemiddelde van die RPC latency is 11,7 sekonde (s) teenoor die vorige 5 minute (s). Die bewegende gemiddelde van die tou tyd is 5,3 sekonde (s). Die bewegende gemiddelde van die verwerking van die tyd is 6,4 sekonde (s). Kritieke drumpel: 5 sekonde (s). Ek het nie in staat was om iets in my boeke of op die internet oor hoe om dit te (behalwe miskien die toevoeging van meer namenodes behulp HDFS federasie) te versag te vind. As ek kyk na die bediener loop die namenode ek nie sien enige swaar utililzation van SVE of sien ek die geheue wat gespanne. Die enigste aanduiding van enigiets in hierdie tyd raam is 'n netwerk piek. Is daar enigiets wat ek kan doen om hierdie probleem te verminder. Ons het nie 'Jumbo rame in staat gestel as wat 'n verskil maak. Kyk na die diens inteken jy genoem het, niks met betrekking tot die namenode sien (ook gesoek hele log vir NAMENODERPCLATENCY en niks gevind). Hier is die JVM argumente geslaag om die begin. (XMS xmx uitbr) HADOOPNAMENODEOPTS-Xms2779774976 - Xmx2779774976 xx lees: UseParNewGC xx lees: UseConcMarkSweepGC xx lees: - CMSConcurrentMTEnabled xx lees: CMSInitiatingOccupancyFraction70 xx lees: CMSParallelRemarkEnabled - Dcom. sun. management. jmxremote - Dcom. sun. management. jmxremote. port3000 - Dcom. sun. management. jmxremote. sslfalse - Dcom. sun. management. jmxremote. authenticatefalse xx lees: OnOutOfMemoryError / killpa rent. sh HADOOPLOGFILEhadoop-CMF-hdfs-NAMENODE-usapname01.ihtech. log. out HADOOPAUDITLOGGERINFO, RFAAUDIT HADOOPROOTLOGGERINFO, RFA CDHVERSION5 HADOOPLOGDIR / var / log / hadoop-hdfs HADOOPSECURITYLOGGERINFO, drie skole Hier is die statistieke van die dfshealth bladsy van die namenode. Opsomming Sekuriteit is af. Safemode af. 816955 lêers en gidse, 953582 blokke 1770537 totale lêerstelsel voorwerp (e). Dra baie Memory gebruik 1.2 GB 2.5 GB Heap Memory. Max Heap Memory is 2,5 GB. Nie Heap Memory gebruik 70,28 MB 97,38 MB verbind Nie Heap Memory. Max Nie Heap Memory is 130 MB. Ingestel Kapasiteit: DFS Gebruik: Nie DFS Gebruik: DFS Oorblywende: DFS Gebruik: DFS Oorblywende: Blok Pool Gebruik: Blok Pool Gebruik: DataNodes gebruike (Min / Mediaan / Max / stdDev): Live NodesDead NodesDecommissioning NodesNumber van Onder-herhaal BlocksNumber van Blocks hangende Skrapping 503,99 TB 199,13 TB 25,21 TB 279,64 TB 39,51 55,49 199,13 TB 39,51 33,93 / 40,66 / 43,58 / 2,85 12 (vaart gestel: 0) 0 (vaart gestel: 0) 0 0 0 NameNode Journal Status Huidige transaksie ID: 140817035 Journal Bestuurder Staat QJM om 10.32.88.30:8485, 10.32.88.23:8485, 10.32.88.24:8485 Skryf segment begin by txid 140817035. 10.32.88.30:8485 (Geskryf txid 140817035), 10.32.88.23:8485 (Geskryf txid 140817035), 10.32.88.24: 8485 (Geskryf txid 140817035) Dankie vir jou antwoord. Ek het eintlik opgelos hierdie probleem wat veroorsaak word deur 'n kombinasie van twee faktore. 1 - Way baie klein lêers geskep word deur vark denormalization werk. Werk die verwerking van hierdie resultaat data is maak baie RPC oproepe gelyktydig, basies die uitvoering van 'n ontkenning van die diens aanval op die namenode (rondom 1800 RPC noem 'n tweede op mislukking punt). 2 - Kort nadat die oplossing van die klein lêers probleem, nog 'n probleem ontstaan. Skynbaar ewekansige hoë tou verwerking las, ten tyde verskyn baie vreemd, want die klein lêers probleem is opgelos en die bedrag van die RPC oproepe was goed binne stabiele gebonde. Die eerste uitgawe blyk baie maklik om op te los te wees. Die werk vark is aangepas om oprol al hierdie klein lêers in veel groter lêers (nie groot op die skaal van hadoop) sodat in plaas van honderde duisende lêers ons in staat was om hulle af te kry om 'n net 'n paar honderd. Die tweede probleem is veel meer interessant. Dit was moeilik om op te los en eintlik opgelos deur 'n ongeluk. Daar is eintlik byna geen dokumentasie oor wat 'n hoë tou verwerking vrag wat gelei het tot my uiteindelik af vir HDFS trek die bronkode sou veroorsaak. Dit blyk uiteindelik uit te veroorsaak word deur die JobHistory bediener probeer om die logs van / tmp / logs trek. Die JobHistory bediener hardloop in regte mislukkings wanneer ek probeer om gesê logs, wat sal lei tot die hoë verwerking tou tyd en uiteindelik 'n agterstand in die RPC tou trek. Protip van my pyn: High tou verwerking gebeur wanneer 'n werk / iemand probeer om te werk teen lêers in HDFS dat hulle nie toestemming vir doen het. Die groot probleem met hierdie is dat selfs jou minste bevoorregte gebruikers cluster onstabiliteit kan veroorsaak word deur net probeer om te werk teen lêers hulle het nie toestemming om te hê. Ek het 'n probleem met die JobHistory logs word opgespoor in die leser. In my saak draai dit uit te wees veroorsaak deur 'n opruim werk ek in die HDFS / tmp Gids gedoen het. Ek het per ongeluk verwyder / tmp / logs sonder om te besef dit is die stoor plek van die garen JobHistory server logs. Die gids is outomaties herskep deur die draad proses, maar met die verkeerde toestemmings wat benodig word vir die JobHistory bediener te werk. Dit blyk die probleem is veroorsaak deur die vorige pogings om skoon te maak die / tmp filespace in HDFS. Die gids / tmp / logs word deur die JobHistory bediener logs te stoor vir herwinning. Wanneer die gids as wat tussen die ouderdomme uit dit outomaties herskep verwyder, maar met die verkeerde toestemmings (Dit is herskep met gare: Supergroep in plaas van mapred: hadoop). Die manier waarop die gids werk is dat dit maak gebruik van die taai bietjie na erfenis van die groep regte af te dwing op alle nuwe lêers geskep. Onder die korrekte toestande sal hierdie krag alle nuwe lêers en gidse te besit word deur hadoop. In hierdie geval is dit gelei het tot al die nuwe dopgehou en lêers wat besit word deur super, wat die JobHistory bediener verhinder is om in staat wees om die stompe te lees. Jy kan sien waar ek in hierdie draad oor hoe om dit op te los .. drwxrwxrwt kommentaar - gare super 0 2015/05/10 09:28 / tmp / logs rootnamenode hadoop-hdfs sudo - U hdfs hdfs DFS - ls / tmp / logs / drwxrwx --- - USER1 super 0 2015/05/10 09:28 / tmp / logs / user1 drwxrwx --- - USER2 super 0 2015/05/06 00:46 / tmp / logs / USER2 drwxrwx --- - user3