20230120금-최종10, 레콤비

레콤비..

정말 잘 돼있는 사이트다. 여기에서 얻어갈 것들을 추려보자.

일단 이 지표 시각화가 굉장히 눈에 띈다. 어차피 값이 전부 0부터 1사이니까 퍼센티지가 대략 보이도록 시각화하는 것은 매우 효과적이라고 본다. 이러한 시각화는 확실히 다양한 값이 있어도 편하게 비교가 가능하다. 근데 여기에서 정의하는 지표들은 어떻게 계산되는 것인지 너무 궁금하다. 우리와 겹치는 지표들은 우리와 같은 방식인가? apl과 lcc는 뭘까?

실화냐.. plotly로 이 정도의 interaction을 만들 수 있다니. 근데 이게 뭘 보여주는 걸까?

novelty가 좀 높은 놈들은 저 근처에 보인다고 해석하면 되려나? 잘 모이는 여부가 중요한 것일 수도 있다.

모델 간 비교인데, 지표별로 기하 공간?에서의 상관관계를 보이는 듯하다. 그나저나 이 페이지 자체는 어떻게 만들었지? 그래프 부분은 plotly가 맞는데, 버튼을 통해 눌러서 바로 상호작용이 되도록 하는 것은 어떻게 한 것일까?

repsys/metrics.py at master · cowjen01/repsys (github.com) 지표들 계산 방식. 뭔가 엄청난 게 있는 것은 아닌 것 같은데, 이쪽에서 받아들이는 지표들의 정의를 알고 싶어서 보는 중이다.

레콤비는 b2b 수익 모델을 가졌으며 기업에게 필요한 추천 서비스를 제공해주는 기업이다. 그러면서 추천에 대한 정보를 알기 쉽도록 시각화를 해준다. 
블로그를 둘러보는데 개인화된 추천에 굉장한 관심을 가지고 있고, 그것을 고려한 시각화 시도가 많은 듯하다.

하이퍼 파라미터 선택방식에서 만들어진 모델들에서 선택하는 방식으로.

데일리 스크럼

원래 우리의 페이지는 모델 간 비교 부분에서 모델을 선택하면 그 모델에서 선택 가능한 하이퍼 파라미터를 선택지로 보여주고, 고객이 그것을 선택하는 방식이었다. 오늘 나온 이야기로는 그냥 고객이 올린 데이터를 나열해서 띄워주는 방식으로 바꾸자는 것. 그것이 구현 난이도가 더 쉽다는 것이 가장 핵심적인 이유. 
사실 이 부분은 어느 정도 나로서는 잘 납득은 가지 않았다. db을 적용함에 있어서 기존의 방식이 사용불가능한 것인가? 내가 너무 나이브하게 생각해서 큰 차이를 느끼지 못하는 것이리라 생각하고 넘어갔다. 다만 내가 이해한 기업 관계자들이 원하는 방식은 우리가 보여줄 수 없겠다 싶었다. 어차피 우리는 우리가 할 수 있는 범위에서만 선택을 하는 게 맞는 것이다.

나는 내가 할 것이 당장 정해져있다. 

하이퍼 파라미터 선택은 없다. -- 후보리스트를 따진다던가, sererndipity max profile같은 파라미터는 어떻게 할까?

오피스 아워

데이터 파이프라인 구축으로 데이터 엔지니어링 맛보기!
데이터 엔지니어 관련에 관심이 많다면, 꼭 듣는 게 좋을 것이다.

데이터 엔지니어링 관련 용어부터 알아보자.

OLAP Online Analytical Processing. 대용량  데이터를 분석하기 쉽도록 구성하는 일련의 처리 기술. 데이터 웨어하우스나 레이크같은 것. 일련의 환경이다.
데이터의 규모가 커지면서 점차 데이터베이스에 부하가 가고, 반복된 쿼리를 날려야 하는 경우가 생기기도 한다. 그래서 데이터를 분석할 수 있도록 잘 마련해주는 것이 필요하다. 그러한 환경을 만드는 것. 그것이 곧 파이프라인을 구축하는 일이다.
외부데이터를 추출해 사용하도록 저장하기까의 과정이다.  스토리지는 웨어하우스와 레이크로 나뉜다. 웨어하우스는 정형 데이터, 레이크는 모든 유형의 데이터를 적재할 수 있다. 
상황에 따라 사용한다. 
분석, 기술적 요구사항에 맞게 변형하는 작업이 필수적이다! 데이터를 월별로 집계한다던가, int값으로 바꿔달라던가. 결측을 0으로 만들어달라던가.
자주 쓰일 것 같은 데이터를 미리 집계해내면 그걸 마트라고 표현한다. 마트는 그냥 개념적 용어이다.

