데브시스터즈 데이터 레이크 구축 이야기 : Data Lake architecture case study (박주홍 데이터 분석 및 인프라 팀장 / 이준호 데이터 분석 및 BI 팀장, 데브시스터즈) :: Gaming on AWS 2018
12 likes6,158 views
데브시스터즈 데이터 레이크 구축 이야기 : Data Lake architecture case study 이 세션에서는 데브시스터즈의 Case Study를 통하여 Data Lake를 만들고 사용하는데 있어 요구 되는 사항들에 대해 공유합니다. 여러 목적에 맞는 데이터를 전달하기 위해 AWS 를 활용하여 Data Lake 를 구축하게된 계기와 실제 구축 작업을 하면서 경험하게 된 것들에 대해 말씀드리고자 합니다. 기존 인프라 구조 대비 효율성 및 비용적 측면을 소개해드리고, 빅데이터를 이용한 부서별 데이터 세분화를 진행할 때 어떠한 Architecture가 사용되었는지 소개드리고자 합니다.
![Athena 시작하기
– Only Two Steps to start Athena
테이블 생성
S3에 저장된 Parquet 파일을 외부스키마로 설정
CREATE EXTERNAL TABLE [table name]
파티션의 데이터를 로드
MSCK REPAIR TABLE [table name]
데이터 쿼리](https://image.slidesharecdn.com/gamingonaws-devsisters-181101004619/85/Data-Lake-architecture-case-study-BI-Gaming-on-AWS-2018-58-320.jpg)
![Athena – 테이블 생성
테이블 생성
S3에 저장된 Parquet 파일을 외부스키마로 설정
CREATE EXTERNAL TABLE [table name]
CREATE EXTERNAL TABLE `d_country`(
`country_code` string
, `country` string
, `is_target_country` int)
PARTITIONED BY (date STRING)
STORED AS PARQUET
LOCATION 's3://dw/d_country/’
TBLPROPERTIES ("parquet.compress"="SNAPPY");](https://image.slidesharecdn.com/gamingonaws-devsisters-181101004619/85/Data-Lake-architecture-case-study-BI-Gaming-on-AWS-2018-59-320.jpg)
![Athena – 데이터 로드
파티션의 데이터를 로드
MSCK REPAIR TABLE
ALTER TABLE
MSCK REPAIR TABLE [table name]
ALTER TABLE [table name] ADD
PARTITION (dt = '2016-05-14') LOCATION 's3://dw/sub_folder’](https://image.slidesharecdn.com/gamingonaws-devsisters-181101004619/85/Data-Lake-architecture-case-study-BI-Gaming-on-AWS-2018-60-320.jpg)
데브시스터즈 데이터 레이크 구축 이야기 : Data Lake architecture case study (박주홍 데이터 분석 및 인프라 팀장 / 이준호 데이터 분석 및 BI 팀장, 데브시스터즈) :: Gaming on AWS 2018
- 2. © 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved. 박주홍 데이터 분석 및 인프라 팀장 / 이준호 데이터 분석 및 BI 팀장 데브시스터즈 데브시스터즈 데이터 레이크 구축 이야기 : Data Lake architecture case study
- 3. 컨텐츠, 기술, 서비스를 통해 세상을 더욱 더 즐겁게 만들기 위해 도전하는 글로벌 엔터테인먼트 기업 • 2007년 5월 22일 설립 • 2014년 10월 코스닥 상장
- 4. 대표작 | 쿠키런 쿠키런 for Kakao | 2013년 4월 2일 출시 LINE 쿠키런 | 2014년 1월 29일 출시 쿠키런 OvenBreak | 2016년 10월 28일 출시 쿠키워즈 | 2018년 8월 23일 출시
- 5. 발표자 및 팀 소개
- 6. 발표자 및 팀 소개 박주홍 DEVSISTERS | Data Scientist • KAIST 수리과학과 • Server Engineer • Data Engineer • 쿠키런 데이터 연구, CHI LBW 발표 • Data Science & Infrastructure 팀장
- 7. 데이터 분석 및 인프라 구축 • 데이터 과학자 • 데이터 엔지니어 • 머신러닝 엔지니어 주요 업무 • 데이터 모델링 및 예측 • A/B Test 인프라 설계 및 구축 • 멀티 게임 데이터 분석을 위한 다중 클러스터 구축 • 데이터 레이크 및 데이터 파이프라인 구축 발표자 및 팀 소개 Data Science & Infrastructure
- 8. Devsisters Data Infra Before
- 9. Semi-Structure Indexing Indexed Log Devsisters Data Infra Before 2014년 – Data Infra & Application Raw Log CS 팀: CS 응대 분석 팀: KPI 추출
- 10. Devsisters Data Infra Before Semi Structure Indexing • JSON 형태의 Game Log • 유저 번호, 유저 행동, 시간으로 Indexing • 주로 CS 대응시 고객 게임 기록 조회, KPI 추출
- 11. Devsisters Data Infra Before Semi Structure Indexing • JSON 형태의 Game Log • 유저 번호, 유저 행동, 시간으로 Indexing • 주로 CS 대응시 고객 게임 기록 조회, KPI 추출 Game Log {“id”:1234, “action”: “play”, “timestamp”: “1234567890”, “score”: 300, ”level”: 12, “coin”: 7}
- 12. Devsisters Data Infra Before Semi Structure Indexing • JSON 형태의 Game Log • 유저 번호, 유저 행동, 시간으로 Indexing • 주로 CS 대응시 고객 게임 기록 조회, KPI 추출 Game Log {“id”:1234, “action”: “play”, “timestamp”: “1234567890”, “score”: 300, ”level”: 12, “coin”: 7} Indexing {“id”:1234, “action”: “play”, “timestamp”: “1234567890”, “score”: 300, ”level”: 12, “coin”: 7}
- 13. Devsisters Data Infra Before Semi Structure Indexing • JSON 형태의 Game Log • 유저 번호, 유저 행동, 시간으로 Indexing • 주로 CS 대응시 고객 게임 기록 조회, KPI 추출 Game Log {“id”:1234, “action”: “play”, “timestamp”: “1234567890”, “score”: 300, ”level”: 12, “coin”: 7} Indexing {“id”:1234, “action”: “play”, “timestamp”: “1234567890”, “score”: 300, ”level”: 12, “coin”: 7} Querying SELECT * FROM game_log WHERE id = 1234 SELECT count(*) FROM game_log WHERE action = “play”
- 15. Various Data Request 부서마다 다른 데이터 요청 분석팀 Json 단위 데이터 조회 특정 Field 만 조회 EX) COUNT(DISTINCT USER) CS팀 모든 로그 중에서 필요 로그 조회 전체의 50%만 필요 마케팅팀 요청시마다 해당일 데이터 가공 일별 고객 정보 스냅샷 필요 BI Spark 로 직접 데이터 추출 후 분석 SQL 문법으로 직접 접근
- 16. Data Lake 도입
- 17. Data Lake 도입 Data Lake 도입 배경 부서별 다양한 데이터 요청 응대 요청 데이터 활용을 위한 다양한 포맷 지원 데이터 계층화를 통한 데이터 활용성 증대
- 18. Data Lake 도입 Parquet 활용 • Columnar Storage Format • 특정 Field 만 접근 가능 • Partition 지원 • Spark Dataframe 호환
- 19. Data Lake 도입 Parquet 활용 • Columnar Storage Format • 특정 Field 만 접근 가능 • Partition 지원 • Spark Dataframe 호환 Source: http://www.saphanacentral.com/p/row-store-vs-column-store.html
- 20. Data Lake 도입 Parquet 활용 • Columnar Storage Format • 특정 Field 만 접근 가능 • Partition 지원 • Spark Dataframe 호환 Source: http://www.saphanacentral.com/p/row-store-vs-column-store.html
- 21. Data Lake 도입 Parquet 활용 • Columnar Storage Format • 특정 Field 만 접근 가능 • Partition 지원 • Spark Dataframe 호환 SELECT sum(Sales) FROM Table Source: http://www.saphanacentral.com/p/row-store-vs-column-store.html
- 22. Data Lake 도입 Parquet 활용 • Columnar Storage Format • 특정 Field 만 접근 가능 • Partition 지원 • Spark Dataframe 호환 SELECT sum(Sales) FROM Table Source: http://www.saphanacentral.com/p/row-store-vs-column-store.html
- 23. Data Lake 도입 Parquet 활용 • Columnar Storage Format • 특정 Field 만 접근 가능 • Partition 지원 • Spark Dataframe 호환 SELECT sum(Sales) FROM Table Source: http://www.saphanacentral.com/p/row-store-vs-column-store.html
- 24. Data Lake 도입 Parquet 활용 • Columnar Storage Format • 특정 Field 만 접근 가능 • Partition 지원 • Spark Dataframe 호환 SELECT sum(Sales) FROM Table WHERE Country = “India” Source: http://www.saphanacentral.com/p/row-store-vs-column-store.html
- 25. Data Lake 도입 Parquet 활용 • Columnar Storage Format • 특정 Field 만 접근 가능 • Partition 지원 • Spark Dataframe 호환 SELECT sum(Sales) FROM Table WHERE Country = “India” Source: http://www.saphanacentral.com/p/row-store-vs-column-store.html
- 26. Data Lake 도입 Parquet 활용 • Columnar Storage Format • 특정 Field 만 접근 가능 • Partition 지원 • Spark Dataframe 호환 SELECT sum(Sales) FROM Table WHERE Country = “India” Source: http://www.saphanacentral.com/p/row-store-vs-column-store.html
- 27. Data Lake 도입 Parquet 활용 • Columnar Storage Format • 특정 Field 만 접근 가능 • Partition 지원 • Spark Dataframe 호환 SELECT sum(Sales) FROM Table WHERE Country = “India” Table Country=India Country=Germany Country=US Source: http://www.saphanacentral.com/p/row-store-vs-column-store.html
- 28. Data Lake 도입 Parquet 활용 • Columnar Storage Format • 특정 Field 만 접근 가능 • Partition 지원 • Spark Dataframe 호환 SELECT sum(Sales) FROM Table WHERE Country = “India” Table Country=India Country=Germany Country=US Source: http://www.saphanacentral.com/p/row-store-vs-column-store.html
- 29. Data Lake 도입 Parquet 활용 • Columnar Storage Format • 특정 Field 만 접근 가능 • Partition 지원 • Spark Dataframe 호환 Table Country=India Country=Germany Country=US SELECT sum(Sales) FROM Table WHERE Country = “India” spark.read.parquet(“s3://path/Country=India”) .agg(sum(“Sales”)) Source: http://www.saphanacentral.com/p/row-store-vs-column-store.html
- 30. Data Lake 도입 Data 계층화 • 전혀 가공 없는 Raw Data • Glacier 활용 • Raw Source 백업 용도 Raw Layer • 중복 제거, 결함있는 로그 수정 등 전처리 • Log 종류별 Partition • 실질적으로 활용하는 로그 Analytics Layer • 데이터 요청 목적에 맞도록 가공 • 필요한 부서별 접근 권한 관리 및 용량 최적화 • 목적에 맞게 Data Format 및 Indexing Objective Layer
- 31. Data Lake 도입 Data Lake 를 통한 데이터 요청 응대 분석팀 Json 단위 데이터 조회 특정 Field 만 조회 EX) COUNT(DISTINCT USER) Parquet 도입 Columnar Storage Format CS팀 모든 로그 중에서 필요 로그 조회 전체의 50%만 필요 필요 데이터 추출 후 Indexing 하여 저장 마케팅팀 요청시마다 해당일 데이터 가공 일별 고객 정보 스냅샷 필요 Parquet 도입 Date 파티션 BI Spark 로 직접 데이터 추출 후 분석 SQL 문법으로 직접 접근 Parquet 도입 Athena 로 접근
- 32. Devsisters Data Infra After
- 33. Semi-Structure Indexing Indexed Log Devsisters Data Infra After 2014년 – Data Infra & Application Raw Log CS 팀: CS 응대 분석 팀: KPI 추출
- 34. Write Parquet Raw Log (Parquet) Devsisters Data Infra After 2018년 – Data Lake Raw Layer
- 35. Write Parquet Raw Log (Parquet) Devsisters Data Infra After 2018년 – Data Lake Raw Layer Preprocessing Analytics Log Date, Action Partition Analytic Layer
- 36. Write Parquet Raw Log (Parquet) Devsisters Data Infra After 2018년 – Data Lake Raw Layer Preprocessing Indexed Log Analytics Log Date, Action Partition Data Analysis Marketing Snapshot Date Partition Semi-Structure Indexing DW Athena Analytic Layer Objective Layer CS 팀: CS 응대 분석 팀: KPI 추출 마케팅 팀: 트랜드 분석 BI 팀: BI 분석
- 37. Write Parquet Raw Log (Parquet) Devsisters Data Infra After 2018년 – Data Lake Raw Layer Preprocessing Indexed Log Analytics Log Date, Action Partition Data Analysis Marketing Snapshot Date Partition Semi-Structure Indexing DW Athena Analytic Layer Objective Layer CS 팀: CS 응대 분석 팀: KPI 추출 마케팅 팀: 트랜드 분석 BI 팀: BI 분석
- 38. 발표자 변경
- 39. 발표자 소개 이준호 DEVSISTERS | Business Intelligence Analyst • 데이터 분석 업무 • In-Game event 효과 측정 분석 • 마케팅 채널 효율 분석 • A/B Test • Dashboard 설계 및 구현 • Data Lake 설계 및 구현
- 40. 기존 분석환경 AWS S3AWS EC2 AWS RDS
- 41. 기존 분석환경 장점 AWS S3AWS EC2 AWS RDS Flintrock으로 많은 부분 자동화 1.AWS EC2 서버 셋팅 2.서버에 Spark 및 각종 라이브러리 설치 3.Driver와 Worker 연결 4.추가 기능 : Add & Remove Worker 기능
- 42. 첫번째 이슈 - 분석환경 셋팅 AWS S3AWS EC2 AWS RDS On-Premise 환경에 익숙한 BI 분석가에게는 분석을 시작하기 까지 환경설정 시간이 오래 걸림 1. EC2할당 받기까지 대기 시간 2. 할당된 EC2에 spark 및 각종 라이브러리 설치 시간 3. Driver – Worker 설정 시간 3단계가 문제없이 진행된다면 약 7~10분안에 셋팅이 되지만 하나라도 잘 안된다면 retry하는 시간 발생
- 43. 첫번째 이슈 - 분석환경 셋팅
- 44. 두번째 이슈 - 데이터 크기 AWS S3AWS EC2 AWS RDS
- 45. 두번째 이슈 - 데이터 크기 AWS S3 1. 분석 용도로 사용하기 버거운 파일 크기 • Columnar Storage 형식이 아니어서 모든 key값을 읽어야함 • 3개월 치 주요 KPI를 추출한다고 가정하면 r4.2xlarge 클러스터를 약 32대 정도 띄워야 원활하게 작업이 가능함 2. 로그 별 각종 전처리 필요 • Ex 1) 매출정보에서 안드로이드에서 KRW 결제금액은 yyyy-mm-dd 일부터 VAT 제외 • Ex 2) AU 집계시 dummy 유저는 제외 • 분석가 마다 처리하는 로직이 다를 수 있음 • 같은 소스를 가지고 분석하지만 수치가 달라져 end-user 입장에서 혼란이 가중됨
- 46. 세번째 이슈 – 배치 작업 및 대시보드 생성 AWS S3AWS EC2 AWS RDS
- 47. 세번째 이슈 – 배치 작업 및 대시보드 생성 1. AWS RDS 데이터 마트 • 적은 비용으로 RDS를 유지하면서 주요 dashboard를 만들 수 있었지만, 분석 용도로 활용하기에는 어려움이 있었음 • Dashboard에 End-user의 추가 요청사항이 발생할 경우, 그에 맞는 테이블을 추가로 구축이 필요 • 관련 코드를 Airflow에 등록 • 데이터가 맞는지 Notebook 분석환경에서 작업한 코드를 그대로 사용하지 못함 (batch 작업에 맞게 변경이 필요) • Batch 작업이 이상없이 잘 돌아가는지 테스트가 필요 AWS RDS
- 48. 문제 정의 및 개선방안 1. 오래 걸리는 분석환경 셋팅 2. 분석하기에는 파일 사이즈가 큰 로그 데이터 3. 같은 source지만 분석가 마다 다른 로그 전처리 과정으로 인한 결과물 불일치 • 즉시 접근이 가능한 분석환경 구축 • 표준 SQL 사용 • 각 로그 별 분석에 필요한 key값만 선정하여 column flat하게 저장 • Columnar Storage를 지원하는 파일형식으로 저장 • 1차적인 예외처리를 진행한 뒤에 파일로 저장 Amazon Athena 문제정의 개선방안 솔루션 4. Batch 작업으로 정리된 RDS table이 다용도로 사용되지 못함 • 다양한 소스의 데이터를 한곳에 저장하여 필요에 따라 꺼내 쓰기 Data Lake
- 49. Data Lake 구축 /login /billing /play_trophy /play_ovenbreak Json – meta file f_login f_billing f_play_trophy f_play_ovenbreak d_country d_currency d_card f_member f_play_total Log Data Fact & Dimension Table Summary Table ……
- 50. 데이터 로드 속도 비교 140.8 10.1 /login f_login 로그인 정보 추출 속도 (단위: Sec) -93% • 클러스터 : R4.2xlarge * 9대 (Driver 포함) • 클러스터당 메모리 : 50GB 기존 분석환경에서 3개월 치 로그인 정보를 로드하는 속도를 비교할 때, /login 보다 정리된 f_login 테이블에서 데이터를 로드하는 속도가 93% 개선됨
- 51. SQL query engine 벤치마크 SPECTRUM 벤치마크 대상 솔루션 선정시 고려한 점 1. 빠른 데이터 처리속도를 담보하고 2. 범용성 – Dashboard 제작 및 데이터 분석 모두 함께 사용가능 해야 하며 3. 기존 Infra에서 최소한의 관리 및 코스트로 변경 가능하면서 4. 비용을 optimization 할 수 있는 제품
- 52. SQL query engine 벤치마크 테스트에 사용된 데이터 및 추출 항목 • 데이터: 3개월 치 로그 • Login, Billing 로그 • 추출 항목: 주요 Daily KPI • Active User / Paying User / PUR / Revenue / ARPU / ARPPU 벤치마크 측정 항목 • 결과물이 나오기까지 Runtime • 비용
- 53. 솔루션 벤치마크 - 상세 설정 내용 Solution Cluster Type # of Machines Cost SQL Engine AWS EC2 & Spark r4.2xlarge • vCPU : 8 • ECU : 27 • 메모리 : 61GiB 1 - Driver 2 - Workers 1 Driver : 1 * $0.532/h 2 Workers : 2 * $0.13/h Total : $0.792/h PySpark Redshift dc2.large • vCPU : 2 • ECU : 7 • 메모리 : 15 GiB • 스토리지 : 0.16 TB – SSD • I/O : 0.60 GB/s 2 2 * $0.25/h Total : $0.5/h Postgre Redshift Spectrum The same as Redshift 2 Redshift Cost + $5 per 1TB Postgre Athena - - $5 per 1TB Presto
- 54. 솔루션 벤치마크 - 결과 0.0295 0.001 0.0101 0.007 USD Cost Spark Redshift Redshift Spectrum Athena 67.6 6.4 25.0 7.5 Sec Runtime (sec) Spark Redshift Redshift Spectrum Athena Spark Redshift Redshift Spectrum Athena 걸린시간 (sec) 67.6 6.4 25.0 7.5 걸린시간 (min) 1.13 0.11 0.42 0.13 걸린시간 (hr) 0.019 0.002 0.007 0.002 $ per hour 1.572 0.5 0.5 duration cost (USD) 0.03 0.00 0.00 - Scan Size (mb) 1,330 1,330 tb로 환산 0.001330 0.001330 computing cost (USD) 0.0067 0.0067 Total Cost (USD) 0.0295 0.0009 0.0101 0.0067
- 55. 솔루션 벤치마크 - 결과 67.6 41.0 22.4 15.0 12.7 2대 4대 8대 16대 32대 Seconds Worker 개수별 Spark SQL 처리속도 기존 분석 환경에서는 클러스터를 32대 사용해도 Redshift, Athena 각각 6.4s, 7.5s 보다 약 70~100%정도 느림
- 56. 솔루션 벤치마크 - 결과 가장 저렴하고 빠른건 Redshift 였지만 몇가지 단점이 있었음 클러스터 설정 및 비용 데이터 Copy 각종 key 설정
- 57. 솔루션 벤치마크 - 결과 가장 저렴하고 빠른건 Redshift 였지만 몇가지 단점이 있었음 1. 클러스터를 항상 띄워두거나 사용하고 싶을때만 켜야함 • 현재 온디멘드 쓰는것과 동일한 구조로 불편 2. 태생적으로 idle time에도 클러스터 개수에 따른 비용이 부과됨 3. 그리고 s3 parquet 파일을 Redshift 쪽으로 데이터를 copy 해야하는 작업이 필요함 • 데이터 이동에 따른 비용은 없지만, 설정한 클러스터 스펙에 넘치는 스토리지 용량이 필요할 경우 추가 클러스터를 띄워야 함 (비용 발생) • copy하는데 시간이 걸림 (걸리는 시간은 미미함) • 3개월치 정리된 유저 play 기록을 복사하는데 약 11분 걸림 (1.32GB) 4. RDB 처럼 primary_key, foreign_key를 정해줘야하고 추가로 • sort_key (정렬키), dist_type (분산 스타일), dist_key (분산키) 를 정해줘야함 쿼리 성능에 큰 영향을 미침 • Copy로 추가되는 데이터가 sort_key의 정렬을 따르지 않거나 중간에 삭제하는 레코드가 생길 경우 vaccum이라는 작업을 주기적으로 실행해야 쿼리 성능을 유지할 수 있음
- 58. Athena 시작하기 – Only Two Steps to start Athena 테이블 생성 S3에 저장된 Parquet 파일을 외부스키마로 설정 CREATE EXTERNAL TABLE [table name] 파티션의 데이터를 로드 MSCK REPAIR TABLE [table name] 데이터 쿼리
- 59. Athena – 테이블 생성 테이블 생성 S3에 저장된 Parquet 파일을 외부스키마로 설정 CREATE EXTERNAL TABLE [table name] CREATE EXTERNAL TABLE `d_country`( `country_code` string , `country` string , `is_target_country` int) PARTITIONED BY (date STRING) STORED AS PARQUET LOCATION 's3://dw/d_country/’ TBLPROPERTIES ("parquet.compress"="SNAPPY");
- 60. Athena – 데이터 로드 파티션의 데이터를 로드 MSCK REPAIR TABLE ALTER TABLE MSCK REPAIR TABLE [table name] ALTER TABLE [table name] ADD PARTITION (dt = '2016-05-14') LOCATION 's3://dw/sub_folder’
- 61. Athena를 사용하기 위한 관리 포인트 자동화 스키마 설정 파티션 인식 AWS Glue Crawler
- 62. 새로운 분석환경 AWS S3AWS EC2 AWS RDS Athena Glue
- 63. 새로운 분석환경의 장점 Hot하게 사용되는 로그는 Column flat하게 정리하여 Data Lake에 저장하고 Athena로 데이터에 직접 접근 데이터 전처리 리소스 절약 빠른 Ad-hoc 분석 빠른 Dashboard 생성
- 64. 새로운 분석환경의 장점 • 분석가가 달라져도 동일한 source 데이터를 활용하게 되므로 중복으로 발생되는 전처리 리소스를 절약함 • 속도가 빠른 Athena로 s3 파일에 직접 접근하여 쿼리가 가능해짐 • Ad-hoc한 분석할 때 시간 단축 • 새로운 지표 추가할 때 데이터 wrangling 작업을 줄이고, 배치작업 없이 바로 대시보드를 만들 수 있음
- 65. Write Parquet Raw Log (Parquet) Devsisters Data Infra After 2018년 – Data Lake Raw Layer Preprocessing Indexed Log Analytics Log Date, Action Partition Data Analysis Marketing Snapshot Date Partition Semi-Structure Indexing DW Athena Analytic Layer Objective Layer CS 팀: CS 응대 분석 팀: KPI 추출 마케팅 팀: 트랜드 분석 BI 팀: BI 분석
- 66. Thank you 박주홍/데이터 분석 및 인프라 팀장 J.Park@devsisters.com 이준호/Business Intelligence 팀장 Junho.lee@devsisters.com