Häufige Fragen (FAQ)

Ausgewählte Fragen und Antworten rund um die IRI-Datenmanagement- und Datenschutz-Software, die JET-Software im deutschsprachigen Raum betreut.

BI & Analytik

IRI Voracity bietet Analysefunktionen auf fünf Arten, mit zwei weiteren, die für 2019 vorgesehen waren:

1) Eingebettetes Reporting und Analyse – über CoSort-SortCL-Programme, die benutzerdefinierte Detail-, Zusammenfassungs- und Trendberichte in 2D-Formaten erstellen, komplett mit Querberechnungen und weiteren integrierten Funktionen für Datentransformation, Neuzuordnung, Maskierung und Formatierung. Die Berichte können deskriptiv sein oder – durch Fuzzy-Logik und Funktionen wie Standardabweichung sowie Boost-gestützte statistische und BIRT-gestützte lineare Regressionsgraphen – prädiktiv.

2) Integration mit BIRT in Eclipse – wobei zur Berichtszeit die von Ihnen entworfenen BIRT-Diagramme über die ODA-Unterstützung mit „IRI-Datenquellen“ aus der Voracity-/CoSort-SortCL-Ausgabe befüllt werden. Das Besondere: Die Datenaufbereitung läuft erst, wenn der Bericht angefordert wird – das spart Zeit und Ressourcen, da die Daten außerhalb der BI-Schicht (mit CoSort- oder Hadoop-Engines) aufbereitet werden.

3) Datenaufbereitung („Franchising“), die die Time-to-Visualization für 10 BI-/Analyseplattformen von Drittanbietern beschleunigt. Benchmarks zeigen, dass SortCL allein schneller ist als BOBJ, Cognos, Microstrategy, QlikView, Splunk, Spotfire, R und Tableau.

4) Ein direktes Voracity-Add-on für Splunk, um Daten zur Analyse an Splunk zu übergeben.

5) Integration mit einem Cloud-Dashboard von DWDigest für interaktive BI, anpassbar und in jedem Browser nutzbar – auch im internen Browser der IRI-Workbench-GUI.

6) Streaming-Analytik (ausstehend) über JupiterOne – Voracity als Quelle Kafka-gespeister Datenströme oder als Ziel für Live-Sentiment-Analysen.

7) Integration mit der KNIME Analytics Platform in der IRI-Workbench-IDE, damit Citizen Data Scientists mit Machine Learning, KI, neuronalen Netzen und unstrukturierten Daten über sich hinauswachsen.

Mehr dazu unter BI & Analytik.
Das kann es sein. CoSort bietet eine Reihe von Lösungen, um aus riesigen Datenmengen aussagekräftige Berichte zu erzeugen. Sie können das SortCL-Programm (4GL) als eigenständigen Report-Generator nutzen oder als Staging-Werkzeug zum Verarbeiten und Weiterreichen großer Datenmengen. SortCL transformiert und schützt riesige Mengen heterogener Daten aus verschiedensten RDBMS-Quellen, sequenziellen oder Index-Dateien sowie Web- und Geräteprotokollen (inkl. ASN.1-TAP3-CDRs). Es kann diese Daten auch verknüpfen, aggregieren, berechnen und in Detail- und Zusammenfassungsberichten darstellen – komplett mit speziellen Variablen und Tags für Webseiten. Über die Ausgabe in .CSV und .XML befüllt SortCL direkt Tabellen wie Excel, Datenbanken, ETL- und BI-Tools. Siehe auch BI & Analytik.
Grundsätzlich alle Tools, die CSV-, flache XML-Dateien oder RDBMS-Tabellen importieren können. Die Aufgabe der IRI-Software ist es, große, strukturierte Daten zentral aufzubereiten („zu wrangeln“). Nutzer erstellen SortCL-Programme in 4GL-Skripten – oder per Assistent in der kostenlosen IRI-Workbench-GUI (Eclipse™) –, die Daten aus über 125 Quellen transformieren (filtern, sortieren, verknüpfen, aggregieren, maskieren/verschlüsseln, pivotieren, vorberechnen …). SortCL/Voracity befüllt direkt: SAP Business Objects, IBM Cognos, DI-Diver, DWDigest, iDashboards, Microstrategy, Oracle DV/OBIEE sowie neuere Plattformen wie Knime, Power BI, QlikView, R, Splunk, Spotfire, Tableau. Dazu ODA-Treiber-Unterstützung für BIRT, ein Splunk-Add-on, das DWDigest-Cloud-Dashboard und geplante Kafka-Feeds an KNIME/JupiterOne. Mehr unter BI & Analytik.

CoSort & kompatible IRI-Produkte – Installation

Die Installation von IRI Voracity und seinen Komponenten- (oder Einzel-)Produkten – IRI CoSort, NextForm, RowGen, FieldShield und DarkShield – erfordert eine Backend-Installation des CoSort-Pakets sowie die Lizenzierung des ausführbaren SortCL-Programms, das all diese Jobs auf Windows-, Linux-, macOS-, AIX-, Solaris- oder HP-UX-Systemen ausführt. Die grafische IRI-Workbench-Oberfläche (auf Eclipse-Basis) ist eine optionale Installation für Windows, Linux und macOS und liegt der Windows-Version von CoSort bei. Workbench unterstützt auch IRI Fast Extract (FACT); FACT erfordert eine separate Installation und Lizenz. Die Installationsschritte für alle genannten Produkte – einschließlich der COBOL-Edition von NextForm – sind in der Installationsanleitung dokumentiert. Separate Installationsanweisungen für die Voracity-, CoSort-, FieldShield-, DarkShield- und RowGen-APIs sowie für die proxybasierte DDM-Option von FieldShield sind auf Anfrage erhältlich (Kontakt).
IRI kann einen CoSort-Build liefern, der entweder als feste oder als schwebende Lizenz funktioniert. Die Standardversion ist eine FESTE Lizenz, die nicht abläuft, an einen bestimmten Hostnamen gebunden ist und eine hostnamenspezifische Registrierung erfordert (RegForm.txt-Formular). Alternativ liefern wir eine andere Version mit einer speziellen cosort.lic-Datei für eine SCHWEBENDE Lizenz, die ablaufen muss, weil sie nicht an einen bestimmten Hostnamen gebunden ist – typisch (aber nicht zwingend) für Cloud-Installationen. Die Entscheidung ist also keine Frage von On-Premise vs. Cloud, sondern davon, wie häufig sich Hostnamen ändern. Welche Version Sie haben, erkennen Sie am „build“-Tag: Beim Ausführen von $COSORT_HOME/bin/sortcl /v sehen Sie R für fest (fixed) oder F für schwebend (floating).
Praktisch alle CoSort-Versionen der letzten 20+ Jahre unterstützen RHEL auf allen 32- und 64-Bit-Intel-kompatiblen Systemen (siehe Plattformen & Preise). Die aktuelle Version CoSort v10.5 ist auf RHEL 7 und 8 portiert und läuft auch auf 9 sowie künftigen RHEL-Versionen. Ports für z/Linux sind verfügbar, aufgrund geringerer Nachfrage aber evtl. nicht so aktuell. Für ältere, nicht mehr unterstützte Versionen wie 9.x nutzt IRI die von Red Hat mit neueren RHEL-Versionen gelieferten Kompatibilitätsbibliotheken.
Nein. Sie benötigen lediglich einen Datenbank-Login mit ausreichenden Rechten, um Daten und Metadaten für die gewünschte Operation zu lesen bzw. zu schreiben. Um Daten aus einer Tabelle zu lesen und in eine Datei zu schreiben, genügen Leserechte. Um eine neue Tabelle zu erstellen und Daten einzufügen, sind mehr Rechte nötig. Um Daten zu lesen und die Zeilen anschließend per UPDATE direkt zu ändern, ist wiederum ein anderer Satz an Berechtigungen erforderlich.
Die IRI Workbench ist die Eclipse-Oberfläche (grafischer Job-Design-Client) und läuft auf Windows, Linux und macOS. Das Backend-Programm SortCL im CoSort-Paket / in der Voracity-Plattform – die Engine für Datenmanipulation, Mapping, Aufbereitung, Maskierung und Mining – läuft auf all diesen Systemen plus allen Unix-Varianten (AIX, Solaris, HP-UX, z/i/pSeries-Linux). Da SortCL das Backend und die Workbench das Frontend mehrerer IRI-Produkte ist, gilt diese Antwort nicht nur für CoSort (Sortierung) und Voracity (ETL usw.), sondern auch für FieldShield, RowGen, NextForm und DarkShield.

Das absolute Minimum für reine CoSort/SortCL-CLI-Operationen sind 40 MB RAM, empfohlen werden aber mindestens 512 MB–2 GB pro CoSort-Nutzer. Sortierjobs, die vollständig in den Arbeitsspeicher passen, sind meist schneller – moderne CoSort-Hosts werden oft mit 64 GB–2 TB RAM konfiguriert, um ohne den I/O-Overhead von Arbeitsdateien zu sortieren. Für die Workbench sind mindestens 4 GB RAM und 10 GB freier Speicher nötig (nach Installation von VMs, DBs usw.); ein JRE ist enthalten. Für viele Datenbankverbindungen und das Parsen von Metadaten sind 6 GB und mehr besser; bei Schemata mit hunderten Tabellen können bis zu 64 GB RAM sinnvoll sein.

Wir empfehlen, das lizenzierte Backend (SortCL) möglichst auf demselben System wie Ihre Datenbankquelle/-ziel oder in unmittelbarer Netzwerknähe zu betreiben – besonders bei bekannten Netzwerk-Engpässen. Bei Datenmaskierung (FieldShield, DarkShield) und Testdaten-Generierung (RowGen) liegt der Engpass meist bei Netzwerk und I/O: Das Maskieren, Subsetten oder Synthetisieren dauert etwa so lange wie das reine Lesen/Schreiben Ihrer Daten. Auch deshalb ist eine Colocation auf demselben System bzw. ein optimales I/O-Subsystem (Fibre Channel, SSD, Multi-Core) empfehlenswert. Als Faustregel gilt: mehr RAM = bessere Performance.
Für eine EC2-Linux-Instanz, die nur die Job-Skripte ausführt, sollte eine t2.small oder t2.medium genügen. Für eine Windows-Instanz, die sowohl Job-Design als auch Laufzeit übernimmt, ist eine t2.large oder sogar t2.xlarge besser. t3-Instanzen derselben Konfiguration sind manchmal günstiger, erfordern aber oft teureren Speicher.
Ja. Das unterscheidet sich nicht von der Installation von CoSort auf einem Unix-Server für mehrere Nutzer. Auch die Installation von Cygwin mit SSH-Zugang für die Nutzer würde gut funktionieren. Der Knackpunkt bei diesem Ansatz ist der Zugriff auf die Ein-/Ausgabe-Datenströme – diese müssten Netzwerkressourcen sein, was die Laufzeiten deutlich verlangsamen kann.
Die Kommandozeilen-Tools der Voracity-Plattform / des CoSort-Pakets (z. B. sortcl-kompatible und *2ddf-Programme) sowie der DarkShield-Webservice laufen problemlos in Docker oder anderen Containern. Die Konfigurationsanforderungen sind dieselben wie bei traditioneller Nutzung. Der Container benötigt einen konsistenten Hostnamen, damit die klassische IRI-Lizenzierung funktioniert – andernfalls lassen sich andere Vereinbarungen treffen. Die erforderlichen Dateien, insbesondere eine feste oder schwebende Lizenzdatei, müssen in $COSORT_HOME/etc vorliegen und die Umgebungsvariable exportiert sein. Da keine Netzwerkschnittstelle zum Ausführen von Jobs verfügbar ist, muss ein Mechanismus zum Auslösen des Kommandozeilenaufrufs konfiguriert werden; alternativ kann ein SSH-Daemon (sshd) im Container laufen. Die IRI Workbench und bestimmte aufrufende Programme (Glue-Code) müssen ggf. außerhalb des Containers laufen.
Sie können die Workbench mit folgendem Befehl aus dem Tarball entpacken:
tar -xzvf com.iri.pelican.workbench-linux.gtk.x86_64.tar.gz -C ${destination_directory}
Ersetzen Sie „${destination_directory}“ durch Ihr gewünschtes Zielverzeichnis. Anschließend starten Sie die Workbench, indem Sie die Datei iri-workbench im Zielverzeichnis ausführen. Wo der Tarball entpackt wird, entscheidet der Nutzer bzw. die Sysadmin-Richtlinie. Wir empfehlen, das Paket pro Nutzer nach $HOME/iri/workbench2/ zu entpacken. Für die ausführbare Datei kann eine Desktop- oder Menüverknüpfung erstellt werden.

