빅데이터라는 말은 기계학습 혹은 딥러닝이라는 말보다 한단계 앞서서 유행하기 시작한 말입니다. 데이터를 어떻게 효과적으로 다루는지에 대한 연구가 이루어지기 위해서는 우선 적절한 데이터가 있어야 하므로 데이터 수집과 관련된 연구가 먼저 강조되는 것이 타당하다고 할 수 있겠습니다.
하지만 여기서 질문을 한번 해보고 싶습니다. 과연 빅데이터란 무엇일까요? 얼마나 커야 Big 하다고 할 수 있을까요?
이 글을 준비하면서 주변 지인들에게 그와 같은 질문을 해 보았을 때 다음과 같은 다양한 답변을 받을 수 있었습니다. (질문: 당신이 생각하는 빅데이터란 무엇인가?)
1. 데이터가 특정 용량 크기 이상이 되었을 때 (1GB, 1TB 이상 등)
2. 데이터가 컴퓨터 한대에서 처리할 수 없을 때
3. 데이터가 Excel에서 열어볼 수 없을 때
4. 데이터의 샘플 수가 많을 때(image 백만장 이상, 1000명 이상의 유전체 데이터 등)
사실 위의 답변들 중 1-3은 관점은 다르지만 모두 데이터의 용량(volume)에 초점을 맞춘 답입니다. 데이터의 크기에 따라서 분산 처리를 하게 되는 개발자 입장에서는 데이터가 한 대에서 처리할 수 있는지 아닌지가 자신의 작업 내용을 결정하게 될 것이고, 엑셀 사용자에게는 내가 이 파일을 열 수 있느냐 없느냐가 중요한 구분점이 되겠지요. 하지만 결국은 용량이 어떤 임계치를 넘는지 여부로 빅데이터를 정의하고 있다는 점에서 동일합니다.
4번 답은 이와 달리, 데이터의 총 용량이 얼마인지가 아니라 그 데이터 안에 독립적으로 취급할 수 있는 샘플들이 몇개나 있는지에 초점을 맞춘 것입니다. 가령 데이터가 총 100GB 가 있을 때, 1GB짜리 그림 100개로 채워져 있을 수도 있고, 10GB짜리 그림 10개로 채워져 있을 수도 있습니다. 1-3의 기준으로는 총 용량은 100GB로 동일하기 때문에 두 경우가 같다고 말할 수 있겠지만, 4의 관점에서는 두 경우는 완전히 다르다고 할 수 있겠습니다.
필자와 같은 입장에 있는 사람들은 같은 질문에 4번과 같은 답을 하게 될 것입니다. 왜냐하면, 독립적으로 취급할 수 있는 샘플의 양은 기계학습이나 딥러닝이 얼마나 힘을 발휘할 수 있을지를 결정짓는 중요한 요소이기 때문입니다. 이에 대해서는 추후 다른 글을 통해서 더 자세히 들여다 보도록 하겠습니다. 하지만 데이터의 볼륨이 커질 수록 샘플 수도 늘어나는 것이 일반적이기 때문에 1-3도 같은 경향을 반영한다고 할 수 있겠습니다. 온라인 커뮤니티 (Quora)에 올라온 같은 질문에서도 대체로 사람들이 데이터의 용량과 용량의 증가 속도에 초점을 맞추고 있습니다 [1].
저장매체의 고집적화를 동반한 컴퓨터 기술발전에 의해 현재 우리는 데이터를 더 많이 생산하고, 더 효율적으로 저장하게 되었습니다. 전세계적으로 하루에 새롭게 생산되는 데이터의 양은 2,500,000 Terabyte (2.5 Exabyte 혹은 2,500 Petabyte – 네 저도 처음 들어보는 단위 입니다) 에 이른다고 합니다 [2]. 이는 블루레이 디스크 천만장을 채울 수 있는 양이고, 천만장의 블루레이를 쌓으면 에펠 탑 높이의 4배에 이릅니다.
또한 이때껏 누적된 데이터의 90%가 불과 2년만에에 생산되었다고 하니, 엄청난 증가속도를 가늠케 합니다. 2004년 한 하버드 학부생의 기숙사 내 서버 한대에서 운영되던 페이스북은 2011년 첫 데이터 센터를 미국 오레곤에 지은 것을 시작으로 2016년까지 총 6개의 데이터 센터(2개는 건설중)를 미국 안팎으로 확보했습니다 [3]. 각 데이터 센터가 수천, 수만에 이르는 서버로 구성된 엄청난 인프라이지만, 전세계적으로 분당 평균 3백만을 넘는 페이스북 포스팅 수를 감안하면 그 공간을 채우는데 그리 오랜 시간이 걸리지는 않을것 같습니다 [4].
그럼 생물학 데이터의 경우 어떨까요?
생물학에서 큰 규모의 데이터가 본격적으로 나타나기 시작한 것은 차세대 시퀀싱 (Next-generation sequencing; NGS) 기술이 보급되기 시작한 이래일 것입니다. NGS는 기본적으로 DNA 염기 서열을 작은 조각 (fragment) 단위로 쪼개서 그 조각들을 무수히 많이 읽어내어 그 조각들의 정보로부터 전체 DNA 염기서열 정보를 얻어내는 기술입니다. 전체 유전자를 한번에 분석할 수 있기에 매력적이기는 하지만 자연스레 데이터의 용량도 또한 커질 수 밖에 없습니다.
한번 데이터의 크기를 대략적으로 계산해 볼까요?
우선 사람의 유전체는 A,T,G,C 이렇게 네가지 염기로 구성된 서열입니다. 4가지 경우의 수를 표현하기 위해서는 염기 하나당 2 bit 가 필요합니다. (00, 01, 10, 11 – 2진수를 생각하시면 됩니다.) 물론 이것은 가장 최적의 경우이고 단순히 텍스트로 저장할 경우에는 염기 하나당 1 byte (=8bit ascii code)가 필요하게 됩니다.
인간의 염기서열의 길이가 약 30억이기 때문에,
2 bit X 3,000,000,000 = 6,000,000,000 bit = 750,000,000 byte = 750 MB
비효율적으로 저장할 경우(즉, 각 염기당 1Byte)에는 이의 4배인 3 GB가 됩니다.
이상적인 세상에서는 위의 크기의 데이터만 생산하면 유전체 정보를 알수 있을 것입니다. 하지만, NGS는 염기서열의 전체를 읽어내는 것이 아니라 조각들을 읽어내기 때문에, 실제 유전체 길이보다 훨씬 많은 양의 염기서열을 읽어야지만 전체를 반영할 수 있습니다. 이 때문에 Sequencing depth (읽어들인 염기서열의 총량을 염기서열 길이로 나눈 값)은 데이터의 질을 평가하는 중요한 척도입니다 [5]. 가령, Sequencing depth를 30으로 잡고 데이터 사이즈를 계산해 보겠습니다.
750 MB X 30 = 22.5 GB
혹은
3GB X 30 = 90 GB (각 염기당 1 byte 일 경우)
한개의 NGS sequence 데이터가 가질 수 는 크기입니다. 어마어마하죠? 물론 유전체 전체가 아닌 전사되는 부분 (RNA로 변환되는 부분; RNA-seq, Exome-seq 등)이나 단백질이 붙는 부분 (ChIP-seq) 등 극히 일부만을 커버하는 데이터의 경우에는 이렇게까지 많이 읽을 필요는 없기 때문에 개개의 데이터 사이즈가 훨씬 작아집니다 [6]. 그러나 여전히 GB 단위의 데이터가 단 하나의 샘플에서 생산됩니다.
자, 그럼 우리들은 이런 데이터를 우리가 얼마나 생산해 왔을까요? 역시나 지수함수를 따릅니다.[7]
암의 분자적 특성을 분석하기 위해서 이루어진 TCGA (The Cancer Genome Atlas) 프로젝트의 경우, 30가지가 넘는 서로 다른 암 조직 11,000명 이상의 샘플로부터 NGS 데이터를 생산했습니다. 게다가 DNA 염기 서열 한가지만 본 것이 아니라 전사 발현 (RNA-seq), 단백질 발현 등을 보는 데이터와 환자의 예후와 관련된 정보까지 감안하면 데이터의 크기가 엄청나게 커집니다. 엄청나 보이는 TCGA지만, 앞으로 다가올 프로젝트들의 백만이 넘는 수치를 보면 이미 초라해 보입니다.
이 어마어마한 데이터가 있으면 뭐든지 할 수 있을 것 같은데요. 과연 그럴까요? 향후 글들에서는 우리가 이런 데이터들을 어떻게 활용하고 있는지, 어떤 한계와 가능성이 있는지 이야기해 보도록 하겠습니다.
[2] http://www.vcloudnews.com/every-day-big-data-statistics-2-5-quintillion-bytes-of-data-created-daily/
[3] http://www.datacenterknowledge.com/data-center-faqs/facebook-data-center-faq
[4] https://www.linkedin.com/pulse/what-happens-internet-minute-fadi-gedeon/
[5] https://www.illumina.com/science/education/sequencing-coverage.html
[6] https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4027199/
[7] http://www.genengnews.com/gen-articles/precision-medicine-research-in-the-million-genome-era/5944
안야로
Latest posts by 안야로 (see all)
- 빅데이터: 큰 용량의 역습 – 차원의 저주 (Curse of dimensionality) - October 10, 2017