Analytics Cube und darüber hinaus

Das Big Data hat einen scheinbar endlosen Vorrat an Umgehungslösungen erfunden. Diese sind sowohl für scalability als auch für Leistungsprobleme gedacht. Letztendlich bestimmt unser Ansatz zur Lösung dieser Probleme, wie nachhaltig sie sein werden. Dieser Beitrag vergleicht einige moderne Best Practices mit Pre-Processing-Cube-Umgebungen.

3 Wege, wie eine Hadoop-Datenbank mit Cube Analytics konkurriert

• Softwareentwicklung ist wichtiger als Vorverarbeitung.
• Die Fähigkeit Datenmanagement ist entscheidend.
• Kontrolle der Datenexplosion und der Komplexität der Plattform.

Cube-Engines(OLAP) für die Analyse von Data Warehouses sind nichts Neues, aber ihre Anwendung in den heutigen verteilten Datenmanagement schon. Dieser Beitrag vergleicht High-Performance SQL analytische Datenbanken mit Cube-Analysen in der heutigen verteilten Umgebung.

Unternehmensweite Cube-Plattformen helfen den Nutzern, sich problemlos durch riesige Datenmengen zu wühlen. Da sich das Betriebssystem für die Data Analytics jedoch auf massiv parallele Rechenarchitekturen mit verteilten Datenquellen zubewegt, kann es verwirrend sein, ob würfelbasierte Analysen für Ihr nächstes Projekt hilfreich sind oder nicht.

Hadoop selbst bietet wenig Hilfe bei der Erstellung von High-Performance . Sie erhalten zwar einen transparenten Zugriff auf eine Vielzahl von Daten, müssen aber oft Abstriche bei der Leistung und anderen wichtigen Funktionen wie Datenmanagement und Kontrolle der Datenexpansion machen - drei Schlüsselkomponenten für die Beherrschung des wachsenden Daten-Lake .

Aus diesem Grund werden Hadoop-Anwender in Zukunft wahrscheinlich keine Cube-Analysen mehr durchführen, da "schnelle" Datenbanken den Overhead und die Komplexität der Wartung eines würfelbasierten Systems umgehen.

Software-Design übertrumpft Vorverarbeitung

Cube-Analysen sind die Rettung für überfüllte Data Warehouses oder unzureichend ausgestattete analytische Datenbanken, wenn sie zu groß, zu schwer und zu langsam werden, um mit den immer schwieriger werdenden Arbeitslasten Schritt zu halten. Warum haben diese Datenbanken so schlecht funktioniert, als die Datenmengen zunahmen oder moderne Hardware erforderlich wurde? Weil veraltete Software-Engineering-Ansätze Leistungsverbesserungen eingeschränkt haben.

