빅지기 스터디 2주차 정리

 

질문 1)

1.비정규화 테이블을 구성할 경우 하나의 팩트 테이블이 여러개의 디멘젼 테이블을 참조하게되면 아래 그림처럼 지네효과(the-centipede-effect)라는 현상이 발생한다고 하는데, DW 모델링 관점에서는 이런 현상이 발생하는 것을 지양해야 한다고 합니다. 주요 디멘전 테이블(전사 운영 시스템에서 공통적으로 사용하는 데이터가 있는 디멘전 테이블)이 하나의 큰 팩트 테이블로 관리가 되기 때문에 각 디멘젼별 세부적인 속성들은 관리가 되지 않기 때문이라고 하더라고요. 예를 들어 고객 관리 디멘젼 테이블의 기본적인 값들(나이, 성별, 구매제품)만 관리되기 때문에 이외에 세부적인 속성들까지는 관리할 수 없는 문제가 있다고 합니다.

혹시 실무에서 모델링을 하시고 계시는 분이 있다면 위와 같은 문제가 발생하는 것을 고려하시는지 궁금합니다. (실제로 제가 다니는 곳만해도 저런 형식의 지네 형식의 테이블이 많은 것 같네요…)

2.열 지향 스토리지는 칼럼 단위로 데이터가 저장되므로 칼럼의 수가 아무리 늘어나도 성능에 영향을 주지 않는다고 하는데(P.81) 성능 저하는 일어나지 않는다고 하더라도 현업에서 어느정도 칼럼의 수를 제한을 두는 편인가요?

답변)

1. 그래도 필요한 세부적인 속성까지는 디멘젼 테이블에 넣어야 관리 및 활용이 되므로 회사차원에서 DS/DE가 쿼리성능을 보아가며, 추가 및 삭제 하는 것으로 알고 있습니다,

2. 아무리 열지향 스토리지라고 해도 리소스에 무한은 없으니 서버성능에 악영향 -> 모든 어플리케이션에 악영향이 생기므로, 가지고 있는 리소스에 따라서 제한을 해야합니다. 보통 서버에 85%~90% 사이의 성능만 항상 사용하도록 조정하는 편이네요.

---

질문 2 - 내 질문)

1. 책에서 행지향 데이터베이스보다 MPP 데이터베이스를 설명하면서, 열 지향 데이터베이스 위주로 설명이 된 듯한데, 실무에서도 행지향 데이터베이스보다는 열 지향 데이터베이스의 비중이 높은지 궁금합니다.

2. 시각화 도구에 스프레드시트, 대시보드 도구, 주피터 노트북 등 여러 가지가 있는데, 실무에서 시각화 도구를 사용하시는 분들은 어떤 툴을 사용 중이신지(혹은 사용 경험에 대해) 궁금합니다. 어떤 장단점이 있는지 경험을 듣고 싶습니다.

 

답변)

1. 회사마다 방침 및 DS/DE의 의사결정에 따라 구분되는데요. 행지향이 이 책에서 설명이 적은 것은 이미 알려진 사실이 많을뿐입니다. 아직도 수많은 의사결정에는 행지향 데이터베이스가 널리 사용됩니다. 열지향 데이터베이스는 수PB의 데이터를 저장하거나 할때 효과적 및 다른 대안이 없어서 사용하게 됩니다. (물론 데이터 분석에 열지향 데이터 베이스가 이점이 확실히 존재합니다.)

2. 저는 분석을 시작한 이후로는 쥬피터 노트북을 메인으로 사용하고, 이를 배포할떄는 *.py형태로 배포했었던거 같네요. 장단점은 비용의 차이, 협업유무 등에 따라 달라진다고 생각합니다.

 

2. 리대시 - 대시보드를 간결하게 보여주기는 편함, 작성하거나 수정하려면 쿼리를 알아야함, 데이터소스를 각각 연결해서 쓰는데 회원정보가 rdb에 있고 ga행동데이터가 빅쿼리에 있으면 join해서 쓸수없음, 호스팅 서비스 종료해서, 셀프 호스팅해야함

태블로 - 사용자 케바케일거 같지만, 리대시보다는 사용방법에 대해학습이 좀 필요했는데 어려워했고 이해도가 떨어져서, 잘 활용을 못했음