CoSort – Installationsprobleme

Das CoSort-Paket mit der ausführbaren Datei sortcl muss auf dem System installiert sein, das das Batch-Skript ausführt. Da das Batch-Skript nicht den vollständigen Pfad zur sortcl-Datei enthält, muss dieser Pfad in der Umgebungsvariable PATH stehen. Beispiel für CoSort 10.5 unter Windows: Stellen Sie sicher, dass der Ordner C:\IRI\cosort105 existiert, die Variable COSORT_HOME darauf zeigt und die Variable PATH den Wert %COSORT_HOME%\bin enthält.
Stellen Sie unter Windows 10/11 sicher, dass Sie Bearbeiten-Rechte (nicht nur Schreibrechte) für die Datei C:\IRI\CoSort105\etc\cosort.lic haben. Ohne diese kann das Setup-Programm den 3-teiligen Lizenzschlüssel nicht mit den Werten aktualisieren, die Sie über die Kommandozeile oder das IRI-Workbench-Setup (Option „Update License“) eingegeben haben. Ggf. müssen Sie die Werte von Hand eintragen und die Standardwerte 0.0.0 ersetzen. Unter Windows 2003 prüfen Sie zunächst, ob die eingegebenen Lizenzschlüssel zum aktuellen (richtigen) Private Key in Ihrer RegForm.txt gehören. Falls ja, wurde die Registry nicht korrekt aktualisiert – öffnen Sie das Installationsverzeichnis und führen Sie global_config.reg und license.reg per Doppelklick aus.
CoSort-Seriennummern werden jedem neuen Versions-Build zugewiesen, den Sie für ein bestimmtes Betriebssystem an einem betreuten Standort installieren, und dürfen nur auf mehreren Hostnamen genutzt werden, die beide Kriterien erfüllen. Sie können also dasselbe Installationsarchiv (mit dieser S/N) auf weiteren Rechnern mit derselben Version am selben Standort verwenden. Unterschieden werden diese Lizenzen über den Hostnamen und den Private-Key-Wert in jeder neuen RegForm.txt, die Sie für Lizenzschlüssel einreichen.
Prüfen Sie den LOG-Datei-Eintrag in $COSORT_HOME/etc/cosortrc. Bei v8.2.1 achten Sie darauf, dass der Pfad kein %s enthält. Sie (und alle CoSort-Nutzer) benötigen Lese- und Schreibrechte für die LOG-Datei (Standard: $COSORT_HOME/etc/cosort.log) und die Überlauf-Verzeichnisse (WORK_AREA).

Data Governance – Daten-/Metadaten-Forensik & RBAC

Ja, auf mehrere Arten: Zugriffsrechte auf Job-Metadaten, Datenquellen (und -ziele), Entschlüsselungsschlüssel sowie über differenzierte Datenklassen-Funktions-/Regelzuweisungen. Siehe die weiteren Fragen in diesem Abschnitt; für Unterstützung beim Einrichten Ihrer Kontrollen kontaktieren Sie uns.
Da es keinen eigenen „Voracity“-, „FieldShield“- oder „CoSort“-Server gibt, existiert derzeit kein zentraler Ort zur Benutzerkonfiguration. Nutzer werden über ihren Login am PC (auf dem die IRI Workbench läuft) oder am Remote-Server (auf dem der Job/SortCL läuft) identifiziert. In beiden Fällen steuert das Betriebssystem den Nutzer. Beim Lesen/Schreiben von Dateien entscheidet das OS anhand des Nutzers, unter dem die Job-Skripte laufen. Für Datenbanken werden Zugangsdaten in den JDBC-/ODBC-Verbindungsstrings hinterlegt. Workbench-Artefakte im Workspace lassen sich zusätzlich schützen, wenn sie über Git versioniert werden. Die neueste Plattform (OGS in CoSort 11) unterstützt eine noch granularere Governance per RBAC für einzelne Jobs, Funktionen und Datenklassen; eine künftige Web-UI wird IAM- und Logging-Richtlinien (integrierbar mit Active Directory oder LDAP) ermöglichen.
Ja. Bei Voracity, CoSort, FACT, NextForm sowie FieldShield und RowGen lassen sich Daten und Metadaten rollenbasiert trennen: über DBA-definierte Quell-/Zielzugriffe (in DSN-Dateien bzw. der Workbench-Datenverbindungs-Registry, geschützt durch Workspace-/OS-Rechte), über Active Directory (bzw. Entra ID) oder LDAP sowie repository-gesteuerten Zugriff (z. B. Git) auf Dateien, Workspaces, Projekte, Metadaten, Executables und Logs, oder auf FieldShield-/DarkShield-Schlüssel (z. B. Azure Key Vault). Das 2026 eingeführte IRI Operational Governance System (OGS) konzentriert sich zunächst auf die Backend-Engine SortCL und nutzt eine zentrale Policy-Datei, um Nutzer, Gruppen und Rollen für job-spezifische Attribute zu definieren. 2027 folgt ein browserbasiertes Frontend mit SSO.
Über Zugriffskontrollen des Client-Rechners bzw. von Active Directory/LDAP und über Dateisystem-Rechte. Darüber hinaus können die erwin-(AnalytiX DS)-Governance-Plattform oder jedes Eclipse-kompatible Versionskontrollsystem wie Git bestimmte Projekte, Jobs und Metadaten rollenbasiert sperren.
Ja. Mehrere Rollen/Rechte für FieldShield- oder Voracity-Metadaten (DDF, Job-Skripte, Flows) lassen sich zuweisen, indem Administratoren policy-gesteuerte Active-Directory-/LDAP-Objekte an diese Assets binden. Weitere Optionen sind die erwin-Data-Governance-Plattform (Premium) oder Git. Auch der IRI Test Data Hub im ValueLabs-TDM-Portal unterstützt Administrator- und Tester-Rollen. Rechte werden sehr feingranular auf Einzel- oder Gruppenebene gesetzt (DB-Login, Ausführung, Datenzugriff, Audit-Log-Abfrage/-Report).
Ja. Bei Voracity (Profiling, ETL, DQ, MDM, BI), CoSort (Transformation), FieldShield (PII-Erkennung/-Maskierung), NextForm (Migration/Replikation) und RowGen (TDM, Subsetting) lässt sich der Zugriff auf Quellen und Ziele bis auf Spaltenebene über DBA- oder Datei-Rechte (DSN-Dateien, Workbench-Registry) steuern, ebenso über feldbezogene Aufdeckungs-Berechtigungen in gesicherten Job-Skripten und Entschlüsselungsschlüsseln. Bei DarkShield wird der Zugriff auf relationale/NoSQL-Datenbanken über verbindungsspezifische Konfigurationen (JDBC-Treiber, API-Keys) beschränkt; Dateiquellen unterliegen lokalen OS- oder Cloud-API-Key-Rechten.
Beides: Zugriff auf Daten, Metadaten und Job-Skripte – plus Ausführungsrechte – sind mit Active-Directory-Objekten, DBA-Logins und/oder Dateisystem-Kontrollen verknüpft, die policy-basiert zur Authentifizierung durchgesetzt werden. Aufrufende Anwendungen können zusätzliche Authentifizierungsschichten einziehen.

Flat Files (flache Dateien)

Neben den vielen Data-Warehouse-Architekten, die das SortCL-Tool von CoSort nutzen und seinen Flat-File-Ansatz schneller finden als SQL-Prozeduren und ETL-Tool-Schritte, betonen auch Experten die Effizienz flacher Dateien beim Staging großer Datenmengen: „Das erste System, für das das Data Warehouse verantwortlich ist, ist der Data-Staging-Bereich, in dem Produktionsdaten aus vielen Quellen eingebracht, bereinigt, vereinheitlicht, kombiniert und schließlich an die Präsentationssysteme geliefert werden … Die zwei dominierenden Datenstrukturen im Staging-Bereich sind die flache Datei und das Entity-/Relationship-Schema.“ – Ralph Kimball, „The Foundations for Modern Data Warehousing“, Intelligent Enterprise Magazine.
Durch flache Dateien umgeht das SortCL-Programm – das Hauptwerkzeug von IRI CoSort und die Standard-Engine der IRI-Voracity-Plattform – den üblichen Overhead von DB-Anbindung und -Transformationen. SortCL flacht sogar per ODBC angebundene Tabellen und semi-strukturierte Quellen wie MongoDB und JSON-Dateien ab. So bewegt sich die Engine sequenziell und konsistent durch die Datenzeilen und nutzt gleichzeitig asynchrones I/O, fortgeschrittenes Speichermanagement und mehrere Threads des Betriebssystems (ohne Java-Programme). Die flache Struktur erlaubt es, Datentransformation, Reporting, Schutz und Prototyping im selben Job und I/O-Durchgang zu kombinieren: Sie können riesige Datenmengen gleichzeitig filtern, bereinigen, standardisieren, transformieren, maskieren und darüber berichten. Also „ein Produkt, ein Ort, ein Durchgang“ statt der Komplexität, Kosten und Zeit konkurrierender Ansätze (mehrere Produkte, Orte, Durchgänge und Preise).
Über das SortCL-Programm nutzen Anwender von IRI CoSort oder IRI Voracity die Ressourcen ihrer bestehenden Dateisysteme – ohne den Overhead und die Einschränkungen von Datenbanken und SQL-Prozeduren und ohne die Kosten von Megavendor-ETL-Tools, ELT-Appliances, In-Memory-DBs oder komplexen Apache-Projekten. Mit SortCL lassen sich viele Aufgaben gleichzeitig gegen beliebig große Quellen ausführen und kombinieren: Datentransformation (Select, Sort, Merge, Join, Aggregation, Re-Map, Pivot, Querberechnung), Datenbereinigung, Data Governance (Stammdaten maskieren/verwalten, Metadaten, Datenqualität), Datenmigration, Datenreplikation, Data Federation, Datenmaskierung (De-ID, Verschlüsseln, Hashing, Pseudonymisieren, Randomisieren, Schwärzen, Tokenisieren), Datenpräsentation (2D-BI-Berichte), Data Franchising (CSV/XML/ODBC für BI-Tools), Data Staging und Prototyping (sichere Testdaten). Für Verarbeitung, Präsentation, Schutz und Prototyping großer Daten sind SortCL und flache Dateien weiterhin der schnellste, kosteneffizienteste Weg. Wenn Ihre Daten in HDFS liegen, laufen viele dieser Funktionen über Voracitys Hadoop-Gateway („VGrid“) auch in MapReduce 2, Spark, Spark Stream, Storm oder Tez – ohne Neuprogrammierung.

Job-Überwachung, Wiederherstellung & Protokollierung

Wenn Sie Voracity-Jobs unter Windows, Linux oder Unix mit dem Standard-CoSort/SortCL-Programm ausführen, kann diese ausführbare Datei Ereignis- bzw. Statusmeldungen an die (CLI- oder GUI-)Konsole senden – in verschiedenen Ausführlichkeitsstufen. Führen Sie Voracity-Jobs in Hadoop (MR2, Spark, Storm, Tez) aus, zeigt das HDFS-Job-Inventar den Status an.
In Hadoop erfolgt dies unseres Erachtens automatisch. Standard-CoSort/SortCL-Ausführungen erlauben ein Pause/Resume nur bei unzureichendem Platz für die Überlauf-(Temp-)Dateien.
Es werden mehrere Logs erzeugt: SortCL-App-Statistiken, Fehler-Logs und eine sich selbst fortschreibende Laufzeit-Performance-Datei. Optional wird pro Lauf eine XML-Audit-Log-Datei erzeugt, die den Skriptinhalt und Umgebungsdetails zeigt.

