대용량의 미가공 데이터를 호스팅하고 공유하기(2)

지음
0쪽
0원
1970년 1월 1일

적합한 데이터 포맷 선택하기

실질적인 활용 사례를 고려해보자. 지방자치정부가 교통 시스템에 매 분마다 각 버스의 위치와 속도를 추적하는 기기를 막 설치했다. 이 데이터는 버스가 운행표대로 제대로 운행되는지 확인하는 데 사용된다. 그러나 공공 프로젝트이기 때문에 지방자치정부에서는 개별적으로 분석하고자 하는 모든 사람들에게 원본 데이터를 공개하고 싶어한다. 지방자치정부에서는 데이터를 어떻게 구축해야 다른 사람들이 쉽게 사용할 수 있을까?

일반적인 데이터 공유 포맷은 콤마로 구분되는 CSV 파일이다. CSV 파일은 데이터 레코드의 각 필드를 콤마(,)로 구분해서 기록한다. 각 줄은 줄바꿈 문자로 구분한다. CSV의 “C”는 콤마를 나타내지만 탭이나 스페이스 등 다른 특수 문자를 구분자로 사용하는 포맷도 쉽게 볼 수 있다. 예제 1.1은 파이썬에서 CSV를 만드는 방법을 보여준다.

예제 1.1 파이썬을 이용해 CSV 파일 만들기

import csv

my_csv_file = open('/tmp/sample.csv', 'w')
csv_writer = csv.writer(my_csv_file)
sample_row = ('Michael', 1234, 23.46, 'San Francisco, California')

# CSV 포맷으로 한 행 쓰기
csv_writer.writerow(sample_row)

# 결과: Michael,1234,23.46,"San Francisco, California"

CSV는 데이터가 한 줄에 나열되는 플랫 데이터일 경우 확실히 훌륭한 포맷이다. 웹 서버나 센서에서 유입되는 로그 데이터는 CSV 포맷으로 잘 표현된다. CSV는 텍스트 기반의 데이터가 그러하듯 상당히 간결한데, 마크업이나 구조가 거의 없는 순수하고 간단한 데이터이기 때문이다. 또한 CSV 파일은 스프레드시트나 데이터베이스로 불러올 수 있고, 프로그램에서 쉽게 파싱해서 사용할 수 있기 때문에 많은 사람들이 사용하기 쉽다. 플랫 데이터 이상의 모델링이 필요없는 로그나 레코드를 표현하는 데 CSV가 굉장히 유용하다.

가장 중요한 것은 CSV가 데이터에 순차적으로 접근할 때 훌륭한 포맷이라는 점이다. 다시 말해, 컴퓨터 프로그램이 파일의 중간에서부터 한 줄이나 두 줄, 혹은 천 줄을 한 번에 읽어서 바로 처리할 수 있다. 이는 분산 처리 시스템에서 큰 규모의 프로그래밍 작업을 작은 작업으로 분할하는 데 유용하다. 장비 한 대에 장착된 메모리를 꽉 채우는 거대한 CSV 파일이 있는가? 그렇다면 파일을 작은 조각으로 나눠서 각각을 처리하라.

CSV가 여러 긍정적인 면을 가지고 있긴 하지만 대용량 데이터를 공유할 때는 그다지 좋지 않은 측면도 있다. 무엇보다 사용하는 데 표준화된 방법이 없다. 확실히 공식 CSV 표준^3이 있긴 하지만 실제로 개발자가 CSV 파일을 만드는 방법에는 정해진 규칙이 거의 없다. 즉, 사람들이 헤더 라인을 추가하거나 필드 사이에 특이한 구분자를 사용하고, 또는 별난 방식으로 문자열을 끝낼 수도 있다는 의미다. 또한 CSV는 필드 자체의 정보를 참조하는 표준적인 방법을 제공하지 않는다. CSV 파일을 처리할 때 데이터가 표현하는 타입이나 날짜 정보를 간혹 파일명에서 발견하기도 한다. 사실 CSV는 기본적으로 메타데이터가 없어서 CSV로 데이터를 공유할 때는 추가 정보를 별도로 제공해야 한다.

