Category: Architecture

A Microsoft Landing Zone usually refers to an Azure Landing Zone (often part of the Cloud Adoption Framework (CAF)). It is a pre-built, best-practice cloud foundation that organizations use to deploy workloads in Azure in a secure, governed, and scalable way.

A Landing Zone is the “foundation environment” in the cloud:

• networking is ready
• security is enforced
• identity is centralized
• governance is in place
• logging & monitoring are enabled

Core Components

• Identity & Access (Entra ID)
  • Central authentication
  • RBAC roles
• Networking
  • Hub-Spoke architecture
  • VNet design
  • Private endpoints
• Governance
  • Policies (Azure Policy)
  • Management Groups
  • Resource tagging standards
• Security
  • Microsoft Defender for Cloud
  • Security baselines
  • Key Vault for secrets
• Monitoring
  • Log Analytics
  • Azure Monitor
  • Alerting system

Star schema has a central fact table connected directly to denormalized dimension tables. It is simple and fast for querying.
Snowflake schema has normalized dimension tables, where dimensions are split into multiple related tables.

Snowflake = more normalized, less redundancy but more joins

Star = simpler, faster queries

I design it using business requirements:

• Align with BI/reporting needs
• Identify facts (measures) like sales, transactions
• Identify dimensions like customer, product, time
• Choose grain (very important)
• Use surrogate keys for dimensions
• Apply star schema for analytics performance

Azure Data Factory is a cloud-based data integration service used to create data-driven workflows for orchestrating and automating data movement and transformation across different data stores and compute services.

Key capabilities

• Data ingestion
• Data orchestration
• Data transformation
• Scheduling and monitoring

The main components are:

A pipeline is a logical grouping of activities that together perform a task such as data ingestion or transformation.

Integration Runtime is the compute infrastructure used by ADF to perform data integration tasks.

• Azure IR Fully managed compute in Azure
• Self-hosted IR Runs on on-premises machines
• Azure SSIS IR Used to run SSIS packages

Types:

A linked service defines the connection information needed for ADF to connect to external resources, example:

• Azure SQL Database
• Data Lake
• databricks
• On-Prem database

A dataset represents the structure of data within a data store.

Solution 1: Watermark column
last_modified_date:
Max(Last_modified)
WHERE last_modified > last_run_time

Solution 2: CDC
transaction log
change tracking

Solution 3: File-based incremental
folder partition by date

Try-Catch pattern
Failure path
Retry policy

Activity
├ success → next step
└ failure → error handling pipeline

Triggers are used to automatically start pipelines.

A tumbling window trigger runs pipelines at fixed time intervals and processes data in discrete time windows.

ADF supports parameters at:

• Linked Service
• plpeline
• dataset

Parallel copy: pipeline success; pipeline duration; failure rate
Staging: use blob staging
Partitioning: split large tables

Monitoring options:
ADF Monitor UI
Azure Monitor
Log Analytics

Azure Data Factory Pipeline is an orchestration layer used to coordinate activities (copy, Databricks, API calls).
Mapping Data Flow is a visual ETL engine running on Spark for transformations without coding

I handle failures using:

• Delta Lake ACID for safe writes and rollback support
• ADF retry policies (activity-level retries)
• Idempotent pipeline design (safe re-runs)
• Checkpointing in streaming jobs
• Logging + monitoring (Log Analytics / Databricks logs)

I use ADF Databricks Notebook activity:

• Prefer job clusters for cost optimization
• Pass parameters from ADF to notebook
• Use cluster or job cluster
• Chain multiple notebooks in pipeline
• Use retries + monitoring in ADF

ADF supports built-in retry at the activity level:

• You can configure retry count + interval
• Used for transient failures (network, timeout, throttling)
• Works per activity (Copy, Databricks, Web, etc.)
• Combined with timeout settings for better resilience

But retries should not replace good design (idempotency is still required).

From ADF side, I rely on:

• Activity output logs
  • ADF captures Databricks job run URL + run ID
• Error message propagation
  • ADF shows Databricks notebook failure message (exit code / exception summary)
• Databricks Job Run API / UI
  • Use run ID to open detailed error logs in Databricks
• Log Analytics integration
  • Centralized monitoring if enabled
• Notebook logging best practice
  • Explicit try/except + logging errors back to ADF (custom messages)

