[공통] 데이터를 적재하고 보기까지

글을 읽기 전에 이 내용은 저의 경험을 토대로 작성하였습니다. 현재 사용하시는 도구 및 방법과 다르다고 하여 무엇이 맞고 틀리고를 이야기하고자 하는 글이 아닌 경험을 공유하고자 작성된 글이므로 참고 차원에서 봐주시길 바랍니다.

 

 

---

 

데이터를 보기 위해서는 많은 과정이 필요합니다. SQL을 이용해서 데이터를 추출하고 이를 엑셀로 다운로드하거나 리포트를 만들어서 보는 과정이 아닌 전체적인 과정을 설명하고자 합니다. 이 글의 내용은 제가 아는 범위에서 작성하였으나 회사마다 모두 다르고 사람마다 모두 다른 방식으로 할 수 있기 때문에 어느 정도 감안해서 글을 읽어 주시길 바랍니다.

 

보통 데이터는 크게 3가지의 데이터가 있습니다. 

 

• 정형 데이터 : 관계형 데이터베이스 (MySQL , SQL Server , Oracle)
• 반정형 데이터 : JSON , parquet , Avro 
• 비정형 데이터 : 음성,텍스트,사진

 

제가 알고 있는 범위는 이 정도이며 이 글에서는 정형 데이터를 수집하여 지표화 하는 과정을 설명 하고 있습니다. 모든 데이터에 대해서 하면 좋겠으나  수집의 방식이 모두 다르고 저장하는 방식 또한 다르기에 글이 너무 길어져서 한 가지의 주제를 잡고 이야기하려고 합니다.

 

데이터를 수집하려면 우선 데이터를 쌓아야 합니다. 관계형 데이터베이스(이하 RDB)의 경우 개발자, DBA가 주로 개발 및 관리를 하며 데이터 분석가/엔지니어, 사업, 기획, PM 등의 팀에서 주도하여 원하는 데이터를 이야기하여 설계하고 이를 DBA가 주도하여 테이블 설계 및 칼럼 형태를 조정하며 개발자가 적재적소에 코드에 심어서 RDB에 데이터가 남도록(INSERT) 합니다. 

 

위의 내용을 예시를 들어서 설명해보겠습니다.

 

• 현재 데이터를 남기는 시스템은 존재하지 않습니다.
  • 데이터를 남기는 시스템이 존재하지 않으므로 새롭게 만들어져야 합니다. 
• 사업팀에서는 다음의 2가지 지표를 보고 싶어 합니다.
  • DAU(Daily Active User) , NRU(New Resistered User)라는 2개의 수치이며 이를 지표 화하여 매일 오전 9시에 보려고 합니다. 데이터는 실시간으로 쌓이지 않아도 괜찮고 매일 오전에 9시에만 리포트 페이지 또는 메일로 받아보고자 합니다. 

 

데이터를 보기 위한 과정을 그림과 함께 보면 다음과 같습니다. 이 과정은 크게 4가지 과정으로 나누어지며 4가지 단계마다 어떠한 내용이 있는지 번호를 지정하고 설명하려고 합니다. 회사마다 다르겠으나 이러한 모든 과정은 PM(프로젝트 매니저)이 주관하며 일정을 잡습니다. 프로젝트 매니저는 각 팀에 필요한 내용을 전달하고 회의를 주관합니다. 

 

데이터를 보기 위한 과정

 

회의의 방식도 조금씩 다르겠으나 1번 과정을 제외하면 대부분 모든 팀이 모여서 한 번에 이야기하고 추후에 필요한 내용에 따라서 각 팀끼리 미팅하는 경우가 많습니다. 모든 팀을 매번 불러서 이야기하면 굉장히 번거롭고 회의가 길어질 수 있으므로 보통 처음 큰 프로젝트 틀과 기획을 이야기할 때 모여서 이야기합니다.

 

결론적으로 이야기하면 4가지의 과정으로 이루어지며 이 글에서는 4가지의 과정을 기반으로 작성하였습니다. 그 4가지의 과정을 정리하면 다음과 같습니다. 

 

1. 지표 기획 

2. 데이터 심기(만들기)

3. 데이터 적재

4. 데이터 가공 및 지표 개발

 

---

 

1. 지표 기획

지표를 기획하자

 

