빅 데이터 구현 사례: 빅 데이터의 전장에서 정보 기술은 처음 사용되기 시작한 이래로 항상 새로운 문제에 직면해 왔다. 연구자들은 각자의 영역에서 정보 처리의 여러 문제를 해결하기 위해 치열한 전쟁을 수행해 왔다. 최근 새롭게 부상한 전쟁터는 빅 데이터 분야이다. 빅 데이터는 기존 정보처리 접근 방법으로는 처리하기 곤란한 대규모 데이터와 이런 데이터의 분석을 위한 기술을 포괄하는 개념이다. 본 기고는 구글, 페이스북, 야후, 링크드인 등 세계적인 정보 기술 서비스 업체가 실제적으로 빅 데이터 문제를 해결하기 위한 전쟁을 어떻게 수행하고 있는지를 생생하게 보여주는 다양한 사례들을 다루고 있다. 먼저, 페이스북은 메시지 서비스를 제공하기 위해 어떻게 스토리지 인프라를 운영하는지를 보고하고, 마이크로소프트의 빙은 상품과 지도 검색을 위해 어떻게 데이터 클렌징(Data Cleansing) 기술을 활용했는지 소개한다. 야후 연구팀은 빅 데이터 프레임워크에 적용할 수 있는 일반화된 기계학습 프레임워크에 대한 연구 결과를 보여준다. 링크드인의 연구팀은 실시간 행위정보의 수집을 위한 데이터 파이프라인의 구현 사례를 소개한다. 마지막으로 구글 연구팀은 지도 서비스 상에 도메인 전문가들이 빅 데이터 분석 결과를 다양하게 표현할 수 있는 기술에 대해 소개한다. 본 기고에서는 개별적인 사례를 제시하기 전에 기본적인 빅 데이터 관련 기반 기술을 설명한 후 각각의 사례들이 이러한 기반 기술과 어떻게 연결되어 있는지를 설명할 것이다. 빅 데이터의 실제적 문제는 무엇이며, 어떤 방식으로 해결책을 찾을 것인지, 또 어떻게 빅 데이터 기반 기술을 실제 문제 해결에 적용할 것인지에 대한 이해를 얻기를 기대한다. 글 김양석 (University of New South Wales), 자료제공 한민족과학자네트워크
1. 서론 정보 기술은 처음 사용되기 시작한 이래로 항상 새로운 문제에 직면해 왔다. 연구자들은 각자의 영역에서 문제를 해결하기 위해 치열한 전쟁을 수행해 왔다. 최근 새롭게 부상한 전쟁터는 빅 데이터 (Big Data) 분야이다[1]. 전산 시스템의 일반화와 인터넷을 기반으로 한 서비스(예, 소셜 미디어)의 확산은 이전에는 예측할 수 없었던 막대한 양의 정보를 생성한다. 이런 유형의 데이터는 기존의 접근 방법으로는 저장, 처리, 분석을 수행하기에 곤란하다. 이런 유형의 데이터를 빅 데이터(Big Data)라고 명명한다. 빅 데이터는 다음의 데이터를 포함한다. 첫째, 빅 데이터는 고객관계관리(CRM) 시스템에서 발생하는 고객정보, 전사적 자원관리시스템 (ERP) 데이터, 전자상거래 거래 데이터 등 전통적인 조직 데이터를 포함한다. 둘째, 빅 데이터는 전화 상담 기록, 웹 로그, 자동계량시스템 (smart meter), 생산 센서 (manufacturing sensors), 장비 로그 (equipment logs), 주식거래시스템 등의 기계가 생성한 또는 센서 데이터를 말한다. 셋째, 빅 데이터는 고객 피드백 정보, 트위터 같은 마이크로 블로깅 사이트, 페이스북 같은 인터넷 미디어에서 발생하는 데이터를 말한다[2].
메킨지 글로벌 연구소(McKinsey Global Insitute)는 빅 데이터의 양은 매년 40%씩 증가할 것이고 2009년에 2020년 사이에 대략 44배 증가할 것이라고 추정했다. 종종 빅 데이터는 양 (volume), 속도(valocity), 다양성 (variety), 가변성(variability) 등으로 특징지어진다 [3].
빅 데이터 분석 (Big Data Analytics)은 빅 데이터를 분석하는 새로운 데이터 분석기법을 말한다. 빅 데이터 분석의 특징은 어떻게 데이터로부터 가치있는 정보를 발견하가에 있다. 빅 데이터는 알려진 값의 단순한 집계 결과를 나타내는 기존의 비지니스 인텔리전스와 다르다. 빅 데이터는 가설을 설정하고, 통계적, 시각적, 의미적 모델을 만들어 검증을 통해 새로운 가설을 만드는 모델링 과정을 통해 가치를 발견한다. 일반적으로 빅 데이터라고 할 때 이는 데이터와 분석 기술을 포괄적으로 나타낸다. 2. 빅 데이터 플랫폼다른 IT 기술 플랫폼처럼 빅 데이터 인프라는 독특한 요구사항이 있다. 먼저 빅 데이터 플랫폼의 모든 구성요소를 고려할 때, 최종 목적이 빅 데이터를 쉽게 통합해서 심도있는 분석을 수행하기 위한 것이라는 사실을 기억해야 한다. 빅 데이터 인프라 요구사항은 데이터 획득 (data acquisition), 데이터 구조화 (data organization), 그리고 데이터 분석 (data analysis)을 포함한다[2]. 데이터 획득은 빅 데이터 이전과 구별되는 주요한 변화 중에 하나이다. 빅 데이터는 매우 빠르고 다양한 데이터 스트림을 말한다. 데이터 획득 측면에서 빅 데이터 인프라는 1) 데이터를 캡처하고 짧고 간단한 질의들을 실행하는 데 있어 낮고 예측 가능한 시간 내에 응답을 해야 한다. 2) 분산 환경에서 매우 많은 양을 취급할 수 있어야만 한다. 3) 유연하고 다이내믹한 데이터 구조를 지원해야 한다. NoSQL 데이터베이스 (예:HBase, Cassandra 등)는 빅 데이터를 획득하고 저장하기 위해 자주 사용된다. NoSQL 데이터베이스는 다양한 데이터 구조에 적합하고 대규모 처리를 지원한다. NoSQL 데이터베이스에 저장된 데이터는 일반적으로 시스템이 데이터 분류나 파싱(parsing) 없이 단순히 캡처를 목적으로 하기 때문에 매우 다양하다. 예를 들어 NoSQL 데이터베이스는 소셜 미디어 데이터를 수집하기 위해 사용될 수 있다. 고객이 사용하는 애플리케이션은 자주 변경되지만, 기저에 있는 스토리지 구조는 단순함을 유지한다. 엔티티 사이에 관계를 가진 스키마를 설계하는 대신에 NoSQL은 종종 데이터 포인트를 구별하는 주요한 키와 관련 데이터를 갖는 컨텐트 컨테이너를 가지고 있다. 이 단순하고 다이내믹한 구조는 스토리지 레이어에서 비용이 많이 드는 재조직화 없이 데이터 구조를 바꿀 수 있게 한다.
빅 데이터의 획득과 관련된 대표적인 기술로는 HDFS (Hadoop Distributed File System)를 들 수 있다 HDFS는 아파치 오픈소스 분산 화일 시스템으로 고성능 하드웨어 상에서 운영되며, 대규모 데이터를 저장할 수 있는 스토리지로 알려져 있다. 오류를 대비해 세 노드에 자동적으로 데이터를 복제하며, 이런 자동적인 데이터 복제는 백업을 필요없게 했다.
데이터베이스 기술과 관련된 기술로는 또한 HBase, Cassandra, Hive 등이 존재한다. HBase는 아파치 오픈소스인 NoSQL 분산 데이터베이스로 Hadoop 프로젝트의 일부로 개발되었다(http://hbase.apache.org/). Hadoop생태계에 구글의 Bigtable과 같은 기능을 제공하며, HDFS 위에서 구동된다. HBase는 압축, 메모리 상에서의 작동, 블룸 필터 (Bloom filter) 등 빅 테이블과 동일한 기능을 가지고 있다. HBase에 있는 테이블은 Hadoop에 운영되는 데이터 처리 기능인 맵-리듀스 (Map-Reduce)을 위한 입력과 출력으로서 역할을 한다. HBase는 전통적인 SQL 데이터베이스를 직접적으로 교체하지는 않는다. HBase는 최근 데이터의 양이 많은 다수의 웹 사이트에 사용됐다. 본 기고에서는 페이스북의 메시지 플랫폼에 사용된 사례를 다룬다. Cassandra는 아파치 오픈 소스 프로젝트로 NoSQL 솔루션이다. 처음에는 페이스북이 개발하여 2010년까지 인박스 검색(Inbox Search)을 위해 사용했다.
Hive는 데이터 요약, 질의, 분석 등을 제공하기 위해 Hardoop 상에 구현된 데이터웨어하우스 인프라다. 처음에는 페이스북이 개발했지만, 넷플릭스와 같은 다른 회사에 의해서 사용되고 개선되어왔다. Hive는 Amazon S3 화일시스템 같은 Hadoop과 호환되는 화일시스템에 저장된 대규모 데이터의 분석을 지원한다. 맵-리듀스를 완벽하게 지원하면서 HiveQL이라 불리우는 SQL 같은 언어를 제공한다.
많은 양의 빅 데이터가 있기 때문에, 데이터를 이동시키지 않고 시간과 비용을 절약하기 위하여, 원시 스토리지에서 데이터를 조직화하려는 경향이 있다. 빅 데이터 조직화를 위해 요구되는 인프라는 1) 원래 스토리지 위치에서 데이터를 처리하고 관리할 수 있어야만 한다. 2) 대규모 데이터 프로세싱 단계를 다루기 위해 대용량 처리를 지원해야 한다. 3) 비구조적인 것에서부터 구조적인 것까지 다양한 데이터 포멧을 다룰 수 있어야 한다. Hadoop은 원래 데이터 스토리지 클러스터 상에 데이터를 유지하면서 대용량의 데이터를 조직화하고 처리할 수 있는 새로운 기술이다. 예를 들어 하둡 분산 화일시스템(Hadoop Distributed File Systems; HDFS)은 웹 로그용 장기 저장 시스템이다. 웹 로그는 클러스터 상에 맵/리듀스를 사용하고 같은 클러스터 상에 집계 결과를 생성하여 브라우징 행위로 전환된다. 이 집계된 결과는 관계형 데이터베이스에 로드 된다.빅 데이터를 분석하는 데 요구되는 인프라는 1) 다양한 시스템에 저장되어 있는 다양한 데이터 유형의 통계적 분석과 데이터 마이닝 같은 더 심도있는 분석을 지원해야만 한다. 2) 막대한 데이터 양를 처리할 수 있어야 한다. 3) 행위에 있어 변화가 있으면 더 빠르게 반응해야 한다. 4) 분석적 모델에 기반한 의사결정을 자동화해야 한다. 오픈 소스 프로젝트인 R(http://www.r-project.org/)이 이런 요구에 부응하는 데이터 분석 도구이다.
본 기고에서 다루는 사례는 기본적인 빅 데이터 인프라를 사용하여 어떻게 실제 문제들을 해결하기 위하여 노력을 하고 있는지를 보여준다. 표 1은 각 회사가 도전한 적용분야, 관련 빅 데이터 요구사항, 주요 적용 기술의 요약이다.
3. 페이스북: 메시지 서비스3.1. 메시지 서비스 개요 페이스북 메시지는 페이스북에서 실제 사용 시스템에 HBase를 사용한 첫 번째 애플리케이션이다[4]. 페이스북은 2009년부터 차세대 메시지 제품에 대해 논의를 시작했다. 이 제품은 채팅 메시지, 이메일, 이전 버전의 메시지 등을 모두 하나로 통합하는 것을 목표로 하였다. 채팅 메시지는 기존의 메시지보다 20배 정도 많고, 이메일 메시지는 훨씬 더 길 것으로 예측됐다. 이전에 채팅 메시지는 메모리 상에 수 일 동안만 저장됐고, 그 외의 메시지는 MySQL에 저장됐다. 페이스북은 쓰기(write)에 있어 20배나 많은 양을 지원해야 하고, 약 한 달에 150TB로 증가할 것으로 예상되는 데이터를 위한 저렴하고 용이한 확장이 가능한 스토리지가 필요했다. 이 문제를 해결하기 위하여 페이스북은 HBase를 선택하였다. 페이스북 개발팀이 HBase를 선택한 이유는 다음과 같다. 첫째, HBase는 대용량 쓰기 처리를 효과적으로 지원한다. 둘째, HBase는 서비스 요청에 대해 매우 낮은 지연시간을 갖고. 무작위 읽기(random read)를 제공할 수 있다. 셋째, HBase는 데이터의 증가에 따라 신축적으로 대응할 수 있다. 넷째, HDFS 상에 구현된 HBase는 저렴한 디스크와 상용 하드웨어를 사용하여 비용을 절감하면서 고장 허용(fault tolerant)에 탁월하다. 다섯째, HBase는 데이터 센터 안에서 데이터의 일관성을 보증한다. 여섯째, 페이스북 개발팀은 Hadoop 과 HDFS를 사용하여 개발을 했던 풍부한 경험이 있어왔다. 3.2. 개발 세부 내용 페이스북의 개발팀은 본격적인 개발에 앞서 기본적인 HBase에 다음과 같은 기능을 보완했다. 첫째, HDFS의 트랜젝션 로그 (transaction log) 기능을 향상시켰다. 둘째, HFDS 상의 다수의 노드에 오류가 발생할 때 데이터를 잃어버릴 가능성을 줄이기 위해 새로운 블록 배치 정책 (Block Placement Policy)을 개발했다. 기존의 방법은 최소 한도로 복제본을 만들도록 제한하였으나, 새로운 방법은 한 파일의 블록 복제본을 더 작은 규모의 노드 그룹에 배치하도록 했다. 이 변화는 이전의 방법과 비교해서 다수의 노드에서 발생하는 오류의 가능성을 줄였다. 셋째, HBase의 유지보수로 인한 서비스 정지를 최소화하기 위한 점진적 업그레이드 (rolling upgrade) 기능, 온라인 스키마 테이블 변환 기능을 개발했다. 넷째, HBase는 쓰기에 탁월한 장점을 보였으나, 읽기에는 그렇지 못했다. 이에 개발팀은 HBase의 읽기 동작의 효율을 향상시키기 위해, 블룸 필터 (Bloom filters on keys), 시간 범위 힌트 (timerange hints), 검색 최적화 (seek optimization) 등의 기능을 개발했다. 다섯째, 쉐도우 테스팅 (shadow testing) 방법을 적용하여 실제 서비스 프로그렘 변환에 따라 발생할 수 있는 위험을 최소화했다. 여섯째, HBase가 새로 소개된 기술로 예상하지 못했던 오류가 발생할 수 있기에 기존의 Scribe를 사용해 HBase에 대한 백업을 수행했다.
페이스북 개발팀은 실제 서비스를 제공하며 다음과 같은 문제에 직면했으며, 이를 해결하기 위한 방법을 개발했다. 첫째, 실제 서비스가 제공되고, 데이터의 크기가 커짐에 따라 HFile의 인덱스와 블룸 필터의 효율성에 있어 문제가 발생됐다. 이 문제를 해결하기 위해 개발팀은 HFile V2라 불리우는 새로운 화일 시스템을 개발했다.
HFile V2는 비교적 고정된 크기의 블록들로 구성된, B-트리 인덱스와 유사한 다단계 데이터 구조 (multi-level data structure)를 가지며, 각 HFile 당 단일 불룸필터(monolithic bloom filter)를 더 작은 블룸으로 분할하였다. 블룸과 인덱스 블록은 HFile 내에 데이터 블록에 산재되어 있고, 필요에 따라 로드되어 데이터 블록들이 사용되는 같은 인-메모리 LRU 블록 캐시에 캐시되도록 했다. 둘째, compaction 기능은 두 개 이상의 HFile을 하나의 HFile로 변환하여 통합-정렬하는 과정으로 HBase의 성능에 많은 영향을 미치는데 페이스북의 개발팀은 이 알고리즘의 변환, 멀티 쓰래딩 등의 방법을 도입하여 효율성을 개선했다. 셋째, Scribe를 활용한 데이터 백업은 데이터의 크기가 증가함에 따라 액션 로그(action logs)의 크기가 지속적으로 증가하게 되어 비효율적이게 됐다.
이 문제를 해결하기 위해 개발팀은 HBase를 기반으로 한 새로운 백업 방법을 개발했다. 백업은 HBase 데이터 화일 백업을 위한 HFile 백업과 HBase 읽기와 쓰기 로그를 위한 HLog 백업으로 나누어진다. 이 두 기술로 인해 FFile 백업 과정의 시작과 종료 시간을 알 수 있어 적시에 복구를 수행할 수 있게 됐다. 넷째, 지속적인 서비스 수준을 모니터링하기 위한 다양한 지표들을 개발하였다(예, 컬럼 패밀리 캐시 당 히트 비율(hit ratios per column family cache), 오퍼레이션 당 N 최악의 시간(N worst time per operation), 총 디스크 사용(total disk usage)). 다섯째, 메시지 애플리케이션은 복잡한 비즈니스 로직을 가지고 있으며, 지속적으로 변한다. 비즈니스 로직의 변화에 따른 스키마의 변화는 피할 수 없다. 이에 개발팀은 이 문제를 해결하기 위한 다양한 방법을 시도했다.
처음에는 사용자의 모든 메시지를 하나의 컬럼 패밀리 (column family)에 저장하고, 가장 빈번하게 접근되는 페이지들을 표시하는 데 필요한 인-메모리 구조의 인덱스/스냅샷 (index/snapshot of the in-memory structures)을 사용했다. 이 접근법은 초기에는 변화를 추적할 수 있어 유용했으나, 스냅샷 컬럼 패밀리의 크기가 증가함에 따라 지연 요인이 됐다. 이 문제를 해결하기 위해 페이스북 연구팀은 스키마를 더 작은 부분으로 만들고, 더 자주 갱신되는 것과 그렇지 않은 것을 분할하여 관리할 수 있도록 하였다. 여섯째, 페이스북 연구팀은 또한 HBase 마스터 상에 자동화된 분산 로그 분할 (automated distributed log splitting) 기능을 개발했다. 이 기능은 모든 또는 대부분의 리전서버 (regionservers)가 정지하여 클러스터를 다시 시작할 때, 기존 쓰기 로그(write logs)를 점검하는 데 소요되는 시간을 감소하기 위해 개발됐다. 일곱째, 렉(rack)단위의 장애로 발생할 수 있는 문제를 피하기 위해 화일의 복제본이 서로 다른 렉에 저장하게 된다. 이는 렉 간의 네트워크 트래픽 문제를 유발했다. 이 문제를 해결하기 위하여 개발팀은 데이터의 위치를 관리하는 방법을 개발했다. 여덟째, 데이터 블록 인코딩 (data block encoding) 방법을 제안하여, 블록 당 더 많은 레코드를 기록하고, 쉽게 찾을 수 있는 방법을 제안했다. 마지막으로 개발팀은 서비스 운영에 따른 각종 장애 (하드 디스크 장애, 기계 장애, 네트워크 장애, 랙 장애 등)에 대한 대비책을 개발했다. 3.3. 페이스북 연구의 의의페이스북 개발팀은 HBase를 실시간 데이터 분석 (Puma), 내부 모니터링 시스템(Operational Data Store), 검색 인덱싱 (search indexing) 등 다양한 다른 에플리케이션 개발에 적용하고 있다. 페이스북의 연구는 실제적인 데이터 축적과 데이터 구조화를 수행했던 경험을 보여준다는 점에서 의미가 있다.
4. 빙(Bing): 데이터 클렌징4.1. 개요마이크로소프트의 인터넷 검색 서비스인 빙(Bing)은 지도와 쇼핑 서비스 분야의 데이터 클렌징(data cleansing)과 근접 부합 (approximate matching) 문제에 대한 빅 데이터 구축 경험을 소개한다. 마이크로소프트는 간단한 프로그램으로 특별한 도메인 (주소 클렌징 또는 제품 중복 제거 등)에 적용할 수 있는 도메인에 독립적인 데이터 클렌징 플랫폼을 개발하고자 했다 [5]. 프로젝트는 텍스트 유사도 (text similarity) 와 정보추출 (information extraction) 같은 근본적인 개념들이 많은 데이터 클렌징에 공통으로 사용된다는 점에 근거하여 시작됐다. 데이터 클렌징 플랫폼에서 개발하고자 하는 기술은 필요에 따라 변경할 수 있는 텍스트 유사도와 이에 기반을 둔 퍼지 룩업(Fuzzy Lookup), 클러스터링 오퍼레이션인 퍼지 그룹핑 (Fuzzy Grouping), 짧은 텍스트에서 구조화된 속성을 추출하는 속성 추출(Attribute Extraction)을 포함한다. 퍼지 룩업과 퍼지 그룹핑은 마이크로소프트 SQL Server 2005에 구현됐다 [6]. 이를 기반으로 빙은 빙 맵(Bing Maps)과 빙 쇼핑 (Bing Shopping) 같은 서비스를 제공한다. 이런 서비스를 제공하는 과정에서 빙은 데이터 클렌징 문제를 인지하게 됐다. 데이터 클렌징 기술의 설계가 기반을 두고 있는 두 가지 주요한 원칙은 필요에 따른 변경 가능성(customizability)과 대규모로 처리 가능한 성능 (performance at scale) 이다. 이 두 원칙은 Bing의 빅 데이터 도전에 대응하기 위해 필수적인 것이다. 4.2. 빙 맵 서비스 4.2.1. 빙 맵 서비스 개요 빙 맵은 웹 기반의 플랫폼으로 쌍방향 지도, 위성 이미지, 실시간 교통 정보, 길찾기, 업무와 연관된 수직적 포털을 포함하는 다양한 지리와 위치기반 서비스를 제공한다. 사용자들은 일반적으로 거리 주소 또는 비즈니스, 주요지형지물, 도시 또는 지역 이름 같은 특별한 관심 장소 (point-of-interest: POI)에 대한 텍스트 기반 키워드를 입력하여 이러한 서비스와 상호작용을 시작한다. 주어진 사용자 질의에 대해 시스템은 수 많은 POI 데이터와 매치시켜 가장 관련있다고 믿어지는 정보를 제공한다. 4.2.2. 빙 맵 서비스 요구사항빙 맵은 다음의 요구사항을 만족시켜야 했다. 첫째, 빙 맵 서비스는 사용자의 필요에 따른 유사도 (curomisable similarity) 서비스를 제공하여야 한다. 사용자의 질의는 비구조화된 주소, 거리명, 도시, 주, 우편번호 등을 입력할 수도 있고, 철자 오류를 포함할 수도 있으며, 서로 다른 나라 또는 지역이 서로 다른 축약어를 필요로 할 수 있다. 둘째, 빙 맵은 대규모의 데이터를 처리할 수 있어야 한다 (performance at scale). 전세계적인 POI 데이터베이스는 1억 개 이상의 엔티티로 구성되어 있다. 새로운 사람, 장소 또는 다른 엔티티들이 계속적으로 증가하고 있다. 각각의 엔티티는 텍스트를 주요 표현 매체로 가지고 있지만, 축약어나 유사어 같은 약간의 대체 형태를 가지고 있다. 시스템의 서비스는 다양한 언어와 지역에 따라 지역화될 수 있지만, 2천만 개 이상의 엔티티를 갖는 지역이 일반적이고, 어떤 근접 스트링 부합 (approximate string matching) 솔루션이든 이 규모에 적합한 고성능을 가지고 있어야 한다. 주어진 질의에 대해 퍼지 매칭은 질의가 다른 방법으로 분할될 수 있기 때문에 여러번 호출 될 수 있지만, 질의는 전반적으로 일정한 시간 내에 서비스를 제공하여야 한다. 즉 퍼지 매칭의 호출은 평균적으로 3초 안에 처리되어야 하며, 최악의 경우에도 15초를 초과하지 말아야 한다. 셋째, 서비스 제공이 낮은 메모리 사용을 유지하여야 한다. 고가용성 (high availability) 및 동적로드 밸런싱(dynamic load balanancing)을 달성하기 위해, 서비스는 사용자 데이터에 필요한 스토리지는 분리된 티어(tier)에 존재하는 비보존형(stateless)으로 설계됐다. 비보존형 모델은 가상머신 (virtual machine - VM) 이미지를 서비스에 대한 사용자의 수요 변화에 동적으로 대응하기 위해 계산 클러스터(compute cluster) 상에 복제될 수 있어야 한다. 만약 수요가 급격히 증가하면 가상머신 이미지의 새로운 인스턴스가 추가적으로 생성될 수 있다. 효율적인 로드 밸런싱을 위하여 가상머신은 메모리 사용량(memory usage)과 중앙처리장치(CPU) 파워 측면에서 고정된 용량으로 정의될 수 있다. 4.2.3. 빙 맵에 사용된 주요 기술빙 맵 서비스에 활용된 주요 아이디어와 기술은 다음을 포함한다. 첫째, 빙 맵은 변환 룰 기반 셋 유사도 (transformation rule based set similarity)를 사용하였다. 변환룰은 (context, production)의 쌍으로 구성되어 있다. 여기서 프로덕션(production)은 lhs → rhs 형태를 갖는다. 컨텍스트(context), lhs, rhs 는 문자열이다. lhs는 항상 값을 가져야 하지만, rhs는 값이 없을 수 있다. 컨텍스트가 없는 프로덕션은 컨텍스트에 제한이 없는 변환(context-free transformation)이라고 불리우고, 프로덕션만 룰로 사용된다. 다음은 변환 룰의 예이다.
IL → Illinois ACM → Association for ComputingMachinery (33027, SW 154th Ave → Lacosta Dr E)
변환 룰을 기반으로 Bing Map 서비스는 유사도를 계산한다. 자세한 변형 룰과 유사도 계산법은 논문을 참조하기 바란다[7]. 둘째, 빙 맵은 Locality Sensitive Hashing (LSH) [8] 기술을 유사도 인덱싱에 사용했다. 이 기술은 주어진 유사도 임계 값 상에 모든 일치하는 항목을 찾을 것을 확률적으로 보장한다. 셋째, 빙의 연구팀은 성능을 최적화할 수 있는 다양한 방법을 시도했다. 예를 들어 참조 테이블에 인접한 토큰 쌍에 블룸 필터를 사용했다. 사전 계산과 캐싱 기술을 매우 큰 사전 단어에 대해 한 단어의 편집 거리(edit distance) 계산 같은 반복되는 작업에 사용했다. 또한 변환 룰에 나타나는 한 쌍의 레코드 사이의 유사도를 계산하기 위하여 이분 매칭(bipartite matching) 기반의 알고리즘을 적용했다. Bing의 연구팀은 Bing의 맵-리듀스 엔진인 코스모스 (Cosmos) 상에서 오프라인 퍼지 매칭이 효율적으로 수행될 수 있음을 보여주었다[9]. 4.3. 빙 쇼핑에서 속성 추출4.3.1. 서비스 개요와 요구사항빙 쇼핑은 빙 검색엔진의 비즈니스 분야의 수직적 검색서비스 (commerce search vertical)이다. 즉 사용자가 어떤 제품을 검색하면, 그 제품을 제공하는 사업자를 제안하는 모델이다. 빙 쇼핑의 핵심 구성요소 중의 하나는 서로 다른 제품 데이터 제공자들의 제품 카탈로그를 하나의 마스터 제품 카탈로그로 통합하는 마스터 제품 카탈로그 서비스이다. 이 서비스의 목적은 빙 쇼핑의 다른 구성요소를 위해 완전하고 오류가 없는 제품에 대한 참조를 제공하는 것이다. 이를 위해 마스터 제품 카탈로그는 모든 제품을 포함할 뿐만 아니라 제품 카테고리 계층, 각 카테고리와 동의어의 속성, 그리고 각 속성과 그것들의 동의어에 대한 적합한 값 등을 포함하는 분류 (taxonomy)를 정의한다. 마스터 카탈로그 서비스의 데이터 처리 과정은 분류 (categorization), 확충 (enrichment), 중복제거(de-duplication)로 구성된다 (그림 1).
[그림 1] 빙 쇼핑 마스터 카탈로그 서비스의 데이터 처리 파이프라인
분류는 제품을 빙 쇼핑의 마스터 카테고리 계층에 분류하는 것이다. 확충은 제공자에 특화된 속성을 정의된 마스터 속성에 일치시키는 과정, 제품명으로부터 속성 값을 추출하는 과정, 속성 값을 정규화하고 Null 값을 채우는 과정 등을 포함한다. 중복제거는 중복되는 것을 함께 모아 그것을 대표하는 마스터를 선택하는 과정이다.
마스터 카탈로그 서비스의 데이터 처리 과정이 충족시켜야 할 요구사항은 다음과 같다. 첫째, 시스템은 정확한 파싱(parsing)을 제공하여야 한다. 외부 데이터 제공자가 빙 쇼핑에 제공하는 데이터는 표준 데이터 형식은 없다. 많은 제품이 속성만 있는 자유 형식의 텍스트로 입력된다. 따라서 자유 형식의 텍스트로부터 속성 값을 추출해야 한다. 둘째, 속성 추출과 관련되어 정확하고 완전한 사전이 필요하다. 고품질의 사전은 속성 추출의 정확도를 증가시킬뿐 아니라 질의 재작성(query rewriting)과 패싯 검색 (faceted search) 같은 다른 기능을 지원한다. 마지막으로 대규모 처리를 지원해야 한다. 빙 쇼핑의 마스터 카탈로그는 3천만개 이상의 제품을 포함하고 있고, 매우 빠르게 증가하고 있다. 따라서 속성 추출과 중복제거는 대규모로 처리되어야 한다. 또 다른 규모의 문제는 3000개 이상의 카테고리와 각 카테고리당 44 개의 속성을 갖는 분류로 인해 발생한다. 모델 번호 같은 속성은 카테고리당 수천 개의 적합한 값을 갖는다. 완전하고 정확한 사전을 구축하는 것은 매우 큰 도전이다. 4.3.2. 속성 추출속성 추출은 제품명(예, Fuji FinePix Z200FD 10.0 MegaPixel Digital Camera - Silver)에서 제품의 속성을 추출해내는 과정이다. Bing Shopping 팀은 중요한 속성과 그것들의 특성, 예를 들어 각각의 분류에 대해 숫자 속성인지 아닌지를 정의한다. 예를 들어 제조사, 생산 라인, 모델, 해상도, 색상, 광학 줌, 디지털 줌 등은 디지털 카메라 분류용 정의이다. 속성 추출은 속성의 사전을 입력으로 받으며, 출력은 각 제품의 속성 값 쌍이다.
속성 추출은 카테고리와 수치 속성이 서로 다르다. 카테고리 속성은 사전 매칭에 의존한다. 제조사에 대한 사전은 Fuji, Pansonic, Casio라고 가정하면, 이 사전 매칭은 Fuji를 제조사로 출력할 것이다. 수치 속성은 패턴 매칭을 사용한다. 해상도 속성에 관한 패턴이 d+[.d+] MegaPixel이면, 위의 예에서 10.0 MegaPixel이 출력 값이 된다. 이러한 접근법은 1) 사전이 필요한 정보를 잘 커버해야 하고, 2) 사전이 대부분 모호한 것이 없어야 한다는 가정에 기반을 두고 있다. 사전이 모호한 결과를 출력할 경우 (예, Apple), 이를 해결하기 위한 모호성제거 (disambiguation) 방법이 필요하다. 빙의 연구팀은 룰 기반 방법을 채택했다. 4.3.3. 사전 증보사전을 활용한 접근법에 있어 많은 것을 포함하는 것이 중요하지만, 현실적으로 사전은 완전하지 않다. 수작업으로 사전을 만드는 것은 쉽지 않다. 제품명에 규칙성 (regularity) 과 반복 (repetition) 이 있어, 이를 활용해 자동으로 사전에 추가해야 할 것을 찾을 수 있다.
빙의 연구팀은 다음의 접근방법을 채택하였다. 첫째, 연구팀은 준지도 학습 (semi-supervised) 접근법을 사용하여 사전 증보를 수행한다. 앞선 예제에 대해 시스템은 표 2와 같은 결과를 생성하며, 개발팀은 이의 수용 또는 기각 여부를 결정한다.둘째, 시스템은 예제 값에 있는 수치적 부분과 상황적 부분(context part)을 반복적으로 일반화하여 새로운 수치적 속성 값을 생성한다. 예를 들어 10.0 MegaPixel은 d+[.d+] MegaPixel 패턴이 된다. 이 패턴을 사용하면, 예를 들어 8.1 MegaPixel은 새로운 속성 값이 된다. 또한8.1 MegaPixel은 다른 속성 값, 8.1MP이 유사한 상황에서 지속적으로 사용되며, d+[.d+] MP라는 새로운 패턴을 찾는 데 사용된다.
마지막으로 상관분석 (correlation analysis)을 활용하여 생성 사전에 들어갈 용어를 생성했다. 사전 용어는 종종 단일 단어로 되어 있지 않은 경우가 있는데, 이런 경우 단순한 상관분석 기법은 충분하지 않은 경우가 있었다. Bing Shopping팀은 이런 문제를 해결하기 SEISA [10] 같은 집합 확장 (Set Expansion) 기법과 필터링 기법을 사용했다. 4.4. 빙 연구의 의미많은 양의 빅 데이터가 텍스트이다. 따라서 텍스트에서 필요한 정보를 추출하는 것은 매우 도전적인 과제이다. 빙의 데이터 클렌징 연구는 특수한 검색 (지도와 상품 검색)을 위해 적용하였던 실제 경험을 제공한다는 점에서 의의가 있다. 5. 야후:선언적 기계학습 시스템5.1. 개요 야후는 대규모 데이터를 처리할 수 있는 대규모 기계학습을 위한 선언적시스템 (declarative systems)을 개발했다. 연구팀은 각각의 특별한 특성을 갖는 기계학습 업무를 위해 새로운 시스템을 개발하거나 새로운 최적화 방법을 프로그램하는 대신에 반복적인 질의(recursive queries)를 사용했다. 이 접근 방법을 채택함으로써 데이터베이스 질의 최적화 기법들이 효율적인 실행 계획을 찾는 데 사용될 수 있었으며, 결과적인 런타임 계획은 단일 통합 데이터 병렬 질의 처리 엔진 (single unified data-prarallel query processing engine) 상에서 실행될 수 있었다.
Hadoop 같은 1세대 빅 데이터 분석 플랫폼은 기본적인 맵-리듀스 프레임워크를 제공하였지만, 기계학습을 위한 필수기능은 부족하다. Hadoop은 맵-리듀스 프로그램을 효율적으로 반복하는 데 필요한 주요 기능을 지원하지 않는다. 기계학습 모델을 구현하는 개발자들은 핵심 맵-리듀스 프레임워크 외부에 반복 기능을 구현하여야만 했다. 이것은 프로그램을 더욱 어렵게 하고 결과적으로 비효율적인 프로그램을 산출했다. Pregel, Spark, Mahout 등은 이런 부족한 기능을 해결하기 위한 특별한 접근법 또는 라이브러리이다. 이들 각각은 그래프 분석 같은 특별한 업무를 지원하는 것을 목표로 한다. 한편 HaLoop, Twister, PrItr등은 맵/리듀스 내에 반복을 강조하는 것을 목적으로 하지만, 물리적 수준에서 그렇게 한다. 5.2. 기계 학습을 위한 고수준 추상화야후 개발팀은 프로그래머들이 매우 다양한 플랫폼을 작동하고 사용하는 것을 배울 필요가 없는 대규모 기계학습 접근법을 제안했다. 이를 위해 데이터베이스에서 논리적, 물리적 데이터의 독립을 위해 개념적, 논리적, 물리적 스키마를 구별하는 것처럼 다음과 같이 기계학습 시스템을 구분했다. 첫째, 사용자의 프로그램과 Datalog에 표현되는 논리적 질의 (logical query) 를 분리했다. 이것은 사용자를 논리적 프레임워크의 변화로부터 보호하는 역할을 한다. 예를 들어 Datalog 프로그램이 어떻게 최적화되는지에 대해 사용자는 신경쓸 필요가 없다. 둘째, 논리적 Datalog 질의와 최적화된 물리적 런타임 계획 (physical runtime plan) 을 분리하였다. 따라서 계획 실행 엔진에 있어 어떤 개선이든, 사용자가 그들의 작업 개선을 얻기 위해 다시 프로그램하지 않고, 자동적으로 더 효율적으로 실행되는 것을 보장한다. 5.3. 기계 학습에 대한 선언형 접근 야후 개발팀은 반복적 멥-리듀스-갱신 (Iterative Map-Reduce-Update)이라 불리우는 대체 프로그래밍 모델을 정의했다. 이는 다음의 세 가지 사용자 정의 함수 (UDF-User Defiend Function)로 구성되어 있다. map - 읽기 전용 전역 상태 값 (read-only global state value)을 부가 정보로 받아서 병렬로 모든 트레이닝 데이터 (training data) 에 적용된다.reduce - map 출력을 하나의 집계 값으로 집계한다. 이 함수는 제시된 순서와 상관 없이 결과가 동일하다.update - 결합된 집계 값을 받아서 다음 반복을 위한 새로운 전역 상태 값을 생성하거나, 새로운 반복이 필요없다는 것을 제시한다. 반복적 멥-리듀스-갱신의 런타임은 일련의 반복을 실행하고, 각각은 먼저 map을 필요한 인수와 함께 호출하고, 전역 reduce 집계를 실행하며, 마지막으로 update를 호출한다. 예를 들어 SVM, 선형과 로지스틱 리그레션 같은 기계학습은 콘백스 최적화 (convex optimization) 문제이다. 이것은 반복적 멥-리듀스-갱신 방법을 사용하여 효율적으로 해결될 수 있다. 반복적 멥-리듀스-갱신 프로그래밍 모델은 자연적으로 고수준 언어로 표현될 수 있는데, 야후 개발팀은 빅 데이터 분석을 위해 ScalOps라는 도메인에 특화된 언어 (DSL: domain specific language) 를 개발했다. ScalOps는 데이터 과학자들에게 친숙한 데이터 구조와 언어 구조체를 사용하여 명령적 코드와 선언적 코드 간의 차이를 완화했다.
기계학습은 검색 (search), 반복적 정재 (iterative refinement), 또는 그래프 계산 (graph computation) 등으로 이해될 수 있다. Datalog 프로그램은 이러한 세 측면에서 기계학습 프로그램에 매우 적합한 것으로 알려져 왔으나, 빅 데이터에 직접 적용되지는 않았다. 야후 개발팀은 Datalog가 대규모 기계학습에 적합하다는 것을 증명하였다. 다음은 Datalog에 사용된 프리디케이트 (predicate) 와 함수들이다.
train_data(Id, Datum)는 트래이닝 데이터 셋에 상응하는 외연 프리디케이트 (extensional predicate) 이다. model(J, M)은 이터레이션 J에서 글로벌 모델 M을 기록하는 내부적 프리디케이트(predicate)이다. 초기화는 초기 글로벌 모델을 리턴하는 init_model(M)을 통해 수행된다.
map(M, R, S)는 사용자 정의 함수 프리디케이트로 현재 모델 M과 데이터 요소 R을 입력으로 받아 통계치 S를 출력으로 생성한다.reduce는 집계 사용자 함수로 여러개의 레코드마다 있는 통계를 하나의 통계치로 집계를 한다. update(J, M, AggrS, NewM)은 사용자 정의 함수 프리디케트로 현재 이터레이션 J, 현재 모데 M, 그리고 집계 통계치 AggrS를 입력으로 받아 새로운 모델 NewM을 생성한다. 정의된 함수를 이용해 야후 개발팀은 반복적 멥-리듀스-갱신 프로그래밍 모델을 표 3과 같이 정의했다.
그림 2는 반복적 멥-리듀스-갱신용 Hyracks 물리적 계획을 보여준다. 상위 데이터 플로우는 HDFS로부터 입력 데이터로 로드하고, 내부 표현 방식으로 변환하며, 그것을 N개의 클러스터 기계상에 분할한다. 각각은 가능한 많은 데이터를 케시한다. 하위 데이터플로우는 이터레이션 단계와 관련된 계산을 수행한다. 드라이버 (Driver) 는 초기 글로벌 모델을 시작하고, 각 이터레이션을 스케줄링하는 역할을 담당한다. 맵 단계는 최적화 수행자(optimizer)에 의해 결정된 클러스터 안에 있는 다수의 노드 상에서 병렬로 처리된다. 각각의 맵 단계는 데이터 통계치를 집계 트리(aggregation tree)의 리프 수준(leaf-level)에 참여하는 작업에 보낸다. 마지막 집계 통계치는 글로벌 모델을 갱신하고 그것을 HDFS에 저장하는 순차적 연산자(Sequential operator)로 넘겨진다. 드라이버는 이 갱신을 감지해고, 긍정적 표시가 있으면 다른 이터레이션을 스케줄링하고, 없으면 계산을 종료한다.
[그림 2] 반복적 멥-리듀스-갱신을 위한 Hyracks물리적 계획 5.5. 야후의 연구의 의미 야후 연구팀은 기계학습 과정이 쉽게 구현될 수 있는 선언적 기반을 제공했다는 점에서 의미가 있다. 즉 연구팀은 기존의 접근 방법이 가졌던 문제점을 해결할 수 있는 대안을 제시했다고 할 수 있다. 6. 링크드인의 행위 데이터 수집6.1. 개요 링크드인 (LinkedIn) 은 실시간 행위 파이프라인 (real-time activity pipeline) 구축 경험을 보고한다. 현대 웹 시스템들의 한 가지 구현 경향은 로그나 이벤트 메시지 형태로 행위 데이터를 사용하는 것이다. 이 데이터는 분석과 보고에 있어 전통적인 역할 뿐만 아니라 광고, 상관관계분석, 검색, 추천 시스템, 보안 영역에 많은 시스템의 핵심이다. 이런 시스템들은 실시간 정보를 필요로 한다.
기존에 로깅을 지원하는 다수의 시스템들이 있다. 페이스북은 Scribe를 구조화된 로깅 시스템을 오픈소스로 제공한다[12]. Flume은 또다른 오픈 소스 로깅 솔루션이다(https://cwiki.apache.org/FLUME/home.html). 야후는 데이터 파이프라인과 하둡 기반의 로그 집계시스템이 있다[13]. 이들 파이프라인은 운영과 비즈니즈 통계 매트릭을 통합하지 않았다. 야후는 실시간과 일괄소비 (batch consumption) 를 위한 분할된 인프라를 운영한다. Flume과 Scribe는 다른 시스템에 출력을 생성하기에 충분한 유연성을 가지고 있지만, 이들은 Hadoop에 로그를 로딩하는 데 더 초점을 두고 있다. 두 시스템은 모두 풀 모델 (pull model) 보다 푸시 모델 (push model) 에 기반을 두고 있는데, 실시간 소비 시나리오에서는 푸시 모델이 운영상 복잡하다.링크드인 연구팀은 기존의 일괄 처리방식에서 Kafka라고 불리우는 실시간 출판-구독 시스템 (publish-subscribe system)으로의 전환 경험을 보고한다[14]. 이 파이프라인은 현재 링크드인에서 실제 운영시스템으로 사용되고 있으며, 초당 최대 170,000의 메시지를 처리하며, 매일 100억 개 이상의 메시지 쓰기를 처리하고 있다. Kafka는 수십개의 구독 시스템을 지원하고, 매일 이 소비 처리에 550억 개 이상의 메시지를 전송한다[15]. 6.2. 기존 시스템 기존에 링크드인은 행위추적시스템과 모니터링 시스템을 사용했다. 행위추적 시스템(activity tracking systems)은 일괄처리형 시스템으로 사용자의 행위 데이터를 처리하고, 순수하게 데이터를 데이터 웨어하우스에 로딩하는 역할을 담당했다. 이 시스템은 간단한 HTTP 로깅 서비스로 구성되어 있다. 애플리케이션은 작은 XML 메시지를 직접 공표하고, 이 메시지들은 화일에 집계하기 위해 쓰여지며, ETL 서버에 복제된다. ETL 서버에서 XML 화일은 분할되어 관계형 데이터웨어하우스와 Hadoop 클러스터에 로드된다. 이 접근법은 실시간 데이터 접근이 어렵고, 데이터에 대해 오직 하나의 목적지만 지원된다. 또 다양한 XML이 다양한 행위를 지원하기 위해 쓰여지기 때문에 종종 문제를 일으키며, XML 파싱을 하는데 매우 많은 자원을 사용한다는 문제가 있다.
모니터링시스템은 서버 통계치와 로그 데이터를 다루는 시스템으로, 모니터링 시스템에만 전송한다. 모니터링 데이터는 그것이 시간 단위로 일괄처리되는 특성 때문에 행위추적시스템에 의해 관리되지 않고, 대신 애플리케이션에 JMX 후크(hooks)를 사용하여 스크랩되어, 오픈소스 기반 모니터링 툴인 Zenoss가 사용할 수 있게 한다. 링크드인에서 모니터링 데이터는 구조화된 로그와 다양한 시스템 통계를 추적하는 애플리케이션 카운터로 구성된다. 이것은 구글의 Dapper 시스템을 모델링한 서비스 레이어 내에 매우 정교한 요구 추적 기능을 포함한다. 불행하게도 이 시스템에 새로운 측정단위를 추가하고 유지보수하는 것은 수작업 과정이고 데이터는 다른 곳에서는 사용할 수 없다. 6.3. 시스템 요구사항이런 기존 시스템의 문제를 해결하기 위하여 링크드인 개발팀은 새로운 시스템을 개발했다. 시스템은 구체적으로 다음을 목표로 했다. 첫째, 데이터가 서로 다른 유형의 피드 사이에 쉽게 공유될 수 있어야 한다. 대규모 고객 웹 사이트에서 서버에 관한 운영시스템 측정단위와 서비스 성능은 비즈니스 측정단위이다. 그것은 개별 엔지니어와 운영 직원에서 이사회까지 모든 사람들이 관심을 갖는 것이다. 이것을 더 전통적인 비즈니스 측정단위로부터 분리하는 것은 시스템에 나타난 문제들을 사업 측정단위에 미치는 영향을 연계시키는 것을 어렵게 한다. 많은 유형의 시스템 문제와 버그들은 시스템 측정단위로 감지되지 않지만, 비즈니스에 악역향을 미친다. (예, 페이지 뷰의 감소, 회원 가입률 등).
기존에는 사업 측정단위를 실시간으로 얻을 수 없기 때문에 많은 유형의 문제를 감지하는 데 많은 시간의 지연이 따르는 데이터웨어하우스 ETL 파이프라인에 의존했다. 이 지연은 데이터 웨어하우스 ETL 프로세스를 지연시킬 뿐 아니라 어떤 문제를 감지하는 데 많은 시간을 걸리게 했다. 유사하게 링크드인의 운영 측정단위가 실시간 모니터링 시스템에서 캡처되기 때문에, 그것들은 용량 분석 또는 시스템 디버깅을 위한 더 심도있는 종적 질의를 위해 접근하는 것이 쉽지 않았다. 두 시스템 모두 수작업에 의해 관리되는 수 많은 정보에 의존하기 때문에 어려움이 있었으며, 양자 모두 유사한 분실 데이터를 가지고 있었다. 새로운 시도는 어떤 시스템이든 데이터 파이프라인을 통합할 수 있고, 최소의 추가적인 통합 작업으로 이들 데이터 소스가 어떤 것이든 생성 또는 소비할 수 있게 하는 것을 목표로 했다.
둘째, 연구팀은 실시간 데이터 분석을 지원하기 위하여 새로운 시스템의 도입을 검토했다. 기존 링크드인에서 데이터 분석을 위해 운영하였던 관계형 데이터 웨어하우스와 대규모 Hardoop 클러스터로 구성되었으며, 일괄처리 프로세스를 사용하여 데이터를 분석했다. 이를 달성하기 위해 연구팀은 가능한 많은 노이즈가 제거된 데이터를 실시간 피드로 이동하여, 일괄처리시스템(예, 데이터웨어하우스)이 이것을 많은 소비자 중에서 하나로서 상속받을 수 있도록 했다. 이 방법은 모든 데이터를 통합하는 조직적인 많은 문제를 Hadoop 또는 데이터웨어하우스 인프라를 보유한 중앙 팀으로부터 관련된 데이터 소스의 보유자들에 이관하여 직접 관리하도록 한다. 6.4. 파이프 라인 구현링크드인은 아파치 카프카(Apache Kafka, http:// incubator.apache.org/kafka/)를 기반으로 실시간 행위 데이터 파이프라인을 구축하였다. Kafka는 분산 게시- 구독 (distributed publish-subsribe) 메시징 시스템이다. Kafka는 전통적인 로그 집계시스템과 메시징 시스템의 장점을 결합하였다. 한편으로 Kafka는 분산, 대규모, 대용량 처리를 제공하며, 다른 한편으로 메시징 시스템과 유사한 API를 제공하여, 에플리케이션이 실시간으로 로그 이벤트를 사용할 수 있도록 한다. Kafka는 세 가지 주요한 기법을 사용하여 효과적인 처리를 개선했다. 첫째, 데이터를 분할하여 데이터의 생성, 브로커링(매개), 작업량이 증가함에 따라 점진적으로 규모를 증가할 수 있는 클러스터에 의해 관리되도록 했다. 둘째, 더 큰 메시지 덩어리를 한번에 보내기 위해 메시지를 일괄적으로 함께 전송하도록 했다 (batching). 셋째, 전송되는 데이터를 더 작게 하기 위해 압축했다 (shringking).
Kafka를 기반으로 한 데이터 파이프라인 개발과 운영 과정에서, 연구팀은 다음과 같은 문제들을 해결해야 했다. 첫째, 행위 데이터의 소스가 다양하기 때문에 다양한 데이터가 발생한다. 이에 연구팀은 다양한 데이터를 처리하는 방법을 개발하였다. 둘째, 데이터를 Hadoop에 효율적으로 로딩하는 방법을 개발했다. 마지막으로 운영적 측면에서 시스템의 성능을 향상시키고, 지속적으로 모니터링하는 방법을 사용했다. 구체적인 내용은 [15]을 참조하기 바란다.
6.5. 링크드인의 연구의 의미링크드인의 실시간 행위 데이터 파이프라인 구축에 관한 연구 보고는 실제적으로 빅 데이터를 어떻게 실시간으로 수집하며, 이를 조직내 관련자들에게 어떻게 효율적으로 배포할 것인가에 대한 접근방법을 보여주었다는 점에서 의미가 있다. 7. 구글의 양방향 지도 서비스7.1. 개요 빅 데이터 분석이란 테라 또는 페타바이트 단위의 데이터에 대한 분석을 수행하는 것을 말한다. 일반적으로 컴퓨터를 집중적으로 활용하는 것을 강조하는 접근 방법은 많은 유형의 데이터 관리에 대한 수요가 비기술적 데이터 전문가 (예를 들어 언론인, NGO, 사회 과학자, 고등학교 선생, 도메인 데이터 사용자) 라는 사실을 경시한 것이다. 이러한 사용자들은 대규모의 흥미로운 데이터에 접근하지만, 그들 자신이 시스템을 구축하거나 대규모 분석 도구를 운영할 수 있는 자원이나 기술이 없다. 그들에게 있어 빅 데이터란 많은 데이터로 뒷받침되는 설득력 있는 시각화를 통해 이야기를 풀어갈 수 있게 하는 능력이다.
구글은 Google Fusion Table (GFT, https:// developers. google.com /fusiontables/) 라는 기술을 통해 쌍방향 지도 서비스를 구현하여, 언론인들에게 제공하고 있다 [16]. GFT는 사용자들이 100MB 이상을 테이블에 저장할 수 있게 한다. GFT의 목적은 매우 짧은 지연 시간과 매우 높은 초당 질의 처리 (QPS - query per second)를 능력을 갖는 SQL 질의어를 지원한다. 일반적인 데이터 이외에도 사용자들이 점, 선, 도형 등을 지도상에 그릴 수 있는 지리 데이터를 지원한다. 사용자는 지도상에 사물의 모양과 색이 데이터에 의해 자동으로 결정되도록 표현 방법을 지정할 수 있다.
사용자가 지도를 접속하였을 때, 브라우저는 구글 백엔드 서버에 다수의 타일 요청(tile requests)을 시작한다. 사용자에게 보이는 지도는 다수의 타일로 구성되는데, 각각의 타일은 256X256 PNG 이미지이다. 사용자들은 지도를 확대/축소하거나 돌려보면서 상호작용을 한다. 각각의 행위는 더 많은 타일을 요청할 수 있다. 그림 3 은 타일 요청시 사용되는 파라미터의 예를 보여준다. table은 매핑되는 데이터 세트를 지정하기 위해 사용되고, window는 타일의 경계를 지정한다. 각 아이템의 프레젠테이션은 style 에 의해 지정된다. sql filter는 테이블의 다양한 컬럼에 대한 SQL 조건을 지정한다. 마지막으로 level of detail은 타일의 확대 수준(1~20)을 지정한다.
그림3
지도 타일 요청 파라미터
타일 응답 처리는 다음과 같이 진행된다. 먼저 공간 인덱스(spatial index) 검색으로 요청된 타일에서 보일 수 있는 목록을 결정하며, 동시에 필터 컨디션에 맞는지의 여부를 결정한다. 이를 기반으로 그것들의 형상을 어떻게 표현할 것인지를 결정한다. 요청된 스타일을 적용하면서 신뢰성의 상실 없이 꼭지점의 갯수를 감소시켜 그것들을 보다 간소하게 나타낸다. 마지막으로 공통 구글 맵 인프라로 타일을 그리게 한다. 이 랜더링 컴포넌트는 각각의 타일을 그리는데 필요한 도형과 스타일을 리스트한다. 구글의 지도 서비스는 각각의 단계를 최적화하여 구현했다. 7.2. 대규모 데이터 처리능력 확장 사용자들은 대규모 데이터로 상호작용하는 지도를 생성하는 잠재적 이익을 인식하게 되었다. 구글 연구팀은 이러한 요구사항에 대응하기 위해 처리능력 확장에 집중했다. 지도가 쌍방향이기 위해서는 타일 요청에 대해 매우 빠르게 응답하여야 한다. 실제적으로 연구팀의 목표는 매우 복잡한 형태를 가진 대규모 데이터인 경우를 제외하고 10 밀리 초 이하로 요청에 답을 하는 것이었다. 이를 위해 연구팀은 (1) 고수준으로 최적화된 인-메모리 컬럼 저장 (in-memory column store) 방법[17], (2) 타일 당 일관성 있는 공간 샘플링 방법 (consistent spatial sampling per tile)[18]을 사용했다. 7.3. 거대하고 복잡한 다각형 데이터 처리능력 확장 주어진 대형 포인트 데이터를 매핑할 수 있는 능력이 정해져 있는 경우, 유사한 복잡한 선과 다각형을 가진 지도를 지원하는 것이 필요할 때가 있다. 이런 경우에 처리 능력을 향상하기 위해 구글 연구팀은 다음과 같은 방법을 채택했다. 첫째, 타일 프로젝션 방법에 기반을 둔 선과 다각형 단순화 (line and polygon simplication) 방법을 사용했다. 둘째, 응답하는 데 많은 로그가 걸리는 경우에 이를 캐시하여 사용하는 방법을 적용하였다(Effort-based response caching 방법). 7.4. 합병에 의한 데이터 처리능력 확장 구글 연구팀은 합병 테이블(merged tables)을 생성하여 사용자들이 상이한 데이터 세트를 통합하여 새로운 것을 발견할 수 있도록 했다. 합병 테이블은 다른 테이블처럼 조작될 수 있다. 합병 테이블은 다른 사용자에게 원시자료의 부분만을 볼 수 있는 권한을 부여하여, 서로 협력할 수 있는 모델을 생성한다. 원시 자료에 대한 갱신은 병합 테이블을 변경하고, 병합 테이블에 대한 질의는 그것의 기본 테이블에 다시 쓰여지거나 처리된다. 병합 테이블은 다음과 같은 장점이 있다. 첫째, 자원 사용을 획기적으로 절감할 수 있다. 둘째, 원시자료가 서로 다른 소스로부터 생성될 때 적당하다. 마지막으로 맵핑된 데이터 세트가 갱신될 때 더 나은 경험을 제공한다는 것이다. 예를 들어 GFT가 다양한 후보자에 얻는 득표수에 의해 투표 지역구가 색칠되는 선거 지도를 위해 사용되는 경우에 적합하다. 7.5. 구글의 연구의 의의 구글 연구팀은 쌍방향 지도 서비스는 빅 데이터 분석 결과가 실제로 어떤 방법으로 사용자에게 기여할 수 있는지를 보여주는 성공적인 사례로 의미가 있다. 빅 데이터는 원시 데이터의 수집과 저장, 나아가 검색할 수 있는 측면이 중요하다. 그러나 이러한 프로세스는 분석 결과를 최종 사용자들이 유용하게 사용할 때 더 의미가 있다. 8. 분석자 결론 본 기고에서 대표적인 인터넷 기업인 페이스북, 빙(마이크로소프트), 야후, 링크드인 구글의 빅 데이터 구축 경험을 살펴 보았다. 각각의 프로젝트는 다양한 분야의 문제를 제시한다. 또한 각각의 프로젝트는 빅 데이터를 저장, 처리, 분석하기 위해 각 기업의 연구팀들이 어떻게 문제에 접근하여 해결책을 찾았는지를 보여준다.
페이스북은 방대한 메시지 처리를 위해 HBase를 이용한 시스템을 개발했다. 빙은 데이터 클렌징 기술을 수직적인 검색 서비스(예, 지도와 상품 검색)에 발생되는 문제를 해결하기 위해 이용했다. 야후는 빅 데이터의 분석이란 부분에 초점을 맞추어 기계학습을 위한 일반적 프레임워크에 대한 연구를 했다. 링크드인 로그나 행위와 관련된 빅 데이터를 어떻게 수집할 것인가에 대한 연구도 수행했다. 마지막으로 구글은 사용자 측면에서 빅 데이터 분석 결과를 어떻게 사용할 것인지에 대한 문제를 쌍방향 지도 서비스 분야에서 적용했다.
빅 데이터의 도입은 단순한 시스템의 도입이 아니다. 빅 데이터는 당면한 문제를 해결하기 위한 다양한 접근 방법이다. 이런 측면에서 본 사례 연구는 빅 데이터 시스템을 도입하려는 많은 조직들에게 문제의 발견, 해결 방안의 도출 등에 관한 많은 도움을 줄 것으로 본다.
참고문헌 1. Cooper, B.F., Special Issues in Big Data War Stories. IEEE Data Engineering Bulletin, 2012. 35(2). 2. Oracle, Big Data: A Big Deal for Public Sector Organizations. 2012.3. Manyika, J., et al., Big data: The next frontier for innovation, competition, and productivity. 2011, McKinsey Global Institute.4. Aiyer, A., et al., Storage Infrastructure Behind Facebook Messages. IEEE Data Engineering Bulletin, 2012. 35(2).5. Data Cleansing Project at Microsoft Research. Available from: http://research.microsoft.com/en-us/projects/datacleaning/default. aspx.6. Chaudhuri, S., et al., Data cleaning in microsoft SQL server 2005, in Proceedings of the 2005 ACM SIGMOD international conference on Management of data. 2005, ACM: Baltimore, Maryland. p. 918-920.7. Arasu, A., S. Chaudhuri, and R. Kaushik, Transformation-based Framework for Record Matching, in Proceedings of the 2008 IEEE 24th International Conference on Data Engineering. 2008, IEEE Computer Society. p. 40-49.8. Andoni, A. and P. Indyk, Near-optimal hashing algorithms for approximate nearest neighbor in high dimensions. Commun. ACM, 2008. 51(1): p. 117-122.9. Chaiken, R., et al., SCOPE: easy and efficient parallel processing of massive data sets. Proc. VLDB Endow., 2008. 1(2): p. 1265-1276.10. He, Y. and D. Xin, SEISA: set expansion by iterative similarity aggregation, in Proceedings of the 20th international conference on World wide web. 2011, ACM: Hyderabad, India. p. 427-436.11. Bu, Y., et al., Scaling Datalog for Machine Learning on Big Data. 2012, Cornell University.12. Borthakur, D., et al., Apache hadoop goes realtime at Facebook, in Proceedings of the 2011 ACM SIGMOD International Conference on Management of data. 2011, ACM: Athens, Greece. p. 1071-1080.13. Ahuja, M., et al., Peta-scale data warehousing at Yahoo!, in Proceedings of the 2009 ACM SIGMOD International Conference on Management of data. 2009, ACM: Providence, Rhode Island, USA. p. 855-862.14. Kreps, J., N. Narkhede, and J. Rao. Kafka: a distributed messaging system for log processing. in ACM SIGMOD Workshop on Networking Meets Databases. 2011.15. Goodhope, K., et al., Building LinkedIn's Real-time Activity Data Pipeline. IEEE Data Engineering Bulletin, 2012. 35(2).16. Madhavan, J., et al., Big Data Storytelling through Interactive Maps. IEEE Data Engineering Bulletin, 2012. 35(2).17. Gonzalez, H., et al., Google fusion tables: data management, integration and collaboration in the cloud, in Proceedings of the 1st ACM symposium on Cloud computing. 2010, ACM: Indianapolis, Indiana, USA. p. 175-180.18. Sarma, A.D., et al., Efficient spatial sampling of large geographical tables, in Proceedings of the 2012 ACM SIGMOD International Conference on Management of Data. 2012, ACM: Scottsdale, Arizona, USA. p. 193-204.
회원가입 후 이용바랍니다.
개의 댓글
댓글 정렬
BEST댓글
BEST 댓글
답글과 추천수를 합산하여 자동으로 노출됩니다.
댓글삭제
삭제한 댓글은 다시 복구할 수 없습니다.
그래도 삭제하시겠습니까?
그래도 삭제하시겠습니까?
댓글수정
댓글 수정은 작성 후 1분내에만 가능합니다.
내 댓글 모음