CSV는 행으로 잘 구분되지 않는 데이터를 표현하는 데 매우 부적합하다. 실제로 현실 세계의 데이터는 여러 차원(dimension)으로 구성될 때가 많고, 일부 차원은 CSV의 직사각형 형태의 엄격한 구조에 딱 들어맞지 않는다. 예를 들어, 미국의 정당에 등록한 인원 수를 각 주별로 기록한 데이터를 보자. 모든 주에는 두 개의 주요 정당과 더 많은 소수 정당의 대표가 있다. 그런데 어떤 주는 다른 주에는 없는 특정 정당이 있다. 따라서 정당 리스트는 각 주별로 크기가 다르다. 이 경우 CSV 포맷으로 데이터를 표현한다면 데이터 모델링 관점에서 문제가 발생한다. 모든 정당에 대한 데이터 열을 추가할 것인가? 아니면 정당 목록을 하나의 문자열로 줄여서 한 필드에 모두 저장할 것인가? 이는 고정된 크기의 행을 포함한 구조에는 부자연스럽다.

다음 절에서 다룰 또 다른 문제는 CSV 파일은 사람이 보기에 가독성이 떨어진다는 점이다. 수치 데이터 파일은 숫자가 뒤범벅돼 있어 한눈에 이해하기 어렵다.

거의 모든 것과 호환성을 확보하려고 하거나 플랫 데이터로 표현하기 쉬운 경우에만 CSV를 선택하라. CSV 파일은 파싱하고 불러오기 쉽고, 많은 곳에서 두루 사용하기 때문에 스프레드시트, 데이터베이스 등 대부분 소프트웨어 애플리케이션에서 손쉽게 활용할 수 있다. 그러나 CSV가 특별한 것을 할 수 있다고 기대해서는 안 된다. 여러분이 편하게 사용하는 쉬운 포맷은 아니다. 고객이 기술에 익숙하지 않다면 CSV가 적합한 방법이다. 소프트웨어 개발자가 데이터를 사용한다면 그들은 JSON 같은 구조화된 데이터 포맷을 더 선호할 것이다.

XML: 데이터, 스스로 표현하다

어떤 데이터를 가지고 작업할 때 반드시 XML(Extensible Markup Language)를 만나게 된다. XML은 널리 사용되고 많은 소프트웨어에 지원하기 때문에 고객과 다수의 파일을 공유할 때 우선적으로 고려하는 파일 포맷이다.

XML은 파일을 다른 포맷을 변환해 구조적으로 저장하는 방법이다. 예를 들어, 다양한 포맷으로 변환해야 하는 구조화된 문서 모음이 있다면 XML은 진정한 원천 파일 포맷으로 사용하기에 최적의 방법이다.

JSON: 프로그래머의 선택

XML은 문서의 호환성이 필요한 경우에는 제격이지만 대량의 파일을 제공하기에는 항상 최선의 선택은 아니다. 어떤 경우에는 위대한 XML의 구조와 사명은 여러 프로그래밍 언어의 객체 지향 관점에는 맞지 않다.

JSON(JavaScript Object Notation )은 개발자 사이에서 큰 인기를 얻은 데이터 교환 규약이다. 이름에서 알 수 있듯이 JSON 객체는 유효한 자바스크립트 형식을 취하기 때문에 자바스크립트 애플리케이션에서 사용하기 쉬운 데이터 포맷이다. 하지만 JSON이 자바스크립트만을 위한 것은 아니며, 여러 주요 프로그래밍 언어에서 쓸 수 있는 파서도 많다.

JSON 문법은 매우 간단하다. XML 표현보다는 데이터 원본에 더 가깝게 데이터를 모델링한다. 다시 말해 XML은 트리 형태의 구조를 띠고 있어서 객체 지향 프로그래밍 환경에서 사용하기 어려운 경우가 있다. XML 모델과 확장 가능한 요소는 모든 타입의 데이터를 모델링할 수 있지만 XML 객체의 노드에서 데이터를 가져오는 것은 JSON에서처럼 간단히 객체로 표현된 데이터를 참조하는 것보다 덜 편리하다. JSON 형식의 파일은 XML 파일보다 문법이 간단해서 빠르게 파싱할 수 있다. JSON은 CSV가 데이터를 순차 접근하는 방식처럼 개행 문자를 구분자로 사용하기 때문에 프로그램으로 쉽게 파싱할 수 있다.

JSON도 XML의 덜 바람직한 특성을 띠고 있다. 장황한 포맷이어서 추가 데이터 저장 공간과 대역폭을 차지한다. XML처럼 JSON의 각 필드는 관련된 설명을 함께 포함하고 있어서 큰 데이터를 설명하기 위해 많은 수의 마크업이 필요하다. 데이터를 옮기는 데 적합한 포맷임에도 JSON은 확장성이 고려되지 않았고 XML에서 볼 수 있는 근사한 스키마와 유효성 검증 기능이 부족하다.

