ansible-role-infosvr-metadata-asset-manager

Роль Ansible для автоматизации развертывания метаданных с использованием брокеров и мостов IBM Metadata Asset Manager.

Новичок в Ansible? Это простое введение может помочь.

Требования

• Ansible v2.4.x
• Доступ по сети с правами 'dsadm' к среде IBM Information Server
• Названия групп инвентаризации должны быть настроены точно так же, как роль IBM.infosvr

Переменные роли

Смотрите defaults/main.yml для документации и пример ниже для основных необходимых переменных.

Каждый брокер и мост имеют свой уникальный набор параметров. Они подробно описаны в каждом из файлов YAML в папке vars/, а минимальные требования для всех брокеров и мостов зафиксированы в vars/simple_examples.yml. Со временем планируется подключить всех брокеров и мостов, но список будет постепенно увеличиваться - ожидайте, что только те, которые включены в vars/ для данной версии роли, будут работать.

Пример плейбука

Роль в первую очередь предназначена для импорта в другие плейбуки по мере необходимости для развертывания метаданных — через любые поддерживаемые брокеры и мосты в среде Information Server. (Таким образом, возникает необходимость в Ansible v2.4.x и модуле import_role.)

Следующий пример:

1. Добавит драйверы DB2, включенные в Information Server, в конфигурацию JDBC.
2. Создаст подключение к данным с именем AutoJDBC (если оно еще не существует) для подключения к базе данных DB2 с именем MYDB на myhost.somewhere.com. (требуется Information Server v11.7+)
3. Создаст область импорта и выполнит импорт метаданных любых файлов, найденных в /data/loadable на файловой системе уровня движка Information Server (и зафиксирует имя хоста, на котором они найдены, как 'IS-SERVER.IBM.COM').
4. Для схемы DB2INST1 базы данных MYDB на подключении AutoJDBC автоматически импортирует любые метаданные (например, таблицы, столбцы), затем выполнит анализ столбцов, определит назначение терминов, запустит анализ качества данных и, после завершения, опубликует любые результаты в Information Governance Catalog. (требуется Information Server v11.7+)

Обратите внимание, что порядок определения переменных не имеет значения — роль автоматически позаботится о запуске их в нужном порядке, чтобы сначала выполнялись зависимые объекты (например, конфигурация JDBC завершается перед попыткой выполнить любое подключение к данным или области импорта).

- import_role: name=IBM.infosvr-metadata-asset-manager
  vars:
    import_areas:
      - name: Simple_LocalFileConnector_ImportArea
        type: LocalFileConnector
        description: "Простой пример (установлены только обязательные поля) для области импорта 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: Подключение к данным для автоматического обнаружения источника 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

Возможные переменные

import_areas

Используйте эту переменную для предоставления списка (массивов) сложных структур, каждая из которых определяет область импорта для Metadata Asset Manager. Если область импорта еще не существует, она будет создана и загружена; если область импорта с таким же именем уже существует, ее метаданные будут импортированы заново (область импорта не будет заменена).

Примеры структур полностью задокументированы в vars/documented_*.yml. Простые структуры можно найти в vars/simple_examples.yml.

data_connections

Доступна только для v11.7+, эта переменная может быть использована для определения только подключений к данным, а не полной области импорта. Это полезно, если, например, вы хотите использовать автоматическую возможность Discovery, доступную начиная с v11.7+ (т.е. используя способность Open Discovery Framework к сбору метаданных, за которой следует автоматизированный анализ столбцов и т.д.).

odbc_entries

Используйте эту переменную для определения любых записей ODBC, которые должны быть добавлены в файл {DSHOME}/.odbc.ini. Это необходимо, чтобы обеспечить надлежащее подключение через ODBC, например, через ODBC-соединения в DataStage и IMAM.

Как правило, требуемые ключи в каждом из этих объектов:

• name: уникальное имя записи ODBC
• description: описание записи ODBC (не должно содержать символ = где-либо)
• type: тип записи ODBC, один из db2, dbase, informix, oracle, oraclewire, sqlserver, sqlservernative, sybase, sybaseiq, salesforce, text, teradata, openedge, mysql, postgres, greenplum, hive, impala
• database: имя базы данных (для записей RDBMS)
• host: имя хоста или IP-адрес системы, на которой размещен источник данных
• port: номер порта (для записей RDBMS) — как правило, это также будет установить значение по умолчанию для данного типа базы данных

