Monthly Archives: 11월 2014

BigData Global Big3 #3 MapR Technologies

최근 기사(2014년 10월 14일)에 다음과 같은 내용이 실려있다. 맵알테크놀로지스가 SQL온하둡 기술 중 하나인 ‘아파치 드릴(Drill)’에 대한 마케팅을 본격화했다. 오픈소스 하둡 진영 중 가장 먼저 개발을 시작하고도 후발주자에게 뒤처진 것을 만회하려는 듯 버전업데이트에 속도를 내는 모습이라고 한다. 맵알은 드릴에 대해 표준 SQL 준수를 강점으로 내세우고 있다. “제공하는 기능이나 파일 포맷의 종류도 하이브, 임팔라에 뒤지지 않는다”고 강조하고 있다.

구분 내용
회사 소개 O 홈페이지 회사소개에는 다음과 같이 서두 제목으로 되어 있다.    MAPR MEANS MORE FROM HADOOP(맵알은 하둡 그 이상을 의미한다.)

O informatica의 MapR 소개

 맵알은 보다 많은 기업 사용자들을 위해 빅 데이터를 관리 및 분석할 수 있도록 한다는 하둡의 비전을 실현하고 있다. 업계 저명한 상을 수상한 바 있는 맵알 배포판은 하둡에 대한 탁월한 신뢰성, 속도 및 사용의 용이성에 데이터 보호 및 비즈니스 영속성을 결합하여 고객들이 빅 데이터 분석의 위력을 활용할 수 있도록 지원한다. 캘리포니아주 산호세에 본사를 두고 있으며, 투자자로는 라이트스피드 벤처 파트너스(Lightspeed Venture Partners), NEA 및 레드포인트 벤처스(Redpoint Ventures) 등이 있다.

SNS 홍보 O Facebook 소개 글 MapR brings unprecedented dependability, ease-of-use & world-record speed to Hadoop & NoSQL in one unified big data platform. Check us out at www.MapR.com

O 설명

MapR delivers on the promise of Hadoop with a proven, enterprise-grade platform that supports a broad set of mission-critical and real-time production uses.…..

Customer O industry 구분(45개 고객사)

  • Adverising, media & Entertainment( 16EA, beatsmusic 외)
  • Data Warehouse (2EA, SPINS외)
  • Financial Services (4EA, Experian외)
  • Government(1EA, US government)
  • Healthcare (1EA, Leading Healthcare Organization)
  • Manufacturing(2EA, 삼성 외)
  • Oil & Gas (1EA, Leading Oil & Gas Company)
  • Retial(2EA, SPINS외)
  • Technology & Information Service (15EA, CISCO외)
  • Telecommunications(3EA, 삼성외)
Partner O 주요 파트너

  •  CISCO, Amazon, informatica, Google, HP, splunk, TATA Consultancy Service
Investors
  • Google Capital
  • LIGHTSPEED Venture Partners
  • Mayfield
  • NEA
  • Qualcomm Ventures
  • Redpoint
제품
  • MapR Distribution
  • MapR-DB in-Hadoop NoSQL
  • Add-ons
    • Apache Drill
    • Apache Spark
    • MapR Search

BigData Global Big3 #2 Hortonworks

최근 기사(2014년 11월 11일 기사 인용)에 빅데이터 핵심 기술 중 하나인 하둡 데이터 플랫폼을 주특기로 하는 호트웍스가 10일(현지시간) 미국 나스닥 기업공개(initial public offering: IPO)를 신청하였고, 골드만삭스, 크레디트 수세, RBC캐피털마켓을 주간사로 선정, 호튼웍스는 3월 벤처캐피털들로부터 1억달러 가량의 투자를 유치할 당시 기업 가치를 10억달러 정도로 인정받았다. 호튼웍스 지분 구조를 보면 야후가 19.6%, 벤처투자회사인 벤치마크캐피털이 18.7%를 소유했다. HP 등도 일부 지분을 갖고 있다.

구분 내용
회사 소개 O Hortonworks는 2011년 야후와 Benchmark Capital 23만달러 펀딩 받아 독립적인 회사를 만들었다.O 홈페이지 소개

2011년 원래 Yahoo! Hadoop 개발 및 운영 팀 엔지니어 24명이 설립한 Hortonworks는 다른 어떤 조직보다 더 많은 Hadoop 경험을 축적해왔습니다.  당사 팀 구성원은 Hadoop 개발, 즉 Hadoop 플랫폼 핵심을 설계, 구축 및 테스트하는 데 적극적으로 참여 및 리드해왔습니다. 당사는 수년간의 Hadoop 운영 경험을 보유하고 있어서 미션 크리티컬한 Hadoop 프로젝트를 지원하는 데 최적의 기업입니다.

O Hortonworks는 “오픈 소스 혁신을 중시하며 이를 중점적으로 다룹니다.”

SNS 홍보 O Facebook 소개 글 We do Hadoop.

O 설명

Hortonworks develops, distributes and supports the only 100 – percent open source distribution of Apache Hadoop explicitly architected, built and tested for enterprise-grade deployments…..

Partner O 파트너 솔루션 구성

  • HP Autonomy와 Vertica에 데이터 Batch, Interactive, Real-time 제공(HDFS, YARN)
  • Microsoft: Window and Azure 도입
  • Red Hat : Data Architecture 결합
  • SAP : SAP HANA, SAP Application, Solution에 Hadoop  연동
  • TERADATA : Service and integrate Hadoop

O 파트너사가 곧 고객이며 별도로 Customer를 구분하지 않음

O 파트너를 2가지 영역으로 구분(중복 있음)

  • Technology Partners(151 EA)
  • System Integrators(199 EA)
  • Certification(HDP 인증)
이사회 구성 O Rob Bearden(Hortonworks CEO)O Paul Cormier (Red Hat inc, President(product and Tech)

O Peter Fenton (General Partner, Benchmark Capital)

O Martin Fink (Executive Vice President & CTO, HP)

O Kevin Klausmeyer

O Jay Rossiter (SVP, Cloud Platform Group, Yahoo!)

제품 O Hortonworks Data Platform(HDP)

  • on-premise, 클라우드, window 배포 가능

 

BigData Global Big3 #1 Cloudera

최근 기사를 인용하면 Cloudera는 최근 다른 하둡기반 솔루션을 제공하는 스타트 업들을 더 이상 경쟁상대로 보지 않고, IBM이나 Teradata같은 대기업들을 경쟁상대라고 말해오고 있었다. 굳이 꼬집어 말하진 않았지만, 결국에는 Oracle, SAP, HP (Vertica)등도 경쟁상대라는 뜻이었다. 실리콘벨리의 Hadoop기반의 최고 기술력을 가진 회사 중 하나로 다양한 글로벌 회사와 손을 잡고 성장하고 있다.

※ Vertica : HP Vertica Analytics Platform(MapR파트너)을 가지고 있으며 데이터분석분야에 가장 돈을 많이 벌고 있는 기업 중 하나 이다.  

구분 내용
회사 소개 O 2009년 크리스토퍼 비시글리아(Ex-google)를 중심으로 오라클, 구글, 야후, 페이스북에서 일했던 전문가 집단들이 모여 Hadoop 기반의 솔루션을 제공하는 회사이다.
SNS 홍보 O Facebook 회사 소개 글 Cloudera is the leading provider of Apache Hadoop-based software and services and works with customers in financial services, web, telecommunications, government and other industries.

O 홍보 관련

Customer에 보면 영역이 financial을 맨 앞에 두었고, JP Morgan과 같은 회사가 고객이며, ”포춘지 선정 50개 회사와 사업 진행을 위해 추진 중”이라고 밝히고 있다.

Customer O 9개의 영역(카테고리 중복 포함, 101개 고객사) Government(11EA), Media & Entertainment(29EA), Other(6EA), Technology(20EA), Healthcare & Life Sciences(8EA), Financial Services(10EA), Retail, ecommerce & Consumer Products(4EA), Energy & Utilities(3EA), Telecommunications(10EA)

O 90개 고객 목록

 37signals, AMD, JP Morgan, ebay, Dell, GROUPON, AMD 등

Partner O 파트너 구성총 258개의 파트너를 맺고 있으며, Accenture, ARISTA, Data기반의 회사 및 Cloud 회사 등이 제휴를 맺고 있다.

O 파트너 솔루션 구성(30개사와 파트너 솔루션)

클라우데라의 기술이 파트너사의 솔루션에 어떤 부분이 포함되어 있는지 소개하고 있다. Amazon Web서비스엔 Cloudera Enterprise platform이 AWS 유연하게 구성되어 있다고 소개

 – accenture (MSP), Amazon (MSP), APPFUENT, capgemini(System integrator), Cisco (HV), Dell(HV) , EMC(MSP), HP(HV), IBM, Informatica(SV),Intel(HV), Microsoft(MSP), Microstrategy(SV), NetApp(HV), Oracle(HV), Pentaho(SV), Platfora, qlik, redhat(SV), Revolution(SV), SAP(SV), SAS(SV), sgi(HV), softlayer(MSP,IBM), splunk, syncsort(SV), tablaeau(SV), Teradata(SV), TIBCO(SV), ZoomData 

※ MSP : Managed Service Provider, SV: Software Vendor, HV : Hardware Vendor

Inventors O 홈페이지 기준 투자자

  • Intel, Accel Partners, Greylock Partners, Meritech Capital Partners, In-Q-Tel, ignition Partners, Google Ventuers, MSD Capital, T.Rowe Price
주력 O 실시간 분석, insight 분야

  • Impala 2.0 (Cloudera Product 내부)
  • CDH : Cloudera Manager를 통해 배포, 관리, 클러스터 관리

O Developer를 위한 교육과정, Developer Blog, Community

  • 개발자들이 쉽게 쓰고, 문제를 쉽게 해결 할 수 있도록 다양하게 지원
  • 한국에도 교육센터부터 운영

 

포스퀘어가 MongoDB를 선택한 이유 : Auto-Sharding

Why MongoDB
MongoDB @ foursquare / Biggest reason : Auto-sharding
포스퀘어의 Harry Harry Heymann 이 직접 발표한 동영상 , 발표자료 슬라이드

 

최근 1,000만 이용자를 돌파한 서비스인 Foursquare. Foursquare는 매일 300만 건의 checkins 과 총 7억 5천만 건의 checkins 데이터가 쌓여 있다. Foursquare 서비스의 환경은 Amazon EC2(Amazon Elastic Compute Cloud) 위에 40대의 장비, 그리고, 8 Clusters – Sharding과 Replica Sets – 로 구성된 mongodb로 가동되고 있다. Foursquare에서 mongodb를 사용한 가장 큰 이유는 Auto-Sharding (오토샤딩)이라고 한다.

Why MongoDB ? Biggest reason (by far): auto sharding

이 글에서는 MongoDB의 아래 2가지 특징 에 대해 알아보겠다.

    • Replication (Replica Sets) : 안전성과 높은 가용성(safety and high availability)을 위한
    • Auto-sharding : 분산확장(scale-out)을 위한

 

Replication, Replica Sets

기존 DB들에서 Master-Slave 구조를 통한 Replication을 제공한다. 복제를 통한 안전성과 높은 가용성을 확보했다.

1) Master/Slave Replication

Figure1_MS

 

  • 일반적인 개념의 Master/Salve Replication 구조
  • 읽기 부하 분산 : Slave들은 Read 전용
  •  단점
    • Master에 Write 부하증가 가능성 높음
    • Master Fail시 대응하기 위한 별도 조치 필요
      (예, HA구성, 멀티Node Master 구성)

 

2) Replica Sets

Figure2

 

[그림 2] Replica Sets

    • Replica set은 자동 장애 넘김 기능이 있는 Master-Slave 클러스터
    • 장애 시 자동 처리
        • 주 서버가 장애가 발생했을 경우 보조서버 중 우선 순위가 높은 서버가 자동으로 주 서버가 됨
        • 우선순위는 Priority가 0이 아닌 노드들 중 높은 순으로 선택
          동일 우선순위 일 경우 최신의 데이터 복제본을 가진 서버가 우선
        • 장애난 서버는 복구 후 보조 서버로 다시 편입
    • Priority 가 0 인 노드 : 절대 주 서버가 될 수 없음, 백업/복구 등의 용도로 사용

3) MongoDB에서 Slave 활용

    • 데이터 유실이나 마스터 노드에서 장애 발생시 요청 넘김
    • 백업
    • 읽기 부하 분산
    • 통계 등 데이터 처리용 업무 수행

 

이 경우에도 마스터 노드로의 쓰기(DB Write)부하는 줄일 수 없다.

이 쓰기 부하를 줄이기 위해 Auto-Sharding 을 통한 분산확장(Scale-Out)이 가능하다.

Auto-Sharding

샤딩(Sharding)은 데이터를 분할해 다른 서버에 나누어 저장하는 과정을 말한다. 데이터를 여러 서버에 분할함으로써,
Scale-Up을 하지 않고도 더 많은 데이터를 저장, 처리 가능하게 한다.
샤딩은 거의 모든 DBMS가 지원한다. 어플리케이션 단에서 처리, 관리하는 수동 샤딩의 어려움을 MongoDB에서는
Auto-Sharding(자동 샤딩)을 제공으로 해결한다.

