4장. 이진 부호화와 발전

#️⃣1. 이진 부호화

✅1.1. 이진 부호화

데이터를 파일에 쓰거나 네트워크를 통해 전송 혹은 메모리를 공유하지 않는 다른 프로세스로 일부 데이터를 전송하려면 바이트열 형태로 부호화해야 한다.

• 부호화 == 직렬화 == 마샬링
• 복호화 == 파싱 == 역직렬화 == 언마샬링

 

✅1.2. 이진 부호화 라이브러리 비교

'스피프트'와 '프로토콜 버퍼'이진 부호화 라이브러리를 사용하려면 부호화할 데이터를 위한 스키마가 필요하다.

각각 스키마 정의를 상용해 코드를 생성하는 도구가 있다. 

1.2.1 스리프트 (Thrift)

# 스리프트 스키마
struct Person{
	1: required string userName,
	2: optional i64 favoriteNumber,
	3: optional list<string> interests
}

좌. 바이너리프로토콜 / 우:컴팩트프로토콜

 

• 구성요소 : 필드 태그와 type, 길이, 데이터
  • 필드 태그 : 필드 이름 대신 필드 태그를 이용하여 필드를 구분한다.

스리프트는 '바이너리프로토콜'과 '컴팩트프로토콜' 종류가 2가지 있다.

둘의 차이점은 컴팩트프로토콜의 바이너리프로토콜과 다르게 필드 타입과 태그 숫자를 단일 바이트로 줄이고, 가변 길이 정수를 사용해서 부호화한다. => 2바이트로 부호화 가능

1.2.2. 프로토콜 버퍼 (Protocol Buffer) 

# 프로토콜 버퍼 스키마
message Person{
	required sting user_name = 1;
	optional int64 favorite_number = 2;
	repeated string interests = 3;
}

• 스리프트의 컴팩트 프로토콜과 매우 비슷함
• 구성요소 : 필드 태그와 type, 길이, 데이터

1.2.3. 아브로 (Avro)

아브로도 부호화할 데이터 구조를 지정하기 위해 스키마를 사용하며, 2개의 스키마 언어가 있다.

하나는 사람이 편집할 수 있는 아브로 IDL, 다른 하나는 기계가 더 쉽게 읽을 수 있는 JSON 기반 언어이다.

# 1. 아브로 IDL 작성한 스키마
record Person{
	string userName;
	union {null, long} favoriteNumber = null;
	array <string> interests;
}

