본문 바로가기

Web/spring

[Spring Batch] The Domain Language of Batch - (1) Job

728x90

https://docs.spring.io/spring-batch/docs/current/reference/html/domain.html#domainLanguageOfBatch

 

The Domain Language of Batch

To any experienced batch architect, the overall concepts of batch processing used in Spring Batch should be familiar and comfortable. There are “Jobs” and “Steps” and developer-supplied processing units called ItemReader and ItemWriter. However, be

docs.spring.io

 

틀린 해석이 있다면 알려주세요 🌲

 

 


 

 

The Domain Language of Batch

Batch architect 에는 "Jobs"와 "Steps" 라는 ItemReader, ItemWriter 처리 단위가 있다.

Spring patterns, operations, templates, callbacks and idioms 와 같은 opportunities가 있다

 

 

 

  • Significant improvement in adherence to a clear separation of concerns.
  • Clearly delineated architectural layers and services provided as interfaces.
  • Simple and default implementations that allow for quick adoption and ease of use out of the box.
  • Significantly enhanced extensibility.

 

Batch Stereotypes

Spring Batch는 매우 복잡한 처리 요구 사항을 해결하기 위한 인프라 및 확장 기능을 통해 간단하거나 복잡한 배치 애플리케이션 생성을 처리하는 데 사용되는 견고하고 유지 관리 가능한 시스템에서 일반적으로 발견되는 계층, 구성 요소 및 기술 서비스의 물리적 구현을 ​​제공한다.

 

 

The preceding diagram highlights the key concepts that make up the domain language of Spring Batch. A Job has one to many steps, each of which has exactly one ItemReader, one ItemProcessor, and one ItemWriter. A job needs to be launched (with JobLauncher), and metadata about the currently running process needs to be stored (in JobRepository).

 

 

 

 

-> batch 작업의 개념과 stereotypes

 

Job 

Job은 전체 batch process를 캡슐화 하는 entity이다. 다른 Spring project처럼 XML, Java 기반 구성으로 연결한다. (이 구성을 "job configuration") 라고 한다. Job은 아래의 이미지처럼 전체 계층 구조의 최상위이다.

Job Hierarchy

 

Spring Batch에서 Job은 단순히 "Step"을 위한 instance container이다. flow에서 여러 단계를 결합하고, restatability를 찾는 전역 속성 구성을 허용한다

 

The job configuration contains:

  • The name of the job. //job의 이름
  • Definition and ordering of Step instances. //Step의 정의와 순서
  • Whether or not the job is restartable. //다시 시작할지에 대한 여부

 

JobInstance

JobInstance는 논리적인 작업 실행의 개념을 나타낸다.

이전 다이어그램의 EndOfDay 작업과 같이 하루가 끝날 때 한 번 실행되어야 하는 배치 작업이 필요하다고 생각해보자.

EndOfDay 작업이 하나 있지만 작업의 각 개별 실행을 개별적으로 추적해야 한다.

이 작업의 경우 하루에 하나의 논리적 JobInstance가 있다. 예를 들어 1월 1일 실행, 1월 2일 실행 등이 있다.

1월 1일 실행이 처음에 실패하고 다음날 다시 실행되면 여전히 1월 1일 실행이 된다. (일반적으로 이것은 처리 중인 데이터와도 일치합니다. 즉, 1월 1일 실행이 1월 1일 데이터를 처리함을 의미)

따라서 각 JobInstance는 여러 번 실행될 수 있으며(JobExecution은 이 장의 뒷부분에서 자세히 설명함) 주어진 시간에 하나의 JobInstance(특정 Job에 해당하고 JobParameters 식별)만 실행할 수 있다.

 

JobInstance의 정의는 로드할 데이터와 전혀 관련이 없다. 데이터가 로드되는 방식을 결정하는 것은 전적으로 ItemReader 구현에 달려 있다.

 

예를 들어 EndOfDay 시나리오에서 데이터가 속한 유효 날짜 또는 일정 날짜를 나타내는 데이터 열이 있을 수 있다.