우선 첫 번째로 사업팀, 기획팀에서 보고자 하는 지표를 엑셀이나 파워포인트 등과 같은 OA 도구를 이용하여 기획을 합니다. 어떤 방식으로 보면 좋겠는지 어떤 점을 구분하면 좋을지에 대해서 이야기합니다. 예를 들면 "회원 가입을 할 때 성별이 구분되어야 하거나 또는 연령대가 구분되어야 한다."와 같은 내용을 구체적으로 기획합니다. 물론 회의에서 역으로 데이터 분석, BI, 데이터웨어하우스(이하 DW)/데이터 엔지니어가 제시하기도 합니다. 이러한 부분을 세분화해서 보면 더욱 효과적이라고 역 제시하기도 합니다. (그래프를 어떻게 하면 좋을지, 어떤 위치에 어떤 지표가 들어가면 좋을지 등)

 

이 과정에서 1차적으로 분석팀, BI팀에서 SQL을 이용해서 데이터가 쌓이고 있는지 확인하거나 어떻게 쌓이고 있는지 확인합니다. 데이터가 없는 경우 새롭게 만들어야 하므로 개발팀, DB팀, 데이터엔지니어팀과 기획 전에 협의할 수도 있습니다. (쌓을 수 있는지 여부와 쌓지 않는다면 개발이 가능할지 여부)

 

분석팀, BI팀의 경우 실제 RDB에 접근 권한이 없는 경우가 많고 주로 DW에서 데이터를 확인하기 때문에 실제로 개발이 안되었는지 여부를 모두 파악하기는 어렵습니다. 문서가 잘 남거나 테이블을 검색할 수 있는 환경이 있다면 테이블을 검색하여 데이터가 남는지도 확인 가능하겠지만 없는 회사가 많이 있으므로 1차적으로 확인 후 2차적으로 DBA, DW/데이터 엔지니어에게 요청합니다. 모두 확인하였으나 데이터가 남고 있지 않다면 개발팀, DB팀, DW/데이터 엔지니어팀이 협의하여 이제 데이터를 만들어야 합니다.

 

---

 

2. 데이터 심기(만들기)

데이터를 심자

 

위의 사진처럼 작물을 수확하기 위해서 씨를 뿌리거나 모종을 심는 작업을 하듯이 데이터를 수확하기 위해서는 데이터를 심어야 합니다. 데이터를 심기 위해서는 데이터가 설계되어야 하며 데이터 설계란 데이터에 어떠한 항목이 들어갈지 정하는 과정입니다. 데이터베이스의 테이블 칼럼을 생각하면 이해하기 쉽습니다. 

 

예를 들어서 2개의 지표를 만들고 싶다고 가정하겠습니다. 만약에 DAU , NRU를 데이터로 심기 위해서는 어떠한 항목이 필요할까요? 간단해 보이지만 생각보다 많은 작업이 필요합니다. 

 

 

필요한 항목

 

DAU

 

• DAU의 경우 어떠한 유저가 유니크하게 들어왔는지를 보는 지표이므로 유저의 로그인 정보가 필요합니다. 
• DB에 로그인할 때마다 데이터를 남겨주어야 합니다. 
• 데이터에는 유저의 고유키(id)와 접속 시간이 기본으로 들어가며 필요에 따라 다른 정보가 들어갈 수 있습니다.
  • 이 부분에 대해서 조금 부연 설명하면 성별, 생년월일은 따로 분리해서 설계하는 게 맞습니다. 1차 정규화 위반 사항으로써 중복된 데이터가 계속해서 쌓이므로, 유저의 정보 테이블을 만들고 차후에 조인해서 보는 게 맞습니다. 하지만 지금 이 부분은 설명하지 않습니다. (말이 길어집니다...)

NRU

 

• 유저가 언제 가입하였는지 고유키(id)와 가입 일자가 찍히며 필요에 따라서 성별, 생년월일, 지역 등의 정보를 남길 수 있습니다. 

 

위의 2개의 정보를 찍기 위해서 여러 가지 고려할 사항이 많습니다. 이러한 내용을 심기 위해서는 몇몇 팀에서 데이터를 심도록 설계해야 합니다. 그 과정은 세세하게 나열하면 굉장히 많지만 간략하게 보면 다음과 같습니다. 

 

 

각 팀에서 해야 할 일

 

개발팀

 

• 개발팀에서는 각각의 코드에 특정 액션을 했을 때 (로그인, 회원가입) 데이터가 남도록 코드를 추가합니다. 
• 해당 코드를 추가하면서 데이터베이스에 테이블에 쌓이도록 만들도록 합니다. 

 

DB팀

 

• RDB에 데이터가 잘 쌓이도록 테이블을 설계하고 정규화 및 테이블을 정의합니다. 
  • 이 과정은 개발팀에서 선행하고 DBA는 검수를 하는 경우가 많지만 함께 하는 경우도 있습니다. 