Stammdaten (Master Data)

Der neue Data-Unification-Assistent von IRI Voracity folgt dem Konsolidierungsstil des MDM und erlaubt es, neue Stammwerte per Fuzzy-Matching zu vergleichen, abzugleichen und zu gruppieren. Alternativ verschieben Sie die Stammdaten manuell an einen zentralen Ort/Metadaten-Repository, wo sie leichter zu bereinigen und zu verwalten sind. Definieren Sie Dateien und Felder im SortCL-lesbaren Format und suchen Sie nach Namens-/Attribut-Diskrepanzen. Erstellen Sie SortCL-Jobs, um diese Dateien zu integrieren und zu standardisieren, und nutzen Sie feldbezogene Transformationsfunktionen, um die Daten nach Ihren Geschäftsregeln zu bereinigen. Anschließend können Sie die Stammdaten-Tabellen bei Bedarf neu befüllen.
Das SortCL-Tool von CoSort kann die nötigen Sicherheitsfilter anwenden, um Ihre Need-to-know-Regeln durchzusetzen und bestimmte gefährdete Dateidaten vor der Weitergabe zu verschlüsseln und zu anonymisieren. Maskieren Sie Ihre Stammdaten auf Feldebene, wenn Sie sie testen, auslagern oder verschiedenen Abteilungen zugänglich machen müssen – und lassen Sie weniger sensible Daten weiterhin zugänglich.
Alle CoSort-(SortCL-)Skripte (ob für Transformation, Reporting, Schutz oder Prototyping) werden geparst und mit Laufzeitinformationen in Audit-Logs gespeichert, die Sie mit Ihrer bevorzugten XML-Anwendung oder mit SortCL selbst absichern und abfragen können.
Das SortCL-Programm in IRI CoSort kann bestimmte hierarchische Daten – auch Mainframe-Index-Dateien – abflachen und für DB-Ladevorgänge und BI-Tools aufbereiten. SortCL kann Produktdaten mit Kundentransaktionen (und andere Dateien über gemeinsame Schlüssel) verknüpfen und benutzerdefinierte Berichte ausgeben, inkl. Aggregation und Querberechnung. SortCL kann zudem feldbezogene Lookups durchführen und neu formatierte Dateien befüllen.

Benutzerdefinierte Transformationen

Auf Feldebene können Sie keine benutzerdefinierten Transformationen einbinden, die Informationen auf Dateiebene (z. B. Statistiken) benötigen. SortCL unterstützt jedoch bereits Aggregation auf Datei- und Datensatzebene sowie Querberechnung für Detail- und Zusammenfassungsberichte.
SortCL übergibt die Felddaten an die Routine, die sie im transformierten Zustand zurückgibt – formatiert gemäß den übrigen Attributen der Ausgabefeld-Beschreibung.
Schreiben oder lizenzieren Sie eine Bibliothek und geben Sie sie am Anfang eines SortCL-Job-Skripts an (das auch in einem thread-sicheren API-Aufruf verwendet werden kann). In der /INREC- oder /OUTFILE-Phase des Skripts definieren Sie die Bibliothek als Feldattribut.

Support

Als deutschsprachiger IRI-Partner unterstützt Sie JET-Software direkt – schreiben Sie eine aussagekräftige E-Mail an info@jet-software.com, nutzen Sie das Kontaktformular oder rufen Sie uns unter +49 6073 711 403 an.
Eine Liste häufiger technischer Fragen zu Installation und Konfiguration steht Kunden mit Wartungsvertrag im geschützten Support-Bereich zur Verfügung. Viele technische und How-to-Antworten erhalten Sie darüber hinaus jederzeit über JET-Software.

Synthetische Testdaten (RowGen)

Ja – all das und mehr. Bemerkenswert: RowGen kann all diese Ziele sogar gleichzeitig aus derselben Quelle synthetisch generierter (oder maskierter) Daten erzeugen, inklusive Detail- und Zusammenfassungsberichten mit jeweils eigener Formatierung.
Die Preise für RowGen v3 beginnen deutlich unter 10.000 $ für den Dauereinsatz und steigen proportional mit zusätzlichen CPU-Kernen, die Sie nutzen möchten. Die Wartung ist im ersten Jahr kostenlos und danach 15–20 % der Lizenzgebühr, je nach Upgrade-Umfang. (Für ein Angebot im DACH-Raum wenden Sie sich an JET-Software.)
Es liest gängige Datenmodell- und Datei-Layout-Metadaten, um die Testdaten-Zeilen in präzise Flat-File-, Report- und Datenbanktabellen-Strukturen zu formen, und bewahrt dabei die referenzielle Integrität. RowGen ist eine Komplettlösung für Testdaten: gleichzeitig große Mengen parallel generieren, eigene Regeln/Wertebereiche anwenden, DB-Datenmodelle und Metadaten nutzen, Realismus und Beziehungen bewahren, transformieren/segmentieren/berichten, in benutzerdefinierten Datei-Layouts formatieren und Jobs zur Konformitätsprüfung auditieren.

DW-ETL-Operationen

Voracity ist eine moderne All-in-One-Plattform, um Unternehmensdaten schnell zu verwalten und zu nutzen. Es ist zugleich ein eigenständiges ETL- und Data-Lifecycle-Management-Produkt, das viele Formen von Big Data in Produktion sowie Testdaten für DevOps aufbereitet, schützt und bereitstellt. Voracity spart Kosten bei Software, Hardware und Beratung und erweitert Ihr Enterprise Information Management (EIM) – alles aus einer Eclipse-Oberfläche. Mehr über Voracity.
Alle unten genannten Funktionen werden von der IRI-Voracity-Plattform und den enthaltenen Suiten IRI Data Manager und IRI Data Protector unterstützt (außer FACT, das unterstützt wird, aber als Premium-Option). Siehe die Komponenten. „GUI“ bezeichnet die IRI Workbench – eine kostenlose Eclipse-basierte Entwicklungsumgebung (IDE) zum Entwerfen und Verwalten der Jobs, die Daten über das SortCL-Programm in Voracity, IRI CoSort und aller anderen IRI-Software integrieren und transformieren. „DTP“ ist das Data Tools Plugin (Data Source Explorer) in der Workbench, „DDF“ sind die Data Definition Files (Metadaten der Quell-/Ziel-Datenlayouts).
Verstehen wir – und genau das tun wir seit Jahren, indem wir Jobs in bestehenden ETL-Tools (v. a. Informatica- und DataStage-Transformationen) beschleunigen. Nutzen Sie die skript- und batchfähige Transform-Engine von IRI parallel zu diesen Plattformen, um ETL-, BI-/Analyse-Tools und DB-Operationen zu beschleunigen. Unterstützte Tools u. a.: ETL (ETI Solution, IBM DataStage, Informatica PowerCenter, Microsoft SSIS, Oracle Data Integrator, Pentaho, Talend), BI (BIRT, BOBJ, Cognos, Excel, MicroStrategy, QlikView, OBIEE), Analytik (JupiterOne, R, SAS, SpotFire, Splunk, Tableau) und Datenbanken (DB2, Greenplum, MySQL, Oracle, SQL Server, Sybase, Teradata). Rufen Sie SortCL-Jobs (im CoSort-Paket oder in Voracity) aus der Kommandozeile Ihres Tools auf, um Big Data schneller aufzubereiten und die Tabellen/Dateiformate zu befüllen, die Ihr Tool direkt einliest. Nutzen Sie dieselben Hochleistungs-Engines wie Voracity: FACT (Extraktion), CoSort/Hadoop (Transformation), NextForm (Migration/Replikation), FieldShield (Maskierung) und RowGen (Testdaten).
Ja. Voracity ist per API mit der AnalytiX-DS-Metadaten-Hub-Technologie integriert, sodass Sie von Alt-ETL-Produkten weitgehend automatisch und kostengünstig migrieren können. Fragen Sie nach CATfx-Templates für Voracity aus Ihrem aktuellen ETL-Tool sowie nach LiteSpeed-Conversion-Diensten für komplexere Mappings. Egal ob Plattformwechsel oder Einstieg in die Datenintegration – Voracity verkürzt Time-to-Deployment und Informationsbereitstellung. (ETL-Replatforming)
Einige Dinge, die Voracity gegenüber Alt- und Open-Source-ETL (erst recht ELT) bietet: eingebaute Daten-Profiling-Tools für Flat-Files, Datenbanken und Dark Data; hohe Leistung und Skalierbarkeit mit oder ohne Hadoop; eine minimale Lernkurve durch einfache, offene Text-Metadaten; das Ausführen von Jobs außerhalb der GUI (Kommandozeile, Batch, per System-/API-Aufruf); eine bekannte Open-Source-GUI (Eclipse); fortgeschrittene Aggregation (Lead/Lag, Ranking, Running, Ausdrücke); mehrfach verschachtelte Bedingungen und abgeleitete Felder mit PCRE, Fuzzy-Matching und C-Funktionen; Composite-Datenwert-Definition für Format-Maskierung und Testdaten; eingebaute Migration, Replikation, Maskierung (12 Schutzfunktionen), DB-Subsetting und referenziell korrekte Testdaten; CDC, Slowly Changing Dimensions sowie Detail-, Summen-, Trend- (predictive) und Clickstream-Reporting; nahtlose Metadaten-Integration mit FACT, Hadoop, AnalytiX DS und MIMB; sehr gutes Preis-Leistungs-Verhältnis und schnellen US-Entwickler-Support. Anders betrachtet – mit Voracity entfällt der Bedarf an: separaten Transformationsstufen (alles in einem Job/I/O-Durchgang), Partitionierung (automatisches Multithreading), manueller Metadaten-Definition (automatische Erkennung + CATfx/MIMB), separaten BI-Tools (Berichte im selben Durchgang), separaten Maskierungs-Tools (enthält FieldShield), separaten Testdaten-Tools (enthält RowGen), langfristiger Beratung (vertraute Eclipse-GUI), separaten MDM-/DQ-Hubs (MDM-Assistent) und einem neuen Team-/Versionskontroll-Paradigma (funktioniert mit Git, CVS, SVN, AnalytiX DS). Zudem: gestützt von IRI, einem stabilen Unternehmen mit über 40 internationalen Niederlassungen; erhältlich zu erschwinglichen Preisen für Dauer- oder Abonnement-Nutzung.
CoSort ist eine Datentransformations- und damit ETL-Engine, aber kein klassisches ETL-Paket. Die IRI-Voracity-Plattform, die CoSort für Transformationen nutzt, ist es hingegen. Voracity kann CoSort und Hadoop für Transformationen sowie FACT für Extraktion und vorsortierte Bulk-Loads verwenden. Mit Voracity/CoSort profitieren Sie von leistungsstarken, I/O-konsolidierten, multithreaded Transformationen (Filtern, Sortieren, Joinen, Aggregieren, Konvertieren). SortCL beherrscht zudem Slowly Changing Dimensions, Fuzzy-Logik, Lookup-Tabellen, Pivotierung, Running/Ranking/Windowed-Aggregate und Bulk-CDC. In Voracity ist vieles davon in grafische Assistenten, Workflow- und Transform-Mapping-Diagramme gepackt, sodass Sie diese Jobs nicht skripten müssen. Sie lassen sich per Vorschau prüfen und aus der GUI oder Kommandozeile ausführen; Metadaten sind versionierbar, teilbar und absicherbar (z. B. EGit). (ETL, Voracity)
Ja, beides. Schon seit 1999 gilt CoSort Experten als ETL-Engine für Hochleistungs-Staging und -Integration. CoSort – speziell sein SortCL-Programm – übernimmt die Schwerarbeit aus Selektion, Transformation, Reporting und Pre-Load-Sortierung gegen sequenzielle Dateien in einem ODS, DW-Staging-Bereich oder auf extrahierten Tabellen. SortCL ist eine Push-Down-Optimierung für Informatica PowerCenter und die Sequential-File-Stage von IBM DataStage (schnellere, kombinierte Single-Pass-Operationen für Sort, Join, Aggregation). Neben bewährten Integrationen und Plug-’n‘-play-Sort-Ersatz für DataStage und Informatica verbindet sich CoSort auch mit Kalido, ETI, SAS und TeraStream. SortCL-Programme lassen sich aus jedem Tool als Executable aufrufen – z. B. Ab Initio, Pentaho, JasperETL, Pervasive DataRush u. a.
Ja – entweder über die DataStage Sequential-File-Stage oder eine Before-Job-Subroutine. Mit oder ohne die größere Voracity-Plattform nutzen Sie CoSort als externen Transformations-Hub und kombinieren große Sort-, Join-, Aggregations-, Reformatierungs-, Schutz- und Bereinigungsfunktionen in einem Job und I/O-Durchgang im Dateisystem. Voracity ergänzt die visuelle ETL-Design-Umgebung und Hadoop-Ausführungsoptionen. Mit AnalytiX-DS-Technologie lassen sich die meisten DataStage-Jobs automatisch nach Voracity konvertieren. (DataStage, ETL-Replatforming)
Ja. Mit oder ohne die größere Voracity-Plattform nutzen Sie CoSort als externen Transformations-Hub und rufen diese Jobs als Kommandozeilenoperation in bestehende Informatica-Flows auf. Voracity ergänzt die visuelle ETL-Design-Umgebung und Hadoop-Optionen. Mit AnalytiX-DS-Technologie lassen sich die meisten PowerCenter-Jobs automatisch nach Voracity konvertieren. (Informatica, ETL-Replatforming)
Zwei kompatible Drittanbieter-Technologien helfen: 1) Der AnalytiX DS Mapping Manager bzw. LiteSpeed-Conversion migriert Alt-ETL-Jobs in gleichwertige Voracity-Jobs (angetrieben von SortCL oder austauschbaren Hadoop-Engines), inklusive Quell-/Ziel-Datenlayouts und der meisten Transform-Mappings; manuelle Übersetzung/Tests füllen Lücken bei komplexen Mappings. 2) Um nur die Datenlayouts aus einem anderen Tool in SortCL-Layouts zu konvertieren, nutzen Sie die Meta Integration Model Bridge (MIMB), die Informatica-.xml, DataStage-.DSX und andere Metadaten in SortCL-DDF umwandelt.
Zu einem gewissen Grad ja. Voracitys Kern-Funktionen (Transformation, Mapping, Maskierung, eingebettete Berichtsformatierung) stecken alle im SortCL-Programm, das Sie mit Ihrer CoSort-Lizenz bereits skripten und ausführen können. Und die GUI für CoSort (IRI Workbench, auf Eclipse) ist dieselbe, die Voracity und alle Teilprodukte der Suiten IRI Data Manager (CoSort, FACT, NextForm) und IRI Data Protector (FieldShield, CellShield EE, RowGen) nutzen – mit Zugriff auf viele Voracity-Funktionen (Data Discovery, ETL-Flow-Diagramme, MDM-Assistenten, FieldShield-Maskierung, RowGen-Testdaten). Als reiner CoSort-Lizenznehmer haben Sie jedoch nur Anspruch auf IRI-Support für die im CoSort-Handbuch dokumentierten Funktionen und die GUI-Operationen aus den Menüs „CoSort“ und „IRI“. Voracity-Abonnenten erhalten Support für alle in der Workbench sichtbaren Funktionen (Profiling, Maskierung, Testdaten, ETL, MDM, CDC, SCD, Metadaten-Management, BIRT-Integration) sowie für kompatible Zusatzoptionen (AnalytiX DS Mapping Manager, FACT, SortCL in Hadoop, predictive Reports mit BIRT, Paques). Vollständiger Funktionsvergleich: siehe Produkt-Funktionsmatrix.
Das SortCL-Programm von CoSort besitzt eingebaute Filter- und Selektionslogik, um Datenmengen während oder nach der Verarbeitung zu reduzieren, zu segmentieren und zu bereinigen. Für fortgeschrittenere Datenbereinigung binden Sie eigene Funktionsbibliotheken ein, um feldbezogene benutzerdefinierte Transformationen vor oder nach Sort/Join/Merge/Report durchzuführen. SortCL liefert eine Beispielvorlage: ein Melissa-Data-Objekt zur Adress-Standardisierung, das das Adressfeld bei der Ausgabe bereinigt. (Datenqualität, Bereinigen)
CoSort SortCL, IRI Voracity und weitere IRI-Programme (FACT, NextForm, FieldShield, RowGen) laufen alle über die Kommandozeile und lassen sich damit per cron, Stonebranch Universal Controller (UAC), Cisco TES, CA Autosys, ASCI ActiveBatch u. Ä. in Batch-Ströme einplanen. PoCs erfolgten mit Oracle DBMS_Scheduler, UAC und Full360 metaController. In der IRI Workbench (der kostenlosen Eclipse-GUI) ist zudem ein Task-Launch-Scheduler eingebaut.

