Ano, můžete ohrozit velká data. Můžete to však ohrozit správným nebo špatným způsobem. Zde je 10 nejhorších praktik, kterým je třeba se vyhnout.
1. Volba MongoDB jako vaší velké datové platformy. Proč vybírám MongoDB? Nejsem, ale z jakéhokoli důvodu je nejvíce zneužívaná databáze NoSQL v tomto okamžiku MongoDB. Zatímco MongoDB má agregační rámec, který chutná jako MapReduce a dokonce (velmi špatně zdokumentovaný) konektor Hadoop, jeho sladkou stránkou je operační databáze, nikoli analytický systém.
[Andrew C. Oliver odpovídá na otázku každého: Jakou šílenou databázi mám použít? | Také zapnuto: Čas pro standardy NoSQL je nyní | Získejte přehled klíčových příběhů každý den v denním zpravodaji. ]
Když začne vaše věta: „K analýze použijeme Mongo ...“, zastavte se a přemýšlejte o tom, co děláte. Někdy opravdu myslíte „sbírejte pro pozdější analýzu“, což může být v pořádku, podle toho, co děláte. Pokud však opravdu myslíte, že budete používat MongoDB jako nějaký druh technologie datových skladů, váš projekt může být na začátku odsouzen k zániku.
2. Použití schématu RDBMS jako souborů. Jo, vyložili jste každou tabulku ze svého RDBMS do souboru. Plánujete to uložit na HDFS. Plánujete na něm použít úl.
Nejprve víte, že Úl je pomalejší než váš RDBMS pro něco normálního, že? Chystá se MapReduce i jednoduchý výběr. Podívejte se na „optimalizovanou“ cestu pro spojení „tabulky“. Dále se podívejme na velikosti řádků - víš, že máš ploché soubory měřené v jednociferných kilobajtech. Hadoop funguje nejlépe na velkých souborech relativně plochých dat. Jsem si jistý, že můžete vytvořit extrakt, který je více denormalizovaný.
3. Vytváření datových rybníků. Na cestě k vytvoření datového jezera jste odbočili z jiného nadjezdu a vytvořili řadu datových rybníků. Conwayův zákon znovu zasáhl a vy jste umožnili každé obchodní skupině nejen vytvořit vlastní analýzu dat, ale také jejich vlastní mini-úložiště. Zpočátku to nezní špatně, ale s různými výňatky a způsoby krájení a krájení dat skončíte s různými pohledy na data. Nemyslím plochý proti kostce - mám na mysli různé odpovědi na stejné otázky. Schéma číst neznamená „vůbec neplánovat“, ale znamená „neplánovat každou otázku, kterou byste se mohli zeptat.“
Měli byste si však naplánovat celkový obraz. Pokud prodáváte widgety, existuje velká šance, že někdo bude chtít zjistit, kolik, komu a jak často jste widgety prodávali. Jděte do toho a získejte to v běžných formátech a udělejte malý up-front design, abyste se ujistili, že neskončíte s datovými rybníky a loužemi, které vlastní každá jednotlivá obchodní skupina.
4. Nedodržení věrohodných případů použití. Myšlenku na datové jezero prodávají prodejci, aby nahradili případy skutečného použití. (Je to také způsob, jak uniknout omezením resortního financování.) Přístup založený na datovém jezeře může být platný, ale měli byste mít na paměti skutečné případy použití. Není těžké je najít ve většině středně velkých podniků. Začněte kontrolou, když někdo naposledy řekl: „Ne, nemůžeme, protože databáze to nezvládne.“ Poté přejděte na „duh“. Například „rozvoj podnikání“ nemá být jen titulární propagací pro vašeho nejlepšího prodejce; mělo to něco znamenat.
A co třeba použít Mahout k vyhledání objednávek zákazníků, které jsou běžnými odlehlými hodnotami? Ve většině společností se většina objednávek zákazníků navzájem podobá. Ale co objednávky, které se stávají dost často, ale neodpovídají běžným? Mohou být příliš malé na to, aby se o ně prodejci mohli starat, ale mohou naznačovat budoucí směr podnikání pro vaši společnost (tj. Skutečný rozvoj podnikání). Pokud nemůžete pro Hadoop nabodnout alespoň pár dobrých reálných použití, možná to nakonec nebudete potřebovat.
5. Myšlení Úl je vše, konec. Znáte SQL. Máte rádi SQL. Děláte SQL. Chápu to, člověče, ale možná můžeš také růst? Možná byste měli sáhnout hluboko do deseti nebo tří let a vzpomenout si na mladého kluka, který se naučil SQL a viděl světy, které se mu otevřely. Nyní si ho představte, jak se současně učí další věc.
