Apache Kylin 기본 개념 정리

네, Kylin은 신화 속의 이 기린이 맞습니다. 카일린이라고도 부르기도 합니다.

Kylin은 무엇인가요?

• Hadoop Ecosystem을 기반으로 한 오픈 소스 분산 분석 엔진(Distributed Analytics Engine)
• SQL 인터페이스와 다차원 분석(OLAP)을 제공
• 데이터의 어떤 면을 볼 건지 미리 정의 (Cube)하여 결과 집합에 대한 데이터를 미리 만들어두고, SQL 쿼리를 통해 미리 만들어놓은 데이터를 수 초(sub-seconds) 이내에 빠르게 조회

단순하게 표현하면 대용량 데이터 조회시 시간이 오래 걸리는 이슈를 해결하기 위하여
"저장 공간을 왕창 쓰는 대신, 속도 이득을 얻는다." (물론 실제로는 이거보다 더 복잡하다.)

Kylin이 무엇인지 이해하기 위해서는 OLAP와 Data Cube에 대한 이해가 선행되어야 한다.

아래 2개의 글을 참고하자.

• [대용량DB] OLAP 이해하기
• OLAP (Online Analytical Processing) 이란?

OLAP에 대해서도 정리 중인데, 정리가 다 되면 위 링크는 정리한 글로 대체 예정이다.

Kylin 주요 구성 요소

Kylin 아키텍처(원본 출처)

1. 데이터 저장소

• 원본 데이터를 Hive에 스타 스키마 형태로 저장

2. 메타데이터 저장소

• 스타 스키마에 대한 정보, 큐브 디자인에 대한 정보 등의 메타데이터가 저장됨

3. 큐브 저장소

• 큐브 빌드 엔진이 빌드한 큐브가 데이터베이스 형태로 HBase에 저장된다.

4. 질의 엔진

• RESTful API, JDBC, ODBC 등으로 데이터에 대한 질의 가능
• 사용자에게 받은 질의를 분석해 질의 결과를 HBase의 큐브에서 가져올지 Hive의 원본 데이터에서 가져올지 결정
  • 질의한 값을 큐브에서 가져올 수 있을때 (원하는 데이터가 큐브에 전부 존재할 때)는 큐브에서, 아닌 경우는 원본 데이터에서 가져옴
  • 당연한 얘기지만 질의 결과를 큐브에서 가져올 때는 빠르고, 원본 데이터에서 가져올 때에는 상대적으로 느림
• Kylin 웹 애플리케이션을 실행하는 Tomcat과 질의 분석 및 실행 계획을 생성하는 Calcite로 이루어져 있다.
  • Tomcat : RESTful API를 제공하기 위한 WAS로 사용
  • [Calcite](https://calcite.apache.org/) : 데이터 관리 시스템 구축을 위한 오픈소스 프레임워크. Kylin에서는 이 Calcite를 SQL 엔진으로 사용한다. (참고)

5. 큐브 빌드 엔진

• 원본 데이터에 Map & Reduce 작업을 통하여 큐브를 생성함
• 큐브 빌드 프로세스
  • 원본 데이터 → Hive에 저장(스타 스키마 형태 - 팩트 테이블에 관한 상세 정보를 제공) → Map & Reduce 작업을 통해 큐브 빌드

팩트 테이블

• 스타 스키마의 중심에 있는 테이블
  • 예시) 아래 스타 스키마에서 중앙에 있는 Fact_Sales 테이블이 팩트 테이블임
• 어떤 사실에 관한 정보가 기록된 테이블이며, 분석의 시작점
• 2가지 타입의 칼럼을 가짐
  • 차원(Dimension)
    • 차원(Dimension)에 따라 한정된 비즈니스 데이터 수치를 담고 있음
    • 여기서는 날짜 ID(Date_Id), 상점 ID(Product_Id), 제품 ID(Product_Id)
  • 지표(Measure) - 측정 기준
    • 여기서는 판매 횟수(Unit_sold)

이 녀석을 토대로 아래와 같은 분석을 할 수 있다. (외래키 Join을 통해서)

• 특정 상품의 날짜별, 판매점별 판매 횟수(Unit_sold) 분석
• 상품 카테고리별, 날짜별 판매 횟수(Unit_sold) 분석

(원본 출처)

스타 스키마

• 팩트 테이블에 대한 상세 정보를 제공함
  • Date_Id → Dim_Date
  • Store_Id → Dim_Store
  • Product_Id → Dim_Product
• 스타 스키마라는 이름은 스키마 다이어그램이 마치 "별표(star)" 모양이라 해서 붙인 이름