노트북보다는 코랩썼었는데(구글스프레드시트를 사용해서) 현업이 재생 재생 재생 누르는 순서만 알려주면 그정도는 하는거 같았음 ㅎㅎ

 

1. 개인적으로는 아직까지는 그래도 행지향 데이터베이스가 더 많은 것 같다고 생각합니다

2. 그리고 시각화 같은 경우에는 조금 다른 용도지만 저희는 데이터 수집 모니터링으로 Grafana를 활용한다정도? 말씀드릴 수 있겠네요

 

+)RDB 관련해서는 어떻게 진행하는지… 행지향은 주로 join해서 쓰는 방향,,,

RDB안에서 열로 바꿀때는 뭔가 쉽게 하는 방향이 있는 것 같다

필요한 데이터만 새로운 테이블로 주기적으로 데이터를 적재하면 그게 데이터 마트라고 부를 수 있을 것 같다.

→ 그래서 데이터레이크에 쌓아두고 필요한 것만 뽑아서 GPDB에서 데이터 마트를 구성합니다.

 

+)제가 데이터웨어하우스 개념에 맞는 작업을 하려고 빅쿼리에 부분적으로 데이터를 이관해서 쓰려고 햇는데 결론적으로 다른 데이터들이 rdb에 있어서..

전체적으로 공유하고 일을 벌리지 않는이상 rdb에서 벗어나기 힘들더라구여

→ 그쵸 ㅠ 그래서 rdb 데이터를 분석에 맞는 형식으로 어떻게 바꾸는지가 일일 것 같아요 전부 rdb면 상관없는데 아닌 형태의 데이터도 같이 분석을 해야 한다고 하면 맞게 가공을 해야 하니까,,저도 그게 궁금해서 이 책을 찾게되었습니다 ㅎ

→ 그래서 그냥... 빅쿼리는 욕심이였을뿐 데이터가 스몰데이터면 데이터웨어하우스로 rdb를 유지하는것도.. 마냥 틀린부분은 아니라고 책보면서 느끼고 있어요 애매하게 옮기면 결국은 join 해야해서 rdb를...벗어나기 힘들어요... ㅋㅋㅋ

 

+)빅쿼리를 사용하려면 rdb에서 데이터들을 조인해서 가져와야하나요? 빅쿼리를 안써봐서 여쭤봅니다

→ 이미 rdb에 프로덕션데이터나 데이터웨어하우스적인 성격을 현행으로 쓰고 있었어여 근데 하도 데이터웨어하우스로 빅쿼리나 redshift 말하길래... 데이터엔지니어로써 데이터웨어하우스를 빅쿼리로 하려고 꿈꿨는데... 이미 현행중인 대시보드같은거 생각하면 통째로 + 분석가랑 함께해야지.. 혼자 일벌리면 안되겟더라구여

---

질문 3)

열지향 데이터는 멀티 코어를 활용하여 여러 태스크로 쪼갠 후 연산하여 결과를 도출한다 라고 설명하면서 1컬럼의 sum을 구하는 작업이 있었는데요 (p62) 이때는 컬럼의 값을 일정량 분할해 집계하는 형식 이었는데 아래와 같은 상황일때는 분산처리가 어떻게 가능할지 예상? 해봤습니다..ㅎㅎ

가정) 컬럼이 여러개인 데이터에 대해 새로운 컬럼을 만들고 각 컬럼값의 합을 구하게 된다면 병렬처리가 어떻게 진행되는지 궁금합니다

총row는 100만건, core가 300개라고 가정 했을때 예상) new col row1의 값=(col1 row 1) + (col2 row1) + (col3 row1) -> row마다 1core씩 할당 병렬로 동시 300건씩 처리, 메모리에서 (100만건/300번)연산

 

답변)

사실 이 문제는 DE가 어떻게 설계 및 구현하기 나름입니다. 한 row 연산을 1core에서 처리하게 만들고 300 코어(실제는 os가 사용하는 영역을 빼야함)가 300줄씩 처리하게 하는게 효과적입니다. 하지만 동시에 메모리에 올릴수 있는 양에 따라서 batch처리 해야 하겠죠

---