• 테스트로 들어온 데이터가 잘 들어왔는지 확인하고 정상적이지 않을 경우 다시 개발팀과 협의합니다.

 

데이터엔지니어팀

 

• 데이터 엔지니어도 마찬가지로 데이터가 정상적으로 쌓이는지 확인하고 이 데이터를 DW로 가져올 때 이슈가 없는지 DBA와 협의하여 인덱스 및 테이블 구조에 대해서 이야기합니다.
  • 예를 들면 로그인 기록의 경우 로그인 시간 또는 데이터 번호(row_id) 등과 같이 인덱스를 통해서 데이터를 시간순 또는 데이터 번호순으로 조금씩 잘 가져갈 수 있는지 확인이 필요합니다.
  • 테이블에 인덱스가 없거나 잘못되었을 경우 나중에 테이블 사이즈가 커지면 인덱스를 잡기 어렵거나 서비스를 중단하고 점검을 통해서 인덱스를 생성해야 하는 경우가 있습니다. (매우 중요합니다.)

 

 

이제 데이터를 심는 과정이 어느 정도 완료되었습니다. 더욱 자세하게 들어가면 데이터 QA가 데이터를 검증하고 DA(Data Architecture)가 데이터 용어사전과 칼럼의 명칭과 형식이 맞는지 등의 검증도 필요하지만 이 부분은 데이터 엔지니어와 DBA가 어느 정도 동반하여 진행합니다. 

 

데이터가 이제 RDB에 쌓이기 시작하면 데이터를 심는 과정이 끝났다고 볼 수 있습니다. 

 

---

 

3. 데이터 적재

데이터를 옮기자

 

우리가 지금까지 했던 부분은 OLTP(Online transaction processing)에 해당하는 부분입니다. 실시간으로 데이터가 쌓이며 사용자가 어떠한 행위를 했을 때 즉시 쌓이는 데이터 환경입니다. 이 환경의 경우 DBA가 담당하며 RDB에 쌓이는 데이터를 뜻 합니다. 이렇게 쌓여 있는 데이터를 분석하고 지표를 만들기 위해서는 OLAP(Online Analytical Processing) 환경으로 옮기는 작업이 필요합니다. (OLAP는 DW입니다. / 글의 흐름을 위해서 OLAP라고 이 단원에서는 부릅니다.)

 

이러한 과정을 ETL(Extract, Transform, Load)이라고 합니다. 이 과정은 추출(Extract), 변환(Transform), 적재(Load)의 3가지 단계로 나누어집니다. 최근에는 많은 회사에서 ETL 보다는 ELT를 선호하는 경우가 많습니다. 앞에서 나온 추출 하여 변환하고 적재하는 것이 아닌 추출하고 적재하고 변환하는 과정으로 프로세스를 진행합니다.

 

일단 쌓고 보자

 

이것은 최근에 선호하는 방법으로써 데이터의 저장 공간이 저렴해지고 클라우드의 등장으로 인해서 대규모 데이터를 처리하는 것이 쉬워지면서 변화된 추세입니다. 저의 개인적인 생각으로는 ELT가 훨씬 더 많은 이점이 있습니다. 앞서 언급했듯이 저장공간의 비용이 싸지고 처리의 속도가 빨라지면서 우선 원천 데이터를 OLTP 환경에서 그대로 가져와서 저장하고 필요에 따라서 적절하게 가공하여 바로바로 쓸 수 있도록 하는 것이 OLTP 환경에 부하를 적게 줄 수 있습니다. 만약에 ETL을 한다면 데이터를 이미 가공하였기에 기획의 의도가 변경되거나 불가피하게 데이터를 수정해야 하는 이슈가 있을 경우 다시 한번 OTLP에서 OLAP 환경으로 데이터를 가져와야 하는 이슈가 있기 때문에 ELT가 더욱 이점이 많다고 생각됩니다. 그리고 OLAP의 경우 여러 가지 방법을 통해서 데이터를 가공하거나 합니다. 아주 다양한 도구가 있지만 제가 알고 있는 도구는 아래와 같습니다. 

 

다양한 도구들

 

약간씩 성격이 다를 수 있겠지만 대규모 데이터를 처리하고 가공하는 부분에 있어서 그 목적은 동일한 도구들입니다. 저 같은 경우 Google의 BigQuery를 주로 사용하고 선호하고 있습니다. SaaS(Software as a Service)이기 때문에 관리가 매우 쉽고 대규모 데이터 처리에서 별다른 세팅 없이 즉시 사용이 가능하다는 장점이 있습니다. 물론 데이터 사용량에 따라서 과금을 하기 때문에 무분별하게 사용하면 비용이 굉장히 많이 발생한다는 단점이 있지만 이 부분만 잘 관리하면 굉장히 좋은 도구라고 생각합니다. ( BigQuery 비용 관리 ) 

 