1) Sharding 구조

  • 샤드 키로 설정된 칼럼의 범위를 기반으로 각각의 값에 맞는 Shard에 저장이 된다.
  •  필요 시 Shard를 추가하여 Migration 하여 확장이 가능하다.
  • 사용하는 Application 단에서는 MongoS 라는 라우팅 프로세스로만 연결함으로써 Shard의 구조에 대해서는 알 필요도, 구조변경에 따른 수정도 필요 없다.

 

Figure3_Sharding                                                                   [그림 3] Sharding 개념

 2) Sharding을 사용해야 할 때

  • 쓰기(DB Write)가 빈번할 경우
  • 현재 장비에 디스크 공간이 부족할 경우
  • 애플리케이션에 영향을 주지 않고 증가하는 부하와 데이터를 처리하기 위해 장비 추가. 즉, Scale-Out

효과적으로 MongoDB를 사용하기 위해 

Replica Sets + Auto-Sharding 구성
대용량 처리를 위한 분산확장이 가능하고 안전성과 높은 가용성 보장을 위해 Auto-sharding 과 Replica Sets 으로 구성

 

Figure4_ShardReplica [그림 4] Sharding+Replica set 구성

 

그러나, 조심해야 할 것

1) Fragmentation

2) Monitoring

  • 최선은 Monitoring : Monitoring is your friend
  • 메모리 상주 크기, 디스크 입출력 속도, 쿼리 입력/수정/삭제 비율, 클라이언트 대기열

 

NoSQL 데이터베이스 접속 시 보안 고려사항

좀 오래된 글이지만, 여전히 간과해서는 안 될 보안에 대한 리뷰글입니다.

—————————————————————————————-

리뷰 글 : http://www.infoq.com/articles/nosql-data-security-virtual-panel

Posted by Srini Penchikala on Nov 15, 2011  요약(NoSQL 데이터베이스 접속 시 보안 고려사항)기존의 RDBMS에 비해 NoSQL은 비교적 신기술에 해당하며, 보안 취약점 역시 RDBMS에 비해 더 많은 검증이 필요한 것이 사실입니다. 아래 언급된 내용 중 NoSQL이 향후3년간 집중과 관심을 받은 만큼 다양한 보안 이슈가 등장할 것으로 예상하고 있습니다. 오픈 소스 형태로 배포된 경우가 많아 취약점 역시 쉽게 노출될 것으로 보이며, 반면 문제점 역시 빠르게 해결될 것이라 예상됩니다.
전반적인 대화 내용 중, 중요한 내용을 살펴보면, NoSQL 데이터베이스는 보안측면에서 기존 RDBMS와 별 차이는 없지만, 클러스터링 측면에서는 차이가 있는 것으로 판단되며, 각각의 DBMS별로 보안정책도 다르게 적용해야 한다는 사실을 알 수 있습니다. 보안에 대한 표준은 없으나 대부분 어플리케이션(미들웨어)에서 보안관련 내용을 처리하는게, 보안관련 사항을 적용하는 일반적인 방법이라 할 수 있겠습니다. 보안에 관련된 사항을 살펴보면 

공통적으로(RDBMS, NoSQL) 주의해야 할 사항은

1. 부족하거나 잘못된 입력 검증

    • 사용자가 입력한 내용을 여과 없이 데이터베이스에게 전달할 경우 SQL injection 같은 위험에 노출될 가능성이 있습니다. 입력된 내용을 어플리케이션 단에서 적절한 검증 또는 권장되는 함수를 통해 데이터베이스로 전달하는 게 중요하다고 판단 됩니다.

2. 어플리케이션 레벨 권한 핸들링 에러
3. 인증 취약, 보안되지 않은 통신

    • 기본적으로 NoSQL의 설치 시 별다른 권한 인증 없이 동작 가능하도록 디자인된 케이스들을 볼 수 있습니다. 이는 개발 시 편리성을 제공하기도 하지만, 도메인 또는 자체적으로 별도 어플리케이션을 통하지 않고 접근이 가능한 케이스일 경우 서비스 오픈 전 반드시 인증 부분을 보완하여 적용하는 것은 필수라고 판단됩니다.

4. 암호화되지 않은 데이터에 대한 불법 접근

    • 데이터 베이스 자체가 암호화하여 저장하는 기능을 가지고 있지 않다면 중요한 내용들은 암호화를 통해 저장하는 게 올바른 선택이라고 생각됩니다. 최근 주민등록 번호와 같은 개인정보들을 암호화하여 저장되도록 방침이 정해진 것 역시 이러한 불법 접근에 대해 사전에 대비하기 위한 것이라 볼 수 있습니다. 접근 방법이 다양하여, 만약 어떠한 경우에라도 데이터가 노출이 될 경우, 암호화 된 데이터는 쉽게 접근이 불가능할 것이며, 이는 최후의 보안정책 이라고도 할 수 있습니다.

이러한 공통적인 요소 외에도 NoSQL 제품들의 보안 취약성들이 존재합니다.

 

NoSQL측면에서 특별히 강조되는 부분을 살펴보면

1. 데이터베이스 종류에 따라 서로 다른 보안이 필요

    • 아래 내용에서 Cassandra, MongoDB, CouchDB는 서로 다른 인증방식을 취하고 있으며 심지어 같은 제품이라 하더라도 버전별 다른 기능을 제공합니다. 이러한 점에서 각 DB별 제공하는 보안기능을 미리 확인한 후 도입여부를 결정하는 것이 적절하다고 판단됩니다.

2. 대부분의 NoSQL은 injection공격에 노출될 가능성이 있음

    • 일반적으로 NoSQL은 injection 공격에 취약하지 않다는 견해가 있는데, 이는 잘못된 견해이며, 어플리케이션 구현단에서 적절히 대처를 해야 합니다. NoSQL injection을 회피하기 위한 방법 중 하나로 권장함수 사용을 권하고 있습니다.

3. NoSQL 향후 3년 이내 다양한 이슈 발견 예상

    • RDBMS는 오랜 기간에 걸처 안정화 됐으나 지금까지도 보완강화를 위해 꾸준히 업데이트 중이며 반면, NoSQL경우 태생 자체가 오래 되지 않아 수많은 검증이 필요하다고 판단됩니다. 이 부분은 꾸준히 업데이트를 통해 문제점을 보완해 나가야 하며 MongoDB의 상용 버전과 같은 지속적으로 업데이트 가능한 제품을 선택하는 것도 최초 선택 시 중요한 사항이라고 생각 됩니다.

4. 클러스터 보안점 취약

    • 샤딩, 리플리케이션, 클러스터링등 NoSQL자체가 대량의 데이터를 처리하기 위해 디자인된 많큼, 표면적으로 기존 RDBMS와 비교해볼 때 많은 부분이 노출되어 있다고 볼 수 있습니다. 또한 클러스러링 환경 자체가 속도나 퍼포먼스에 치중한 많큼 상대적으로 보안관련 기능이 취약 할 수 있으며, 이러한 특징을 잘 이해 할 필요가 있습니다.

이러한 보안 이슈를 해결하기 위해 일반적으로 권장되는(표준화된) 방법은 없으며, 주로 미들웨어에 접근에 관리기능을 포함하여 개발이 진행되는 경우가 많습니다. 이럴 때 사용 할 수 있는 대표적인 미들웨어 는(자바 환경 일 경우)

1. JSSA(Java Authentication and Authorization Service)프레임웍
2. 스프링보안 프레임웍,
3. 아파치 Shiro 프레임웍,
4. J2EE프레임웍 등.

등이 존재하며 꼭 위의 프레임웍을 사용하지 않더라도 해당기능을 대치 할 수 있는 기능으로 사용하셔도 무방할 것으로 판단 됩니다.

There is No Security in NoSQL(NoSQL에 보안은 없다)

첫번째 문서로 뭔가 부족하다 싶어 인터넷을 뒤적이던 중 관련된 내용이 있어 첨부합니다. 보안 기능의 완성도가 떨어지는 NoSQL이 이미 사용되고 있는 부분에 대해 약간 부정적인 시각으로 바라보는 경향이 있는 것으로 보이나 읽어볼 가치는 있다고 생각합니다. 두번째 문서내용은 Cassandra 와 MongoDB의 보안에 대한 내용으로

두개의 데이터베이스에 대한 주요 문제점을 정리하면

    • 데이터 파일에 대한 암호화의 부족
    • 클라이언트와 서버, 그리고 서버간 미약한 인증
    • 세밀한 권한인증 과 롤기반 접근제어에 대한 기능 지원 없는 매우 간단한 인증
    • 그리고 SQL Injection과 DoS 에 대한 취약점

으로 결론 지었습니다. 아래 표를 기반으로 두가지 NoSQL의 보안관련 사항에 대한 현재 상태와 권장사항을 보실 수 있습니다.

 

카산드라의 권장 사항(0.8.x기준)

Category Status Recommendations
Data at rest 비암호화 OS 레벨의 메커니즘과 함께 보호되어야 함
Authentication 이용 가능한 솔루션이 없음 IAuthentication 커스텀 하여 적용 필요
Authorization 컬럼 패밀리 단위의 이용 가능한 솔루션이 없다 IAuthority를 커스텀 하여 적용 필요
Auditing 쉽게 사용 불가 인증과 권한 솔루션의 부분으로 적용
Intercluster network communication 암호화 이용 가능 사설 인증 기관 사용
Client communication 암호화 이용 불가 알려지지 않은 호스트로부터 연결을 차단하기위해 패킷 필터 룰을 적용, Thrift 0.6 내의 SSL 전송을 사용하기 위해 Thrift 서버측을 재구현Thrift 서버측 안의 연결을 위한 타임아웃 추가와 연결 가능한 클라이언트 수의 제한
Injection Attacks 카산드라 쿼리 랭귀지(CQL)를 통해 가능 자바 드라이버를 사용한다면, 어플리케이션 안에서 항상 입력 검시 Statements 보다PreparedStatements 를 사용. 항상 어플리케이션의 입력을 검증

 

몽고디비의 권장사항(버전정보 없음)

잠깐 몽고 디비의 설계 원칙을 들여다보면 “몽고 디비 설계자들의 첫번째 관심사는 보안이 아니다 그결과로 디자인 자체에 몇개의 홀이 존재한다.” 라고 표현되어 있습니다. 이것은 어찌보면 당연할 수 있습니다. 사용자에 의해 선택되지 않았다면 보안적인 내용을 거론할 필요 조차 없을 것이고, 선택될 수 있는 최우선 사항이 가용성과 확장성인 만큼, 보안은 순위에서 밀려 있는 상황이며, 이것은 어찌 보면 최초 설계에 있어 사치일수도 있습니다. 그러나 결국 보안이슈는 “어플리케이션이 통과해야만 하는 마지막 관문이지 않을까” 라는 생각이 드는 문구였습니다.

Category Status Recommendations
Data at rest 비암호화 OS 레벨의 메커니즘과 함께 보호 되어야 함.
Authentication for native connections 샤드 되지 않은 상태만 이용 가능 만약 가능하면 사용.
Authorization for native connections 샤드 되지 않은 상태에서 읽기/읽기쓰기/어드민 적용 만약 가능하면 사용, 활성화된 인증 요구하라.
Auditing 이용 불가
AAA (authentication, authorization, auditing) for RESTful connections 사용자와 퍼미션이 외부로 연결 된 상태로 유지됨. 만약 리버스 프록시로 조정 가능하면 이용 가능.
Database communication 암호화 이용 불가
Injection Attacks 자바스크립트와 문자결함을 통해 가능 어플리케이션이 사리에 맞는 입력검증을 하는지 확인하라

 

이상으로 두개의 문서에 대해 간략하게 NoSQL의 보안상 특징들을 알아봤습니다. 주목할만한 내용 중 하나는 Ben-Gurion University Team (BGU)그룹이 2011년 11월에IEEE TrustCom-11” 에서 “Security Issues in NoSQL Databases” 라는 주제로 발표하였다고 합니다. 그들의 의견이 어떠한 지 한번 읽어 보는 것도 가치가 있다고 생각됩니다.

So What If You Have Big Data? Without Data-Driven Processes And Products, It’s Useless

좀 오래된 글의 번역이지만, 지금 이 시점에도 의미 있는 글이기에 공유합니다.


“설령 당신에게 빅데이터가 있다 한들,

데이터에 기반한 프로세스와 솔루션들이 없다면 아무데도 쓸데가 없다.”

Editor’s note

JOHN DE GOES, CEO of Precog,  analytics platform for developers, 회사는 미국 콜로다도주 볼도(Boulder)에 위치함.

    image2012-12-20+14_16_38 

 

 