So ADF gives high-level error, Databricks gives detailed stack trace.

Answer: * I design a resilient ingest architecture rather than forcing hardcoded mappings. In ADF, I use Mapping Data Flows with the “Allow Schema Drift” option enabled so the pipeline doesn’t break when a source team adds a column.

When landing data into the Databricks Bronze layer, I utilize Databricks Auto Loader (cloudFiles) with Schema Evolution enabled (.option("mergeSchema", "true")). This allows Delta Lake to automatically infer and append new columns to the table schema on-the-fly, while isolating structural alerts into a monitoring log.

Databricks offers several ways to store data. First, there’s the Databricks File System for storing and managing files. Then, there’s Delta Lake, an open-source storage layer that adds ACID transactions to Apache Spark, making it more reliable. Databricks also integrates with cloud storage services like AWS S3, Azure Blob Storage, and Google Cloud Storage. Plus, you can connect to a range of external databases, both relational and NoSQL, using JDBC.

Databricks Delta, now known as Delta Lake, is an open-source storage layer that brings ACID transactions to Apache Spark and big data workloads. It enhances Azure Databricks by providing features like:

• ACID transactions for data reliability and consistency.
• Scalable metadata handling for large tables.
• Time travel for data versioning and historical data analysis.
• Schema enforcement and evolution.
• Improved performance with data skipping and Z-ordering

there are several alternative technologies that provide Delta Lake–style Lakehouse capabilities (ACID + schema enforcement + time travel + scalable storage + SQL engine). such as,

• Apache Iceberg
• Apache Hudi
• Snowflake (Iceberg Tables / Unistore)
• BigQuery + BigLake
• AWS Redshift + Lake Formation + Apache Iceberg
• Microsoft Fabric (OneLake + Delta/DQ/DLTS)

Yes. Delta Live Tables, or DLT, is a Databricks framework for building and managing reliable data pipelines. In current Databricks terminology, it is part of Lakeflow Declarative Pipelines, but DLT is still commonly used in projects and interviews.

I have used DLT in my previous projects, mainly for production data pipelines using the Bronze, Silver, and Gold architecture.

For example, in the Bronze layer, we ingested raw data from sources such as APIs, files, and enterprise systems. In Silver, we used DLT for data cleansing, validation, deduplication, CDC processing, and business transformations. The Gold layer provided curated datasets for reporting and downstream applications.

One of the key features I used was data quality expectations. I could define rules such as required business keys, valid values, and data completeness. Depending on the requirement, invalid records could be quarantined or handled separately instead of simply being dropped, while the pipeline continued processing valid data.

DLT is also declarative, which means I define what the target datasets should look like and how they depend on upstream data, rather than manually managing every execution step. Databricks manages things such as pipeline dependencies, incremental processing, monitoring, and lineage.

I also used DLT with incremental processing and CDC patterns, including identifying new or changed records using business keys and timestamps and applying changes to Delta tables.

So, in my experience, DLT is not just a transformation tool. I used it as part of a production-grade data engineering solution, covering ingestion, transformation, data quality, incremental processing, CDC, dependency management, monitoring, and the overall Bronze-Silver-Gold architecture.

I would use DLT when I need a more managed and reliable data pipeline, especially for multi-stage production pipelines.

The main advantage is that DLT provides a declarative approach. I define the data transformations and dependencies, and Databricks manages much of the pipeline execution.

It also provides built-in capabilities for data quality expectations, dependency management, incremental processing, lineage, monitoring, and pipeline recovery.

For example, if I have a Bronze-to-Silver-to-Gold pipeline with multiple dependent datasets, DLT can manage those dependencies and process the data incrementally instead of requiring me to build all of that orchestration logic myself.

Regular Databricks Jobs are still very useful, especially for custom Python or PySpark processing, batch jobs, orchestration, and tasks that don’t naturally fit a declarative pipeline.

So I would say the key difference is: Databricks Jobs are primarily an execution and orchestration mechanism, while DLT provides a more complete framework for building and operating reliable data pipelines.

Delta Table vs Delta Live Tables (Side-by-Side)

Schema evolution allows Delta tables to automatically or manually adapt when new columns are added or schema changes occur, without breaking pipelines.

