이전 장
Avro
아브로는 하둡에서 만든 RPC 프레임워크이다. thrift의 스키마는 하둡과 맞지 않아 동적 스키마를 생성할 수 있는 아브로를 만들었다. (왜 thrift의 스키마는 맞지 않았을까? 궁금.)
아브로의 스키마
아브로가 thrift, protocol buffer와 같이 정적 스키마를 사용하는 프레임워크와 다른 점은 스키마에 필드 인덱스가 없다는 것이다. 아브로는 IDL, JSON 두 가지 스키마를 사용한다.
record Person {
string UserName;
union {null, long} favoriteNumber = null;
}
GraphQL
복사
이 때문에 부호화 시에도 필드 태그와 필드 타입을 바이트 배열에 포함하지 않는다. 부호화된 바이트는 데이터의 길이와 값으로 이루어져 있다. thrift, protocol buffer보다 용량을 좀 더 줄일 수 있다. (81 → 32바이트)
스키마 발전
부호화된 데이터를 받는 쪽에서는 스키마의 필드를 순서대로 살펴보고 데이터 순서와 필드 순서를 대응시켜봐야 한다. 따라서 데이터를 쓰는 쪽(서버)과 읽는 쪽(클라이언트) 스키마가 똑같아야한다. 쓰는 쪽과 읽는 쪽의 스키마를 일치시키면서 *스키마를 발전시키려면 어떻게 해야할까?
*스키마 발전(schema evolution): 시간이 지남에 따라 스키마가 변화하는 것을 의미한다. 양방향 호환성을 지키면서 스키마를 변경해야 한다.
읽기, 쓰기 스키마
쓰는 쪽과 읽는 쪽의 스키마를 일치시키면서 스키마를 발전시키려면 어떻게 해야할까?
→ 아브로는 쓰기 스키마와 읽기 스키마를 일치시키지 않고도 스키마를 발전시킨다.
어플리케이션에서 데이터를 전송할 때 아브로로 부호화하기 위해 사용하는 스키마를 쓰기 스키마라고 한다. 반대로 어플리케이션이 DB나 네트워크로부터 받은 데이터를 복호화할 때 사용하는 스키마는 읽기 스키마라고 한다.
아브로의 가장 큰 특징은 ‘읽기 스키마와 쓰기 스키마가 호환만 가능하면 된다’는 것이다.
데이터를 읽을 때는, 쓰기 스키마와 읽기 스키마를 모두 살펴본 후 데이터를 읽기 스키마에 맞게 변환한다. 스키마를 해석(schema resolution)할 때는 이름으로 구분한다.
예를 들어 쓰기 스키마에서는 필드가 username, favoriteNumber 순서이고 읽기 스키마에서는 favoriteNumber, username이라면 데이터를 읽을 때 두번째 데이터를 첫번째로, 첫번째 데이터를 두번째로 변경해서 읽기 스키마가 제대로 읽을 수 있게 만든다.
그래서 스키마 발전 어떻게 시키는 거죠?
thrift, protocol buffer의 정적 스키마같은 경우 양방향 호환성을 지키기 위해 필드 태그를 변경하는 대신 새로운 번호를 부여하고, optional 데이터만 삭제할 수 있다. 필드 이름 대신 필드 태그를 사용하니 필드 이름은 자유롭게 바꿀 수 있다.
아브로는 호환성을 유지하기 위해 기본값이 있는 필드만 추가하거나 삭제할 수 있다. optional, require가 없는 대신 기본값과 유니온 타입을 사용해 null을 허락함으로써 optional을 대신한다.
아브로는 필드 이름을 사용해 쓰기, 읽기 스키마를 비교한다. 따라서 정적 스키마와 달리 데이터 타입을 자유롭게 변경할 수 있다. 반대로 필드 이름을 사용하니 그것은 쉽게 변경할 수 없다. 대신 별칭을 사용해 예전 스키마 필드의 이름과 매치시킴으로써 하위호환성을 유지한다.
references
•
책 데이터중심어플리케이션설계 4장
