Wie man eine BIG DATA Data Mart/Faktentabelle anpackt? (240 Millionen Zeilen)

Question

Wir haben einen BI-Kunden, der monatlich etwa 40 Millionen Zeilen in seinen Verkaufsdatenbanktabellen erzeugt, die aus seinen Verkaufstransaktionen generiert werden. Sie möchten einen Sales Data Mart mit ihren historischen Daten von 5 Jahren aufbauen, was bedeutet, dass diese Faktentabelle potenziell 240 Millionen Zeilen haben wird. (40 x 12 Monate x 5 Jahre)

Dies ist gut strukturierte Daten.

Dies ist das erste Mal, dass ich mit dieser Datenmenge konfrontiert bin, und dies hat mich dazu gebracht, vertikale Datenbanken wie Inforbright und andere zu analysieren. Aber mit dieser Art von Software würde eine einfache Abfrage sehr lange dauern.

Dies brachte mich dazu, einen Blick auf Hadoop zu werfen, aber nach dem Lesen einiger Artikel kam ich zu dem Schluss, dass Hadoop nicht die beste Option ist, um eine Faktentabelle zu erstellen, da in meinem Verständnis mit unstrukturiert gearbeitet werden soll Daten.

Also, meine Frage ist: Was wäre der beste Weg, um diese Herausforderung zu bauen ?? , Suche ich nicht nach der richtigen Technologie? Was wären die besten Abfrageantwortzeiten, die ich in einer so großen Faktentabelle bekommen könnte? ..oder konfrontiere ich hier eine echte Mauer und die einzige Option ist es, aggregierte Tabellen zu erstellen?

Answer 1

Sie könnten eine gepackte NoSQL-/Analyselösung wie DataStax Enterprise in Betracht ziehen, die Apache Cassandra mit Hadoop und anderen nützlichen Analysetools verwendet. Sie haben Recht, dass das "Standard" -HDFS-Dateisystem von Hadoop für unstrukturierte Daten geeignet ist. Durch die Integration in einen NoSQL-Datenspeicher (wie Cassandra oder HBase) können Sie jedoch Ihre strukturierten Daten mithilfe von MapReduce einfacher analysieren.

Answer 2

hadoop ist absolut geeignet für so große Daten .. Sie können es mit HBase verwenden, die uns zu Millionen von Zeilen und Milliarden von Spalten erweitert, und bietet große horizontale Skalierbarkeit sowie .. es ist geeignet für Echtzeit zufällig Lese Schreibzugriff ... auf der anderen Seite ist Hive gut für Batch-Verarbeitung, so können Sie Bienenstock Jobs im Hintergrund für andere Aufgaben ausführen .. wir sollten Hadoop als Alternative zu traditionellen RDBMS nicht verwechseln, aber es ist wirklich hilfreich im Umgang mit großen Datensätze können Sie ein anderes Apache-Projekt "sqoop" verwenden, das uns erlaubt, unsere Daten aus bestehenden Datenbanken zu Hadoop-Cluster ohne viel Schmerz zu importieren.

Answer 3

zuerst ich nehme seine 240m nicht 2400m.

nimmt zunächst einen Blick auf ssd.analytical-labs.com

Die FCC Demo hat eine 150m Rekord Faktentabelle auf Infobright läuft, würde ich auf VW vermutet, es wäre sogar noch schneller sein.

Der Schlüssel ist es einfach zu halten, es wird Abfragen geben, die es langsam fallen lassen, aber Largley ist ziemlich ansprechend.

Ich würde vorschlagen, Sie denken über Aggregate, die Art, wie Sie abfragen und vor allem, was Sie abfragen.

Zum Beispiel teilen Sie es in Marts für Leistung, nach Produkt, nach Marke, nach Jahren usw. Wenn der Benutzer nur eine Abfrage auf < 1 Jahr Wert von Daten (was häufiger der Fall als die meisten Menschen ist) würde gerne denken) sie könnten dann eine viel kleinere Faktentabelle verwenden.

Speicher ist billig, es spielt also keine Rolle, ob du Daten duplizierst, solange sie darauf reagieren.

Natürlich auch, wenn Sie OLAP tun Sie Verwendung von Inline-Aggregat Tabellen machen können, um sicherzustellen, die meisten Abfragen zu einem weitaus mehr akzeptables Niveau laufen vorausgesetzt, sie aufgerollt haben.

Hardware ist auch sehr wichtig, stellen Sie sicher, dass Sie schnelle Festplatten haben, das ist fast immer der Flaschenhals, desto schneller können Sie die Daten von den Festplatten im Allgemeinen desto schneller wird es für den Endbenutzer angezeigt.