Schema Enforcement means the system validates incoming data against a predefined schema before writing the data. It checks column names, data types, and structure to ensure data consistency and quality. And the system will reject the write or throw an error if incoming data does not match the expected schema.

A schema contract is an agreement between a data producer and a data consumer that defines the expected structure and rules of the data.

For example, it can define the required columns, data types, nullable rules, and sometimes business constraints.

The purpose is to make sure the producer and consumer have a clear and stable understanding of what the data should look like.

For example, if the contract says customer_id must be a non-null STRING, the producer should always provide the data in that format. If the producer wants to make a breaking change, such as changing the data type, that change needs to be agreed upon and managed.

So, in simple terms, a schema contract is the agreed data interface between the producer and the consumer.

Time Travel is a feature that allows you to access and query previous versions of data in a table.

In Delta Lake, every data change (insert, update, delete) is versioned. This means the system keeps a history of changes, and you can query the table as it existed at a specific point in time or version.

SELECT * FROM table VERSION AS OF 5;
SELECT * FROM table TIMESTAMP AS OF '2024-01-01';

1. Bronze Layer (Raw Data): Ingest raw data from various sources into the Bronze layer. This data is stored as-is, without any transformation.
2. Silver Layer (Cleaned Data, as known Enriched layer): Clean and enrich the data from the Bronze layer. Apply transformations, data cleansing, and filtering to create more refined datasets.
3. Gold Layer (Aggregated Data, as known Curated layer): Aggregate and further transform the data from the Silver layer to create high-level business tables or machine learning features. This layer is used for analytics and reporting.

Z-Ordering in Databricks (specifically for Delta Lake tables) is an optimization technique designed to co-locate related information into the same set of data files on disk.

OPTIMIZE mytable
ZORDER BY (col1, col2);

Liquid Clustering is Databricks’ next-generation data layout optimization for Delta Lake.
It replaces (and is far superior to) Z-Order.

## At creation time:
CREATE TABLE sales
CLUSTER BY (customer_id, event_date)
AS SELECT * FROM source;

## For existing tables:
ALTER TABLE sales
CLUSTER BY (customer_id, event_date);

## Trigger the actual clustering:
OPTIMIZE sales;

## Remove clustering:
ALTER TABLE sales
CLUSTER BY NONE;

Dataframe refers to a specified form of tables employed to store the data within Databricks during runtime. In this data structure, the data will be arranged into two-dimensional rows and columns to achieve better accessibility.

RDD, Resilient Distributed Dataset, is a fault-tolerant, immutable collection of elements partitioned across the nodes of a cluster. RDDs are the basic building blocks that power all of Spark’s computations.

Dataset is an extension of the DataFrame API that provides compile-time type safety and object-oriented programming benefits.

A cache is a temporary storage that holds frequently accessed data, aiming to reduce latency and enhance speed. Caching involves the process of storing data in cache memory.

This is the standard Apache Spark feature. It stores data in the JVM Heap (Memory).

This is a Databricks-specific optimization. It automatically stores copies of remote files (Parquet/Delta) on the local NVMe SSDs of the worker nodes.

both .cache() and .persist() are used to save intermediate results to avoid re-computing the entire lineage. The fundamental difference is that .cache() is a specific, pre-configured version of .persist().

.cache(): This is a shorthand for .persist(StorageLevel.MEMORY_ONLY). It tries to store your data in the JVM heap as deserialized objects.

.persist(): This is the more flexible version. It allows you to pass a StorageLevel to decide exactly how and where the data should be stored (RAM, Disk, or both).

When optimizing Databricks workloads, I focus on several layers. First, I optimize data layout using partitioning and Z-ordering on Delta tables. Second, I improve Spark performance by using broadcast joins, filtering data early, and caching intermediate results. Third, I tune cluster resources such as autoscaling and Photon engine. Finally, I run Delta maintenance commands like OPTIMIZE and VACUUM to manage small files and improve query performance.

Data Layout Optimization:
Partitioning:
CREATE TABLE sales
USING DELTA
PARTITIONED BY (date)

Z-Ordering:
OPTIMIZE sales
ZORDER BY (customer_id);

Liquid Clustering:

Photon is a high-performance query engine built in C++ that accelerates SQL queries and data processing workloads in Azure Databricks. It improves performance by using vectorized processing and optimized execution for modern hardware.

