상세 컨텐츠

본문 제목

Apache Kylin 기본 개념 정리

IT/프로그래밍

by James Lee. 2019. 2. 10. 20:14

본문

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

Kylin은 무엇인가요?

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

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

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

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

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)" 모양이라 해서 붙인 이름

큐브

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

(큐브 예시 : 원본 출처)

요약

  • 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 인터페이스 → 모든 데이터베이스에서 호환됨

효율성

  • 어느정도 쿼리 패턴이 정해져있어 CubeModeling할 수 있다면 Hive를 사용하는 것보다 Kylin을 사용하는 것이 유리함
    • 데이터 setcardinality가 정해져 있는 경우
  • 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를 정리할 예정이다.

참고자료


관련글 더보기

댓글 영역