MMP 데이터 분석 파이프라인 구축기 - 4탄 <Partitioning, Merging and Analysis>
Partitioning and Merging
Athena
S3에 적재된 JSON형태의 데이터는 이제 분석이 ‘가능한’ 상태가 되었습니다. 그렇다면 이 데이터는 무엇으로 분석할 수 있을까요? Amazon Athena를 이용하면 별다른 인프라 관리 없이도 바로 분석을 시작할 수 있습니다. Athena란, S3를 위한 서버리스 분산 (SQL) 쿼리 엔진입니다. 즉, S3에 데이터가 저장되어 있다면 SQL Query Engine을 이용해서 데이터를 쿼리(Query)할 수 있고, 효율적인 분석을 위해 분산 처리가 되어 결괏값을 빠르게 볼 수 있는 것입니다. 특히, Athena는 데이터베이스를 운영할 때 가장 많이 신경 써야 하는 부분 중 하나인 infrastructure 또는 resource에 대한 매니지먼트를 할 필요가 없는 서버리스(Serverless) 형태이기 때문에 사용한 만큼만 요금을 지불하면 된다는 장점이 있습니다.
(What Does the Fox Say - Athena의 소개)
또한 Athena는 CSV, TSV, JSON, Parquet 그리고 ORC 등 다양한 형태의 파일을 쿼리할 수 있도록 지원해 줍니다. 단, 별다른 제한을 주지 않으면 쿼리하는 만큼 과금되기 때문에 불필요한 계산이 너무 많이 되지 않도록 유의하며 사용해야 합니다.
Create Database
먼저, Athena 콘솔 쿼리 편집기에서 간단하게 데이터베이스를 생성합니다. 다음 CREATE DATABASE {databaseName}과 같은 Hive 데이터 정의 언어(Data Definition Language, DDL)를 이용하면 데이터베이스를 만들 수 있습니다. 또한 이미 생성된 데이터베이스를 이용하려면 왼쪽 콘솔 창에서 데이터베이스를 선택하면 됩니다.
(Athena DB 생성)
Create Table
이후, Hive DDL을 사용해서 테이블을 생성할 수 있습니다. 다음은 테이블 생성 쿼리인데요, mmp_db라는 데이터베이스를 생성한 후, mmp라는 External 테이블을 생성했고, S3버킷에 적재된 위치를 주었습니다.
CREATE EXTERNAL TABLE mmp_db.mmp`(
`app_version` string,
`device_download_time` timestamp,
`event_name` string,
`event_time` timestamp,
`event_value_user_id` string,
`event_value_comic_id` string,
`event_value_screen_name` string)
PARTITIONED BY (
`year` int,
`month` int,
`day` int,
`hour` int)
ROW FORMAT SERDE
'org.openx.data.jsonserde.JsonSerDe'
WITH SERDEPROPERTIES (
'classification'='json')
STORED AS INPUTFORMAT
'org.apache.hadoop.mapred.TextInputFormat'
OUTPUTFORMAT
'org.apache.hadoop.hive.ql.io.IgnoreKeyTextOutputFormat'
LOCATION
's3://data-lake-bucket-name/mmp/'
TBLPROPERTIES (
)
부분적으로 살펴보겠습니다.
CREATE EXTERNAL TABLE mmp_db.mmp`(
`app_version` string,
`device_download_time` timestamp,
`event_name` string,
`event_time` timestamp,
`event_value_user_id` string,
`event_value_comic_id` string,
`event_value_screen_name` string)
먼저, 적재된 데이터에서 읽을 칼럼(Column)과 타입을 명시해 줍니다. 각 칼럼에 대한 코멘트도 남길 수 있지만, 이 예시에서는 생략했습니다. Athena에서 칼럼 이름을 만들 때 다음과 같은 사항을 유의해야 합니다.
Athena 공식 문서에서 더 디테일하게 확인 할 수 있습니다.
소문자를 이용해서 이름을 작성해야합니다.
이름의 글자 수는 255자보다 작거나 같아야합니다.
밑줄(‘_’) 이외의 특수문자는 지원되지 않습니다.
MySQL과 같이 Athena에도 특정 예약어들이 있습니다.
ROW FORMAT SERDE
'org.openx.data.jsonserde.JsonSerDe'
WITH SERDEPROPERTIES (
'classification'='json')
STORED AS INPUTFORMAT
'org.apache.hadoop.mapred.TextInputFormat'
OUTPUTFORMAT
'org.apache.hadoop.hive.ql.io.IgnoreKeyTextOutputFormat'
이후 데이터가 어떤 포맷으로 저장되어 있는지에 대한 정보를 제공합니다. JSON 형식의 RAW 데이터를 쿼리하기 위해서 위와 같은 값을 주었고 Output의 format도 제공해 주었습니다. JSON 쿼리에 대한 자세한 내용은 Athena 공식 문서에 있습니다.
LOCATION 's3://data-lake-bucket-name/mmp/'
마지막으로 Raw JSON 데이터가 적재된 S3 Location을 주면 됩니다.
Create Partition
PARTITIONED BY (
`year` int,
`month` int,
`day` int,
`hour` int)
데이터를 원하는 만큼만 쿼리하기 위해 파티션을 만들어 두고, 쿼리할 때 만들어 둔 파티션을 이용하면 시간적으로도 데이터 스캔에 있어서 많은 이점을 얻을 수 있습니다. 앞서 보여주었던 테이블 생성 쿼리에서, 칼럼 선언 이후에 위와 같은 코드 블록이 있었습니다. 바로 파티션을 생성해 주는 코드입니다. 이 테이블에 속하는 데이터에 파티션을 부여하기 위해서는 PARTITIONED BY 명령어를 사용하며, 테이블 생성 시 파티션을 생성해 줄 수 있습니다.
Hive 스타일의 파티션을 사용한다면 테이블 Repair 쿼리를 통해서 파티션을 업데이트해 줄 수 있고, 만약 non-Hive 스타일의 파티션이라면 ALTER TABLE을 이용해서 파티션을 추가해 줄 수 있습니다. 저희는 RAW 테이블과 추후 설명해 드릴 parquet로 merge된 파일들을 쿼리할 수 있는 테이블을 위해 매시간 파티션을 추가해 주고 있습니다. 예시는 다음과 같습니다.
ALTER TABLE mmp_db.mmp ADD if NOT EXISTS
PARTITION (year=2022, month=07, day=25, hour=23)
LOCATION "s3://data-lake-bucket-name/mmp/year=2022/month=07/day=25/hour=23/"
PARTITION (year=2022, month=07, day=26, hour=00)
LOCATION "s3://data-lake-bucket-name/mmp/year=2022/month=07/day=26/hour=00/"
PARTITION (year=2022, month=07, day=26, hour=01)
LOCATION s3://data-lake-bucket-name/mmp/year=2022/month=07/day=26/hour=01/"
위의 예시는 2022년 7월 26일 UTC 00시 05분에 일어난 자동 파티션 생성 쿼리의 일부분입니다. Lambda를 이용해서 지금 시간 -1 시간(23), 현재 시(00) 그리고 +1시간이 된 시점까지(01) 파티션을 생성하고, 그 파티션의 데이터가 S3 버킷에서 어느 위치에 있는지를 연결해 준 작업을 한 것입니다. 이러한 쿼리를 매시간 돌려주면, 자동으로 새롭게 생성되는 데이터가 S3 버킷의 새로 지정해준 위치에 들어오게 됩니다. 그러면 데이터를 사용하는 유저들은 파티션을 사용해 효율적으로 쿼리할 수 있으므로 결국 많은 비용을 절약할 수 있습니다.
이 작업을 해주는 lambda 코드 예시는 AWS analytics immersion day Repository를 참고해주세요.
Query Data
테이블 생성이 성공적으로 완료되면, Athena에서 쿼리를 통해 해당 데이터들을 살펴볼 수 있습니다. 2022년 7월 7일에 생성된 데이터를 살펴보겠습니다. 아래 예시와 같이 year, month 그리고 day 파티션을 이용해서 전체 데이터를 스캔하지 않고 원하는만큼의 데이터만 스캔할 수 있습니다.
SELECT *
FROM mmp_db.mmp
WHERE year = 2022 and month = 07 and day = 07
아래는 예시 결과의 일부분입니다. 유저가 어떤 이벤트를 발생시켰고 어디에서 발생시켰는지에 대한 정보를 볼 수 있습니다. 이처럼 Athena를 이용해서 손쉽게 S3에 저장된 JSON 데이터를 바로 쿼리할 수 있습니다. 하지만 Athena 또는 다른 데이터 웨어하우스를 이용해서 쿼리한다는 것은 고비용이 요구되는 작업입니다. 또한 똑같은 데이터를 여러 번 쿼리하거나 큰 데이터를 계획 없이 반복적으로 JOIN한다고 하면 그 비용은 점점 더 증가하게 됩니다. 하지만 데이터 사이즈가 커질수록 원하는 수치를 계산하기 위해서 여러 테이블을 JOIN하는 것은 불가피합니다.
Athena와 같이 AWS Redshift라는 Data Warehouse를 이용해서도 비슷한 방식으로 쿼리를 할 수 있습니다. 바로 Redshift Spectrum이라는 기능입니다. 이 부분에 대해서는 이 글에서 상세하게 다루지 않습니다. 최근에는 사내에서 Redshift의 Materialized View를 이용해서 미리 원하는 테이블을 만들어서 이용하고 있는데요, 이 방식을 이용하면, 쿼리를 할 때마다 과금되지 않고 데이터를 미리 Redshift에 적재해두고 사용할 수도 있습니다.
Merge to Parquet
위에서 테스트한 것처럼 Athena를 이용하면 실시간 Raw Data를 쉽게 쿼리할 수 있지만, 데이터 사이즈가 커질수록 그리고 분석 시간이나 인력이 증가할수록 요금과 시간에 대한 부담은 커지기 마련입니다. 이러한 상황을 대비하기 위해서 쿼리가 빨리 끝나도록 미리 데이터를 작업해 두면 장기적으로는 많은 비용을 절감할 수 있고 분석 시간도 훨씬 절약할 수 있습니다. 즉, Athena에서 파티셔닝을 로드해 주는 작업 그리고 Columnar의 파일 형태인 Parquet 형태로 1시간 단위(또는 니즈에 따라 알맞는 단위로) 파일을 merge후 사용하는 것이 좋습니다.
(What Does the Fox Say? - Parquet? Columnar!)
Parquet란, columnar저장 포맷입니다. 한국어로는 열 기반 형식이라고 합니다. JSON 또는 정형화된 RDS는 메모리에 Row-wise로 데이터가 적재되는 반면, Parquet는 columnar 기반으로 데이터가 적재됩니다. 이 부분에 대해서는 이번 글에서 자세하게 설명하지 않겠습니다. 간략하게 설명하자면, 저장 공간에 데이터를 적재할 때 읽기 속도를 빠르게 할 수 있도록 각 칼럼의 데이터끼리 메모리에 나란히 나열해서 적재하는 방식이라고 설명할 수 있습니다. 즉, 분석하기 빠른 형태의 파일 저장 방식이라고 말할 수 있습니다. Athena 공식 문서에서 Columnar 형식으로 변환시의 Athena 쿼리 성능 개선에 대한 내용을 확인하실 수 있습니다.
JSON to Parquet
기존 JSON 파일을 담당하는 테이블에 파티션을 생성하고, 1시간 동안 적재된 파일을 스캔해서 Parquet 형태로 저장하며, 저장된 데이터를 불러올 수 있는 테이블에도 파티셔닝해 주는 작업이 필요합니다. 즉, 지난 한시간동안 생성된 여러개의 JSON 파일을 Parquet파일로 만들고, 그 파일을 year, month, day, hour로 나누어진 저장공간에 저장하게 따로 되면, 컴퓨터에서도 찾고 읽는 속도가 훨씬 향상됩니다. 관련있는 문서들을 책으로 묶고, 연도나 장르 등 자주 쓰는 카테고리에 맞게 가까운 곳에 함께 배치해두는 도서관 사서의 전략과 비슷하다고 생각할 수 있습니다. 저장 예시 쿼리는 다음과 같습니다.
CREATE TABLE mmp_db.tmp_mmp_parquet2022072600
WITH ( external_location='s3://data-lake-bucket-name/mmp-parquet/year=2022/month=07/day=26/hour=00/',
format = 'PARQUET',
parquet_compression = 'SNAPPY')
AS SELECT *
FROM mmp_db.tmp_mmp
WHERE year=2022 AND month=07 AND day=26 AND hour=00
WITH DATA
새로 추가하고 싶은 시간대의 파일들을 선택해서 Parquet 형식으로 원하는 위치에 저장하게 됩니다. 상황마다 달라지는 플랫폼 정보(android 또는 ios) 그리고 시간 데이터(연, 월, 일, 시간)를 유동적으로 넣어줄 수도 있고, 파티션을 적용할 데이터의 위치도 매번 바뀌기 때문에 아래와 같이 미리 structure를 생성해 둘 수도 있습니다. 이후, 쿼리에 알맞는 값을 format 함수를 이용해 넣어주고, 이 작업을 매시간 자동으로 수행할 수 있도록 Cloudwatch Events Bridge를 이용해서 매시 5분에 Lambda를 작동할 수 있도록 설정했습니다.
Drop Temporary Table
위의 방식대로 작업하면 매시간 temporary 테이블이 계속해서 생성됩니다. 이 테이블은 데이터를 parquet로 생성하기 위함이지 추후에 쿼리를 할 목적이 아니기 때문에 parquet 파일이 성공적으로 생성되어 지난 1시간의 데이터가 잘 merge되었다면 이후에 정리해 주는 작업이 필요합니다. 지난번 만들어진 tmp 테이블을 삭제해서 이미 작업이 완료된 테이블을 정리해 주면 데이터베이스를 정돈되게 유지할 수 있습니다.
DROP TABLE IF EXISTS appsflyer_db.tmp_mmp_parquet2022072523
위의 예시처럼, 2022년 7월 25일 23시부터 2022년 7월 26일 00시 사이에 생성된 데이터를 저장하는 작업을 해줄 때 생성되었던 temp 테이블은 삭제해줍니다. 이렇게 임시 테이블을 삭제 하는 작업 또한 매시간 진행해주었는데요, 1시간 이후, 2022년 7월 26일 01 - 02시 사이 적재된 데이터를 처리할 때는 1시간전 생성되었던 tmp_mmp_parquet2022072600 테이블을 삭제하게 됩니다.
Create Partition
ALTER TABLE mmp_db.mmp ADD if NOT EXISTS
PARTITION (year=2022, month=07, day=25, hour=23)
LOCATION "s3://data-lake-bucket-name/mmp/year=2022/month=07/day=25/hour=23/"
PARTITION (year=2022, month=07, day=26, hour=00)
LOCATION "s3://data-lake-bucket-name/mmp/year=2022/month=07/day=26/hour=00/"
PARTITION (year=2022, month=07, day=26, hour=01)
또한 앞서 JSON 파일에 해주었던 것처럼, 현재 시간을 포함해 전후로 파티션을 테이블에 생성하면, S3에 시간별로 나누어져 있는 데이터를 효율적으로 쿼리할 수 있습니다. Parquet로 한 번 merge한 데이터에 partition을 이용해서 조금 더 이점을 보는 것입니다.
Summary
이렇게 적재된 Raw JSON 데이터를 매시간 parquet 형태의 파일로 merge하는 방법으로 시간과 비용을 절약하면서 쿼리할 수 있는 전처리 작업을 수행하였습니다.
(MMP Architecture, Merge)
위 이미지에서 보시다시피,
- Cloudwatch가 매시 5분(예: 1시 5분, 2시 5분…)에 람다 함수를 작동하고
- 이 람다 함수는 Athena를 이용해서
- 1시간 전 데이터를 위해 작업했던 데이터를 삭제해 주고
- Data Lake tier-0에 쌓여 있는 JSON 형태의 small objects 중, 일정 기간의 데이터를 쿼리해서
- 결과값을 Data Lake tier-1에 분석에 효율적인 Parquet 형태로 변환해서 저장하고
- 저장 시 year, month, day, hour의 파티션을 생성하게 됩니다.
AWS에서 제공하는 Hands on exercise 중에 이 작업을 비슷하게 따라 할 수 있는 리소스가 있었습니다. 이 튜토리얼을 따라 한 후, 이 글에서 설명해 드린 전체 파이프라인 구축을 어렵지 않게 할 수 있었습니다. 또한 Github Repository에 공유된 Python 코드를 참고해서 파일을 merge하고 partition을 매시간 생성해 주는 Lambda 작업을 하는 데도 도움을 받을 수 있었습니다.
Cost Comparison
위에서 설명했던 JSON 파일을 이용해서 방금 들어온 RAW 데이터를 거의 실시간으로 쿼리하거나, 효율적으로 Merge된 데이터를 분석에 사용할 수 있는 환경이 되었습니다. 앞에서 설명드렸듯이, Parquet형식으로 Merge된 파일에 쿼리를 하면 훨씬 적은 용량의 데이터를 스캔해서 빠르게 결과를 도출하는 것을 볼 수 있습니다. 다음 표는 데이터 쿼리 결과를 비교하여 보여줍니다. 먼저, Raw파일이 500MB 이하인 데이터를 쿼리해 보았습니다.
500MB 이하 데이터 쿼리
| JSON (Raw) | Parquet (After Merge) | |
|---|---|---|
| Run time | 28.054 sec | 23.099 sec |
| Data scanned | 343.77 MB | 24.14 MB |
| Cost | $0.0018 | $0.0001 |
쿼리에 걸린 시간은 5초 정도 차이로 그렇게 많은 시간이 걸리지는 않았지만, 스캔된 데이터양을 보면 확연하게 많이 차이가 나는 것을 볼 수 있습니다. 14%에 해당하는 데이터만 스캔하여 요금을 1/7만큼 절감할 수 있었고, 조금 더 빠른 시간(5초)에 같은 내용의 데이터를 쿼리해서 볼 수 있었습니다. 조금 더 쿼리 양을 늘려서 측정해 보았습니다. 이번에는 Raw 형태의 JSON이 약 10GB 일 때, Merge 전후를 비교해 봤습니다.
10GB 이하 데이터
| JSON (Raw) | Parquet (After Merge) | |
|---|---|---|
| Run time | 3 min 3.854 sec | 2 min 50.359 sec |
| Data scanned | 9.54 GB | 685.73 MB |
| Cost | $0.0477 | $0.0034 |
시간은 약 13초가 단축되었는데요, Athena는 워낙 고성능 쿼리를 위한 엔진이다 보니 10GB의 데이터는 그렇게 큰 데이터가 아닌 것으로 보입니다. 그렇기 때문에 처리 시간이 많이 차이 나지는 않았습니다만, 스캔한 데이터양을 보면 분명히 다릅니다. 무려 약 8.8GB 줄어든 용량을 쿼리함으로써 비용도 약 1/14 만큼 줄어들었습니다. 한화로 계산했을 때, 0.0477달러는 약 62원, 0.0034달러는 약 4.46원 인데요, 적은 돈 같지만, 만약 이 쿼리가 매분 발생한다면 어떨까요? Raw 데이터는 약 2,000달러 (약 260만 원)가 발생하고, 전처리가 된 Parquet 파일의 경우에는 150달러(약 20만 원)가 발생하기 때문에 정말 많은 비용을 절감할 수 있습니다.
Daily 3000TB 데이터 쿼리 예시
| JSON (Raw) | Parquet (After Merge) | |
|---|---|---|
| Daily data scanned | ≈ 3000 TB | ≈ 300 TB |
| Monthly Data scanned | ≈ 30 PB | ≈ 3 PB |
| Cost | $450,000 | $45,000 |
실제 돌려보지는 않았지만, 만약 회사가 성장해서 하루 분석 용도로 처리하는 데이터가 3000TB라면 어떨까요? 1달 동안 매일 분석이 진행되었다면 약 30 PB의 데이터가 스캔되고, 이는 약 45만 달러(약 5억 9천만 원)라는 막대한 금액이 소요됩니다. 하지만 전처리를 해 두었다면, 약 10배 절감되어, 4만 5,000달러(약 5,900만 원)로 절감할 수 있습니다. 물론, 분석 시간에 있어서도 작은 데이터는 1분 내외의 차이지만, 데이터가 커지면 처리 시간에서도 더 많은 이점을 얻을 수 있게 됩니다.
데이터 엔지니어는 항상 비용 문제와 싸워야 하는 것 같습니다. 물론, 다른 인프라도 비용이 있고 무시할 수 없지만, 데이터 엔지니어가 구축하는 인프라는 평균적으로 비용이 훨씬 많이 들기 때문에 이런 기술 스택을 결정할 때 부담이 큰 것 같습니다. 사용자분이 어떤 쿼리를 사용하실지 알 수 없고, 모든 것을 예측하기는 힘듭니다. 그런 측면에서, 작은 Raw 데이터들을 좀더 큰 사이즈의 parquet로 합쳐서 저장하고 partitioning하는 작업은 꼭 필요하다고 생각합니다.
Business Intelligence, Quicksight
Quicksight는 BI(Business Intelligence) Tool입니다. 데이터를 텍스트 형태가 아닌 시각화해서 전체적인 인사이트를 파악하기도 하고, 중요한 지표를 자동으로 계산해서 실시간으로 확인할 수 있게 해 줍니다.
BI는 방대한 양의 데이터를 분석해 기업이 데이터를 활용해서 의사결정을 하는 프로세스를 의미하는데요, 흔히 BI 솔루션이라고 하면 데이터를 시각화하는 것을 의미합니다. 데이터 소스를 연결해 주고 원하는 분석 이미지를 만들어 두면 매일의 지표를 한눈에 파악하기 좋습니다.
(Quicksight 예시 이미지, 출처: Amazon Web Services)
한번 툴을 결정하면 비용 지출을 지속적으로 해야 하기 때문에, 저희는 Redash, Tableau 등 BI 툴 결정에 있어서 짧지 않은 논의를 거쳤습니다. 구축 이후 얼마나 많은 사내 유저가 사용할지와 보안상으로 안전한지를 따져 보았을 때, 초기에는 Quicksight로도 충분하다는 결정을 했습니다. 사용 빈도가 높아지고 다른 BI툴에 대한 요구도가 높아진다면, 그때 비용 투자를 더 하기로 했습니다. 그에 따라 현재는 회사 내부적으로 BI툴을 아주 다양하게 사용하게 되었고 분석 환경이나 전사적인 데이터 사용량도 전보다 많이 향상되었기 때문에, 다른 분석 툴의 사용도 고려하고 있습니다.
(What Does the Fox Say? - 천천히)
계정 작업과 Athena를 Quicksight에서 허용하는 작업을 해준 후 데이터세트를 생성하면, 사내 유저분들이 Datalake에 저장된 Appsflyer 데이터를 사용할 수 있습니다. 이때, 니즈에 맞게 데이터세트를 생성하는 것이 중요하기 때문에 어떠한 분석이 이루어질지에 대해 논의했습니다. 그리고 BI툴이나 Quicksight Analysis 생성 또는 대시보드의 이용을 처음 접하는 분이 많아 세 차례에 걸쳐서 기초부터 심화 레벨까지 인프라세션을 진행하여 Quicksight 유저분들의 이해도를 높이고 BI툴에 대한 친숙도를 높이기 위해 노력했습니다. 또한 Dashboard의 제작자분들이 대시보드 설명 세션도 진행해 주심으로써 많은 분이 대시보드를 이해하고 효율적으로 사용할 수 있는 환경을 만들어 나가는 데 도움을 주셨습니다.
데이터를 파티셔닝해 두었고 Parquet 포맷으로 저장해 두었기 때문에, Quicksight의 SPICE에 따로 저장하지 않고 사용해도 체감상으로는 큰 차이가 없었습니다. 다만, 대시보드를 유저가 볼 때마다 데이터를 쿼리하는 형식이기 때문에 Athena 쿼리 요금이 과금됩니다. 실시간 데이터가 중요하다고 생각되면 Athena에서 직접 쿼리를 하는 것이 유리하고 장기적인 데이터를 보는 것이 목적이고 1~2시간 전의 데이터까지는 포함이 되지 않아도 되는 분석이라면 SPICE를 활용해서 주기적으로 리프레시해도 좋을 것 같습니다. 또한 자주 사용하는 통계 데이터가 있다면, 별도의 통계 결과용 DB등을 만들어서 사용하는 것도 유리합니다.
지난 1년간 데이터 파이프라인과 분석 환경을 구축한 이후 많은 것이 달라졌습니다. 사내에서도 데이터를 사용하는 유저의 수가 대폭 증가했습니다. 데이터를 쿼리해 보고 시각화해 보면서 팀별로 다양한 대시보드가 생성되었고 다양한 분석이 진행되었습니다. 이러한 성장으로 최근 또 다른 BI툴과 Data Lake House 도입을 계획하고 있습니다. 처음부터 비용 투자를 과도하게 하기보다는 적당한 버짓 안에서, 데이터 엔지니어 1명이 구축, 유지, 보수 및 사용자 서포트까지 가능한 정도의 적정 사이즈의 인프라를 구축해 우리 회사의 데이터에 대해 많은 분이 알 수 있게 되었습니다. 그 기간에 저를 포함한 사내 데이터 유저분들의 숙련도도 향상돼서 ‘우리는 또 다른 BI 툴에 인력과 비용을 투자하기에 적절한 시기에 이르렀다’는 확신이 들게 되었습니다. 만약 초기 단계에 우리가 갖고 있는 데이터에 대한 이해도 없이 무조건 비싸고 ranking이 높은 툴을 사용했다면 그것은 과유불급이 되었을지도 모른다고 생각합니다.
마치며
데이터 엔지니어로서 커리어를 쌓은 지 오랜 시간이 지나진 않았지만, 그럼에도 불구하고 이 프로젝트를 주도하면서 성공적으로 배포할 수 있었던 이유는 태피툰 개발팀의 문화와 AWS Korea 스타트업 팀의 적극적인 서포트 덕분이라고 생각합니다. 인프라와 관련된 지식을 리서치하는 시간이 충분히 주어졌고, 무언가 풀리지 않을 때는 AWS 아키텍트분들의 도움을 받으면서 풀어 갈 수 있었습니다. 무엇보다도, 처음 해보는 저에게는 조금 시간이 걸리더라도 중간중간 실패하더라도 기다려주는 회사의 분위기가 원동력이 되어서 빠르게 dev 테스팅을 완료했고 총 2달여 만에 프로덕션에 배포할 수 있었습니다.
이상으로 MMP 데이터 분석 파이프라인 구축에 관한 기록을 마치겠습니다.
Reference
https://github.com/aws-samples/aws-analytics-immersion-day
https://catalog.us-east-1.prod.workshops.aws/workshops/a861fb26-12b0-4669-b3c3-ae1def49735d/en-US