큐브

• 릴레이션 기반의 소스에서 다양한 정보에 대한 선계산 값을 미리 산출하여 저장하는 연산
  • 스타 스키마를 토대로 빌드 됨
• Dimension과 Measure로 구성

(큐브 예시 : 원본 출처)

요약

• Hadoop Ecosystem 기반
• 다차원 분석
  • MOLAP Cube (참고)
    • 다차원 데이터베이스에 기반한 OLAP 아키텍처
    • 결과 값을 다차원 배열로 저장하는 방식
      • 장점
        • 리포팅 할 경우 유리
        • 결과값을 산출하는 과정에서 다차원 배열을 이용하는 경우 릴레이션을 이용하는 경우에 비해 비용이 적게 들어감 (Join을 덜 맺어서)
      • 단점
        • 릴레이션 소스를 다차원 배열로 변경하는 로딩 비용이 들어감
        • 결과 값의 저장에 있어 다차원 배열의 경우 빈셀이 많이 발생(희박성) 하므로 저장 공간의 낭비를 초래할 수 있음. 즉, 데이터가 폭발적으로 증가할 수 있음
          • 스페이스를 왕창 쓰고, 속도 이득을 얻는다!
    • 네트워크 상의 데이터 이동이 최소화 ⇒ 다차원 데이터의 저장과 프로세싱에 동일한 엔진 사용
• 매우 빠른 쿼리(Interactive Query Capability)
  • Hadoop 데이터에 질의 가능
  • 동일한 데이터 세트에 대해 Hive 쿼리보다 훨씬 뛰어남 (공식 doc에는 1초 미만(sub-second)라고 되어 있음)
  • 아래의 3 step을 통함
    1. Hadoop에서 Star / Snowflake 스키마를 식별
    2. 식별된 테이블에서 큐브 생성
    3. ANSI-SQL / ODBC, JDBC / RESTful API를 통해 결과를 얻음
• RESTful API 제공
• 대규모 데이터를 SQL 기반으로 분석
  • ANSI(미국 표준)SQL 인터페이스 → 모든 데이터베이스에서 호환됨

효율성

• 어느정도 쿼리 패턴이 정해져있어 Cube를 Modeling할 수 있다면 Hive를 사용하는 것보다 Kylin을 사용하는 것이 유리함
  • 데이터 set의 cardinality가 정해져 있는 경우
• ex) 광고 로그 조회에서 컬럼 조합이 a, b, c, … 등과 같이 정의되어 있고, 이 컬럼 내에서 조합을 다르게 하여 여러 번 쿼리를 호출하는 경우

왜 쓰는가?

kylin은 다양한 특징을 가진 데이터 플랫폼이고, 그것을 사용하는 이유는 각자 다를 것이다.

우리의 경우는

1. 대용량 데이터를 빠른 시간 내에 조회할 수 있어야 한다.

   → Space(데이터 크기)를 왕창 쓰고, 속도 이득을 얻는다.

   → HyperLogLog 알고리즘을 활용하여 Distinct count도 빠르게 수행한다.

2. 개발 공수가 적어야 한다.

   → Kylin은 많은 기능을 포함하고 있고, SQL을 사용하기 때문에 쿼리 작성이 간편했다.

   • 예를 들어, Spark을 썼다면 RESTful API 형태로 데이터를 제공받기 위해서 별도의 RESTful API를 구축하고 배포해야 했겠지만, Kylin에서는 RESTful API가 내장되어 있다.

느낀 점

• 작년에 람다 아키텍쳐를 적용한 프로젝트를 진행했다. 우리 람다 아키텍쳐 중 핵심은 Kylin이었다. 우리 팀은 사내에서 제일 먼저 Kylin을 도입했다.
• 일정 상 Kylin이 뭔지, 어떤 장단점이 있는지 대략적으로 파악한 상태에서 개발을 진행했다. 사실, 당시 상황에서 우리에게 Kylin은 최선의 선택이었다. 다른 선택지가 없었다.
• 나는 철저히 Kylin을 사용자 입장에서만 사용해왔다. Kylin에 대한 노하우가 부족하다는 것을 느꼈다. 올해는 Kylin을 더 공부해야겠다고 느꼈다.
• 이번 장에서는 Kylin의 전체적인 개념을 다뤘고, 다음 포스팅에서는 Kylin의 핵심 알고리즘인 HyperLogLog를 정리할 예정이다.

참고자료

• Kylin 공식 문서
  • 기술 용어
• 빅데이터 다차원 분석 플랫폼, Kylin
• 팩트 테이블