Data skew happens when some partitions have much more data than others, causing slow tasks and performance bottlenecks.

Data skew usually happens during:

• Joins
• GroupBy
• Aggregations

Answer: * Diagnosis: I look at the Spark UI. If one task takes significantly longer than others (Stage Skew) or if an executor’s memory usage spikes and drops unexpectedly, it indicates data skew. If an executor JVM dies entirely, it’s an OOM error.

I optimize partitioning using Adaptive Query Execution (AQE) or implement Liquid Clustering in Delta Lake to maintain balanced, performance-aware file sizes.

Mitigation for Skew: * If joining on a skewed key, I leverage Broadcast Joins if one table is small enough.

For larger tables, I use Skew Hints in Spark SQL (/*+ SKEW('tablename', 'columnname') */) to force Spark to salt the skewed key automatically.

Mitigation for OOM: * I review the code for anti-patterns like calling .collect() on large DataFrames.

1. Salting: split one hot key into multiple keys
   for example: Add a random key to spread data across partitions.
   sample data:
   Partition 1: US (1M rows) ← Skew, slow
   Partition 2: UK (10k rows)
   Partition 3: CA (5k rows)
   
   doing this “Salting”
   df = df.withColumn("salt", rand() % 10)
   result:
   US_0 → 200k
   US_1 → 200k
   US_2 → 200k
   US_3 → 200k
   US_4 → 200k
   
   
   then re-partition by the new “salt” column
   df.repartition("salt")
   
   AFTER (Salting)
   Partition 1: US_0
   Partition 2: US_1
   Partition 3: US_2
   Partition 4: US_3
   Partition 5: US_4
   
2. Better Partitioning: Repartition data using a better key.
   df.repartition(“country”)
3. AQE:
   AQE (Adaptive Query Execution) in Spark dynamically optimizes query execution during runtime.
   
   How to enable AQE. It can adjust join strategies, merge small partitions, and handle data skew by splitting large partitions based on real execution statistics instead of static estimates.
   spark.conf.set("spark.sql.adaptive.enabled", "true")

I handle late data using:

• Reprocessing logic for backfill if needed
• Event-time processing (not processing-time)
• Watermarking in Structured Streaming
• Window-based aggregations
• Delta Lake MERGE INTO for upserts

Batch processing processes data in chunks at scheduled intervals, while streaming processes data continuously in near real-time.

Databricks uses Structured Streaming, which treats streaming as incremental batch processing with fault tolerance.

I manage cost by:

• Using Photon and Delta optimizations to reduce compute time
• Using autoscaling clusters
• Choosing right node types (memory vs compute optimized)
• Using job clusters instead of all-purpose clusters
• Auto-termination for idle clusters

I validate data quality using:

• Row count validation
• Null checks
• Duplicate checks
• Data type validation
• Referential integrity checks
• Business rule validation

I usually automate these checks in pipelines and log failures.

I monitor failures using:

• ADF Monitor
• Databricks job monitoring
• Log Analytics / Azure Monitor
• Alerts and notifications (email/Teams)
• Custom logging tables

I also track pipeline run IDs for troubleshooting.

Key production metrics:

• Pipeline success/failure rate
• Execution duration
• Throughput
• Data latency
• Row counts
• Error counts
• Cluster utilization/cost
• SLA compliance

These help identify performance or reliability issues.

Schema drift happens when source schema changes unexpectedly.

I handle it by:

• Enabling schema evolution
• Using dynamic column mapping
• Metadata-driven pipelines
• Auto Loader schema inference
• Logging and alerting schema changes
• Separating mandatory vs optional columns

1. Use Azure Key Vault to store and manage secrets securely.
2. Integrate Azure Key Vault with Azure Databricks using Databricks-backed or Azure-backed scopes.
3. Access secrets in notebooks and jobs using the dbutils.secrets API.
   dbutils.secrets.get(scope=”<scope-name>”, key=”<key-name>”)
4. Ensure that secret access policies are strictly controlled and audited.

I design it using a layered approach (Medallion Architecture):

• Bronze: raw ingestion (batch/streaming via ADF / Auto Loader)
• Silver: cleaned and standardized data
• Gold: business-ready aggregated data

For scalability:

• Use Auto Loader for incremental file ingestion
• Use partitioning + incremental loads
• Decouple ingestion and transformation
• Use Delta Lake for reliability and ACID

