데이터 중심 어플리케이션 - 4장

부호화와 발전

→ 직역으로 번역때문에 책 내용이 이해가 어렵네요. 원문은 Encoding and Evolution 입니다.

부호화보다는 인코딩이 더 나아보이네요. 발전도 내용이 Schema Evolution을 의미함으로

스키마 진화에 대한 대응이라 인코딩과 스키마 진화 로 번역을 했으면 좋았을것 같습니다.

 

만물은 변한다. 그대로 있는 것은 아무것도 없다

- 에베소의 헤라클레이토스, 플라톤이 크라틸로스에서 인용

 

위 문구가 마음에 듭니다. 어플리케이션은 언제든지 변경될 수 있다는 생각을 모두 가지고 설계를

진행해야 된다는게 중요합니다. 요구사항도 항상 변경될 수 있으니 어플리케이션도 변경이 되겠지요.

 

어플리케이션 작성시 하위 호환성 및 상위 호환성을 유지의 중요성에 대해 언급하고 있습니다.

 

• 하위호환성: 새로운 코드는 예전코드가 기록한 데이터를 읽을수 있음
• 상위호환성: 예전코드는 새로운 코드가 기록한 새로운 데이터를 읽을 수 있음

인코딩 데이터 형태(Formats for Encoding Data)

 

인코딩과 디코딩

메모리에 객체, 구조체, 리스트, 배열, 해시 테이블, 트리 등으로 데이터가 유지 되고 이런 데이터 구조는 CPU에서

효율적으로 접근하고 조작하루 수 있음(포인터 이용)

데이터를 파일에 쓰거나 네트워크를 통해 전송하려면 스스로를 포함한 일련의 바이트열(예를 들어 JSON문서)의 형태로

인코딩해야 한다. 두가지 표현사이의 전환이 인코딩(직렬화나 마샬링)이라 하고 역을 디코딩(파싱, 역직렬화, 언마샬링)이

으로 정의함

 

언어별 형식

많은 프로그램 언어는 인메모리 객체를 바이트열로 인코딩하는 기능을 내장함

- 자바: java.io.Serializable, 루비: Marshal, 파이썬: pickle

인코딩은 특정 프로그래밍 언어와 묶여 있어 다른 언어에서 데이터를 읽기는 어려움

 

JSON과 XML, 바이너리 바이너리 파일 변형

• 수(number) 인코딩의 문제점: XML과 CSV는 숫자(digit)로 구성된 문자열 구분이 안됨, JSON은 문자열과 숫자는 구별하지만 정수와 부동소수점 구별하지 않음.
• JSON과 XML은 유니코드 문자열을 잘 지원, 이진 문자열을 지원하지 않음. 이진 데이터를 Base64를 사용로 텍스트로 부호화하며 해석을 위해 스키마를 사용하나 데이터 크기가 33% 증가함
• JSON, XML, CSV 인코딩 형식이 계속 유지될 것이며 무엇이든 다른 조직의 동의를 얻는게 가장 중요

바이너리 인코딩

• 바이너리 형식이 XML, JSON보다 훨씬 적은 공간을 사용

스리프트와 프로토콜 버퍼

• 아파치 스리프트(Apache Thrift)와 프로토콜 버퍼(Protocol Buffers,protobuf)는 같은 원리 기반으로 한 이진 인코딩 라이브러리이다. 프로토콜 버퍼는 구글에서 개발, 스리프트는 페이스북에서 개발

스리프트는 바이너리프로토콜과 컴팩트프로토콜 일반적으로 두가지 이진 인코딩 형식이 있음
(3가지 프로토콜이 있으나 DenseProtocol은 C++만 지원함)

 

필드 태그와 스키마 진화

• 상위 호환성: 필드 태그는 변경이 안됨. 새로운 태그 번호를 부여하는 방식으로 스키마 새로운 필드 추가함
• 하위 호환성; 새로운 필드에 대한 required할수 없음. 추가되는 필드는 optional로 하거나 기본값으 가져야 함

AVRO: 하둡 사용을 위한 이진 인코딩 형식

쓰기 스키마

• 데이터를 저장하거나 전송할 때 사용된 스키마
• 데이터와 함께 저장되거나, 저장소/레지스트리에 따로 저장됨

읽기 스키마

• 데이터를 읽을 때 사용하는 스키마
• 사용자 또는 시스템이 원하는 목적에 맞게 정의 가능
• 쓰기 스키마와 다를 수 있음 (필드를 추가하거나 제거할 수 있음)

스키마진화 규칙

• 상위호환성은 새로운 버전의 쓰기 스키마와 예전 버전의 읽기 스키마를 가질수 있음을 의미한다.
• 하위호환성은 새로운 버전의 읽기 스키마와 예전 버전의 쓰기 스키마를 가질수 있음을 의미한다.
• 호환성을 유지하기 위해서는 기본값이 있는 필드만 추가하거나 삭제할 수 있다.
• Avro는 널을 허용하려면 union type을 사용해야 한다.

쓰기 스키마 사용

• 많은 레코드가 있는 대용량 파일(시작 부분 한번만 쓰기 스키마 포함)
• 개별적으로 기록된 레코드를 가진 데이터베이스
• 네트워크 연결을 통해 레코드 보내기

동적 생성 스키마

• Avro가 프로토콜 버퍼나 스리프트에 비해 장점은 태그 번호가 포함되어 있지 않다는 점이다.
• 새로운 Avro스키마 생성해서 내보내면 갱신되지만 스리프트나 프로토콜 버퍼는 필드 태그를 수동으로 할당해야 함.

코드 생성과 동적 타입 언어

• 스리프트와 프로토콜 버퍼는 코드 생성에 의존한다.(정적 타입 언어)
• 아브로는 정적 타입 프로그램 언어를 위해 코드 생성을 선택적 제공(코드 생성 없이도 사용할 수 있다.)

스키마의 장점

• 스리프트, 프로토콜 버퍼와 아브로는 스키마 사용해 이진 인코딩 형식을 기술함
• 이 스키마 언어는 XML스키마나 JSON 스미카보다 훨씬 간단하며 더 자세한 유효성 검사 기준 지원
• 스키마 진화는 스키마리스 또는 읽기 스키마 JSON 데이터베이스가 제공하는것과 동일한 종류의 유연성 제공

데이터플로우 모드

• 메모리를 공유하지 않는 다른 프로세스로 일부 데이터를 보내고 싶을때는 바이트열 인코딩해야 한다.
• 데이터베이스를 통해/서비스호출을 통해/비동시 메시지 전달을 통해

서비스를 통한 데이터플로우:REST와 RPC 

• 서비스지향설계(SOA), 마이크로서비스설계(MSA)

웹서비스: 서비스와 통신하기 위한 기본프로토콜로 HTTP를 사용할 때