안녕하세요. 이번에 Bagelcode에서 새로운 BI 툴로 Metabase를 도입했는데 그 과정에 대해서 소개해 드리려 합니다.목차Bagelcode의 Data Delivery- Bagelcode의 Data Delivery 현황- 추가적인 BI 툴 필요성 제기Metabase 배포 과정- EKS 환경 배포- 초기설정- 트러블 슈팅 과정메모리 점유sync, scan 병목schema 하나당 데이터베이스 하나로 등록이 되는 문제,driver 커스텀하기 (feat. clojure)쿼리 timeout 문제마무리Bagelcode의 Data DeliveryBagelcode의 Data Delivery 현황Redshift 제거 과도기Bagelcode에서는 데이터를 추출해서 S3에 저장 후 Databricks에서 가공해서 사용합니다. 기존에는 end-user에게 데이터를 제공하기 위한 툴로 Redshift, Tableau를 이용 중이었습니다.그런데 테이블이 점점 늘어나면서 lock에 걸려서 write, read 시간이 오래 걸리고 비용 문제 등의 이유로 Databricks SQL warehouse를 통해 Superset으로 쿼리할 수 있도록 변경했고 Redshift와 Superset을 동시에 이용하는 과도기를 지나 Superset만을 이용하는 방식으로 변경했습니다.Redshift를 제거하는 과정에 대해서 궁금하시다면 ‘Databricks SQL Serverless 도입기’를 참고해 주세요.Before Metabase과도기를 지난 후 데이터를 사용하는 end-user가 사용할 수 있는 툴은 Superset과 Tableau 두 가지가 되었습니다.직접 테이블에서 바로 쿼리를 해서 사용하고 싶을 때는 Superset으로, 시각화가 필요할 때는 Tableau를 이용하였습니다.추가적인 BI 툴 필요성 제기하지만 신작팀이 점점 늘어나면서 추가적인 BI 툴의 필요성을 느꼈습니다. 신작팀은 인원이 많지 않은 관계로 데이터를 직접적으로 다룰 수 있는 인원이 없는 경우가 많았습니다. 이 경우 데이터 팀에게 직접적으로 요청하는 방법이 존재하지만, 빠른 사이클이 필요한 신작팀에게는 일분일초가 소중합니다.After Metabase‘SQL 쿼리를 할 줄 모르는 사용자’도 ‘빠르게’ 데이터를 다룰 수 있는 BI 툴의 필요성을 느껴서 Metabase를 도입하게 되었습니다.Metabase에서는 question이라는 기능을 통해 template화된 GUI 쿼리 툴이 존재하기 때문에 SQL을 모르는 사용자도 쉽게 쿼리를 할 수 있도록 해주고 자체 시각화 기능 및 alert 설정 등 다양한 기능이 있기 때문에 도입을 결정하게 되었습니다.정리하자면 아래와 같습니다.Superset: SQL 쿼리를 다룰 줄 아는 사용자가 데이터를 추출하기 위해 사용.Tableau: SQL 쿼리를 다룰 줄 아는 사용자가 시각화를 위해 사용. 또는 SQL 쿼리를 모르는 사용자도 데이터 팀에 요청해 사용.Metabase: SQL 쿼리를 다룰 줄 모르는 사용자가 빠르게 데이터를 다루거나 시각화할 때 사용.Metabase 배

빅데이터 분석을 위한 인프라 구축에 대한 경험을 공유하고자 합니다. 최근 데이터 분석을 위한 데이터 처리 시간의 증가로 기존 데이터 처리방법의 한계를 경험하였습니다. 결국 빅데이터 프레임워크를 검토하고 최종적으로 기술을 선정하 여 도입하게 되었습니다. 이 과정에서의 경험이 비슷한 고민을 하는 사람들에게도 도움이 될 것으로 여겨 글을 작성하고 공유하게 되었습니다. 많은 회사에서 그렇듯이 데이터를 기반으로 현재 서비스의 현황을 정확하게 파악하고 합리적인 의사결정을 할 수 있도록 여러 지표를 만들고 이를 정기적으로 모니터링 합니다. 때에 따라서는 가설을 세우고 이를 확인하기 위해 데이터를 이용하여 분석을 합니다. 가설을 세우고 데이터를 만들어 분석하는 전담 부서를 두기도 하지만 업무에 대한 지식과 관련 데이터는 업무 담당자가 가장 잘 알 수 있는 부분이므로 데이터를 분석하는 것은 모두에게 필요한 부분이라 생각합니 다. 하지만 전체 데이터의 구조나 관련 기술이 부족한 업무 담당자가 분석을 위한 데이터를 처음부터 찾아서 보는 것은 매우 어려운 작업입니다. 저는 이러한 사람들이 좀 더 쉽게 데이터를 통해 원하는 분석 결과를 얻을 수 있도록 데이터 추출과 분석을 지원하는 업무를 하고 있습니다. 사내에서는 이를 ‘Data Intelligence’라고 부르고 있으며, 타 팀에서 데이터를 효과적으로 분석 할 수 있도록 저장된 데이터를 가공하여 추출하며, 경우에 따라서는 데이터를 수집하는 업무를 하고 있습니다. 무엇이 문제인가? 데이터 사이즈의 크기가 늘어나면서 더 높은 처리 속도가 필요하였고, API 로그 등의 데이터를 DB 데이터와 연동해서 봐야하는 Needs가 증가했습니다. 데이터 추출 작업을 생각해보면, 데이터가 DB 테이블에 저장 되었을 경우 간단히 SQL 쿼리를 통해 원하는 데이터를 찾을 수 있습니다. 이 경우 데이터 기준을 요청자와 논의하면서 적절한 쿼리를 작성 후 엑셀로 추출하여 요청자에게 전달 하게 됩니다. 이때 데이터 조회 속도가 너무 오래 걸린다면 날짜와 같은 키로 쿼리로 나누어서 조회하기도 하고 인덱스 등을 조정하기도 합니다. 만약 데이터 추출이 쿼리로 불가능하거나 처리 속도를 높일 필요가 있을 경우 Python, Java 등의 언어로 프로그램을 만들어 추출하기도 합니다. 때에 따라서는 중복된 데이터 처리를 피하기 위해 중간 과정의 데이터를 만들어 활용하기도 하며, 서버 사양을 높이거나 병렬 처리를 통해 최종 데이터 생성의 속도를 높이는 시도를 하기도 합니다. 많은 노력에도 불구하고 어떤 데이터의 경우는 이틀 이상 소요되는 경우가 많아 졌습니다. 또한 API로그를 통해서만 볼 수 있는 분석에 대한 요청도 있었습니다. 앱에서 버그가 발생하여 동일 API가 여러 번 호출 되는 경우가 있었는데 이 버그의 영향이 어느 정도 영향을 미쳤는지 파악하기 위해 API 로그를 살펴보아야 했습니다. 이러한 케이스의 로그 데이터 분석은 ELK, AWS Cloud Watch에서는 살펴보기에는 어려움이 있었습니다. 이러한 과거 데이터 처리, 추출