당연한 이야기겠지만 데이터를 1번 옮겼다고 끝나지 않습니다. 데이터를 옮기기 위해서도 여러 가지 도구가 필요하며 데이터의 동기화 (ELT) 주기에 따라서 도구가 달라지게 됩니다. 주로 배치성 (1시간, 1일 이상)의 데이터의 경우는 Airflow라는 도구를 통해서 주기적으로 데이터를 동기화하고 실시간성으로 하는 경우 Kafka , Spark Stream 등의 도구를 이용해서 주로 작업을 합니다. 

 

주기적인 작업을 하는 도구들

 

저 같은 경우 Airflow만 사용해 봤으며 주로 일 배 치나 1시간에 한 번씩 데이터를 동기화하였기 때문에 Airflow를 통해서 동기화를 진행하여도 큰 문제가 없었습니다. Airflow의 경우 굉장히 막강한 도구라고 생각되며 오픈소스이기 때문에 무료라는 점이 굉장히 매력적입니다. 

 

---

 

4. 데이터 가공 및 지표 개발

지표 보여주기

 

지표를 보여주는 마지막 단계로 데이터를 가공하고 이를 지표에 연결하여 보여줘야 합니다. 앞서 DW환경으로 데이터를 동기화하였다고 그 데이터를 그대로 지표에 연결하여 보여준다면 DW에서 부하가 발생할 수 있습니다. DW 환경에서는 수천, 수억 건의 데이터가 저장되어 있기 때문에 아무리 좋은 성능의 하드웨어와 도구를 붙여도 부하가 없진 않습니다.

 

데이터를 하다 보면 다음의 용어를 많이 접했을 듯합니다. Data Lake , Data Warehouse , Data Mart 등과 같이 불리는 용어를 많이 들어보셨을 것 같습니다. 그리고 FACT Table , Report Table , Dimension Table 등과 같은 용어도 많이 들어보셨을 거라 생각됩니다. 이 용어를 조금 더 알기 쉽게 그림과 같이 표현하면 다음과 같습니다. 

 

Data Lake / Data Warehouse

 

Data Lake

우선 Data Lake(바다, 호수)에서 생선(데이터)이 엄청나게 많습니다. 바다나 호수에는 다양한 종류의 생선이 있듯이 Data Lake에는 여러 종류의 데이터가 있습니다. 정형, 비정형, 반정형 등의 다양한 형태의 데이터가 있습니다. 여기에 일단 모든 데이터가 쌓인다고 보면 됩니다. 주로 Data Lake는 S3(Simple Storage Service)또는 GCS(Google Storage Service) 등과 같은 곳에 데이터를 쌓아 놓습니다. 

 

가끔 Data Lake가 없고 Data Warehouse만 있는 경우도 많은데, 꼭 Data Lake를 가지고 있을 필요는 없다고 생각합니다. 데이터가 반정형, 정형을 주로 취급할 경우는 저는 Data Lake가 꼭 필요하진 않다고 생각합니다. (실제로 없는 회사도 많습니다.) 그 목적과 사용에 따라서 Data Lake는 있을 수도 있고 없을 수도 있다고 생각합니다.

 

Data Warehouse

위의 바다, 호수에서 데이터를 잡아서(Extract / Data Lake가 없으면 RDS에서 데이터를 잡아서) 손질하여 창고에 보관합니다. 어느 정도 손질(Transform)을 하고 차곡차곡 창고에 넣어(Load) 둡니다. 데이터가 어느 정도 손질이 되어 있고 분류도 어느정도 되어 있기 때문에 Data Warehouse에서도 인사이트를 찾거나 바로 SQL을 통해서 질의하기도 합니다. 

 

 

Data Mart

 

Data Mart

창고(Warehouse)에서 보관된 생선(Data)은 이제 전국으로 퍼지게 됩니다. Data Mart는 각 용도에 맞는 데이터를 조금 더 비즈니스 모델 또는 프로젝트에 맞는 데이터끼리 모아서 조금 더 세부적으로 분류한 것을 뜻 합니다. 

 

 

FACT Table / Report Table

 

FACT , Report Table

이제 각각의 기호에 맞게 데이터를 사용할 수 있도록 가공해야 합니다. 생선을 창고에서 꺼내서 바로 먹을 수 없듯이 가공을 음식 형태로 미리 손질해놔야 합니다. 

 

