目录
rrrkharse

feat: add log_lineage_inputs for declaring a model’s upstream data (#31)

  • feat: add log_lineage_inputs for declaring a model’s upstream data

Adds log_lineage_inputs(model_id, lineage_inputs), which records the upstream data inputs that produced a logged model as a sagemaker_lineage_inputs.json artifact on that model.

The helper makes no AWS calls and resolves nothing. When the model is registered, the SageMaker model registry server plugin reads the artifact and associates each declared input upstream of the model’s lineage, so the graph records which data produced the model rather than beginning at the experiment. Declaring inputs for a model that is never registered has no effect.

Two input types are understood today, FeatureGroup (by Arn) and S3TableSnapshot (by Uri, with an optional SnapshotId), but only the list’s shape is validated here. Each entry’s Type and identifier fields are interpreted server-side, so an input type newer than the installed client is forwarded rather than rejected and a new type can ship without a client release. TypedDicts are provided for editor ergonomics, with a Dict[str, Any] escape hatch for that same reason.

  • fix: reject input types the server cannot resolve

log_lineage_inputs accepted any Type and wrote it verbatim, on the reasoning that a type newer than the installed client should be forwarded rather than rejected. That made a typo indistinguishable from success: the call returned, the artifact was written, and at registration the server skipped the entry with a warning the caller never sees, leaving no lineage and no error.

Close the set. Type must be one of SUPPORTED_INPUT_TYPES, and must carry that type’s identifier (Arn for FeatureGroup, Uri for S3TableSnapshot), both enforced at the call site with an error that names the supported types. One bad entry rejects the whole declaration, so a model never ends up with partial lineage. Fields beyond the identifier still pass through untouched.

The cost is that adding a type now needs a client release alongside the server resolver, and a client pinned to an older version cannot use a newer server-side type. That is preferable to a silent trap.

7天前15次提交

SageMaker MLflow Plugin

What does this Plugin do?

This plugin generates Signature V4 headers in each outgoing request to the Amazon SageMaker with MLflow capability, determines the URL of capability to connect to tracking servers, and registers models to the SageMaker Model Registry. It generates a token with the SigV4 Algorithm that the service will use to conduct Authentication and Authorization using AWS IAM.

Installation

To install this plugin (lightweight, depends on mlflow-skinny):

pip install sagemaker-mlflow

To install with the full mlflow dependency set:

pip install sagemaker-mlflow[full]

To install from source:

pip install .

Custom AWS session

By default, the plugin signs requests using credentials from the boto3 default credential chain (environment variables, shared config, instance role, etc.). Callers that need to sign with a specific boto3.Session — for example a non-default profile or per-tenant credentials in a shared process — can inject one without mutating os.environ:

import boto3
import mlflow
import sagemaker_mlflow

custom = boto3.Session(profile_name="my-profile")

with sagemaker_mlflow.use_session(custom):
    mlflow.MlflowClient().search_experiments(max_results=1)

use_session is a context manager scoped to the current thread / asyncio task; the previous session is restored on exit (including on exception). sagemaker_mlflow.set_session(session) is also available for setting a default that lasts for the rest of the context. Resolution order inside AuthBoto: explicit boto3_session= kwarg → use_session/set_session → boto3.Session().

Presigned S3 artifact uploads

Set SAGEMAKER_PRESIGNED_URL_UPLOAD_ENABLED=true to route recognized S3 artifact uploads through URLs issued by the MLflow tracking server. The tracking-server request uses SageMaker authentication, while the file is streamed directly to the returned S3 URL so those uploads do not require direct S3 write credentials.

export SAGEMAKER_PRESIGNED_URL_UPLOAD_ENABLED=true

Once a presigned upload is attempted, request or PUT failures propagate to the caller; there is no silent fallback to direct S3. When the setting is disabled, the repository retains the standard MLflow direct-S3 behavior.

When the setting is enabled and the repository has a tracking URI, artifact roots that cannot be identified as run or logged-model targets fail before any server or S3 request; they do not fall back to direct S3. Repositories without a tracking URI retain the standard MLflow direct-S3 behavior.

Warning: trace logging is not supported with presigned uploads

Warning: Trace payload and attachment uploads are not currently supported when SAGEMAKER_PRESIGNED_URL_UPLOAD_ENABLED=true and a tracking URI is configured. Trace logging fails closed before any server or S3 request and does not fall back to direct S3. To use trace logging until the server supports a trace_id upload scope, disable the setting and ensure that the client has direct S3 write permissions.

Presigned uploads for MLflow 3 logged-model artifacts (log_model) require both a client containing logged-model scope support and a tracking server containing mlflow/mlflow#24765. Upgrading only one side does not enable the flow: an older client still sends the model ID as run_id, while a newer client sends model_id, which an older server does not support.

Development details

setup.py

setup.py Contains the primary entry points for the sdk. install_requires Installs mlflow-skinny (lightweight) by default. The [full] extra installs the full mlflow package. entry_points Contains the entry points for the sdk. See https://mlflow.org/docs/latest/plugins.html#defining-a-plugin for more details.

Running tests

Setup

To run tests using tox, run:

pip install tox

Installing tox will enable users to run multi-environment tests. On the other hand, if running individual tests in a single environment, feel free to continue to use pytest instead.

Running format checks

tox -e flake8,black-check,typing,twine

Formatting code to comply with format checks

tox -e black-format

Running unit tests

tox --skip-env "black.*|flake8|typing|twine" -- test/unit

Running integration tests

tox --skip-env "black.*|flake8|typing|twine" -- test/integration

Available test environments by default

tox.ini contains support for:

  • Python 3.9: mlflow 2.8., 2.9., 2.10., 2.11., 2.12., 2.13., 2.16.*, 3.0.0
  • Python 3.10/3.11: mlflow 2.8., 2.9., 2.10., 2.11., 2.12., 2.13., 2.16.*, 3.0.0, 3.4.0, 3.10.0

To add test environments on tox for additional versions of python or mlflow, modify the environment configs in envlist, as well as deps and depends in [testenv].

关于
429.0 KB
邀请码
    Gitlink(确实开源)
  • 加入我们
  • 官网邮箱:gitlink@ccf.org.cn
  • QQ群
  • QQ群
  • 公众号
  • 公众号

版权所有:中国计算机学会技术支持:开源发展技术委员会
京ICP备13000930号-9 京公网安备 11010802047560号