• Data Classification: Classify data based on sensitivity and compliance requirements.
• Access Controls: Implement role-based access control (RBAC) using Azure Active Directory.
• Data Lineage: Use tools like Databricks Lineage to track data transformations and movement.
• Audit Logs: Enable and monitor audit logs to track access and changes to data.
• Compliance Policies: Implement Azure Policies and Azure Purview for data governance and compliance monitoring.

1. Repartitioning: Repartition the data to balance the workload across nodes and reduce skew.
2. Broadcast Joins: Use broadcast joins for small datasets to avoid shuffle operations.
3. Caching: Cache intermediate results to reduce the need for recomputation.
4. Shuffle Partitions: Increase the number of shuffle partitions to distribute the workload more evenly.
5. Skew Handling: Identify and handle skewed data by adding salt keys or custom partitioning strategies.

• Assessment: Evaluate the existing Hadoop workloads and identify components to be migrated.
• Data Transfer: Use Azure Data Factory or Azure Databricks to transfer data from on-premises HDFS to ADLS.
• Code Migration: Convert Hadoop jobs (e.g., MapReduce, Hive) to Spark jobs and test them in Databricks.
• Optimization: Optimize the Spark jobs for performance and cost-efficiency.
• Validation: Validate the migrated workloads to ensure they produce the same results as on-premises.
• Deployment: Deploy the migrated workloads to production and monitor their performance.

Answer: * Databricks Notebooks are excellent for ad-hoc exploration, rapid prototyping, and interactive data analysis. They combine markdown documentation with executable code blocks, making them highly visual.

Decision Criteria: For production ETL pipelines, I advocate for modular code deployed via Databricks Jobs. It allows us to implement proper software engineering practices, such as unit testing (via pytest), static code analysis, and robust CI/CD branch policies. Notebooks are kept strictly for initial R&D or orchestrating lightweight, high-level control flows.

Modular Python Code (e.g., packaged .py files/wheels) breaks logic down into reusable, unit-testable classes and functions.

Answer: * df.collect() pulls every single row from the distributed executors across the network and dumps it into the memory of the single Driver node, converting the Spark DataFrame into a local Python list. It is highly dangerous because if the data volume exceeds the Driver’s available RAM, it triggers an immediate OOM crash.

df.take(n) and df.show(n) only retrieve the first n rows. They are safe because they cap the memory allocation on the Driver, making them ideal for debugging or lightweight data sampling.

Step 1 — Enable Unity Catalog
Step 2 — Create Catalog and Schema
Step 3 — Configure External Location

Step 4 — Assess Hive Tables: Check:

• managed vs external tables
• Delta vs non-Delta
• table size
• dependencies
• downstream jobs
• permissions

Step 5 — Convert Non-Delta Tables (IMPORTANT)
CONVERT TO DELTA parquet.`abfss://container/path`;
or
CONVERT TO DELTA hive_metastore.sales.orders;

Step 6 — Migrate Tables

CREATE TABLE finance.sales.orders
DEEP CLONE hive_metastore.sales.orders;

or 

CREATE TABLE finance.sales.orders AS
SELECT * FROM hive_metastore.sales.orders;

or 
SYNC TABLE finance.sales.orders
FROM hive_metastore.sales.orders;
SYNC works mainly for: external tables and metadata sync scenarios

Step 7 — Migrate Permissions
GRANT SELECT ON TABLE finance.sales.orders TO analysts;

Answer: * Hardcoding passwords or keys in code is strictly prohibited. I create an Azure Key Vault-backed Secret Scope within Databricks.

All database passwords, API keys, and service principal secrets live inside Azure Key Vault. When Databricks runs a pipeline, it fetches these secrets securely at runtime using dbutils.secrets.get(). Credential rotation is handled upstream entirely within Azure Key Vault (often via automated Azure Functions), and Databricks automatically reflects the rotated values without requiring code changes.

Yes. Delta Sharing is an open protocol developed by Databricks for securely sharing data across different organizations, platforms, and cloud environments without requiring the recipient to copy or physically move the underlying data.

I have used Delta Sharing in Databricks environments to share Delta tables and curated datasets with downstream consumers. For example, instead of creating another physical copy of the data for a consumer, we can provide controlled access to the shared data through a Delta Share.