가공 작업 없이 데이터를 row형태로 DW에 적재하였다고 그대로 SQL을 이용해서 지표에 연결할 경우 비용/성능면에서 매우 효율이 좋지 않습니다. 만약에 1건 정도의 데이터라면 크게 문제가 없을 수 있지만(그대로 해두는 게 좋다.) 100만 건 , 1000만 건 또는 수십억 건의 데이터를 매번 그때그때 SQL로 가져와서 지표에 보여준다면 지표가 데이터를 가져오는 시간만 수십 분이 걸릴 수 있습니다. 그렇기 때문에 미리 데이터를 시간, 일자, 주간, 월간으로 가공하여 적재해둡니다. 

 

이렇게 미리 가공을 한 테이블을 FACT 테이블이라고 합니다. 미리 가공을 해두었기 때문에 성능이나 비용에서 큰 무리가 없이 사용이 가능하고 여러 사용자가 정확한 기준으로 가공된 데이터를 볼 수 있으므로 혼선이 발생하는 것을 미리 방지할 수도 있습니다. 그리고 Report 테이블은 지표에서 즉시 조회할 수 있도록 FACT에서 조금 더 해당 지표에 맞게 데이터를 가공하여 더욱 작은 단위로 데이터를 쪼개서 저장한 테이블입니다. FACT가 그렇게 크지 않거나 Report가 굳이 필요하다고 판단되지 않을 경우 FACT를 그대로 붙이는 경우도 있습니다. 

 

다양한 BI 도구

 

이제 모든 준비를 마쳤으면 가공된 데이터를 토대로 지표를 개발해야 합니다. 지표를 개발할 때는 앞서 기획된 화면을 참고하여 지표를 개발할 수 있습니다. 저 같은 경우 Data Studio와 Tableau를 주로 사용하였는데, Data Studio의 경우 GCP의 다양한 도구와 바로 연동이 가능하다는 장점과 Goolge Sheets와 같은 Google의 도구와도 손쉽게 연동이 가능하다는 장점이 있습니다. 

 

하지만 무료인 만큼 제공이 안 되는 기능이 조금 있습니다. 반면 Tableau의 경우 유료이기 때문에 막강한 기능을 많이 제공하며 사용자 관점에서 조금 더 쉽게 사용이 가능합니다. (데이터를 가져와서 즉시 가공 가능 , 물론 성능상 좋진 않음) 그렇기에 본인의 상황에 맞게 어떠한 BI 도구를 사용할지 선택이 필요합니다. 

 

---

 

5. 그 밖에...

모니터링 및 운영

적재 및 가공 그리고 지표를 개발하는 것이 끝이 아닌 지속적으로 모니터링을 통해서 데이터를 정확하게 제공해야 합니다. 데이터가 정확하게 RDB에서 DW로 넘어왔는지 모니터링하는 작업이 필수적으로 필요합니다. 이를 하지 않을 경우 중복 및 누락으로 인하여 데이터가 정확하게 보이지 않을 경우가 있습니다. 이 경우 경영진 및 사업, 마케팅에서 판단을 할 때 잘못된 판단을 할 수 있습니다. 

 

데이터 정합성 체크

데이터 정합성 체크

https://burning-dba.tistory.com/130

RDBMS 데이터 적재 시 데이터 정합성 체크

 

DW 운영 (BigQuery)

 

불필요한 Dataset 삭제 

https://burning-dba.tistory.com/145

BigQuery - 운영 1탄 / 불필요한 dataset 삭제

 

BigQuery 사용량 관리

https://burning-dba.tistory.com/148

BigQuery - 운영 2탄 / Query 사용량 관리하기

 

BigQuery 비용 줄이기 

https://burning-dba.tistory.com/137

BigQuery 성능/비용 팁

 

---

 

6. 마치며...

지표 하나를 보기 위해서 수많은 팀의 수많은 사람들이 필요하며 수많은 과정이 필요합니다. 단순히 앞에 숫자 몇 개가 보인 다고 하여 쉽게 보여줄 수 있는 과정이 아닙니다. 많은 사람들이 지표 한 개만 표면적으로 보고 "이렇게 간단한데 왜 그렇게 말하지?"라고 생각합니다. 하지만 이 한 개의 지표를 보여주기 위해서 위에 언급한 수많은 과정이 필요합니다. 그리고 몇 번 언급하긴 했지만 이렇게 많이 설명했는데, 이 과정 또한 어느 정도 간략하게 줄인 내용입니다. 그렇기에 지표를 1개 보기 위한 과정을 굉장히 어렵습니다.

 

 

긴 글 읽어 주셔서 감사합니다.