따라서 1월 1일 실행은 1일의 데이터만 로드하고 1월 2일 실행은 2일의 데이터만 사용한다.

이 결정은 비즈니스 결정일 가능성이 높으므로 ItemReader가 결정해야 한다.

그러나 동일한 JobInstance를 사용하면 이전 실행의 "state"(즉, 이 장의 뒷부분에서 설명하는 ExecutionContext)가 사용되는지 여부가 결정된다. 새로운 JobInstance를 사용한다는 것은 "start from the beginning"을 의미하고 기존 인스턴스를 사용한다는 것은 일반적으로 "중단한 부분부터 시작//start from where you left off"을 의미한다.

 

 

JobParameters

JobInstance와 Job을 공부하다보면 자연스럽게 "하나의 JobInstance가 다른 JobInstance와 어떻게 구별되는 거지?"라는 질문이 나오게 된다.

그 구별의 답은 "JobParameters"이다. JobParameters 개체는 일괄 작업을 시작할 때 사용되는 매개 변수의 집합을 가지고 있다.

Job Parameters

 

1월 1일에 대한 인스턴스와 1월 2일에 대한 두 개의 인스턴스가 있는 앞의 예에서 하나만 있지만

JobParameter는 2017년 1월 1일 작업 매개변수로 시작된 객체와 2017년 1월 2일 매개변수로 시작되었다.

따라서 contract은 다음과 같이 정의할 수 있다.

 

JobInstance = Job + identifying JobParameters

이를 통해 개발자는 전달되는 매개변수를 제어하므로 JobInstance가 정의되는 방식을 효과적으로 제어할 수 있다

 

JobInstance를 식별하는 데 모든 작업 매개변수가 필요한 것은 아니지만 기본적으로 매개변수를 사용한다.

프레임워크는 JobInstance의 ID에 기여하지 않는 매개변수를 사용하여 Job을 제출할 수도 있다.

 

 

JobExecution

JobExecution은 작업을 실행하려고 하는 단일 시도의 기술 개념을 말한다

Excution(실행)은 실패 또는 성공으로 종료될 수 있지만, 해당 Excution에 해당하는 JobInstance의 실행이 성공적이지 않으면 완료라고 보지 않는다. EndOfDay작업을 예시로 하면 처음 1월 1일 instance를 가 실패되었을 때, 동일한 식별 작업 매개변수를 사용하여 재실행하면 새 JobExecution이 생성된다. 하지만 우리는 하나의 JobInstance만 가지고 있다.

 

Job은 Job의 defines를 정의하며, JobInstance는 Excution을 함께 그룹화하는 조직적인 개체이고 올바르게 다시 시작할 수 있는 semantics를 가능하게 한다.

JobExecution은 실행 중에 실제로 발생한 일에 대한 기본 storage mechanism 이며, controlled and persisted 제어하고 유지해야하는 속성들을 포함한다

 

 

-> JobExecution Properties

Property Definition
Status A BatchStatus object that indicates the status of the execution. While running, it is BatchStatus#STARTED. If it fails, it is BatchStatus#FAILED. If it finishes successfully, it is BatchStatus#COMPLETED
startTime A java.util.Date representing the current system time when the execution was started. This field is empty if the job has yet to start.
endTime A java.util.Date representing the current system time when the execution finished, regardless of whether or not it was successful. The field is empty if the job has yet to finish.
exitStatus The ExitStatus, indicating the result of the run. It is most important, because it contains an exit code that is returned to the caller. See chapter 5 for more details. The field is empty if the job has yet to finish.
createTime A java.util.Date representing the current system time when the JobExecution was first persisted. The job may not have been started yet (and thus has no start time), but it always has a createTime, which is required by the framework for managing job-level ExecutionContexts.
lastUpdated A java.util.Date representing the last time a JobExecution was persisted. This field is empty if the job has yet to start.
executionContext The “property bag” containing any user data that needs to be persisted between executions.
failureExceptions The list of exceptions encountered during the execution of a Job. These can be useful if more than one exception is encountered during the failure of a Job.
 
728x90