A key advantage is that the provider can control what data is shared and who can access it. We can share specific tables or views rather than giving consumers direct access to the underlying storage.

In a typical implementation, the provider creates a share and adds the required tables or views. The recipient is then granted access and can consume the shared data using supported clients, without needing access to the provider’s underlying ADLS or cloud storage.

I also see Delta Sharing as useful for cross-organization and cross-cloud data sharing, because the consumer doesn’t necessarily need to be on the same Databricks workspace or even the same cloud platform.

So the key point is: Delta Sharing provides governed data sharing without requiring traditional data copying or giving the consumer direct access to the underlying storage.

Unity Catalog Volumes provide a governed way to manage non-tabular files in cloud storage through Unity Catalog.

in short, Delta tables are for structured/tabular data; Volumes are for files, unstructured.

Unity Catalog Volumes provide a governed way to access and manage files in cloud storage that are not necessarily Delta tables.

I have used Volumes in Databricks environments for file-based data such as documents, JSON, CSV, and other files that need to be accessed by data engineering or AI workloads.

There are two main types: managed volumes and external volumes. With a managed volume, Databricks manages the underlying storage. With an external volume, the data remains in an external cloud storage location such as ADLS Gen2, while Unity Catalog provides centralized governance and access control.

One of the main benefits is that users and workloads can access files through a governed Unity Catalog path such as /Volumes/<catalog>/<schema>/<volume>/..., rather than directly accessing cloud storage credentials or storage paths.

This is particularly useful when we need to apply centralized access control, auditing, and governance to file-based data.

So, in simple terms, Unity Catalog tables are primarily for governed structured data, while Volumes provide governed access to files.

Answer: * Effective prompt design relies on clear persona, context, and explicit constraints.

Example Prompt: “You are an expert Data Architect. Act as a technical documentation writer. Analyze the following PySpark code which performs a Type 2 Slowly Changing Dimension (SCD Type 2) merge. Write a technical markdown document explaining the data lineage, column mappings, and transformation logic. Constraints: Do not use placeholder code. Do not explain standard PySpark syntax. Format the column mappings strictly in a markdown table. Highlight the idempotency mechanics of the code.”

I use generative AI tools like GitHub Copilot and ChatGPT as productivity accelerators across development, testing, and optimization, but always within a controlled and validated engineering workflow.

For example, when building Databricks notebooks, I use Copilot to scaffold initial PySpark structures such as data ingestion patterns, Delta table reads/writes, and common transformation templates. This helps me quickly set up a working baseline, especially for standard ETL/ELT pipelines, while I focus on business logic, data modeling, and performance design.

For unit testing, I use ChatGPT or Copilot to generate initial PySpark or SQL test cases, such as null checks, schema validation, row count verification, and data quality rules. I then refine these tests to align with data contracts and production expectations, ensuring they are meaningful and not just syntactically correct.

For SQL optimization, I often use ChatGPT to analyze slow queries and suggest improvements like better join strategies, partition pruning, or indexing considerations. However, I always validate improvements using query execution plans, Databricks Spark UI, and actual runtime benchmarks before applying changes.

In all cases, I treat AI as an assistant rather than an authority. I ensure no sensitive or PII data is included in prompts, and all AI-generated code is reviewed, tested, and validated before production deployment. The goal is to improve engineering velocity without compromising correctness, security, or governance.

Answer: * Data privacy is paramount, especially in financial services. My absolute rule is that no actual client data, proprietary database schemas, or PII can ever enter a commercial AI prompt.

When utilizing AI for troubleshooting or code generation, I completely anonymize and abstract the prompt. I swap out proprietary table names for generic placeholders (e.g., Table_A, Table_B), obfuscate custom column names (e.g., changing account_balance_cad to metric_1), and generate synthetic mockup rows if I need to illustrate a data structure issue.

I never take AI-generated code at face value; it must be fully verified. My validation process includes:

Unit Testing: Verify the output against expected boundaries (checking edge cases like handling of Null values or empty DataFrames). Only after it passes automated testing do I integrate it into the codebase and open a PR.

Code Review & Linting: Check for syntax errors, deprecated Spark methods, or non-existent library parameters.

Local/Dev Execution: Run the generated code block inside a isolated scratchpad environment using a small, controlled sample dataset.