[Volume 2][Chapter 06] Q&A

[KKambi]

Parquet (파케이)

컬럼 방식으로 저장하는 데이터 파일

• 압축 효율 증가
• 컬럼별로 유리한 인코딩 사용 가능
• 필요한 컬럼의 데이터만 조회하기 쉬움
• 쿼리할 때 개연성이 없는 데이터를 신속하게 건너뛸 수 있음

★대신 데이터 추가 시 불리함 (행 기반은 그냥 추가하면 되는데)

Star schema (별 모양의 스키마)

중심이 되는 팩트 테이블과 연결된 차원 테이블들이 존재한다.

• 정규화 X (중복 O)
• 팩트테이블
  • 사실을 포함하는 수치 정보 (낮은 수준의 데이터)
  • 차원 테이블에 매핑되는 외래 키

핫스팟 해결 - Local Global Aggregation

왼쪽처럼 특정 집계 서비스에 데이터가 편향될 수 있다. 책에서는 스케일 아웃으로 대처했다.

• Local-Global Agg는 집계 노드로 보내기 전, 미니 배치에서 사전 집계를 수행하는 방법
• 오른쪽에서 color에 따라 사전 집계를 수행했고, Global Agg에서 편향이 사라졌다.

핫스팟 해결 - Split Distinct Aggregation

위와 같이 color를 group by 조건으로 사용하면서 + id를 distinct로 사용하려면 Local-Global Agg를 사용할 수 없다. id의 cardinality가 높으면 중복이 적어 편향은 여전히 발생한다.

Split Distinct는 각 미니 배치에서 사전 집계를 수행하지 않는다. 대신 id를 n개의 그룹으로 나눈다. 아래 슈도 코드를 보면 해쉬코드로 4개의 그룹으로 분할했다.

# Apache Flink SQL
SELECT color, SUM(cnt)
FROM (
    SELECT color, COUNT(DISTINCT id) as cnt
    FROM T
    GROUP BY color, MOD(HASH_CODE(id), 4)
)
GROUP BY color

[kihyun-yang]

시계열 데이터베이스 - TSDB

• https://datamoney.tistory.com/287
• 특정 상황에서 RDBMS의 성능 이슈를 보완할 수 있는 선택지가 될 수 있을 듯.
  • ex) 쓰기 및 시간 범위 질의에 최적화

카프카 Exactly once

• 카프카 사용 시 Exactly once를 보장하기 위한 방법
  • https://blog.voidmainvoid.net/504

맵리듀스

• https://songsunbi.tistory.com/5

[janeljs]

p. 206

• star schema
  • https://www.integrate.io/ko/blog/snowflake-schemas-vs-star-schemas-what-are-they-and-how-are-they-different-ko/

p.208

• kappa에서는 일괄 처리와 스트리밍 처리 계층 구분 없이 하나의 스트림 처리 엔진을 사용하는데 이로인해 발생하는 문제는 없을까?
  • https://dev-mystory.tistory.com/160
  • https://pynomial.com/2022/05/lambda-vs-kappa-architecture-how-to-choose-one-for-my-business/

    p. 225

• hive
  • 방대한 규모에서 분석할 수 있는 내결함성을 갖춘 분산 데이터 웨어하우스 시스템
  • 관계형 데이터베이스는 중소 규모의 데이터 세트에 대한 대화형 쿼리를 위해 설계됨 → 대규모 데이터 세트 처리에 한계
  • Hive는 배치 처리를 사용하므로 대규모 분산 데이터베이스에서 신속하게 작동함

[easyfordev]

이번 챕터는 저희 조직에서 하는 일을 설명하는 부분이라서, 다른 챕터보다는 이해가 잘 되었고, 개인적으로는 현재 우리 조직의 설계와 비교하며 읽게 되었습니다. 담당자로서(?) 관련해서 책과 의견이 조금 다른 부분 등 의견을 공유해볼게요.

의견

