An external asset is an asset that is not materialized by Dagster, but is tracked in the asset graph and asset catalog. This allows you to model assets in Dagster, attach metadata and events to those assets, but without scheduling their materialization with Dagster.
External assets are a good fit when data is:
Landed by an external source (e.g. an external file landing daily; Kafka landing data into Amazon S3)
Created and processed using manual processes
Materialized by existing pipelines with their own scheduling and infrastructure that you do not want to or need to migrate en masse
With an external asset, you can:
Attach metadata to its definition for documentation, tracking ownership, and so on
Track its data quality and version in Dagster
Use asset sensors or auto-materialize policies to update downstream assets based on updates to external assets
What about Source Assets? A common use case for external assets is modeling data produced by a process not under Dagster's control. For example, a daily file drop from a third party into Amazon S3. In most systems, these are described as sources. This includes Dagster, which includes SourceAsset. As external assets are a superset of Source Asset functionality, source assets will be supplanted by external assets in the near future.
External assets can depend only on other external assets.
Dependencies are defined by using the deps argument of AssetSpec. This enables Dagster to model entire graphs of assets scheduled and orchestrated by other systems.
In the following example, we have two assets: raw_logs and processed_logs. The processed_logs asset is produced by a scheduled computation in another orchestration system. Using external assets allows you to model both assets in Dagster.
Click the Assets in the Dagster UI tab to see how these assets would be rendered in the Dagster UI.
As Dagster doesn't control scheduling or materializing external assets, it's up to you to keep their metadata updated. This also means that materialization for external assets will be disabled in the Dagster UI.
To keep your external assets updated, you can use any of the following approaches:
Dagster OSS exposes a REST endpoint for reporting asset materializations. Refer to the following tabs for examples using a curl command, and for invoking the API in Python.
The following demonstrates how to use a curl command in a shell script to communicate with the API:
By using the asset_events parameter of SensorResult, you can generate events to attach to external assets and then provide them directly to sensors. For example:
import datetime
from dagster import(
AssetMaterialization,
AssetSpec,
Definitions,
SensorEvaluationContext,
SensorResult,
external_asset_from_spec,
sensor,)defutc_now_str()->str:return datetime.datetime.now(datetime.timezone.utc).strftime("%Y-%m-%d, %H:%M:%S")@sensor()defkeep_external_asset_a_up_to_date(context: SensorEvaluationContext)-> SensorResult:# Materialization happened in external system, but is recorded herereturn SensorResult(
asset_events=[
AssetMaterialization(
asset_key="external_asset_a",
metadata={"source":f'From sensor "{context.sensor_name}" at UTC time "{utc_now_str()}"'},)])
defs = Definitions(
assets=[external_asset_from_spec(AssetSpec("external_asset_a"))],
sensors=[keep_external_asset_a_up_to_date],)
You can insert events to attach to external assets directly from Dagster's Python API. Specifically, the API is report_runless_asset_event on DagsterInstance.
For example, this would be useful when writing a hand-rolled Python script to backfill metadata:
from dagster import AssetMaterialization
# instance is a DagsterInstance. Get using DagsterInstance.get()
instance.report_runless_asset_event(
AssetMaterialization("asset_one", metadata={"nrows":10,"source":"From this script."}))
You can log an AssetMaterialization from a bare op. In this case, use the log_event method of OpExecutionContext to report an asset materialization of an external asset. For example: