Computer Science/데이터 베이스

0. 글을 시작하며현재 진행하는 프로젝트에는 해시태그 개념이 존재하고, 이 해시태그를 이용한 검색 기능을 제공하고 있었습니다. 기존에는 하나의 post는 하나의 해시태그만을 가질 수 있다는 정책을 설정하고 사용하고 있어서 데이터를 다음과 같은 형태로 저장하고 있었습니다.post_idpost_namepost_content...hash_tag1석촌호수 벚꽃석촌호수 벚꽃이 정말......벚꽃2따뜻한 날씨요즘 날씨가 많이 따뜻......일상......104날씨 좋은 날 나들이이렇게 날씨 좋은 날 ......나들이105Querydsl 도입기기존 프로젝트에서는......기술 그래서 사용자가 "벚꽃" 또는 "나들이" 라는 해시태그가 포함된 글을 보고 싶다면 다음과 같은 쿼리를 사용해서 해당 태그를 포함한 포스트들을 ..

0. 글을 시작하며 올해 2월 현재 회사에 서버개발자로 입사했지만 부가적인 업무로 빅데이터 분석을 통한 BI(Business Intelligence)를 지원하는 업무를 병행하게 되었습니다. 입사 초반에 모르는 기술 용어와 개념으로 가득한 회의에 들어가면서 어려움을 겪었던 기억이 있습니다. 물론 이 분야를 전문으로 하지 않는 상황에서 빅데이터 분석에 대한 전문적인 개념들을 모두 이해하고 업무를 하는 것은 불가능하지만 "해당 분야에 대한 큰 그림을 이해하고 접근하자"라는 관점이 업무를 진행하는 데 굉장히 큰 도움이 되었습니다. 이 글에서는 빅데이터 분석에서 사용하는 어떤 특정 기술에 대한 전문적인 내용을 다루는 것이 아니라 빅데이터 분석 분야에 대한 대략적인 큰 그림을 정리해보고자 합니다. 혹시 저처럼 본인..

0. 배경 통계쿼리를 작성할 때 가독성을 고려하지 않고 작성하다보면 주요 지표들을 계산하는 복잡한 로직과 Table 간의 JOIN, 많은 서브쿼리들이 복잡하게 얽혀 매우 복잡한, 가독성을 사실상 거의 포기한 Query가 나오게 됩니다. 하지만 보통 데이터 분석에서 다루는 로그 성격의 정보를 저장하는 테이블들은 아무리 적절히 정제과정을 거처더라도 row수가 매우 많습니다 (1억건도 많지는 않은 편...). 그렇기 때문에 이렇게 거대한 Table들을 모두 JOIN해서 사용하는 것은 아무리 ON 조건을 적절히 잘 건다고 하더라도 상상 이상의 비용이 발생합니다. Google BigQuery 같이 수천대의 분산환경 컴퓨팅 성능을 활용할 수 있는 막강한 성능을 가진 플렛폼을 사용하더라도 분명 결과를 받기까지 상당히..

0. 배경 (문제 상황) 데이터 분석 프로젝트를 진행하면서 Google BigQuery로 구성된 DW에 저장된 전체 서비스 로그와 사용자 정보가 저장된 Table로부터 Mart Table을 생성하는 CTAS Query를 작성해야할 일이 있었습니다. 전체 서비스 로그가 하나의 Table로 모여 저장되고 있었기 때문에 내부적으로 이를 저장할 때에는 해당 로그가 어떤 서비스에 대한 로그인지를 식별하기 위한 식별자가 들어갔고, 이 식별자를 알고 있으면 특정 서비스에 대한 로그만을 필터링하여 이를 데이터 분석에 활용할 수 있었습니다. 하지만 통계쿼리의 특성 상 쿼리 길이가 굉장히 길고(수백라인...) 각 서비스들이 가지는 자신 만의 히스토리가 데이터에 스며있기 때문에 이 모든 맥락을 이해하며 데이터 분석에 활용할..