• 197p. API의 필터링 전략

  • 

  • 이렇게 설계하면 모든 조합의 경우의 수를 필터 테이블에 넣어놔야 하는데 운영상 효율적인지 모르겠다.

  • 문제가 되는 상황을 예를 들면, 대시보드에서 요청을 보낼 때, filter_id라는걸 알아야만 요청을 보낼 수 있게 되는데...

    • 사용자 입장에서 ‘region은 US인 집계 결과를 보여줘’ 이런식으로 요청을 보낼텐데,
    • 사용자 클릭값(region=US)으로 조건을 입력 받고 → 이에 해당하는 filter_id를 매번 대시보드 내부적으로 구해서(programing적 요소가 반드시 들어가야함) → 그리고 API를 호출한다..? 이게 쉽지 않을 것 같음

  • 그리고 집계를 1분마다 하는데, 하나의 이벤트마다 여러개의 filter_id 조건을 각각 먹여서 여러개의 row로 풀어서 집계하는게 1분 안에 성능측면에서 가능한가..?도 의문

• 199p. Columnar 저장 방식
  • 책에서 이 구성이 많은 사람에게 낯설 것이라고 되어있음
  • 따라서 우리 조직은 맨 처음에는 단순 text로 쓰고(row를 무제한으로 별도 가공 없이 확장 가능하므로) → 배치로 parquet로 가공해서 데이터 압축률, 조회 성능을 높여서 쓰고 있음. 이후 text파일은 삭제
• M분동안 가장 많이 클릭된 상위 N개 광고 아이디 반환 방법 - 여러모로 좋은 설계라는 생각은 들지 않음
  • 201p. 두번째 메시지 큐에 입력되는 상위 N개 광고
    • 
    • 사용자의 요구사항을 고려하면 항상 N이 변할텐데, 이렇게 저장하는게 좋은 설계인가?에 대한 의문이 든다.
  • 213p. 슬라이딩 윈도우
    • (데이터를 저장하지 않는다면 괜찮겠지만), 마찬가지로 N분이 계속 변한다는 점에서 유의미한 설계 방식인지 의문이 든다.
    • 텀블링 윈도우 방식으로 하고, 사용자 질의에 맞게 집계해서 나가는게 맞는 것 같음
• 206p. 1분 간격 집계
  • 페이스북, 구글 규모인데 1분안에 집계가 되는가..?에 대해서는 맵리듀스 특성을 고려하면 어렵다고 생각함
  • 1분 단위로 집계를 돌리는 것은 가능 하지만, 맵리듀스 앱이 뜨고 완료되는데 수분 이상 소요될 것이기 때문에 완료 시간은 점점 밀릴 것
  • 1분 단위로 집계를 돌리고 -> 수분 뒤에 확인 가능한 요구사항이면 수용 가능할 것 같음

우리도 이렇게 하고 있어요

• 저장소 종류
  • 카산드라가 아닌 HDFS에 저장 + Hive라는 쿼리 엔진 활용
• 스타 스키마
  • 필터링 기준(집계 기준)이 정말 다양하기 때문에 필터 테이블을 별도로 두는 것보다 이렇게 하는게 좋음
  • 다만, 일반적인 스타 스키마에 대한 설명처럼 dimension 테이블을 따로 두는 방식은 아직 사용하지 않으며, 단순히 테이블에 여러 필터링 조건을 여러개의 컬럼으로 쭉 풀어두는 방식을 사용 중
• 이벤트 시각과 처리 시각의 차이
  • 이거 되게 중요한 문제인데 책에서 잘 짚었다. 지금 우리는 둘 다 기록하되, 발생 시간 기준으로 처리하고 있고, 1시간 이내로 늦게 도착한 이벤트까지만 받아주는 설계를 취하고 있음
• 집계 서비스의 규모 확장에 방법 1(ad_id별로 별도 처리 스레드를 나누는 것)보다 방법 2(YARN같은 외부 리소스 매니저에 배포하느 ㄴ방식)을 많이 쓰는 이유는 1은 직접 구현해야 하고 2는 오픈소스이기 때문
• 핫스팟 문제 - 더 많은 집계 서비스 노드를 할당하여 완화
  • 사실 이 부분은 책에서 말한 것처럼, MapReduce나 Yarn이 내부적으로 알아서 처리해주기 때문에, 시스템 개발자(운영자)는 집계 서비스 노드의 CPU 사용량, 메모리 사용량, OOM 발생 여부나 빈도를 보고 노드를 추가해야하는 시점을 판단하면 된다.
• 조정 : 우리도 이렇게 하고 있고, 조정의 윈도우는 1시간과 1일 모두 해줘야 가장 정확함. 1시간에서 발견 안되었던게 1일에서 발견되기도 함

질문

• Kappa 아키텍처에서 그림상 일괄 처리 엔진은 없는데, 실시간 처리 엔진과 같은 엔진을 사용하기 때문에 그림상 생략한걸까?