ansible-role-infosvr-metadata-asset-manager

Rola Ansible do automatyzacji wdrażania metadanych za pomocą brokerów i mostów IBM Metadata Asset Manager.

Nowy w Ansible? To proste wprowadzenie może pomóc.

Wymagania

• Ansible v2.4.x
• Dostęp sieciowy z uprawnieniami 'dsadm' do środowiska IBM Information Server
• Nazwy grup inwentaryzacyjnych skonfigurowane tak samo jak w roli IBM.infosvr

Zmienne ról

Szczegóły znajdują się w pliku defaults/main.yml, a poniżej przykłady głównych potrzebnych zmiennych.

Każdy broker i most ma swój unikalny zestaw parametrów. Szczegóły dokumentacji można znaleźć w plikach YAML w folderze vars/, a minimalne wymagania dla wszystkich brokerów i mostów są opisane w vars/simple_examples.yml. Z biegiem czasu planowane jest, aby wszystkie brokery i mosty działały, ale lista będzie stopniowo rosła – oczekuj, że tylko te zawarte w vars/ dla danej wersji tej roli będą działać.

Przykładowy Playbook

Rola jest przede wszystkim przeznaczona do importu do innych playbooków w razie potrzeby do wdrożenia metadanych – poprzez dowolnego z obsługiwanych brokerów i mostów w środowisku Information Server. (Dlatego wymagana jest wersja Ansible v2.4.x i moduł import_role).

Poniższy przykład wykona:

1. Doda sterowniki DB2 zawarte w Information Server do konfiguracji JDBC.
2. Utworzy połączenie danych o nazwie AutoJDBC (jeśli już nie istnieje), aby połączyć się z bazą danych DB2 o nazwie MYDB na myhost.somewhere.com. (wymaga Information Server v11.7+)
3. Utworzy obszar importu i wykona import dla metadanych plików znajdujących się w /data/loadable w systemie plików silnika Information Server (i zapisze nazwę hosta, na którym je znaleziono jako 'IS-SERVER.IBM.COM').
4. Dla schematu DB2INST1 w MYDB na połączeniu AutoJDBC, automatycznie zaimportuje wszelkie metadane (np. dla tabel, kolumn), następnie przeprowadzi analizę kolumn, automatycznie wykryje przypisania terminów, przeprowadzi analizę jakości danych, a po zakończeniu opublikuje wszelkie wyniki w Katalogu Zarządzania Danymi. (wymaga Information Server v11.7+)

Należy zauważyć, że kolejność definiowania zmiennych nie ma znaczenia – rola automatycznie zadba o ich wykonanie we właściwej kolejności, tak aby obiekty zależne były realizowane jako pierwsze (np. konfiguracja JDBC jest ukończona zanim spróbuje się nawiązać jakiekolwiek połączenie danych lub obszary importu).

- import_role: name=IBM.infosvr-metadata-asset-manager
  vars:
    import_areas:
      - name: Simple_LocalFileConnector_ImportArea
        type: LocalFileConnector
        description: "Prosty przykład (ustawiając tylko wymagane pola) dla obszaru importu LocalFileConnector"
        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: Połączenie danych do automatycznego odkrywania źródła JDBC
        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

Możliwe zmienne

import_areas

Użyj tej zmiennej, aby podać listę (tablicę) złożonych struktur, z których każda definiuje obszar importu dla Metadata Asset Manager. Jeśli obszar importu jeszcze nie istnieje, zostanie utworzony i załadowany; jeśli obszar importu o tej samej nazwie już istnieje, jego metadane zostaną ponownie zaimportowane (obszar importu nie zostanie zastąpiony).

Przykłady struktur, w pełni udokumentowane, można znaleźć w plikach pod vars/documented_*.yml. Proste struktury znajdują się w vars/simple_examples.yml.

data_connections

