ansible-role-infosvr-metadata-asset-manager

Ansible-Rolle zur Automatisierung der Bereitstellung von Metadaten mit IBM Metadata Asset Manager-Brokern und -Brücken.

Neu bei Ansible? Diese einfache Einführung könnte hilfreich sein.

Anforderungen

• Ansible v2.4.x
• 'dsadm'-fähiger Netzwerkzugang zu einer IBM Information Server-Umgebung
• Inventargruppennamen müssen gleich wie bei der Rolle IBM.infosvr eingerichtet sein

Rollenvariablen

Siehe defaults/main.yml für die Dokumentation und das Beispiel unten für die wichtigsten benötigten Variablen.

Jeder Broker und jede Brücke hat ein eigenes Set an Parametern. Diese sind in den YAML-Dateien unter vars/ detaillierter dokumentiert, und die grundlegenden Anforderungen für alle Broker und Brücken sind in vars/simple_examples.yml dokumentiert. Im Laufe der Zeit ist das Ziel, alle Broker und Brücken funktionsfähig zu machen, aber die Liste wird schrittweise wachsen -- erwarten Sie, dass nur die in vars/ für eine bestimmte Version dieser Rolle enthaltenen Broker und Brücken funktionieren.

Beispiel-Playbook

Die Rolle soll hauptsächlich in andere Playbooks importiert werden, wenn Metadaten bereitgestellt werden sollen -- durch einen der unterstützten Broker und Brücken in der Information Server-Umgebung. (Daher die Notwendigkeit für Ansible v2.4.x und das import_role-Modul.)

Das folgende Beispiel wird:

1. Die DB2-Treiber, die mit dem Information Server geliefert werden, zur JDBC-Konfiguration hinzufügen.
2. Eine Datenverbindung namens AutoJDBC erstellen (falls sie noch nicht existiert), um eine DB2-Datenbank namens MYDB auf myhost.somewhere.com zu verbinden. (benötigt Information Server v11.7+)
3. Ein Importbereich erstellen und die Importierung für Metadaten von Dateien durchführen, die im Verzeichnis /data/loadable im Dateisystem der Information Server-Engine gefunden wurden (und den Hostnamen, auf dem sie gefunden wurden, als 'IS-SERVER.IBM.COM' dokumentieren).
4. Für das Schema DB2INST1 von MYDB über die Verbindung AutoJDBC alle Metadaten (z.B. für Tabellen, Spalten) automatisch importieren, dann eine Spaltenanalyse durchführen, automatisch Begriffszuweisungen erkennen, eine Datenqualitätsanalyse durchführen und die Ergebnisse, sobald sie abgeschlossen sind, im Information Governance Catalog veröffentlichen. (benötigt Information Server v11.7+)

Beachten Sie, dass die Reihenfolge, in der die Variablen definiert sind, nicht wichtig ist -- die Rolle kümmert sich automatisch um die Ausführung in der richtigen Reihenfolge, damit abhängige Objekte zuerst ausgeführt werden (z.B. wird die JDBC-Konfiguration abgeschlossen, bevor versucht wird, eine Datenverbindung oder Importbereiche herzustellen).

- import_role: name=IBM.infosvr-metadata-asset-manager
  vars:
    import_areas:
      - name: Simple_LocalFileConnector_ImportArea
        type: LocalFileConnector
        description: "Ein einfaches Beispiel (nur erforderliche Felder setzen) für einen LocalFileConnector-Importbereich"
        metadata_interchange_server: myhost.domain.com
        dcn:
          name: LOCALFS
        assets_to_import:
          - "folder[/data/loadable]"
        hostname: "IS-SERVER.IBM.COM"
    jdbc_entries:
      classpaths:
        - /opt/IBM/InformationServer/ASBNode/lib/java/db2jcc.jar
      classnames:
        - com.ibm.db2.jcc.DB2Driver
    data_connections:
      - name: AutoJDBC
        type: JDBCConnector
        description: Datenverbindung für die automatische Entdeckung einer JDBC-Quelle
        url: jdbc:db2://myhost.somewhere.com:50000/MYDB
        username: db2inst1
        password: "{{ a_password_from_eg_vault }}"
    discover_sources:
      - dcn: AutoJDBC
        project: UGDefaultWorkspace
        target_host: myhost.somewhere.com
        steps:
          - import
          - columnAnalysis
          - termAssignment
          - dataQualityAnalysis
          - publish
        parameters:
          rootAssets: schema[MYDB|DB2INST1]
          Asset_description_already_exists: Replace_existing_description

Mögliche Variablen

import_areas

Verwenden Sie diese Variable, um eine Liste (Array) komplexer Strukturen bereitzustellen, von denen jede einen Importbereich für den Metadata Asset Manager definiert. Wenn der Importbereich noch nicht existiert, wird er erstellt und dann geladen; wenn ein Importbereich mit demselben Namen bereits existiert, wird dessen Metadaten erneut importiert (der Importbereich wird nicht ersetzt).

Beispielstrukturen, die vollständig dokumentiert sind, finden Sie unter vars/documented_*.yml. Einfache Strukturen finden Sie unter vars/simple_examples.yml.

