OCI Data Science Pro cheat sheet

Oracle Cloud Infrastructure (OCI) Data Science is a managed service covering the full lifecycle: data exploration in notebook sessions, model training (interactive or as jobs), model catalog storage, deployment as HTTP endpoints, and pipelines for MLOps automation.

Core resource hierarchy: compartment contains projects; a project contains notebook sessions, jobs, models, model deployments, and pipelines. IAM policies are written against these resource types within a compartment.

Notebook sessions are interactive, JupyterLab-based compute environments; jobs are non-interactive, repeatable runs of a script or notebook on managed compute - use jobs for scheduled or long training, sessions for exploration.

Model deployments host one or more models behind a single endpoint with a load balancer; the deployment shape (instance type/count, bandwidth) determines throughput and must match model memory and concurrency needs.

Service integrations: Object Storage for data and artifacts, Vault for secrets, Identity and Access Management for auth, Data Flow and Functions for orchestration options, and OCI Logging/Monitoring for observability.

The OCI Python SDK and the oci CLI expose the same REST APIs; the ADS (Accelerated Data Science) library wraps common workflows (datasets, model training, evaluation, deployment) with higher-level Python calls.

Regions and availability domains matter: resources are regional (projects, models, deployments), while compute for sessions and jobs is placed in a subnet you choose, so networking and private endpoints are design decisions.

Pricing model: you pay for compute and storage consumed (sessions, jobs, deployment instances, block/object storage); idle notebook sessions still consume compute until stopped or deactivated by an idle-timeout policy.

Creating a project requires a compartment and is the prerequisite for every session, job, model, deployment, and pipeline; projects are the unit of IAM policy scoping and resource grouping.

A notebook session is created from a shape (CPU or GPU), a block-storage size, and a subnet; it runs JupyterLab, and the session's block volume persists across stop/start cycles until the session is deleted.

Conda environments inside a session: the base environment is managed by OCI; create a custom conda environment (conda create) and install the oracle-ads package to use ADS, then register the kernel for Jupyter.

Environment variables and secrets: store credentials in Vault and reference them via OCIDs; avoid hardcoding in notebooks. Session environment variables can be set at creation time.

Idle timeout: sessions can be configured with an idle timeout that stops the session after inactivity to control cost; stopping preserves the block volume, deleting destroys it.

Lifecycle states to know: Creating, Active, Stopping, Stopped, Updating, Deleting, Failed. You cannot open JupyterLab unless the session is Active.

The ADS DataScienceSession/NotebookSession APIs and CLI commands (oci data-science notebook-session create) allow programmatic session management; the session OCID is the key identifier for automation.

Custom environments can be captured as conda pack archives or container images so jobs and deployments reproduce the exact library versions used during exploration.

Jobs run a command in a container on managed compute: you specify a job shape, block-storage size, subnet, and the artifact (script or notebook) from Object Storage; logs stream to OCI Logging.

Job run states: Accepted, InProgress, Succeeded, Failed, Canceled. Each job can have many runs; the run OCID is what you monitor and what pipeline steps reference.

Model artifacts must be saved in a defined format (e.g., pickle/joblib, ONNX, or a score.py for custom inference) and stored in Object Storage; the model catalog entry references that artifact plus provenance metadata.

Model deployment creation requires: model artifact, shape (instance type and count), bandwidth, and optionally a custom inference container image and a score.py implementing load_model and predict.

Deployment strategies include single-model and model-group (multiple models behind one endpoint with traffic splitting for A/B or canary); traffic split percentages are configured on the deployment.

Deployment states: Creating, Active, Updating, Deleting, Deleted, Failed. Invoke via the predict REST endpoint with authentication (IAM token or resource principal).

Provenance: model catalog entries record the training job, notebook, git commit, and input data references when created through ADS, which supports audit and reproducibility.

Autoscaling and logging: deployments emit access and prediction logs to OCI Logging; monitoring metrics (invocations, latency, errors) go to OCI Monitoring for alerting.

Data access patterns: Object Storage via the SDK/CLI or ADS dataset APIs; Autonomous Database via wallet + connection string; secrets pulled from Vault at runtime using resource principals.

Resource principals let jobs, deployments, and pipeline steps call OCI services without storing user credentials - configure dynamic groups and policies granting the resource principal access to buckets, models, and vaults.

ADS datasets (ADSData) load from Object Storage, databases, or local files and provide train/test splitting, profiling, and visualization helpers before training.

OCI Data Science Pipelines are DAGs of steps (custom script, job, or deployment steps) defined in a YAML/JSON spec; each step runs in its own container and passes outputs to downstream steps.

Pipeline run states and step outputs: a failed step stops downstream execution; artifacts are written to Object Storage and referenced by OCID so runs are reproducible and auditable.

MLOps loop: version data and code, train as jobs, register models in the catalog, deploy via pipeline step, monitor with Logging/Monitoring, and retrain on drift using scheduled pipeline runs.

IAM policy examples: Allow group DataScientists to manage data-science-family in compartment DS and Allow dynamic-group DSJobs to read objects in compartment DS - least privilege per resource type.

Operational hygiene: tag resources for cost allocation, set idle timeouts on sessions, use budgets and alarms in OCI Budgets/Monitoring, and rotate Vault secrets used by jobs and deployments.