Big-Data-Problem
Big-Data-Volumen wachsen exponentiell. Dieses Phänomen tritt seit Jahren auf, hat sich aber seit 2012 dramatisch beschleunigt. Sehen Sie sich diesen Blog mit dem Titel „Big Data Just Beginning to Explode“ von CSC an, um einen ähnlichen Standpunkt zur Entstehung von Big Data und den damit verbundenen Herausforderungen zu erhalten.
IRI ist dieser Trend seit der Firmengründung Ende der 1970er Jahre bewusst. Sein Flaggschiff-Paket CoSort wurde entwickelt, um wachsende Datenmengen durch Effizienz bei Softwarealgorithmen und -design, Techniken zur Nutzung „tragbarer“ Hardware und Aufgabenkonsolidierung (z. B. Sortieren-Join-Aggregatieren-Verschlüsseln-Bericht) zu bewältigen. Die Frage, die dieser Artikel aufwirft, ist eine der Herangehensweise angesichts des „Aufstiegs der Maschinen“.
Beschränkung der Hardware bei der Lösung
Sicherlich hat sich die Computerleistung seit Jahrzehnten in fast jeder Hinsicht beschleunigt. Und für viele ist es nur eine Selbstverständlichkeit, Hardware auf das Big-Data-Problem zu werfen. Das Problem kann jedoch größer sein. Betrachten Sie das Mooresche Gesetz, in dem sich die CPU-Leistung nur verdoppelt bestenfalls alle 18 Monate und die inhärente Veralterung, Wartungsprobleme und reine Kosten einer hardwarezentrierten Strategie.
Neu zu berücksichtigen ist auch die Erwartung, dass dieses Performance-Paradigma für Big Data möglicherweise zu Ende geht. Laut Gery Menegaz ist seine Prämisse, dass das Ende von Moores Gesetz nahe ist. Das Time Magazine veröffentlichte im Mai 2012 eine ähnliche Geschichte mit dem Titel The Collapse of Moore’s Law: Physicist Says Its While Happening. Laut dem Time-Artikel
In Anbetracht dessen sagt Kaku, dass wir, wenn Moores Gesetz bis Ende des nächsten Jahrzehnts endgültig zusammenbricht, „es einfach ein bisschen mit chipähnlichen Computern in drei Dimensionen optimieren werden“. Darüber hinaus sagt er:„Möglicherweise müssen wir zu Molekularcomputern und vielleicht im späten 21. Jahrhundert zu Quantencomputern übergehen.“
Für die meisten Benutzer wird ihre Hardware jedoch so gekauft, dass sie die Herausforderungen der Big-Data-Verarbeitung bewältigen und in gewissem Maße skalieren kann, mit denen sie konfrontiert sind oder die sie vorhersehen. Aber je weniger effizient die darauf laufende Software arbeitet, desto mehr Hardwareressourcen müssen aufgewendet werden, um die Ineffizienz zu überwinden. Ein Beispiel in unserer Welt könnte der Kauf eines IBM p595 sein, um /bin/sort auszuführen, wenn eine Maschine mit einem Drittel dieser Größe und Kosten, auf der stattdessen CoSort ausgeführt wird, dasselbe Ergebnis liefern würde.
In der Zwischenzeit erfordern DB- und ELT-Appliances wie Exadata und Netezza, die auf Hardware basieren, bereits Investitionen im sechs- bis siebenstelligen Bereich. Und obwohl sie skalieren können, um größere Lasten zu übernehmen, gibt es normalerweise eine Grenze dafür, wie stark sie skalieren können (sicherlich nicht exponentiell), wie viel Geld für den Versuch ausgegeben werden kann, die Skalierung fortzusetzen, und wie bereit die Menschen sind, sich auf a zu verlassen einen einzigen Anbieter für jeden unternehmenskritischen Aspekt ihrer Workloads. Und ist es eine gute Idee, den Overhead der Big-Data-Transformation stattdessen Datenbanken aufzuerlegen, die für die Optimierung von Speicherung und Abruf (Abfrage) entwickelt wurden?
Selbst wenn all diese Fragen einfach zu beantworten wären, wie werden Rechenprobleme gelöst (auch wenn das Big-Data-Wachstum nur linear skaliert wird), die einen exponentiell größeren Ressourcenverbrauch (wie Sortieren) erfordern? Irgendwie scheint die Antwort nicht darin zu liegen, einfach auf bezahlbare Quantencomputer zu warten …
Die Rolle der Software
Wie Hadoop- und Data-Warehouse-Architekten wissen, ist das Sortieren – und die Join-, Aggregate- und Ladevorgänge in ETL, die auf Sortierung angewiesen sind – das Herzstück der Big-Data-Verarbeitungsherausforderung und ein exponentieller Verbraucher von Rechenressourcen. Wenn sich Big Data verdoppelt, kann sich der Ressourcenbedarf zum Sortieren verdreifachen. Daher sind die Algorithmen, Hardware-Nutzungstechniken und Verarbeitungsschemata, die mit Multi-Plattform-Multi-Core-Sortiersoftware verbunden sind, der Schlüssel zur Bewältigung dieses Problems auf skalierbare, erschwingliche und effiziente Weise.
Der Beitrag von CoSort
Die Leistung von CoSort skaliert linear im Volumen, eher in Anlehnung an das Gesetz von Amdahl. Während CoSort mit ein paar Dutzend Kernen Hunderte von Gigabyte an Big Data in Minuten umwandeln kann, können andere Tools mehr als doppelt so lange brauchen, nicht annähernd so gut skalieren und/oder dabei mehr Speicher und E/A verbrauchen. Vielleicht noch wichtiger ist, dass CoSort die Sortierung direkt in verwandte Anwendungen integriert und seine gesamte Schwerarbeit außerhalb der DB- und BI-Ebene leistet, wo die Bereitstellung von Daten weniger effizient wäre.
Die Co-Routine-Architektur von CoSort verschiebt Datensätze zwischen dem Sortierer und Programmen wie SortCL (CoSorts Datenumwandlungs-, Filter-, Such-, Berichts-, Migrations- und Schutzdienstprogramm) interaktiv über den Speicher. Sobald also der nächste sortierte Datensatz verfügbar ist, kann er in die Anwendung verschoben, geladen usw. werden. Für die App sieht es so aus, als würde sie eine Eingabedatei lesen, aber in Wahrheit wurde das Back-End der Quelle noch nicht erstellt. Und nein, Sie werden den Sortierer nicht überholen.
Ende 2015 wurde CoSort auch zum Motor in Voracity, der modernen Big-Data-Verwaltungs- und Manipulationsplattform von IRI. Voracity nutzt sowohl CoSort- als auch Hadoop-Engines nahtlos.
Fazit
Physical Computing-Ressourcen allein können nicht verwendet werden, um das Problem der Verarbeitung von Big Data zu bewältigen. Die CoSort-Softwareumgebung ist eine Umgebung, in der die erforderliche Big-Data-Transformation und zugehörige Jobs nicht als eigenständige Prozesse, sondern parallel während desselben E/A-Durchgangs ausgeführt werden.
Wenn Sie also eine schnelle Sortierung für einen anderen Zweck als nur die Zeit zum Sortieren benötigen, sollten Sie darüber nachdenken, was nach der Sortierung passiert und wie Sie solche Prozesse am besten miteinander verbinden können. Und wenn Sie das beste Laufzeitparadigma ermittelt haben, können Sie dann Hochleistungshardware mit solcher Software kombinieren, um die Leistung zu optimieren? Können Sie beispielsweise DW-Daten mit CoSort auf der Datenbankserverseite von Exadata bereitstellen? Oder wäre es sinnvoller, Ihren IBM p595 zu behalten und CoSort hinzuzufügen, um den Durchsatz zu verdreifachen? Oder wenn Sie beabsichtigen, Hadoop zu verwenden, erwägen Sie die Verwendung der gleichen einfachen 4GL von CoSort oder der intuitiven ETL-Mappings von Voracity, um MapReduce 2-, Spark-, Storm- oder Tez-Jobs zu steuern.
Lassen Sie sich bei der Bewältigung des Datenwachstums von Ihrem Budget und Ihrer Vorstellungskraft leiten.