Поскольку каждый драйвер ODBC для разных платформ поддерживает различные специфические для платформы параметры, их также можно (по желанию) указать. Смотрите шаблоны в templates/odbc/*.j2 для дополнительных параметров; любые, которые не являются обязательными (перечислены выше), автоматически устанавливаются на их значения по умолчанию в конфигурации ODBC, если вы не укажете для них другие значения.

Наконец, если вы знаете о дополнительных свойствах, которые хотите добавить к определенной записи, которые не имеют значений по умолчанию (т.е. которые уже не перечислены в вышеупомянутом шаблоне), добавьте их в запись extras в виде пар "ключ-значение".

Примеры:

odbc_entries:
  - name: IADB on DB2
    description: Подключение к IADB на DB2
    type: db2
    database: IADB
    host: infosvr.vagrant.ibm.com
  - name: Тестовая база данных на Oracle
    description: Подключение к некоторому тестовому набору данных на Oracle
    type: oracle
    database: TESTDB
    host: infosvr.vagrant.ibm.com
    SID: TESTDB
    extras:
      - QueryTimeout: -1
      - ColumnSizeAsCharacter: 1
      - ColumnsAsChar: 1

jdbc_entries

Используйте эту переменную, чтобы определить любые классы JDBC, которые должны быть включены в файл {DSHOME}/isjdbc.config. Это необходимо для обеспечения надлежащих соединений через JDBC, например, через JDBC-соединения в DataStage и IMAM.

Требуются два под-ключа:

• classpaths: определяет местонахождения любых Java-классов, которые должны быть добавлены в CLASSPATH, т.е. которые предоставляют драйверы JDBC
• classnames: определяет имена Java-классов, которые предоставляют драйверы JDBC в указанных выше classpaths

Роль обеспечит добавление любых classpaths или classnames, которые еще не включены в конфигурационный файл, и оставит те, которые уже присутствуют.

Примеры:

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

osh_schemas

Используйте эту переменную, чтобы определить любые DDL файлы (содержащие операторы CREATE TABLE), которые должны быть использованы для генерации файлов схемы OSH для файлов данных, которые будут захватывать такое же содержание, как таблицы базы данных.

Все параметры обязательны, за исключением параметра tables — если он не указан, будет сгенерирована схема OSH для каждого оператора CREATE TABLE, найденного в указанном ddl.

Это создаст следующее:

• один (пустой) файл данных в указанном каталоге dest для каждого оператора CREATE TABLE в указанном ddl (ограниченный таблицами, определенными в необязательном параметре tables), используя указанный fileext в качестве расширения файла
• один файл схемы OSH в том же указанном каталоге dest для каждого созданного пустого файла данных, добавляя .osh как дополнительное расширение файла

Примеры:

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

Пример выше создаст:

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

discover_sources

Используйте эту переменную, чтобы определить любые источники данных, которые должны быть автоматически обнаружены с использованием Open Discovery Framework в v11.7+

Следующие под-ключи обязательны для каждой записи:

• dcn: указывает название соединения с данными, которое следует использовать для открытия
• project: указывает название проекта Information Analyzer, в котором будет происходить обнаружение
• target_host: указывает имя хоста, которое следует использовать для источника, который обнаруживается

Остальные под-ключи являются необязательными:

• parameters: предоставляет набор под-ключей, определяющих дополнительное поведение или ограничения, которые следует применить к обнаружению, например:
  • rootAssets: определяет подмножество активов, для которых необходимо выполнить обнаружение (в противном случае будут обнаружены все активы на целевом объекте — например, все файлы во всех каталогах, все таблицы по всем схемам)
  • Asset_description_already_exists: определяет, как обрабатывать ситуацию, когда конкретный технический актив с такой же идентичностью уже существует
  • другие параметры также возможны в зависимости от типа источника — смотрите справочный центр по Information Server для более подробной информации
• steps: указывает, какие шаги процесса открытия должны быть применены, и может включать:
  • import: обнаруживает и захватывает технические метаданные для источника в Catalog управления информацией
  • columnAnalysis: проводит анализ столбцов для источника, определяя форматы, частоты распределения значений и определяя классы данных (зависит от выполнения import)
  • termAssignment: пытается автоматически определить бизнес-термины для назначения техническим метаданным на основании их обнаруженных классов данных, имен столбцов и предыдущих отношений, из которых система извлекла вывод (если настроено) (зависит от выполнения columnAnalysis), включая применение любых Правил автоматизации, которые автоматически назначают правила данных на основе заданных терминов
  • dataQualityAnalysis: проводит ряд стандартных проверок качества, например, проверяя на выбросы и любые правила данных, которые были автоматически назначены
  • publish: публикует результаты всех других шагов в Catalog управления информацией

Обратите внимание, что до последнего шага publish вся работа оставалась в неопубликованном состоянии в проекте / рабочем пространстве Information Analyzer. После публикации все различные анализы становятся видимыми для всех в Catalog управления информацией. Поэтому вы можете пожелать пропустить последний шаг publish, чтобы принудительно провести проверку (и вручную решить о публикации) в Information Analyzer. (По умолчанию, если шаги не указаны, обнаружение будет включать все шаги, кроме шага publish.)

Также имейте в виду, что формат schema[DBNAME|SCHEMA] в параметре rootAssets, применяемый к соединениям JDBC, может потребовать специальных значений для части DBNAME (например, для DB2, поскольку база данных является неотъемлемой частью URL, предоставленного в составе соединения с данными, вы всегда указываете db2 в качестве DBNAME здесь, а не фактическое имя базы данных).

Примеры:

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

Лицензия

Apache 2.0

Информация об авторе

Кристофер Гроте