마지막으로 JSON으로 데이터를 제공하는 또 다른 훌륭한 이유가 있다. JSON 객체는 다양한 종류의 유명한 오픈소스 비관계형 데이터베이스에 넣기가 쉽다. 3장, “대중이 생성한 데이터를 수집하기 위한 NoSQL 기반의 웹 애플리케이션 구축하기”에서 관련 기술을 살펴보겠다.

팀에 프로그래머가 포함돼 있다면 개행 문자를 구분자로 쓰는 JSON 형식의 데이터를 제공하는 식으로 데이터 교환을 시작하는 편이 것이 좋다. 이 포맷은 애플리케이션 개발자와 비관계형 데이터베이스 관리자를 행복하게 만든다. JSON은 스프레드시트에 데이터를 바로 불러올 수 있다고 기대하는 일반인에게는 적합하지 않은 포맷이다. 그렇게 하려면 CSV를 사용하면 된다.

예제 1.2는 CSV, XML, JSON 포맷의 구조를 간략하게 비교한 것이다.

예제 1.2 CSV, XML, JSON 비교

# CSV 예제
first_name,last_name,book,date
"Michael", "Manoochehri", "Data Just Right",2013

<!-- XML 예제 -->
<xml>
  <author>Michael Manoochehri</author>
  <list>
    <book position="1">Data Just Right</book>
  </list>
</xml>

// JSON 예제
{
  "name": "Michael",
  "book":{"title":"Data Just Right","date":"2013"}
}

문자 인코딩

문자 인코딩은 지금 이 책을 읽고 있는 것처럼 정보를 전달하는 데 사용하는 모든 문자나 기호를 컴퓨터로 표현하는 과정이다. 문자 인코딩의 간단한 예로는 선을 통하거나 시각적인 방식으로 펄스를 전송해 알파벳 문자를 표현하는 모스 부호가 있다.

몇 년 전, 하드웨어의 한계 때문에(그리고 어쩌면 초기 컴퓨팅 시스템에서 일하던 미국인 컴퓨터광들의 언어 편중 때문에) 많은 컴퓨터가 텍스트 문자를 ASCII(American Standard Code for Information Interchange)로 알려진 포맷으로 표현하곤 했다. ASCII는 영어권 문자를 표현하는 데 훌륭한 방법이었다. 너무 잘 동작해서 존슨(Johnson) 행정부는 1968년 ASCII를 미 연방 표준으로 지정하기까지 했다^4.

미국에서 잘 작동하는 것이 영어 알파벳과 다른 문자를 사용하는 언어로 소통하는 사용자에게는 정확히 번역되지 않았다. 실제로 많은 국가에서는 ASCII와 비슷하지만 호환되지 않는 각자의 인코딩 표준을 다양한 방법으로 만들었다. 이로써 소프트웨어 세계에 온갖 종류의 성가신 문제가 일어났다.

다행히도 1980년대 후반에 이르러 굉장히 똑똑한 컴퓨터 과학자들이 이 문자 인코딩 문제에 대한 솔루션을 만들기 시작했다. 이 솔루션이 바로 세상의 모든 문자의 표준 인코딩 집합을 정의하는 것을 목표로 만들어진 유니코드 표준(Unicode Standard )이다. 보통 유니코드는 여러 표준 중 하나로 구현돼 있는데, 가장 흔히 볼 있는 것으로 UTF-8, UTF-16이 있다. UTF-8 표준은 식탁 매트에서 처음 구상한 후 며칠 만에 구현된 것으로 유명하다^5. 빅데이터 환경을 둘러싼 기술이 대부분 UTF-8이 개발된 이후에 발전했기에 유니코드는 2장과 다른 장에서 소개하는 소프트웨어에서 거의 모두 지원된다. 이 책에 등장하는 각종 기술과 도구는 이러한 인코딩 중 하나를 기본적으로 사용한다.

하지만 안타깝게도 다량의 데이터가 ASCII의 특정 버전이나 비유니코드 체계를 따르는 파일에 들어 있을 때가 있다. 간혹 비유니코드 데이터가 우연히 혹은 무의식적으로 만들어지기도 한다. 비유니코드 데이터가 생성되는 또 다른 원천은 일부 항공사의 수십 년 된 예약 시스템 같은 레거시 소프트웨어다. 어떤 오래된 데스크톱 소프트웨어에서는 구식 인코딩 포맷만 지원하기도 한다.