질문 4)

1. 쿼리 연산 속도를 측정하는 방법이 궁금합니다.

2. 데이터 마트를 구성할때 컬럼 안에 들어있는 값의 크기의 영향은 없을까요?

 

답변)

1. Sql의 연산속도를 측정하는 것은 보통 explain이라고하는 DB engine마다 built-in되어 있는 모듈로 보통 확인을 합니다 ex) explain + SQL statement -> 결과를 수치 및 시각화해서 어느 연산 라인에서 병목이 걸리는지, 인덱싱이 제대로 되는건지 등을 파악해 쿼리 속도를 높힙니다.

2. 당연히 영향이 생깁니다. 메모리에 올릴수 있는 데이터의 총량이나, 데이터 연산에서 발생하는 오버플로우 등

---

질문 5)

61 페이지의 열 지향 데이터베이스에 관한 설명을 읽어보다 든 의문점인데요, 그림 2.9처럼 칼럼별로 데이터를 보관하는 건 알겠는데 만약 2017년 1월 3일에 판매한 상품들의 목록을 알고 싶다면 열 지향 데이터베이스에서는 찾을 수 없지 않나요? 칼럼1과 칼럼 2의 상관관계가 전혀 없을 것 같아서요. 그렇다면 여기서 설명하는 열 지향 데이터베이스가 컬럼별로 데이터를 보관한다는 건 그냥 RDB에서는 인덱스를 잡지만 열 지향에서는 컬럼별로 나누는 식으로 인덱스(인덱스가 아니겠지만)같은 것을 잡는다 이런 뜻일까요? (group by 같은 느낌이 드네요,,)

그림 2.10은 상품 금액이 담긴 컬럼이 데이터 양이 많아 분산 처리를 저런 식으로 한다는 이야기인데, 그렇다면 단순히 그 금액 컬럼에 대한 집계만 알고 싶을 때 열 지향 데이터베이스를 쓰는지, 그렇다면 아까 질문한 것처럼 2017년 1월 3일에 팔린 상품들의 금액 합을 알고 싶을 때에도 열 지향 데이터 베이스를 사용할 수 있는지? 된다면 어떤 방식으로 짝을 찾을 수 있는지가 궁금합니다.

답변)

1. schema가 관리를 하고 있고, 저건 단순히 데이터가 저장된 형태만 보여드리는 것 뿐입니다. 실제 데이터 간의 관계는 metadata가 관리하고 있습니다.

2. 1번에서 설명드리데로 metadata를 활용하 각 해당하는 데이터를 찾을수 있습니다. 만약 이러한 행위를 반복한다면 저장할때 복합 컬럼의 열지향 형태로 저장하게 되겠지요

 

 

+) 복합 컬럼 열지향이 무엇인지 간단하게 설명부탁드립니다

→ 열지향 테이블에 컬럼이 추가 되는 것이 아닌지? 날짜 | 합계 | 평균 이런식으로요

→ 저희 같은 경우에는 파티션 칼럼(날짜)을 사용하고 있습니다.

→ row-based로 크게크게 분산시켜서 저장하고, 그 분산되는 조각 내부에서 column-based로 저장한다는 뜻 아닐까요?

그게 약간 rdb에서 인덱스 잡는 느낌이라고 생각을 했거든용 저는 하나의 컬럼을 인덱스 잡으면 빨리 계산이 되니까. 본질은 비슷한 것 같네요 ㅎㅎ

열지향은 아무래도 빅데이터를 다루는데에 적합하다 보니, 행 지양에서 내부로 열 지향으로 저장하는 부분이 무조건 있겠네여

 

+) 혹시 중간에 파티션을 쓰는 것과 또 다른 테이블을 만들어 쓰는 것과의 차이가 있나요?

→ 저희가 사용하는 기준으로 말씀드리자면 아무래도 찬77님이 질문주신것중에 후자에 가까운 것 같습니다. 데이터 마트에 테이블을 생성할 때 원본테이블 + 저희가 잡은 기준칼럼(원본 테이블에 존재하는 date type의 칼럼)을 가공해서 추가하여 테이블을 생성합니다.

CREATE TABLE COL1, COL2, DATE_COL, DATE_FORMAT(DATE_COL, 'YYYYMMDD')

