[external-assets] Standardize terminology on "execution set"

[smackesey]

Summary & Motivation

The terminology around groups of assets/checks that must be executed together is currently a little mixed:

• AssetGraph has get_required_multi_asset_keys and get_required_asset_and_check_keys
• ExternalAssetNode and ExternalAssetCheck have a field atomic_execution_unit_id

It's not obvious that these are related to one another. This PR attempts to tighten up and standardize the terminology around the phrase "execution set":

• AssetGraph.get_required_multi_asset_keys -> get_execution_set_asset_keys
• AssetGraph.get_required_asset_and_check_keys -> get_execution_set_asset_and_check_keys
• ExternalAsset{Node,Check}.atomic_execution_unit_id -> execution_set_id

It also tweaks the return value of the AssetGraph functions-- the current behavior is to return an empty set for subsettable assets, which does not make sense for "execution sets"-- this changes it to return a set with a single element (the passed asset key).

How I Tested These Changes

Existing test suite.

[smackesey]

• [external-assets] Build base asset jobs using AssetGraph #20227
• [external-assets] Allow asset jobs to combine materializations and observations #19667
• [external-assets] Update AssetGraph accessor callsites to fetch nodes #20132
• [external-assets] Implement AssetGraph with AssetNode and RemoteAssetNode #20114
• [external-assets] AssetGraph class renames #20276
• [external-assets] Normalize assets defs in InternalAssetGraph #20223
• [external-assets] Expose asset_checks_defs_by_key on RepositoryDefinition #20222
• [external-assets] Mark public RepositoryDefinition.{assets_defs_by_key, source_assets_by_key} #20221
• [external-assets] Standardize terminology on "execution set" #20140 👈
• [external-assets] Create external assets defs for undefined assets in repo construction #20145
• [external-assets] Hoist resolution of input asset keys to RepositoryDataBuilder #20186
• Fix test for compatibility with pytest 8.1 #20225
• master

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @smackesey and the rest of your teammates on Graphite

[OwenKephart]

certainly an improvement 🙏

[smackesey]

So to be clear, an "execution unit" is defined as a "a set of assets and asset checks that must be executed together because they are attached to the same op and can_subset is false"?

Sounds accurate to me

[schrockn]

Let's meet this AM to come up with some naming ideas for this concept. I don't think execution unit is particularly intuitive.

This is relevant conversation from Slack yesterday.

AssetSelection has a required_multi_asset_neighbors which isn't great either.

[schrockn]

Per zoom convo:

execution unit -> execution set (the set of asset or check sets executed together)
atomic execution id -> execution set identifier

[schrockn]

cc: @OwenKephart for your thoughts on this naming proposal

[smackesey]

I've performed the rename to "execution_set_identifier"

[OwenKephart]

@schrockn @smackesey to be honest, I'm not seeing a major difference between "execution unit" and "execution set" -- fine with this outcome.

[schrockn]

kn @smackesey to be honest, I'm not seeing a major difference between "execution unit" and "execution set" -- fine with this outcome.

@OwenKephart the thinking is that the word "set" indicates the "set of keys in an asset graph that must be executed together". This aligns with the can_subset language in our public API.

[smackesey]

@schrockn anything else you wanted to see in this PR