Mapping Contract Agent: Робочий процес і артефакти

Mapping Contract Agent є центральним координатором для перекладу даних між вашими джерельними архітектурами та моделями схем. Він визначає та регулює те, як стовпчики, типи та логіка сопоставляються з вхідних схем джерел до цільових визначень, встановлюючи надійний контракт. Агент нативно підтримує автоматизовану документацію, власну бізнес-логіку, генерацію коду SQL та Python, відстеження джерело-ціль (source-to-target), правила перевірки якості даних (DQ), робочі процеси затвердження за участю людини (human-in-the-loop) та контроль версій.

first

Підтримувані можливості мапінгу

Для забезпечення наскрізної оркестрації та управління конвеєрами даних Mapping Contract Agent надає повне покриття життєвого циклу інтеграції:

AUTOMATED DOCS: Миттєво генерує багаті пояснення схем, визначення, обґрунтування мапінгу та документацію для використання розробниками або аудиторами.
BUSINESS LOGIC: Синтезує складні трансформації, функції пошуку (lookup), розрахунки та умовну логіку.
SQL/PYTHON: Генерує нативні конвеєри та скрипти трансформації на ваш вибір у стандартному SQL (для баз даних та сховищ) або Python (для Pandas, Spark або serverless виконання).
SOURCE TO TARGET: Встановлює повну простежуваність на рівні окремих стовпців від схем джерел до цільових схем, забезпечуючи аудитованість.
DQ VALIDATION: Вбудовує автоматизовані обмеження якості даних безпосередньо у згенерований контракт (ліміти порожніх значень, перевірки діапазонів, відповідність форматам).
APPROVAL WORKFLOW: Реалізує шлюз затвердження за участю людини, де зміни повинні бути перевірені та цифровий підписані перед розгортанням у продакшен.
VERSION CONTROL: Керує ревізіями мапінгу за допомогою семантичного версіонування та сумісного з git відстеження контрактів для фіксації всієї історії та змін.

Покроковий операційний робочий процес

Mapping Contract Agent працює в інтерактивному робочому просторі з двома панелями, що дозволяє архітекторам даних та інженерам швидко проєктувати, перевіряти та версіонувати контракти мапінгу.

Крок 1: Підписка на агента

Отримайте доступ до Mapping Contract Agent через каталог платформи:

Перейдіть на платформу Agentpunkt та увійдіть.
Знайдіть Mapping Contract Agent у доступному каталозі.
Оберіть тривалість підписки (7 днів, 14 днів або щомісяця).
Перейдіть на сторінку "Hired Agents", щоб керувати активними підписками.

Крок 2: Ініціалізація сесії робочого простору

Запустіть агента для ініціалізації вашого інтерактивного робочого простору:

Натисніть "Start Session", щоб відкрити інтерактивний інтерфейс із двома панелями.
Ліва панель — це ваша "Інтерактивний чат та історія сесії", де ви спілкуєтеся з агентом, завантажуєте схеми та запитуєте ревізії.
Права панель — це "Візуальний робочий простір та згенерований код", де ви перевіряєте активні контракти мапінгу, трансформації та діаграми.

Крок 3: Надання метаданих джерела та цілі

Ініціалізуйте мапінг шляхом завантаження схем, які ви хочете з'єднати:

У Лівій панелі завантажте схему джерела (згенеровану Data Source Agent) та цільову схему (згенеровану Data Modeling Agent).
Ви також можете завантажити файли власних бізнес-вимог, аркуші мапінгу або застарілі скрипти трансформації.
Надайте інструкції простою мовою. Наприклад: "Будь ласка, зістав наші джерельні таблиці MySQL із аналітичною моделлю Snowflake, переконавшись, що стовпчики з PII маскуються та застосовано стандартну бізнес-логіку."

Крок 4: Перегляд синтезованої карти Source-to-Target

Перевірте семантичні рекомендації агента у Правій панелі:

Агент розбирає назви, описи та розподіл даних для створення чернетки мапінгу Source-to-Target.
Він автоматично додає Automated Docs для кожного вибору мапінгу, пояснюючи, чому він зіставив стовпчик джерела з цільовим стовпчиком.
Перевірте чернетку на наявність невідповідних типів даних або назв.

Крок 5: Застосування власної бізнес-логіки та SQL/Python трансформацій

Налаштуйте деталі трансформації за допомогою діалогових команд:

Запросіть агента в Лівій панелі написати власну бізнес-логіку. Наприклад: "Для загальної ціни помнож ціну за одиницю на кількість і застосуй податковий коефіцієнт 1.15."
Вкажіть бажану мову: SQL (для dbt/Snowflake views) або Python (для виконання в Spark/Pandas).
Агент миттєво регенерує відповідний блок коду трансформації у Правій панелі.

Крок 6: Налаштування шлюзів DQ Validation

Налаштуйте автоматизовані правила якості даних, вбудовані в контракт:

Скажіть агенту, які обмеження є критичними. Наприклад: "Перевір, що email клієнта ніколи не є null, а сума транзакції завжди більша за нуль."
Агент додасть ці правила до контракту мапінгу, гарантуючи, що ваш рушій оркестрації виконає перевірку DQ до завантаження в цільову базу даних.

Крок 7: Виконання робочого процесу затвердження

Забезпечте комплаєнс через формальне затвердження:

Натисніть кнопку "Approve Contract" або введіть "Затвердити поточний мапінг" у чаті.
Система зареєструє ваше ім'я користувача, встановить часову мітку та заморозить стан контракту.
Це створює безпечний аудит-слід того, хто авторизував потік даних.

Крок 8: Контроль версій та експорт у Git

Завершіть сесію експортом версіонованих активів:

Агент призначає семантичну версію (наприклад, v1.1.0) та фіксує історію змін.
Експортуйте фінальний контракт мапінгу як документ YAML або JSON.
Відправте цей файл безпосередньо у ваш Git-репозиторій для відстеження конфігурацій конвеєрів у ситемі контролю версій.

Основні вихідні артефакти

Mapping Contract Agent видає структуровані файли, які слугують прямою конфігурацією для ваших інтеграційних конвеєрів.

1. Визначення контракту мапінгу (YAML)

Цей артефакт містить правила source-to-target, обмеження якості даних та метадані затвердження:

yaml

contract_metadata:
  contract_id: "mc_billing_v1"
  version: "1.1.0"
  status: "APPROVED"
  approved_by: "alex.developer@enterprise.com"
  approved_timestamp: "2026-06-24T17:19:20Z"

source_to_target_mappings:
  - source_field: "src_db.billing.cust_num"
    target_field: "target_warehouse.finance.customer_id"
    description: "Unique account identifier mapped from transactional source system."
    data_quality_rules:
      - rule_type: "NOT_NULL"
      - rule_type: "REGEX_MATCH"
        expression: "^CUST-[0-9]{5}$"

  - source_field: "src_db.billing.unit_val"
    target_field: "target_warehouse.finance.total_amount"
    business_logic: "Multiply unit_val by quantity and apply a tax rate of 1.15."
    transformation_type: "BUSINESS_LOGIC"
    data_quality_rules:
      - rule_type: "MIN_VALUE"
        limit: 0.01

2. Конвеєр трансформації (SQL / Python)

Залежно від вашого вибору, агент створює готовий до розгортання код.

Згенероване SQL View (сумісне з dbt)

sql

-- Generated by Mapping Contract Agent
-- Version: 1.1.0
-- Target Dialect: Snowflake

WITH source_data AS (
    SELECT
        cust_num,
        unit_val,
        quantity,
        load_timestamp
    FROM {{ source('billing_system', 'billing') }}
)

SELECT
    cust_num AS customer_id,
    -- Business Logic transformation
    CAST(unit_val * quantity * 1.15 AS NUMBER(12,2)) AS total_amount,
    CAST(load_timestamp AS TIMESTAMP_NTZ) AS record_timestamp
FROM source_data

Згенерований скрипт Python (сумісний з Spark DataFrame)

python

# Generated by Mapping Contract Agent
# Version: 1.1.0
# Engine: PySpark

from pyspark.sql import functions as F
from pyspark.sql.types import DecimalType, TimestampType

def transform_billing(source_df):
    return source_df.select(
        F.col("cust_num").alias("customer_id"),
        # Business Logic transformation
        (F.col("unit_val") * F.col("quantity") * 1.15)
        .cast(DecimalType(12, 2))
        .alias("total_amount"),
        F.col("load_timestamp").cast(TimestampType()).alias("record_timestamp")
    )

Переваги: Чому це ефективно?

Без хаосу ручних електронних таблиць: Усуває ризик зламаних конвеєрів, спричинених застарілими файлами мапінгу Excel. Все оголошується в машиночитаному контракті з контролем версій.
Миттєва портативність SQL та Python: Дозволяє легко перемикати рівні виконання з SQL баз даних на озерні сховища даних на базі Spark/Python без переписування бізнес-логіки.
Вбудований захист якості: Гарантує, що неякісні дані виявляються до того, як вони потраплять у ваші аналітичні бази даних або бази звітництва, шляхом запису правил DQ безпосередньо у визначення контракту.
Повний аудит-слід: Кожна зміна керована версіями та затверджується з деталями користувача, задовольняючи суворі регуляторні аудити для лінії походження даних та корпоративного комплаєнсу.

Mapping Contract Agent: Робочий процес і артефакти ​

Підтримувані можливості мапінгу ​

Покроковий операційний робочий процес ​

Крок 1: Підписка на агента ​

Крок 2: Ініціалізація сесії робочого простору ​

Крок 3: Надання метаданих джерела та цілі ​

Крок 4: Перегляд синтезованої карти Source-to-Target ​

Крок 5: Застосування власної бізнес-логіки та SQL/Python трансформацій ​

Крок 6: Налаштування шлюзів DQ Validation ​

Крок 7: Виконання робочого процесу затвердження ​

Крок 8: Контроль версій та експорт у Git ​

Основні вихідні артефакти ​

1. Визначення контракту мапінгу (YAML) ​

2. Конвеєр трансформації (SQL / Python) ​

Згенероване SQL View (сумісне з dbt) ​

Згенерований скрипт Python (сумісний з Spark DataFrame) ​

Переваги: Чому це ефективно? ​