요지는 간단하다. 아직 UTF-8이나 UTF-16 같은 방식으로 인코딩돼 있지 않은 다량의 데이터가 있다면 변환하라는 것이다.

텍스트 파일을 다루게 된다면 다음의 고전적인 방법을 시도해 보라.

다량의 텍스트 데이터를 다룰 경우 문제를 해결하는 가장 빠른 방법은 split, grep, sed와 같은 기본 유닉스 명령줄 유틸리티를 사용하는 것이다. 나온 지 수십 년이 지났지만 지금도 이러한 소프트웨어는 널리 사용된다. GNU/리눅스 같은 오픈소스 유닉스 배포판 덕분에 이런 유틸리티는 이전보다 더 많이 사용될 것이다.

CSV 파일에 성가신 헤더 정보가 포함돼 있는가? 파일의 첫 두 줄을 제거하고 새로운 파일을 만들려면 다음과 같이 하면 된다.

sed '1,2d' file > newfile

원본 파일에 캐럿(^) 같은 이상한 구분자가 쓰였는가? 그런 성가신 문자를 콤마로 대체하라!

sed 's/\^/,/g' original_file > new_file

백만 줄 이상의 굉장히 큰 텍스트 파일을 처리할 때 특정 줄에 잘못된 레코드가 있을 수 있다. 이것을 어떻게 확인할 것인가? sed를 이용하면 특정 줄 번호를 화면에 출력할 수 있다. 예를 들어 3,451,234번 줄을 보고 싶다면 다음과 같이 하면 된다.

sed '3451234q;d' your_large_file.csv

큰 파일을 다루는 데 좋은 유틸리티로 split이 있는데, 이름에서 알 수 있듯이 큰 파일을 작은 파일로 쪼갠다. 예를 들어, 매우 큰 파일을 줄 단위가 깨지지 않는 선에서 500Mb 단위로 분할하고 싶다면 다음 명령을 실행하면 된다.

split -C 500m your_large_file.csv

텍스트 처리와 관련된 유닉스 명령줄 유틸리티를 활용하면 더 많은 일들을 할 수 있다. 때로는 가장 간단한 것이 가장 빠르고 훌륭한 해결책이 되기도 한다.

파일 변환

지금까지는 다양한 데이터 포맷으로 이뤄진 파일이 많을 때 직면하는 문제에 대해 간략히 다뤘다. 실제로 많은 파일을 한 포맷에서 다른 포맷으로 변환하는 것은 매우 복잡한 절차가 될 수 있다. 특정 포맷의 데이터를 많이 가지고 있고, 그것을 다른 포맷으로 변환하고 싶다면 어떻게 해야 할까? 이러한 데이터 변환 프로세스는 때때로 굉장히 벅찬 일이 될 수 있다.

다량의 데이터를 한꺼번에 변환하는 데는 엄청나게 오랜 시간이 걸릴 수 있다. 다행히도 이것 역시 분산 처리 시스템에 적합한 작업이다. 수백 혹은 수천의 개별 문서를 처리해야 할 경우 굉장히 많은 수의 분산 처리 장비에서 병렬로 작업을 처리하는 것이 도움이 된다.

가장 유명한 오픈소스 분산 처리 프레임워크는 하둡(Hadoop)이다. 하둡은 맵리듀스(MapReduce) 프레임워크를 구현한 오픈소스로서 데이터 처리 작업을 굉장히 많은 수의 장비에 배분해서 처리한다. 하둡은 원래 구글의 맵리듀스 논문에서 시작했다(그러나 맵리듀스를 구현한 솔루션으로 하둡만 있는 것은 아니다). 9장, “피그와 캐스케이딩을 이용한 데이터 변환 워크플로우 구축하기”에서는 오픈소스 캐스케이딩(Cascading) 워크플로우 프레임워크를 이용해 E2E[^6] 데이터 변환 파이프라인을 어떻게 만드는지 살펴보겠다.

[^6]: (옮긴이) E2E(end-to-end)는 네트워크에서 복잡한 작업은 모두 양쪽 끝 노드에서 처리하고, 그 사이를 연결하는 엣지는 최대한 간단해야 한다는 원칙을 말한다

데이터 이동: 데이터 직렬화 포맷

XML이나 JSON, 심지어 오래된 CSV 파일은 모두 데이터를 컴퓨터가 이해할 수 있는 비트로 변환해 한곳에서 다른 곳으로 옮길 때 사용하는 객체의 클래스 멤버로 사용될 수 있다. 이 프로세스를 데이터 직렬화(data serialization)라고 한다.

