런칭 후 약 1년 간 타다 서비스의 데이터 웨어하우스의 변화 과정에 대해 소개합니다. 서버 데이터베이스의 Read Replica 로 시작해서, RDBMS 로 데이터를 모으던 과도기를 거쳐, 현재 BigQuery 에 이르기까지. 각 단계별로 가능했던 것들과 아쉬웠던 것들, 그리고 이를 해결하기 위한 고민 들에 대해 얘기합니다.
기쁜 소식 : 서버 DB 로 Aurora MySQL 선택 ● RDBMS 라서 직접 SQL 가능 (비트윈은 메인 DB 로 HBase) ● Amazon Aurora 라서 Read Replica 띄우는게 간단 ● Read Replica 띄우고 Holistics 연결 2019.10.19 데이터야 놀자
BI 서비스 : Holistics 를 예시로 ● 다양한 데이터 소스 연결 ○ 데이터 소스 마다 적합한 연결 방식 제공 (e.g. VPC 내의 RDBMS -> SSH Reverse Tunneling) https://www.holistics.io/integrations/ 광고 X 2019.10.19 데이터야 놀자
BI 서비스 : Holistics 를 예시로 ● 다이나믹 필터 ○ SQL 적고 구멍 뚫어두면 -> 이후 대시보드 조회하는 유저가 원하는 값으로 SQL Formatting https://docs.holistics.io/docs/filters 광고 X 2019.10.19 데이터야 놀자
BI 서비스 : Holistics 를 예시로 ● 원하는 스케줄 / 방식으로 데이터 추출 및 전달 ○ 이메일, 슬랙, 구글 시트 (직접 Sheets API 써서 개발하려면 은근 번거로움), SFTP ○ e.g. 구글 시트로 Raw 데이터 추출 -> (구글 시트만 쓸 줄 알면) 원하는 형태로 대시보드 제작 광고 X 2019.10.19 데이터야 놀자
다양한 솔루션 https://www.softwareadvice.com/bi/#top-products Apache Superset ● (유료 제품) Mode Analytics, Chartio, Periscope Data, Holistics 등 ● (오픈소스) Apache Superset, Redash 등 ● 필요와 상황에 따라 적절히 선택 2019.10.19 데이터야 놀자
Read Replica ● Console 에서 클릭 몇 번으로 Read Replica 생성 https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-replicas-adding.html . . . 2019.10.19 데이터야 놀자
● 기존 테이블 -> SQL -> 새로운 테이블 추가하기 힘듦 ○ 새로운 테이블 -> Read Replica 가 아닌 Master 에 + Read 가 아닌 Write 권한 필요 ○ Master 의 schema 변경 -> 서버 배포 파이프라인 중 일부 (Liquibase 로 관리) ○ 서버 개발 프로세스에 엮이기보다, 독립적으로 진행하고 싶은 마음 ■ 서버 개발 = 핵심 비즈니스 로직 / 협업 / 신중한 배포 ■ 분석은 이와는 별개의 작업 런칭 직후 : 아쉬운 점 2019.10.19 데이터야 놀자
런칭 직후 : 아쉬운 점 ● SQL 표현력이 아쉬움 ○ Aurora MySQL 2.x (2.04.6 이 최신) ~ MySQL 5.7 Compatible ○ Analytic Function 은 MySQL 8.0.2 부터 지원 ■ e.g. 유저의 직전 호출 시각 -> Analytic Function 이 없다면 힘듦 어찌 저찌 할 수는 있음 ○ Array, Struct 타입도 지원하지 않음 ■ e.g. 유저의 리뷰 항목들 2019.10.19 데이터야 놀자
런칭 직후 : 정리 ● Amazon Aurora (MySQL) Read Replica (+ Holistics) ○ 코드 1줄 없이 설정 + SQL 만으로 빠르게 리포트 / 대시보드 생성 가능 ○ 새로운 테이블 추가 힘듦, SQL 표현력 아쉬움, 여러 데이터 소스 JOIN 불가능 ○ 아직 데이터 웨어하우스는 아님 ● 리포트 / 대시보드 작업 2019.10.19 데이터야 놀자 Icon made by Freepik from www.flaticon.com
Apache Spark ● Uniform Data Access ○ CSV / JSON / Parquet / JDBC 등 다양한 데이터 소스를 거의 똑같이 생긴 API 로 Read / Write 2019.10.19 데이터야 놀자 https://databricks.com/spark/about
MySQL 8 / PostgreSQL 10 ● 처음에 MySQL 8 쓰다가 -> PostgreSQL 10 로 이동 ○ MySQL 8.0.11 에서 TEXT 타입으로 partition by 했을 때 틀린 결과가 나온 경험 (TEXT -> CHAR 하면 됨) ○ PostgreSQL 은 Array, Composite 타입 제공 ○ date_trunc 함수 등 소소하지만 분석에 도움이 되는 기능들이 많음 2019.10.19 데이터야 놀자
Spark 로 RDBMS UPSERT ● 원하는건 UPSERT ○ 기존 테이블에 해당 Primary Key 의 record 가 없으면 -> INSERT ○ 기존 테이블에 해당 Primary Key 의 record 가 존재하면 -> UPDATE ● 여러가지 방법이 가능 ○ Dataset#foreachPartition 으로 뭉치 단위로 INSERT ○ 적절한 단위로 (Partition) Read -> 임시 테이블로 Write -> UPSERT SQL 실행 -> 임시 테이블 Drop 2019.10.19 데이터야 놀자
Spark 로 RDBMS UPSERT ● 임시 테이블 Write -> 기존 테이블에 UPSERT ○ DataFrame 의 schema 정보를 써서 UPSERT SQL 생성 ○ MySQL / PostgreSQL 이 크게 다르지 않음 MySQL PostgreSQL 2019.10.19 데이터야 놀자
Spark 로 RDBMS UPSERT ● 적절한 단위 (Partition) 에 대한 고민 ○ 테이블의 TIMESTAMP 타입 컬럼의 값과 비즈니스 로직을 적절히 활용 ○ Partition 나누는 기준 = record 의 insert 시각 ○ 비즈니스 로직을 고려하여 -> Partition 에 더 이상의 변화가 없을 때 까지 UPSERT ● e.g. 유저의 호출이 하나의 record 로 쌓이는 ride 테이블 ○ 호출 시각 (created_at) 기준으로 Partitioning ○ 상태 (status) 컬럼 값이 DROPPED_OFF (하차) 혹은 CANCELED (취소) 가 될 때 까지 UPSERT ● 관련하여 생각을 정리한 개인 블로그 포스트 2019.10.19 데이터야 놀자
로그 수집 ● Kinesis Data Firehose ○ Kinesis Data Stream 선택 ○ Record transform : X (서버 -> Kinesis Data Stream 으로 넣은 ndjson 그대로) ○ Record format conversion : X (서버 -> Kinesis Data Stream 으로 넣은 ndjson 그대로) ○ Destination : Amazon S3 / Amazon Redshift / Amazon Elasticsearch Service / Splunk ○ Buffer size / Buffer interval : 둘 중 어느 하나 먼저 만족되면 -> S3 에 새로운 JSON 파일 Put ○ 일단 쌓고 나중에 생각 ● 필요하다면 transform, format conversion 가능 ○ 데이터 전처리 / Format 변환 (e.g. Kinesis Data Stream 에는 JSON -> S3 에는 Parquet 로) 2019.10.19 데이터야 놀자
과도기 : 아쉬운 점 ● 탄력적인 Scale-In / Out 이 힘듦 ○ 퇴근 시간 지나면 사용률이 현저히 낮아짐 ○ 가끔 매우 큰 데이터를 처리하는 쿼리 실행 필요 e.g. 6개월치 차량 위치 데이터로 이동거리 패턴 분석 ○ RDBMS 라는 특성상 Scale-In / Out 이 어려움 2019.10.19 데이터야 놀자
과도기 : 정리 ● 데이터 웨어하우스로 Amazon RDS ○ 여러 소스의 데이터를 한 곳으로 모으면서 -> JOIN 가능 ○ 개선된 SQL 표현력 ○ 서버와 별도의 데이터베이스 -> 새로운 테이블 추가가 용이 ○ 리소스 관리가 힘듦 ● 리포트 / 대시보드 작업 . . . . . . . 2019.10.19 데이터야 놀자 Icon made by Freepik from www.flaticon.com
RDBMS -> 매니지드 (Managed) 데이터 웨어하우스 ● Amazon Athena 도전 ○ 서버 로그는 단일 data class 라서 근본적으로 STRUCT : 비즈니스 로직 추가 -> 컬럼 추가 발생 가능 ○ (Athena 의 기반이 되는) Presto 0.172 버전은 STRUCT 타입의 schema update 를 허용하지 않음 2019.10.19 데이터야 놀자
RDBMS -> 매니지드 (Managed) 데이터 웨어하우스 ● Amazon Athena 도전 ○ schema 관리는 Glue Data Catalog 사용 권장 -> 테이블 / 파티션 schema 각각 관리 필요 ○ Crawler 를 쓸 수도 있지만 -> 단순히 schema 업데이트를 위해 쓰기에는 과하다는 생각 2019.10.19 데이터야 놀자
Google BigQuery ● BigQuery is a serverless, highly-scalable, and cost-effective cloud data warehouse with an in-memory BI Engine and machine learning built in. 2019.10.19 데이터야 놀자
Partitioned Table ● DATE or TIMESTAMP 타입 컬럼에 대한 Partitioning 제공 ○ TIMESTAMP 타입 컬럼으로 Partitioning 해도 -> 실제 Partitioning 은 UTC 기준 DATE 단위로 ○ (국내 서비스니까) Asia/Seoul 기준 DATE 컬럼을 달고 (= date_kr) 그 컬럼으로 Partitioning ○ SQL 성능 UP + Partition 단위로 데이터 Load 할 수 있어 배치 (Batch) 작업에 편리 2019-10-19 ... 2019-10-01 ... 2019-01-01 where date(created_at, ‘Asia/Seoul’) = ‘2019-10-01’ 2019-10-19 ... 2019-10-01 ... 2019-01-01 where date_kr = ‘2019-10-01’ 2019.10.19 데이터야 놀자
Partitioned Table ● Amazon RDS 시절 Spark 로 데이터 옮길 때도 이미 Partition 단위로 처리 ○ 본래 Spark Application 의 코드 패턴과 거의 유사 : Partition UPSERT 대신 Partition 교체 ○ 작은 테이블 (처리 시간 10분 미만) -> 매번 전체 테이블 Overwrite ○ 큰 테이블 -> Date Partitioned 테이블로 만들고 Partition 단위로 교체 2019.10.19 데이터야 놀자
현재 : 정리 ● Google BigQuery 로 이전 ○ 매니지드 데이터 웨어하우스 -> 인프라 관리 비용 ZERO ○ 높은 확장성 + 강력한 SQL 표현력 + 편리한 Console -> 더 많은 팀원들의 + 더 많은 데이터 분석 ○ + Firebase Analytics SDK 으로 찍는 라이더 앱 / 드라이버 앱 로그는 자동으로 BigQuery 에 쌓임 ● 리포트 / 대시보드 작업 . . . . . . . 2019.10.19 데이터야 놀자 Icon made by Freepik from www.flaticon.com
데이터 엔지니어로서 느낀 점 ● 좋은 데이터 웨어하우스? ○ 팀이 풀고자 하는 미션 + 처한 상황에 따라 선택은 달라질 것 ■ e.g. Cloud Storage / BigQuery 면 스토리지 비용 2배? AWS -> GCP 데이터 옮기는거 별론데? ○ Google BigQuery -> 현재 저희 상황에 적합할 뿐 ○ 다른 상황 / 다른 팀 -> 더 좋은 다른 데이터 웨어하우스가 있을 지도 2019.10.19 데이터야 놀자
데이터 엔지니어로서 느낀 점 ● 다양한 환경의 가능한 데이터 웨어하우스들의 장단점 파악하는 능력 중요 + 필요 ○ AWS -> Amazon Redshift, Amazon Athena, Amazon Aurora Serverless 등 ○ Azure -> SQL Data Warehouse 등 ○ GCP -> Google BigQuery 등 ○ On-Premise 혹은 매니지드 서비스 원치 않음 -> Presto, Apache Druid 등 ○ 그 외의 다양한 선택지들 2019.10.19 데이터야 놀자
● 개인적 아쉬움 ○ 다양한 선택지들을 미리 파악하고 있었더라면 ○ 돌이켜보니 길었던 과도기 -> 이전한 뒤 100여개 리포트 / 대시보드 SQL 도 이전 ○ 그래도 일련의 시행 착오가 성장에는 큰 도움이 하핫 데이터 엔지니어로서 느낀 점 2019.10.19 데이터야 놀자
We Are Hiring ● 힘들지만 재밌게 문제를 해결하고 있고, 문제 -> 시도 -> 해결 -> 성장 -> 문제 -> 시도 -> 해결 -> 성장 -> ... ● 팀도 커졌고, ● 앞으로 풀 재밌는 문제들도 많으니, 배치 작업 고도화, 스트리밍 아키텍처 고민, 시뮬레이터, MLOps ... ● 함께하실 분들은 -> 타다 채용 ● tadacareer.vcnc.co.kr ● [email protected] 광고 O 2019.10.19 데이터야 놀자
vcnc
seike460
ivargrimstad
terhechte
heyitsmohit
star_zero
parttimenerd
hazumirr
slsops
uhooi
malarkey
speakerdeck
bryan
jasonvnalue
denniskardys
pedronauck
kastner
trishagee
62gerente
tenderlove
deanohume