Da, lahko imate velike podatke. Lahko pa ga ogrožate na pravi ali napačni način. Tu je 10 najhujših praks, ki se jim je treba izogniti.
1. Izberite MongoDB kot platformo za velike podatke. Zakaj izbiram na MongoDB? Nisem, toda iz kakršnega koli razloga je baza podatkov NoSQL, ki je trenutno najbolj zlorabljena, MongoDB. Medtem ko ima MongoDB zbirni okvir, ki ima okus po MapReduceu, in celo (zelo slabo dokumentiran) Hadoop priključek, je njegova najboljša točka operativna baza podatkov in ne analitični sistem.
[Andrew C. Oliver odgovarja na vprašanje vseh: Katero prekleto bazo podatkov naj uporabim? | Tudi o: Čas za standarde NoSQL je zdaj | Vsak dan v dnevniškem dnevniku preberite povzetek ključnih zgodb. ]
Ko se začne vaš stavek: "Mongo bomo uporabili za analizo ...", se ustavite tam in razmislite, kaj počnete. Včasih resnično mislite "zbiraj za poznejšo analizo", kar je lahko v redu, odvisno od tega, kaj počnete. Če pa res mislite, da boste MongoDB uporabljali kot nekakšno bolno tehnologijo shranjevanja podatkov, bo vaš projekt na začetku že obsojen na propad.
2. Uporaba sheme RDBMS kot datotek. Ja, vsako tabelo ste iz RDBMS-a shranili v datoteko. To nameravate shraniti na HDFS. Na njem nameravate uporabiti Hive.
Najprej veste, da je panj počasnejši od vašega RDBMS za kaj običajnega, kajne? MapReduce bo celo preprost izbor. Oglejte si "optimizirano" pot za združitve "tabele". Nato si poglejmo velikosti vrstic - če veste, imate ploščate datoteke, merjene v enomestnih kilobajtih. Hadoop se najbolje obnese pri velikih naborih razmeroma ravnih podatkov. Prepričan sem, da lahko ustvarite izvleček, ki je bolj denormaliziran.
3. Ustvarjanje podatkovnih ribnikov. Na poti do ustvarjanja podatkovnega jezera ste zavili drug nadvoz in ustvarili vrsto podatkovnih ribnikov. Conwayev zakon je znova udaril in vsaki poslovni skupini ste dovolili, da ne ustvarja samo lastne analize podatkov, temveč tudi lastna mini skladišča. To sprva ne zveni slabo, toda z različnimi izvlečki in načini rezanja in rezanja podatkov dobite različne poglede na podatke. Ne mislim ravno v primerjavi s kocko - mislim na različne odgovore na enaka vprašanja. Shema, ki jo beremo, ne pomeni "sploh ne načrtuj", ampak pomeni "ne načrtuj za vsako vprašanje, ki bi ga morda zastavili."
Kljub temu bi morali načrtovati širšo sliko. Če prodajate pripomočke, obstaja velika verjetnost, da bo nekdo želel videti, koliko, komu in kako pogosto ste pripomočke prodali. Pojdite naprej in si zagotovite to v običajnih oblikah in naredite malo vnaprej, da ne boste dobili podatkovnih ribnikov in luž v lasti posamezne poslovne skupine.
4. Ni uspelo razviti verjetnih primerov uporabe. Zamisel o podatkovnem jezeru prodajajo prodajalci, da bi nadomestili primere dejanske uporabe. (To je tudi način, da se izognete omejitvam financiranja oddelkov.) Pristop podatkovnega jezera je lahko veljaven, vendar bi morali imeti v mislih dejanske primere uporabe. Ni jih težko najti v večjih srednje velikih podjetjih. Začnite s pregledom, kdaj je nekdo nazadnje rekel: "Ne, ne moremo, ker baza podatkov tega ne more obvladati." Nato pojdite na "duh." Na primer, "poslovni razvoj" naj ne bi bil le naslovna promocija za vašega najboljšega prodajalca; to naj bi nekaj pomenilo.
Kaj pa recimo uporaba Mahouta za iskanje naročil strank, ki so običajna odstopanja? V večini podjetij je večina naročil strank podobnih. Kaj pa naročila, ki se zgodijo dovolj pogosto, a se ne ujemajo s splošnimi? Te so morda premajhne, da bi jih prodajalci skrbeli, lahko pa kažejo na prihodnje poslovno področje vašega podjetja (torej dejanski poslovni razvoj). Če za Hadoop ne morete zbrati vsaj nekaj dobrih resničnih načinov uporabe, ga morda kljub vsemu ne potrebujete.
5. Misli panj je vse, konec-vse. Saj poznate SQL. Všeč vam je SQL. Delali ste SQL. Razumem, človek, a mogoče tudi ti lahko rasteš? Mogoče bi morali poseči globoko v desetletje ali tri in se spomniti mladega otroka, ki se je naučil SQL in videl svetove, ki se mu je odprl. Zdaj pa si predstavljajte, da se hkrati nauči še nekaj.