FROM TABLE PARTITION BY(PARTITION_COL)

 

++)파티션은 뭔가요??

→ 예를 들자면 월단위로 데이터를 집계해야하는 데이터를 가진 테이블이라면 이를 효율적으로 조회하기 위해서 월단위 기준 인덱스를 만든다? 정도로 이해하면 될 듯

제가 설명드린 파티션은 분산 스토리지에 저장되는 디렉토리로 존재하는 칼럼입니다. HIVE PARTITION을 검색해서 보시면 좀 더 이해가 되실 것 같네요..!

---

질문 6)

질문1. p.61 “열 지향 데이터베이스는 데이터의 압축 효율도 우수하다. 같은 칼럼에서는 종종 유사한 데이터가 나열된다. 특히, 같은 문자열의 반복은 매우 작게 압축할 수 있다.” →칼럼 내에서 중복되는 값들을 압축하게 될 경우, 기존 중복 값들에 대한 인덱스 정보를 유지한 채 압축이 되는 건가요? 압축을 한다는 것은 곧 압축 된 것을 풀어야 할 때도 있다고 생각하게 되는데 그 경우 기존 문자열과 같은 위치에 있는 다른 칼럼의 값(하나의 행값)들 간의 상관성을 고려했을 때 단순 압축을 하였을 경우 문제가 생기지 않을지 생각되어 압축 메커니즘이 궁금합니다.

질문2. 분산 데이터베이스 vs. 분산 스토리지 → 안정성을 위해서는 분산 데이터베이스를 고려하라고 하던데, [여러 곳으로 분산되어 있는 데이터 베이스를 하나의 가상 시템으로 사용할 수 있게 한 데이터베이스인 “분산 데이터베이스”]와 [데이터 소스들을 여러 스토리지에 분산하여 저장하고 하둡과 같은 프레임워크 등을 사용하여 제어할 수 있는 “분산 스토리지”] 간 차이가 궁금합니다.

질문3. 네임 노드 vs. 데이터 노드 → 저번 스터디 시간에 네임 노드 데이터 노드가 언급되어서 좀 찾아 봤는데 노드라는 것이 서버 rack 안에 들어가 있는 서버들 하나하나를 의미하는 건가요?

답변)

1. 인덱스는 존재하지 않구요 schema + metadata로 저장됩니다. 실제 데이터는 하프만 코딩처럼 저장하면되고, 실제 데이터의 관계는 metadata에 저장하여서 찾게 됩니다.

2. 분산 스토리지 != 분산 데이터 베이스 를 이해하고 계신다면, 하둡과 분산데이터 베이스를 비교하실 수는 없습니다. 실제로는 HIVE와 분산 데이터 베이스를 찾아보시는게 더 나을 듯합니다. 분산 데이터베이스(지난시간 GPDB)는 DB Engine에서 분산되어있는 데이터의 위치에 기반에 각각 머신(또는 노드)의 DB Engine에서 연산 후 합칠수 있는 것(일종의 Map-Reduce 개념)이고, 분산 스토리지는 대량의 데이터를 다수의 노드에 저장하는 기술 입니다.

3. 지금 그림에서는 각 Rack에 있는 직사각형 == 하나의 서버(노드) 입니다.

 

+) 세컨더리 네임노드의 주역할인 edit log 동기화도 검색해서 찾아보시면 좋을 것 같습니다!

→ GPDB의 멀티코어를 통해 연산기능을 수행함

---

질문 7)

1. p68 책에서 주피터의 노트북은 josn파일 이라는 말이 나오는데 무엇을 뜻하는지 이해가 안감

2. 대시보드 도구와 bi 도구가 각각 별도로 있는건 아니죠? 용도에 따라 알아서 쓰라는거죠? ex) 리대시, 슈퍼셋, 키바나중에 대시보드 도구와 bi도구가 각각 나뉘어지는건지

3. 노트북이나 코랩 현업에서 아직 잘 쓰나용???? 세이지메이커에 있는 노트북은 잘 쓸거 같기도 한데 아직도 노트북를 직접 호스팅해서도 쓰나 궁금해요

 

답변)

