들어가며 안녕하세요. 주형권입니다. 오늘은 저연차 주니어 분들에게 도움이 될 것 같은(?) 글을 작성하려고 합니다. 제가 주니어 시절에 많은 시니어 분들께서 강조하셨고 가르쳐 주셨던 내용을 여러분께 정리하여 공유 드리고자 합니다. 저의 링크드인을 보면 아시겠지만 저는 이직을 꽤 여러번 하였습니다. 물론 자의가 아닌 타의(회사가 망...)로 회사를 옮긴적도 여러 번 있지만 이직을 여러 번 경험 한 저에게는 한 가지 습관이 있습니다. 누구나 자신만의 업무 스타일이 있고, 연차가 오래될수록 그 업무 스타일은 습관으로 굳어지는 것 같습니다. 여러가지 업무 스타일이 있지만 유독 이 부분은 제가 강점이라고 생각합니다. 누군가에게는 별것 아니라고 들을 수 있지만 제가 여러 회사를 옮기면서 느꼈지만 별게 맞습니다. 왜..

안녕하세요. 데이터엔지니어 주형권입니다. 오랜만에 꽤나 길고 범용적인 주제에 관해서 글을 쓰려고 합니다. 많은 회사에서 데이터를 활용하여 많은 업무를 하고 데이터를 이용해서 많은 의사결정을 하고 있습니다. 그러면서 데이터의 양도 방대하고 종류도 꽤나 다양해졌습니다. 제가 처음에 일할 때는 RDB(Relational Database)에서 발생하는 데이터만 주로 다루었습니다. 하지만 최근에는 너무도 많고 너무도 다양한 데이터를 이용해서 의사결정과 업무를 진행합니다. 하지만 데이터가 아무리 다양하고 많아져도 RDB에서 발생하는 트랜잭션 데이터는 절대적으로 필요합니다. 그렇기에 RDB에서 데이터를 가져오는 것은 절대로 필요하다고 볼 수 있습니다. 회원 데이터 또는 빌링 데이터등은 무결성이 무조건이기 때문에 RD..

안녕하세요. 주형권입니다. 데이터웨어하우스 관련 글을 오랜만에 쓰는 것 같습니다. 글을 읽기 전에 이 글의 내용은 제가 알고 있고 공부한 내용을 바탕으로 설명하였습니다. 이 내용을 꼭 맹신하지 않고 혹시라도 다른 내용이 있다면, 서로 비교하여 읽기를 추천드립니다. 데이터웨어하우스 (이하 DW) 관련한 여러 가지 글이 있는데 그중에 DW의 설계 기법인 Star Schema와 Snowflake Schema에 대해서 설명해 보려고 합니다. DW를 하다 보면 가히 필수로 알아야 하는 개념이며 추가적으로 Galaxy Schema라는 설계 기법도 존재합니다. 최근에는 BigQuery와 같은 컬럼 형식으로 저장하면서 이러한 기법을 굳이 사용하지 않아도 최적의 저장 효율을 제공합니다. DW 기법이 필요한 이유는? DW..

글을 읽기 전에 이 내용은 저의 경험을 토대로 작성하였습니다. 현재 사용하시는 도구 및 방법과 다르다고 하여 무엇이 맞고 틀리고를 이야기하고자 하는 글이 아닌 경험을 공유하고자 작성된 글이므로 참고 차원에서 봐주시길 바랍니다. 데이터를 보기 위해서는 많은 과정이 필요합니다. SQL을 이용해서 데이터를 추출하고 이를 엑셀로 다운로드하거나 리포트를 만들어서 보는 과정이 아닌 전체적인 과정을 설명하고자 합니다. 이 글의 내용은 제가 아는 범위에서 작성하였으나 회사마다 모두 다르고 사람마다 모두 다른 방식으로 할 수 있기 때문에 어느 정도 감안해서 글을 읽어 주시길 바랍니다. 보통 데이터는 크게 3가지의 데이터가 있습니다. 정형 데이터 : 관계형 데이터베이스 (MySQL , SQL Server , Oracle)..

Hello. Many people seem to know the part of optimizing cost and performance by fetching data without reading unnecessary parts in big queries using partition columns. There are many advantages to using partitioned columns as above, but there may be cases where you cannot. If there are several date columns in the table, the case where the date column to be used is not partitioned is as follows. B..

멱등성이란 DW에서 데이터를 적재 할때 자주 사용 합니다. DW에서 이따금씩 재처리를 하는 경우 기존의 잘못된 데이터를 지우고 재적재 해야 합니다. 그렇지 않으면 데이터의 중복이 발생하여 데이터가 이상하게 증가하거나 결과값이 이상하게 나올 수 있습니다. 그런데 big query에서 제가 겪은 상황에서 멱등성을 고려 하여 프로세스를 구성하였다가 큰 낭패를 본적이 있습니다. 상황은 다음과 같습니다. bucket에 JSON 형태로 쌓이는 데이터가 있습니다. 데이터는 YYYY/MM/DD 형태로 쌓이고 있습니다. 그런데 데이터를 적재할때 2020/02/26 폴더의 데이터에 서버에서 조금씩 지연되서 들어오는 경우 2020-02-27의 데이터가 들어오는 경우가 있습니다. (한개의 파일에 다른 날짜의 데이터가 들어옴)..