data_connections

Nur verfügbar für v11.7+, kann diese Variable verwendet werden, um nur Datenverbindungen anstelle eines vollständigen Importbereichs zu definieren. Dies ist nützlich, wenn Sie beispielsweise die automatisierte Entdeckungsfunktion nutzen möchten, die ab v11.7+ verfügbar ist (d.h. die Fähigkeit des Open Discovery Framework, die Erfassung von Metadaten zu pipeline).

odbc_entries

Verwenden Sie diese Variable, um alle ODBC-Einträge zu definieren, die zu der Datei {DSHOME}/.odbc.ini hinzugefügt werden sollen. Dies ist notwendig, um eine geeignete Konnektivität über ODBC sicherzustellen, z.B. durch die ODBC-Verbindungen in DataStage und IMAM.

Allgemein sind die erforderlichen Schlüssel innerhalb jedes dieser Objekte:

• name: der (einzigartige) Name des ODBC-Eintrags
• description: eine Beschreibung des ODBC-Eintrags (sollte keine Zeichen = enthalten)
• type: der Typ des ODBC-Eintrags, einer von db2, dbase, informix, oracle, oraclewire, sqlserver, sqlservernative, sybase, sybaseiq, salesforce, text, teradata, openedge, mysql, postgres, greenplum, hive, impala
• database: der Name der Datenbank (für RDBMS-Einträge)
• host: der Hostname oder die IP-Adresse des Systems, das die Datenquelle hostet
• port: die Portnummer (für RDBMS-Einträge) -- in der Regel wird dies auch als Standardport für den jeweiligen Datenbanktyp voreingestellt.