1. 쥬피터 파일은 내부에 JSON형태로 저장되어 있습니다(*.ipynb) 그러니 Git에서 history관리가 가능한 것이죠

2. 네 정확하게 이해하고 계시네요

3. 코렙은 퍼블릭으로 사용하면 공짜지만(개인에게만) 실제로 프라빗하게 사용하려면 상당한 돈을 내야합니다. 세이지 메이커는 너무 느리고 배포만으로 사용합니다.(그리고 비쌉니다..)

 

저희 회사는,,, 로컬에 gpu 달아서 개발하기 때문에 아직 주피터를 써요 ㅎ 사실 개발하기 나름인 것 같아요 결과 하나하나씩 보기 위해서 주피터를 쓴다고 생각하는데 클라우드 사용하시는 분들은 세이지메이커 많이 쓰시겠죵??

 

+) 데이터 마트 구축도 ETL인지?

→ 마켓생성도 ETL로 봐도 될것 같습니다 추출해서 가공하고 적재하는 것이니 저는 ETL이라고 생각됩니다 ㅎㅎ

→ 저희는 데이터 마트까지를 ETL이라고 합니다.

---

질문 8)

질문1. Column-Based와 Row-Based는 데이터가 실제로 저장되는 ‘순서’가 다르다고 알고있습니다. 그러면 데이터를 실제로 로드하는 과정에서도 속도차이가 있을까요? 그리고 속도차이가 있으면 이 부분이 캐시메모리와도 연관성이 있을까요 ???

질문2. 데이터를 정규화, 반정규화 하는게 무조건적으로 좋은건가요? 역정규화는 어떤 이점이 있어서 사용하는걸까요?

 

답변)

1. 저장되는 순서는 당연히 다릅니다. 실제로드 속도는 어떠한 형태로 가져오는지에 따라 차이가 있을수 있습니다 열형태로 저장되어 있는 200개의 컬럼에서 특정 5 행만 가져 온다면 느리겠지요

2. 원데이터 형태 및 로드하는 데이터 형태에 따라 다르게 해야할 뿐 각 장단점이 존재 합니다. 무조건 옳다 하는 시대는 지났습니다 ㅎㅎ

 

제가 질문에서 언급했던 지네효과와 조금 관련이 있는 질문이신거 같습니다. 지네효과로 여러 디멘션 테이블을 참조해서라도 사용하는 이유가 조회성능이 더 좋기 때문입니다. 결국엔 역정규화 또한 join을 대신해서 하나의 큰 테이블을 통해서 조회성능을 높이는 목적이 존재합니다.

→ join 이라는 것 자체가 자원을 많이 소모해서 그런거지 않나요?

→ 넵넵 맞습니다

사실 이부분도 요즘은 성능에 큰차이가 없다라는 의견을 가지신분들도 있어서 항상 논쟁거리가 되고있습니다.

→ 역정규화에 대한 레퍼런스가 없어서 방금 서치 하나 해 봤는데

https://inpa.tistory.com/entry/DB-📚-제-1-2-3-정규화-역정규화#역정규화

이런 포스팅이있네요! 저는 여기서 제일 공감 가는 게 group by 부분인데 이거 부하를 줄이는 게 역정규화의 이유 중 하나라고 해용 어쨌든 모든 데이터를 읽어서 내장함수를 쓰는 것보다 역정규화로 필요한 컬럼만 뽑아서 쓰는 게 리소스 과부하가 덜 되니 좋다는 말인 것 같습니다

근데 사실 실무자가 제일 편한 방식대로 하지 않나요 결국엔 ㅋㅋㅋ

만약 성능 차이가 그렇게 없다면...

→ 그룹바이 하나만 넣으면 되는데 굳이 테이블 하나 더 만들어서...

그렇게 튜닝이 시작되고... 그런 거 아닐까요 ㅋㅋㅋ

저는 postgresql 써서 pgadmin으로 explain 많이 사용하긴 하는데 그걸로 뭔가 쿼리를 개선한다기 보다는 서브쿼리를 쓴다거나 다른 방식을 쓴다거나 view을 넣어본다거나 그런 식으로 방법을 여러가지를 써서 속도 체크를 해 보는 것 같아요 ㅋㅋㅋ마치 코딩테스트처럼....