음악과 영화의 장르 그리고 큐레이션

 

우리가 흔히 일상에서 접하는 음악의 장르는 보통 아래와 같이 분류한다.

• 클래식
• 재즈
• 블루스
• 리듬 앤 블루스
• 힙합
• 컨트리 음악
• 팝
• 전자 음악
• … (엄청 많다. 인류는 음악 분류를 정말 좋아한다.)

음악에서의 장르란 광범위한 음악들을 형식적으로 카테고리화한 것이다.

음악을 좀 듣는 사람들은 처음 듣는 음악이라도 장르를 구분한다. 음악의 장르를 구분하는 AI 기술도 이미 존재한다. 대체로 음악의 장르 구분 기준은 듣는 사람의 감성과는 무관하다. 그리고 시간이 지남에 따라 음악은 엄청 많아졌다. 역설적으로 나의 감성/상황에 적합한 음악을 찾기가 어려워진것이다. 그래서 감성/상황 기반의 Playlist를 제공하고 있다. 부족한 부분을 보완한 분류체계인것이다. Spotify, Youtube Music 등의 음악 서비스에서 기본적으로 제공하고 있고, 사용자가 Custom하게 만들고 공유할 수 있다. 이 기능 덕분에 누군가가 공유한 “운동할 때 듣는 음악”, “여행 갈때 듣는 음악”, “슬플때 듣는 음악”등등의 플레이리스트를 잘 활용하고 있다. 특정 사용자가 큐레이터가 되는 것이다.

이제 영화를 살펴보자. 영화 장르는 보통 아래와 같이 분류한다.

• 액션 영화
• 범죄 영화
• SF 영화
• 코미디 영화
• 스릴러 영화
• 공포 영화
• 전쟁 영화
• 스포츠 영화
• 판타지 영화
• 음악 영화
• 뮤지컬 영화
• 멜로 영화
• …

영화에서의 장르 역시 광범위한 영화들을 형식적으로 카테고리화한 것이다.

그럼 음악에서 제공하는 상황/무드 기반의 분류 체계는 없는 것일까? 음악 서비스 업체처럼 Custom하게 사용자가 Playlist를 만들고 공유하는 기능은 없을까? “수학자가 나오는 영화”, “우울할때 볼만한 영화”등등… 누군가가 큐레이션를 해줄 수는 없는걸까?