▶ 내용 요약

  •  원문에 내용 대부분이 제목 한줄로 요약이 됩니다.
  •  데이터를 가지고 있어도 데이터 기반으로 처리하고 제품을 만들어 활용하지 않으면 쓸모가 없다는 내용이 주입니다.
  •  Data 자체 보다는 Data-Driven이라고 이야기를 주로 하며, Data를 그대로 놔둘거면 그냥 폐기하라고 합니다.
  •  Data-Driven은 21th의 화폐라고 이야기 하고 있으며, 중요성을 계속적으로 강조합니다.
  •  그 만큼 데이터기반의 제품의 변화를 통해 얻게 되는 추가 수익이 상당하니 놓치지 말라고 하고 있습니다.

 ■ Data-Driven Procesess 주요 내용

  • 데이터 사이언티스트가 하는 일에 대한 내용입니다.    
  • 좋은 데이터사이언티스트는 당신이 하고자 하는 모든 것에 대해 도움을 주는 것이다. 당신의 제품중에 무엇이 먹히고 무엇이 안 먹히는지 (Zynga사용), 
  • 당신의 주변 친구들을 통해 미래예측모델을 만들고, 당신이 오늘 더 나은 결정을 할 수 있도록 도움을 줄 수 있다. (WalmartLabs에서 사용)

■ Data-Driven Products 주요 내용

  • 당신이 만드는 제품의 기능을 향상하는데 데이터를 이용하라는 내용이며, 사례에 대한 내용입니다.

■ 데이터를 통해 돈을 벌고 싶은 사람들에게 역자의 조언 키워드

  • Capture everything centrally 
  • Get yourself a data scientist
  • Productize your data

그리고 마지막으로 “Big data isn’t about the data “

 빅데이터는 그냥 데이터에 대한 것이 아니며, 비지니스 즉 돈이라고 합니다. 


 원문 해석

* 주의: 발번역인 관계로 원문 의미랑 약간 다를 수 있으니 참고해주세요. 이상한 해석이 발견되면 수정해주시면 감사하겠습니다. 
요즘은 힘들게 빅데이터를 찾을 필요가 없다.

작게 시작하더라도 하루에 gigabyte를 만들 수 있고, 인스타그램과 같은 회사는 하루에 500T정도는 쉽게 만들어내고 있습니다.

당신과 같은 많은 회사들은 계속 커가는 데이터 산 꼭대기에 앉아, 머리를 긁적이며 놀라서 Okay, 내가 빅데이터가 있는데 이제 무엇을 할 수 있지?” 라고  나처럼 말할 것입니다.

당신은 데이터를 갖고 있다고 해서 골드메달을 딸 수 없으며, 진정한 승자는 아마존, 넷플릭스와 같이 그들의 데이터를 통해 경쟁에서 더 나은 장점을 찾는 것입니다.

데이터를 통해 수익을 낼 수 있는 플랜으로 바꾸게 될 일이 없다면, Hadoop 이나 저장되어 있는 Petabyte의 데이터를 폐기하는 게 나을 것이다.

반면 만약 당신이 당신의 데이터가 경쟁에서 장점을 활용할 수 있는 방안을 찾는다면 아마존과 넷플릭스와 같은 순위에 함께 할 것입니다.

자, 당신의 데이터를 현금으로  변환하는걸 어떻게 시작할 수 있을까요?

대부분의 기업은 다음과 같은 두 가지 방법으로 그들의 광범위한 데이터자산을 이용해 경쟁우위요소를 생성한다:

data-driven processes and data-driven products

image2012-12-20 14-21-47

 

Data-Driven Processes

빅데이터시대에, 비즈니스 분석가가 엑셀로 방정식을 입력하고 Sql 데이터베이스에서 ad hoc 쿼리를 수행하여도 자르지 않습니다.

새로운 시대는 스몰과 빅 데이터세상 둘 다에서  유능하게 툴들을 사용하는 능력을 가진 새롭고 대담한 Data 탐험가를 요구합니다.

데이터사이언티스트라고 불리는 요즘 세대는 data에 대해 전통적인 BI툴, Query language, Statistics, 기계학습을 충분히 알고 있느냐로 차이가 있을거라고 인지하는데 이런 생각은 위험합니다.

좋은 데이터사이언티스트는 당신이 하고자 하는 모든 것에 대해 도움을 주는 것이다. 당신의 제품중에 무엇이 일을 하고 안 하는지(Zynga사용),

당신의 주변 친구들을 통해 미래예측모델을 만들고, 당신은 오늘 더 나은 결정을 할 수 있도록 도움을 줄 수 있다. (WalmartLabs에서 사용)

여기 데이터사이언티스트가 당신을 도울 수 있는 몇 가지 구체적인 사례가 있습니다.

 만약 당신이 SaaS application을 판다고 한다면, 데이터사이언티스트는 높은 수익을 내는 사용자들의 일반적인 특성과 유사성을 찾는데 도와줄 것입니다.

예를 들어 데이터사이언티스트는 유료 계정으로 전환하는 특정 경로를 확인하고, 인구통계학적 속성(성별, 수입, 위치, 연령대, 등)과 제품을 사용하는 특정방법 등을 공유합니다.

이런 인사이트는 광고, 마케팅, 제품을 수정하고 수입을 증가시키는데 도움이 됩니다.

■ 데이터사이언티스트는 하나의 가격대가 갖는 범위가 무엇인지, 다른 가격대나 제품을 통해서 재구매세일 제품을 식별하고, 당신의 최적 가격전략과 제품라인을 최적화하는 것을 가능하게 합니다.

  데이터사이언티스트는 과거 데이터를 바탕으로 예측 모델을 구축 하여 상당히 정확한 예측을 만들 수 있습니다.

  예를 들어 고객을 식별할 수 있습니다. 여성과 임산부, 특정 타겟 대상, 또는 판매라인을 바꾸고 어떤 수준까지 변경가능한지 식별이 가능합니다.

 데이터사이언티스트는 당신의 데이터 대한 궁금증에 대한 정확한 질문을 파악하는데 도움이 줄 수 있습니다.

 예를들어, 데이터사이언티스트는 마케팅 데이터, 웹로그 데이터, 거래데이터, 마케팅 홍보 뒤에 투자수익에 대한 연관성을 제시할 수 있습니다.

Data-Driven Products

한편 데이터를 활용한다는 것은 당신의 비즈니스처리방안을 데이터기반으로 운영하고, 당신이 만드는 제품의 기능을 향상하는데 데이터를 이용합니다.

(그러나 모든 제품에 적용하지는 마라 예를 들어 칫솔이나 베개에는)==> 왜 안될까요?

어떤 기업은 이미 패키징데이터를 통해 유용하고, 통찰력 있는 제품을 만들었고 그들은 다른 기업들에 판매할 수 있습니다.

트위터는 반면에 데이터제품을 스스로 만들지 않고, 트위터 데이터의 라이선스는 DataSift와 같은 공급자에 있으며,

데이터 제품을 생산하기 위해 이동하고 기업은 인사이트를 제공하는 데이터를 넙적 받아 먹습니다

어떤 미디어 기업은 그들의 오디어 시청자 데이터를 제품에 담아 패키징하고 그들은 채널 PD나 컨텐츠 생산자에게 판매하는 것으로 전환했습니다.

메이저 기업들은 데이터기반의 제품을 만들었으나 순수 데이터 제품을 만들거나 팔지 않고, 그들은 직접 또는 간접적으로 추가수익을 내기 위한 몇 가지 방안은 기존제품을 더 효율적이고,

지능적 또는 통찰력 있게 만들기 위해 데이터를 이용합니다.

여기 몇 가지 데이터를 기반으로 기존제품에 통찰력 있고, 지능적인 요소를 이용한 실제 사례가 있습니다.

광고 플랫폼은 개인에게 어떤 광고를 보여줄지 선택해야 합니다.

  위치기반 광고는 광고 스스로 무엇을 보여줄지 알고 있으며 사용자에게 광고를 보여주고, 클릭이나 수익을 내는 사용자 행동에 대한 확률을 통해 주문은 극대화됩니다.

■ E-커머스 앱은 지능적인 제품 추천을 통해 사용자의 구매를 확률을 극대화하고 무엇보다도, 닥치는 대로 사거나 사지 않은 것이 무엇인지 알 수 있습니다.

■ 출판사는 개인화된 단일 페이지를 모든 사용자를 위해 만들었고, 이를 기반으로 사용자들이 출판사 사이트에 머무르는 기회를 얻게 되었고 더 많은 광고수익을 얻게 되었습니다.

■ 비디오플랫폼은 모든 사용자의 interaction을 수집 했고, 자세한 분석 내용을 콘텐츠 제작자에게 공급했고 그들의 중요한 통계를 최적화 하는데 도와주었습니다.

  이번 예는 간접적 수익을 창출하는 사례이며. 데이터 기반의 요소를 추가하는 플랫폼을 사용자에게 더 매력적으로 만들 수 있는데 도움이 됩니다.

You Too Can Be Data-Driven

data-driven processes and data-driven products에 대한 내 설명에 당신이 군침을 흘리지만 당신은 여전히 무질서한 데이터의 산에서 현금을 어떻게 가져올 수 있을지 궁금해하며, 내가 당신이 시작할 수 있도록 몇 가지 구체적 사례를 제공하여 도울 수 있습니다.

Capture everything centrally. 

지금은 스토리지가격은 떨어지고 언제 어디서나(무료로) 빅데이터를 저장할 수 있으므로, 만약 당신이 모든 데이터를 저장하지 않는다면 그건 뭔가 잘못하고 있는 것입니다.

나는 종종 기업들에게, 당신들이 가지고 있는 데이터를 무시할 수는 있지만, 가지고 있지 않은 데이터는 애초에 분석할 수도 없다고 말합니다.

비정형 또는 세미정형 데이터를 원형 포맷으로 쌓아놓는데는 큰 돈이 들지 않고, 단지 그것으로부터 구조를 찾아낼 때 비로소 돈을 쓰게 됩니다.

그러므로 당신이 얻을 수 있는 그 어떤 것 거래내용, 상호작용, 행동에 대한데이터, 센서데이터, 사용자 일반적인 컨텐츠, 로그파일 등 모든 것을 저장하지 않는다는 변명은 안됩니다.

Get yourself a data scientist. 

만약 당신이 시작하게 된다면 적어도 한 명 이상의 데이터사이언티스가 필요하거나 누군가는 데이터사이언티스트 일을 겸해야 합니다.

만약 기업이 크다면, 팀이 필요한데, 새로 데이터사이언티스트를 고용하는 것보다 회사내부에서 교육을 하는 게 비용도 낮고 쉽습니다.

데이터사이언티스트는 훌륭한 비즈니스분석가나 또는 훌륭한 BI나 Sql을 통해 교육할 수 있습니다.

데이터사이언티스트는 기업의 전체 데이터에 자유롭게 접근할 수 있어야 합니다. 그리고 특별한 질문에 답을 찾을 수 있고, 탐색적 데이터마이닝을 수행하고, BI팀을 서포트 하고 데이터 상품화하는데 도움을 줄 수 있도록 적합한 툴과 장비를 갖춰줘야 합니다.

훌륭한 데이터사이언티스트는 당신의 과제를 수행하기에 필요한 적절한 질문을 찾는데 도움을 줄 수 있습니다. 그 또는 그녀는 역시 당신의 회사의 데이터를 활용하는 새로운 방법들을 찾을 것입니다.

Productize your data.

어떤 기업도 특화된 데이터가 있다면 신규 상품을 만들거나 데이터기반의 요소를 상품에 포함하는 것을 강하게 고려해야 합니다.

모든 기업은 데스크탑, 모바일 웹, 서버 또는 미디어 기반의 어플리케이션이 있고, 특화된 데이터를 가지고 있습니다. (요즘과 같은 데이터의 시대엔 대부분의 기업은 특화된 데이터를 가지고 있다.)

기업은 특히 광고나 소매에 대해 데이터를 이용한 지능적인 기능을 그들의 어플리케이션에 이용하여 수백만 심지어 수억 달러의 추가수익을 남겼습니다.

만약 당신이 B2B SaaS 벤더라면 데이터를 제품의 기능으로 변환할 수 있는 간단한 방법으로 당신의 고객에게 고객의 서비스 레포팅을 제공하십시오. 간접적인 추가수익이  생깁니다.

만약 당신이 E-커머스 플랫폼이 있다면, 추천과 개인화를 위해 모든 데이터를 이용하면 상당한 수익증대를 얻을 수 있습니다.

만약 당신이 사용자 어플리케이션이 있다면, 어플리케션을 좀더 스마트하게 만들기 위해 데이터를 이용하면 고가용성과 더 많은 가입을 이끌 수 있습니다.

데이터 Productization을 향한 그 첫 번째 단계는 데이터 자산으로부터 생성 가능한 제품과 기능이 무엇인지에 대해서 생각하는 직원을 갖는 것입니다.

하지만 궁극적으로 제품과 기능에 데이터를 포함하도록 변환하려면 엔지니어링 자원이 필요합니다.

 The Data-Driven You

빅데이터는 데이터에 관한 것이 아닙니다.

그것은 데이터를 활용해 당신의 비즈니스를 발전시킬 방법을 찾는 것입니다.