IRI Software – Preise & Lizenzierung

Der Kaufpreis (CapEx, Dauernutzung) von IRI-De-Identifizierungssoftware wie FieldShield richtet sich in der Regel nur nach der Anzahl der Hostnamen, auf denen statische Maskierungsjobs laufen (dort, wo die Engine/das SortCL-Programm installiert ist). Er variiert nicht nach Cores, Workbench-Nutzern, Datenquellen, Zeilen, Funktionen usw. Dasselbe gilt für Voracity-Lizenzen (inkl. FieldShield, CellShield EE, DarkShield, RowGen, CoSort). DarkShield-Lizenzen für Datenbankquellen (RDB/NoSQL) mit C/BLOBs werden wie FieldShield bepreist; bei DarkShield-Maskierung von Dateien/Dokumenten ohne Datenbanken erfolgt die Bepreisung volumetrisch. FieldShield und DarkShield sind einzeln (oder zusammen mit Rabatt) als Einmallizenz erhältlich, die Dauernutzung, Dokumentation und das erste Jahr Support abdeckt. Es gibt Rabatte für Mehrfach- und Runtime-Lizenzen; in Volumen ist Voracity günstiger. Mindestens eine Engine-Lizenz ist zum Maskieren nötig; die Basis-/erste Voracity-Preisstufe enthält fünf Engine-Lizenzen. Empfehlung: Die Anzahl/Verteilung der Lizenzen sollte Performance, Komfort und Budget berücksichtigen – aus Performance-Sicht möglichst je große DB-Quelle/-Ziel eine Engine (vermeidet Netzwerk-/I/O-Contention); aus Komfort-Sicht oft zusätzlich lokale Dev/Test-Lizenzen auf Workbench-PCs; im Budget sind gleichzeitig beschaffte zusätzliche Produktionslizenzen um 20–40 % rabattiert. Jährliche Wartung: 20 % der Lizenzgebühr (inkl. Upgrades); bei Voracity-Abos ist Support enthalten. Weitere Hinweise: Voracity enthält u. a. eine CellShield-EE-Lizenz, die DarkShield-Assistenten + API und dieselben 5 SortCL-Engines; höhere Tiers (z. B. bis 15, 50, 100, 500 Hostnamen) senken den Stückpreis. Für dynamische Maskierung über die FieldShield-„SandKey“-API (SDK) oder DarkShield-REST-API gilt eine tiefer gestaffelte Volumen-Preisstruktur (Royalty an eine primäre statische Entwicklungslizenz). Für ein DACH-Angebot wenden Sie sich an JET-Software.
Zusätzliche Hostname-Kopien eines Einzelprodukts kaufen Sie zu den dann gültigen Konditionen (Vollpreis auf dem größten neuen System, gleichzeitig benötigte weitere mit Rabatt). Bei weniger Lizenzen gibt es keine Rückerstattung, aber Ihre jährliche Wartungsbasis wird gesenkt, wenn Sie die Außerbetriebnahme und Entfernung von den Hostnamen formell bestätigen. Da Voracity in Tiers (Hostname-Blöcken) lizenziert wird, zahlen Sie den Differenzpreis einer höheren Stufe nur, wenn zusätzliche Lizenzen Sie in die nächste Stufe heben (z. B. von 5 auf 6/7 oder über 15/50/100/500). Umgekehrt ermöglicht die Stilllegung/Nicht-Verlängerung (nach Zertifizierung) eine niedrigere Tier-Rate bei der nächsten Verlängerung.
Die Preise pro Kopie (inkl. SortCL) liegen typischerweise im mittleren vier- bis fünfstelligen USD-Bereich und richten sich nach Hardware (z. B. RAM auf x86-PCs, Modell auf Unix-OEM-Servern) und Anzahl der genutzten Cores. CoSort ist auch per Abo innerhalb von Voracity erhältlich (dann ohne Berücksichtigung der Maschinengröße). Bei Dauernutzung gibt es Rabatte für gleichzeitig bestellte Folgelizenzen, begrenzte/ablaufende Nutzung, Runtime-Integration und GSA-Beschaffung. Endgültige Angebote erfolgen unter NDA. Angebot für den DACH-Raum: JET-Software.
Die IRI Workbench (Eclipse-IDE) ist für jeden Windows-/Linux-Hostnamen enthalten, auf dem ein lizenziertes IRI-Produkt läuft; eine macOS-Version gibt es auf Anfrage kostenlos für Lizenznehmer. IRI CoSort: Dauernutzung pro Hostname nach installiertem RAM (x86 Windows/Linux) und Anzahl lizenzierter Threads; auf AIX/Solaris/HP-UX/zLinux nach OEM-Modell. IRI Voracity (inkl. CoSort, NextForm, FieldShield, DarkShield, RowGen, Ripcurrent): meist Abo (1 oder 5 Jahre) nur nach Anzahl der SortCL-ausführenden Hostnamen; Hadoop und weitere Premium-Optionen kosten extra; Dauernutzung auf Anfrage. IRI FACT und IRI RowGen: pro Hostname nach lizenzierten CPU-Cores. IRI NextForm: mehrere Editionen/Preise (Details). IRI FieldShield: nur nach ausführenden Hostnamen (Linux und außerhalb der USA teurer). CellShield/DarkShield: nach Anzahl der zu schützenden Tabellen/Dokumente (DarkShield bei DB gleich FieldShield). DMaaS: Tages-, Stunden- oder Projektpreise. Für ein DACH-Angebot: JET-Software.
Im ersten Jahr ist sie oft in der Lizenzgebühr enthalten, danach eine jährliche Option als Prozentsatz der Lizenzgebühr, abhängig vom gewünschten Support-/Upgrade-Niveau. Üblich sind 20 % der Lizenzbasis; das berechtigt zu Produkt-Updates und begrenzten Lizenz-Transferrechten. Läuft der Support aus, ist Rückwirkungs-Support fällig und ggf. ein Major-Upgrade nötig (mit Rabatt). 24/7-Support ist ein zusätzliches Premium.
Die Software läuft nicht ab. Das Standard-Geschäftsmodell erlaubt zeitlich unbegrenzte Nutzung, mit oder ohne Support. Sie müssen also nicht am Ende einer mehrjährigen Laufzeit erneut zahlen – es sei denn, Sie haben ausdrücklich ein Leasing gewünscht.

ISV-/OEM-Integration