유튜브는 사용자가 제작한 콘텐츠를 공유하는 플랫폼이기에 대체로 영상이 짧다. 그렇다보니 콘텐츠 양이 어마어마하다. 그래서일까? Playlist 기능을 제공한다. 아시는분은 아시겠지만 유튜브는 영화 콘텐츠도 제공한다. (https://www.youtube.com/movies)

Netflix는 더 재밌는 서비스가 존재한다.

2016년에 Flixtape 서비스를 런칭한다.

Flixtape는 Netflix가 제공하는 콘텐츠의 짧은 플레이리스트를 만드는 기능이고 공유할 수 있다. 예전에 카세트 테이프에 좋아하는 음악을 Mix해서 들었던 기억이 있는지?

Netflix안에만 머물던 콘텐츠가 외부 SNS, SMS등을 통해 사용자들이 직접 입소문 마케팅을 할 수 있는 간단한 방법을 Flixtape가 제공한다.

혹시 국내 서비스중에 사용자에 의한 큐레이션 기능을 제공하는 서비스가 있으면 소개좀…

Read More

Netflix Artwork의 개인화

본글은 “Artwork Personalization at Netflix”의 글의 내용중 일부를 발췌해서 작성했습니다.

Netflix 추천 시스템의 주요 목표는 사용자에게 맞는 콘텐츠를 추천하는 것이었습니다. 사용자가 콘텐츠에 흥미를 가지고 해당 콘텐츠가 가치가 있는지를 확인하는 방법이 무엇일지 많은 고민을 했습니다. 콘텐츠의 포스터가 관문 역할을 하며 사용자에게 콘텐츠에 대한 매력을 어필할 수 있다고 판단했습니다.

구구절절한 설명보다 단 한장의 이미지로 함축적인 내용을 전달 할 수 있습니다. Netflix는 이점에 착안하여 Artwork의 개인화를 시스템에 반영했습니다.

“Good Will Hunting”이라는 영화를 묘사할 때 사용하는 이미지를 개인화하려고 시도해봅시다. 로맨틱한 영화를 즐겨본 사용자는 Matt Damon과 Minnie Driver가 포함된 포스터를 보여주면 “Good Will Hunting”에 관심이 있는 반면, Robin Williams가 포함된 포스터를 사용하면 코미디 영화를 좋아하는 사용자가 영화에 관심이 있을 수 있습니다.

또 다른 시나리오를 생각해봅시다. Pulp Fiction의 포스터의 경우, 우마서먼이 출연한 영화를 많이 본 사용자(바로 저)는 우마서먼이 나오는 포스터에 호감을 가지게 될 것입니다. 한편 존 트라볼타의 팬은 존 트라볼타가 나오는 포스터에 더 관심이 있을 수 있습니다.

Netflix는 포스터를 개인화함으로써 모든 사용자가 최상의 선택을 할 수 있도록 사용자 경험을 향상 시킵니다.

포스터를 개인화하는 방법을 알기 위해서는 한 콘텐츠에 대해 어떤 포스터가 더 효과가 있다라는 신호를 찾기 위해 많은 데이터를 수집해야 합니다.

효과적인 개인화를 달성하려면 각 콘텐츠에 대해 훌륭한 포스터 풀이 필요합니다. clickbait(독자가 흥미롭지 않거나, 가치가 떨어지는 콘텐츠의 링크를 클릭하도록 유도하는 행위)를 피하기 위해 매력적이면서 유익한 포스터 자산이 필요하다는 것을 의미합니다. Netflix의 아티스트 및 디자이너팀은 다양한 차원에서 다양한 이미지를 만들기 위해 노력을 기울입니다.

포스터를 개인별로 제공하기 위해서는 엔지니어링 관점에서 Challenge가 필요합니다. 사용자의 시각적 경험을 위해 많은 이미지를 포함한다는 점입니다. 각 콘텐츠에 대해 개인별 맞춤형 포스터를 제공하면 초당 2천만건의 요청을 처리할 수 있는 견고한 시스템이 필요합니다. UI에서 포스터를 제대로 렌더링 하지 못하면 사용자의 경험이 크게 저하됩니다. 사용자의 취향이 변함에 따라 포스터의 효과가 시간이 지나면서 바뀌게되므로 알고리즘이 지속적으로 대응해야 합니다.

Netflix의 추천엔진 대부분은 기계학습에 의해 동작됩니다. 사용자의 서비스 사용에 대한 데이터를 수집하고 그 데이터를 기반으로 알고리즘을 실행합니다.

그리고 A/B 테스트를 통해 새로운 알고리즘을 테스트 합니다. A/B 테스트는 새로운 알고리즘이 무작위로 구성된 사용자를 대상으로 진행하며, 현재 프로덕션 시스템보다 우수한지를 확인합니다.

그룹B의 사용자가 새로운 알고리즘 환경에 접속하는 동안 그룹A의 사용자는 현재의 프로덕션 환경으로 접속합니다. 그룹B의 사용자가 참여도가 높으면 새로운 알고리즘을 전체 사용자에게 배포합니다. 그러나 불행하게도 이러한 접근법은 실패했습니다. 오랜동안 많은 사용자가 더 나은 경험을 얻지 못했습니다.

Netflix는 이 실패를 해결하기 위해 Batch성 기계학습에서 벗어나 실시간 기계학습을 고려했습니다. Netflix가 사용하는 학습 알고리즘은 Contextual bandits입니다. (참조: https://medium.com/netflix-techblog/artwork-personalization-c589f074ad76)

이러한 접근 방식을 통해 Netflix는 사용자가 새로운 콘텐츠를 선택하는 방법에 대해 의미있는 개선을 했습니다. 대단합니다.

콘텐츠의 첫 관문인 포스터는 정말 중요합니다.

성인은 첫번째, 어린아이들은 두번째 포스터를 선택하지 않을까요? 개인화 Artwork를 통해 사용자 경험을 증대시키는 Netflix에게 박수를 보냅니다.

Read More

Robot이 불러오는 변화들

 

인공지능과 함께 로봇은 이미 우리 생활 곳곳에 파고 들고 있고 큰 변화를 가져올 것으로 예상되고 있다.

과거에는 싼 인건비를 찾아서 동남아등에 공장을 설립했지만, 요 근래 리쇼어링 현상이 발생하고 있다. 로봇 적용으로 인해 인건비 부담이 줄게되었고 물류 비용과 행정적 비용을 고려하면 동남아에 있을 이유가 없어진다.

가장 대표적인 사례가 아디다스(Adidas)의 스피드 팩토리(Speed Factory)이다.

아디다스가 2006년 독알 안스바흐에 만든 스피드 팩토리는 독일정부 + 아헨공대 + 아디다스의 작품이다. 여기에 들어간 기술은 지멘스의 Mind Sphere(클라우드 기반의 IoT)이며 그 외 여러 업체들이 참여해 센서와 시스템을 구축했다.

신발 제조 산업은 대표적 노동집약적 산업이고 인력이 가장 중요했다. 스피드 팩토리로 인해 필요 인력이 가장 크게 줄어들 것으로 보인다. 신발 제조 근로자 75% 이상이 베트남, 인도네시아, 중국등 아시아 지역에 집중되어 있고 타격이 불가피할 것으로 전망된다.

스피드 팩토리의 목적은 다음과 같다.

1. “급변하는 트렌드에 발빠른 대응” - 다른 신발 공장처럼 같은 소재, 디자인의 신발을 계속 만드는 것이 아니라 고객의 주문을 넣으면 원단 직조에서 마감까지 로봇이 처리하고 스타일, 깔창, 소재, 색깔 및 신발끈까지 고객의 요구 사항 그대로 맞춤형으로 생산된다.
2. “저임금 근로자에 대한 의존도 축소” - 스피드 팩토리의 연간 생산량은 약 50만 켤레이다. 여기에 투입된 인력은 약 10명이다. 로봇없이 사람으로 50만 켤레를 생산하려면 약 600명의 근로자가 필요했다.
3. “재고 감소” - 스피드 팩토리는 고객이 제품을 주문하면 생산하는 개념이다. 재고 관리에 대한 부담이 적어진다.

만약, 모든 제조업체가 스피드팩토리를 도입한다면 어떤 일이 발생할까?

과거 산업 혁명 시절에도 기계로 인해 인간의 일자리가 사라질거라고 생각했었지만, 다른 형태의 일자리를 창출하게 되었다. 하지만 이번은 조금 다르다. 아디다스가 독일에 스피드 팩토리를 지으면서 일자리 창출에 대한 기대감이 있었지만 결과적으로는 그렇지 않았다.

로봇으로 대체할 수 있는 일자리는 사라질 것이고, 대체하지 못하는 일자리는 창출 될 것이다. 현재 우리가 일하고 있는 분야에서 우리의 역할이 어떻게 변화하고 로봇을 리드할 능력을 어떻게 갖출지 고민이 필요해보인다.

Read More

GraphQL과 RESTful

 

GraphQL(Graph Query Language)은 Server API를 만들기 위해 Facebook에서 만든 Query Language입니다.

Query Language는 질의문(Query)과 컴퓨터언어(Language)의 조합입니다. 기존에 RESTful이라는 개념이 존재하였고, 그동안 잘 사용하고 있었는데 Facebook은 왜 이런 개념을 만든 것일까요?

https://graphql.org/blog/graphql-a-query-language/에 의하면 아래와 같은 문제점이 존재했다고 합니다.

• 다양한 기기에서 필요한 정보들을 REST로 일일히 구현하기 힘듬
• 각 기기마다 UI/UX가 다르기에 Server에서 일일히 대응하기가 어려움

그래서 Facebook은 서버가 데이터를 노출하는 방법을 정의한 기술 표준이 필요했고 내부적으로 만들어서 사용하다가 2015년도에 오픈소스로 공개하게 되었습니다.

RESTful과 GraphQL의 차이점은 무엇일까요?

RESTful과 GraphQL의 차이점

API Endpoint

REST의 핵심 아이디어는 Resource입니다.각 Resource는 URL로 식별되며 해당 URL 에 요청을 보내 정보를 얻습니다. REST는 Resource의 유형 및 모양과 리소스를 가져오는 방법이 결합된 방식을 제공한다는 점입니다.

GET / books / : id 
GET / authors / : id 
GET / books / : id / comments 
POST / books / : id / comments

GraphQL의 경우는 위에서 언급한 두 개념이 완전히 분리되어 있습니다. 전체 API를 위해서 단 하나의 Endpoint만 사용합니다. github의 경우 v3 API와 v4의 API의 기술 표준이 다릅니다. v3의 경우는 v3 루트 element하위에 각 Resource들의 endpoint가 존재하지만, v4의 경우 루트 element만 존재합니다. 이 의미는 사용측에서 Query 스키마 유형을 만들어야 합니다.

type Query {
  book(id: ID!): Book
  author(id: ID!): Author
}
type Mutation {
  addComment(input: AddCommentInput): Comment
}
type Book { ... }
type Author { ... }
type Comment { ... }
input AddCommentInput { ... }

API Response

RESTful의 경우 각 API마다 spec이 존재하며, 정의해놓은 format대로 각 Resource의 정보를 Response합니다.

GraphQL의 경우 사용하는 측에서 Response 구조를 원하는 방식으로 변경할 수 있습니다.

이 둘간의 차이점을 보여주는 그림입니다.

GraphQL을 사용하게되면 아래의 장점을 지니게 됩니다.

• HTTP 요청 횟수를 줄일 수 있기 때문에, Network Latency가 감소됩니다.
• HTTP 응답 Size가 줄게 됩니다.

결론

그동안 RESTful은 N+1 쿼리의 제약에서 자유롭지 못했습니다. 특정 사용자가 작성한 글의 모든 내용을 보고 싶다고 하면 모든 글의 목록을 가져오고 내용은 목록 리스트를 루프를 돌면서 fetch를 해야 했었습니다. 그리고 필요 정보만 가져오고 싶어도 API에서 제공해주는 모든 정보를 받은 후에 필터 처리를 해야 했었습니다. 이런 점은 성능에도 영향을 주게 되었고요.

물론, RESTful의 단점을 개선한 GraphQL도 장점만 존재하는 것은 아닙니다. 높은 학습 곡선이 존재하고 적절한 상황에서 사용해야 합니다.

Read More

Back-end for Front-end Pattern (BFF)

소프트웨어 구성의 진화

완전하게 분산된 아키텍처가 실행되기 전에는 일반적으로 하나 이상의 계층으로 어플리케이션을 작성합니다.

이러한 아키텍처는 매우 복잡할 순 있지만, 전반적으로 다른 어플리케이션간에 선을 그려서 시작지점과 끝지점을 명확하게 구분할 수 있었습니다. 각 어플리케이션마다 데이터 사본과 공통 비즈니스 프로세스가 중복되고 시간이 지남에따라 데이터를 공유하고 비즈니스 로직을 재사용 할 수 있는 어플리케이션이 필요했으며 단순했던 아키텍처는 약간 복잡해졌습니다.

더 많은 재사용과 통합이 필요함에 따라 집단적 사고 방식은 “서비스”라는 매우 추상적인 개념에 정착했습니다.

단순한 사용자 인터페이스였던 LOB(Line-of-Business)시스템이 점점 증가하여 UI기반의 시스템으로 작성되고 있습니다.

모노리틱 파괴

2011년 SoundCloud의 웹사이트는 아래와 같았습니다.

모두 하나의 시스템에 존재했었습니다.

SoundCloud의 경우 Back-end 시스템을 매우 간단한 형태로 생각을 했었습니다.

위의 사고 방식은 큰 상자를 하나의 모놀리틱으로 구현하는 것을 의미합니다. 사실 하나의 큰 상자는 아래처럼 되어 있습니다.

사실 SoundCloud는 하나의 시스템을 가지고 있지 않았고, 여러 구성요소가 존재하는 플랫폼을 가지고 있었고, 이 아키텍처에 대한 문제점을 발견하고 마이크로서비스를 사용하기로 결정했습니다. 그래서 아래와 같이 아키텍처를 변경했습니다.

위의 아키텍처를 수립할때 가장 중요한 점은 새로운 기능에 대한 출시일 단축이었습니다. 그리고 위의 아키텍처 수립당시에는 거의 모든 사용자는 웹에서 서비스를 사용했었습니다. 그러나 사용자층은 웹보다 모바일을 많이 사용하기 시작했습니다. SoundCloud는 안드로이드와 iOS를 위한 모바일 클라이언트를 제공하고 있었습니다. 기존 웹 어플리케이션과 마찬가지로 API를 통해 모바일 클라이언트를 지원했습니다.

SoundCloud의 과제

자체 API를 바탕으로 제품을 구축하는 것이 API가 높은 품질을 유지하고 항상 최신 상태를 확인할 수 있는 가장 좋은 방법으로 인식되었습니다. SoundCloud는 이 접근 방식에 대해 몇가지 문제점을 발견했습니다. 첫번째 문제는 제품 개발에 대한 근본적인 문제였습니다.

단일 프로필 페이지를 생성하려면 아래와 같이 여러 API를 호출해야 합니다.

• GET /tracks/1234.json (저자)
• GET /tracks/1234/related.json (관련 트랙 추천)
• GET /users/7123.json (트랙 작성자 정보)
• GET /users/me.json (현재 사용자 정보)
• …

위의 API들을 병합하여 사용자 프로필 페이지를 만들게 됩니다. 위의 아키텍처에서는 네트워크 병목 현상이 존재 했었고 새로운 것을 추가할때마다 모든 클라이언트가 쉽게 사용할 수 있도록 많은 시간을 투자해야 했습니다.

Front-end를 위한 Back-end

위의 아키텍처로 수립한지 약 1년후, SoundCloud는 새로운 iOS 어플리케이션을 개발하기 위한 준비를 시작했습니다.이것은 사용자 환경을 변화시키는 대규모 프로젝트였고, 아키텍처팀은 위의 문제들이 프로젝트의 방해물이 된다는 것을 알았습니다. 아키텍처를 다시 고민해야 하는 시점이었습니다.

Google의 첫번째 제안 솔루션은 모바일 및 웹용으로 서로 다른 API를 사용하는 것입니다. 이 아이디어는 클라이언트가 API를 소유하고 있는 팀을 가지고 있으면, 상호간의 조정이 필요하지 않으므로 훨씬 빨리 움직일 수 있다는 것입니다.

궁극적으로 코드를 단순화하고 성능을 향상 시켰습니다. BFF는 어플리케이션의 API가 아니라 클라이언트 프로그램의 일부라는 사실을 발견했습니다.

결론

SoundCloud는 생산성을 더욱 향상시키는 방법을 연구하기 시작했습니다. 모든 어플리케이션에 동일한 사용자 프로필 페이지가 존재했기 때문에 모든 BFF가 데이터를 가져와서 병합하는 과정중에 많은 중복코드가 있었습니다. 그래서 API를 묶어서 비즈니스 로직을 제공하는 서비스가 필요했습니다.

시간이 지남에 따라 이런 상황이 점점 더 많이 발견되었고, 아키텍처는 이 부분을 포용하면서 변화되었습니다.

Sources

• http://philcalcado.com/2015/09/18/the_back_end_for_front_end_pattern_bff.html

Read More

Netflix Metacat : 큰 데이터를 발견하고 의미있게 만들기

대부분 기업에는 다양한 데이터 형식으로 된 많은 양의 데이터와 수많은 데이터 소스가 있습니다. 그리고 데이터 소스로 부터 데이터를 분석합니다. Netflix의 데이터웨어하우스는 Amazon S3, Druid, Elasticsearch, Redshift, Snowflake 및 MySQL에 저장된 많은 양의 데이터 세트로 구성됩니다. 그리고 Spark, Presto, Pig/Hive를 이용하여 데이터 세트를 처리합니다.

Netflix는 다양한 데이터 소스를 “단일” 데이터웨어 하우스로 상호 운용하기 위해서 Metacat을 구축했습니다. 본 글에서는 데이터를 쉽게 찾고, 처리/관리하기 위한 메타 데이터 서비스인 Metacat을 만들게된 이유에 대해서 기술합니다.

목표

Netflix의 빅데이터 플랫폼의 핵심 아키텍처에는 세가지 주요 서비스가 존재합니다.

1. 실행 서비스(Genie)
2. 메타 데이터 서비스
3. 이벤트 서비스

Netflix가 플랫폼을 구축할때, Pig를 ETL언어로 Hive를 ad-hoc 쿼리 언어로 채택했습니다. Pig는 기본적으로 메타 데이터 시스템을 가지고 있지 않기 때문에 두 시스템간에 상호 운용될 수 있는 시스템을 구축하는것이 이상적이었다고 합니다.

그래서 모든 데이터 저장소를 위한 federated metadata access layer 역할을 하는 Metacat이 탄생했습니다. Metacat은 세가지 주요 목표를 제공합니다.

• 메타 데이터 시스템 통합뷰
• 데이터 세트에 대한 메타데이터용 통합 API
• 데이터 세트에 대한 사용자 메타 데이터 저장소와 임의의 비즈니스

크고 분산된 형태의 데이터세트를 가지고 있는 다른 회사들도 Netflix와 비슷한 어려움을 겪었고 Apache “Atlas”, Twitter “Data Abstraction Layer”, Linkedin “WhereHows”는 유사한 문제를 해결하기 위해 작성되어졌습니다.

Metacat

Metacat은 다양한 데이터 저장소의 메타 데이터에 접근할 수 있는 Federation 서비스 입니다.

데이터 세트에 대한 비즈니스 및 사용자 정의 메타 데이터만 직접 저장하고 전체 검색을 위해 Elasticsearch에 데이터 세트에 대한 모든 정보를 기재합니다.

다음은 Metacat에서 제공하는 기능입니다.

• 데이터 추상화 및 상호 운용성
• 비즈니스 및 사용자 정의 메타 데이터 저장소
• 데이터 검색
• 데이터 변경에 대한 감사 및 알림
• Hive 메타 스토어 최적화

데이터 추상화 및 상호 운용성

Pig, Spark, Presto/Hive와 같은 여러 Query 엔진은 Netflix에서 데이터 처리 및 사용하는데에 활용됩니다. 이 부분에 공통 추상화 계층을 도입함으로써 데이터 세트를 서로 다른 엔진에서 상호 교환적으로 접근 할 수 있습니다.

Hive 에서 데이터를 읽는 Pig 스크립트는 Pig 유형의 Hive열 테이블을 읽을 수 있습니다. 하나의 데이터 저장소에서 다른 데이터 저장소로의 데이터 이동을 위해 Metacat은 대상 테이블의 데이터 형식을 사용하여 대상 데이터 저장소에 새 테이블을 생성하는 것을 도와줌으로써 프로세스를 쉽게 만들 수 있습니다.

Metacat thrift 서비스는 Spark/Presto와의 손쉬운 통합을 위해 Hive Thread 인터페이스를 지원합니다. 이를 통해 모든 메타 데이터 변경 사항을 하나의 시스템으로 전달 할 수 있게됩니다.

비즈니스 및 사용자 정의 메타 데이터

Metacat은 스토리지에 데이터 세트에 대한 추가 비즈니스 및 사용자 정의 메타 데이터를 저장합니다. 현재의 비즈니스 메타 데이터를 사용하여 다른 유즈케이스와의 연결정보, 구성정보, 메트릭(Hive/S3 파티션 및 테이블) 및 테이블 TTL을 저장합니다.

사용자 정의 메타 데이터는 사용자가 자신의 용도로 설정 할 수 있는 자유 형식의 메타 데이터 입니다. 비즈니스 메타 데이터는 논리적/물리적 메타 데이터로 분류 됩니다. 테이블과 같은 논리적 구조에 대한 비즈니스 메타 데이터는 논리적 메타 데이터로 분류됩니다.

데이터 분류 및 ETL 처리 표준화를 위해 메타 데이터를 사용하게되고 테이블 소유자는 비즈니스 메타 데이터의 테이블에 대한 감사 정보를 제공 할 수 있습니다.테이블 속성(열 기본값과 유효성 검사 규칙)을 제공할 수 도 있습니다. 테이블이나 파티션에 저장된 실제 데이터에 대한 메타 데이터는 물리적 메타 데이터로 분류됩니다.

ETL처리는 작업 완료시 데이터에 대한 메트릭을 저장하고 나중에 유효성 검사에 사용됩니다. 동일한 측정 항목을 사용하여 데이터의 비용과 공간을 분석할 수 있습니다. 두 테이블이 동일한 위치를 가리킬 수 있는 경우에는 두 테이블이 동일한 실제 메타 데이터를 가질 수 있지만 다른 논리 메타 데이터도 가질 수 있기 때문에 논리적 vs 물리적 메타 데이터를 구별하는 것이 중요합니다.

데이터 검색

데이터 소비자로서 다양한 데이터 세트를 쉽게 찾고 발견 할 수 있어야 합니다. Metacat은 Elasticsearch에 스키마 메타 데이터 및 비즈니스/사용자 정의 메타 데이터를 게시하여 데이터웨어 하우스의 정보를 전체 텍스트로 검색할 수 있도록 해줍니다. 또한 Big Data Portal SQL 편집기에서 자동 제안 및 자동 완성 기능을 사용할 수 있습니다. 데이터 세트를 카탈로그로 구성하면 소비자가 정보를 탐색하는 데 도움이 됩니다. 태그는 조직 및 주제 영역을 기반으로 데이터를 분류하는데 사용되고 데이터 수명주기 관리를 위한 테이블 식별도 가능합니다.

데이터 변경 알림 및 감사

Metacat은 데이터 저장소의 중앙 게이트웨이로써 메타 데이터 변경 및 데이터 업데이트를 캡쳐합니다. 테이블 및 파티션 변경에 대한 푸시 알림 시스템도 제공합니다. 현재 Netflix는 이 매커니즘을 사용하여 분석을 위해 자체 데이터 파이프 라인(Keystone)에 이벤트를 게시하여 데이터 사용 및 추세를 분석 합니다. 또한 Amazon SNS에도 게시하고 있습니다. Netflix의 경우 데이터 기반 아키텍처를 이벤트 중심 아키텍처로 발전시키고 있습니다. SNS에 이벤트를 게시하면 데이터 플랫폼의 다른 시스템이 이러한 메터 데이터 또는 데이터 변경 사항에 적절하게 대응 할 수 있습니다. 예를 들어 테이블을 삭제하면 S3 웨어 하우스 관리자 서비스가 이벤트를 구독하고 S3의 데이터를 적절하게 정리할 수 있습니다.

Hive 메타스토어 최적화

RDS를 기반으로 하는 Hive 메타스토어는 부하가 높으면 성능이 떨어집니다. Netflix는 메타 스토어 API를 사용하여 파티션을 작성하고 읽는데 많은 문제를 발견했습니다. 그리고 해당 API를 더이상 사용하지 않기로 결정합니다. 대신 파티션 읽기 및 쓰기를 위해 백업된 RDS와 직접 연동하는 Hive Connection을 개선했습니다.

Next Steps

Netflix는 Metacat을 구축하는데 많은 노력을 기울였습니다. 그러나 더욱더 데이터웨어 하우스 환경을 향상시키기 위해 계속해서 작업해야 하는 몇 가지 추가 기능이 존재합니다.

• 테이블 히스토리를 제공하기 위한 스키마 및 메타 데이터 버전 관리 (특정 컬럼에 대한 메타 데이터 변경 사항을 추적하거나 시간 경과에 따라 테이블 크기 경향을 볼 수 있도록…)
• 테이블 액세스 빈도과 같은 메타 데이터를 Metacat에 집계하고 테이블의 중요도 순위를 지정하는데 활용하기 위한 데이터 계보 서비스
• Elasticsearch 및 Kafka와 같은 데이터 저장소에 대한 지원 추가
• Pluggble metadata validation — 비즈니스 및 사용자 정의 메타 데이터는 자유 형식이기에 메타 데이터의 무결성을 유지하려면 유효성 검증이 필요합니다. Metacat은 메타 데이터를 저장하기 전에 실행할 수 있는 유효성 검증 전략을 통합 할 수 있는 Pluggable metadata 아키텍처를 수립해야 합니다.

Sources:

• https://github.com/Netflix/metacat
• https://medium.com/netflix-techblog/metacat-making-big-data-discoverable-and-meaningful-at-netflix-56fb36a53520

Read More

대체 코드?

동아비즈니스에서 흥미로운 주제를 발견했다. 바로 익숙하면서도 새로운 “대체 코드의 힘” 일반적인 사람들은 익숙하면서도 낯선 것에 끌린다.

너무 익숙하면 진부하다 여기고, 낯설기만 하면 이질감이 느껴지기 때문이다. 익숙하면서도 새로운 것을 만들려면 기존 시스템의 일부를 새로운 것으로 대체해야 한다. 아래는 이런 대체 코드에 대한 사례이다.

세계대전 이후 이탈리아는 물자가 부족한 상황이 지속되었고 수많은 가죽업체가 도산하는 열악한 상황이었다. 1947년 구찌는 가죽이 아닌 일본산 대나무를 손잡이로 활용한 Bamboo Bag을 내놓았다. 처음 뱀부백은 부드러운 돼지 피혁으로 제작한 가방에 대나무를 가열하여 구부린 손잡이를 부착한 작은 사이즈의 핸드백이었다. 대나무를 손잡이로 사용한 뱀부백은 가죽이 아닌 재료들을 핸드백에 어떻게 사용해야 하는지를 보여준 대표적인 사례라고 할 수 있다.

대체코드가 가장 많이 활용되는 분야는 광고이다. 사람들의 이목을 끌기 위해 “절반은 새롭고 절반은 익숙”해야 하는 원칙이 있기 때문이다. 위의 그림은 이제석씨가 디자인한 살충제 광고이다. 폭스바겐 비틀이 뒤집혀 있는 광고를 보면 살충제 성능이 엄청난 것처럼 보여진다. 일반적으로 흔히 말하는 창의성은 전부 새롭게 구성된 것이 아니다. “일부는 익숙하게 일부는 새롭게”라는 명제를 현실에 구현한 것이다.

Read More