Die 10 schlimmsten Big-Data-Praktiken

Ja, Sie können Big Data gefährden. Sie können es jedoch auf die richtige oder die falsche Weise tun. Hier sind die 10 wichtigsten Praktiken, die Sie vermeiden sollten.

1. Wählen Sie MongoDB als Ihre Big-Data-Plattform. Warum wähle ich MongoDB aus? Ich bin es nicht, aber aus irgendeinem Grund ist MongoDB die am meisten missbrauchte NoSQL-Datenbank. Während MongoDB über ein Aggregationsframework verfügt, das nach MapReduce schmeckt, und sogar über einen (sehr schlecht dokumentierten) Hadoop-Connector, ist sein Sweet Spot eine operative Datenbank und kein Analysesystem.

[Andrew C. Oliver beantwortet die Frage in aller Munde: Welche verdammte Datenbank soll ich verwenden? | Ebenfalls am: Die Zeit für NoSQL-Standards ist jetzt | Im Daily Newsletter erhalten Sie jeden Tag einen Überblick über die wichtigsten Geschichten. ]]

Wenn Ihr Satz beginnt: "Wir werden Mongo verwenden, um zu analysieren ...", hören Sie genau dort auf und überlegen Sie, was Sie tun. Manchmal meinst du wirklich "für spätere Analysen sammeln", was je nach dem, was du tust, in Ordnung sein kann. Wenn Sie jedoch wirklich meinen, dass Sie MongoDB als eine Art kranke Data-Warehousing-Technologie verwenden, ist Ihr Projekt möglicherweise zu Beginn zum Scheitern verurteilt.

2. Verwenden des RDBMS-Schemas als Dateien. Ja, Sie haben jede Tabelle aus Ihrem RDBMS in eine Datei geschrieben. Sie planen, das auf HDFS zu speichern. Sie planen, Hive darauf zu verwenden.

Zunächst einmal wissen Sie, dass Hive für alles Normale langsamer ist als Ihr RDBMS, oder? Es wird MapReduce sogar eine einfache Auswahl treffen. Schauen Sie sich die "optimierte" Route für "Tabellen" -Verbindungen an. Schauen wir uns als nächstes die Zeilengrößen an - wie Sie wissen, haben Sie flache Dateien, die in einstelligen Kilobyte gemessen werden. Hadoop eignet sich am besten für große Mengen relativ flacher Daten. Ich bin sicher, Sie können einen Extrakt erstellen, der denormalisierter ist.

3. Erstellen von Datenteichen. Auf dem Weg zum Erstellen eines Datensees haben Sie eine andere Überführung ausgeschaltet und eine Reihe von Datentümpeln erstellt. Das Gesetz von Conway ist erneut in Kraft getreten und Sie haben jede Unternehmensgruppe nicht nur ihre eigene Analyse der Daten erstellen lassen, sondern auch ihre eigenen Mini-Repositories. Das klingt zunächst nicht schlecht, aber mit verschiedenen Auszügen und Methoden zum Schneiden und Würfeln der Daten erhalten Sie unterschiedliche Ansichten der Daten. Ich meine nicht flach gegen Würfel - ich meine unterschiedliche Antworten auf einige der gleichen Fragen. Schema-on-Read bedeutet nicht "überhaupt nicht planen", sondern "nicht für jede Frage planen, die Sie möglicherweise stellen".

Trotzdem sollten Sie das große Ganze einplanen. Wenn Sie Widgets verkaufen, besteht eine gute Chance, dass jemand sehen möchte, wie viele, an wen und wie oft Sie Widgets verkauft haben. Holen Sie sich das in den gängigen Formaten und gestalten Sie es ein wenig im Voraus, um sicherzustellen, dass Sie nicht mit Datenteichen und Pfützen enden, die jeder einzelnen Unternehmensgruppe gehören.

4. Keine plausiblen Anwendungsfälle entwickeln. Die Idee des Datensees wird von Anbietern verkauft, um reale Anwendungsfälle zu ersetzen. (Dies ist auch ein Weg, um den Einschränkungen der Abteilungsfinanzierung zu entgehen.) Der Data-Lake-Ansatz kann gültig sein, Sie sollten jedoch tatsächliche Anwendungsfälle berücksichtigen. Es ist nicht schwer, sie in den meisten mittelständischen Unternehmen zu finden. Überprüfen Sie zunächst, wann jemand zuletzt gesagt hat: "Nein, das können wir nicht, weil die Datenbank damit nicht umgehen kann." Fahren Sie dann mit "duh" fort. Zum Beispiel soll "Geschäftsentwicklung" nicht nur eine Titelwerbung für Ihren Top-Verkäufer sein. es soll etwas bedeuten.

Wie wäre es beispielsweise mit Mahout, um Kundenaufträge zu finden, bei denen es sich häufig um Ausreißer handelt? In den meisten Unternehmen ähneln sich die meisten Kundenaufträge. Aber was ist mit den Befehlen, die oft genug vorkommen, aber nicht mit den üblichen übereinstimmen? Diese sind möglicherweise zu klein, als dass sich Vertriebsmitarbeiter darum kümmern könnten, aber sie können auf einen zukünftigen Geschäftszweig für Ihr Unternehmen hinweisen (dh auf die tatsächliche Geschäftsentwicklung). Wenn Sie nicht mindestens ein paar gute reale Anwendungen für Hadoop finden können, brauchen Sie sie vielleicht doch nicht.

5. Thinking Hive ist das A und O. Sie kennen SQL. Sie mögen SQL. Sie haben SQL ausgeführt. Ich verstehe, Mann, aber vielleicht kannst du auch wachsen? Vielleicht sollten Sie ein oder drei Jahrzehnte tief in die Tiefe greifen und sich an das junge Kind erinnern, das SQL gelernt und die Welten gesehen hat, die es für ihn geöffnet hat. Stellen Sie sich jetzt vor, er lernt gleichzeitig etwas anderes.