지난 몇 년 동안 데이터과학의 눈부신 성장은 데이터가21세기의 통화($)라는 사실을 선언합니다.

만약 당신이 당신의 데이터로 아무것도 하지 않고 있다면 당신은 경쟁에서 이미 심각하게 불리한 조건에 있습니다. 하지만 간단한 몇가지, 예를 들어 당신이 가질 수 있는 모든 데이터를 수집하고, 물론 최소한 한 명 이상의 데이터사이언티스를 갖고 데이터 Productization을 향한 일을 하기만 해도, 이런 최소한의 지출은 당신의 데이터웨어하우스에 현금을 가득 채워줄 것을 확신할 수 있습니다.


Cassandra Data Modeling Best Practices, Part 2

앞의 글 “Cassandra Data Modeling Best Practices, Part 1“에 이어 Part 2 번역글 입니다.

들어가기전


원문 : http://www.ebaytechblog.com/2012/08/14/cassandra-data-modeling-best-practices-part-2/

지난 번(Cassandra Data Modeling Best Practices, Part 1)에 이어 Best Practices Part 2에서는 Cassandra 특성에 기반한 설계를 중점적으로 다루고 있으며, 다음과 같이 요약할 수 있습니다.

    • Cassandra column name은 물리적으로 정렬되어 저장되는 특징이 있으며, 이를 잘 활용한다면 범위검색 시 이점이 있음.
    • Wide rows를 사용하면 그룹화된 데이터를 단 한번의 조회로 엑세스 가능 (단, 요청된 데이터는 메모리에 적재 되기 때문에 하나의 row에 대한 사이즈 조절이 중요함)
    • Row 하나는 물리적으로 분리되어 저장될 수 없기 때문에 너무 큰 사이즈는 병목의 원인이 될 수 있음.(클러스터간 하나의 row를 분리하여 저장할 수 없음.)
    • Key 선택은  네트웍 트래픽을 효율적 분산을 위해 중요함.
    • 수퍼컬럼은 2차 인덱스 사용이 어려우며, 복합컬럼의 사용이 나은 선택.
    • 특징과 용도 및 목적에 맞게 사용하여 속도와 성능에 주의 (counter column family(CF)의 대체키 사용)
    • 데이터 생성 및 업데이트 가능여부 고려하여 적용
    • 멱등형(동일한 결과값이 나오는) 구조로 설계가 필요하며, 멱등형 구조가 수용할 수 없는 기능의 경우 counter column family 와 같은 대체 기능 활용 방안 추천 내용별로 Cassandra의 특성을 고려하여 어떻게 하면 효율적인 설계가 가능한지 적절한 예를 들어 설명 하고 있습니다.

Cassandra를 사용 하지 않더라도 분산형 데이터베이스들은 유사한 특징을 지니고 있어 다른 데이터베이스 설계 시에도 도움이 될 것이라 예상됩니다.

Cassandra Data Modeling Best Practices, Part 2


 in Data Infrastructure and Services

 Part1에서, Cassandra 초기 데이터 모델링 시 도움이 될 만한 몇 가지 기초적인 사례를 예제와 함께 살펴 보았습니다.

Part1을 무시해도 상관 없지만, Part2 용어와 규칙들을 이해하기 위해서라도 간략하게 읽어보길 권고 합니다.( 만약 Cassandra가 처음이라면 part1을 읽어보길 바랍니다.)

예제 중 일부는 차후에 좀더 다루어질 예정이며, Jira를 통해 진행 상황을 확인하실 수 있습니다.

아래는 주제별로 요약된 내용입니다.

    • 데이터 저장 시 column name을 사용하라
    • ordering, grouping, and filtering 을 위해 적절히 wide rows를 사용하라
    • 적합한 (로우키)샤드키를 선택하라
    • 트래픽에 따라 데이터를 분리하라
    • 컬럼키와 로우키가 유니크인지 확인하라
    • 적절한 비교와 유효성 검사를 사용하라
    • 컬럼명을 짧게 유지해라
    • 멱등 형태로 데이터 모델을 디자인하라
    • 트랜젝션을 고려하여 데이타를 설계하라
    • front 에서 적합한 TTL을 셋팅하라
    • 대리 키를 생성하기 위해 카운터 컬럼 페밀리를 사용하지 마라
    • 수퍼컬럼 보다는 복합컬럼을 선호하라
    • 복합 컬럼 내의 서브 컬럼의 정렬 기법을 활용하라
    • 매뉴얼 구조 보다는 built-in 복합 타입을 선호하라
    • 동적 구조 보다 정적인 복합 타입을 사용하라

Storing values in column names is perfectly OK


Cassandra에 실 데이터 저장을 column value 가 아닌 column name 를 사용하여 저장할 수 있으며, null 을 허용합니다. 이러한 방식을 사용한 주된 이유는 column name기반의 물리적인 정렬 저장이 가능하지만 column value는 이러한 정렬 저장을 지원이 것이 불가능하기 때문입니다.

 Notes:

    • column key는 최대 64KB까지 사용 가능하지만, 아이템 설명과 같은 형태는 column key로 사용하지 않기를 바랍니다.
    • timestamp 는 서버간 쓰기 시에 충돌의 우려가 있으니 timeuuid를 사용을 권장합니다.
    • column value의 최대 사이즈는 2GB 지원하지만, 스트리밍 구조는 수용할 수 없으며, 요청될 때 힙메모리로 올라가니 되도록 몇 메가 사이즈로 제한해서 사용하시길 바랍니다.
      (대용량 사이즈는 아직 지원될 예정이 없다고 합니다.  Astyanax 클라이언트 라이브러리를 사용하면 지원 가능)

Leverage wide rows for ordering, grouping, and filtering


정렬, 그룹, 필터 기능을 위해 적절한 wide rows를 사용하되, 지나칠 정도로 사용은 피하는 게 좋습니다.

이전 내용을 바탕으로 계속 설명하자면, 실 데이터가 컬럼명에 저장 될 때 wide rows 사용하게 됐습니다.

Benefits of wide rows:

    • 물리적 정렬을 지원하는 컬럼명 기반으로, wide rows 사용시 그 속성을 그대로 사용 가능하며, 정렬된 데이터 특성상 효율적인 필터링이 가능하고(범위 조회) 각각의 컬럼들에 대해 효율적인 조회가 가능합니다.
    • 만약 조회된 데이터 수가 많을 시, 효율적으로 재 읽기가 가능한 하나의 wide row를 사용해 한번의 조회로 그룹화 할 수 있습니다.
    • 하나의 예로, 시계열 데이터에 대한 추적 또는 모니터링을 위해 시간/날짜/서버/이벤트 타입을 하나의 wide rows를 사용하여 그룹형태로 처리 가능합니다.
    • 하나의 row를 (나중에 논의될) 수퍼컬럼 또는 복합컬럼을 기반으로 생성시 좀 더 그룹화된 형태도 가능합니다.
    • Cassandra에서 wide rows Column family(CF)은 (복합컬럼과 같이) 인덱스를 생성하기 위해 많이 사용됩니다.
    • 덤으로, 하나의 wide rows는 데이터 중복을 피해 1:N 관계의 비정규화를 표현할 수 있습니다.
      하지만 읽기에 대한 퍼포먼스 튜닝이 필요하면서 데이터가 함께 조회될 시만 사용하시길 추천 합니다.

Example:
어떤 이벤트 로그 데이터를 저장하고 매시간 단위로 검색 된다고 가정해봅시다.

로우키가 그날의 시간으로 구성된 아래 예제에서 컬럼명은 이벤트가 일어난 시간으로 구성되고 컬럼값은 payload를 저장합니다.

염두해야 할 사항은, row는 넓고 이벤트 컬럼명은 정렬 저장속성에 의해 시간 기준으로 정렬되 있는다는 점입니다.

wide rows 단위(이 예제에서, 몇분 단위보단 시간당)는 사용된 케이스, 트레픽, 데이타 사이즈에 의존적이며, 이 부분은 나중에 다시 논의하도록 하겠습니다.

12

하나의 row 노드들간 분리되어 저장될  없기 때문에 너무 크지 않도록 조절이 필요합니다:

어느 정도의 길이가 wide row로 정의될 수 있는지 각 케이스마다 다르기 때문에 명확히 정의하는 것은 어렵습니다. 그렇지만 몇 가지 조언을 하자면:

Traffic: 모든 트래픽은 어떤 하나의 노드 또는 샤드(정확하게 말하면 하나의 리플리카 셋)로 구성된 어떤 하나의 row와 관련 되어 있습니다.

 “fat” 한 row 는 클러스터 내부에서 병목을 유발 할 수 있으며, wide row를 하나로 조합시 row 수가 클러스터 사이즈 보다 작거나,  일부 row들이 다른 곳에 비해 비대해질 때 역시 병목이 발생할 수 있습니다.

그래서 클러스터간 로드 밸런싱은 어떤 로우키를 선택하는가가 중요합니다.

다르게 말하면, 로우키는 하나의 row에 대한 범위를 정의하면서 로드 밸런싱은 디자인 시 지속적으로 염두해 두어야 합니다.

Size: 하나의 row는 노드간 공유가 불가능 하기 때문에, 하나의 row에 저장되는 데이터는 클러스터 내에 존재 하나의 노드 디스크에 맞게 저장 되어야 합니다.

그러나, 메모리에 충분히 수용될 수 없을 만큼 클 가능성이 있으며, Cassandra는 2십억건의 컬럼을 하나의 row에 수용할 수 있습니다.

ebay는 “wide rows”에 대한 벤치마킹을 진행한 적이 없지만, 하나의 row안에 몇 메가바이트 또는 몇 백만 건의 컬럼 이상으로 구성되지 않게 설계했기 때문입니다.

(로우키를 granularity하게 변화하거나, 여러 개로 분리하였습니다), 여기에 대해 흥미가 있다면, Aaron Morton가 작성한 Cassandra Query Plans 에서 wide rows와 관련된 퍼포먼스 자료를 확인하실 수 있습니다.

유의할 점은 wide rows를 사용하지 말란 의미가 아니라. 비대한 wide row를 사용하지 말란 의미 입니다.

Choose the proper row key – it’s your “shard key”


그렇지 않으면RandomPartitioner 사용할지라도 결국 병목이 발생할 것이다.

시계열 형태의 이벤트 로그를 저장하고 한 시간 주기로 조회하는 상단의 예제를 검토해보면, 한 row에 한 시간의 데이터를 함께 다루기 위한 row 키를 하나 선택했지만 문제가 있습니다.

모든 쓰기가 현재 시간 기준으로 하나의 노드에 존재하는 한 row에 해당한하면, 이는 클러스터 병목의 원인이 됩니다.

시간에서 분으로 단위를 줄이는게 과연 도움이 될까?. 어떻게 하더라도 단지 하나의 노드만 응답할 것이며 병목시점과 위치만 이동 할 뿐입니다.

Bad row key:  “ddmmyyhh”
이 문제를 해결하기 위한 한가지 방법은 로우키에 확장하는 방법이다. 이벤트 타입, 서버아이피등이 추가 될 수 있습니다.

Better row key: “ddmmyyhh|eventtype”

21

알아야 될 사항은 컬럼 패밀리 안에 존재하는 모든 이벤트 타입에 대해 글로벌 타임 형태로 정렬되어 있지않다는 사실입니다.

그러나, 추후 이벤트 타입에 의해 데이타가 그룹화 되어 보여진다면 문제되지 않을 수도 있으며, 시간순으로 정렬된 모든 이벤트에 대한 검색이 필요한 케이스라면,

해당 시간 동안 모든 이벤트 타입을 동시에 처리해야 하며, 어플리케이션 내에서 병합될 때 시간 순서대로 정렬해야 합니다.

만약 로우키에 어떤 데이타 추가가 불가능 하거나, 시간을 꼭 로우키로 사용해야 한다면, 또 다른 옵션은 로우키를 분리하여 물리적으로 분할하는 것입니다.

 “ddmmyyhh | 1″, “ddmmyyhh | 2″,… “ddmmyyhh | n”, 여기서 n은 클러스터에 존재하는 노드의 갯수입니다.

한 시간 동안 데이터를, 각 샤드에 골고루 분배하는 것이다.; 그리고 이를 위해 라운드 로빈 알고리즘이 필요합니다.

그렇지만, 한시간 동안 데이타를 읽는 것은 모든 분리된 노드들에 대해 다중 입력이 필요하며, 어플리케이션 내에서 병합작업을 수행해야 합니다.

 (여기에 랜덤 파티셔너가 사용된다는 가정이 필요하며, 따라서 로우키 기반의 범위 검색은 처리할 수 없게 된다.)

Keep read-heavy data separate from write-heavy data


이방법은. Cassandra 로우 케시에 대한 heap off 형태만이 적용 가능합니다.

케싱,NoSQL 과 관계없이 서로 다른 확장 형태를 취하는 많은 읽기와 쓰기가 필요한 데이타를 분리하는 것이 적절하다고 생각 합니다.

