Why Kappa architecture (streaming only) in Hadoop? - Purpose & Use Cases

The Big Idea

What if you could fix past data mistakes instantly without juggling multiple systems?

The Scenario

Imagine you have a busy store with thousands of customers every day. You try to write down every sale by hand on paper to understand what sells best. But the notes pile up, get messy, and you miss some details.

The Problem

Writing down each sale manually is slow and mistakes happen easily. When you want to check past sales, you have to dig through piles of paper. It's hard to keep up with new sales while fixing old mistakes.

The Solution

Kappa architecture lets you handle all sales as a continuous stream of data. Instead of separate systems for old and new data, you use one simple process that updates in real-time and can replay past data if needed. This keeps things clean and fast.

Before vs After

✗ Before

read old files; process new files separately; merge results manually

✓ After

process data as one stream; replay stream to fix or update results

What It Enables

You can build fast, reliable systems that handle live data and past data with one simple flow.

Real Life Example

A music app tracks every song played live and can replay past plays to fix errors or update recommendations instantly.

Key Takeaways

Manual data handling is slow and error-prone.

Kappa architecture uses one streaming process for all data.

This approach simplifies updates and improves real-time insights.

Practice

1.

What is the main idea behind the Kappa architecture in data processing?

easy

A. Store data in batches and process later

B. Process data only once as a continuous stream

C. Use separate systems for batch and streaming data

D. Process data multiple times for accuracy

Solution

1. Step 1: Understand Kappa architecture concept

   Kappa architecture focuses on processing data as a stream only once, avoiding batch processing.

2. Step 2: Compare with other architectures

   Unlike Lambda architecture, Kappa does not separate batch and streaming layers.

3. Final Answer:

   Process data only once as a continuous stream -> Option B

4. Quick Check:

   Kappa = single stream processing [OK]

Hint: Kappa means one stream, one processing path [OK]

Common Mistakes:

• Confusing Kappa with Lambda architecture
• Thinking Kappa uses batch processing
• Assuming multiple processing passes

2.

Which of the following is a correct component used in a typical Kappa architecture setup?

A) Separate batch and speed layers

B) Hadoop MapReduce for batch jobs

C) HDFS for storing batch data

D) Kafka for streaming data

easy

A. Separate batch and speed layers

B. Hadoop MapReduce for batch jobs

C. HDFS for storing batch data

D. Kafka for streaming data

Solution

1. Step 1: Identify streaming components in Kappa

   Kappa architecture uses streaming tools like Kafka to handle real-time data.

2. Step 2: Exclude batch-specific components

   Batch tools like MapReduce or HDFS batch storage are not part of Kappa's streaming-only design.

3. Final Answer:

   Kafka for streaming data -> Option D

4. Quick Check:

   Kappa uses Kafka, not batch tools [OK]

Hint: Kappa = streaming tools like Kafka only [OK]

Common Mistakes:

• Choosing batch tools like MapReduce
• Selecting batch storage like HDFS
• Thinking Kappa has separate batch layers

3.

Consider this simplified streaming code snippet using Kafka and Spark in a Kappa architecture:

from pyspark.sql import SparkSession
spark = SparkSession.builder.appName('KappaExample').getOrCreate()

# Read stream from Kafka topic
stream_df = spark.readStream.format('kafka') \
  .option('kafka.bootstrap.servers', 'localhost:9092') \
  .option('subscribe', 'events') \
  .load()

# Select and cast value to string
value_df = stream_df.selectExpr('CAST(value AS STRING)')

# Write stream to console
query = value_df.writeStream.outputMode('append').format('console').start()

query.awaitTermination()

What will this code do?

medium

A. Continuously print new Kafka messages from 'events' topic to console

B. Read all past Kafka messages once and stop

C. Write data back to Kafka topic 'events'

D. Throw an error due to missing schema

Solution

1. Step 1: Understand the streaming read

   The code reads a continuous stream from Kafka topic 'events' using Spark Structured Streaming.

2. Step 2: Analyze output mode and sink

   Output mode 'append' with console sink means new messages print continuously to console.

3. Final Answer:

   Continuously print new Kafka messages from 'events' topic to console -> Option A

4. Quick Check:

   Streaming read + console output = continuous print [OK]

Hint: Streaming read + console output = live print [OK]

Common Mistakes:

• Thinking it reads all past messages once
• Assuming it writes back to Kafka
• Expecting schema error without explicit schema

4.

Identify the error in this Kappa architecture streaming code snippet using Kafka and Spark:

stream_df = spark.readStream.format('kafka') \
  .option('kafka.bootstrap.servers', 'localhost:9092') \
  .option('subscribe', 'events') \
  .load()

value_df = stream_df.selectExpr('CAST(value AS STRING)')

query = value_df.writeStream.outputMode('complete').format('console').start()

query.awaitTermination()

What is the problem?

medium

A. Output mode 'complete' is invalid for streaming without aggregation

B. Missing schema definition causes failure

C. Kafka server address is incorrect

D. No error, code runs fine

Solution

1. Step 1: Check output mode usage

   Output mode 'complete' requires aggregation queries to output full results.

2. Step 2: Analyze query type

   This query only selects and casts values without aggregation, so 'complete' mode is invalid.

3. Final Answer:

   Output mode 'complete' is invalid for streaming without aggregation -> Option A

4. Quick Check:

   'complete' mode needs aggregation [OK]

Hint: 'complete' mode only with aggregation queries [OK]

Common Mistakes:

• Assuming missing schema causes error
• Thinking Kafka address is wrong
• Believing code runs without error

5.

You want to build a real-time dashboard using Kappa architecture that shows the count of events per user from a Kafka stream. Which approach fits best?

A) Use two separate systems: one for batch counts and one for streaming counts, then merge results.

B) Store Kafka data in HDFS, run daily batch jobs to count events per user, then update dashboard.

C) Use Spark Structured Streaming to read Kafka, group by user, count events, and update dashboard continuously.

D) Read Kafka stream once and save raw data only, no processing.

hard

A. Use two separate systems: one for batch counts and one for streaming counts, then merge results.

B. Store Kafka data in HDFS, run daily batch jobs to count events per user, then update dashboard.

C. Use Spark Structured Streaming to read Kafka, group by user, count events, and update dashboard continuously.

D. Read Kafka stream once and save raw data only, no processing.

Solution

1. Step 1: Understand Kappa architecture goal

   Kappa architecture processes data as a stream only, avoiding batch layers.

2. Step 2: Choose streaming aggregation for real-time dashboard

   Using Spark Structured Streaming to group and count events per user fits Kappa's streaming-only design and real-time needs.

3. Step 3: Exclude batch or hybrid approaches

   Batch jobs or separate batch/stream systems contradict Kappa principles.

4. Final Answer:

   Use Spark Structured Streaming to read Kafka, group by user, count events, and update dashboard continuously. -> Option C

5. Quick Check:

   Real-time + streaming aggregation = Use Spark Structured Streaming to read Kafka, group by user, count events, and update dashboard continuously. [OK]

Hint: Real-time dashboard needs streaming aggregation [OK]

Common Mistakes:

• Choosing batch processing for real-time needs
• Using hybrid batch and streaming systems
• Not processing data, just storing raw stream