Taip, galite sugadinti didelius duomenis. Tačiau galite jį užteršti teisingu ar netinkamu būdu. Čia yra 10 geriausių praktikų, kurių reikėtų vengti.
1. Pasirinkite „MongoDB“ kaip didžiųjų duomenų platformą. Kodėl renkuosi „MongoDB“? Aš ne, bet dėl kokių nors priežasčių šiuo metu labiausiai piktnaudžiaujama „NoSQL“ duomenų baze yra „MongoDB“. Nors „MongoDB“ turi apibendrinimo sistemą, kurios skonis panašus į „MapReduce“ ir netgi (labai prastai dokumentais patvirtintą) „Hadoop“ jungtį, jos saldus taškas yra veikianti duomenų bazė, o ne analitinė sistema.
[Andrew C. Oliveris atsako į klausimą visų mintyse: kurią keistą duomenų bazę turėčiau naudoti? | Be to: „NoSQL“ standartų laikas dabar | „Daily“ naujienlaiškyje kiekvieną dieną gaukite svarbiausių istorijų santrauką. ]
Kai prasidės jūsų sakinys: „Mes naudosime„ Mongo “analizuoti ...“, sustokite tiesiai ten ir pagalvokite, ką darote. Kartais jūs tikrai turite omenyje „rinkti vėlesnei analizei“, o tai gali būti gerai, atsižvelgiant į tai, ką darai. Tačiau, jei jūs tikrai norite galvoti, kad „MongoDB“ naudosite kaip kažkokią ligotų duomenų sandėliavimo technologiją, jūsų projektas gali būti pasmerktas pradžioje.
2. Naudojant RDBMS schemą kaip failus. Taip, jūs išvedėte kiekvieną lentelę iš savo RDBMS į failą. Jūs planuojate tai laikyti HDFS. Jame planuojate naudoti avilį.
Pirmiausia, jūs žinote, kad avilys yra lėtesnis nei jūsų RDBMS, jei norite nieko normalaus, tiesa? Tai bus „MapReduce“ net paprastas pasirinkimas. Pažvelkite į „optimizuotą“ „lentelių“ prisijungimo maršrutą. Toliau pažvelkime į eilučių dydžius - žinokime, kad jūs turite plokščius failus, matuojamus vieno skaitmens kilobaitais. „Hadoop“ geriausiai sekasi dideliems santykinai plokščių duomenų rinkiniams. Esu tikras, kad galite sukurti ištrauką, kuri būtų labiau denormalizuota.
3. Duomenų tvenkinių kūrimas. Kurdami duomenų ežerą, jūs išjungėte kitą viaduką ir sukūrėte duomenų tvenkinių seriją. „Conway“ įstatymas vėl įsigaliojo ir jūs leidote kiekvienai verslo grupei ne tik kurti savo duomenų analizę, bet ir savo mažas saugyklas. Iš pradžių tai skamba neblogai, tačiau naudojant skirtingus duomenų ištraukimo ir supjaustymo būdus, gaunami skirtingi duomenų rodiniai. Aš neturiu omenyje plokščio ir kubo - turiu omenyje skirtingus atsakymus į tuos pačius klausimus. Skaityta schema nereiškia „visai neplanuokite“, bet reiškia „neplanuokite kiekvieno klausimo, kurį galite užduoti“.
Nepaisant to, turėtumėte planuoti bendrą vaizdą. Jei parduodate valdiklius, yra didelė tikimybė, kad kažkas norės sužinoti, kiek, kam ir kaip dažnai pardavėte valdiklius. Darykite tai įprastu formatu ir atlikite šiek tiek išankstinio dizaino, kad įsitikintumėte, jog neužteksite duomenų tvenkinių ir balų, priklausančių kiekvienai atskirai verslo grupei.
4. Nepavyksta sukurti tikėtinų naudojimo atvejų. Duomenų ežero idėją pardavėjai parduoda, kad pakeistų tikrojo naudojimo atvejus. (Tai taip pat būdas išvengti skyrių finansavimo apribojimų.) Duomenų ežero metodas gali būti pagrįstas, tačiau turėtumėte atsižvelgti į faktinius naudojimo atvejus. Nesunku juos rasti daugelyje vidutinių ir didelių įmonių. Pirmiausia peržiūrėkite, kada kas nors paskutinį kartą pasakė: "Ne, mes negalime, nes duomenų bazė negali jos tvarkyti". Tada pereikite prie „duh“. Pvz., „Verslo plėtra“ neturėtų būti tik pagrindinė jūsų aukščiausio lygio pardavėjo reklama; tai turėtų ką nors reikšti.
Ką daryti, tarkime, naudojant „Mahout“ ieškant klientų užsakymų, kurie yra įprasti rodikliai? Daugumoje įmonių dauguma klientų užsakymų yra panašūs vienas į kitą. Bet ką daryti su užsakymais, kurie vyksta pakankamai dažnai, bet neatitinka įprastų? Tai gali būti per maža pardavėjams, kad jiems tai nerūpėtų, tačiau jie gali parodyti būsimą jūsų įmonės verslo kryptį (tai yra faktinė verslo plėtra). Jei negalite surinkti bent kelių gerų „Hadoop“ panaudojimų realiame pasaulyje, gal jums to ir nereikia.
5. Galvojimas apie avilį yra viskas, pabaiga. Jūs žinote SQL. Jums patinka SQL. Jūs darėte SQL. Suprantu, žmogau, bet gal ir tu gali augti? Galbūt turėtumėte pasiekti dešimtmetį ar tris ir prisiminti jauną vaiką, kuris išmoko SQL ir pamatė jam atsiveriančius pasaulius. Dabar įsivaizduokite, kad jis tuo pačiu metu išmoksta dar vieno dalyko.