데이터 시스템에서는 네트워크를 통해 여러 대의 장비를 활용하기도 한다. 어떤 장비는 많은 수의 데이터 출처에서 데이터를 빠르게 수집하는 데 특화돼 있다. 또 어떤 장비는 데이터를 분석하는 배치 프로세스를 실행하는 작업을 한다. 데이터를 한 시스템에서 다른 시스템으로 옮기는 시스템을 구축할 때 한 프로세스의 결과물이 다른 프로세스의 입력으로 사용되는 것이 일반적이다. 아쉽게도 이 프로세스에서 네트워크는 항상 가장 느린 부분에 해당한다. 데이터 이동의 효율성을 높이려면 데이터를 가급적 가장 간결한 형태로 표현하는 것이 유리하다.

2장의 앞 부분에서는 XML이 문서 포맷을 다른 것으로 바꾸는 데 적합하지만 데이터 호환성 측면에서 언제나 최고의 선택은 아니라고 언급한 바 있다. 데이터가 매우 큰 경우에는 더욱 그렇다. JSON에도 XML의 이런 특징이 있다는 점을 떠올려보자. XML과 JSON의 마크업은 데이터가 각 포맷으로 표현되는 것보다 파일을 크게 만들기 때문에 물리적으로 데이터를 한곳에서 다른 곳으로 옮기는 시간이 늘어난다. 파일을 보내기 전에 압축할 수 있다고 하더라도 여전히 개발자가 압축하고 푸는 과정을 직접 처리해야 한다.

인터넷 회사들이 웹 규모의 데이터 문제를 다루기 시작하면서 시스템 간에 데이터를 옮기는 데 꽤 많은 비용과 시간이 든다는 사실을 금방 깨달았다. 이와 비슷하게 다양한 기술(예를 들어, 어떤 애플리케이션에서는 C++를 사용하고 어떤 애플리케이션에서는 파이썬을 사용하는 경우)로 구축된 시스템에서 데이터를 이리저리 옮길 때 같은 언어를 사용하는 것이 유리하다는 사실을 발견했다.

이 문제에 대한 초보적인 접근법은 데이터를 바이트 배열, 즉 기본적으로 바이너리 방식으로 변환하는 것이다. 이 방법은 데이터 크기를 줄일 수 있지만 아쉽게도 각 시스템에서는 데이터가 어떻게 직렬화되는지 사전에 정확히 알고 있어야 나중에 원상 복구할 수 있다. 애플리케이션의 인코딩과 디코딩 기능을 하드코딩하는 것도 가능하지만, 데이터 모델이 변경되는 경우 문제가 될 수 있다. 한 애플리케이션 파이프라인이 다른 프로그래밍 언어로 구축된 여러 시스템에 맞물려 있다면 이런 기능을 변경하는 작업도 고려해야 한다.

이 문제를 해결하기 위한 다양한 솔루션은 서로 독립적으로 만들어졌지만 모두 비슷한 방식으로 동작한다. 일반적으로 첫 번째 단계에서는 데이터에 대한 설명이나 스키마를 제공하고 발신자와 수신자 모두에게 공통된 장소에 스키마를 정의해야 한다. 두 번째 단계는 메시지 송수신자 모두 데이터를 직렬화하기 위해 프로그래밍 언어를 이용해 표준 인터페이스를 구축하는 것이다.

아파치 쓰리프트와 프로토콜 버퍼

데이터가 매우 커질 때 시스템 간의 데이터 전송 오버헤드가 발생할 수 있다. 이것은 메가바이트 규모에서는 문제가 되지 않지만 기가바이트 또는 그 이상이 되면 데이터를 이리저리로 옮기는 비용과 대기시간이 커다란 문제로 대두된다. 이 문제를 해결하는 비슷한 두 접근법이 바로 아파치 쓰리프트(Apache Thrift)와 프로토콜 버퍼(Protocol Buffers)다.

아파치 쓰리프트는 원래 페이스북에서 데이터 직렬화를 위한 일반화된 데이터 솔루션을 제공하기 위해 개발한 오픈소스 프로젝트다. 쓰리프트에서는 직렬화될 데이터를 기술하는 설정 파일을 개발자가 정의할 수 있다. 그러고 나면 코드 생성기가 실행되어 미리 지정한 언어로 데이터 직렬화를 처리하는 서버가 만들어진다.

