Spring Boot 4 Complete Guide · 강의

청크 중심 Reader-Processor-Writer 흐름

확장 가능한 청크 처리를 위해 ItemReader, ItemProcessor 및 ItemWriter 구성 요소를 연결합니다.

청크 중심 Reader-Processor-Writer 흐름은(는) CoddyKit의 무료 Spring Boot 4 Complete Guide 강의입니다. 이것은 4개 중 2번째 강의입니다. 아래에서 전체 강의를 무료로 읽을 수 있으며, 내장 코드 에디터와 24/7 AI 튜터와 함께 브라우저에서 직접 실습할 수 있습니다. 이 강의는 Spring Boot 4 Complete Guide 학습 경로의 일부이며, 진행 상황이 웹과 CoddyKit 앱에 동기화됩니다. Spring Boot 4 Complete Guide 강의에는 총 4개의 강의가 포함되어 있습니다.

이 강의의 일부는 아직 번역되지 않았으며 영어로 표시됩니다.

Why Chunk-Oriented Processing?

Spring Batch reads, processes, and writes data in chunks instead of one record at a time. A chunk is a configurable number of items (the commit-interval) handled inside a single transaction.

Read N items one by one with an ItemReader.
Process each item with an ItemProcessor.
Write the whole batch of N at once with an ItemWriter.

Writing in bulk and committing per chunk is what makes batch jobs scale to millions of rows without exhausting memory.

The Three Core Interfaces

Every chunk step is built from three single-method interfaces. Knowing their contracts is the foundation of the whole pattern.

ItemReader<I> → I read() returns the next item, or null when the input is exhausted.
ItemProcessor<I, O> → O process(I item) transforms an input into an output; returning null filters the item out.
ItemWriter<O> → void write(Chunk<? extends O> chunk) persists the accumulated chunk.

public interface ItemReader<I> {
    I read() throws Exception; // null = end of input
}

public interface ItemProcessor<I, O> {
    O process(I item) throws Exception; // null = filter
}

public interface ItemWriter<O> {
    void write(Chunk<? extends O> chunk) throws Exception;
}

Defining a Domain Type

A chunk step flows typed data from reader to processor to writer. Let's model a simple input and output. The reader emits raw Customer records and the writer stores normalized ones.

Using a Java record keeps these immutable value types concise. This snippet is plain Java with no framework, so it runs standalone.

public class DomainDemo {
    record Customer(String name, String email) {}

    public static void main(String[] args) {
        Customer c = new Customer("  Ada ", "ADA@MAIL.COM");
        Customer normalized = new Customer(
                c.name().trim(),
                c.email().toLowerCase());
        System.out.println(normalized);
    }
}

Building the ItemReader

For database input, JdbcCursorItemReader streams rows one at a time so memory stays flat. You give it a DataSource, a SQL query, and a RowMapper to turn each row into a domain object.

Spring Batch calls read() repeatedly until it returns null, advancing the cursor each time.

@Bean
public JdbcCursorItemReader<Customer> reader(DataSource dataSource) {
    return new JdbcCursorItemReaderBuilder<Customer>()
            .name("customerReader")
            .dataSource(dataSource)
            .sql("SELECT name, email FROM customers WHERE active = true")
            .rowMapper((rs, rowNum) ->
                    new Customer(rs.getString("name"), rs.getString("email")))
            .build();
}

Building the ItemProcessor

The processor is where business logic lives: validation, enrichment, transformation, or filtering. Its input and output types may differ.

Return a transformed object to pass it downstream.
Return null to skip the item entirely — it never reaches the writer.

Keep processors stateless and idempotent so they behave correctly when chunks are retried.

@Bean
public ItemProcessor<Customer, Customer> processor() {
    return customer -> {
        if (customer.email() == null || !customer.email().contains("@")) {
            return null; // filter invalid records out of the chunk
        }
        return new Customer(
                customer.name().trim(),
                customer.email().toLowerCase());
    };
}

Building the ItemWriter

The writer receives the whole processed chunk at once via a Chunk<O>. Writing in bulk — one batched INSERT per chunk instead of one per row — is the key performance win.

JdbcBatchItemWriter uses a parameterized SQL statement and a bean-property parameter source to map fields automatically.

@Bean
public JdbcBatchItemWriter<Customer> writer(DataSource dataSource) {
    return new JdbcBatchItemWriterBuilder<Customer>()
            .dataSource(dataSource)
            .sql("INSERT INTO customers_clean (name, email) VALUES (:name, :email)")
            .beanMapped()
            .build();
}

Wiring the Chunk Step

A Step ties the three components together. The generic types <Customer, Customer> declare the input and output of the chunk, and the integer is the commit-interval.

With a chunk size of 100, Spring Batch reads 100 items, processes each, then writes all survivors in one transaction before committing.

@Bean
public Step chunkStep(JobRepository jobRepository,
                      PlatformTransactionManager txManager,
                      ItemReader<Customer> reader,
                      ItemProcessor<Customer, Customer> processor,
                      ItemWriter<Customer> writer) {
    return new StepBuilder("chunkStep", jobRepository)
            .<Customer, Customer>chunk(100, txManager)
            .reader(reader)
            .processor(processor)
            .writer(writer)
            .build();
}