Notes:

    • 로우 케시는 사이즈가 일치할 때는 적합하지만, 모든 로우를 메모리에 적재하기 때문에 현재 wide row에는 맞지 않습니다.
      Cassandra-1956 와 Cassandra-2864에서 추후 릴리즈된 기능 변화 확인이 가능하지만  과도한 데이타 쓰기와 읽기에 대한 분리 저장 정책은 유효할 것입니다.
    • 하나의 컬럼 패밀리가 메모리에 적재할 수 있는 양보다 많을 지라도 그 중 자주 사용될만한 부분을 분리하여 메모리에 적재가 가능합니다.

Make sure column key and row key are unique


만약 그렇지 않다면데이타는 손실될 우려가 존재한다.

    • Cassandra(분산 데이터 베이스)는 로우키나 column key에 대해 유니크 사용이 필수가 아닙니다.
    • 역시, 분리 업데이트 기능이 존재 하질 않는다. Cassandra 에서는 항상 덮어씌우는 방식을 취합니다.
    • 만약 사고로 존재하는 로우키, column key에 대해 데이터를 insert 한다면, 기존의 컬럼 값은 어떠한 에러나 버전관리 없이 사라질 것입니다.

Use the proper comparator and validator


기본적인 BytesType 비교자(comparator) 유효성 검사자를 사용하지 마라

Cassandra 에서는 컬럼밸류를 위한 데이터 타입이 유효성 검사기라 불리며, 컬럼 명에 대한 데이터 타입은 비교자(comparator)라고 합니다.

비록 Cassandra에서 양쪽 다 필요하지 않거나, 컬럼 패밀리가 정적이거나 , 정렬 조차 사용하지 않는다고 해도, 비교자(comparator)는 필수로 정의되어야 합니다.

    • 부적절한 비교자(comparator)는 디스크 상에 컬럼명 기반으로 부적절하게 정렬할 것이며, 차후 컬럼명 기반의 범위 검색에 대해 나쁜 영향을 미칠 것입니다.
    • 한번 정의된 데이터는 모든 데이타를 재적하지 않는 한 비교자(comparator)를 변환할 수 없으며 검증자(validator)는 추후에도 변환이 가능합니다.
      comparators and validators 지원하는 데이터 타입을 Cassandra 문서를 통해 확인해보길 바랍니다.

Keep the column name short


컬럼명은 반복적으로 저장 되기 때문에 가능한 짧은 형태가 최적화에 도움이 된다.

컬럼명에 실제 데이터를 적재하는 부분은 제외하고 컬럼 값과 반복적으로 함께 저장되기 때문에 컬럼명을 짧게 유지해야 합니다.

메모리와 디스크에 대한 오버헤드는 컬럼 값보다 컬럼명이 더 클때 눈에 띄게 늘어날 것이며 작을 경우에도 마찬가지입니다.

예를 들어 설명하면 다음과 같은 케이스입니다.

ex)‘firstname’ 보다는 ‘fname’ , ‘lastname’ 보다는 ‘lname’

Note: Cassandra-4175

Design the data model such that operations are idempotent


유즈케이스가 부정확한 형태로 진행되는  또는 부정확 부분이 차후 수정이 가능한지 확인하라

Cassandra와 같은 eventually consistent 모델을 수용하는 분산 시스템은, 멱등(연산을 여러 번 적용하더라도 결과가 달라지지 않는 성질) 기능을 많은 부분에서 지원합니다.

멱등 기능은 시스템 내에서 부분 실패를 수용하며, 시스템의 최종 상태에 대한 변화 없이 안전하게 재수행할 수 있으며, 이러한 원칙이 어떻게 Cassandra에 적용되는 지 알아 보도록 합니다.

여기서 몇 개의 부분 실패 케이스를 확인해보고, 그리고 각 케이스 별로 다양하기 때문에 다음 포스트까지 strong consistency에 대한 필요성 부분을 무시할 것입니다.
관계형 데이터베이스와 다른 Cassandra의 멀티마스터 분산 시스템의 기본 성질로 인해, 쓰기 실패는 데이터에 대한 쓰기 성공을 보장하지 않지만, 다른 말로 풀어 쓰면, 클라이언트가 쓰기 기능에 대한 실패 메시지를 받게 될 경우라도, 데이타는 리플리카셋 중 하나에 쓰여질 가능 성이 있다, 따라서 결국 리플리카셋 모두에 적용될 것이다.

Notes:

    • “멱등 업데이트” 동작이 멱등 구조의 데이터 모델이라는 의미이다. 한번이든 여러 번이든 같은 결과를 가져온다면 멱등이라고 할 수 있습니다.

대부분의 케이스에서, 항상 멱등 형태의 업데이트의 정규컬럼 패밀리에 쓰기로 인해 문제는 없습니다.

예외는 카운터 컬럼 패밀리와 같이 사용될때 발생하며, 아래 예제를 통해 확인할 수 있으며, 때로는 유즈케이스 관점에서 멱등형 업데이트 형태가 아닌 쓰기 동작의 데이타 모델이 가능합니다.

예를 들어, 파트1의 ‘사용자가 아이템을 좋아한다는’ 유즈케이스를 중복으로 수행한다고 해도, 최종모델인 User_by_Item 과 Item_by_User 멱등형 업데이트가 아니며, 매번 다른 timestamp로 업데이트 될 것입니다.

그러나, 기억해야 할 점은, ‘user likes item’ 과 같은 정해진 유즈케이스 수행은 멱등으로 분리할 수 있으며, 그래서 실패시 몇번이고 반복해서 수행할 수 있습니다.

좀더 유즈케이스를 정리하는 부분은 추후 다른 포스트에서 언급할 예정입니다.

    • consistency level ONE 일지라도, 쓰기 실패는 쓰기가 완료된 데이타를 보장하지 않습니다:
      결국 모든 리플리카에 대해 데이터를 지속적으로 전파할 것입니다.

Example
어떤 아이템을 좋아하는 사용자의 수를 조회한다고 가정해봅시다.

Cassandra의 카운터 컬럼 패밀리를 사용하여 아이템당 사용자 수를 파악하는 방법이 있습니다.

카운터 증가는 멱등형 업데이트가 아니기 때문에, 적어도 한 노드에서 카운터 증가가 성공했다면, 오버 카운트는 수행되지 않을 것입니다.

멱등형 업데이트를 만드는 또 한가지 방법은 유저의 아이디 리스트를 유지하는 방법인데, 아래와 같이 카운터를 증가시키는 방법이 있습니다.

31

유저가 아이템을 like 할 때마다, 아이템에 대해 위 멱등 모델의 업데이트는, 카운터 값을 가져오는 것은 모든 유저의 아이디를 읽어야만 가능하며 데이터 건수(몇백만)로 인해 원활히 수행되기는 어려운 상황입니다.

많은 양적 부담으로 인해 읽기 수행이 어렵고 정확한 수치가 필요하지 않다면, 카운터 컬럼은 위의 케이스에 적합하다고 볼 수 있습니다.

필요하다면 카운터 값은 컬럼 패밀리의 멱등 업데이트로부터 유저 아이디에 대한 카운팅 방식을 주기적으로 수행함으로써 정확한 값을 유지 할 수 있습니다.

Note: Cassandra-2495 하나의 실패한 요청의 경우 카운터를 위한 적합한 재수행 메커니즘의 추가가 가능하나 일반적으로, 이 예제에서는 성공을 지속적으로 유지할 것입니다.

그래서 멱등 업데이트를 위한 당신의 설계 모델에 대해 항상 리트머스 테스트 수행으로 확인할 것입니다.

*멱등에 대한 보충설명:멱등법칙 또는 멱등성(idempotence)은 수학이나 전산학에서 연산의 한 성질을 나타내는 것으로써, 연산을 여러 번 적용하더라도 결과가 달라지지 않는 성질을 의미한다. 멱등법칙의 개념은 추상대수학(특히, 투영 이론·닫힘 연산·함수형 프로그래밍의 참조 투명성과 연관된 성질에서)의 여러 부분에서 사용하고 있다.

Model data around transactions, if needed


그렇지만 항상 가능하지는 안으며케이스 별로 상황이 다르다.

Cassandra는 멀티로우 방식이 아니며, 클러스터간 트랜젝션 또는 롤백 메커니즘이 없는 대신;로레벨 차원의 원자성을 제공합니다. 다른 말로 표현하면, 주어질 로우키에 연관된 컬럼에 대한 데이터 업데이트는 원자적 특징이 존재합니다.

만약 트랜젝셔널한 기능이 필요하다면, 하나의 row기반으로 즉시 업데이트 가능하도록 설계해야 됩니다.

그러나, 상황 별로 다를 수 있으며, 항상 수행하는것은 불가능합니다.

비슷한 케이스로, ACID 트렌젝션 지원이 필요한 시스템 이라면 데이타 베이스 선택에 대한 문제를 신중히 고려해야만 합니다.
Note: Cassandra-4285는 eventually consistent 배치 기능의, 원자성을 추가를 고려하고 있습니다.

Decide on the proper TTL up front, if you can


기존에 데이터에 TTL 값을 변화하긴 어렵기 때문이다.

Cassandra에서, TTL (time to live)은 정의되지 않았거나, 또는 모든 컬럼 패밀리에 적용되어 있습니다. 각 컬럼값에 셋팅되어 있으며, 셋팅 후 변경은 어렵습니다;

초기에 셋팅되어 있지 않을 시, 기존의 데이터에 추가적으로 수정 하는 것 역시 불가능 합니다. TTL 값을 갱신하기 위한 유일한 방법은 새로운 TTL 값과 함께 모든 데이타를 다시 읽고 쓰는 방법 뿐입니다.

그렇기 때문에 원래 목적을 잘 생각해보고, 가능하다면 사전에 적합한 값을 셋팅하길 바랍니다.

Note: Cassandra-3974 에서 컬럼 TTL과는 별개로 컬럼 패밀리를 위한 TTL을 확인할 수 있습니다.

Don’t use the Counter column family to generate surrogate keys


목적에 맞지 않기 때문이다.

카운터 컬럼 패밀리는 분산 카운팅을 위해 분산된 형태의 카운터들을 관리합니다. 컬럼 패밀리를 대체키 형태의 순차적 숫자(Oracle 시퀀스 와 MySQL 자동증가 컬럼과 같은 기능을 하는)들로 생성하여 사용하는 것은 자제하시기 바랍니다.

사용하게 된다면 중첩된 형태의 시퀀스 숫자를 할당 받을 것입니다. 대부분 시스템에서 전체를 위한 시퀀스 발급은 필요한 경우가 드물다고 볼 수 있습니다.

그리고 필요 시 timeuuid가 대체키로 더 적합하다 볼 수 있습니다. 정말 전체 시퀀스 생성이 필요하다면, 몇 가지 방법이 존재합니다.

그렇지만 중앙집중형 방식이기 때문에 시스템의 확장성과 가용성에 전반적으로 문제를 일으킬 수 있습니다.

Favor composite columns over super columns


수퍼컬럼 사용시 퍼포먼스 저하가 발생할 가능성이 있다.

Cassandra 내부의 수퍼 컬럼은 column key들을 모아서 사용할 수 있고, 또는 2단계의 구조로 구성될 수 있지만 수퍼 컬럼들은 다음과 같은 구현 이슈가 존재하며 합니다.

Issues:

    • 수퍼 컬럼의 서브 컬럼은 인덱스를 사용하지 않는다. 하나의 서브 컬럼에 대한 읽기는 모든 서브 컬럼들을 비직렬화 합니다.
    • 2차 인덱스 생성은 서브컬럼에서 동작하지 않습니다.
    • 수퍼 컬럼은 두 단계 이상 암호화가 불가능합니다.

유사한 기능으로 복합컬럼 사용에 의해 압축이 가능하나 하나의 일반 컬럼은 그 안에 서브 컬럼을 암화화해 같이 저장할수 있습니다.

 이러한 기능으로 인해, 일반 컬럼의 모든 장점(정렬 , 범위 조회)은 이용 가능하고 두 단계 이상의 암호화도 가능합니다.

Note: Cassandra-3237  복합 컬럼을 사용하기 위해, 그러나, 복합 컬럼이 수퍼 컬럼보다는 보다 더 적합하다고 판단된다.

The order of sub-columns in composite columns matters


순서는 그룹화된 형태로 정의 된다.

예를 들어, <state|city>와 같은 하나의 복합 컬럼 키는 “state” ,”city” 순으로 정렬되어 저장됩니다.
다시 말하면, 하나의 state에 대한 모든 도시들은 그룹화 되어 디스크에 함께 저장됩니다.

 

Favor built-in composite types over manual construction


매뉴얼 방식이 항상  동작하는 것은 아니기 때문이다.

문자열을 결합(separators like “:” or “|”)하여 사용하는 복합 컬럼 타입을 사용하지 마시고, 대신 Cassandra 0.8.1 이상 버전에서 지원하는 내장형 복합 타입 사용을 추천합니다.