Dostępna tylko dla v11.7+, ta zmienna może być używana do definiowania jedynie połączeń danych, a nie pełnego obszaru importu. Jest to przydatne, jeśli na przykład chcesz skorzystać z funkcji automatycznego odkrywania dostępnej od v11.7+ (tj. wykorzystując możliwości Open Discovery Framework do pozyskiwania metadanych, a następnie automatycznej analizy kolumn itd.).

odbc_entries

Użyj tej zmiennej, aby zdefiniować wszelkie wpisy ODBC, które powinny zostać dodane do pliku {DSHOME}/.odbc.ini. Jest to konieczne, aby zapewnić odpowiednią łączność za pomocą ODBC, np. przez połączenia ODBC w DataStage i IMAM.

Wymagane klucze w tych obiektach to:

• name: (unikalna) nazwa wpisu ODBC
• description: opis wpisu ODBC (nie powinien używać znaku = w żadnym miejscu)
• type: typ wpisu ODBC, jeden z db2, dbase, informix, oracle, oraclewire, sqlserver, sqlservernative, sybase, sybaseiq, salesforce, text, teradata, openedge, mysql, postgres, greenplum, hive, impala
• database: nazwa bazy danych (dla wpisów RDBMS)
• host: nazwa hosta lub adres IP systemu hostującego źródło danych
• port: numer portu (dla wpisów RDBMS) – zazwyczaj domyślny dla danego typu bazy danych