Assembling the Job

A Job is an ordered set of steps. For a single chunk step, the job simply starts with it. Spring Boot auto-detects the Job bean and runs it on startup.

The JobRepository records execution metadata — status, read/write counts, and the last committed position — enabling restartability.

@Bean
public Job importCustomersJob(JobRepository jobRepository, Step chunkStep) {
    return new JobBuilder("importCustomersJob", jobRepository)
            .start(chunkStep)
            .build();
}

Choosing the Chunk Size

The commit-interval is a tuning lever, not a magic number.

Too small (e.g. 1): one transaction per row — high commit overhead, slow.
Too large (e.g. 100,000): bigger transactions, more memory and rollback cost if a chunk fails.
Typical sweet spot: 100–1000, tuned by measuring throughput against your database and row size.

Remember: a failed item rolls back the entire chunk, so larger chunks mean more work redone on failure.

Fault Tolerance: Skip and Retry

Real input is messy. Wrap the step with .faultTolerant() to keep processing despite isolated failures.

.skip(...) — tolerate up to skipLimit bad items instead of failing the job.
.retry(...) — re-attempt transient errors (e.g. deadlocks) up to retryLimit before giving up.

On a skip or retry, Spring Batch re-scans the chunk item by item, isolating the offending record.

@Bean
public Step faultTolerantStep(JobRepository jobRepository,
                              PlatformTransactionManager txManager,
                              ItemReader<Customer> reader,
                              ItemProcessor<Customer, Customer> processor,
                              ItemWriter<Customer> writer) {
    return new StepBuilder("ftStep", jobRepository)
            .<Customer, Customer>chunk(100, txManager)
            .reader(reader)
            .processor(processor)
            .writer(writer)
            .faultTolerant()
            .skip(FlatFileParseException.class)
            .skipLimit(20)
            .retry(DeadlockLoserDataAccessException.class)
            .retryLimit(3)
            .build();
}

The Chunk Lifecycle in Order

Putting it together, each chunk follows the same loop inside one transaction:

1. Read: call read() repeatedly until chunk-size items are buffered (or null ends input).
2. Process: call process() on each item; nulls are filtered out.
3. Write: pass the surviving items as one Chunk to write().
4. Commit: commit the transaction and record progress in the JobRepository.

Then the loop repeats for the next chunk until the reader is exhausted.

Quick Check

Test your understanding of the chunk pipeline.

Recap

You wired a complete chunk-oriented flow in Spring Batch:

ItemReader streams input one item at a time, returning null at the end.
ItemProcessor transforms or filters items; null drops an item.
ItemWriter persists the whole chunk in bulk for performance.
The Step binds them with a chunk(size, txManager) commit-interval, and the Job orchestrates the steps.
Tune chunk size for throughput, and add .faultTolerant() with skip/retry for resilient pipelines.

This read-process-write loop, committed per chunk, is the backbone of scalable batch processing.

자주 묻는 질문

“청크 중심 Reader-Processor-Writer 흐름” 강의는 무료인가요?

네 — “청크 중심 Reader-Processor-Writer 흐름” 전체 내용을 이 웹사이트에서 무료로 읽을 수 있습니다. 인터랙티브하게 실습하려면(내장 코드 에디터와 24/7 AI 튜터), CoddyKit PRO로 업그레이드하면 Spring Boot 4 Complete Guide 강의 전체를 잠금 해제할 수 있습니다. Spring Boot 4 Complete Guide 강의에는 총 4개의 강의가 포함되어 있습니다.

“청크 중심 Reader-Processor-Writer 흐름”에서 뭘 배우나요?

확장 가능한 청크 처리를 위해 ItemReader, ItemProcessor 및 ItemWriter 구성 요소를 연결합니다. 브라우저에서 직접 실행하는 실습 코드로 Spring Boot 4 Complete Guide을(를) 배우며, 24/7 AI 튜터가 강의를 진행하면서 질문에 답변해줍니다.

Spring Boot 4 Complete Guide을(를) 시작하는 데 경험이 필요한가요?

사전 경험은 필요하지 않습니다. CoddyKit의 Spring Boot 4 Complete Guide은(는) 초급자부터 고급 학습자까지를 위해 구성되어 있으므로, 여기서 시작하거나 처음부터 시작할 수 있으며 자신의 속도대로 진행할 수 있습니다. 이것은 4개 중 2번째 강의입니다.

“청크 중심 Reader-Processor-Writer 흐름” 강의는 얼마나 걸리나요?

대부분의 CoddyKit 강의는 약 5~10분이 소요됩니다. 각 강의는 간결하고 인터랙티브하여 꾸준한 진행이 가능하며, 웹과 앱에서 중단한 부분부터 바로 시작할 수 있습니다.

이 Spring Boot 4 Complete Guide 강의에서 코드를 작성하고 실행할 수 있나요?

네. 모든 Spring Boot 4 Complete Guide 강의에는 내장 코드 에디터가 포함되어 있으므로, 브라우저에서 바로 실제 코드를 작성하고 실행한 후 즉시 AI 피드백을 받을 수 있습니다 — 로컬 설정이 필요 없습니다.

이 강의의 모든 강의

← Spring Boot 4 Complete Guide(으)로 돌아가기