Data Pipeline in the Field of Big Data (Korean)
Gyuhang Shim
Introduction to Data Pipeline
데이터 파이프라인은 원시 데이터 (Raw Data) 를 수집하여 유용한 정보로 변환하는 일련의 프로세스를 말합니다.
데이터의 수집, 저장, 처리, 분석, 그리고 시각화까지의 전 과정을 포함하며, Big Data 환경에서는 대용량 데이터의 효율적인 처리를 위해 필수적인 요소입니다.
데이터 파이프라인의 주요 구성 요소
데이터 수집 (Data Ingestion)
데이터 저장 (Data Storage)
데이터 처리 및 변환 (Data Processing and Transformation):
데이터 분석 및 모델링 (Data Analysis and Modeling):
데이터 시각화 및 활용 (Data Visualization and Utilization):
모니터링 및 관리 (Monitoring and Management)
데이터 수집(Data Ingestion)
웹 로그, 센서 데이터, 소셜 미디어, 거래 기록 등 다양한 소스로부터 데이터 수집
배치 (Batch) 처리와 실시간 (Streaming) 처리 방식으로 구분
도구: Apache Flume, Kafka, NiFi 등
수집 단계에서 Message Queue 가 필요한 이유
수집단계와 저장 단계의 Decoupling 을 위해
더 높은 수준에서 추상화가 가능
데이터 저장
HDFS(Hadoop Distributed File System) 등 분산 파일 시스템 사용
NoSQL 데이터베이스(MongoDB, Cassandra), Data Warehouse, Data Lakehouse 등
데이터 처리 및 변환
Batch 처리: 대량의 데이터를 일정 주기로 처리 (예: Apache Hadoop MapReduce)
Stream 처리: 데이터를 실시간으로 처리 (예: Apache Spark Streaming, Flink)
ETL 프로세스: 추출(Extract), 변환(Transform), 적재(Load)의 과정
데이터 분석 및 모델링
데이터 분석: 통계 분석, Data Mining, Machine Learning 을 통한 인사이트 도출
데이터 모델링
데이터베이스에 저장될 데이터의 구조와 관계를 개념적으로 표현하는 과정
비즈니스 요구 사항을 충족시키기 위한 데이터의 정의, 구성 및 제약 조건 정의
일반적으로 개념적, 논리적, 물리적 모델링의 세 단계로 진행
효율적인 데이터 관리와 시스템 개발에 핵심적인 역할을 담당
Tools and Frameworks: Apache Spark, TensorFlow, PyTorch 등
데이터 시각화 및 활용
Tableau, Power BI, D3.js 등을 사용하여 데이터 시각화.
의사결정 지원을 위한 정보 제공을 위해서 보고서 및 대시보드 생성
모니터링 및 관리
시스템의 상태 및 성능을 실시간으로 모니터링
Apache Airflow, Oozie 등을 사용하여 작업들의 orchestration 및 scheduling
데이터 파이프라인 구축 시 고려 사항
확장성(Scalability)
- 데이터 양이 증가함에 따라 시스템이 원활하게 확장되어야 함
신뢰성(Reliability)
- 데이터 손실 없이 안정적으로 운영되어야 함
실시간 처리
- 비즈니스 요구 사항에 따라 실시간 데이터 처리가 필요할 수 있음
데이터 품질
- 정확하고 일관된 데이터를 유지하기 위한 데이터 정제 (Cleaning) 필요
보안 및 프라이버시
- 민감한 데이터의 보안과 개인정보 보호 규정 준수
Big Data Pipeline 에서 사용되는 기술 Stack
데이터 수집
- Apache Kafka, Flume, Logstash, Apache Flink, Apache Storm, Apache Beam
데이터 저장
Hadoop HDFS
Cloud Service: Amazon S3, Google Cloud Storage
데이터 처리
- Apache Spark, Hadoop MapReduce, Apache Flink
데이터베이스
- NoSQL(MongoDB, Cassandra, HBase), RDBMS (MySQL, Oracle)
워크플로우 관리
- Apache Airflow, Luigi
시각화 및 BI 도구
- Tableau, Power BI, Superset, Metabase, Apache Kylin
수집에 사용하는 패턴
Request / Response Pattern
요청이 보내지고 응답이 수신되는 양방향 상호작용입니다.
이 패턴은 주로 HTTP, gRPC 등 다양한 네트워크 프로토콜에서 사용되며, 클라이언트가 서버에 데이터를 요청하거나 특정 작업을 수행하고 그 결과를 받는 방식입니다.
+---------+ +---------+ | | --- Request ---> | | | Client | ---------------------------->| Server | | | | | +---------+ +---------+ | +---------+ +---------+ | | <--- Response --- | | | Client | <----------------------------| Server | | | | | +---------+ +---------+
Publish / Subscribe Pattern
발행자가 여러 구독자에게 메시지를 보내고, 구독자들이 독립적으로 업데이트를 받는 시스템입니다.
이 Pattern 은 Messaging 시스템, Event Streaming 플랫폼 (i.e. Apache Kafka) 등에서 많이 사용됩니다.
+-----------+ +-----------+ +-----------+ | Publisher | | Broker | | Subscriber| +-----------+ +-----------+ +-----------+ | | | | --- Publish Msg -->| | | | --- Msg --------> | (Subscribed) | | | | | --- Msg --------> | (Subscribed) | | | | --- Publish Msg -->| | | | |
One-way Pattern
응답을 기대하지 않는 단방향 통신입니다.
이 패턴은 클라이언트가 서버에 데이터를 전송하고, 이후 서버의 상태나 처리 결과에 대해 관심을 갖지 않는 상황에서 사용됩니다. 예를 들어, 로깅 시스템이나 알림 시스템에서 자주 사용됩니다.
+---------+ +---------+ | | --- Send Message ---> | | | Client | ---------------------------->| Server | | | | | +---------+ +---------+
Request / Acknowledge Pattern
요청이 보내지고, 확인 응답만 받는 패턴입니다.
이 패턴은 요청을 빠르게 처리해야 하는 상황에서 유용하며, 클라이언트는 서버가 요청을 받았다는 사실만을 확인하고, 그 이후 작업 완료 여부는 알 필요가 없는 경우에 적합합니다.
+---------+ +---------+ | | --- Request ---> | | | Client | ---------------------------->| Server | | | | | +---------+ +---------+ | v +------------------+ | Process Request | +------------------+ | +---------+ +---------+ | | <--- Acknowledge --- | | | Client | <----------------------------| Server | | | | | +---------+ +---------+
Stream Pattern
한 시스템에서 다른 시스템으로 시간이 지남에 따라 지속적인 데이터 흐름이 발생하는 패턴입니다.
이 패턴은 실시간 데이터 전송이 필요한 시나리오에 적합하며, 웹소켓 (WebSockets), gRPC 스트리밍, Kafka 등의 시스템에서 많이 사용됩니다.
+---------+ +---------+ | | --- Request Stream ---> | | | Client | ---------------------------->| Server | | | | | +---------+ +---------+ | v +----------------------+ | Process Stream Data | +----------------------+ | +---------+ +---------+ | | <--- Stream Data 1 --- | | | Client | <----------------------------| Server | | | | | +---------+ +---------+ | +---------+ +---------+ | | <--- Stream Data 2 --- | | | Client | <----------------------------| Server | | | | | +---------+ +---------+ | ... ... | +---------+ +---------+ | | <--- Stream Data N --- | | | Client | <----------------------------| Server | | | | | +---------+ +---------+
Request/Response Pattern
개념
요청/응답 패턴은 가장 기본적이고 널리 사용 되는 통신 방식 중 하나로, 클라이언트와 서버 간의 양방향 통신을 의미합니다.
클라이언트가 서버에게 특정 작업이나 정보를 요청하면, 서버는 그에 대한 결과나 데이터를 응답으로 반환합니다.
이 과정은 보통 동기적으로 이루어지며, 클라이언트는 서버의 응답을 받을 때까지 기다립니다.
특징
동기적 통신: 클라이언트는 요청을 보내고 응답을 받을 때까지 다른 작업을 수행하지 않고 대기합니다.
상태 비유지성: 각 요청은 독립적으로 처리되며, 서버는 이전 요청의 상태를 유지하지 않을 수 있습니다(예: RESTful API).
오류 처리 용이: 서버는 요청 처리 중 발생한 오류를 응답 메시지에 포함하여 클라이언트에게 전달할 수 있습니다.
프로토콜 사용: HTTP, HTTPS 등 명확한 규격을 가진 프로토콜을 통해 통신합니다.
사용 사례
웹 브라우징: 사용자가 웹 페이지를 요청하면 서버는 해당 페이지의 HTML, CSS, JavaScript 등을 응답으로 제공합니다.
API 호출: 애플리케이션이 외부 서비스의 기능을 사용하기 위해 RESTful API를 호출하고 결과를 받습니다.
Database Query: 애플리케이션이 Database 에 Query 를 요청하고 Result Set 을 반환받습니다.
Publish/Subscribe Pattern
개념
발행/구독 패턴은 메시지 기반의 비동기 통신 방식으로, 메시지를 생성하는 발행자(Publisher)와 메시지를 수신하는 구독자(Subscriber)로 구성
발행자는 특정 주제 (Topic) 에 메시지를 발행하고, 해당 주제를 구독한 구독자 들은 Message Broker 를 통해 메시지를 수신합니다. (i.e. Apache Kafka)
특징
느슨한 결합: Publisher 와 Subscriber 는 서로를 알 필요가 없으며, Message Broker 를 통해 간접적으로 연결됩니다.
비동기적 통신: Publisher 는 메시지를 보낸 후 Subscriber 의 상태에 관계없이 계속 작업을 수행합니다.
확장성: Subscriber 의 수에 관계없이 Publisher 는 동일한 방식으로 메시지를 발행하며, Subscriber 는 필요한 Topic 만 선택적으로 수신합니다.
유연성: 새로운 Subscriber 를 추가하거나 제거해도 시스템 전체에 영향을 주지 않습니다.
사용 사례
이벤트 스트리밍: 실시간으로 발생하는 이벤트를 여러 서비스에 전달하여 처리합니다 (예: 금융 거래 Data).
알림 시스템: 특정 이벤트나 상태 변화에 대한 알림을 여러 사용자에게 전송합니다.
로그 수집: 애플리케이션의 로그를 중앙 로그 관리 시스템으로 전달하여 분석합니다.
One-way Pattern
개념
단방향 통신은 송신자에서 수신자로 한 방향으로만 데이터가 전달되는 통신 방식입니다.
송신자는 메시지를 보내고, 수신자로부터의 응답이나 확인을 받지 않습니다.
이는 통신 과정을 단순화하고, 응답 대기 시간 없이 데이터를 전달할 수 있게 합니다.
특징
비동기적 데이터 전송: 송신자는 메시지 전송 후 즉시 다음 작업을 수행합니다.
응답 없음: 수신자로부터의 응답이나 확인이 없으므로, 메시지 전달 성공 여부를 송신자가 알 수 없습니다.
낮은 Overhead: 응답을 처리할 필요가 없어 통신 Overhead 가 줄어듭니다.
사용 사례
Log 전송: 애플리케이션이 발생한 Log 를 중앙 서버로 전송하지만, Log 수집 여부를 확인하지 않습니다.
모니터링 데이터 전송: 센서가 주기적으로 데이터를 전송하지만, 수신 확인을 기다리지 않습니다.
광고 Push: 광고 서버가 다수의 클라이언트에 광고 메시지를 전송합니다.
Request/Acknowledge Pattern
개념
요청/확인 패턴은 클라이언트가 서버에게 요청을 보내면, 서버는 그 요청을 받았다는 사실을 확인 (Acknowledge) 하는 메시지를 반환합니다.
이후 실제 요청에 대한 처리는 서버에서 비동기적으로 진행되며, 클라이언트는 추가적인 응답을 기다리지 않습니다.
특징
비동기적 처리: 서버는 요청을 받은 후 즉시 ACK 를 반환하고, 실제 처리는 별도로 수행합니다.
작업 Queue 활용: 서버는 받은 요청을 작업 큐에 저장하고 순차적으로 처리할 수 있습니다.
확인 메시지 제공: 클라이언트는 요청이 정상적으로 수신 되었는지 확인할 수 있습니다.
사용 사례
비동기 작업 처리: 이메일 전송, 이미지 렌더링 등 시간이 오래 걸리는 작업에 대해 즉각적인 ACK 를 반환하고, 백그라운드에서 처리합니다.
메시지 큐 시스템: RabbitMQ, Apache Kafka 등에서 메시지를 큐에 넣은 후 ACK 를 반환합니다.
주문 처리 시스템: 고객의 주문을 받고 ACK 를 반환한 후, 실제 주문 처리는 나중에 진행됩니다.
Stream Pattern
개념
Stream 은 Data 가 연속적이고 실시간으로 흐르는 통신 방식으로, 한 시스템에서 다른 시스템으로 데이터가 지속적으로 전달됩니다.
Streaming Data 는 발생하는 즉시 처리 되며, 대용량의 Real Time Data 처리가 필요한 분야에서 사용됩니다.
특징
실시간 처리: 데이터가 생성됨과 동시에 전달되고 처리됩니다.
고속 데이터 전송: 지연 시간을 최소화하여 빠르게 데이터를 전달합니다.
연속성: 데이터 흐름이 지속적으로 유지되며, 시작과 끝이 명확하지 않을 수 있습니다.
Processing Frameworks: Apache Spark Streaming, Apache Flink 등
사용 사례
멀티미디어 스트리밍: 비디오나 오디오 콘텐츠를 실시간으로 사용자에게 전달합니다 (예: 라이브 방송).
실시간 분석: 금융 시장 데이터, Social Media Feed 등을 실시간으로 분석하여 Insight 를 도출합니다.
사물인터넷 (IoT): 센서 네트워크에서 수집된 데이터를 실시간으로 모니터링하고 제어합니다.
Log 처리: 서버나 애플리케이션의 로그를 실시간으로 수집하고 분석하여 이상 징후를 탐지합니다.
Fault Tolerance for Robust Data Pipeline
Fault Tolerance 를 달성하기 위한 방법 2가지
Check pointing
Logging
Check Pointing
Global Snapshot
- 수집단계의 상태 뿐만 아니라 시스템 전역상태에 대한 Snapshot 을 정기적으로 특정 저장소에 저장해야 한다.
데이터 유실 가능성
가장 최근에 기록된 전역 상태까지 복구할 수 있어야 한다.
이후에 처리되고 생성된 모든 메시지는 유실된다.
HDFS, NoSQL 을 사용할 경우, Check Pointing 이 유용하다.
Streaming System 에는 적합하지 않다.
- 단계별로 데이터가 이동할때마다 모든 시점에 대해서 Snapshot 데이터를 일관성있게 유지하는 것이 매우 어렵기 때문
Logging
Streaming System 에서 사용할 수 있는 복구 방법
장애가 발생하기 전까지 수신된 마지막 메시지까지 복구하는 기능을 제공
메시지를 재처리 할 수 있다면, 시스템은 전역 Snapshot 이 없어도 시스템은 전구간에서 일관된 상태에 도달할 수 있음을 목표로 한다.
Logging 의 종류는 3가지가 있다.
RBML (Receiver Based Message Logging)
- 구현이 단순하고 수신자가 독립적으로 복구할 수 있지만, 복구 시간이 길어질 수 있습니다.
SBML (Sender Based Message Logging)
- 수신자의 Overhead 를 줄이고 빠른 복구를 지원하지만, 송신자에 대한 의존성이 증가합니다.
HML (Hybrid Message Logging)
- 두 방식의 장점을 결합하여 성능과 복구 시간을 최적화하지만, 구현과 관리의 복잡성이 높습니다.
수신자 기반 메시지 Logging (RBML)
개념
수신자 기반 메시지 Logging 은 메시지의 수신자가 자신에게 도착한 메시지를 안정된 저장소에 Logging 하는 방식입니다.
이 방식에서는 각 프로세스가 수신한 모든 메시지를 로컬 또는 분산된 안정 저장소에 기록하여, 장애 발생 시 해당 메시지들을 재 적용함으로써 이전 상태를 복원합니다.
+---------+ +---------+ +---------+
| Sender | | Receiver| | Log |
+---------+ +---------+ +---------+
| | |
| --- Send Message (M) ---> | |
| | |
| | --- Log (M) -------> |
| | |
| | <--- Ack (M) --------|
| <--- Acknowledge (Ack) ---| |
| | |
+---------+ +---------+ +---------+
작동 방식
메시지 수신 시 로깅
프로세스가 메시지를 수신하면, 그 메시지를 안정 저장소에 기록합니다.
Logging 된 메시지는 메시지의 내용과 송신자 정보, 메시지의 순서 등을 포함합니다.
Checkpoint 와 결합
각 프로세스는 주기적으로 자신의 상태를 Checkpoint 로 저장합니다.
Checkpoint 는 프로세스의 메모리 상태, 변수 값 등을 포함합니다.
복구 절차
프로세스가 장애로 인해 재 시작되면, 마지막으로 저장된 Checkpoint 를 Load 합니다.
Checkpoint 이후에 수신한 메시지들을 Logging 된 메시지에서 순서대로 재 적용합니다.
이를 통해 장애 이전의 상태를 복원합니다.
장점
간단한 구현
- 메시지 Logging 이 수신자 측에서만 이루어지므로 구현이 비교적 단순합니다.
Logging Overhead 감소
- 송신자는 메시지 Logging 에 관여하지 않으므로 송신자 측의 Overhead 가 없습니다.
독립적인 복구
- 수신자는 자신이 Logging 한 메시지만으로 복구 가능하므로 다른 프로세스에 의존하지 않습니다.
단점
복구 시간 증가
- Checkpoint 이후 수신한 모든 메시지를 재 적용해야 하므로 복구 시간이 길어질 수 있습니다.
Cascade 복구 위험
- 장애 프로세스가 다른 프로세스에 영향을 줄 수 있어 복구 범위가 확대될 위험이 있습니다.
스토리지 요구량 증가
- 수신한 모든 메시지를 Logging 해야 하므로 저장 공간이 많이 필요할 수 있습니다.
사용 사례
작은 규모의 시스템
- 메시지 교환이 빈번하지 않은 시스템에서 효과적 입니다.
로컬 복구가 필요한 경우
- 프로세스 간 의존성이 낮아 독립적인 복구가 가능한 환경에 적합합니다.
송신자 기반 메시지 Logging (SBML)
개념
송신자 기반 메시지 Logging 은 메시지의 송신자가 자신이 전송한 메시지를 안정된 저장소에 Logging 하는 방식입니다.
이 방식에서는 수신자가 장애로 인해 복구가 필요할 때, 송신자가 Logging 된 메시지를 재전송하여 수신자의 상태 복원을 도와줍니다.
+---------+ +----------+ +---------+
| Sender | | Receiver | | Log |
+---------+ +----------+ +---------+
| | |
| --- Send Message (M) ---> | |
| | |
| --- Log (M) ------------> | |
| | |
| <--- Acknowledge (Ack) ---| |
| | |
+---------+ +---------+ +---------+
작동 방식
메시지 전송 시 Logging
프로세스가 메시지를 전송할 때, 그 메시지를 안정 저장소에 기록합니다.
Logging 된 정보에는 메시지 내용, 수신자 정보, 메시지 순서 등이 포함됩니다.
Checkpoint 와 결합
송신자는 주기적으로 자신의 상태를 Checkpoint 로 저장합니다.
Checkpoint 는 메시지 전송 이력과 관련된 정보를 포함할 수 있습니다.
복구 절차
수신자가 장애로 인해 재 시작되면, 송신자는 자신이 Logging 한 메시지를 수신자에게 재 전송합니다.
수신자는 재 수신한 메시지를 적용하여 이전 상태를 복원합니다.
장점
빠른 복구
- 수신자는 송신자로부터 필요한 메시지를 바로 받아 복구 시간을 단축할 수 있습니다.
수신자 오버헤드 감소
- 수신자는 메시지를 Logging 할 필요가 없어 성능 Overhead 가 줄어듭니다.
스토리지 효율성
- 송신자가 전송한 메시지만 Logging 하므로 중복 저장이 감소합니다.
단점
송신자 부담 증가
- 송신자가 모든 전송 메시지를 Logging 해야 하므로 Overhead 가 증가합니다.
의존성 증가
- 수신자의 복구가 송신자에 의존 하므로, 송신자도 장애를 겪으면 복구가 어려워집니다.
복잡한 구현
- 메시지 전달 보장과 순서 유지 등을 관리해야 하므로 구현이 복잡해질 수 있습니다.
사용 사례
신뢰성 높은 네트워크
- 송신자의 장애 확률이 낮은 환경에서 효과적 입니다.
수신자 성능이 중요한 경우
- 수신자의 Logging Overhead 를 줄여야 하는 시스템에 적합합니다.
하이브리드 메시지 Logging (HML)
개념 설명
하이브리드 메시지 Logging 은 수신자 기반과 송신자 기반 메시지 Logging 의 장점을 결합한 방식입니다.
이 접근법은 메시지의 특성이나 시스템 상태에 따라 Logging 주체를 동적으로 결정하여, 성능과 복구 시간을 최적화 합니다.
+---------+ +----------+ +---------+
| Sender | | Receiver | | Log |
+---------+ +----------+ +---------+
| | |
| --- Send Message (M) ---> | |
| | |
| --- Log (M) ------------> | |
| | --- Log (M) --------> |
| | |
| <--- Acknowledge (Ack) ---| |
| | |
+---------+ +---------+ +---------+
작동 방식
메시지 특성에 따른 Logging
중요한 메시지는 송신자가 Logging 하고, 덜 중요한 메시지는 수신자가 Logging 합니다.
메시지의 크기, 빈도, 중요도 등에 따라 Logging 방식을 선택합니다.
동적 Logging 전략
- 시스템의 부하, 네트워크 상태, 프로세스의 신뢰성 등에 따라 Logging 주체를 변경할 수 있습니다.
Checkpoint 와 결합
Process 들은 주기적으로 자신의 상태를 Checkpoint 로 저장합니다.
Checkpoint 와 메시지 Logging 정보를 조합하여 복구 시 사용합니다.
복구 절차
장애 프로세스는 Checkpoint 를 Load 한 후, 필요한 메시지를 송신자나 자신이 Logging 한 메시지로부터 재 적용합니다.
이때, 메시지의 Logging 위치를 추적하여 필요한 메시지를 확보합니다.
장점
Logging 오버헤드 분산
- 송신자와 수신자 간에 Logging 부담을 분산하여 시스템 성능을 향상 시킵니다.
유연한 복구
- 상황에 맞게 복구 전략을 조정할 수 있어 복구 시간을 최적화할 수 있습니다.
확장성
- 대규모 시스템에서 다양한 시나리오에 대응할 수 있습니다.
단점
복잡한 관리
- Message 마다 Logging 주체가 달라질 수 있으므로 추적과 관리가 어려워질 수 있습니다.
구현 난이도 증가
- Logging 전략의 동적 변경과 메시지 추적을 위해 복잡한 메커니즘이 필요합니다.
의존성 증가 가능성
- Logging 주체가 다양하므로 복구 시 여러 프로세스에 의존할 수 있습니다.
사용 사례
대규모 분산 시스템
- 다양한 메시지 패턴과 프로세스 특성을 가진 시스템에서 효과적 입니다.
동적인 환경
- 시스템 상태가 자주 변하고 유연한 Logging 전략이 필요한 경우에 적합합니다.
Fault Tolerance 에서 추가 고려사항
체크포인트 전략
Global Checkpoint
모든 프로세스가 동시에 Checkpoint 를 생성하여 시스템의 일관성을 보장합니다.
그러나 동기화 Overhead 가 크므로 성능 저하를 일으킬 수 있습니다.
Local Checkpoint
Process 들이 독립적으로 Checkpoint 를 생성합니다.
메시지 Logging 과 결합하여 일관성 있는 복구를 지원합니다.
Cascading Rollback
문제점
하나의 프로세스 장애로 인해 다른 프로세스들도 복구해야 하는 상황이 발생할 수 있습니다.
이는 전체 시스템의 복구 시간을 증가시키고 성능을 저하 시킵니다.
해결 방법
Orpheus Protocol 등과 같은 Deterministic Replay 기법을 사용하여 캐스케이드 복구를 방지합니다.
Recovery Predecessor Set 을 관리하여 필요한 최소한의 프로세스만 복구합니다.
성능과 신뢰성 균형
Logging Overhead vs 복구 시간
Logging Overhead 를 최소화하면 복구 시간이 증가할 수 있고, 반대로 복구 시간을 단축하면 Logging Overhead 가 증가할 수 있습니다.
시스템의 요구사항에 맞게 균형을 맞추는 것이 중요합니다.
안정 저장소의 신뢰성
Logging 된 메시지와 Checkpoint 가 손실되지 않도록 안정된 저장소를 사용해야 합니다.
분산된 저장소나 복제 메커니즘을 통해 신뢰성을 높일 수 있습니다.
구현 고려사항
메시지 순서 유지
- 메시지의 순서가 중요한 시스템에서는 Logging 과 복구 시 순서를 정확히 유지해야 합니다.
동기화 메커니즘
- Logging 과 Checkpoint 생성 시 프로세스 간의 동기화를 어떻게 관리할지 결정해야 합니다.
Overhead 측정 및 최적화
- 실제 환경에서 Logging 과 복구가 시스템에 미치는 영향을 측정하여 최적화 해야 합니다.
Subscribe to my newsletter
Read articles from Gyuhang Shim directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by
Gyuhang Shim
Gyuhang Shim
Gyuhang Shim Passionate about building robust data platforms, I specialize in large-scale data processing technologies such as Hadoop, Spark, Trino, and Kafka. With a deep interest in the JVM ecosystem, I also have a strong affinity for programming in Scala and Rust. Constantly exploring the intersections of high-performance computing and big data, I aim to innovate and push the boundaries of what's possible in the data engineering world.