Oczywiście niektóre sterowniki ODBC dla różnych platform obsługują różnorodne opcje specyficzne dla danej platformy, co można opcjonalnie określić. Zobacz szablony w templates/odbc/*.j2, aby poznać opcje, które można dodatkowo podać; te, które nie są obowiązkowe (wymienione powyżej) będą automatycznie ustawione na swoje wartości domyślne w konfiguracji ODBC, jeśli nie podasz dla nich innych wartości.

Na koniec, jeśli znasz dodatkowe właściwości, które chcesz dodać do danego wpisu i nie mają one wartości domyślnych (tj. nie są już wymienione w szablonie), dodaj je jako wpis extras w postaci par klucz-wartość.

Przykłady:

odbc_entries:
  - name: IADB na DB2
    description: Połączenie z IADB na DB2
    type: db2
    database: IADB
    host: infosvr.vagrant.ibm.com
  - name: Testowa baza danych na Oracle
    description: Połączenie z przykładowym zbiorem danych na Oracle
    type: oracle
    database: TESTDB
    host: infosvr.vagrant.ibm.com
    SID: TESTDB
    extras:
      - QueryTimeout: -1
      - ColumnSizeAsCharacter: 1
      - ColumnsAsChar: 1

jdbc_entries

Użyj tej zmiennej, aby zdefiniować wszelkie klasy JDBC, które powinny być zawarte w pliku {DSHOME}/isjdbc.config. Jest to konieczne, aby zapewnić odpowiednią łączność za pomocą JDBC, np. przez połączenia JDBC w DataStage i IMAM.

Dwa wymagane podklucze to:

• classpaths: definiuje lokalizacje klas Java, które powinny być dodane do CLASSPATH, tj. które dostarczają sterowniki JDBC
• classnames: definiuje nazwy klas Java, które dostarczają sterowniki JDBC w powyższych classpaths

Rola zapewni, że wszelkie classpaths lub classnames, które nie są już zawarte w pliku konfiguracyjnym, zostaną do niego dodane, a te, które już są, pozostaną bez zmian.

Przykłady:

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

osh_schemas

Użyj tej zmiennej, aby zdefiniować wszelkie pliki DDL (zawierające instrukcje CREATE TABLE), które powinny być używane do generowania plików schematów OSH dla plików danych, które uchwycą tę samą treść, co tabele bazy danych.

Wszystkie parametry są wymagane, z wyjątkiem parametru tables – jeśli nie jest określony, zostanie wygenerowany schemat OSH dla każdej instrukcji CREATE TABLE znalezionej w określonym ddl.

To stworzy:

• jeden (pusty) plik danych w określonym katalogu dest dla każdej instrukcji CREATE TABLE w określonym ddl (ograniczone przez tabele zdefiniowane w opcjonalnym parametrze tables), używając określonego fileext jako rozszerzenia pliku
• jeden plik schematu OSH w tym samym katalogu dest dla każdego z pustych plików danych, dodając .osh jako dodatkowe rozszerzenie pliku

Przykłady:

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

Powyższy przykład stworzy:

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

discover_sources

Użyj tej zmiennej, aby zdefiniować wszelkie źródła danych, które powinny być automatycznie odkrywane za pomocą Open Discovery Framework w wersji v11.7+

Następujące podklucze są wymagane dla każdego wpisu:

• dcn: określa nazwę połączenia danych, które ma być użyte do odkrywania
• project: określa nazwę projektu Information Analyzer, w którym ma nastąpić odkrywanie
• target_host: określa nazwę hosta, która ma być używana dla źródła odkrywanego

Pozostałe podklucze są opcjonalne:

• parameters: dostarcza zestaw podkluczy definiujących dodatkowe zachowanie lub ograniczenia, które mają być nałożone na odkrywanie, np.:
  • rootAssets: definiuje podzbiór zasobów, dla których ma być wykonane odkrywanie (w przeciwnym razie wszystkie zasoby na docelowym hoście będą odkrywane – np. wszystkie pliki w wszystkich katalogach, wszystkie tabele w różnych schematach)
  • Asset_description_already_exists: definiuje, jak postępować w przypadku, gdy pewien zasób techniczny o tej samej tożsamości już istnieje
  • inne parametry są również możliwe w zależności od typu źródła – zobacz Centrum Wiedzy Information Server, aby uzyskać więcej szczegółów
• steps: wskazuje, które kroki procesu odkrywania mają być stosowane, i może obejmować:
  • import: odkrywa i wprowadza metadane techniczne dla źródła do Katalogu Zarządzania Danymi
  • columnAnalysis: przeprowadza analizę kolumn względem źródła, ustalając formaty, częstotliwości występowania wartości oraz wykrywając klasy danych (zależne od wykonania import)
  • termAssignment: próbuje automatycznie wykryć terminy biznesowe do przypisania do metadanych technicznych na podstawie ich wykrytych klas danych, nazw kolumn oraz wcześniejszych relacji, które system już zrozumiał (jeśli skonfigurowano) (zależne od wykonania columnAnalysis), w tym stosując wszelkie Reguły Automatyzacji, które automatycznie przypisują reguły danych na podstawie przypisanych terminów
  • dataQualityAnalysis: przeprowadza standardowe kontrole jakości, np. szukając wartości odstających i wszelkich reguł danych, które zostały automatycznie przypisane
  • publish: publikuje wyniki wszystkich pozostałych kroków do Katalogu Zarządzania Danymi

Należy zauważyć, że do ostatniego kroku publish, wszystkie działania były zachowywane w stanie niepublikowanym w projekcie / przestrzeni roboczej Information Analyzer. Po opublikowaniu wszystkie różne analizy są widoczne dla każdego w Katalogu Zarządzania Danymi. Dlatego możesz chcieć pominąć ten ostatni krok publish, aby wymusić przegląd (i ręczną decyzję o publikacji) w Information Analyzer. (Domyślnie, jeśli kroki nie są określone, odkrywanie będzie obejmować wszystkie kroki oprócz kroku publish).

Zwróć również uwagę, że format schema[DBNAME|SCHEMA] dla rootAssets, stosowany dla połączeń JDBC, może wymagać specjalnych wartości dla części DBNAME (np. dla DB2, ponieważ baza danych jest inherentna w URL podanym jako część połączenia danych, zawsze musisz podać db2 jako DBNAME, a nie rzeczywistą nazwę bazy danych).

Przykłady:

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

Licencja

Apache 2.0

Informacje o autorze

Christopher Grote