Das CoSort-Paket enthält alle Werkzeuge, Konvertierungs-Utilities und aufrufbaren Bibliotheken sowie vollständige PDF-Dokumentation für Executables und APIs.
Bei der Installation eines CoSort-Pakets werden Standard-Tuning-Parameter automatisch so konfiguriert, dass verfügbare RAM- und CPU-Ressourcen genutzt werden. Nutzer können die Parameter (inkl. Zuweisung von Überlauf-Disks und Audit-Logs) manuell in einer einfachen Textdatei anpassen.
In der Regel über systemspezifische Lizenzschlüssel. Rufen Sie uns an, um Ihre Situation zu schildern (Kontakt).
Das hängt davon ab, welche Komponenten Sie einsetzen und welchen Funktionsumfang Sie benötigen. Für eine einfache Sortierung dauert die Wahl der Schnittstelle oft so lange wie deren Umsetzung. Benutzerdefinierte Ein-/Ausgabe- oder Vergleichs-Routinen bzw. eigene feldbezogene Transformationen (z. B. eigene Bereinigungs- oder Statistikfunktionen) dauern länger.
Von 150 $ bis 15.000 $ pro Kopie oder Standort, wenn CoSort in Ihre Anwendung eingebettet und weiterverteilt wird. Das hängt vom integrierten Teil, der Anzahl/Geschwindigkeit der Verteilung sowie der (durchschnittlichen) Endnutzer-Hardware und dem Preis Ihrer Anwendung ab. Wir streben eine faire Lizenzierung innerhalb Ihres Geschäftsmodells an.
Es kann alles davon (bzw. jede Kombination) sein.
Sie können ein vollständiges oder teilweises CoSort-Paket unsichtbar einbetten, re-lizenzieren oder verweisen. Teiloptionen sind u. a.: eigenständige Schnittstellen (sorti, sortcl); Drittanbieter-Sort-PlugIns (z. B. Unix sort, SAS); Runtime-Bibliotheken (cosort_r(), sortcl_routine()).
Das hängt von Ihrer aktuellen Methodik, Hardware, Kernel- und CoSort-Tuning, Datenvolumen und Job-Spezifikation ab. Sie können es in einem kostenlosen, vertraulichen Test messen.
Falls ja, weniger als für Produktion. Sprechen Sie uns an, um Ihre Situation zu besprechen (Kontakt).

Große XML-Dateien erstellen/konvertieren

Ja, sofern Ihre XML-Dateien strukturierte, sequenzielle Datensätze beschreiben. Die Ausgabe kann eine weitere flache XML-Datei oder jeder andere von SortCL unterstützte Dateityp sein.
Ja, wenn die XML-Datei strukturierte, sequenzielle Datensätze enthält und der Ausgabe-Prozesstyp in SortCL dokumentiert ist.
Ja, wenn diese Prozesstypen in SortCL dokumentiert sind. Gültige Ausgabeziele können zudem für Reporting, Übergaben und Outsourcing benutzerdefiniert formatiert und geschützt werden.
Ja, im Rahmen der oben genannten Formatgrenzen.
Nein – außer, der Speicherplatz geht aus.

Oracle-Beschleunigung

Es hilft, die Daten ohne Qualifizierer in eine flache Datei oder Pipe an CoSort zu geben. Überlassen Sie also ORDER BY, GROUP BY, DISTINCT und JOIN dem CoSort – das alle (gleichzeitig) schneller im Dateisystem erledigt und im selben I/O formatierte Berichte liefert.
SortCL unterstützt alle SQL-Aggregatfunktionen (Sum, Average, Count, Max, Min), ist aber effizienter, weil es auf mehreren Schlüsseln sortieren und Aggregatergebnisse für eine oder mehrere Ausgabedateien im selben Durchgang (offline) erzeugen kann.
Auf einem ia64-HP-Server rx5670 (vier 1-GHz-Itanium2-CPUs, 32 GB RAM) verband Oracle 9i (SQL*Plus) zwei 1-GB-Tabellen in 48 Minuten. Das Entladen derselben Tabellen mit IRI Fast Extract (FACT), Pipen in flache Sortier-/Join-Vorgänge in SortCL und anschließendes Pipen in SQL*Loader erzeugte dieselbe verbundene Tabelle in 18 Minuten (etwa 1/3 der Zeit der Online-Methode).
Direct-Path-Ladevorgänge mit vorsortierten Daten sind der schnellste Weg, neue Tabellen zu erstellen, da diese Methode den Overhead der Oracle-Index-Sortierung umgeht. Für Bulk-Loads sortieren Sie die Daten zuerst mit CoSort auf dem Primärindex-Schlüssel; das CREATE INDEX überspringt dann den Sortierschritt. Für reguläre Insert-Loads sortieren Sie auf dem Clustered-Index als Schlüssel.
Über datenbankspezifische APIs und parallele Unload-Techniken, die portable flache Dateien erzeugen. Details, Broschüre, White Paper, Webinar oder Test: siehe FACT.
CoSort-(bzw. Voracity-)SortCL-Skripte erledigen viele gleiche Aufgaben deutlich schneller und mit weit weniger Code. SortCL läuft außerhalb der Datenbank auf flachen Dateien und nutzt dieselbe relationale Logik: SELECT/WHERE, DISTINCT, ENCRYPT, ORDER BY, GROUP BY, JOIN. Beispiel: SortCL nutzt bedingte /INCLUDE- und /OMIT-Anweisungen zur Selektion; DISTINCT entspricht /NODUPLICATES, ORDER BY einem /KEY, GROUP BY einem /SUM, /AVERAGE usw.
Wie FACT können auch der AnalytiX DS Mapping Manager oder die Meta Integration Model Bridge (MIMB) von MITI die Datei-Layout-Metadaten aus Ihrem relationalen bzw. ETL-Tool automatisch in das CoSort/SortCL-Data-Definition-File-(DDF-)Format konvertieren.
Siehe BI & Analytik > Berichtsfunktionen.

CoSort – Sortier-Anwendungen & Performance-Tuning

CoSort ist ein robustes Software-Paket in kommerzieller Qualität, um große Datenmengen effizient zu manipulieren und zu verwalten. Genauer: ein Paket für Sortierung, Datentransformation, Migration und Reporting, das ein sehr breites Spektrum an Herausforderungen in Datenintegration, Datenmaskierung, Business Intelligence und angrenzenden Disziplinen adressiert. „CoSort“ steht für Co-routine Sort und wurde erstmals kommerziell veröffentlicht: CP/M 1978, DOS 1980, Unix 1985, Linux 1990, Windows 1995, IBM i/Z 2000. CoSort nutzt Parallelverarbeitung, fortgeschrittenes Speichermanagement, I/O-Techniken, Task-Konsolidierung und überlegene Algorithmen, um Datenbewegung und -manipulation in bestehenden Dateisystemen zu optimieren – ohne Paradigmenwechsel zu DB-Engines, NoSQL, Hadoop oder Appliances. Manchmal etwas mehr RAM, aber das genügt meist.
Sehr schnell. Die Leistung variiert nach Quellgröße/-format, Daten- und Job-Ausrichtung, Hardware-Konfiguration, Ressourcen, paralleler Aktivität und Tuning. Die besten Benchmarks (z. B. 1 GB in 12 Sekunden, 50 GB in 2 Minuten) laufen im Arbeitsspeicher auf schnellen Multi-CPU-Unix-Servern.
Sobald Sie einen Engpass bemerken – je nach Hardware ab etwa 500.000 bis 50 Mio. Zeilen. CoSort sortiert routinemäßig im Terabyte-Bereich und skaliert linear ohne Hadoop; Eingabedateien im zwei- bis dreistelligen Gigabyte-Bereich sind üblich. Beliebig viele Ein-/Ausgabedateien und strukturierte Formate werden gleichzeitig unterstützt (Line/Record/Variable Sequential, Blocked, CSV, I-SAM, LDIF, flaches XML, Vision). CoSort ist außerdem die Standard-Engine der IRI-Voracity-Plattform, die viele CoSort-Transformations- und Maskierungsjobs (in SortCL-4GL oder grafisch in der Workbench) nahtlos in Hadoop ausführen kann – die Frage ist also eher, ab welchem Volumen man solche Jobs stattdessen über eine Hadoop-Engine laufen lässt.
Meist über eine CoSort-Resource-Control-(cosortrc-)Textdatei, die global, nutzer- und/oder job-spezifisch sein kann (unter Windows setzen Registry-Einstellungen Standardwerte, die per rc-Datei überschrieben werden). Sie legen Ober-/Untergrenzen für CPU-/Core-Threads und Speicher, I/O-Puffer sowie Speicherplatz für den Sort-Überlauf fest. Der wichtigste Faktor für die Sortier-Performance ist meist die Geschwindigkeit der I/O-Kanäle. Bei kleinen (in-Memory-)Dateien optimieren Sie Lesen/Schreiben der Quell-/Zieldateien; bei großen Dateien zusätzlich den Durchsatz zu den Work-Area-Dateien. Die lokalen Work-Areas (temporäre Merge-Dateien) lassen sich oft optimieren – mehrere schnelle SSDs auf getrennten Controllern machen Überlauf-Sortierungen fast so schnell wie In-Memory. Danach sind die Speicher-Einstellungen am wichtigsten; CoSort 10 hat leistungsstarke Selbst-Tuning-Techniken. Wir empfehlen als einzige Speicher-Einstellung MEMORY_MAX AUTO in $COSORT_HOME/etc/cosort.rc. Beispiel-Tuning-Datei:
THREAD_MAX 6
THREAD_MIN 1
MEMORY_MAX AUTO
WORK_AREAS /mnt/ssd1/work
WORK_AREAS /mnt/ssd2/work
MONITOR_LEVEL 0
MINIMUM_YEAR 70
ON_EMPTY_INPUT PROCESS_WITH_ZEROS
OUTPUT_TERMINATOR INFILE
Setzen Sie THREAD_MAX bis zur von Ihrer Lizenz erlaubten Core-Anzahl. Bei weiteren Fragen kontaktieren Sie uns.
Eine externe Sortierung ist zu groß für den Speicher und nutzt temporäre Work-Dateien (LWF). Dabei wird pro Thread-/Work-Area-Kombination eine physische Work-Datei erzeugt. Der Speicherbedarf beim LESEN der Eingabe entspricht etwa: THREAD_MAX × AIO_BUFFERS × BLOCKSIZE × Anzahl WORK_AREAS. In der Merge-Phase (SCHREIBEN) wird deutlich mehr Speicher benötigt, da jede physische Datei mehrere logische Work-Dateien enthalten kann. Reicht der über MEMORY_MAX verfügbare Speicher nicht, tritt der Fehler „insufficient merge memory“ (Fehler 2) auf. Abhilfe: MEMORY_MAX erhöhen oder eine der anderen an der Berechnung beteiligten Einstellungen verringern.
CoSort nutzt mehrere Threads, sobald das Sortiervolumen mindestens doppelt so groß ist wie die in der cosortrc angegebene BLOCKSIZE (bei Auto-Tuning typischerweise 1–2 MB). CoSort unterscheidet nicht zwischen physischen CPUs, Cores oder Hyper-Threading – das Betriebssystem plant die Threads. CoSort erzeugt nur die Sort-Threads bis zum in der Tuning-Datei angegebenen Maximum (nie über das Lizenzlimit). Cores sind meist der beste Indikator für die Spitzenleistung vor dem Punkt des abnehmenden Grenznutzens (Ressourcen-Contention, Amdahlsches Gesetz). Da jeder sortcl-Prozess unabhängig ist (keine Inter-Prozess-Kommunikation), sind in parallelen Multi-Job-Umgebungen oft nur 1–2 max. Threads effizienter. Der Speicher tunt sich bei MEMORY_MAX AUTO selbst. Zum Testen fordern Sie über den normalen Registrierungsprozess einen temporären Lizenzschlüssel für die Gesamtzahl der physischen Cores an und variieren dann THREAD_MAX. Laufzeitergebnisse werden protokolliert und lassen sich später offline analysieren.
Nein – welche CPU-Cores die Threads nutzen, entscheidet allein das Betriebssystem. Sofern Ihr OS es unterstützt, können Sie per System-Tuning versuchen, sortcl-Prozesse bestimmten Chips/Cores zuzuweisen.
CoSort hat keine Inter-Prozess-Kommunikation; jede Instanz steht für sich. Bei MEMORY_MAX = 10 % und zwei gleichzeitigen Jobs nutzen Sie also 20 % des Systemspeichers.
Ja. Eine höhere BLOCKSIZE verbessert Lese-/Schreib-Performance, wenn Quell- und Work-Dateien auf demselben Gerät liegen – andernfalls ist eine niedrigere BLOCKSIZE besser. Testen Sie Werte von 100K bis 16M. Bei großen externen Sortierungen kann eine zu große BLOCKSIZE zu unzureichendem Merge-Speicher führen.
AIO_BUFFERS ist die Anzahl der Puffer zum Lesen/Schreiben. CoSort nutzt überlappendes I/O (während ein Puffer verarbeitet wird, wird ein anderer gelesen/geschrieben). Mehr Puffer bringen eine leichte Beschleunigung, benötigen aber mehr Merge-Speicher. Werte über dem Standard mit Vorsicht verwenden, zuerst mit der größten auftretenden Eingabe testen und prüfen, ob der Gewinn messbar ist.
CoSort-Nutzer können Laufzeitinformationen vor, während und nach der Ausführung anzeigen: über optionale Bildschirm-Anzeigestufen, selbst-fortschreibende/ersetzende Log-Dateien, anwendungsspezifische Statistikdateien sowie einen vollständigen Audit-Trail für Compliance- und Forensik-Anforderungen.
Mehr als 120 – Tendenz steigend. Dazu zählen Single- und Multi-Byte-Zeichensätze, Unicode, C-, COBOL- und Mainframe-Numerik. Wenn Sie unsicher sind, was Sie haben, hilft JET-Software bei der Definition. Zudem unterstützt CoSort die (gleichzeitige) Kollation, Konvertierung und Erstellung von über zwei Dutzend Dateiformaten.
Es gibt keine spezielle mvs2scl-Option dafür, aber Sie können grep beim Ausführen der Übersetzung nutzen. Führen Sie auf der Kommandozeile aus:
mvs2scl job1.mvs | grep -v '$SORT' > job1.scl
Dabei ist job1.mvs das zu übersetzende MVS-Skript und job1.scl das SortCL-Skript ohne $SORTIN-/$SORTOUT-Zeilen. Die Option -v gibt nur Zeilen aus, die den Ausdruck $SORT nicht enthalten.
SAS dokumentiert die CoSort-Option in den v7-/8-Systemen für Unix (in den SAS- und CoSort-Handbüchern). Der Einsatz von CoSort beschleunigt native SAS-PROC-Performance abseits des Mainframes deutlich und kostengünstig. In SAS wird CoSort automatisch oder über eine vom Administrator eingerichtete Resource-Control-Datei getunt (jederzeit auf globaler, Nutzer- oder Job-Ebene änderbar). Für SAS 9 und neuer wenden Sie sich bitte an SAS, da diese ihr „Sort-Appendage“ für CoSort noch nicht aktualisiert haben.
Sie unterscheiden sich und basieren auf Zusammenarbeit und Feedback mit Partnern und Kunden, die ihre Daten- und Job-Definitions-Metadaten besitzen.

