Upgrade to Pro — share decks privately, control downloads, hide ads and more …

타다 (TADA) 서비스의 데이터 웨어하우스 : 태초부터 현재까지

VCNC
October 19, 2019

타다 (TADA) 서비스의 데이터 웨어하우스 : 태초부터 현재까지

런칭 후 약 1년 간 타다 서비스의 데이터 웨어하우스의 변화 과정에 대해 소개합니다. 서버 데이터베이스의 Read Replica 로 시작해서, RDBMS 로 데이터를 모으던 과도기를 거쳐, 현재 BigQuery 에 이르기까지. 각 단계별로 가능했던 것들과 아쉬웠던 것들, 그리고 이를 해결하기 위한 고민 들에 대해 얘기합니다.

데이터야놀자 in 2019-10-19 토요일

VCNC

October 19, 2019
Tweet

More Decks by VCNC

Other Decks in Programming

Transcript

  1. • 데이터 엔지니어 @ VCNC • 서버 개발자 9개월 +

    데이터 엔지니어 2년 5개월 • 궁금한 것들 찾아보고 개발 블로그에 적는 걸 좋아함 • 산업기능요원 복무 완료한 지 1개월 발표자 소개 2019.10.19 데이터야 놀자
  2. • 타다 (TADA) 서버 최초 커밋 ◦ 회의 때 노트북을

    잘 챙겨가면, 두고두고 우려먹을 껀덕지가 생김 TMI 2019.10.19 데이터야 놀자
  3. 타다 (TADA) • 새로운 이동의 기준을 제시하는 모빌리티 플랫폼 •

    2019년 10월 8일 : 타다 베이직 런칭 1주년 2019.10.19 데이터야 놀자
  4. 오늘 나눌 이야기 • 런칭 후 ~ 약 1년간 데이터

    웨어하우스 변천사 (+ 배운 것들) 현재 인수 런칭 직후 과도기 (아쉬운 점) (아쉬운 점) 2019.10.19 데이터야 놀자
  5. 오늘 나눌 이야기 • 이런 분들께 도움이 되었으면 ◦ 데이터

    웨어하우스가 무엇인지 궁금하신 분들 ◦ 데이터 웨어하우스를 구성 할 / 구성 중이신 분들 2019.10.19 데이터야 놀자
  6. 약간의 배경 설명 Icon made by Freepik from www.flaticon.com 4명

    -> 1명 = 발표자 2019.10.19 데이터야 놀자
  7. 기쁜 소식 : 서버 DB 로 Aurora MySQL 선택 •

    RDBMS 라서 직접 SQL 가능 (비트윈은 메인 DB 로 HBase) • Amazon Aurora 라서 Read Replica 띄우는게 간단 • Read Replica 띄우고 Holistics 연결 2019.10.19 데이터야 놀자
  8. Holistics? • 유료 BI (Business Intelligence) 서비스 • 여러가지 기능

    제공 -> (약간의) 돈으로 엔지니어의 시간을 교환! 광고 X 2019.10.19 데이터야 놀자
  9. BI 서비스 : Holistics 를 예시로 • 다양한 데이터 소스

    연결 ◦ 데이터 소스 마다 적합한 연결 방식 제공 (e.g. VPC 내의 RDBMS -> SSH Reverse Tunneling) https://www.holistics.io/integrations/ 광고 X 2019.10.19 데이터야 놀자
  10. BI 서비스 : Holistics 를 예시로 • 다이나믹 필터 ◦

    SQL 적고 구멍 뚫어두면 -> 이후 대시보드 조회하는 유저가 원하는 값으로 SQL Formatting https://docs.holistics.io/docs/filters 광고 X 2019.10.19 데이터야 놀자
  11. BI 서비스 : Holistics 를 예시로 • 브라우저에서 UI 설정만으로

    쿼리 결과를 다양하게 시각화 ◦ Pivot Table, Line Chart, Combination Chart, Cohort Retention ... 광고 X 2019.10.19 데이터야 놀자
  12. BI 서비스 : Holistics 를 예시로 • 원하는 스케줄 /

    방식으로 데이터 추출 및 전달 ◦ 이메일, 슬랙, 구글 시트 (직접 Sheets API 써서 개발하려면 은근 번거로움), SFTP ◦ e.g. 구글 시트로 Raw 데이터 추출 -> (구글 시트만 쓸 줄 알면) 원하는 형태로 대시보드 제작 광고 X 2019.10.19 데이터야 놀자
  13. 다양한 솔루션 https://www.softwareadvice.com/bi/#top-products Apache Superset • (유료 제품) Mode Analytics,

    Chartio, Periscope Data, Holistics 등 • (오픈소스) Apache Superset, Redash 등 • 필요와 상황에 따라 적절히 선택 2019.10.19 데이터야 놀자
  14. Read Replica • Console 에서 클릭 몇 번으로 Read Replica

    생성 https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-replicas-adding.html . . . 2019.10.19 데이터야 놀자
  15. Read Replica • (Holistics 가 제공하는) SSH Reverse Tunneling 스크립트만

    실행 하면 -> 설정 끝! https://docs.holistics.io/docs/tunnel-setup 2019.10.19 데이터야 놀자
  16. • 기존 테이블 -> SQL -> 새로운 테이블 추가하기 힘듦

    ◦ 새로운 테이블 -> Read Replica 가 아닌 Master 에 + Read 가 아닌 Write 권한 필요 ◦ Master 의 schema 변경 -> 서버 배포 파이프라인 중 일부 (Liquibase 로 관리) ◦ 서버 개발 프로세스에 엮이기보다, 독립적으로 진행하고 싶은 마음 ▪ 서버 개발 = 핵심 비즈니스 로직 / 협업 / 신중한 배포 ▪ 분석은 이와는 별개의 작업 런칭 직후 : 아쉬운 점 2019.10.19 데이터야 놀자
  17. 런칭 직후 : 아쉬운 점 • 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 데이터야 놀자
  18. 런칭 직후 : 아쉬운 점 • 여러 데이터 소스 JOIN

    할 수 없음 ◦ 용도에 따라 분리한 서버 DB 2개 + S3 에 쌓이는 JSON 로그 ◦ 각각을 BI 서비스에 연동하는 건 가능하지만, 그들을 JOIN 하는건 불가능 2019.10.19 데이터야 놀자
  19. 런칭 직후 : 정리 • Amazon Aurora (MySQL) Read Replica

    (+ Holistics) ◦ 코드 1줄 없이 설정 + SQL 만으로 빠르게 리포트 / 대시보드 생성 가능 ◦ 새로운 테이블 추가 힘듦, SQL 표현력 아쉬움, 여러 데이터 소스 JOIN 불가능 ◦ 아직 데이터 웨어하우스는 아님 • 리포트 / 대시보드 작업 2019.10.19 데이터야 놀자 Icon made by Freepik from www.flaticon.com
  20. • 다양한 리포트 / 대시보드 작업을 혼자서 처리하기 위한 최선의

    선택 런칭 직후 : 정리 2019.10.19 데이터야 놀자
  21. 데이터를 한 곳으로 • 별도의 RDBMS 를 띄우고 -> Spark

    로 데이터를 모으고 -> BI 서비스에 연결 2019.10.19 데이터야 놀자
  22. Apache Spark • Uniform Data Access ◦ CSV / JSON

    / Parquet / JDBC 등 다양한 데이터 소스를 거의 똑같이 생긴 API 로 Read / Write 2019.10.19 데이터야 놀자 https://databricks.com/spark/about
  23. Apache Spark • Uniform Data Access DataFrame write.csv(...) write.json(...) write.parquet(...)

    write.jdbc(...) spark.read.csv(...) spark.read.json(...) spark.read.parquet(...) spark.read..jdbc(...) 2019.10.19 데이터야 놀자
  24. MySQL 8 / PostgreSQL 10 • Amazon RDS ◦ 역시나

    매니지드 서비스 -> 쉽게 데이터베이스 띄울 수 있음 2019.10.19 데이터야 놀자
  25. 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 데이터야 놀자
  26. Spark 로 RDBMS UPSERT • Spark 로 Write 할 때는

    Append / Overwrite 만 가능 2019.10.19 데이터야 놀자
  27. Spark 로 RDBMS UPSERT • 원하는건 UPSERT ◦ 기존 테이블에

    해당 Primary Key 의 record 가 없으면 -> INSERT ◦ 기존 테이블에 해당 Primary Key 의 record 가 존재하면 -> UPDATE • 여러가지 방법이 가능 ◦ Dataset#foreachPartition 으로 뭉치 단위로 INSERT ◦ 적절한 단위로 (Partition) Read -> 임시 테이블로 Write -> UPSERT SQL 실행 -> 임시 테이블 Drop 2019.10.19 데이터야 놀자
  28. Spark 로 RDBMS UPSERT • 임시 테이블 Write -> 기존

    테이블에 UPSERT 서버 DB 데이터 웨어하우스 2019.10.19 데이터야 놀자
  29. Spark 로 RDBMS UPSERT • 임시 테이블 Write -> 기존

    테이블에 UPSERT 서버 DB 데이터 웨어하우스 임시 테이블 spark application 에서 df.write.jdbc(...) 2019.10.19 데이터야 놀자
  30. Spark 로 RDBMS UPSERT • 임시 테이블 Write -> 기존

    테이블에 UPSERT 서버 DB 데이터 웨어하우스 임시 테이블 DBMS 에서 insert … on duplicate ... 2019.10.19 데이터야 놀자
  31. Spark 로 RDBMS UPSERT • 임시 테이블 Write -> 기존

    테이블에 UPSERT 서버 DB 데이터 웨어하우스 DBMS 에서 drop table ... 2019.10.19 데이터야 놀자
  32. Spark 로 RDBMS UPSERT • 임시 테이블 Write -> 기존

    테이블에 UPSERT 서버 DB 데이터 웨어하우스 배치 (Batch) 실행 사이 시간 동안 데이터 변화 2019.10.19 데이터야 놀자
  33. Spark 로 RDBMS UPSERT • 임시 테이블 Write -> 기존

    테이블에 UPSERT 서버 DB 데이터 웨어하우스 임시 테이블 spark application 에서 df.write.jdbc(...) 2019.10.19 데이터야 놀자
  34. • 임시 테이블 Write -> 기존 테이블에 UPSERT update insert

    Spark 로 RDBMS UPSERT 서버 DB 데이터 웨어하우스 임시 테이블 DBMS 에서 insert … on duplicate ... 2019.10.19 데이터야 놀자
  35. • 임시 테이블 Write -> 기존 테이블에 UPSERT Spark 로

    RDBMS UPSERT 서버 DB 데이터 웨어하우스 DBMS 에서 drop table ... 2019.10.19 데이터야 놀자
  36. Spark 로 RDBMS UPSERT • 임시 테이블 Write -> 기존

    테이블에 UPSERT ◦ DataFrame 의 schema 정보를 써서 UPSERT SQL 생성 ◦ MySQL / PostgreSQL 이 크게 다르지 않음 MySQL PostgreSQL 2019.10.19 데이터야 놀자
  37. Spark 로 RDBMS UPSERT • 임시 테이블 Write -> 기존

    테이블에 UPSERT ◦ 작업이 멱등적이라 좋음 2019.10.19 데이터야 놀자
  38. 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 데이터야 놀자
  39. 로그 수집 • Kinesis Data Firehose ◦ 코드 없이 AWS

    Console 설정만으로 Kinesis Data Stream -> S3 https://speakerdeck.com/vcnc/eksreul-hwalyonghan-tada-seobiseu-gucuggi?slide=25 2019.10.19 데이터야 놀자
  40. 로그 수집 • 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 데이터야 놀자
  41. 과도기 : 아쉬운 점 • 탄력적인 Scale-In / Out 이

    힘듦 ◦ 퇴근 시간 지나면 사용률이 현저히 낮아짐 ◦ 가끔 매우 큰 데이터를 처리하는 쿼리 실행 필요 e.g. 6개월치 차량 위치 데이터로 이동거리 패턴 분석 ◦ RDBMS 라는 특성상 Scale-In / Out 이 어려움 2019.10.19 데이터야 놀자
  42. 과도기 : 정리 • 데이터 웨어하우스로 Amazon RDS ◦ 여러

    소스의 데이터를 한 곳으로 모으면서 -> JOIN 가능 ◦ 개선된 SQL 표현력 ◦ 서버와 별도의 데이터베이스 -> 새로운 테이블 추가가 용이 ◦ 리소스 관리가 힘듦 • 리포트 / 대시보드 작업 . . . . . . . 2019.10.19 데이터야 놀자 Icon made by Freepik from www.flaticon.com
  43. RDBMS -> ? • 고려했던 친구들 ◦ Presto ◦ Amazon

    Redshift ◦ Amazon Athena ◦ Google BigQuery 2019.10.19 데이터야 놀자
  44. RDBMS -> 매니지드 (Managed) 데이터 웨어하우스 • 고려했던 친구들 ◦

    Presto (EMR Cluster 가 도와주지만 일단 운영이 필요하긴 함) ◦ Amazon Redshift (scale in/out 하려면 명시적인 resize 작업 필요) ◦ Amazon Athena ◦ Google BigQuery 2019.10.19 데이터야 놀자
  45. RDBMS -> 매니지드 (Managed) 데이터 웨어하우스 • Amazon Athena 도전

    ◦ 서버 로그는 단일 data class 라서 근본적으로 STRUCT : 비즈니스 로직 추가 -> 컬럼 추가 발생 가능 ◦ (Athena 의 기반이 되는) Presto 0.172 버전은 STRUCT 타입의 schema update 를 허용하지 않음 2019.10.19 데이터야 놀자
  46. RDBMS -> 매니지드 (Managed) 데이터 웨어하우스 • Amazon Athena 도전

    ◦ schema 관리는 Glue Data Catalog 사용 권장 -> 테이블 / 파티션 schema 각각 관리 필요 ◦ Crawler 를 쓸 수도 있지만 -> 단순히 schema 업데이트를 위해 쓰기에는 과하다는 생각 2019.10.19 데이터야 놀자
  47. RDBMS -> 매니지드 (Managed) 데이터 웨어하우스 • Amazon Athena 도전

    ◦ Console 기능이 아쉬움 ◦ e.g. SQL 을 실행해야지만 처리되는 데이터 크기를 (= 과금 기준) 알 수 있음 2019.10.19 데이터야 놀자
  48. RDBMS -> 매니지드 (Managed) 데이터 웨어하우스 • 고려했던 친구들 ◦

    Presto ◦ Amazon Redshift ◦ Amazon Athena ◦ Google BigQuery 2019.10.19 데이터야 놀자
  49. 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 데이터야 놀자
  50. 높은 확장성 (highly-scalable) • e.g. 차량 궤적 데이터 처리 ◦

    아래 SQL -> 수백 GB / 수백억 records 처리 2019.10.19 데이터야 놀자
  51. 높은 확장성 (highly-scalable) • 쿼리 실행 -> Execution details 짧은

    소요 시간 x 수백배의 컴퓨팅 (?) 시간 2019.10.19 데이터야 놀자
  52. 높은 확장성 (highly-scalable) • Classical UI 로 보면 좀 더

    많은 정보 ◦ console.cloud.google.com 에서 console -> bigquery 로 수정 ◦ 최대 수천 units 2019.10.19 데이터야 놀자
  53. 저장+쿼리한 만큼 과금 • 스토리지 + 쿼리 처리량 만큼 과금

    (Amazon Athena 도 비슷) • Amazon RDS 때는 인스턴스 타입 시간당 가격 x 시간으로 과금 2019.10.19 데이터야 놀자
  54. 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 데이터야 놀자
  55. Partitioned Table • Amazon RDS 시절 Spark 로 데이터 옮길

    때도 이미 Partition 단위로 처리 ◦ 본래 Spark Application 의 코드 패턴과 거의 유사 : Partition UPSERT 대신 Partition 교체 ◦ 작은 테이블 (처리 시간 10분 미만) -> 매번 전체 테이블 Overwrite ◦ 큰 테이블 -> Date Partitioned 테이블로 만들고 Partition 단위로 교체 2019.10.19 데이터야 놀자
  56. 현재 : 정리 • Google BigQuery 로 이전 ◦ 매니지드

    데이터 웨어하우스 -> 인프라 관리 비용 ZERO ◦ 높은 확장성 + 강력한 SQL 표현력 + 편리한 Console -> 더 많은 팀원들의 + 더 많은 데이터 분석 ◦ + Firebase Analytics SDK 으로 찍는 라이더 앱 / 드라이버 앱 로그는 자동으로 BigQuery 에 쌓임 • 리포트 / 대시보드 작업 . . . . . . . 2019.10.19 데이터야 놀자 Icon made by Freepik from www.flaticon.com
  57. 분석 쿼리 유저 1~2 5~10 49 런칭 직후 과도기 현재

    (2019.10.01 ~ ) 2019.10.19 데이터야 놀자
  58. 240개 / 380일 ~ 0.6개 / 일 140개 / 120일

    ~ 1.2개 / 일 리포트 / 대시보드 (BigQuery 이전 후) 2019.10.19 데이터야 놀자
  59. 좋은 데이터 웨어하우스 (+ SQL 활용력) • 데이터-드리븐 (Data-Driven) 팀으로

    나아가는데 있어 중요한 역할을 하는 듯 2019.10.19 데이터야 놀자
  60. 데이터 엔지니어로서 느낀 점 • 좋은 데이터 웨어하우스? ◦ 팀이

    풀고자 하는 미션 + 처한 상황에 따라 선택은 달라질 것 ▪ e.g. Cloud Storage / BigQuery 면 스토리지 비용 2배? AWS -> GCP 데이터 옮기는거 별론데? ◦ Google BigQuery -> 현재 저희 상황에 적합할 뿐 ◦ 다른 상황 / 다른 팀 -> 더 좋은 다른 데이터 웨어하우스가 있을 지도 2019.10.19 데이터야 놀자
  61. 데이터 엔지니어로서 느낀 점 • 다양한 환경의 가능한 데이터 웨어하우스들의

    장단점 파악하는 능력 중요 + 필요 ◦ AWS -> Amazon Redshift, Amazon Athena, Amazon Aurora Serverless 등 ◦ Azure -> SQL Data Warehouse 등 ◦ GCP -> Google BigQuery 등 ◦ On-Premise 혹은 매니지드 서비스 원치 않음 -> Presto, Apache Druid 등 ◦ 그 외의 다양한 선택지들 2019.10.19 데이터야 놀자
  62. • 개인적 아쉬움 ◦ 다양한 선택지들을 미리 파악하고 있었더라면 ◦

    돌이켜보니 길었던 과도기 -> 이전한 뒤 100여개 리포트 / 대시보드 SQL 도 이전 ◦ 그래도 일련의 시행 착오가 성장에는 큰 도움이 하핫 데이터 엔지니어로서 느낀 점 2019.10.19 데이터야 놀자
  63. 결론 • 좋은 데이터 웨어하우스 -> 데이터 드리븐 팀으로 나아가는데

    큰 역할 • 데이터 엔지니어 -> 좋은 데이터 웨어하우스에 대해 끊임없이 고민 + 탐색 2019.10.19 데이터야 놀자
  64. We Are Hiring • 힘들지만 재밌게 문제를 해결하고 있고, 문제

    -> 시도 -> 해결 -> 성장 -> 문제 -> 시도 -> 해결 -> 성장 -> ... • 팀도 커졌고, • 앞으로 풀 재밌는 문제들도 많으니, 배치 작업 고도화, 스트리밍 아키텍처 고민, 시뮬레이터, MLOps ... • 함께하실 분들은 -> 타다 채용 • tadacareer.vcnc.co.kr • [email protected] 광고 O 2019.10.19 데이터야 놀자
  65. Thanks to 발표자 지원 + 발표 준비에 큰 도움을 주신

    SOCAR 변성윤님 (a.k.a @zzsza) 2019.10.19 데이터야 놀자