generated from Learning-Is-Vital-In-Development/study-template
-
Notifications
You must be signed in to change notification settings - Fork 1
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #7 from tlarbals824/main
docs: 9장 데이터 파이프라인 구축하기
- Loading branch information
Showing
1 changed file
with
127 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,127 @@ | ||
# 9장 데이터 파이프라인 구축하기 | ||
|
||
* 데이터 파이프라인에 있어 카프카가 갖는 주요한 역할은 데이터 파이프라인의 다양한 단계 사이사이에 버퍼 역할을 해준다는 점입니다. | ||
|
||
## 9.1 데이터 파이프라인 구축 시 고려사항 | ||
|
||
### 9.1.1 적시성 | ||
|
||
* 대부분의 파이프라인은 실시간성을 요구하거나 요구하지 않는 두 가지 경우가 있다. | ||
* 카프카를 쓰는 쪽과 읽는 쪽 사이의 시간적 민감도에 대한 요구 조건을 분리시키는 거대한 버퍼로 생각하면 좋다. | ||
|
||
### 9.1.2 신뢰성 | ||
|
||
* 서비스 유형에 따라 데이터가 유실되면 안되는 경우가 있다. 이때 카프카의 최소 한 번 전송을 통해 데이터 손실을 방지할 수 있다. | ||
|
||
### 9.1.3 높으면서도 조정 가능한 처리율 | ||
|
||
* 매우 높은 처리율을 가질 수 있는 확정상 있는 시스템에서 카프카는 버퍼 역할로서 쓰는 속도와 읽는 속도를 조정할 수 있다. | ||
|
||
### 9.1.4 데이터 형식 | ||
|
||
* 데이터 파이프라인에서 가장 중요하게 고려해야 할 것 중 하나는 서로 다른 데이터 형식과 자료형을 적절히 사용하는 것이다. | ||
* 카프카와 커넥트 API는 데이터 형식에 완전히 독립적이다. 따라서 데이터 형식을 변경하더라도 카프카에 영향을 주지 않는다. | ||
|
||
### 9.1.5 변환 | ||
|
||
* 데이터 파이프라인을 구축하는 방법에는 ETL와 ELT 두 방식이 있습니다. | ||
* ETL은 "추출-변환-적재(Extract-Transform-Load)"의 약자로, 데이터를 추출하고 변환한 후 다른 시스템에 적재하는 방식입니다.(smart pipeline) | ||
* ELT는 "추출-적재-변환(Extract-Load-Transform)"의 약자로, 데이터를 추출하고 다른 시스템에 적재한 후 변환하는 방식입니다.(dude pipeline) | ||
* 카프카 커넥트는 원본 시스템의 데이터를 카프카로 옮길 때 혹은 카프카의 데이터를 대상 시스템으로 옮길 때 단위 레코드를 변환할 수 있게 해주는 단일 메시지 변환 기능을 제공합니다. | ||
* 데이터를 추출할 때 성급하게 최적화하려하지 말아야합니다. 어떤 경우에는 원본 데이터가 필요할 수 있기 때문입니다. | ||
|
||
### 9.1.6 보안 | ||
|
||
* 데이터 파이프라인의 관점에서 보안에 대해 주로 고려해야 할 점은 다음과 같습니다. | ||
* 누가 카프카로 수집되는 데이터에 접근할 수 있는가? | ||
* 파이프라인을 통과하는 데이터가 함호화되었다고 확신할 수 있는가? 이것은 여러 데이터센터에 걸쳐 구축된 데이터 파이프라인의 경우 특히 중요하다. | ||
* 누가 파이프라인을 변경할 수 있는가? | ||
* 만약 파이프라인이 접근이 제한된 곳의 데이터를 읽거나 써야할 경우, 문제 없이 인증을 통과할 수 있는가? | ||
* 개인 식별 정보를 저장하고, 접근하고, 사용할 때 법과 규제를 준수하는가? | ||
* 카프카는 데이터 전송 과정의 암호화를 지원합니다. 또한 SASL을 사용한 인증과 인가 역시 지원합니다. | ||
|
||
### 9.1.7 장애 처리 | ||
|
||
* 데이터 파이프라인에는 장애가 발생할 수 있기 때문에 모든 단계에서 장애 처리를 고려해야 합니다. | ||
|
||
### 9.1.8 결합과 민첩성 | ||
|
||
* 데이터 파이프라인을 구현할 때 데이터 원본과 대상을 분리할 수 있어야 합니다. | ||
* 임기 응변 파이프라인 | ||
* 데이터 파이프라인이 특정 엔드포인트에 강항게 결합되어 있는 경우, 새로운 기술을 도입하는 데 많은 비용이 발생한다. | ||
* 메타데이터 유실 | ||
* 데이터 파이프라인에서 스키마 진화를 지원함으로써 각 팀은 시스템 중단을 걱정할 필요 없이 자신들의 애플리케이션을 변경할 수 있다. | ||
* 과도한 처리 | ||
* 데이터를 가공하지 않고 그대로 전달하는 것이 더 좋을 수도 있다. | ||
|
||
## 9.2 카프카 커넥트 vs. 프로듀서/컨슈머 | ||
|
||
* 카프카 커넥트는 카프카를 직접 코드나 API를 작성하지 않고, 변경도 할 수 없는 데이터 저장소에 연결시켜야할 때 쓴다. | ||
* 카프카 커넥트는 여러 저장소에 맞게 구현되어 있어, 설정 파일만 작성하기만하면 사용할 수 있다. | ||
|
||
## 9.3 카프카 커넥트 | ||
|
||
* 카프카 커넥트는 아파치 카프카의 일부로서, 카프카와 다른 데이터 저장소 사이에 확장성과 신뢰성을 가지면서 데이터를 주고받을 수 있는 수단을 제공합니다. | ||
* 카프카 커넥트는 여러 워커 프로세스들의 클러스터 형태로 실행된다. | ||
* 커넥터는 대용량의 데이터 이동을 병렬화해서 처리하고 워커의 유휴 자원을 더 효율적으로 활용하기 위해 태스크를 추가로 실행시킨다. | ||
* 소스 커넥터 테스크는 데이터를 읽어서 워커 프로세스에 전달한다. | ||
* 싱크 커넥트 테스크는 워커로부터 데이터를 받아서 대상 시스템에 쓴다. | ||
|
||
### 9.3.1 카프카 커넥트 실행하기 | ||
|
||
* 카프카 커넥트는 카프카 브로커와 별도의 서버에서 실행시켜야 한다. | ||
* 커넥트 워커의 핵심 설정은 다음과 같다. | ||
* bootstrap.servers: 커넥트 커넥트와 함께 작동하는 카프카 브로커 목록 | ||
* group.id: 커넥트 클러스터 내에서 고유한 그룹 ID | ||
* plugin.path: 커넥트 플러그인이 설치된 디렉터리 | ||
* key.converter, value.converter: 카프카 메시지의 키와 값을 변환하는 클래스 | ||
* rest.host.name, rest.port: 카프카 커넥트의 REST API를 사용할 때 사용하는 호스트 이름과 포트 | ||
|
||
### 9.3.4 개별 메시지 변환 | ||
|
||
* 카프카 생태계에서는 상태 없는 변환을 상태가 있을 수 있는 스트림 처리와 구분하여 개별 메시지 변환이라고 부른다. | ||
* SMT는 카프카 커넥트가 메시지를 복사하는 도중에 데이터 변환 작업의 일부로서, 보통 코드를 작성할 필요 없이 수행된다. | ||
* 카프카는 다음과 같은 SMT들을 포함한다. | ||
* Cast: 필드의 데이터 타입을 변경 | ||
* MaskField: 필드의 값을 null로 채운다. | ||
* Filter: 특정 조건에 부합하는 모든 메시지를 제외하거나 포함한다. | ||
* Flatten: 중첩된 자료구조를 핀다. | ||
* HeaderForm: 메시지의 필드를 헤더로 이동하거나 복사한다. | ||
* InsertHeader: 헤더에 정적인 문자열을 추가한다. | ||
* InsertField: 메시지에 새로운 필드를 추가해 넣는다. | ||
* RegexRouter: 정규식과 교체할 문자열을 사용해 목적지 토픽의 이름을 바꾼다. | ||
* ReplaceField: 필드의 값을 다른 값으로 교체한다. | ||
* TimestampConverter: 타임스탬프 필드의 형식을 변경한다. | ||
* TimestampRouter: 타임스탬프 필드의 값을 기반으로 목적지 토픽을 선택한다. | ||
|
||
### 9.3.5 카프카 커넥트: 좀 더 자세히 알아보기 | ||
|
||
#### 1. 커넥터와 태스크 | ||
|
||
* 커넥터 플러그인은 커넥터 API를 구현한다. | ||
* 커넥터는 다음의 세 가지 작업을 수행한다. | ||
* 커넥터에서 몇 개의 태스크가 실행되어야 하는지 결정한다. | ||
* 데이터 복사 작업을 각 태스트에 어떻게 분할해 줄지 결정한다. | ||
* 워커로부터 태스트 설정을 얻어와 태스크에 전달한다. | ||
* 태스크는 데이터를 실제로 카프카에 넣거나 가져오는 작업을 담당한다. | ||
* 모든 태스크는 워커로부터 컨텍스트를 받아 초기화된다. | ||
* 소스 컨텍스트는 소스 태스크가 소스 레코드의 오프셋을 저장할 수 있게 해주는 객체를 포함한다. | ||
* 태스크가 시작되면 소스 태스크는 외부 시스템을 폴링해서 워커가 카프카 브로커로 보낼 레코드 리스트를 리턴한다. | ||
|
||
#### 2. 워커 | ||
|
||
* 카프카 커넥트의 워커 프로세스는 커넥터와 태스크를 실행시키는 역할을 맡는 '컨테이너' 프로세스라고 할 수 있다. | ||
* 워커 프로세스가 다운되면 클러스터 내의 다른 워커 프로세스가 해당 워커 프로세스의 태스크를 다시 실행시킨다. | ||
* 클러스터에 새로운 워커가 추가되면 워커들의 부하가 균형이 잡히도록 재조정을 거친다. | ||
|
||
#### 3. 컨버터 및 커넥트 데이터 모델 | ||
|
||
* 컨버터는 커넥트 워카가 카프카 메시지를 변환할 때 사용하는 클래스이다. | ||
* 싱크 커넥터는 반대로 동작한다. 워커가 카프카로부터 레코드를 읽어 온 뒤, 설정된 컨버터를 사용해 읽어 온 레코드를 카프카에 저장된 형식 커넥트 데이터 API 레코드로 변환한다. | ||
|
||
#### 4. 오프셋 관리 | ||
|
||
* 커넥터는 어떤 데이터를 이미 처리했는지 알아야 하며 커넥터는 카프카가 제공하는 API를 사용해서 어느 이벤트가 이미 처리됐는지에 대한 정보를 유지 관리할 수 있다. | ||
* 소스 커넥터의 경우, 커넥터가 커넥트 워커에 리턴하는 레코드에는 논리적인 파티션과 오프셋이 포함된다. | ||
* 워커는 소스 커넥터로부터 받은 레코드를 카프카 브로커로 전송하며, 해당 레코드가 정상적으로 저장되면 오프셋을 갱신한다. | ||
* 싱크 커넥터는 레코드를 읽어온 뒤 대상 시스템에 저장하면 오프셋을 갱신한다. |