Skip to main content

1. Relationship Between Data Lakehouse and Data Warehouse

  • Data Warehouse:
    • Traditional structured storage optimized for SQL analytics.
    • Uses Extract, Transform, Load (ETL) to process structured data.
    • Limited support for unstructured/semi-structured data.
    • Examples: Snowflake, Redshift, BigQuery.
  • Data Lakehouse:
    • Combines data lake (flexible storage) + data warehouse (performance & governance).
    • Supports structured, semi-structured (JSON, Parquet), and unstructured data (images, logs).
    • Uses Delta Lake for ACID transactions, schema enforcement, and time travel.
    • Enables BI, ML, and streaming on a single platform.
Key Differences: Reference: Databricks Lakehouse Whitepaper

2. Improvement in Data Quality in Lakehouse Over Data Lake

  • Data Lakes (Traditional Issues):
    • No schema enforcement โ†’ โ€œData Swampโ€ (poor quality).
    • No ACID transactions โ†’ Dirty reads/writes.
    • Limited metadata management โ†’ Hard to govern.
  • Lakehouse Improvements (via Delta Lake):
    • ACID Transactions: Ensures consistency (e.g., concurrent writes).
    • Schema Enforcement: Prevents bad data ingestion.
    • Time Travel: Rollback to previous versions (e.g., RESTORE TABLE).
    • Data Quality Checks: Expectations (e.g., CHECK constraints).
    • Unified Governance: Fine-grained access control (Row/Column-level).
Example:
Reference: Delta Lake Documentation

3. Silver vs. Gold Tables & Workload Sources

  • Medallion Architecture:
    • Bronze (Raw): Raw ingested data (e.g., JSON logs, IoT streams).
    • Silver (Cleaned): Validated, deduplicated, enriched data.
    • Gold (Aggregated): Business-level aggregates (e.g., KPIs, reports).
Workload Examples:
  • Bronze as Source: Stream processing (e.g., Spark Structured Streaming).
  • Gold as Source: BI dashboards (Tableau, Power BI).

4. Databricks Platform Architecture (Control vs. Data Plane)

  • Control Plane:
    • Managed by Databricks (in their cloud).
    • Includes:
      • UI/API management.
      • Job scheduler.
      • User authentication (via Databricks account).
  • Data Plane:
    • Runs in customerโ€™s cloud account (AWS/Azure/GCP).
    • Includes:
      • Compute (Clusters, SQL Warehouses).
      • Storage (DBFS, External Blob Storage).
      • Delta Lake tables.
Reference: Databricks Architecture

5. All-Purpose vs. Jobs Clusters

Example:
  • All-Purpose: Data scientists exploring data.
  • Jobs Cluster: Nightly ETL pipeline.

6. Cluster Software Versioning (Databricks Runtime)

  • Databricks Runtime (DBR): Optimized Spark + extra features (Delta, ML).
    • Versions: DBR 10.4 LTS, DBR 11.3 (latest).
    • LTS: Long-Term Support (stable).
    • GPU/ML Runtimes: Pre-installed libraries (TensorFlow, PyTorch).
Example:

7. Filtering Accessible Clusters

  • Methods:
    • UI: Compute โ†’ Filter by โ€œCan Attach Toโ€.
    • API: GET /api/2.0/clusters/list โ†’ Check can_manage flag.

8. Terminating a Cluster & Impact

  • Termination:
    • Manual: UI/API (DELETE /api/2.0/clusters/terminate).
    • Auto-Termination: After idle time (configurable).
  • Impact:
    • Running Jobs Fail.
    • Notebook Sessions Disconnected.
    • Storage Persists (DBFS/Delta unaffected).

9. When to Restart a Cluster

  • Scenarios:
    • Library install requires restart.
    • Configuration changes (e.g., autoscaling).
    • Cluster becomes unresponsive.

10. Using Multiple Languages in a Notebook

  • Magic Commands:
    • %python, %sql, %scala, %r.
    • Example:

11. Running a Notebook from Another Notebook

  • %run Command:
  • dbutils.notebook.run() (for jobs):

12. Sharing Notebooks

  • Methods:
    • Export: .dbc or .ipynb format.
    • Permissions: Can View, Can Edit, Can Run.
    • Workspace Access Control: Admin-managed.

13. Databricks Repos for CI/CD

  • Features:
    • Git integration (GitHub, GitLab, Bitbucket).
    • Sync notebooks with remote repos.
    • Branching/Merging directly in UI.
Example Workflow:
  1. Clone repo โ†’ git checkout feature-branch.
  2. Develop โ†’ Commit โ†’ Push.
  3. Open PR โ†’ Merge to main.

14. Git Operations in Databricks Repos

  • Supported:
    • git clone, pull, push, commit, branch.
  • Not Supported:
    • git rebase, submodules.

15. Notebook Version Control Limitations (vs. Repos)

  • Notebook History:
    • Only saves local revisions (no Git integration).
  • Repos Advantage:
    • Full Git history.
    • Collaboration (PRs, branching).
Reference: Databricks Repos Docs