Why?

    • 매뉴얼 생성 방식은 서브 컬럼 데이타 타입이 동일하지 않다면 동작하지 않습니다.
      예를 들면 <state|zip|timeuuid>과 같은 복합 키는 잘 알려진 타입으로 정렬 기능을 지원하지 않습니다.(state as string, zip code as integer, and timeuuid as time)
    • 사용시 역정렬이 불가능 합니다. 예를 들면 위의 키타입을 사용시 state 에 대한 순차 정렬과 zip code에 대한 역정렬

Note: Cassandra의 내장된 복합 타입은 두 가지 형태가 존재합니다.

    • Static composite type : 하나의 복합컬럼의 각 부분을 위한 데이터 타입들은 각 컬럼 패밀리별로 사전에 정의됩니다. 컬럼 패밀리 내부에 존재하는 모든 컬럼 명들과 키들은 복합 구성 타입 입니다.
    • Dynamic composite type: 하나의 컬럼 패밀리 안에 서로 다른 복합 타입의 컬럼명이 혼합되있는 구조를 허용하며, 심지어 하나의 로안에도  존재하더라도 허용합니다.
      복합타입에 대해 좀더 자세한 정보를 원하면 여기로 Introduction to composite columns

Favor static composite types over dynamic, whenever possible


동적 복합 타입은 너무 동적이기 때문이다.

만약 하나의 컬럼 패밀리에 존재하는 모든 컬럼키들이 동일한 복합타입이라면, 정적인 복합 타입을 사용을 추천합니다.

동적 복합 타입은 어떤 컬럼 패밀리 안에 존재하는 멀티 커스텀 인덱스를 유지목적으로 만들었으며, 절대적으로 필요한 경우가 아니라면 동적 복합타입을 사용하는 어떤 로우 안에 서로 다른 복합 타입을 혼합하지 말 것을 권장합니다.
Cassandra-3625는  동적 복합타입에 대한 심각한 이슈를 수정한 내용이 존재합니다.

Note: CQL(Cassandra Query Language)3는 클러스트된 로를 통해 컬럼 명들을 위한 정적 복합 타입을 지원한다. 어떻게 CQL 3가 넓은 로를 다루는지 좀더 자세한 정보를 원한다면 DataStax docs 를 참고하시기 바랍니다.

Cassandra Data Modeling Best Practices, Part 1

NoSQL 분야의 강자 Cassandra에 대한 좋은 글이 있어 번역해 올립니다.

들어가기전


원문 : http://www.ebaytechblog.com/2012/07/16/cassandra-data-modeling-best-practices-part-1

Cassandra 는 맵기반의 중첩된  데이타 구조를 수용하여 스키마의 설계시 이점(RDBMS 보다 자유로운 확장성)을 가지나, 높은 (디스크 공간과 같은 물리적)확장성을 지향하는 분산서버의 특성상 데이타 조인이 어렵습니다. 이러한 특징 때문에 데이터 중복 및 비정규화 사용이 중요하며, 지나친 비정규화 역시 걸림돌이 되기 때문에 이를 제한적으로 사용하기 위해 조회 패턴기반의 최적화 설계가 필요합니다.

기존 관계형 데이터베이스를 기반으로한 설계시 중복 및 비정규화를 사용하지 않는 게 원칙이라고 볼수 있지만, 분산환경을 지원하는 데이타베이스에서는 꼭 필요한 설계요소이며, Cassandra 역시 이러한 특징을 잘 활용해야 합니다. 그러기 위해선 초기 설계시 다음과 같은 몇가지 사항을 고려하셔야 합니다.

    • 데이타 중복 허용
    • 비정규화 사용 -> 맵구조의 특성을 잘 활용하고 서비스 수행속도를 보장
    • 비정규화 사용시 조회 패턴에 맞는 범위 내에서 적절하게 사용
    • 지연시간에 민감하거나 리스크가 높은 패턴 분리

이번 포스트의 핵심은, 분산환경 기반의 DBMS에 대한 경험이 적은 사용자들이 Cassandra 사용시 비정규화가 왜 중요한 설계 포인트가 되는지 이해하는 것입니다.  그렇지만  결국 서비스 구조와 사용하는 툴이 조화를 이루는 설계가 중요하다는 것으로 이해할 수 있습니다.

이해를 돕기위해 맵을 활용한 정규화된 데이터를  3단계의 비정규화 과정을 거쳐가며 Cassandra에 맞는 적절한 비정규화를 예를 들어 자세히 설명하고 있으니, 천천히 읽어 보시고 적절한 비정규화의 범위가 어디까지인지 eBay사례를 통해 확인해 보시길 바랍니다.(Cassandra에 대한 사전 지식이 없더라도 이해하는데는 문제 없을 것입니다.)

eBay내에서 Cassandra사용에 대한 몇가지..


eBay는 과도한 쓰기가 발생하는 logging 와 tracking부터 복합적인 기능에 이르기까지 다양한 케이스에 Cassandra를 적용 중이며, “Social Signal” 프로젝트 및  eBay 상품 페이지에 “like/own/want” 기능에 활용하고 있습니다. Cassandra 사용률은 지속적인 증가 추세를 보이고 있으며, 기능과 위험도에 따라 수십 개의 노드를 작은 클러스터 단위로 쪼개어 여러 개의 데이터센터에 분산 적용하였습니다. 그리고 Cassandra이외에도 MongoDB 와 HBase도 활용 중으로 보입니다.

 이 글은 eBay에서 적용한 Cassandra 데이터모델링 best practices에 중점을 두고 있기 때문에, 이외 여러 가지 사항들이 궁금 하시다면 Cassandra summit에 방문해 보시길 권해 드립니다.

Terms and Conventions

    • 몇 가지 규칙을 먼저 설명 드리면.“Column Name” 과 “Column Key” 그리고  “Super Column Name” 과  “Super Column Key” 는 서로 바꾸어 사용 가능합니다.
    • 아래 그림은 Column Family (CF)의 형태입니다.

    • 다음 그림은 Super Column Family (SCF)의 형태입니다.

    • 아래 내용은 복합 컬럼 형태의 Column Family를 하나의 row로 표현한 그림입니다. 복합 컬럼의 구분 자는  ‘|’를 사용합니다.
    • ‘|’ 단순히 표현상의 내용이지, Cassandra는 실제 ‘|’를 사용하지는 않습니다.

위 세가지 형태의 Column Family를 기반으로 설명을 진행하도록 하겠습니다.

Don’t think of a relational table

Cassandra는 관계형 테이블 대신 중첩된 맵 구조를 사용합니다. 아래 그림은 관계형 모델을 기반으로 Cassandra를 설명하기 위해 자주 사용되는 내용입니다.
 RDBMS에 익숙한 사용자들 위해 Cassandra의 데이터 모델을 관계형 모델에 비유한 그림입니다. 위 그림은 그냥 참고용 표현일뿐, 데이터 디자인 시 이러한 연관관계를 기반으로  설계 하는 것은 잘못된 설계의 원인이 될 수 있으며, 설계시 외부는 Row Key 이고 내부는  Column Key 형태로 둘다 정렬된 Cassandra column family를 사용하는 게 좀더 설계에 도움이 되는 구조이며 아래와 같습니다.

SortedMap<Row Key, SortedMap<Column Key, Column Value>>

위와 같이 Cassandra column family는 map 기반의 정렬된 Row Key와 Column Key형태가 적합하다고 볼수 있습니다.

Why?

하나의 중첩 정렬된 맵은 관계형 테이블에 비해 보다 자세한 표현이 가능 하기 때문에 Cassandra 데이터 모델링에 적합니다.