Da jeder ODBC-Treiber für verschiedene Plattformen eine Vielzahl plattformspezifischer Optionen unterstützt, können diese ebenfalls (optional) angegeben werden. Siehe die Vorlagen in templates/odbc/*.j2 für die Optionen, die zusätzlich bereitgestellt werden können; alle, die nicht zwingend erforderlich sind (oben aufgeführt), werden automatisch auf ihre Standardwerte in der ODBC-Konfiguration gesetzt, wenn Sie keine anderen Werte angeben.

Wenn Sie schließlich weitere Eigenschaften kennen, die Sie einem bestimmten Eintrag hinzufügen möchten, die keine Standardwerte haben (d.h. nicht bereits in der oben genannten Vorlage aufgeführt sind), fügen Sie diese als Schlüssel-Wert-Paare zu einem extras-Eintrag hinzu.

Beispiele:

odbc_entries:
  - name: IADB on DB2
    description: Verbindung zu IADB auf DB2
    type: db2
    database: IADB
    host: infosvr.vagrant.ibm.com
  - name: Testdatenbank auf Oracle
    description: Verbindung zu einem Testdatensatz auf Oracle
    type: oracle
    database: TESTDB
    host: infosvr.vagrant.ibm.com
    SID: TESTDB
    extras:
      - QueryTimeout: -1
      - ColumnSizeAsCharacter: 1
      - ColumnsAsChar: 1

jdbc_entries

Verwenden Sie diese Variable, um alle JDBC-Klassen zu definieren, die in die Datei {DSHOME}/isjdbc.config aufgenommen werden sollen. Dies ist notwendig, um eine geeignete Konnektivität über JDBC sicherzustellen, z.B. durch die JDBC-Verbindungen in DataStage und IMAM.

Es sind zwei Unter-Schlüssel erforderlich:

• classpaths: definiert die Standorte aller Java-Klassen, die zum CLASSPATH hinzugefügt werden sollen, d.h. die JDBC-Treiber bereitstellen.
• classnames: definiert die Namen der Java-Klassen, die die JDBC-Treiber in den oben genannten classpaths bereitstellen.

Die Rolle wird sicherstellen, dass alle classpaths oder classnames, die nicht bereits in der Konfigurationsdatei enthalten sind, hinzugefügt werden, und wird alle, die bereits vorhanden sind, unbeeinflusst lassen.

Beispiele:

jdbc_entries:
  classpaths:
    - "{{ ibm_infosvr_metadata_asset_mgr_install_location }}/ASBNode/lib/java/db2jcc.jar"
  classnames:
    - com.ibm.db2.jcc.DB2Driver

osh_schemas

Verwenden Sie diese Variable, um DDL-Dateien (die CREATE TABLE-Anweisungen enthalten) zu definieren, die verwendet werden sollen, um OSH-Schema-Dateien für Datendateien zu generieren, die denselben Inhalt wie die Datenbanktabellen erfassen würden.

Alle Parameter sind erforderlich, außer dem Parameter tables -- wenn er nicht angegeben ist, wird ein OSH-Schema für jede CREATE TABLE-Anweisung generiert, die in der angegebenen ddl gefunden wird.

Dadurch werden folgende Dateien erstellt:

• eine (leere) Datendatei unter dem angegebenen dest-Verzeichnis für jede CREATE TABLE-Anweisung in der angegebenen ddl (eingeschränkt durch die in der optionalen tables-Variable definierten Tabellen), unter Verwendung der angegebenen fileext als Dateierweiterung
• eine OSH-Schemadatei unter dem gleichen angegebenen dest-Verzeichnis für jede erstellte leere Datendatei, die .osh als zusätzliche Dateierweiterung anhängt.

Beispiele:

osh_schemas:
  - ddl: /some/location/MYDB.sql
    structure: "file_format: 'delimited', header: 'false'"
    recordfmt: "delim='|', final_delim=end, null_field='', charset=UTF-8"
    dest: /some/target/directory
    fileext: csv
    tables:
      - TABLE1
      - TABLE2

Das obige Beispiel wird erstellen:

• /some/target/directory/TABLE1.csv
• /some/target/directory/TABLE1.csv.osh
• /some/target/directory/TABLE2.csv
• /some/target/directory/TABLE2.csv.osh

discover_sources

Verwenden Sie diese Variable, um Datenquellen zu definieren, die mit dem Open Discovery Framework in v11.7+ automatisch entdeckt werden sollen.

Die folgenden Unter-Schlüssel sind für jeden Eintrag erforderlich:

• dcn: gibt den Namen der Datenverbindung an, die für die Entdeckung verwendet werden soll.
• project: gibt den Namen des Information Analyzer-Projekts an, in dem die Entdeckung stattfinden soll.
• target_host: gibt den Hostnamen an, der für die Quelle verwendet werden soll, die entdeckt wird.

Die restlichen Unter-Schlüssel sind optional:

• parameters: stellt eine Gruppe von Unter-Schlüsseln bereit, die zusätzliches Verhalten oder Einschränkungen definieren, die auf die Entdeckung angewendet werden sollen, z.B.:
  • rootAssets: definiert die Teilmenge der Assets, für die die Entdeckung durchgeführt werden soll (ohne die alle Assets auf dem Ziel entdeckt werden -- z.B. alle Dateien in allen Verzeichnissen, alle Tabellen über alle Schemata).
  • Asset_description_already_exists: definiert, wie die Situation zu behandeln ist, wenn ein bestimmtes technisches Asset mit derselben Identität bereits existiert.
  • andere Parameter sind ebenfalls möglich, je nach Art der Quelle -- siehe das Knowledge Center des Information Server für weitere Details.
• steps: gibt an, welche Schritte des Entdeckungsprozesses angewendet werden sollen, und kann Folgendes umfassen:
  • import: entdeckt und übernimmt die technischen Metadaten für die Quelle in das Information Governance Catalog.
  • columnAnalysis: führt eine Spaltenanalyse für die Quelle durch, bestimmt Formate, Häufigkeitsverteilungen der Werte und erkennt Datenklassen (abhängig vom durchgeführten import).
  • termAssignment: versucht, automatisch Geschäftstermine zu erkennen, um sie den technischen Metadaten basierend auf ihren erkannten Datenklassen, Spaltennamen und vorherigen Beziehungen zuzuordnen, die das System gelernt hat (wenn konfiguriert) (abhängig von der durchgeführten columnAnalysis), einschließlich der Anwendung von Automatisierungsregeln, die automatisch Datenregeln basierend auf den zugeordneten Begriffen zuweisen.
  • dataQualityAnalysis: führt eine Reihe von Standardqualitätsprüfungen durch, z.B. das Suchen nach Ausreißerwerten und alle automatisch zugewiesenen Datenregeln.
  • publish: veröffentlicht die Ergebnisse aller anderen Schritte im Information Governance Catalog.

Beachten Sie, dass bis zum letzten publish-Schritt alle Arbeiten in einem unveröffentlichten Zustand im Information Analyzer-Projekt/Workspace gehalten wurden. Nach der Veröffentlichung sind alle verschiedenen Analysen für jeden im Information Governance Catalog sichtbar. Sie möchten diesen letzten publish-Schritt möglicherweise weglassen, um eine Überprüfung (und eine manuelle Entscheidung zur Veröffentlichung) im Information Analyzer zu erzwingen. (Standardmäßig, wenn die Schritte nicht angegeben sind, umfasst die Entdeckung alle Schritte, außer den publish-Schritt.)

Seien Sie auch darauf vorbereitet, dass das Format schema[DBNAME|SCHEMA] für die rootAssets im Zusammenhang mit JDBC-Verbindungen möglicherweise spezielle Werte für den DBNAME-Teil (z.B. bei DB2, da die Datenbank im URL, die Teil der Datenverbindung ist, enthalten ist, geben Sie hier immer db2 als DBNAME an, anstelle des tatsächlichen Datenbanknamens).

Beispiele:

discover_sources:
  - dcn: AutoJDBC
    project: UGDefaultWorkspace
    target_host: myhost.somewhere.com
    steps:
      - import
      - columnAnalysis
      - termAssignment
      - dataQualityAnalysis
      - publish
    parameters:
      rootAssets: schema[MYDB|DB2INST1]
      Asset_description_already_exists: Replace_existing_description

Lizenz

Apache 2.0

Autor Informationen

Christopher Grote