Schemaentwurf ist auch wichtig, moderne Spaltenspeicherdatenbanken bevorzugen viel eine demormalised Tabelle mit 0 verbindet wo möglich, ich habe in der Vergangenheit gefunden, 1 denormalised Tabelle für 90% der Abfragen dann einige Verbindungstabellen habend (Datum Dim zum Beispiel) für spezielle Fälle zählt für die meisten Anwendungsfälle.

Wie auch immer, das ist mein 2 Cent. Ping mich auf Twitter, wenn du einen Skype darüber willst oder so.

Tom

Edit:

Auch hier ist ein nicht wissenschaftlicher bench mark zu sichern, was JVD sagt:

• ssd auf physische Box: 175,67 MB/s
• sata auf Physische Box: 113,52 MB/Sek.
• ec2: 75,65 MB/Sek.
• ec2 ebs raid: 89,36 MB/s ec

Wie Sie einen großen Unterschied gibt es in Lesegeschwindigkeit zu sehen.

Answer 4

Eine weitere Kombination der Technologien, die ich erfolgreich für ein sehr großes Data Warehouse verwendet habe, ist Hadoop + Hive. Die Daten wurden mithilfe von Map/Reduce-Jobs manipuliert und als externe Tabellen an Hive übergeben. Aktualisierungen wurden durchgeführt, indem Partitionen zwischen den Bereichen der Stufe und des Data Warehouse ausgetauscht wurden.

Der große Vorteil dieses Ansatzes war, dass man (fast) normale SQL-Abfragen auf den Daten ausführen konnte. Der Nachteil - Sie konnten kein Hive-Backend an ein interaktives UI-Frontend anschließen. Aber wenn Sie nur tägliche Berichte und Datamining ausführen, sollte dies funktionieren.

Answer 5

Ich denke, es gibt ein paar Ansätze hier,

1) Sie aggregierte Tabellen auf Mondrian versuchen sollte, ist die Kehrseite der agg Tabellen, die Sie vorher die Anwendungsfälle für die meisten wiederkehrenden Anfragen wissen müssen, wenn Sie dann ist es nicht so einfach, das zu tunen, und Sie werden lange Antwortzeiten für die Abfragen haben, die Sie die Gesamttabelle nicht optimiert haben.

2) Eine andere Möglichkeit ist, die Daten der Faktentabelle zu partitionieren, vielleicht nach Jahren, verschiedene Schemata für jedes Jahr und einen virtuellen Würfel für die gesamte Historie zu erstellen. Wenn Sie die richtige Software haben, können Sie auch eine materialisierte Ansicht (wenn Sie Oracle haben) oder eine indizierte Ansicht erstellen, wenn Sie MS SqlServer haben.

Der späte Ansatz hat sehr gut für mich gearbeitet, mit spürbaren Verbesserungen bei den Abfragezeiten. Außerdem war mein ETL-Prozess nicht betroffen (in Option 1 müssen Sie einen zusätzlichen Prozess zum Erstellen und Verwalten von Aggregat-Tabellen erstellen), da der RDMBS den Prozess der Aktualisierung der Daten auf jeder Partition übernimmt.

Answer 6

Haben Sie Google BigQuery (Paid Premium Service) ausgecheckt, das Ihren Anforderungen entspricht?Es ist so einfach wie

1. Laden Sie die Daten in CSV (begrenzt durch neue Zeile für Datensatz oder konfigurierbare Zeichen für Feld). Die Datei kann im gzip-Format vorliegen. Sie können auch an vorhandene Tabelle anhängen.

2. Starten Sie Abfragen mit SQL-Anweisung (begrenzte SQL-Anweisung) und die Ergebnisse werden in Sekunden von mehreren Millionen Zeilen zurückgegeben.

3. Extrahieren der Daten in eine CSV-Datei oder einer anderen Tabelle (ähnlich Aggregationsschicht)

prüfen geführt. https://developers.google.com/bigquery/

Erste 100GB für die Datenverarbeitung ist kostenlos. So können Sie jetzt beginnen und es integriert sich auch mit Google Spreadsheet, mit dem Sie Visualisierungen wie Diagramme und Grafiken usw. für das Management erstellen können. Sie können die Google Tabellenkalkulation als Microsoft Excel/PDF exportieren.

Google gibt an, dass es auf Multi-Terrabyte skaliert werden kann und Echtzeit-Abfragen (wenige Sekunden Antwort) bietet.