(참고: http://en.wikipedia.org/wiki/List_of_data_structures)


How?

    • 맵의 정렬구조는 조회를 보다 빠르게 수행할 수 있도록 도와줍니다. Cassandra에서는 row keys와 column keys 기반으로 조회나 범위 검색을 효율적으로 처리할 수 있습니다.
    • 컬럼 키의 수는 제약이 없으며, 하나의 키 자체가 값으로 사용될 수 있습니다. 물론 Value에는 Null(Null도 값으로 볼수 있지만, 여기서는 데이타가 없음을 의미하며 단지 Null로 표현 하였습니다)값도 허용합니다.

row keys 기반의 범위 검색은  데이터 Order Preserving Partitioner (OOP)를 사용한 클러스터에서 가능하며, 대부분 사용을 피하기 때문에 대신 정렬되지 않은 outer map을 고려해볼 수  있습니다.

(여기서 잠깐, Cassandra는 두가지 타입의 Partitioner를 지원하며 기본은 RandomPartitioner입니다. 약간 설명을 추가 하자면

    • RandomPartitioner  : MD5 기반의 hash Key를 발급하여 트래픽을 골고루 분산할수 있는 장점이 있으나 Range Scan 불가능 합니다.
    • ByteOrderedPartitioner : Key를 hexadecimal 형태로 관리하여 각 노드에 할당하는 구조로 key 값을 기준으로 각 노드에 대한 바이트 추적이 가능하나 병목 유발의 가능성이 존재하여 일반적으로 사용을 안합니다.)

Map<RowKey, SortedMap<ColumnKey, ColumnValue>>

Cassandra 안에는 “Super Column” 이라는 게 존재합니다.  “Super Column”을 그룹화된 컬럼이라고 간주한다면 두 개의 중첩된 맵을 3개의 중첩된 맵으로 다음과 같이 변환할 수 있습니다.

Map<RowKey, SortedMap<SuperColumnKey, SortedMap<ColumnKey, ColumnValue>>>

Notes:

    • Cassandra의 전반적인 문제점 해결을 위해 각각의 컬럼 밸류에 time stamp가 필요합니다. 그러나 모델링 시점에서는 무시해도 상관 없기 때문에, 어플리케이션 데이터에 time stamp를 고려한 내용은 생략하도록 하겠습니다. HBase와 달리 맞춤형 모델이 아니며, 데이타의 새로운 버전도 정의 되어 있지 않습니다.(HBase는 각각의 데이타에 대한 버전 관리를 지원합니다)
    • Cassandra의 커뮤니티는 수퍼컬럼의 사용을 2차 인덱스의 지원과 퍼포먼스 상의 이유로 반대하고 있으며, 수퍼컬럼 대신 복합컬럼을 사용하는 방법도 존재합니다.

Model column families around query patterns


조회 패턴을 고려하여 컬럼 패밀리를 구성하되, 엔티티와 관계를 디자인 시작 시 같이 검토하시기 바랍니다.

    • 관계형 데이터베이스와 달리, 조인, 오더, 그룹을 사용하는 복잡한 SQL을 만드는 것과 2차 인덱스를 생성하는 것은 확장성을 지향하는 Cassandra에서는 사실상 불가능합니다. 그렇기 때문에 조회패턴을 고려한 컬럼 패밀리 디자인이 필요합니다.
    • 앞서 얘기한 중첩된 맵구조를 기반으로 어떻게 쿼리가 요구한 내용을 안전하고 빠르게 조회/정렬/그룹/필터/병합등을 맵형태의 데이타 구조로 처리할 지 고려해야 합니다.

그러나  엔티티나 관계에 대한 추가 수정이 필요한 상태입니다. (로그 저장이나 시간기준의 데이타와 같은 특별한 경우에도 포함해서) . 만약 전자 상거래 웹사이트 모델링 시  조회패턴이 엔티티나 관계에 대한 아무런 정보가 없다면, 아마도 엔티티와 관계에 대해 조회 패턴이나 사전에 이해하고 있는 도메인 정보 기반으로 조사하려고 할 것입니다.  엔티니와 관계를 이해하는 것으로부터의 시작은 중요하며, 지속적으로 중복과 비정규화된 조회 패턴들 위주의 모델링 수정 작업이 필요합니다. 만약 잘 이해가 되지 않는다면, 다음 포스트에서 확인해보시기 바랍니다.

Note: 조회 빈도의 많고 적음에 대해 예를 들면, 쿼리 기준으로 단지 몇 천 번 처리된 것과 1억 번 이상 수행된 것 둘 중 어느 것이 많고 적은지는 분명합니다. 당연히 조회빈도가 1억건 이상인 쿼리를 우선시하여 설계할 필요가 있습니다. 추가적으로 고려해야할 사항은 지연시간에 대한 민감도입니다. 가장 높은 빈도와 위험도가 높은 쿼리 순으로 문제가 없는지 확인이 필요합니다.

De-normalize and duplicate for read performance


비정규화는 가능한 필요한 부분에만 적용하고 남용하는 것 역시 금물입니다. 모든 것이 적합한 밸런스를 찾기 위함이지 비정규화가 목적은 아니기 때문입니다.

정규화의 장점(최소한의 중복 등)이나 단점(테이블간 많은 조인이 필요할경우 속도가 느려짐)은 잘 알려져 있습니다. Cassandra 역시 마찬가지로 분산환경의 특성상 조인이 불가능한 것은 단점 중에 하나입니다. 그래서 스키마 정규화 시 많은 어려움이 있을 수 있습니다. 모델링과 조회 패턴에 대한 이해, 그리고 지금 이 내용은 아주 중요한 부분이기 때문에 나머지 부분에서 상세한 예제와 함께 집중적으로 다루어 볼 생각입니다.

Example: ‘Like’ relationship between User & Item

아래는 전자 상거래 시스템에서 하나 또는 여러 아이템에 대한 like 기능 수행 기능에 관련된 예제입니다.
각각의 사용자는 여러 아이템을 “like” 할 수 있으며, 각각의 아이템 역시 여려 사용자에게 “like”로 선택될 수 있습니다. 이는 관계형 모델 기반으로 N:N 형태로 나타나게 됩니다.


위그림을 기반으로 예를 들면 아래와 같이 데이타를 조회할 수 있습니다.

    • Get user by user id
    • Get item by item id
    • Get all the items that a particular user likes
    • Get all the users who like a particular item

아래에서 Cassandra의 데이타 모델링을 위한 몇 가지 옵션들을 비정규화를 적용하여 가장 낮은 순에서부터 가장 높은 순으로 적용한 예를 보여 드리도록 하겠습니다. 곧 알게 되겠지만 가장 최선의 방법은 조회 패턴에 기반한 모델링입니다.

Option 1: Exact replica of relational model

위 모델은 아이템 아이디와 유저아이디 기반의 조회가 가능합니다. 그러나 특정 유저가 좋아하는 또는 모든 유저들이 어떤 아이템을 좋아하는지 표현하기엔 부족할수 있으며, 보충하기 위해선  User_Item_Like 조회 기능의 최적화가 필요합니다. ‘time stamp’ 컬럼은 (유저가 “like”할 때 저장되는) 간결하게 하기위해 User_Item_Like 에서 삭제되었으며, 이 부분은 뒤에 설명할 예정입니다.

Option 2: Normalized entities with custom indexes

 

위 모델은 유저 아이디와 아이템 아이디를 중복으로 저장하여 맵핑하는 것을 제외하면 상당히 정규화된 형태를 취하고 있습니다.
일부 유저가 Item_By_User를 사용하여 “like”한  모든 아이템을 쉽게 조회할수 있으며, User_By_Item을 사용하여 일부 아이템을 “like”한 모든 사용자를 조회할 수 있습니다.그렇지만 컬럼 패밀리가 분리돼 있기 때문에 조인이 필요한 상황이며 조인을 할 수 없기 때문에 문제가 발생할수 있습니다. 예를 들면 특정 유저에 의해 “liked”된 아이템 아이디와 제목을 원한다고 가정해 보면,

  • 첫째, 사용자가 “like”한 아이템 아이디를 얻기 위해 Item_By_User 를 조회하기 위한 쿼리가 필요합니다.
  • 그리고  각각 아이템 아이디의 타이틀을 가져오기 위한 조회가 또 한번 필요합니다.

다른 예를 들면, 특정 아이템을 좋아하는 사용자의 아이디와  이름을 동시에 조회해야 할 상황이라면,

  • 해당 아이템을 좋아하는 모든 유저들을 찾기 위해 User_By_Item에 대한 조회 후,
  • 각각의 유저 아이디별로 유저 이름에 대한 추가 조회를 해야만 원하는 결과를 가져올 수 있습니다.


하나의 아이템이 수백 명의 사용자에 대해 “like” 되거나 또는 한명의 유저가 많은 아이템을 선택하는 것이 현실적으로 가능한 상황이기 때문에 이러한 조회패턴을 염두해서 설계할 필요가 있습니다. 이렇게 해당 아이템을 좋아하는 사용자 이름을 조회하기 위해, 또는 그 반대일 경우에도 많은 추가 조회 작업이 필요한 상황은 개선할 필요성이 있다고 생각됩니다. 이는 Item_by_User 와 User_by_Item에 아이템 제목에 대한 비정규 형태의 최적화가 더욱더 필요하며 옵션3과 같이 나타낼 수 있습니다.

Option 3: Normalized entities with de-normalization into custom indexe


이번 예제의 모델에서는, User_By_Item과 Item_By_User 안에 사용자 이름과 제목이 비정규화 되어 있습니다.  하나의 사용자가 “like”한 모든 아이템 제목과 하나의 아이템을 “like”한 모든 사용자 이름을 효과적으로 조회할수 있도록 설계를 변경 했습니다.

조회 패턴을 좀더 발전시켜 한 명의 사용자가 “like”한 아이템들에 대해 주어진 모든 정보를 가져와야 한다면? 만약 정말 이러한 조회가 필요한 지 고민해 볼 필요가 있습니다. 대신 사용자가 좋아할만한 제목을 모두 노출시키고, 클릭시 추가적인 정보를 끌어오는 방법으로 처리해서 부적합한 조회 패턴을 적절하게 변경할 수 있기 때문입니다. 때문에 이러한 극도의 비정규화는 적절한 형태로 바꾸는것이 가능합니다. (일반적으로 제목과 가격은 노출이 되며, 간단히 목적에 맞추어 처리하기 할 수 있습니다.)
이어서 다음 두 개의 조회 패턴을 검토해보겠습니다.

  • 주어진 하나의 아이템 아이디를 기반으로 그 아이템을 좋아하는 사용자의 이름과 함께 모든 아이템 데이타를 조회한다.
  • 주어진 한명의 사용자 아이디를 기반으로 그 사용자가 좋아한 아이템 제목들과 함께 모든 사용자 데이터를 조회한다.


사용자 상세 페이지나 상품 상세 페이지에 기능으로  잘 동작할 것입니다. 둘 다 위 모델을 기반으로  두  번의 조회가 필요하며 ,

  • 첫 번째로 아이템(또는 사용자) 데이터를 조회하고
  • 두 번째로 사용자 이름(또는 아이템 제목)을 조회할 것입니다.


만약 사용자가 활동적이더라도 (수천 개의 아이템을 좋아한다면) 또는 상품이 반응이 뜨거워 수백 만의 사용자가 좋아 하더라도 추가 조회는 발생하지 않을 것입니다.

이정도면 꽤 많은 최적화가 진행됐다고 생각 되며 option 2에 비해서 비정규화 부분은 그리 많지는 않았습니다. 그러나 설명을 위해 option 4에서 좀더 최적화를 할수 있는지 알아보도록 하겠습니다.

Option 4: Partially de-normalized entities

 

11

option 4는 지나친 비정규화로 한 예로 볼수 있습니다. 수퍼 컬럼을 기반으로한 option 3는  사용자와 아이템이 많은 항목(eBay에서 처리했던것과 유사하게)을 공유한다면, 옵션4 보다는 3번을 선택할 것입니다.

모든 아이템 데이터를 사용자 엔티티에 넣거나 또는 그 반대가 되는 극도의 비정규화는 아니기 때문에 여기서는 부분 비정규화라는 용어를 사용했습니다. 모든 데이터를 한쪽 속성으로 편입시키는 극도의 비정규화는 고려하지도 않았으며, 이러한 케이스는 부적절하다고 여러분도 생각할 것입니다.

Note: 여기서는 수퍼 컬럼을 단지 데모 목적으로 사용했습니다. 실제로는 수퍼 컬럼보다는 복합 컬럼을 선호할 수 있습니다.

The best model

위의 예제에서 Best는 3번입니다(4번은 필요 이상의 비정규화 과정을 거쳤기 때문..). 추가적으로 time stamp는 제외 되었지만 timeuuid 형태로 아래 마지막 모델에는 포함 하도록 해보겟습니다.

User_By_Item 와 Item_By_User 컬럼 패밀리들을 안의 timeuuid 와 userid를 합쳐서 하나의 컬럼키로 구성합니다.

column keys는 물리적으로 정렬되고 저장된 구조로 이를 재호출하는 구조입니다. User_By_Item과 Item_By_User 내의 timeuuid 에 의해 정렬 저장 되었으며, 시간에 의한 범위 검색에 효율적이라 볼 수 있습니다. 모든 데이타를 읽을 필요없이, 사용자가 “like” 한 내용이나 또는 어떤 아이템이 “like”한 내용을 마지막(최근)에 저장된 데이타에 대해 범위검색시 이점을 가진다고 볼 수 있습니다.
  

 

Summary


지금까지 Cassandra 데이타 모델을 디자인하기 위해 몇 개의 기본적인 사례를 기반으로 상세한 예제와 함께 살펴 보았습니다. 몇 가지 주요 내용을 살펴보면

 

    • Cassandra 컬럼 패밀리를 디자인할 때 관계형 테이블을 고려하지 말고, 중첩된 맵구조를 고려하라.
    • 조회 패턴에 기반하여 컬럼 패밀리를 디자인하라. 그러나 가능한 엔티티와 그 관계를 디자인 시작할 때 고려하라.
    • 읽기 성능을 위해 비정규화와 중복을 허용하라. 그렇지만 비정규화는 필요할 때만 사용하라.
    • 모델링을 하기 위한 많은 방법이 존재하지만 최고의 방법은 유즈케이스와 조회 패턴들을 잘 활용 하는 것이 중요하다.


Cassandra 의 장점을 최대한 살리기 위해 트래픽 비중을 고려하여 적절한 비정규화 에 대해 간단히 알아 보았습니다.

쌩뚱맞지만 마지막으로 이글을 읽으시는 분들중에 NoSQL의 선택에 대한 고민을 가지시는 분들도 있으실거라 생각 되어(NoSQL 도입시 선택에 대한 질문을 몇 차례 받은 바가 있어서..), 마무리는 NoSQL의  초기 도입 전략에 대한 제 소견을 짧게 정리해보고 마치도록 하겠습니다.

관계형DB가 범용에 가까운 특징을 가졌다고 하면,  NoSQL은 각각 태생적 특성에 맞추어 차별화된 기능을 가지고 있습니다. 많은 NoSQL이 존재하며 전문가도 부족한 상황입니다. 그렇기에 도입 분석에 대한 시간이나 역량이 부족하다고 판단될 시는 Mongo DB와 같은 초기 도입이 쉬운 것을 추천 드리며, 기능을 어느 정도 이해하신 후 세부사항이 도출되면 거기에 따라 적합한 NoSQL을 선택 하시길 권해드립니다. 만약 전문가라면 한번에 적절한 걸 선택 하실지도 모르지만, 최초 설계가 마지막까지 지속되지 않을 수 있음으로, 되도록 유연하고 빠른 개발이 가능 한것을 선택하시는게 현명하다고 생각됩니다.

 

추천 시스템 분석 – 어떻게 아마존과 넷플릭스가 당신의 취향을 예상하는가?

들어가기전

추천분야는 1990년대에 시작된 이후 지금까지 꾸준히 발전 해오고 있습니다. 비교적 조잡하고 부정확한 형태로부터 시작했지만, 데이타가 다양하고 많아질 수록 더욱 발전하였고 그러한 데이터와 함께 혁신적인 알고리즘을 덧붙여 갔습니다. 이러한 추천시스템은 현재 아마존 상품 추천, 넷플릭스 영화추천, 페이스북의 친구 추천 등 대형 서비스와 함께 지속적으로 영역이 확대되어 가며 점점 중요성이 높아지고 있습니다. 또한 대학들은 이러한 추천을 정규 코스로 추진 해가고 있으며, 휴대폰 회사들은 다른 이통사로 이탈확률이 높은 고객들을 예측하기 위해 사용하기도 합니다.

이러한 추천의 배경이 무엇인지 살펴보도록 하겠습니다.

 [추천 효과]

  • Netflix : 대여되는 영화의 2/3가 추천으로부터 발생
  • Google News : 38% 이상의 조회가 추천에 의해 발생
  • Amazon : 판매의 35% 가 추천으로부터 발생
  • Netflix Prize (~2009) Netflix에서 주관하는 경연대회로, 영화 선호도를 가장 잘 예측하는 협업 필터링 알고리즘에 수상 (US$1,000,000)

협업 필터링(Collaborative filtering)

이런 추천의 근간이 되는 유사점을 분류하는 방식에 협업 필터링 이라 불리는 방법이 존재 합니다. 사전에 누적된 대규모의 데이터를 활용하여 이를 분류하고 분류된 데이터의 기준을 기반으로 새로운 데이터에 대입하여 분류하는 방법 입니다. 이러한 협업 필터링의 분류 기준은 대표적으로 두 가지가 존재합니다.

 

cf_base[출처 :Deconstructing Recommender Systems by JOSEPH A. KONSTAN, JOHN RIEDL  /  OCTOBER 2012]

사용자 기반(user-user)

두 사용자의 공통된 아이템을 기반으로 얼마나 많이 일치하는지 거리를 수치화하는 방법을 사용합니다. 예를 들어, 짐과 제인이 각각 트론이라는 영화에 5점을 입력하였다면, 그 둘 사이의 거리는 0입니다. 반면, 한명은 5 점, 나머지 한명은 3점을 입력하였다면 거리는 증가하게 됩니다. 이러한 사용자간의 유사도를 활용하여 추천하는 방식이 사용자 기반이라고 볼 수 있겠습니다. 그러나, 사용자 기반의 필터링은 공통점을 이끌어내는 것이 쉽지 않다는 문제점이 존재합니다. 사용자 간의 공통점이 추천에 활용할 수 없을 많큼 데이터가 부족할 수 있기 때문입니다. 한가지 예를 들면, 대부분의 사람들은 블록버스터 영화에 선호도가 집중하는 경향이 있습니다. 대부분의 데이터가 블록 버스터 영화에만 데이터가 몰려있기 때문에 추천의 결과가 모든 사용자들에게 동일한 현상이 발생할 확률이 높으며, 이는 추천에 대해 무의미한 결과를 가져오기도 합니다. 또는 웹사이트를 기준으로 볼 때 어떤 페이지의 특정 부분을 클릭하는데 많은 시간이 걸리기 때문에 데이터 수집 자체에 어려움을 겪을 수도 있습니다. 간단한 설명이라 부족한 점이 있지만, 추천에 있어 적절한 데이터 양의 부족으로 인해 공통요소(분류기준)을 분류한다는 게 아주 단순하다고는 볼 수 없습니다. 이를 보완할 수 있는 방법 중 하나가 아이템 기반이라 할 수 있습니다.

아이템 기반 (item-item)

오늘날 대부분의 추천시스템은 사용자 기반 대신 아이템 간의 거리를 사용하는 아이템 기반을 활용합니다. 넷플릭스와 아마존이 세부적인 내용은 공개하진 않지만, 아이템 기반의 다양한 알고리즘을 사용한다고 공개적으로 언급하고 있습니다. 아이템 기반에 대해 예를 들어 설명을 간략히 하면, 톰클랜시의 책을 좋아하는 사람들이 Clive Cussler의 책도 아주 좋아한다면,Clancy 와 Cussler는 아주 가깝다고 볼 수 있습니다. 즉, 사용자기반과 동일하게 유사도를 기준으로 아이템 간의 거리를 측정한 후 유사한 아이템을 추천하는 방식을 취한다고 볼 수 있습니다. 대부분 사용자대비 아이템이 적은 수를 차지하고 있기 때문에 아이템을 기준으로 볼 때 아주 다양한 관계 데이터가 발생할 확률이 높다고 볼 수 있습니다. 이러한 방식은 데이터가 누적 될수록 추천의 정확도가 높일 수 있는 가능성이 있습니다.

참고로, 원하는 전화번호를 쉽게 찾아 전화 할 수 있는 대표적인 114전국전화 앱에서도 아이템 기반의 분석을 통해, 추천 검색어, 검색품질 개선에 사용되고 있습니다.

문제점

비율의 일관성(inconsistency of ratings)

위에서 언급된 두 가지 방식을 사용한다고 해도 여러 가지 추가적인 문제점이 존재합니다. 우선 첫 번째로 비율의 일관성 문제입니다. 다시 말해, 같은 아이템에 같은 방법일 지라도 재측정시 값이 변할 수 있으며, 원인은 사용자의 취향이라는게 항상 고정되어 있는 것이 아니기 때문입니다. 1990년대 후반에 MIT에서 진행한 한 실험은 하나의 원본 비율이 1년후 7가지 형태로 변화될 수 있음을 증명한 사례가 있다고 합니다. 이렇듯 축적된 데이터라고 하더라도 여러 가지 요인에 의해 변동이 가능하다는 사실은 염두해야만 합니다.

유사 아이템 추천

추가적으로 사용자 및 아이템 기반의 알고리즘은 일관성보다 더욱 큰 문제가 존재합니다. 적용 기준이 엄격하기 때문에, 동일한 아이템이 아닌 유사한 아이템을 기반으로는 적용 불가하다는 것입니다. 예를 들어 설명하자면, 모네의 수련 그림에 대한 팬이라고 가정 봅시다. 250 개의 작품 중 사용자마다 정말 좋아하거나 또는 좋아하지 않는 작품이 존재할 수 있습니다. 이러한 상세 취향은 기본 알고리즘만 가지고는 각자 그들의 취향을 알수 없습니다. 그래서 이러한 유사취향 문제를 해결할 수 있는 차원 축소라 불리는 방법이 존재합니다. 이 방법은 사용자 아이템 기반의 알고리즘보다는 많은 계산량이 요구되기 때문에 실제 적용하기까지 상당한 시간이 소요됐지만, 컴퓨터의 성능이 나날이 발전함에 따라 적용 가능하게 됐습니다.

차원축소(dimensionality reduction)

차원축소를 이해하기 위해 다른 수많은 사람들과 음식 취향을 비교하는 것으로 예를 들어보겠습니다. 거대한 메트릭스로 취향을 표현할 수 있습니다. 각각의 사람들의 취향과 수천 가지 음식을 표로 만들어볼 수 있습니다. gave grille 5점, braised short rib 4.5점, s, fried chicken wing 2점, cold tofu rolls 1점, roasted portobello mushroom 5점, steamed edamame with sea salt 4점 등… 이렇게 각각의 음식에 대해 점수를 부여한 데이터를 기반으로, 추상화 단계를 거쳐 (예를들어, 짠 음식, 생선요리 등) 유사한 기준으로 분류한 후, 새로운 아이템을 유사도 분류 기준에 대입하여 적용하면 어느 정도 같은 취향으로 분류가 가능하게 됩니다.

이러한 차원 축소를 적용한 추천은 상세한, 특정 음식에 대한 점수가 그리 큰 영향을 미치지는 않습니다. 그렇지만 다양한 음식에 대해 차원 감소를 적용함으로써 발생하는 일반화 현상은 이해하고 있어야 합니다.  예를 들면, beef, salty things, and grilled dishes는 좋아한다로 정의 될수 있고, chicken and anything fried는 싫어한다로 정의 될 수 있으며, vegetable은 보통으로 정의될 수 있습니다. 이러한 형태로 축소 시 약 50에서 100개의 차원으로 축소가 가능하게 되며, 차원을 보는 것만으로도 ,추천자는 새로운 음식이 속하는 범위를 빠르게 결정하는 게 가능하게 됩니다. 이는 아직 분류되지 않은 유사한 아이템을 특정 사용자에게 추천할 수 있게 하는 더욱 일반화된 방법이라고 볼 수 있습니다. 차원 축소가 많이 적용될 수록 추천이 더욱 효율적이라 할 수 있으며, 이러한 차원 축소를 적용하기 위해 사용되는 방법중 특이값 분해 (Singular Value Decomposition, SVD)를 사용할 수 있습니다.

추가 고려 사항

지금까지 추천의 기본적인 배경지식에 대해 살펴보았습니다. 추가적으로 알아두어야 할 몇 가지 부분을 좀 더 알아보도록 하겠습니다.

만약, 이메일로 어떤 물건을 추천한다고 가정해 봅시다. 사용자가 이메일을 확인 후 쓸모 없는 내용이라 판단된다면, 그리고 이런 결과가 지속적으로 반복된다면, 사용자로부터 신뢰를 잃을 것이며, 스팸으로 분류되어 사용자에게 어떠한 정보도 전달할 수 없는 상태로 이어질 수 있습니다. 이렇듯 정확한 정보를 전달하는 것은 매우 중요한 요소이며, 정확한 정보 전달 이후에 사용자와 판매자 둘 다 이익이 발생해야 한다는 것입니다.

정확성

정확한 추천이 어떻게 이루어 질 수 있는지 아마존의 온라인 스토어를 예를 들어 설명해보도록 하겠습니다.

아마존은 사용자에게 적절한 추천을 하기 위해 몇가지 방법으로 사용자의 성향을 파악합니다. 대부분 사용자가 해당 페이지에 접근한 후 활동한 내역들을 기반으로 한다고 볼 수 있습니다. 예를 들면 제품에 대한 별점 적용 수치, 방문한 페이지중 상세페이지까지 확인했는지, 반복해서 접속한 페이지, 구매 의향이 있는지, 실제 제품을 구매했는지, 동일한 세션 안에서 확인했던 목록 정보등, 클릭 했던 모든 사용자 행동을 기반으로 성향을 파악합니다. 이런 모든 사용자 데이터를 차후에 활용하기 위해 모아 둘 것입니다. 심지어 로그인 하지 않은 사용자 데이터까지 모아서 활용하기도 합니다. 이런 대량의 데이터 수집 활동은 온라인 스토어에서만 이루어지는 것이 아니며, 월마트와 같은 곳에서도 사용자 영수증 데이터(구매목록)를 활용 중에 있습니다. 나아가 전세계에서 지금도 진행되고 있는 중입니다. 단 유럽의 경우 법적으로 데이터 수집 범위에 따라 제약을 받을 수 있습니다.

business rules

시스템이 잘못된 추천을 방지하고 사용자의 신뢰를 잃지 않으며 판매자의 수익을 최고로 하기 위해 추가 적용된 부분이 business rules입니다. 예를 들어, 비틀즈와 같은 유명한 음악가들의 앨범을 모든 방문자에게 추천을 하고 있다고 가정해 보면, 통계적으로 옳은 수치가 적용됐다고 볼 수 있지만, 실제 구매는 거의 이루어지지 않을 가능성이 있습니다. 모든 방문자들이 앨범에 대해 실제 높은 별점을 부여하기는 하지만 대부분 앨범을 소유했기 때문입니다. 또 하나의 예로, Netflix의 영화추천 시스템의 사례를 설명하면 액션 영화를 좋아하는 사람에게 The Avengers(액션영화) 라는 영화를 추천할 수도 있습니다. 그러나 실제론 Netflix에서는 대여 불가 항목 이라면, 추천해야 될 영화 일지라도 서비스에서 허용하는 한계를 고려하고, 이러한 점들이 시스템에 당연히 반영되야 할 것입니다. 그리고 기타 비즈니스적인 요인들이 접목 되어야할 부분은 각 서비스별로 무수히 존재할 것이며 이를 잘 반영해야 된다는 점은 중요한 부분이라 생각 됩니다.

 

지막으로 추천시스템을  검토 중이라면 아래 오픈소스들을 활용해보는 것을 추천 합니다.

참고로, kth 데이터지능팀의 대용량 실시간 분석 솔루션인 DAISY(Data Intelligence System)에서는 Apache Mahout 기반으로 추천엔진을 구성하고 있습니다!

Software Description Language URL
Apache Mahout Machine learning library includes collaborative filtering Java http://mahout.apache.org
Cofi Collaborative filtering library Java http://www.nongun.org/cofi
Crab Components to create recommender systems Python https://github.com/muricoca/crab
easyrec Recommender for Web pages Java http://easyrec.org
LensKit Collaborative filtering algorithms from CroupLens Rearch Java http://lenskit.grouplens.org
MyMediaLite Recommender system algorithms C#/Mono http://mloss.org/software/view/282
SVDFeature Toolkit for featurebased matrix factorization C++ http://mloss.org/software/view/333
Vogo PHP LIB Collaborative filtering engine for personalizing web sites PHP http://sourceforge.net/projects/vogoo

 

 


about HBase

Hadoop 에 들어 있는 데이터를 M/R, Hive, Pig 등으로 분석을 하면 수십초 이상의 MR Job 수행시간이 걸립니다. 이럴 경우 Hadoop 앞단에 NoSQL인 HBase가 유용할 것입니다. 조금 철지난 글이지만, HBase에 대해서 서술해봅니다.

특징 요약

  • 읽기/쓰기에 대한 일관성 보장 (카산드라보다 쓰기 속도가 떨어지는 이유)
  • 오토 샤딩 지원
  • 자동화된 fail-over 지원
  • Hadoop/HDFS 통합:HDFS  지원.(Hbase 버전별 Hadoop버전 확인필요)
  • MapReduce: MapReduce 지원.
  • Java Client API 지원: Java API기반의 엑세스 가능.
  • Thrift/REST API 지원: Thrift 및 front-ends 의 non-Java를 지원하기 위한 REST 지원.

적용 고려사항

  • 데이터 사이즈 : 수십억건이상의 데이터 사용이 아니라면 RDBMS를 추천
  • 설계모델 검토 : RDBMS의 장점(e.g., typed columns, secondary indexes, transactions, advanced query languages, 등.)이 사라지게 되어도 문제가 없는지 확인이 필요하며, JDBC에 최적화된 구조라면 도입시 디자인부터 다시 고려해야 할 수 있다. 간단한 구조 변화로 HBase로 전환 불가

사용패턴

tumblr  
  • 서비스특징 : 5억 PV, 초당 4만 request, 하루에 3TB 데이터를 저장하는 서비스
  • 사용처 : write성능이 필요한 곳. 수십억개의 URL을 저장하는 단축 url서비스등에 사용
  • Many TB/day into Redis, HBase, MySQL,Hadoop

facebook

  • Cassandra 에서 HBase로 전환중
  • 메시징 플랫폼에 사용

Architecture

hbase-files

[출처:larsgeorge.com :HBase Architecture 101 – Write-ahead-Log]
  • 파일은 주로 HRegionServer들이 처리
  • Write-ahead log & Actual data
  • Zookeeper
  • 하둡 분산 파일시스템에 실제 데이터를 저장시  작은 블록 단위로분할 저장
  • client -> Zookeeper quorum(a separate cluster of Zookeeper nodes)

리플리케이션

                                                                           [출처:hbase.apache.org]

 

HBase IO

  • Flushes And Compactions
  • HBase Row Log Libary

Example

성능비교

                                               [출처: www.cubrid.org]