구글의 프로토콜 버퍼는 쓰리프트와 아주 비슷하고 프로토콜 버퍼를 컴파일하는 소프트웨어는 오픈소스 소프트웨어로 공개돼 있다.

쓰리프트처럼 프로토콜 버퍼도 다양한 프로젝트에서 사용되고 있다. 일반적으로 프로토콜 버퍼는 데이터를 이리저리 옮길 때 사용하지만 어떤 곳에서는 파일을 저장하는 데 프로토콜 버퍼를 사용하기도 한다. 예를 들어, 오픈스트리트맵(OpenStreetMap)에서는 현재 가용한 지도 데이터를 XML 포맷에서 PBF(프로토콜 버퍼 바이너리 포맷)로 알려진 정적 포맷으로 변환하는 작업을 진행하고 있다.

아파치 아브로

아파치 아브로(Apache Avro)는 앞에서 살펴본 기술에서 최고의 기능만을 결합한 비교적 새로운 직렬화 포맷이다. 아브로 데이터는 아파치 쓰리프트나 프로토콜 버퍼와 달리 스스로 설명하고, 각 개별 필드를 정의하기 위해 JSON 스키마 규약을 사용한다. 그러나 XML이나 JSON과는 달리 이 스키마는 모든 필드에 포함되지 않으며 데이터 자체와 함께 JSON 객체의 형태로 제공된다. 아브로는 기본적으로 압축을 지원하기 때문에 개발자가 압축 로직을 만드느라 많은 시간을 쓰지 않아도 된다.

아브로는 현재 하둡 커뮤니티에서 사용되고 있지만 다른 애플리케이션에도 널리 사용될 만하다. 일부 개발자들은 아브로 포맷에 담긴 데이터를 정적 파일로 읽고 쓰는 것의 가능성을 탐구 중이다. 아브로를 지원하는 프로그래밍 언어는 점차 늘고 있는 추세이고, 시간이 지남에 따라 데이터 직렬화를 위한 사실상의 표준이 될 가능성이 있다.

정리

다량의 문서를 공유하는 것은 간단한 작업처럼 보여도 접근성이 가장 높은 방식으로 데이터를 공유해야 하는 많은 조직에서 현실은 그렇게 녹록치 않다.

대량의 파일을 제공하는가? 대용량 스토리지와 대역폭에 대한 확장성과 비용을 고려한다면 보통 IAAS를 통한 분산 스토리지 서비스만이 유일한 경제적인 솔루션이다.

제공하는 파일 포맷을 선택하는 것은 도전과제가 될 수 있지만 고객이 데이터를 어떻게 사용하는지 알고 있다면 큰 문제가 되지 않을 수 있다. CSV 파일은 쉽게 파싱할 수 있고 스프레드시트에서 데이터베이스 소프트웨어, 프로그래밍 언어에 이르기까지 거의 모든 종류의 소프트웨어에서 범용으로 지원된다. 그러나 CSV로는 복잡한 데이터 구조를 모델링하기가 수월하지 않다. XML은 문서를 한 포맷에서 다른 포맷으로 변환돼야 하는 데이터를 명확하게 설명해주는 훌륭한 포맷이다. XML은 구조가 명확한 문서 데이터를 제공할 때 가장 잘 지원된다. 그러나 빠르게 직렬화하고, 전송하고, 파싱하고 싶어하는 개발자에게는 좋은 포맷이 아니다. JSON은 XML만큼 확장성이 뛰어나지 않고 CSV만큼 간단하지 않지만 데이터 전송이 용이하다는 점 때문에 프로그래머나 비관계형 데이터베이스 관리자에게 가장 인기 있다.

XML과 JSON 모두 데이터를 설명하는 데 사용하는 마크업과 함께 데이터를 전송한다. 데이터 규모가 커지면서 더 많은 데이터 제공자가 텍스트 기반 파일 포맷(XML이나 JSON 같은)에서 데이터 전송을 효율적으로 처리하도록 고안된, 특정 언어에 종속되지 않는 바이너리 포맷으로 변경하고 있다.

대량의 데이터를 전송하거나 처리하는 소프트웨어 시스템을 만들어야 하는 상황이라면 데이터 직렬화 포맷을 사용해 효율성을 증진시킬 수 있다. 쓰리프트나 프로토콜 버퍼는 오픈소스이고 관련 커뮤니티에서 잘 지원하고 있다. 아브로는 2장에서 기술한 포맷의 다양한 장점을 결합시켜 데이터 직렬화를 처리하는 새로 등장한 흥미로운 방식이다.