Ja, du kan ha store data. Du kan imidlertid risikere det på riktig eller feil måte. Her er de 10 beste verste metodene å unngå.
1. Velge MongoDB som din store dataplattform. Hvorfor velger jeg på MongoDB? Jeg er ikke det, men av en eller annen grunn er NoSQL-databasen som er mest misbrukt på dette tidspunktet MongoDB. Mens MongoDB har et aggregasjonsrammeverk som smaker som MapReduce og til og med en (veldig dårlig dokumentert) Hadoop-kontakt, er søtpunktet som en operativ database, ikke et analytisk system.
[Andrew C. Oliver svarer på alles tanker: Hvilken freaking database skal jeg bruke? | Også på: Tiden for NoSQL-standarder er nå Få et sammendrag av nøkkelhistoriene hver dag i Daily newsletter. ]
Når setningen din begynner, "Vi vil bruke Mongo til å analysere ...", stopper der og tenker på hva du gjør. Noen ganger mener du virkelig "samle til senere analyse", noe som kan være OK, avhengig av hva du gjør. Imidlertid, hvis du virkelig mener at du skal bruke MongoDB som en slags syk datalagringsteknologi, kan prosjektet ditt være dømt i starten.
2. Bruke RDBMS-skjema som filer. Ja, du dumpet hver tabell fra RDBMS til en fil. Du planlegger å lagre det på HDFS. Du planlegger å bruke Hive på det.
For det første, du vet at Hive er tregere enn RDBMS for noe normalt, ikke sant? Det kommer til å redusere til og med et enkelt valg. Se på den "optimaliserte" ruten for "tabellen" blir med. Deretter, la oss se på radstørrelser - hva vet du, du har flate filer målt i ensifrede kilobyte. Hadoop klarer seg best på store sett med relativt flate data. Jeg er sikker på at du kan lage et ekstrakt som er mer denormalisert.
3. Opprette datadammer. På vei til å lage en datasjø tok du en sving av en annen overgang og opprettet en serie datadammer. Conways lov har slått til igjen, og du har latt hver forretningsgruppe ikke bare lage sin egen analyse av dataene, men også sine egne mini-depoter. Det høres ikke dårlig ut i begynnelsen, men med forskjellige utdrag og måter å kutte og skjære data på, ender du opp med forskjellige visninger av dataene. Jeg mener ikke flat mot kube - jeg mener forskjellige svar på noen av de samme spørsmålene. Skjema ved lesing betyr ikke "ikke planlegg i det hele tatt", men det betyr "ikke planlegg for alle spørsmål du måtte stille."
Likevel bør du planlegge for det store bildet. Hvis du selger widgets, er det en god sjanse for at noen vil se hvor mange, til hvem og hvor ofte du solgte widgets. Gå videre og få det i de vanlige formatene, og gjør litt design på forhånd for å sikre at du ikke ender med datadammer og sølepytter som eies av hver enkelt forretningsgruppe.
4. Unnlater å utvikle plausible brukssaker. Ideen om datasjøen selges av leverandører for å erstatte tilfeller med reell bruk. (Det er også en måte å unnslippe begrensningene for avdelingsfinansiering.) Data-lake-tilnærmingen kan være gyldig, men du bør ha faktiske brukssaker i tankene. Det er ikke vanskelig å komme dem opp i de fleste mellomstore til store bedrifter. Start med å se gjennom når noen sist sa: "Nei, vi kan ikke, fordi databasen ikke kan håndtere det." Gå deretter videre til "duh." For eksempel, "forretningsutvikling" er ikke ment å være bare en titulær kampanje for din beste selger; det skal bety noe.
Hva med, si, å bruke Mahout for å finne kundeordrer som er vanlige outliers? I de fleste selskaper ligner de fleste kundeordrer på hverandre. Men hva med ordrene som skjer ofte nok, men som ikke samsvarer med vanlige? Disse kan være for små til at selgere kan bry seg om, men de kan indikere en fremtidig bransje for bedriften din (det vil si faktisk forretningsutvikling). Hvis du ikke kan tromme opp minst et par gode virkelige bruksområder for Hadoop, trenger du kanskje ikke det tross alt.
5. Thinking Hive er det som er alt, slutt. Du kjenner SQL. Du liker SQL. Du har drevet med SQL. Jeg skjønner det, mann, men kanskje du også kan vokse? Kanskje du skulle stikke dypt ned et tiår eller tre og huske unggutten som lærte SQL og så verdenene den åpnet for ham. Tenk deg at han lærer en annen ting samtidig.