IRI (Unternehmen)

Das Unternehmen ist IRI, Inc. – IRI steht für Innovative Routines International. IRI wurde 1978 in New York als Information Resources, Inc. gegründet und benannte sich beim Umzug nach Florida 1995 um (dort war der Name Information Resources bereits vergeben). CoSort ist IRIs erstes Produkt und macht das Unternehmen bekannt. Wir sind nicht mit dem anderen „IRI“ verbunden – der Chicagoer Marktforschungsfirma Information Resources, Inc. (die ironischerweise selbst IRI-CoSort-Lizenznehmer ist).
CoSort ist IRIs bekanntestes Produkt für Datenmanagement und -manipulation. Das zentrale Werkzeug im CoSort-Paket ist das Sort-Control-Language-(SortCL-)Programm – SortCL bezeichnet sowohl die ausführbare Datei als auch die 4GL-Syntax für Job-Skripte (Datendefinition + Manipulation). Aus SortCL sind mehrere IRI-Spin-off-Produkte entstanden, die dieselbe Definitions-Syntax verwenden, aber einen günstigeren, gezielten Funktions-Teilbereich abdecken: NextForm (Migration), FieldShield (Maskierung sensibler Daten) und RowGen (Testdaten). Voracity ist IRIs „Total Data Management“-Plattform, die CoSort und alle SortCL-Spin-off-Funktionen enthält – plus Data-Discovery/Profiling, visuelles Job-Design, Hadoop-Engine-Optionen, Cloud-/Big-Data-Konnektoren, Datenqualitäts- und MDM-Assistenten und mehrere Analyse-Frameworks. Die IRI Workbench ist die kostenlose, gemeinsame Eclipse-GUI für alle diese Jobs.
Bis vor Kurzem lag IRIs Fokus auf Backend-Systemen, über die kaum jemand spricht. Als „stiller Partner“, der die Schwerarbeit für die Produkte und Abläufe anderer erledigt (u. a. CGI, CSC, Cincom, Epsilon, NTT Data, Sabre, Sungard), war IRI weniger sichtbar, als der Software-Stack es rechtfertigt. Tatsächlich ist IRI auch ein bedeutender Enterprise-Software-Anbieter und in vielen Großunternehmen weltweit bekannt (u. a. American Airlines, Bank of America, Comcast, Disney, EDS, Fidelity) sowie bei den sie betreuenden Beratungen (Accenture, Atos, Cognizant, DXC, HPE, IBM Global Services). IRI ist nicht Venture-finanziert und investiert weit mehr in F&E als in Marketing – zum Vorteil der Kunden. Gartner verfolgt IRI-Software in den Bereichen Datenintegration, Datenmaskierung, Legacy-Migration, Testdaten und Business Intelligence.
Ja und ja.
Als deutschsprachiger IRI-Partner unterstützt Sie JET-Software vor, während und nach Ihrer Evaluierung und leitet Sie an die richtige Ressource. Da es in unserem Interesse liegt, dass Ihre geschäftlichen und technischen Ziele mit der Software erreicht werden, arbeiten wir mit Ihnen an erfolgreichen Lösungen. Kontakt.
JET-Software – als deutschsprachiger IRI-Partner – sowie über 40 internationale IRI-Support-Büros und zahlreiche mit IRI-Software vertraute Beratungen. Vor allem aber werden Sie feststellen, wie einfach Sie sich selbst helfen können: Alle daten- und job-bezogenen Metadaten sind offen, selbst-dokumentierend und leicht anzupassen, und die vertraute Eclipse-GUI automatisiert Skripterstellung, Integration, Ausführung und Verwaltung.
Weil sie niedriger sind. Als Teil so vieler anderer Anwendungen brauchte IRI nicht den Marketing-Overhead der Wettbewerber; zudem ist IRI kein börsennotiertes Unternehmen und bedient keine externen Investoren oder Schulden. Diese Ersparnisse geben wir an die Kunden weiter.
Im deutschsprachigen Raum direkt über JET-Software als autorisierten IRI-Partner, der die Software auch betreut. Fordern Sie ein Angebot an (Kontakt) und geben Sie nach erfolgreicher Evaluierung die zu lizenzierenden Produkte an. Die Preise richten sich danach, was und wo Sie es einsetzen (siehe Preis-FAQ).
Ja, 24/7-Support ist verfügbar. Für weltweiten 24/7-Support fällt in der Regel ein Aufpreis zum Standard-Jahressupport an.
Die Wartung ist im ersten Jahr nach der Lizenzierung kostenlos. Für Nutzer mit Wartung sind Minor-Releases auf Anfrage bzw. bei Bedarf für den Support kostenlos. Major-Releases sind optional, aber meist kostenpflichtige Upgrades; die Kosten hängen von Ihrem Wartungslevel ab.
Weil Sie eine Dauernutzungslizenz einmalig kaufen. Support ist optional, und Sie sind nicht zum Upgrade gezwungen (auch wenn es irgendwann sinnvoll ist). Nutzen Sie Voracity im Abo, können Sie Lizenz- und Supportkosten über eine rabattierte Vorauszahlung für fünf Jahre festschreiben.

IRI Partnerschaften

Ja – aber nicht in der aufwändigen Art von Megavendor-Programmen. Wir setzen auf maßgeschneiderte, wechselseitige Beziehungen in diesen Kategorien: Experten-Berater (spezialisiert auf Branchen und/oder IT-Disziplinen, die IRI-Software empfehlen, vermitteln, weiterverkaufen und/oder implementieren); Branchen-Allianzen mit Hardware-/Software-Herstellern (Plattform-Kompatibilität, Referenzarchitekturen, Benchmarks) sowie Analysten/Medien; internationale Reseller, die IRI-Software proaktiv vermarkten, verkaufen, implementieren und/oder betreuen; sowie ISVs, ASPs, MSPs, VARs und Systemintegratoren, die IRI-Software einbetten, bündeln oder verweisen.
Nein – abgesehen von der Zeit, die Sie ins Erlernen der Software investieren, und etwaigen Vertriebs-/Marketing-Aktivitäten. Diese sind nicht erforderlich oder quantifiziert, sofern keine territoriale Exklusivität gewünscht ist.
Das hängt von der Art der Partnerschaft ab. Ein informierter Analyst oder Referral-Partner können Sie nach einem halben Tag Einarbeitung werden; die Vertragsunterzeichnung dauert einige Tage. Für Reseller und Einbettung kann der Prozess je nach Onboarding und Geschäftschancen Tage bis Wochen dauern.
Die Zusammenarbeit mit einem Anbieter, der seit 1978 stabil und profitabel ist – ohne Druck externer Investoren, hohe Fluktuation oder verzögerten Support; relativ hohe Margen ohne Gebühren oder Quoten; faktische Exklusivität in mehreren geografischen, Branchen- oder technischen Bereichen; ein gut integrierter Technologie-Stack (gemeinsame Metadaten, Eclipse-GUI) für einfaches Onboarding und Cross-Selling; schnelle, flexible und faire kommerzielle Reaktionen.
Sie sollten ausreichende technische Kompetenz, kommerzielle Tragfähigkeit, relevante Erfahrung/Chancen und einen guten Ruf mitbringen. Eine bestimmte Mitarbeiterzahl, Firmenhistorie oder Zertifizierungen sind keine verlässlichen Erfolgsindikatoren. Die erfolgreichsten Partner haben oft Kernteams von nur 2–3 Personen für Demos, Support, Vertrieb/Marketing und Verwaltung; mit wachsenden Chancen sollte weiteres Personal hinzukommen.
Das hängt von der Beziehung ab, z. B.: vendor-neutrale Beratung/Analyst → NDA oder MNDA; reine Vermittlung → wechselseitige Finder’s-Fee-MoU; Wiederverkauf → Reseller-Vereinbarung; OEM-Integration → Royalty-Vereinbarung.
Ja, es gibt mehrere Schulungswege und Zertifizierungsstufen. In der Regel entstehen keine Zusatzkosten außer unserer und Ihrer Zeit für die Orientierung und den Weg zum Selbstlernen. Für das Zertifikat fällt eine Gebühr an; wir verlangen von Partnern jedoch keine Zertifizierung. Zertifizierte Partner haben aber einen klaren Vorteil.
Das hängt vom Produkt, der Art der Beziehung, Wettbewerbs-/Kundenumständen und Faktoren wie Features, Versionen, Sonderfällen und Volumenrabatten ab. In der Regel erhalten Finder’s-Fee-Partner 10 % Rabatt, Reseller 25–50 %. Öffentliche Preisspannen finden Sie auf der Website; konkrete Preise stehen im Reseller-Guide.
Ja – und das ist erforderlich, wenn eine dauerhafte Entwicklungskopie mit Support für die Erstellung/Pflege einer Runtime-Integration oder eines Lösungsbündels benötigt wird oder Produktionslizenzen in Managed-Service-Szenarien genutzt werden. Eine kostenlose, aber ablaufende (langfristige) Lizenz gibt es für ein Disaster-Recovery-System sowie für aktiv vermarktende Reseller (Schulung, Demo, Support).
Wir ermutigen ausdrücklich zur Nutzung unseres aktuellen Logos und aktueller Beschreibungen. Wir bitten lediglich um Vorab-Freigabe der Online-Botschaften bzw. Marken-Materialien, die Sie wiederverwenden oder neu erstellen möchten. Zudem freuen wir uns, Use Cases und gemeinsame Lösungen zu dokumentieren und gemeinsam zu bewerben.
Je nach Beziehung ist oft keine formale Verlängerung nötig, bis ein Ereignis wie eine Unternehmens- oder Missionsänderung eintritt. Referral-Vereinbarungen verlängern sich meist automatisch, solange die Beziehung erfolgreich ist, können aber bei wesentlichen technischen, kommerziellen oder rechtlichen Umständen geändert/gekündigt werden. Andere Vereinbarungen (exklusiver Wiederverkauf, Runtime-Integration, Abo/Support) können jährlich ablaufen oder an weitere Bedingungen geknüpft sein.

