CoSort
Seit +45 Jahren der Schnellste für DatentransformationVersion: 10.5
Version: 10.5
IRI CoSort ist eine leistungsstarke Softwarelösung, die Unternehmen bei der Bewältigung von Big Data-Herausforderungen unterstützt. In einer Zeit, in der Datenmengen exponentiell wachsen, bietet CoSort eine effiziente Möglichkeit, große Datenmengen zu verarbeiten, zu transformieren und zu analysieren.
CoSort zeichnet sich durch seine Vielseitigkeit und Effizienz aus. Es ist das herausragende Sortierprodukt für Mainframes und bietet ein hervorragendes Preis-Leistungs-Verhältnis für die Manipulation großer Datenquellen.
Ein großes Finanzinstitut nutzt CoSort, um täglich Millionen von Transaktionsdaten zu verarbeiten. Die Software sortiert und bereinigt die Daten, maskiert sensible Kundeninformationen und erstellt aggregierte Berichte für das Management – alles in einem einzigen, effizienten Prozess. Dies ermöglicht dem Institut, schneller auf Marktveränderungen zu reagieren und gleichzeitig die Datenschutzbestimmungen einzuhalten.
Sie möchten mehr über CoSort und seine Verwendungsmöglichkeiten erfahren? Nehmen Sie einfach noch heute Kontakt mit uns auf!
Seit 1978 weltweit im B2B-Sektor anerkannt: Bei Großunternehmen, Banken, Versicherungen sowie Behörden im Einsatz!
Schnelle, sichere und kosteneffiziente Datenverarbeitung: Für IT-Experten, die große und sensible Datenmengen effizient verarbeiten wollen!
Seit über 40 Jahren nutzen unsere Kunden weltweit aktiv unsere Software für Big Data Wrangling und Schutz! Dazu gehören NASA, American Airlines, Walt Disney, Comcast, Universal Music, Reuters, das Kraftfahrtbundesamt, das Bundeskriminalamt, die Bundesagentur für Arbeit, Rolex, Commerzbank, Lufthansa, Mercedes Benz, Osram,..
Sie finden eine Auswahl weltweiter Referenzen hier und eine Auswahl deutscher Referenzen hier:
CoSort ist ein robustes, kommerzielles Softwarepaket für die effiziente Bearbeitung und Verwaltung großer Datenmengen. Genauer gesagt handelt es sich um ein Paket zur Sortierung, Datenumwandlung, Migration und Berichterstellung, das eine breite Palette von unternehmens- und entwicklungsbezogenen Herausforderungen in den Bereichen Datenintegration, Datenmaskierung, Business Intelligence und ergänzenden Disziplinen bewältigt. Weitere Informationen finden Sie in der Produktbeschreibung und in den Abschnitten zu den Lösungen auf dieser Website.
Für den Zweck dieser einfachen Sortier-/Zusammenführungsfrage steht CoSort für Co-routine Sort, das erstmals für den kommerziellen Einsatz freigegeben wurde:
Auf:
CP/M in 1978
DOS in 1980
Unix in 1985
Linux in 1990
Windows in 1995
IBM i/Z in 2000
CoSort nutzt Parallelverarbeitung, fortschrittliche Speicherverwaltungs- und E/A-Techniken sowie Aufgabenkonsolidierung und überlegene Algorithmen, um die Leistung von Datenbewegungen und -manipulationen in bestehenden Dateisystemen zu optimieren. Es sind keine Paradigmenwechsel zu Datenbank-Engines, NoSQL, Hadoop oder Appliances erforderlich. Vielleicht ein bisschen mehr RAM, aber das reicht normalerweise aus!
Das kann es sein. CoSort bietet eine Reihe von Lösungen für die Erstellung aussagekräftiger Berichte aus großen Datenmengen. Sie können das Programm SortCL (4GL) von CoSort als eigenständigen Berichtsgenerator oder als Staging-Tool zur Verarbeitung und Weitergabe großer Datenmengen verwenden.
SortCL kann nicht nur riesige Mengen unterschiedlicher Daten aus einer Vielzahl von RDBMS-Quellen, sequentiellen oder Indexdateien sowie Web- und verschiedenen Geräteprotokollen (einschließlich ASN.1 TAP3 CDRs) transformieren und schützen. Es kann diese Daten auch zusammenführen, aggregieren, berechnen und in benutzerdefinierten Detail- und Übersichtsberichtsformaten anzeigen, komplett mit speziellen Variablen und Tags für Webseiten.
Durch die Erstellung von Ausgaben im CSV- und XML-Format kann das SortCL-Tool von CoSort direkt in Tabellenkalkulationen wie Excel, Datenbanken, ETL-Tools und BI-Tools eingesetzt werden.
Sehr schnell! Die Leistung variiert je nach Quellgröße und -format, Daten- und Auftragsorientierung, Hardwarekonfiguration und Ressourcenzuweisung, gleichzeitiger Aktivität und Anwendungsoptimierung. Die besten Benchmarks (z. B. 1 GB in 12 Sekunden, 50 GB in 2 Minuten) laufen im Speicher auf schnellen Unix-Servern mit mehreren CPUs.
Wenn Sie einen Engpass erkennen, der je nach Ihrer Hardware bei 500K bis 50M Zeilen beginnen kann. CoSort sortiert routinemäßig im Terabyte-Bereich - und skaliert linear im Volumen ohne Hadoop. Eingabedateien im Bereich von Dutzenden oder Hunderten von Gigabytes sind heute üblich. Eine beliebige Anzahl von Eingabe- und Ausgabedateien - und strukturierte Dateiformate - werden gleichzeitig unterstützt, darunter Zeilen-, Satz- und variable sequentielle Dateien, blockierte Dateien, CSV, I-SAM, LDIF, XML (flat) und Vision. Eine Liste der unterstützten Datenquellen finden Sie hier.
CoSort ist jetzt auch die Standard-Engine in der IRI Voracity ETL-, BI/analytischen Datenvorbereitungs- und Datenmanagement-Plattform, die auch viele CoSort-Datentransformations- und Maskierungsaufträge (in SortCL 4GL-Syntax geskriptet und/oder grafisch in der IRI Workbench GUI dargestellt) nahtlos in Hadoop ausführen kann. Es stellt sich also die Frage, ab welchem Volumen ich solche Aufträge stattdessen über eine Hadoop-Engine ausführen sollte. Siehe unseren Artikel Wann Hadoop verwendet werden soll.
Wir verstehen das und beschleunigen schon seit Jahren Aufträge in älteren ETL-Tools (insbesondere Informatica- und DataStage-Transformationen). Um ETL- und BI-/Analyse-Tools von Drittanbietern sowie DB-Operationen zu beschleunigen, können Sie die skriptfähige(n), stapelverarbeitbare(n) Transformations-Engine(s) von IRI zusammen mit diesen Plattformen einsetzen - und so die Rendite Ihrer Investitionen in diese Plattformen steigern:
ETL-Werkzeuge:
BI-Werkzeuge:
Analytische Werkzeuge:
Datenbanken:
Führen Sie „SortCL“-Programmjobs im IRI CoSort-Paket oder in der IRI Voracity-Plattform über die Kommandozeilenoption (Shell) Ihres Tools aus, um Big Data schneller vorzubereiten und die DB-Tabellen oder Dateiformate aufzufüllen, die Ihr Tool direkt einlesen kann.
Nutzen Sie die gleichen hochleistungsfähigen Datenverarbeitungs-Engines, die auch Voracity nutzen kann: IRI FACT für die Extraktion, IRI CoSort (oder Hadoop) für die Datentransformation, IRI NextForm für die Daten/DB-Migration und Replikation, IRI FieldShield für die Datenmaskierung und/oder IRI RowGen für die Erzeugung von Testdaten.
Wenn Sie einen Engpass erkennen, der je nach Ihrer Hardware bei 500K bis 50M Zeilen beginnen kann. CoSort sortiert routinemäßig im Terabyte-Bereich - und skaliert linear im Volumen ohne Hadoop. Eingabedateien im Bereich von Dutzenden oder Hunderten von Gigabytes sind heute üblich. Eine beliebige Anzahl von Eingabe- und Ausgabedateien - und strukturierte Dateiformate - werden gleichzeitig unterstützt, darunter Zeilen-, Satz- und variable sequentielle Dateien, blockierte Dateien, CSV, I-SAM, LDIF, XML (flat) und Vision. Eine Liste der unterstützten Datenquellen finden Sie hier.
CoSort ist jetzt auch die Standard-Engine in der IRI Voracity ETL-, BI/analytischen Datenvorbereitungs- und Datenmanagement-Plattform, die auch viele CoSort-Datentransformations- und Maskierungsaufträge (in SortCL 4GL-Syntax geskriptet und/oder grafisch in der IRI Workbench GUI dargestellt) nahtlos in Hadoop ausführen kann. Es stellt sich also die Frage, ab welchem Volumen ich solche Aufträge stattdessen über eine Hadoop-Engine ausführen sollte. Siehe unseren Artikel Wann Hadoop verwendet werden soll.
CoSort beginnt mit der Verwendung mehrerer Threads, wenn das Sortiervolumen (Eingabedatei/Tabelle) mindestens zweimal so groß ist wie die in der CoSort Resource Control (cosortrc)-Datei angegebene BLOCKSIZE, die bei einem automatisch abgestimmten Auftrag normalerweise 1 bis 2 MB beträgt.
CoSort macht keinen Unterschied zwischen physischen CPU-Chips, CPU-Kernen oder Hyper-Threading. Wir versuchen nicht, das Gerät, auf dem ein Thread erstellt wird, im Detail zu steuern. Das Betriebssystem ist am besten in der Lage, zu bestimmen, wo neue Threads eingeplant werden sollen. CoSort erstellt lediglich die Sortier-Threads, und zwar bis zu der in der Tuning-Datei angegebenen Höchstzahl, die die von der Lizenz unterstützte Anzahl von Threads nicht überschreiten darf. Die Anzahl der Kerne ist in der Regel der beste Indikator für die zu erwartende Spitzenleistung vor dem Punkt des abnehmenden Nutzens, vorbehaltlich der Ressourcenkonkurrenz und des Amdahlschen Gesetzes.
Beachten Sie auch, dass jeder CoSort sortcl-Prozess unabhängig von allen anderen ist. Es findet keine Kommunikation oder Synchronisation zwischen den Prozessen statt, so dass in einer Umgebung mit mehreren gleichzeitigen Aufträgen die Angabe von nur 1 oder 2 maximalen Threads wahrscheinlich effizienter ist, selbst wenn jeder gleichzeitig laufende Auftrag ein hohes Volumen aufweist. Der Arbeitsspeicher passt sich jedoch selbst an, wenn MEMORY_MAX auf AUTO gesetzt ist.
Um eine unterschiedliche Anzahl von Threads zu testen, empfehlen wir Ihnen, über den normalen CoSort-Installations- und Registrierungsprozess (wie in der Installationsanleitung beschrieben) einen Lizenzschlüssel für einen vorübergehenden Zeitraum anzufordern, wobei Sie die Gesamtzahl der physischen Kerne auf dem Host-Rechner angeben. Sobald Sie die Lizenzschlüssel für diese Anzahl (bis zu 64) erhalten haben, führen Sie Aufträge mit verschiedenen THREAD_MAX-Werten (von 1 bis zum Höchstwert) in Ihrer cosortrc-Datei aus. Sie können auch mit speicher- und überlaufbezogenen Einstellungen experimentieren, um zu sehen, was am besten funktioniert.
Es gibt keine Möglichkeit festzulegen, welchen CPU-Kern die Threads verwenden sollen. Dies ist allein Sache des Betriebssystems. Wenn Ihr Betriebssystem dies unterstützt, können Sie versuchen, sortcl-Prozesse über die Systemeinstellung bestimmten Chips oder Kernen zuzuweisen.
Ja. Eine höhere BLOCKSIZE verbessert die Lese-/Schreibleistung, wenn sich die Quell- und Arbeitsdateien auf demselben Gerät befinden, andernfalls ist eine niedrigere BLOCKSIZE besser. Testen Sie mit verschiedenen Blockgrößen von 100K bis zu 16M. Denken Sie daran, dass bei großen, externen Sortierungen ein zu großer BLOCKSIZE zu unzureichendem Merge-Speicher führen kann.
CoSort-Benutzer können sich Laufzeitinformationen vor, während und nach der Ausführung anzeigen lassen:
Mittlerweile mehr als 150, Tendenz steigend. Dazu gehören Einzel- und Multi-Byte-Zeichensätze, Unicode, C, COBOL und Mainframe-Numerik. Wenden Sie sich an IRI, um eine Definition zu erhalten, wenn Sie nicht sicher sind, was Sie haben. Außerdem unterstützt CoSort das (gleichzeitige) Sortieren, Konvertieren und Erstellen von mehr als zwei Dutzend Dateiformaten.
SAS dokumentiert die CoSort-Option im System v7 und 8 für Unix, was sich in den SAS- und CoSort-Benutzerhandbüchern widerspiegelt. Die Verwendung von CoSort beschleunigt nachweislich die native SAS PROC-Leistung auf dem Mainframe drastisch und kostengünstig! In SAS wird die CoSort-Leistung automatisch oder über eine Ressourcensteuerungsdatei eingestellt, die bei der Einrichtung vom Systemadministrator konfiguriert wird. Diese Textdatei kann jederzeit als Referenz auf globaler, Benutzer- oder Job-Ebene geändert werden.
Für SAS 9 und spätere Versionen wenden Sie sich bitte an SAS, da sie ihr „Sortieranhängsel“ für CoSort bereits aktualisiert haben. IRI hat SAS wiederholt gebeten und angeboten, bei der Aktualisierung der CoSort-Verbindung zu helfen und den Benutzern eine bessere Option zu bieten. SAS hat uns jedoch mitgeteilt, dass Sie Ihre CoSort-Anfrage direkt an SAS richten müssen. Wenn Sie dies tun, benachrichtigen Sie uns bitte gleichzeitig, damit wir uns auch für Sie an SAS wenden können.
FieldShield, CellShield und DarkShield (sowie CoSort) und damit Voracity werden mit mehreren 128- und 256-Bit-Verschlüsselungsbibliotheken ausgeliefert, die bewährte, konforme 3DES-, AES-, GPG- und OpenSSL-Algorithmen verwenden. Für jedes PII-Element oder jeden Teilstring können Sie die gleiche oder eine andere integrierte Verschlüsselungsroutine verwenden oder eine Verknüpfung zu Ihrer eigenen Verschlüsselungsbibliothek herstellen und diese als benutzerdefinierte Transformationsfunktion auf Feldebene in einem Jobskript angeben. Sie können auch denselben Algorithmus bzw. dieselben Algorithmen und einen anderen Verschlüsselungsschlüssel für jedes Feld verwenden.
Die Verwaltung von Verschlüsselungsschlüsseln wird durch Passphrasen in Jobskripten, sicheren Dateien und Umgebungsvariablen sowie in Drittanbieter-Tresoren wie Azure Key Vault und Townsend Alliance Key Manager unterstützt.
Alle FieldShield- und CoSort/SortCL-Jobskripte und Funktionen auf Feldebene können in XML-Auditprotokollen aufgezeichnet werden, die Sie sichern und mit Ihrem bevorzugten XML-Berichtstool abfragen können. Sie können auch SortCL-Skripte (es werden Beispiele zur Verfügung gestellt, bei denen /INFILE=$path/auditlog.xml /PROCESS=XML usw.) gegen diese Audit-Protokolle für die Berichterstattung verwenden.
Ja, zum Beispiel an Splunk, und zwar auf verschiedene Weise. Siehe Artikel wie diesen:
Da es keinen „Voracity“-, „FieldShield“- oder „CoSort“-Server an sich gibt, gibt es derzeit keine Möglichkeit, Benutzer zu konfigurieren. Benutzer werden durch ihre Anmeldung entweder an dem PC identifiziert, auf dem sie IRI Workbench ausführen, oder an dem Remote-Server, der den Auftrag ausführt (d.h. auf dem SortCL installiert ist). In beiden Fällen kontrolliert das Betriebssystem (OS) den Benutzer, nicht die IRI-Software.
Wenn es um das Lesen und Schreiben von Dateien geht, bestimmt das Betriebssystem, wer auf der Grundlage des Benutzers, unter dem die Auftragsskripte ausgeführt werden, Zugriff auf Dateien hat. Bei Datenbanken werden die Benutzerkennung und die Kennwörter oder andere Anmeldeinformationen in die JDBC- und ODBC-Verbindungszeichenfolgen eingegeben, die für die Verbindung mit der Datenbank verwendet werden.
Die Workbench-Artefakte im Arbeitsbereich können auch geschützt werden, wenn sie über ein Git- oder ein anderes Quellkontroll-Repository freigegeben werden. Auf diese Weise kann mit Passwörtern oder Verschlüsselungsschlüsseln kontrolliert werden, wer die Job-Skripte, Metadaten-Dateien, Set-Dateien und andere Assets im Workspace lesen und schreiben darf.
Dies ist ein anderes Paradigma als bei den meisten anderen ETL- und Maskierungsprodukten, bei denen alle Datenbankverbindungen auf einem zentralen Server verwaltet werden. Unsere Architektur ist zwar etwas gewöhnungsbedürftig, vor allem, wenn man von einer anderen Art von Tool kommt, aber wir sind der Meinung, dass sie viel mehr Flexibilität im Betrieb bietet.
Unser zukünftiges Plattform-Release sieht ein noch granulareres System der Benutzer- und Daten-Governance vor, das RBAC für bestimmte IRI-Jobs, Funktionen und Datenklassen unterstützt. IAM- und Protokollierungsrichtlinien werden in IRI Workbench konfiguriert und von der ausführbaren Laufzeitanwendung durchgesetzt, um sicherzustellen, dass die Berechtigung zur Ausführung des Auftrags wie angegeben mit den Governance-Richtlinien und den angegebenen Benutzergruppen übereinstimmt und/oder mit ActiveDirectory oder LDAP integriert ist.
Wie sieht es mit dem Zugriff auf Aktivitätsprotokolldaten für Audits und Berichte aus?
Ja. Im Kontext von IRI Voracity, CoSort, FACT, NextForm oder IRI FieldShield und RowGen können Daten und Metadaten über Rollen getrennt werden:
Durch Zugriffskontrollen auf Client-Computern oder ActiveDirectory/LDAP und Berechtigungen auf Dateiebene. Darüber hinaus kann entweder die erwin (AnalytiX DS)-Governance-Plattform oder ein beliebiges Eclipse-kompatibles SCCS wie Git für Metadaten-Assets - bei dem Berechtigungen nach Rollen konfigurierbar sind - bestimmte Projekte, Jobs und andere Metadaten-Assets sperren.
Ja, im Kontext von IRI Voracity (für Profiling, ETL, DQ, MDM, BI, etc. ), CoSort (für Datentransformation), FieldShield (für PII-Erkennung und -Maskierung), NextForm (für Datenmigration, Remapping und Replikation) und RowGen (für TDM und Subsetting) kann der Zugriff auf bestimmte Datenquellen (und Ziele, bis hinunter zur Spaltenebene) durch vom DBA erteilte Berechtigungen oder Berechtigungen auf Dateiebene (verwaltet in DSN-Dateien und der IRI Workbench-Datenverbindungsregistrierung) sowie durch Offenbarungsberechtigungen auf Feldebene, die in (sicherbaren) Jobskripten und Entschlüsselungsschlüsseln gesteuert werden, kontrolliert werden.
Im Zusammenhang mit der optionalen proxy-basierten DDM SQL#-Anwendung für FieldShield können Einzel- und Gruppenrollen mit granular definierten Sicherheitsrichtlinien abgeglichen werden, die das Recht bestimmen, sich mit bestimmten DB-Instanzen zu verbinden, bestimmte SQL-Anweisungen auszuführen, Spalten dynamisch zu maskieren (oder nicht), usw.
Prüft IRI-Software unabhängig, wer der Endbenutzer ist, der versucht, auf geschützte Daten zuzugreifen, oder verlässt es sich auf die zugrunde liegenden Datenbank- oder Anwendungszugriffskontrollen?
Beides, da der Zugriff auf Daten, Metadaten und/oder Jobskripte - sowie die Ausführungserlaubnis - mit objektdefinierten ActiveDirectory-, DBA-Login- und/oder Dateisystem-Kontrollen verbunden ist, die auf einer Richtlinienbasis zu Authentifizierungszwecken auferlegt werden.
IRI bietet auch eine optionale proxy-basierte dynamische Datenmaskierung, die abgefragte Spaltenwerte gemäß spezifischer Richtlinien, die einzelne Benutzer, Benutzerrollen oder Benutzergruppen betreffen, unkenntlich machen kann.
Die aufrufenden Anwendungen können auch zusätzliche Ebenen der Benutzerauthentifizierung einführen, um optional eine Lücke zu schließen oder zusätzliche Datenkontaktpunkte zu schützen.