Infolgedessen ist die Industrie begeistert, wenn es lediglich lineare Verbesserungen der Anfrage im Vergleich zur Hardwareverbesserung gibt. Beschleunigen Hardwareverbesserungen (à la Moore's Law) alle unsere Anfragen so sehr oder merken wir das überhaupt? Ich wette, nicht. Wie kann das sinnvoll sein, wenn z. B. die Chip-Hersteller regelmäßig weitere Möglichkeiten zur Optimierung der Verarbeitung hinzufügen?

Actian hat verschiedene Verbesserungen in Hardware und Software genutzt, um hoch optimierte Analyseumgebungen zu schaffen.

Bessere Hardware nutzen

Die meisten Systeme nutzen einfach nicht die inhärente Leistung moderner Computerplattformen aus. Wenn man schnellere Festplatten (SSD) und besseren Arbeitsspeicher einbaut und die Netzwerkverbindungen verbessert, können die Dinge natürlich schneller laufen. Wenn man dann noch Cube Analytics hinzufügt, verbessert sich zwar die Leistung, aber nur im Vergleich zu Altsystemen, die auf ähnlich konzipierten Architekturen laufen.

Moderne Datenbanken, die die neuesten Prozessorverbesserungen (Chip-Cache, Festplattenverwaltung, Speichergrößen, Vertikale Speicherung usw.) nutzen, bringen alle einen Leistungsgewinn gegenüber den alten Ansätzen. Diese Verbesserungen zeigen mehr als lineare, oft exponentielle Verbesserungen gegenüber anderen gängigen Lösungen auf dem Markt. Dies ist der Punkt, an dem Actian seinen Hut im Bereich Big Data aufhängt (siehe Actians Vector auf der Hadoop-Plattform ).

Wir alle sollten von Generation zu Generation erhebliche Verbesserungen sowohl bei der Hardware als auch bei der Software erwarten. Schließlich sind die Ingenieure von heute besser ausgebildet als je zuvor und verwenden die beste jemals entwickelte Hardware.

Wenn Sie sich diese Vorteile nicht zunutze machen, haben Sie die Chance auf einen "Moon Shot" durch big data Analytics bereits vertan. Sie werden den Damm nicht mit altem Beton stopfen können - Sie müssen ihn neu gießen.

Hochleistungsdatenbanken beseitigen die Grenzen, die in den letzten Jahrzehnten die alten Datenbanken und Data Warehouses erdrückt haben. Cube-Engines können zwar immer noch auf diesen neuen Analytics Database arbeiten, sind aber oft so schnell, dass sie diese Hilfe nicht benötigen. Stattdessen können gängige Business Intelligence (BI) direkt an sie angeschlossen werden und eine hervorragende Anfrage beibehalten.

Datenmanagement ist entscheidend

Funktionen sind für jede nachhaltige Datenbank von entscheidender Bedeutung. Front-End-Benutzer benötigen lediglich einen SQL-Zugang, aber DBAs benötigen immer Werkzeuge für die Änderung von Tabellen, die Optimierung der Speicherung, die Sicherung von Daten und die Aufräumarbeiten nacheinander. Dies ist ein weiterer Bereich, in dem sich analytische Datenbanken und Cube-Engines der nächsten Generation unterscheiden.

Viele Tools im Hadoop-Ökosystem können eine Sache gut - nämlich verschiedene Arten von Daten lesen oder analytische Prozesse ausführen. Das bedeutet, dass sie nicht all die Dinge tun können, die eine Unternehmensdatenbank normalerweise erfordert. Cube-Engines sind hier keine Ausnahme - ihre Stärke liegt in der Zusammenfassung von Daten und der Erstellung von Abfragen auf diesen Daten.

Wenn Ihre Daten von einem Würfelsystem verarbeitet werden, verfügen Sie nicht mehr über eine unternehmensweite SQL-Datenbank. Zugegeben, Sie haben vielleicht SQL-Zugriff, aber Sie haben wahrscheinlich Einfüge-, Aktualisierungs- und Funktionen und andere verloren. Diese Funktionen sollten Sie von Ihrer Analytics Database erwarten - ACID-Konformität, volle SQL-Konformität, vektorbasierter spaltenbasierter Ansatz, nativ in Hadoop, zusammen mit anderen Notwendigkeiten Datenmanagement .

Eng verbunden mit dem Datenmanagement ist die Möglichkeit, an die Rohdaten an der Quelle heranzukommen. Bei einer schnellen relationalen Datenbank gibt es keine Trennung von zusammengefassten Daten und detaillierten Datensätzen. Sie sind immer nur eine Anfrage entfernt von Daten höherer Granularität - aus derselben Datenbank, aus derselben Tabelle. Wenn die Datenbank aktualisiert wird, stehen alle neuen Datenpunkte sofort für die nächste Anfrage zur Verfügung, unabhängig davon, ob sie vorverarbeitet wurden oder nicht.

Datenmanagement ist wichtig!  

Daten ändern sich, wenn neue Daten aufgenommen werden, aber auch, weil die Nutzer sie ändern, bereinigen oder auf andere Weise als bisher zusammenfassen wollen. Wir alle brauchen diese Flexibilität und Leistung, um unsere Fähigkeiten und unser Fachwissen im Umgang mit Daten weiter nutzen zu können.

Explosion der Steuerungsdaten und Komplexität der Plattform

Die Datenexplosion ist real. Das Sprichwort, dass wir das Datenwachstum ständig vervielfachen, wirft die Frage auf: Wie können wir es so überschaubar wie möglich halten?

An dieser Stelle habe ich ein grundsätzliches Problem mit Würfelansätzen für die Analytik. Wir sollten uns bemühen, Tools zu vermeiden, die unsere exponentiell wachsenden Datenmengen duplizieren und noch weiter aufblähen. Natürlich sollten wir auch keine Daten aus Hadoop auslagern, wie es einige Produkte tun.

Wäre es nicht sinnvoller, eine Lösung zu entwickeln, die sich direkt mit den Leistungsengpässen in der Software befasst, anstatt eine langsame Analytics Database durch die Vorverarbeitung von Dimensionen zu reparieren, die in Zukunft vielleicht gar nicht verwendet werden?

Leider führen Cube-Konzepte zwangsläufig zu einer Vergrößerung des Datenvolumens. Die Leiter des Kylin-Projekts haben zum Beispiel gesagt, dass sie durch die Verwendung von Würfeln eine "6-10-fache Datenerweiterung" sehen. Dies setzt auch entsprechend geschultes Personal voraus, das im Laufe der Zeit Würfel erstellen und bereinigen kann. Es wird schnell unmöglich, den zukünftigen Speicherbedarf abzuschätzen, wenn Sie nicht sicher sein können, wie viel Platz Ihre Analysen benötigen werden.

Vermeiden Sie das Jonglieren mit komplexen Plattformen

Viele Plattformen erfordern das Jonglieren mit mehr technologischen Komponenten als eine moderne Analytics Database. Das Laden und Verarbeiten von Datenquellen in einer Datenbank ist schon schwierig genug. Wenn dann noch Schichten für Normalisierung, Cube-Generierung, Abfragen und Cube-Regenerierung usw. hinzukommen, wird die Wartung eines Systems noch schwieriger.

Das Kylin-Projekt von Apache, um nur ein Beispiel zu nennen, erfordert eine ganze Reihe beweglicher Teile: Hive für die Aggregation der Quelldaten, Hive für die Speicherung einer denormalisierten Kopie der zu analysierenden Daten, HBase für die Speicherung der resultierenden Würfeldaten, eine darauf aufbauende Anfrage , um sie SQL-kompatibel zu machen, usw. Sie können sich vorstellen, dass Sie möglicherweise zusätzliche Knoten benötigen, um verschiedene Teile dieses Entwurfs zu handhaben.

Das ist eine Menge Gepäck; hoffen wir, dass Sie es wirklich brauchen, wenn Sie es benutzen!

Betrachten Sie die Alternative, wie Actian Vector auf Hadoop. Sie stellen Ihre Daten aus operativen Quellen zusammen. Sie erstellen Ihre Abfragen in SQL. Das war's. Nur weil viele Hadoop-Optionen langsam sind, heißt das nicht, dass sie es auch sein müssen, und wir müssen nicht noch mehr Komplexität in die Plattform einbauen, um dies auszugleichen.

Mit einer optimierten Plattform müssen Sie Ihre Abfragen nicht stapelweise im Hintergrund laufen lassen, um eine gute Leistung zu erzielen, und Sie müssen sich keine Sorgen über Ressourcenkonflikte zwischen den Produkten in Ihrem Stack machen. Es ist alles ein einziges System. Alles, von der Blockverwaltung bis zur Optimierung von Anfrage , läuft über dasselbe System, und so sollte es auch sein.

SQL-Analysten vs. Jongleure

Der letzte Punkt, den Sie berücksichtigen sollten, sind Ihre Humanressourcen. Sie können nur in einer begrenzten Anzahl von Dingen Experten sein. Nicht alle Plattformen sind einfach zu verwalten und über die gesamte Lebensdauer Ihrer Investition zu unterstützen.

Wir arbeiten mit vielen Open-Source-Projekten zusammen, aber am Ende des Tages kennen wir unser eigenes Produkt in- und auswendig am besten. Wir können Teile des Stacks auf jeder Ebene verbessern und optimieren. Wenn Sie ein System mit vielen Teilkomponenten verwenden, die von verschiedenen Teams, verschiedenen Unternehmen oder sogar verschiedenen freiwilligen Gemeinschaften entwickelt und verwaltet werden, können Sie die Vorteile einer eng gekoppelten Lösung nicht mehr nutzen. Langfristig möchten Sie, dass diese Lösungen professionell unterstützt und gewartet werden, wobei Ihre Bedürfnisse im Vordergrund stehen.

Aus praktischer Sicht habe ich versucht zu zeigen, dass viele der Probleme, die Cubes zu lösen versuchen, weniger problematisch sind, wenn bessere relationale Datenbanken zur Verfügung stehen. Ebenso ist eine sorgfältige Abwägung wichtig, um zu entscheiden, ob der zusätzliche Aufwand für die Pflege einer solchen Lösung sinnvoll ist. Natürlich ist dies von Situation zu Situation unterschiedlich, aber ich hoffe, dass diese allgemeinen Vergleiche nützlich sind, wenn es darum geht, eine Technologie für eine bestimmte Anforderung zu qualifizieren.

Über Actian Corporation

Actian macht Daten einfach. Unsere Datenplattform vereinfacht die Verbindung, Verwaltung und Analyse von Daten in Cloud-, Hybrid- und lokalen Umgebungen. Mit jahrzehntelanger Erfahrung in den Bereichen Datenmanagement und -analyse liefert Actian leistungsstarke Lösungen, die es Unternehmen ermöglichen, datengesteuerte Entscheidungen zu treffen. Actian wird von führenden Analysten anerkannt und wurde für seine Leistung und Innovation mit Branchenpreisen ausgezeichnet. Unsere Teams präsentieren bewährte Anwendungsfälle auf Konferenzen (z. B. Strata Data) und tragen zu Open-Source-Projekten bei. Im ActianBlog behandeln wir Themen wie Echtzeit-Dateneingabe, Datenanalyse, Data Governance, Datenmanagement, Datenqualität, Datenintelligenz und KI-gesteuerte Analysen.