Datensicherheit – PII klassifizieren, suchen, maskieren (IRI *Shield-Tools)

Beide – IRI FieldShield (strukturierte Daten, per ODBC und JDBC) und IRI DarkShield (strukturierte Daten plus C/LOB-Spalten, nur per JDBC) – können sensible Daten in relationalen Datenbanken finden und maskieren und sind dafür gleich bepreist. Der Anwendungsfall entscheidet: DarkShield kann getrennt oder gleichzeitig suchen und maskieren, FieldShield trennt beides; FieldShield kann maskierte Ergebnisse leichter auf unterschiedliche Ziele abbilden (andere DB-, Datei- und Report-Ziele, sogar alle zugleich, ETL-artig), DarkShield nur auf dieselbe RDB oder eine Flatfile; nur DarkShield verarbeitet auch semi- und unstrukturierte Quellen (EDI, Freitext, Dokumente, Bilder, NoSQL, Parquet usw.); FieldShield-Jobs sind bei rein strukturierten Quellen dank SortCL metadaten-kompatibel mit Subsetting, inkrementeller Maskierung, Testdaten-Synthese, Cleansing, ETL und Reporting; und FieldShield unterstützt Input-Filterung (SortCL include/omit oder SQL) sowie komplexe Zielfeld-Logik (kombinierte Maskierung/String-Transformation, Joins, bedingte Regeln, Reformatierung). Beide laufen standardmäßig on-premise, aber auch in der Cloud (LAN, SharePoint, Azure, S3, GCP), nutzen dieselben Datenklassen und Maskierungsfunktionen für Struktur- und referenzielle Integrität, teilen die IRI-Workbench-IDE, haben aufrufbare APIs, lassen sich in DevOps-Pipelines integrieren und in CLI-Jobs ausführen, und sind Bestandteile der IRI-Voracity-Plattform. Oft werden beide Produkte im Bundle oder als Voracity-Transaktion lizenziert. Schildern Sie uns Ihre Anforderungen und fordern Sie ein Online-Meeting oder eine Live-Demo an: JET-Software kontaktieren.
Das variiert nach Anwendungsfall. Bei RDB-Quellen/-Zielen sind DBA-Kenntnisse und Wissen über Datenstrukturen von Vorteil. CDO/CISO bzw. Data-Governance/Security-Verantwortliche sollten an der Definition (Klassifizierung) beteiligt sein – welche Datentypen sensibel sind und welche Maskierungsregeln gelten. Data Scientists helfen bei ML/AI-Aspekten (DarkShield-NER-Modelle). BI-/Analytics-Architekten sind nützlich, um anonymisierte Ausgaben, PII-Suchberichte und Logs auszuwerten. Für Produktionsnutzer sind Kenntnisse in Eclipse, Git, 4GL/3GL (API) und relevanten Cloud-Verbindungen hilfreich. TDM-Architekten unterstützen bei Definition/Konfiguration und Bereitstellung maskierter, subsettierter oder synthetisierter Daten.
Das hängt von Quellen, Zielen und der benötigten Funktionalität ab. Für DB-Subsetting und Testdaten brauchen Sie IRI RowGen oder die IRI-Voracity-Plattform (enthält Subsetting, RowGen-Synthese und alle *Shield-Produkte). Gerne beraten wir Sie zur passenden Auswahl: Kontakt.
Indem dieselbe deterministische Maskierungsfunktion automatisch und global stets auf denselben Klartext angewendet wird. Das geschieht über Regeln, die an gemusterte Spaltennamen gebunden sind, oder zuverlässiger über integrierte Datenklassen. Klassifizierte Daten werden per RegEx-Muster (mit einstellbaren Genauigkeitsschwellen), Lookup-Wertabgleich, Fuzzy-Match, Named-Entity- und Gesichtserkennungsmodellen oder JSON/XML/CSV/DB-Pfad-Filtern entdeckt/validiert. Alle Shield-Produkte – FieldShield, DarkShield, CellShield EE – teilen dieselben Datenklassen und deterministischen Funktionen, wodurch Daten- und referenzielle Integrität über strukturierte, semi- und unstrukturierte Quellen hinweg gewahrt bleibt. IRIs integrierte Datenklassifizierung macht formal definierte Primär-/Fremdschlüssel überflüssig – referenzielle Integrität wird auch ohne Constraints unterstützt (in DBs wie in Dateien, Dokumenten, Bildern). Wo Constraints für automatisch generierte RDB-Testdaten nötig sind, liegen sie im DB-Subsetting- und im Testdaten-Synthese-Assistenten; ohne definierte Constraints ist Subsetting/Synthese möglich, erfordert aber mehr manuelle Eingriffe.
Richtig – es gibt mehr Anwendungsfälle und Aufruf­methoden, als wir aktuell halten können. Es sind bereits mehrere KI-Modelle im Produkt, die per Machine Learning sensible Daten über strukturierte, semi- und unstrukturierte Quellen entdecken; IRI führt laufend weitere ein. Gerne demonstrieren wir Ihnen konkrete Lösungen zu Ihrem Anwendungsfall in einer Live-Demo: Kontakt.
Ja – über einen externen Kommandozeilen-Aufruf (CLI) sowie über eine RPC-API, die per Web-Requests aus einem eigenen aufrufenden Programm angesprochen werden kann.
Datenschutzrechts-Gruppen und Sensitivitäts-Klassifizierungen sind ab Werk enthalten; die übrigen Standard-Maskierungsregeln sind nicht branchenspezifisch, entsprechen aber wahrscheinlich schon Ihren Anforderungen (z. B. FPE für Kartennummern, Pseudonyme für Namen, Schwärzung für Steuer-IDs). Datenklassen, Datenklassen-Gruppen und die zugehörigen Regeln lassen sich leicht anpassen – das ist meist nur einmal nötig. Es gibt eine große Auswahl an Maskierungsregeln.
Was Ihre Anforderungen erfüllt. In IRI FieldShield (bzw. dem SortCL-Programm in IRI CoSort) können Sie pro Feld/Spalte anwenden: Verschlüsselung, Maskierung, Hashing, Pseudonymisierung, Randomisierung, De-ID, Ausdrucks-(Berechnungs-)Logik, Substring-/Byte-Verschiebung, Datentyp-Konvertierung oder eine eigene Funktion. Entscheidungskriterien pro Datum: Sicherheit (wie stark/„unknackbar“), Umkehrbarkeit (muss das Verborgene später wieder aufgedeckt werden), Performance (Rechen-Overhead) und Erscheinungsbild (muss das Originalformat erhalten bleiben). Sie können ein oder mehrere Felder mit gleichen oder verschiedenen Funktionen schützen oder ganze Datensätze („wholerec“); Bedingungen und Ziel-/Layout-Parameter sind anpassbar und im selben Job mit Transformation und Reporting kombinierbar. Über Mehrtabellen-Assistenten oder globale Datenklassifizierung können DBAs und Data Stewards diese Schutzmaßnahmen als Regeln datenbank- oder unternehmensweit konsistent anwenden. Gerne helfen wir bei der Auswahl: Kontakt.
Beides! FieldShield und CoSorts SortCL-Programm schützen beide Quelltypen gleichzeitig mit einer oder mehreren feldbezogenen Sicherheitsfunktionen – in großem Umfang (statische Maskierung) oder gezielt (dynamische Maskierung, per Filterbefehl/Stored Procedure). Manche DBs haben eingebaute Spaltenverschlüsselung, doch deren Ansatz kann umständlich oder limitierend sein: Sie müssen mehrere DBs, andere Quellen oder Daten in Bewegung (Flatfiles) schützen, die eine einzelne Methode nicht abdeckt; eingebaute DB-Krypto-Bibliotheken sind evtl. zu langsam, teuer oder komplex; sie sind auf eine einzige Methode beschränkt, die Sicherheits- oder Erscheinungsanforderungen evtl. nicht erfüllt; oder Sie müssen Daten in der DB unverändert lassen, aber beim Ein-/Ausgang schützen (hier kommen Flatfiles ins Spiel). Andere Krypto-Produkte verschlüsseln ganze Dateien, DBs, Disks oder Netzwerke – das kann lange dauern und den Zugriff auf nicht-sensible Daten blockieren. FieldShield und SortCL verschlüsseln (oder schützen) nur die Felder/Spalten, die es benötigen – im selben Job-Skript und I/O-Durchlauf zusammen mit Transformation, Migration und Reporting.
Für MongoDB können FieldShield oder DarkShield sensible Daten je nach Anwendungsfall unterschiedlich finden und maskieren (DarkShield deckt beide Fälle ab). Bei rein strukturierten Daten in den Collections: 1. FieldShield mit CSV-Export/-Import; 2. FieldShield mit CData-O/JDBC-Treibern; 3. FieldShield mit IRI-BSON-Treiber. Enthalten die Collections auch semi-strukturierte (JSON) oder unstrukturierte Daten (Dokument, Bild, Freitext): 4. DarkShield-GUI; 5. DarkShield-API.
1) TDE bietet nur AES/3DES und nur für MS-SQL-RDBs. IRI enthält mehr Verschlüsselungs- plus viele weitere Maskierungsfunktionen und deckt mehrere Quellen ab (andere RDBs on-prem/Cloud, Legacy-/COBOL-Dateien, Freitext, JSON/XML, MS-Office-/PDF-Dokumente, NoSQL, Bilder). 2) TDE ist nicht spaltenspezifisch; IRI erlaubt Verschlüsselung/Maskierung ad hoc auf Feld-/Zeilenebene, bedingt auf Wertebene und konsistent auf Spaltenebene über mehrere Tabellen/Schemata als Datenklassen-Regel (inkl. formaterhaltender Verschlüsselung) zur Wahrung referenzieller Integrität. 3) TDE ist an SQL gebunden und damit für SQL-Injection anfällig, was die gesamte Anwendung umkehren kann; IRI maskiert statisch spezifische Spalten mit ggf. unterschiedlichen Funktionen – SQL kann die Daten nicht umkehren, und selbst mit Executable, Skript und einem Schlüssel wäre nur eine Spalte exponiert. 4) TDEs Ver-/Entschlüsselung ist rechenintensiv (jede DB-Seite); IRI-Feld-Jobs sind nur I/O-gebunden (ODBC-Lese-/Schreibtempo, per inkrementeller Maskierung weiter reduzierbar). 5) TDE erfordert Azure Key Vault (EKM); IRI unterstützt Azure Key Vault ebenfalls, benötigt es aber nicht (Schlüssel lokal, als Umgebungsvariable oder via Townsend Alliance Key Manager). 6) TDE arbeitet nicht direkt mit anderen Metadaten-Systemen zusammen; FieldShield ist Teil von SortCL/4GL – Maskierung im selben Job mit ETL, CDC, DB-Subsetting, Reorgs, Cleansing, Migration, Reporting; Metadaten werden mit RowGen geteilt und von MIMB/erwin unterstützt. 7) TDE ist nicht mit PII-Klassifizierung/-Suche, Re-ID-Risikobewertung, Audit-Trails oder SIEM-Tools (Splunk ES) integriert – all das ist bei FieldShield/DarkShield in der IRI Workbench enthalten. 8) TDE ist nicht in Testdaten-Provisionierungssysteme für DevOps integriert; FieldShield und RowGen integrieren sich direkt in Testdaten-Hubs, Web-Services oder virtualisierte DB-Cloning-Tools (Actifio, Commvault, Windocks).
Automatische Erkennung sensibler Daten & Beziehungen: Oracle erkennt Spalten mit sensiblen Infos über eingebaute Muster (nationale IDs, Kreditkarten, PII) sowie Eltern-Kind-Beziehungen. Die Eclipse-basierte IRI-Workbench-IDE deckt alle Discovery-Funktionen ab – DB-Profiling (Statistik, Integritätsprüfung, Wertsuche), schemaweite PII-Suche/-Klassifizierung und ER-Diagramme für Oracle und andere RDBs über FieldShield; hinzu kommt ML-/NLP-basierte Named-Entity-Recognition (bereits in DarkShield für unstrukturierte Daten). Umfangreiche Maskierungsformat-Bibliothek & Templates: Oracle bietet vordefinierte Formate und ladbare Templates für ausgewählte Oracle-Anwendungen. IRI bietet dasselbe und mehr: wähl- und anpassbare Muster für NID, Kreditkarten, Telefonnummern usw. sowie Testdaten-Funktionen für rechnerisch valide NIDs; zwar ohne Oracle-spezifische Download-Templates, aber mit eigenen Formaten und 14 Kategorien von Maskierungsfunktionen für jede Oracle-Version. Umfassende Maskierungs-Transformationen: Oracle deckt bedingte Maskierung, konsistente Ausgaben u. a. ab. FieldShield bietet mehr Funktionen und wahrt Konsistenz/referenzielle Integrität über ad-hoc- oder gespeicherte Regeln (gemusterte Spaltennamen oder muster-/wertbasierte Datenklassen); IRI Workbench bietet zusätzlich mehr Job-Design-/Management-Optionen. Multi-Faktor-Subsetting: Oracle erzeugt Subsets nach Größe, Zeilenanteil oder Bedingungen. Ein DB-Subsetting-Assistent ist in IRI-Voracity-Abos enthalten und erzeugt automatisch referenziell korrekte, maskierte/unmaskierte Subsets jedes verbundenen Schemas; zudem ist robuste Testdaten-Generierung von Grund auf mit realistischen Bedingungen definierbar. Schnell, sicher, heterogen: Oracle maskiert/subsettiert auf Klonen oder beim Export. IRI dasselbe und mehr: maskierte/subsettierte Ziele gehen an alternative Tabellen (in IRI Workbench erstellbar), Cloning/Maskierung via Commvault/Actifio-Snapshots möglich; Voracity-Nutzer führen zusätzlich Transformation, Migration und Cleansing im Maskierungsjob aus. Darüber hinaus bietet IRI FieldShield/Voracity 15 weitere, nur dort verfügbare Maskierungs- und verwandte Funktionen.
Nachdem Sie PII in der kostenlosen, Eclipse-basierten IRI Workbench gefunden und klassifiziert haben, deklarieren Sie ad hoc und/oder per Regel feldbezogene Schutzfunktionen in FieldShield oder anderen SortCL-kompatiblen Jobs. Diese statischen Maskierungsfunktionen liefern feldgeschützte Sichten sensibler Daten (SV-Nummern, Telefonnummern, Gehälter, medizinische Codes) in ODBC-verbundenen DB-Tabellen und sequentiellen Dateien über rund 14 Techniken-Kategorien: Feld-Filterung (Entfernen), String-Manipulation/-Maskierung (Schwärzung), Quasi-Identifier-Generalisierung, sichere Ver-/Entschlüsselung, umkehrbare und nicht-umkehrbare Pseudonymisierung, ASCII-De-/Re-ID, Encoding und Byte-Shifting. Die konsistente Anwendung dieser Funktionen (auf Basis von Datenklassen oder Spaltennamen-Regeln) wahrt die referenzielle Integrität. Weitere Wege in Voracity: der eingebaute DB-Subsetting-Assistent (auch mit Maskierung) oder strukturell/referenziell korrekte synthetische Testdaten über den RowGen-DB-Testdaten-Assistenten.
Ja. Sie können mit FieldShield PII auf Spalten- oder Zeilenebene entfernen (schwärzen, weglassen, löschen) oder randomisieren (Zufallserzeugung/-auswahl als Ersatz), statt sie nur zu verschleiern (z. B. per Verschlüsselung/Blurring). Ziel kann eine neue Tabelle gleicher Struktur in einem anderen Schema sein, das Sie in IRI Workbench – zugleich eine plattformübergreifende DB-Administrationsumgebung – erstellen, aufbauen und laden.
Beides, wobei Letzteres üblicher ist. Für In-Place deklarieren Sie einfach das Ziel als die Quelle. Wir empfehlen das erst nach Testen der Ausgabe (z. B. kleine Testdatei oder stdout), um Format/Erscheinung und Funktionalität (etwa Umkehrbarkeit per Entschlüsselung) zu prüfen, falls Sie kein Backup haben.
Fehler werden mit Begründung protokolliert. Passen Sie die Regel format­erhaltend oder schema-konform an und führen Sie dann „Mask Only“ mit den vorherigen Annotationen aus, um ohne erneutes Scannen zu korrigieren.
In IRI-Maskierungsprodukten (FieldShield, CellShield, DarkShield) bedeutet Pseudonymisierung das Ersetzen einer Identität durch eine andere – die Werte können konsistent und reproduzierbar sein, manche umkehrbar/wiederherstellbar, andere zufällig. Alle Pseudonymisierungs-Techniken benötigen eine Set-Datei mit Ersatzwerten. Für konsistente Ersetzung braucht es zwei durch Tab getrennte Spalten (ein „Lookup-Set“ bzw. Ihren Crosswalk): Jeder mögliche Wert der ungeschützten Spalte muss links stehen, gefolgt von Tab und dem eindeutigen Ersatzwert; die Datei muss nach der linken Spalte sortiert sein. In manchen Fällen kann die Anwendung die Set-Dateien auf Basis vorhandener Daten (und optional einer Ersatzwert-Liste) selbst erzeugen – nicht jedoch, wenn Pseudonymisierung per nicht-datenspezifischer Regel erfolgt. Ersatzwerte lassen sich per Datei angeben oder durch Mischen der Originalwerte gewinnen; bei kleinen Datensätzen empfiehlt sich eine separate Set-Datei, bei großen (Namen, Straßen, Städte) genügt oft eine gemischte Version der Originalwerte.
Ja, gleichzeitig. IRI CoSort (via SortCL) bzw. IRI Voracity (via SortCL oder austauschbare Hadoop-Engines) können feldbezogene Sicherheit im Zuge von Integrations-, Datenqualitäts- und Reporting-Jobs durchsetzen. Im selben Produkt, Programm und I/O-Durchlauf können Sie also PII maskieren/schwärzen, verschlüsseln, pseudonymisieren oder anderweitig de-identifizieren, während Sie Daten aus heterogenen Quellen transformieren, bereinigen und umformen. Klassische ETL-/BI-Tools schaffen das nicht so effizient oder günstig. In Voracity können Sie Daten zugleich verarbeiten (integrieren, bereinigen), schützen (maskieren) und präsentieren (Report/Analyse) oder aufbereiten. Alternativ schützen IRI-Maskierungsprogramme statische Quellen (oder Sie rufen die API dynamisch auf), um nur bestimmte Felder zu sichern, die Ihre bestehende Plattform dann transformiert oder visualisiert – so nutzen Sie Ihren Code weiter, schützen nur die nötigen Felder und halten geschützte wie ungeschützte Daten verfügbar.
Es gibt mehrere; beginnen Sie mit der aktuellsten Methode „PII in MongoDB und Cassandra mit DarkShield maskieren“ (4. IRI-Methode). Gerne beraten wir Sie dazu: Kontakt.
Die Aufruf-Optionen sind flexibel. Speicherplatz kann relevant werden, wenn maskierte Ziele zurück in begrenzten SharePoint-Speicher geschrieben werden – das ist aber nicht nötig (Ziele können lokal oder in anderen Cloud-Stores wie Azure Blob liegen). Sie können die konfigurierten Jobs also planen oder ad hoc aus GUI, CLI oder per API-Aufruf ausführen.
Es hängt von der Excel-Version ab (nicht vom Betriebssystem). Die CellShield-COM-Plug-ins müssen zur Excel-Version passen. So prüfen Sie Ihre Office-Version: Office-Programm starten → Registerkarte „Datei“ → links „Hilfe“ (bzw. „Konto“ ab Office 2013) → Abschnitt „Info zu Microsoft [Programm]“ → Versionsinfo oben (z. B. „… 32-bit“) ansehen. Hinweis: Auch unter 64-Bit-Windows nutzen Sie nicht zwingend ein 64-Bit-Office.
IRI wird eine Web-Anwendung als Ergänzung zum bisherigen Thick-Client (IRI Workbench) bereitstellen, aber vermutlich nie Software auf einer von IRI kontrollierten Infrastruktur. Grund: IRI-Kunden wollen Kontrolle über ihre Daten, und IRI möchte weder die Haftung für deren Speicherung noch die Kosten von SOC2-/FedRAMP-Zertifizierungen. Technisch lässt sich IRI-Software schon heute als rudimentäres SaaS betreiben – via VM/RDP in Ihrer Cloud (inkl. DarkShield-API im Container) und kommerziell per Pay-Go-Abo. Zudem unterstützt DarkShield V7 granularere, volumenbasierte Lizenzgebühren für alle Quelltypen.
Die DarkShield-Service-Parameter selbst bestimmen die Ressourcen nicht – es hängt vom Setup ab, besonders davon, wo Sie die API hosten. DarkShield skaliert bei Dateien gut und linear im Volumen und unterstützt Load-Balancing über mehrere Knoten. Allgemeine Mindest-Ressourcen-Empfehlungen für IRI-Software finden sich in dieser FAQ.
Es werden keine Daten aus dem CellShield-Plugin übertragen. CellShield und die anderen IRI-Produkte zur PII-Erkennung und statischen Maskierung stellen keine Verbindung her und benötigen keine.
FieldShield, CellShield und DarkShield (sowie CoSort) und damit Voracity liefern mehrere 128- und 256-Bit-Verschlüsselungsbibliotheken mit bewährten, konformen Algorithmen (3DES, AES, GPG, OpenSSL). Für jedes PII-Element oder jeden Teilstring nutzen Sie dieselbe oder eine andere eingebaute Routine oder binden Ihre eigene Bibliothek als benutzerdefinierte feldbezogene Funktion ein; auch derselbe Algorithmus mit unterschiedlichem Schlüssel je Feld ist möglich. Schlüsselverwaltung erfolgt über Passphrasen im Job-Skript, sichere Dateien und Umgebungsvariablen sowie Drittanbieter-Vaults (Azure Key Vault, Townsend Alliance Key Manager).
Wer Zugriff auf Maskierungsjobs hat, ist meist eine Frage der Software-/Job-Verteilung (z. B. Kontrolle über IRI-Projekte/-Jobs in Git). Admin- oder Endnutzer-Maskierung kann von der lokalen Desktop-GUI, per vorbereitetem CLI-Befehl oder aus einem Drittprogramm via CLI/API erfolgen – die Zugriffssteuerung ist damit eine Systemadministrations-Funktion (wer erhält GUI-/API-Zugang). In verteilten Umgebungen kann die DarkShield-API auf demselben Rechner wie IRI Workbench, auf einem anderen Windows-/Linux-System oder in einem Linux-Container (on-prem/Cloud) liegen, was Rollentrennung als Netzwerk-Administrationsfunktion ermöglicht. Die künftige Web-App-Roadmap sieht feinere Rollentrennung/Job-Governance in einem eigenständigeren Portal vor.
Alle FieldShield- und CoSort/SortCL-Job-Skripte und feldbezogenen Funktionen lassen sich in XML-Audit-Logs aufzeichnen, die Sie absichern und mit Ihrem bevorzugten XML-Reporting-Tool abfragen können (auch per SortCL-Skript gegen die Logs; Beispiele werden mitgeliefert). In CoSort 11 kann ein noch robusteres JSON-Audit-Log gemäß einer Governance-Richtlinie erzeugt und per Data-Wrangling-Tool ausgewertet werden. IRI DarkShield erzeugt mehrere Logs für Such- und Maskierungsoperationen.
Ja, z. B. nach Splunk – auf mehrere Arten. Siehe Artikel wie „Revealing Data Profiling Secrets in Splunk“, „Automatically Forward Target or Log Data into Splunk“ und „Shedding Light on Dark Data with Splunk ES“.