Spark CLI
MicrosoftOfficialPublished by Microsoft
- Skill
- Tool integration
- Software development
- MIT
- Low risk
AutoGineer summary
Written by AutoGineer from the skill’s own files, not by the author
spark-cli is a mode-based dispatcher designed to handle the full lifecycle of Fabric Spark operations. It provides structured guidance for authoring notebook code, managing interactive Livy sessions, diagnosing Spark job failures, and operating Materialized Lake Views (MLV). The skill enforces strict operational boundaries, requiring users to select a specific mode (authoring, consumption, operations, or mlv) and consult the corresponding reference documentation before executing any commands to ensure correct API usage and payload construction.
What it does
- Authors and manages Fabric notebook cell code including PySpark, Scala, and %%sql.
- Facilitates interactive data analysis through Livy session management.
- Diagnoses failed, slow, or OOM Spark jobs and pipeline runs.
- Manages the complete lifecycle of Materialized Lake Views, including definition, scheduling, and refresh monitoring.
- Provides standardized patterns for data engineering, schema management, and error handling in Fabric.
- Ensures proper telemetry and authentication for all Fabric API interactions.
When to use it
- When writing or updating code within Fabric notebooks.
- When performing ad-hoc data analysis using interactive Livy sessions.
- When investigating performance bottlenecks or failures in Spark jobs.
- When creating, scheduling, or troubleshooting Materialized Lake Views.
- When you need to ensure your Fabric API calls follow mandatory telemetry and authentication standards.
Advantages
- Provides a structured, mode-based approach to prevent configuration errors.
- Centralizes complex Spark and MLV management tasks into a single interface.
- Enforces best practices for data engineering and schema management.
- Reduces ambiguity by clearly defining the scope of Spark-related operations versus other CLI tools.
Usage examples
- “Write a notebook cell that reads a bronze table and writes a silver Delta table.”
- The agent enters 'authoring' mode, reads the relevant reference, and generates the appropriate PySpark code using Delta Lake patterns.
- “My notebook run failed with an OOM error, can you help me diagnose it?”
- The agent enters 'operations' mode, reads the diagnostic workflow reference, and guides the user through analyzing the job logs and metrics.
- “Schedule a nightly refresh for the lakehouse MLV and show me its run history.”
- The agent enters 'mlv' mode, reads the MLV reference, and executes the necessary API calls to configure the schedule and retrieve the history.
Install
Download the skill as a ZIP:
https://autogineer.com/agent-skills/microsoft/spark-cli/downloadUnzip it into the cross-client skills folder of your project:
mkdir -p .agents/skills && unzip spark-cli.zip -d .agents/skills
Documentation by Microsoft
Telemetry — MANDATORY. Every
api.fabric.microsoft.comcall must carryx-ms-fabric-skill: spark-cli(az rest:--headers "x-ms-fabric-skill=spark-cli"), including every LRO poll,fabric_lroand retry. Snippets omit it — add it anyway.
CRITICAL NOTES
To find the workspace details (including its ID) from workspace name: list all workspaces and, then, use JMESPath filtering
To find the item details (including its ID) from workspace ID, item type, and item name: list all items of that type in that workspace and, then, use JMESPath filtering
Skill disambiguation: use
spark-clifor notebook cell code (including%%sqlcells), named notebook runs, Livy sessions, Spark failure triage, and everything about a Materialized Lake View -- writing the definition, reviewing a query for incremental-refresh readiness, and scheduling, refreshing, monitoring or diagnosing an existing one. A KQL materialized view in an Eventhouse iseventhouse-cli; plain read-only T-SQL against a Warehouse or Lakehouse SQL endpoint issqldw-cli.Hard routing boundary: never execute an Eventhouse/KQL materialized-view request from this skill. Route it to
eventhouse-cli; if that skill is unavailable, state that the request cannot be completed in the current skill context and stop without calling Fabric APIs or creating artifacts.
Fabric Spark and Materialized Lake Views -- CLI Skill
This one skill owns Fabric Spark: notebook cell authoring, notebook runs, Livy-session analysis, Spark failure diagnostics, and the whole Materialized Lake View lifecycle.
It is a mode dispatcher and contains NO procedures. Pick the mode that matches the request from the table below, then read the matching references/<mode>.md file end to end with your file-reading tool BEFORE issuing a single command. That file holds the endpoints, payload shapes, templates and gotchas; acting without it produces wrong payloads and wrong results.
Mode selection
| Mode | Use when the request ... | Example triggers | Read this first |
|---|---|---|---|
authoring | writes notebook cell code (PySpark, Scala, SparkR, %%sql, %%configure), runs a notebook by name and reports a NORMAL run status, or authors a Materialized Lake View definition or reviews an MLV query for incremental-refresh readiness | write notebook code, notebook cell code, %%sql cell, run notebook, execute notebook, notebookutils, create materialized lake view, is this MLV query incremental-refresh ready | references/authoring.md |
consumption | runs interactive ad-hoc PySpark in a Lakehouse Livy session -- never a notebook | create a Livy session, run calculation in Livy, PySpark, DataFrame analysis, join tables across lakehouses, Delta time-travel | references/consumption.md |
operations | diagnoses a FAILED, unhealthy, throttled or slow Spark notebook / pipeline / Livy run | failed notebook, Spark Livy health, Spark OOM, why is my notebook slow, job diagnostics, 430 throttling | references/operations.md |
mlv | discovers or operates EXISTING Materialized Lake Views: Spark SQL discovery, refresh schedules, on-demand refresh, run history, cancellation, and refresh-failure classification | discover MLVs, list materialized lake views, schedule MLV, MLV run history, cancel refresh, trigger MLV refresh, diagnose MLV refresh failure | references/mlv.md |
Mode boundary rule
Mode is decided by the artefact and the outcome, not by the language. A notebook cell is always authoring even when the cell is %%sql. A Livy session is always consumption. A Spark run that FAILED or is unhealthy is operations; a run that succeeded is reported by authoring. For a Materialized Lake View the VERB decides: writing or reviewing the definition is authoring, while discovering, scheduling, refreshing, monitoring or diagnosing existing MLVs is mlv. If discovery must be executed, switch to consumption for Livy or authoring for a notebook only after reading the discovery command from references/mlv.md.
If a request genuinely spans modes, handle them one at a time and read each reference before you start that part. If the mode is ambiguous after reading this table, ask one short clarifying question instead of guessing.
Terminal write -- the step you must not skip
Reading the reference and planning the change is NOT completing the task. Each mutating mode ends with one state-changing call. If you did not issue it, nothing was persisted -- say so explicitly rather than reporting success.
| Mode | Terminal write |
|---|---|
authoring | for an EXISTING notebook, POST .../notebooks/{id}/updateDefinition to save the cell; a NEW notebook needs POST /v1/workspaces/{ws}/items first; for a run request, trigger the job via the Jobs API. Printing cell code into the chat is not saving or running it. |
consumption | none -- this mode is read-only |
operations | none -- this mode is read-only |
mlv | POST /v1/workspaces/{ws}/lakehouses/{lakehouse}/jobs/refreshMaterializedLakeViews/instances for an on-demand refresh, or the schedule create/update/delete call for a scheduling request. Reporting what the schedule would be is not creating it. |
Before you report the task done, confirm the terminal call returned success and, where the reference documents a readback, read the artefact back to prove the change landed.
Shared essentials (all modes)
Resolve the workspace and item first; every mode depends on it.
| Task | Reference | Notes |
|---|---|---|
| Finding Workspaces and Items in Fabric | COMMON-CLI.md | Mandatory -- read before resolving any workspace or item id |
| Fabric Topology & Key Concepts | COMMON-CORE.md | Item types, workspaces, capacities |
| Environment URLs | COMMON-CORE.md | Sovereign / non-public cloud hosts |
| Authentication & Token Acquisition | COMMON-CORE.md | Wrong audience = 401; read before any auth issue |
| Authentication Recipes | COMMON-CLI.md | az login flows and token acquisition |
| Core Control-Plane REST APIs | COMMON-CORE.md | Pagination, LRO polling, rate limiting |
| Gotchas & Troubleshooting | COMMON-CLI.md | az rest audience, shell escaping, token expiry |
Rules
MUST
Select exactly one mode from the table above before doing anything else.
Treat vague requests such as "set up my data" as insufficiently scoped. Ask what artefact, source, destination, and outcome the user wants; never infer intent by finding and running an existing notebook or job.
Read
references/<mode>.mdend to end, as your FIRST tool call, before the first command of that mode. Read it ONCE, in a single full read: do not re-open it, do not grep it again, and do not page through it. You already have it.Apply the same read-once discipline to every other file you load, including nested
references/<mode>/*.mdsub-references and sharedcommon/*.mdfiles: open only the ones you actually need, read each ONCE end to end, and never grep or re-open one you already loaded.Resolve workspace and item ids by listing and filtering, never by guessing a GUID.
Stop after routing any Eventhouse/KQL materialized-view request. Unavailable sibling skills are a blocking boundary, not permission to implement their workload directly.
Announce a mode switch explicitly when the request crosses a boundary.
Treat the reference as instructions, never as the deliverable. After reading it, RUN the documented commands against the live workspace and report the real results. Quoting what the reference says instead of executing it does not answer the request.
PREFER
The narrowest mode that satisfies the request.
Reading exactly ONE mode reference. Load a second only when the request genuinely spans modes, and say so before you do.
Reporting the mode you chose in your first response so the user can correct you.
AVOID
Acting from this dispatcher alone -- it intentionally omits the operational detail.
Answering with a summary of the reference instead of executing it.
Re-reading or re-grepping a reference you already loaded; it costs turns and tokens.
Mutating anything while in a read-only mode.
Loading a different skill for work this family already owns (see CRITICAL NOTES 3).
Attempting an out-of-scope request through raw REST calls when the owning skill is unavailable. Name the owning skill and stop; do not improvise by creating Fabric artefacts outside
spark-cli's scope.
Examples
| User request | Mode | Reference to read |
|---|---|---|
| "Write a notebook cell that reads the bronze table and writes a silver Delta table." | authoring | references/authoring.md |
| "Create a Livy session and count the distinct customers in the lakehouse." | consumption | references/consumption.md |
| "My notebook run failed with an OOM -- work out why." | operations | references/operations.md |
| "Is this materialized lake view query ready for incremental refresh?" | authoring | references/authoring.md |
| "Show me the Spark SQL command that lists the MLVs in schema silver." | mlv | references/mlv.md |
| "Schedule a nightly refresh for the lakehouse MLV lineage and show me its run history." | mlv | references/mlv.md |
Files
- ATTRIBUTION.mdAdded by AutoGineer863 B
- LICENSELicence file added by AutoGineer1.1 KiB
- SKILL.md10.1 KiB
- apm.yml430 B
- references/authoring.md32.9 KiB
- references/authoring/resources/data-engineering-patterns.md24.3 KiB
- references/authoring/resources/development-workflow.md7.4 KiB
- references/authoring/resources/infrastructure-orchestration.md10.4 KiB
- references/authoring/resources/materialized-lake-view-patterns.md20.1 KiB
- references/authoring/resources/mlv-incremental-refresh-patterns.md11.4 KiB
- references/authoring/resources/notebook-api-operations.md14.2 KiB
- references/consumption.md12.3 KiB
- references/mlv.md32.8 KiB
- references/operations.md20.3 KiB
- references/operations/automated-diagnostic-workflow.md12.7 KiB
- references/operations/diagnostic-workflow.md7.3 KiB
- references/operations/job-diagnostics.md17.7 KiB
- references/operations/jobinsight-api.md7.2 KiB
- references/operations/performance-patterns.md17.4 KiB
- references/operations/pipeline-diagnosis.md20.8 KiB
- references/operations/session-health.md8.7 KiB
- references/operations/spark-history-server.md6.5 KiB
references/operations/performance-patterns.md
Performance Patterns
Scope: Identify and resolve Spark performance bottlenecks in Microsoft Fabric — covering detection thresholds, anti-patterns, stage/task analysis, optimization recipes, and capacity diagnostics. All examples use
az restand PySpark via Livy sessions.
Detection Thresholds
The diagnostic skill uses the following thresholds to flag performance issues:
| Metric | Threshold | Severity | Meaning |
|---|---|---|---|
Max executorRunTime / Median | > 3× | HIGH | Data skew |
diskBytesSpilled | > 0 | MEDIUM | Memory insufficient for sort/join |
gcTime / executorRunTime | > 20% | MEDIUM | GC pressure |
shuffleWriteBytes per stage | > 1 GB | MEDIUM | Heavy shuffle |
coreEfficiency | < 30% | HIGH | Severe underutilisation |
idleTime / duration | > 40% | MEDIUM | High idle ratio |
Anti-Patterns
These are the most common performance killers in Fabric Spark workloads. Each pattern includes detection methods and fixes.
Shuffle Spill
What it is: When shuffle data exceeds available memory, Spark spills data to disk. Disk I/O is orders of magnitude slower than memory access.
Detection (via Livy PySpark statement):
# Check for spill in the last completed job
from pyspark.sql import SparkSession
sc = spark.sparkContext
# Get status URL info
print("Spark UI available via Fabric Monitoring Hub")
print(f"Application ID: {sc.applicationId}")
# Check current Spark config for shuffle settings
for key in ['spark.sql.shuffle.partitions', 'spark.shuffle.spill.compress',
'spark.sql.adaptive.enabled', 'spark.sql.adaptive.coalescePartitions.enabled']:
print(f"{key} = {sc.getConf().get(key, 'not set')}")Fixes:
| Approach | When to Use |
|---|---|
| Increase executor memory | Spill is small relative to data size |
| Reduce shuffle partition count | Too many partitions create overhead |
| Pre-filter data before joins/aggregations | Unnecessary data enters shuffle |
| Enable AQE coalescing | spark.sql.adaptive.coalescePartitions.enabled=true |
Data Skew
What it is: Uneven distribution of data across partitions. A few partitions have vastly more data than others, causing some tasks to run much longer.
Detection:
# Detect skew in a DataFrame
df = spark.table("your_table")
# Check partition sizes
from pyspark.sql.functions import spark_partition_id, count
partition_stats = df.groupBy(spark_partition_id().alias("partition")) \
.agg(count("*").alias("row_count"))
stats = partition_stats.describe("row_count")
stats.show()
# Skew ratio: max / mean — values > 3x indicate significant skew
max_count = partition_stats.agg({"row_count": "max"}).collect()[0][0]
mean_count = partition_stats.agg({"row_count": "avg"}).collect()[0][0]
print(f"Skew ratio: {max_count / mean_count:.1f}x (>3x = significant skew)")Fixes:
| Approach | When to Use |
|---|---|
| Salting join keys | Join on skewed key; add random salt to distribute |
| AQE skew join | spark.sql.adaptive.skewJoin.enabled=true (on by default in Fabric) |
| Pre-aggregate before join | Reduce cardinality of skewed dimension |
| Repartition by different column | Current partition key has low cardinality |
Small File Problem
What it is: Too many small files in Delta tables cause excessive metadata overhead and slow reads.
Detection:
# Check file sizes in a Delta table
from delta.tables import DeltaTable
dt = DeltaTable.forName(spark, "your_table")
# File count and sizes
files_df = spark.sql("DESCRIBE DETAIL your_table")
files_df.select("numFiles", "sizeInBytes").show()
# Rule of thumb: aim for 128MB-1GB per file
size_bytes = files_df.collect()[0]["sizeInBytes"]
num_files = files_df.collect()[0]["numFiles"]
avg_file_mb = (size_bytes / num_files) / (1024 * 1024) if num_files > 0 else 0
print(f"Average file size: {avg_file_mb:.1f} MB")
if avg_file_mb < 32:
print("⚠️ Small file problem detected — consider OPTIMIZE")Fix:
# Compact small files
spark.sql("OPTIMIZE your_table")
# For partitioned tables, optimize specific partitions
spark.sql("OPTIMIZE your_table WHERE date = '2024-01-15'")
# Enable auto-optimize for future writes
spark.sql("ALTER TABLE your_table SET TBLPROPERTIES ('delta.autoOptimize.optimizeWrite' = 'true')")Collect Misuse
What it is: Calling .collect(), .toPandas(), or .show(n) with large n on a large DataFrame pulls all data to the driver, causing OOM or extreme slowness.
Detection: Look for these patterns in notebook code:
df.collect()on DataFrames with > 10K rowsdf.toPandas()without prior.limit()df.show(1000000)or similar large show calls
Fixes:
| Instead of | Use |
|---|---|
df.collect() | df.limit(100).collect() or df.write.saveAsTable() |
df.toPandas() | df.limit(10000).toPandas() |
df.show(n) for large n | df.show(20) (default) or write to table and query |
Cartesian Joins
What it is: A join without a proper join condition produces the Cartesian product — row count = left × right.
Detection: Check for cross joins in the query plan:
df_result = df1.join(df2, ...) # suspect join
df_result.explain(True) # look for "CartesianProduct" or "BroadcastNestedLoopJoin"Fix: Always specify explicit join conditions. If a cross join is intended, use df1.crossJoin(df2) to make intent clear and add a downstream filter.
High GC Pressure
What it is: The JVM heap is filling up faster than garbage collection can free it. Executor CPU time is dominated by GC; throughput is much lower than raw CPU capacity suggests.
Detection: gcTime / executorRunTime > 20%
Root Cause:
Python UDFs that create Python objects in every row
String-heavy DataFrames with high cardinality
Many small objects created by complex aggregation logic
Fix:
# Option 1: Replace Python UDFs with native PySpark SQL functions
# BAD — UDF creates Python objects per row
from pyspark.sql.functions import udf
@udf("string")
def clean(s):
return s.strip().lower() if s else ""
# GOOD — uses JVM-native function, no Python object creation
from pyspark.sql.functions import lower, trim
df = df.withColumn("cleaned", lower(trim(col("value"))))
# Option 2: Use Pandas UDFs (vectorized) when Python logic is mandatory
from pyspark.sql.functions import pandas_udf
import pandas as pd
@pandas_udf("double")
def compute_score(values: pd.Series) -> pd.Series:
return values.apply(lambda x: x * 2.5)
# Option 3: Cache DataFrames that are used multiple times
df_expensive.cache()
df_expensive.count() # trigger materialization
# Option 4: Use Parquet/Delta format (columnar, minimizes Java object count)
df.write.format("delta").save("Files/output/")Heavy Shuffle
What it is: Too much data is being shuffled across the network. Stage takes a long time; many "shuffle write" / "shuffle read" bytes visible in stage metrics.
Detection: shuffleWriteBytes > 1 GB in a stage
Root Cause:
groupBy+ aggregation on a high-cardinality columnMultiple chained joins without caching intermediate results
repartition(N)with N larger than needed
Fix:
# Option 1: Cache intermediate DataFrames to avoid re-shuffling
df_joined = large1.join(large2, "key").cache()
df_joined.count() # materialize
result1 = df_joined.groupBy("category").agg(...)
result2 = df_joined.filter(col("status") == "active")
# Option 2: Reduce join width — select only needed columns before join
df_slim = df.select("key", "value1", "value2")
df_slim.join(other_slim, "key")
# Option 3: Use bucket tables for repeated large-table joins (eliminates shuffle)
df.write.bucketBy(64, "user_id").sortBy("user_id").saveAsTable("events_bucketed")
events = spark.table("events_bucketed")
users = spark.table("users_bucketed")
events.join(users, "user_id") # no shuffle!
# Option 4: Tune shuffle partitions to match data volume
# Rule of thumb: each shuffle partition should be 100-200 MB
spark.conf.set("spark.sql.shuffle.partitions", "100")
# Or let AQE coalesce automatically:
spark.conf.set("spark.sql.adaptive.coalescePartitions.enabled", "true")Too Many Small Partitions
What it is: High number of tasks but very short duration per task (< 100ms). Task scheduling overhead dominates actual compute time.
Detection: Stage shows 1000+ tasks but each completes in milliseconds.
Root Cause: spark.sql.shuffle.partitions is set too high relative to data volume, or source files are very small (many small Parquet files).
Fix:
# Reduce shuffle partitions globally
spark.conf.set("spark.sql.shuffle.partitions", "50") # tune to your data size
# Or let AQE coalesce small partitions automatically (recommended)
spark.conf.set("spark.sql.adaptive.enabled", "true")
spark.conf.set("spark.sql.adaptive.coalescePartitions.enabled", "true")
spark.conf.set("spark.sql.adaptive.advisoryPartitionSizeInBytes", "128MB")
# For source files: coalesce small files before processing
df = spark.read.parquet("Files/raw/")
df = df.coalesce(20) # reduce from 500 tiny partitions to 20 larger onesDriver Memory Bottleneck
What it is: Operations that run on the driver rather than executors. All executors idle while driver is computing.
Detection: Driver OOM (see job-diagnostics.md pattern #1) or very long "driver computation" phases with idle executors.
Root Cause:
df.collect()— materializes entire DataFrame in driver memorydf.toPandas()— sameSchema inference on many files
Building broadcast variables from large datasets
Fix:
# Instead of collect(): write results
df.write.mode("overwrite").parquet("Files/output/")
display(df.limit(1000)) # paginate for visual inspection
# For schema inference on many files: provide schema explicitly
from pyspark.sql.types import StructType, StructField, StringType, LongType
schema = StructType([
StructField("id", LongType(), True),
StructField("name", StringType(), True),
])
df = spark.read.schema(schema).json("Files/data/")Missing Cache / Re-computation
What it is: A DataFrame that is used multiple times is not cached, so Spark re-executes the full lineage from the source each time an action is called. Same stage appears multiple times with identical input/output.
Detection: Multiple downstream actions re-trigger the same expensive computation (visible in stage repetition).
Fix:
# BEFORE (expensive re-computation)
df_expensive = df.join(other, "key").groupBy("cat").agg(...)
result1 = df_expensive.filter(col("cat") == "A").count()
result2 = df_expensive.filter(col("cat") == "B").show()
# Both calls re-execute the join and aggregation
# AFTER (cache and reuse)
df_expensive = df.join(other, "key").groupBy("cat").agg(...).cache()
df_expensive.count() # trigger materialisation
result1 = df_expensive.filter(col("cat") == "A").count()
result2 = df_expensive.filter(col("cat") == "B").show()
# ALWAYS unpersist when done
df_expensive.unpersist()Stage and Task Analysis
Reading Spark Execution Metrics
In Fabric, the Spark UI is accessible through the Monitoring Hub. For programmatic access, use Livy to query runtime metrics.
# Get active and completed job info
sc = spark.sparkContext
status_tracker = sc.statusTracker()
# Active jobs
active_jobs = status_tracker.getActiveJobIds()
print(f"Active jobs: {list(active_jobs)}")
# For each active job, get stage info
for job_id in active_jobs:
job_info = status_tracker.getJobInfo(job_id)
print(f"Job {job_id}: status={job_info.status()}, "
f"stages={list(job_info.stageIds())}")Identify Slow Stages
# Run a query and then analyze the plan
df = spark.sql("SELECT ... FROM ... JOIN ...")
# Physical plan shows shuffle boundaries and join strategies
df.explain("formatted")
# The plan reveals:
# - Exchange nodes = shuffle boundaries (expensive)
# - BroadcastHashJoin vs SortMergeJoin (broadcast = faster for small tables)
# - Filter pushdown (filters should appear as early as possible)Monitor Active Statements
# Check all statements in a session
az rest --method get --resource "$FABRIC_RESOURCE_SCOPE" \
--url "$FABRIC_API_URL/workspaces/$workspaceId/lakehouses/$lakehouseId/$LIVY_API_PATH/sessions/$sessionId/statements" \
--query "statements[].{id:id, state:state, progress:progress}" --output tableOptimization Recipes
Partition Tuning
# Check current partition count
df = spark.table("your_table")
print(f"Current partitions: {df.rdd.getNumPartitions()}")
# Rule of thumb: 128MB per partition, 2-4x parallelism of cluster
# For a 10GB dataset on 8 cores: ~80-320 partitions
optimal = max(1, int(df.inputFiles().__len__() * 128 / 1024)) # rough estimate
print(f"Suggested partitions: {optimal}")
# Repartition if needed
df_optimized = df.repartition(optimal)Broadcast Join Optimization
from pyspark.sql.functions import broadcast
# For small dimension tables (< 100MB), broadcast to avoid shuffle
dim_df = spark.table("small_dimension_table")
fact_df = spark.table("large_fact_table")
# Explicit broadcast hint
result = fact_df.join(broadcast(dim_df), "key_column")
# Check if broadcast was used
result.explain() # Should show BroadcastHashJoin, not SortMergeJoinCaching Strategy
# Cache intermediate results that are reused multiple times
intermediate_df = spark.sql("""
SELECT customer_id, SUM(amount) as total
FROM transactions
GROUP BY customer_id
""")
# Cache only if the DataFrame is reused in multiple downstream operations
intermediate_df.cache()
intermediate_df.count() # Materialize the cache
# Use in multiple downstream queries
top_customers = intermediate_df.filter("total > 10000")
segments = intermediate_df.join(dim_customers, "customer_id")
# ALWAYS unpersist when done
intermediate_df.unpersist()AQE (Adaptive Query Execution) Settings
AQE is enabled by default in Fabric. Verify and tune:
# Check AQE settings
aqe_keys = [
'spark.sql.adaptive.enabled',
'spark.sql.adaptive.coalescePartitions.enabled',
'spark.sql.adaptive.skewJoin.enabled',
'spark.sql.adaptive.skewJoin.skewedPartitionThresholdInBytes',
'spark.sql.adaptive.advisoryPartitionSizeInBytes'
]
for key in aqe_keys:
print(f"{key} = {spark.conf.get(key, 'not set')}")Predicate Pushdown Verification
# Verify that filters are pushed down to the data source
df = spark.table("your_table").filter("date >= '2024-01-01'").filter("status = 'active'")
# Check the physical plan — filters should appear at the scan level
df.explain(True)
# Look for: PushedFilters: [IsNotNull(date), GreaterThanOrEqual(date,2024-01-01)]
# If filters appear ABOVE the scan, pushdown is not workingCapacity and Resource Diagnostics
Check Capacity Utilization
When jobs are slow across the board, the issue may be capacity-level, not job-level.
Per-Application Resource Metrics: Use the Resource Usage API for granular vCore allocation and utilization timelines per Spark application, including core efficiency and idle time metrics.
# List available capacities and their state
az rest --method get --resource "$FABRIC_RESOURCE_SCOPE" \
--url "$FABRIC_API_URL/capacities" \
--query "value[].{name:displayName, id:id, sku:sku, state:state}" \
--output tableDetect Throttling
Fabric throttles workloads when capacity utilization exceeds limits. Symptoms:
Jobs take longer than usual to start
Sessions stay in
startingstateAPI calls return 429 (Too Many Requests)
# Check if any recent API calls were throttled (429 responses)
# This is visible in job instance details
az rest --method get --resource "$FABRIC_RESOURCE_SCOPE" \
--url "$FABRIC_API_URL/workspaces/$workspaceId/items/$notebookId/jobs/instances?limit=5" \
--query "value[].{status:status, start:startTimeUtc, failureReason:failureReason}" \
--output tableCapacity Sizing Guide
| SKU | CU | Concurrent Spark Sessions (Typical) | Use Case |
|---|---|---|---|
| F2 | 2 | 1 | Dev/test |
| F4 | 4 | 1-2 | Small workloads |
| F8 | 8 | 2-3 | Light production |
| F16 | 16 | 3-5 | Medium production |
| F32 | 32 | 5-8 | Standard production |
| F64 | 64 | 8-15 | Large production |
| F128+ | 128+ | 15+ | Heavy production |
Concurrent session counts are approximate and depend on session size (memory/cores). Starter Pool sessions consume fewer CUs than custom pool sessions.
Resource Efficiency Check
Run this diagnostic in a Livy session to check for resource waste:
# Check if executors are underutilized
sc = spark.sparkContext
conf = sc.getConf()
print("=== Resource Allocation ===")
print(f"Driver memory: {conf.get('spark.driver.memory', 'default')}")
print(f"Executor memory: {conf.get('spark.executor.memory', 'default')}")
print(f"Executor cores: {conf.get('spark.executor.cores', 'default')}")
print(f"Dynamic allocation: {conf.get('spark.dynamicAllocation.enabled', 'not set')}")
print(f"Min executors: {conf.get('spark.dynamicAllocation.minExecutors', 'not set')}")
print(f"Max executors: {conf.get('spark.dynamicAllocation.maxExecutors', 'not set')}")
active_execs = len(sc._jsc.sc().getExecutorMemoryStatus()) - 1 # subtract driver
print(f"\nActive executors: {active_execs}")
print(f"Default parallelism: {sc.defaultParallelism}")
print(f"Shuffle partitions: {spark.conf.get('spark.sql.shuffle.partitions', 'default')}")Requirements and compatibility
Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta
“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.
Security
What our scanner noticed· Low risk
- Instructions that use the network
A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.
Attribution and licence
- Published by
- Microsoft
- Publisher
- Microsoft (Official)
- Source
- microsoft/skills-for-fabric · skills/spark-cli · commit f8fac11
- Licence
- MIT License (redistribution allowed)
- LICENSE (added by AutoGineer from LICENSE)
- ATTRIBUTION.md (written by AutoGineer)
- Synced
- Also distributed in
- microsoft/skills-for-fabric
AutoGineer is not affiliated with or endorsed by Microsoft or Microsoft.
Download ZIP
The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download spark-cli.zip