ETL Extract Transform Load. 추출하고 변형해서 적재한다. 뽑아서 마스킹하거나 필터링. 그리고 빅쿼리 같은 것에 적재.
거꾸로 ELT도 할 수 있다. 먼저 적재하고 변형하는 케이스도 존재. 데이터 양이 많을수록 변형하는 시간이 오래 걸려서 로드가 느리게 된다. 그래서 일단 로드부터 때리고 하자는 것. 또 요구사항이 변할 때가 있다. 트랜스폼을 다르게 해야 하는 케이스가 생기니까.

배치. 특정 시간 범위의 데이터를 처리. 5분단위로 자른다던가.
스트리밍. 생성되는 데이터를 실시간으로 처리하는 기술.

둘다 필요한 경우도 있다.

이건 데이터 파이프라인 구성요소이다. 데이터 인프라 구조가 다양하고 복잡하다.

orchestration.
airflow. 데이터의 추출, 적재 등의 작업을 자동화해준다.

wherehouse.
sql문법을 대체로 지킨다. 그래서 편하게 사용가능하다.

lake
뭐든 저장 가능한 스토리지. 비용이 저렴하다. 대표적인 것이 s3. spark 같은 대용량 처리 엔진이 필요하다.

그리고 분석! tableau나 그런 소스를 사용하기도 하고, 손수 주피터를 쓸 수도 있다.

numba.jit

오늘 나온 이야기로는 지표들을 미리 서버에 저장을 해두는 게 낫다는 것. 이유야 몇가지가 있겠지만, 사실 웹페이지에서 지표 계산을 빠르게 해준다면 굳이 담을 이유도 없다. 매번 빠르게 계샨을 해주면 되니까. 그리고 그렇게 해줄 수 있다면, 충분히 고객에게 인터랙티브한 선택지를 제공해줄 수 있을 것으로 생각된다.

그렇다면 저번에 내가 알게 된 놈을 활용하는 방향으로 생각해봐야겠다. 느려터진 파이썬에 c 급의 속도감을 부여해주는 numba.jit! 웅장이 넘바해진다.

그러나, 이 놈의 안타까운 점은 넘파이는 잘 받아줘도 판다스는 잘 못 받아준다는 것이다. 각 행렬들을 넘파이 행렬로 바꾸는 것은 결코 어렵지 않다. 그러나 넘파이에서 내가 원하는 방식으로 인덱싱을 하는 게 생각보다 어렵다.

인덱싱이 판다스처럼 되어주지를 않는다. 팬시 인덱싱이라고 불연속한 인덱싱이 가능하기는 한데, 그게 어떻게 쓰는지를 잘 모르겠다.

찾아보니 take니, compress니 하는 함수들도 있는데 이것들을 결국에는 boolean, fancy 인덱싱의 전신이 되는 함수들일 뿐이었다.

그렇다면 조금 더 투박한 방법을 쓰는 수밖에(주석을 잘못 써서 수정함). 일단 되는 대로 해보자고.

음. 최악의 상황. 아무래도 인덱싱에 대해 numba가 인식을 못해주는 것 같다.

회고 및 다짐

지금 뭔가 살짝 불안한 느낌이다. 팀이 생각하는 프로젝트의 기획 의도와 내 생각이 완벽하게 일차하지 않는다. 묘하게 엇갈리는 핀트가 있는 것 같은데, 그냥 용인할 수 있는 수준이지만 나중에 왜 그렇게 만들었냐는 질문이 들어올 때 나는 명쾌하게 답할 자신이 없어졌다. 하이퍼 파라미터 튜닝에 따른 변화를 보여주는 측면에서의 우리의 의도가 많이 약화됐지만, 일단 구현 난이도는 적어졌다.
serendipity의 인터랙티브를 줄이는 방향으로 나아가는 게 과연 좋은 것일까? 하지만 분명 웹서비스에서 로딩이 오래 걸리는 건 분명하게 마이너스 요소이다. 나는 아무래도 계산 속도를 더 빠르게 하는 방법을 구상해보는 게 어떨까 한다. 성능을 위해 우리의 기획을 포기한다는 게 너무 아쉽다.