# 2.JSON으로 작성한 스키마
{
	"type": "record",
	"name" : "Person",
	"fields": [
		{"name" : "userNAme", "type" : "string",
		{"name" : "favoriteNumber", "type" : {"null", "long"}, "default" : null},
		{"name" : "interests", "type" : {"type" : "array", "items" : "string"}} 
		]
}

• 구성요소 : 길이, 데이터
  • 특이점: 스키마에 태그 번호가 없고, 필드나 데이터 타입을 식별하기 위한 정보가 없다
    => 모든 부호화 중 길이가 가장 짧다

복호화 시, Avro는 태그 번호가 없기 때문에, 스키마를 이용해 각 필드의 데이터 타입을 미리 파악해야한다.

또한, Avro는 위의 두개의 라이브러리와 다르게 복호화시 읽기 스키마와쓰기 스키마가 필요하다.

• 읽기 스키마와 쓰기 스키마가 완전히 동일하지 않아도 되며 필드 순서가 달라도 괜찮다. 단지 호환 가능하면 된다.
• 데이터를 읽는 코드가 기대하는 특정 필드가 쓰기 스키마에는 없는 경우, 읽기 스키마에 선언된 기본값을 이용한다.
• 반대로, 데이터를 읽는 코드가 읽기 스키마에는 없고, 쓰기 스키마에 존재하는 필드를 만나면 해당 필드는 무시한다.

또한, Avro 특성상 복호화시 쓰기 스키마가 필요한데, 모든 레코드에 전체 스키마를 포함시킨 어렵다. 

왜냐하면 스키마는 부호화된 데이터보다 훨씬 클 가능성이 있기 때문이다.

Avro를 사용하는 상황은 다음과 같다.

1. 많은 레코드가 있는 대용량 파일 
   : 모두 동일한 스키마로 부호화된 수백만 개 레코드를 포함한 파일을 저장할 때 좋다. 그러면 파일 쓰기 때 파일 시작 부분에 한 번만 쓰기 스키마를 포함시키면 되기 때문이다.
2. 개별적으로 기록된 레코드를 가진 데이터베이스
   : 데이터베이스의 다양한 레코드들은 다양한 쓰기 스키마를 사용해 서로 다른 시점에 쓰여질 수 있다. 
   이를 부호화된 모든 레코드의 시작부분에 버전 번호를 포함하고 데이터베이스에는 스키마 버전 목록을 유지하면 된다.
3. 네트워크 연결을 통해 레코드 보내기
   : 두 프로세스가 양방향 네트워크 연결을 통해 통신할 때 연결 설정에서 스키마 버전 합의를 할 수 있다.

1.2.4. 부호화 라이브러리 비교 

	스리프트 (Thrift)	프로토콜 버퍼 (Protocol Buffer)	아브로 (Avro)
스키마 구성	태그 번호, optional/required, 타입,  필드 이름	Optional/required/repeated, 타입, 필드 이름, 태그 번호	필드 이름, 타입, Default
목록 타입 지원 여부	O 전용 목록 타입 있으며, 중첩 목록 지원함	△ Repeated 필드로 처리	-
필드 번호 여부	O	O	X
복호화 방법	별도 필요 없음	동일	읽기 스키마와 쓰기 스키마 모두 필요함
필드 태그 변경 여부	X	X	-
하위 호환성	태그 번호 있으면 가능, 새로운 필드 추가시 optional 또는 기본값 필요	태그 번호 있으면 가능, 새로운 필드 추가시 optional 또는 기본값 필요	기본값이 있는 필드만 추가/삭제 가능함
필드 데이터 타입 변경	가능하지만 잘릴 위험 있음	가능하지만 잘릴 위험 있음	가능. 단, null을 허용하는 유니온 타입을 사용해야 함
필드 이름 변경 여부	O	O	까다로움. 읽기 스키마는 필드 이름의 별칭 포함 가능 (하위 호환성은 있지만 상위 호환성은 없음)
필드 삭제	Optional만 삭제 가능	동일	기본값 있는 필드만 가능
필드 추가	가능	가능	기본값 있는 필드만 가능
동적 생성 스키마 고려	X 데이터베이스 스키마 변경될 때 마다 관리자는 수동으로 갱신해야됨	X 데이터베이스 스키마 변경될 때 마다 관리자는 수동으로 갱신해야됨	O 완전 편리함. 데이터베이스 스키마로 부터 아브로 스키마 쉽게 생성 가능. 아브로는 동적 생성 스키마를 고려해 설계함

참고.

- 하위 호환성 : 새로운 코드는 예전 코드가 기록한 데이터를 읽을 수 있어야 한다.

- 상위 호환성 : 예전 코드는 새로운 코드가 기록한 데이터를 읽을 수 있어야 한다.

✅1.3. 스키마의 장점

• 부호화된 데이터에서 필드 이름생략 가능 → 크기 훨씬 작음
• 복호화시 스키마가 최신 상태인지 확인 가능함
• 스키마 데이터베이스 유지하면 상위호환성,하위호환성 확인 가능
• 정적 타입 프로그래밍 언어 사용자에게 스키마로 코드 생성하는 기능은 컴파일 시점에 타입 체크를 할 수 있게하여 유용하다.

---

#️⃣2. 데이터 플로 모드

데이터 플로 : 프로세스간 데이터를 전달하는 것

방법

1. 데이터베이스를 통해
   1. 상위 호환성/ 하위 호환성 필요성
   2. 다양한 시점에 기록된 다양한 값 (data outlives code, 마이그레이션)
   3. 보관 저장소 - 스냅숏, 데이터 덤프는 아브로가 적합
2. 서비스 호출을 통해
3. 비동기 메시지 전달을 통해

 

출처

[책] 데이터 중심 애플리케이션 설계 - 4장