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

6a11050c8147e4f5fbf2637907c27964?s=47 VCNC
October 19, 2019

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

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

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

6a11050c8147e4f5fbf2637907c27964?s=128

VCNC

October 19, 2019
Tweet

Transcript

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

    (Max) 2019.10.19 데이터야 놀자
  2. • 데이터 엔지니어 @ VCNC • 서버 개발자 9개월 +

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

    잘 챙겨가면, 두고두고 우려먹을 껀덕지가 생김 TMI 2019.10.19 데이터야 놀자
  4. VCNC • Value Creators & Company 2019.10.19 데이터야 놀자

  5. 타다 (TADA) • 새로운 이동의 기준을 제시하는 모빌리티 플랫폼 •

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

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

    웨어하우스가 무엇인지 궁금하신 분들 ◦ 데이터 웨어하우스를 구성 할 / 구성 중이신 분들 2019.10.19 데이터야 놀자
  8. 런칭 직후 2019.10.19 데이터야 놀자

  9. 약간의 배경 설명 Icon made by Chanut from www.flaticon.com 4명

    2019.10.19 데이터야 놀자
  10. 약간의 배경 설명 Icon made by Freepik from www.flaticon.com 4명

    -> 1명 2019.10.19 데이터야 놀자
  11. 약간의 배경 설명 Icon made by Freepik from www.flaticon.com 4명

    -> 1명 = 발표자 2019.10.19 데이터야 놀자
  12. 신규 서비스 • 데이터를 어떻게 조회할 지 + 조회하게 만들

    지 고민 2019.10.19 데이터야 놀자
  13. 기쁜 소식 : 서버 DB 로 Aurora MySQL 선택 •

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

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

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

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

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

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

    Chartio, Periscope Data, Holistics 등 • (오픈소스) Apache Superset, Redash 등 • 필요와 상황에 따라 적절히 선택 2019.10.19 데이터야 놀자
  20. Read Replica • 분석 Workload 분리 2019.10.19 데이터야 놀자 https://techblog.timers-inc.com/entry/2016/03/02/135607

  21. Read Replica • Console 에서 클릭 몇 번으로 Read Replica

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

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

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

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

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

    선택 런칭 직후 : 정리 2019.10.19 데이터야 놀자
  28. 과도기 2019.10.19 데이터야 놀자

  29. 데이터 웨어하우스 (Data Warehouse) 2019.10.19 데이터야 놀자 https://addepto.com/implement-data-warehouse-business-intelligence/

  30. 데이터를 한 곳으로 • 별도의 RDBMS 를 띄우고 -> Spark

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

    / Parquet / JDBC 등 다양한 데이터 소스를 거의 똑같이 생긴 API 로 Read / Write 2019.10.19 데이터야 놀자 https://databricks.com/spark/about
  32. 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 데이터야 놀자
  33. • 팀에서 예전부터 쓰고 있었음 Apache Spark http://engineering.vcnc.co.kr/ 2019.10.19 데이터야

    놀자
  34. MySQL 8 / PostgreSQL 10 • Amazon RDS ◦ 역시나

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    소스의 데이터를 한 곳으로 모으면서 -> JOIN 가능 ◦ 개선된 SQL 표현력 ◦ 서버와 별도의 데이터베이스 -> 새로운 테이블 추가가 용이 ◦ 리소스 관리가 힘듦 • 리포트 / 대시보드 작업 . . . . . . . 2019.10.19 데이터야 놀자 Icon made by Freepik from www.flaticon.com
  53. 과도기 : 아키텍처 2019.10.19 데이터야 놀자

  54. 현재 2019.10.19 데이터야 놀자

  55. RDBMS -> ? • 고려했던 친구들 ◦ Presto ◦ Amazon

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

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

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

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

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

    Presto ◦ Amazon Redshift ◦ Amazon Athena ◦ Google BigQuery 2019.10.19 데이터야 놀자
  61. 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 데이터야 놀자
  62. 인프라 관리 X • Google 이 해줌 2019.10.19 데이터야 놀자

  63. 높은 확장성 (highly-scalable) • e.g. 차량 궤적 데이터 처리 ◦

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

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

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

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

    때도 이미 Partition 단위로 처리 ◦ 본래 Spark Application 의 코드 패턴과 거의 유사 : Partition UPSERT 대신 Partition 교체 ◦ 작은 테이블 (처리 시간 10분 미만) -> 매번 전체 테이블 Overwrite ◦ 큰 테이블 -> Date Partitioned 테이블로 만들고 Partition 단위로 교체 2019.10.19 데이터야 놀자
  69. BigQuery 의 장점과 사용법에 대해 더 궁금하시다면…! https://www.slideshare.net/zzsza/bigquery-147073606 2019.10.19 데이터야

    놀자
  70. 현재 : 정리 • Google BigQuery 로 이전 ◦ 매니지드

    데이터 웨어하우스 -> 인프라 관리 비용 ZERO ◦ 높은 확장성 + 강력한 SQL 표현력 + 편리한 Console -> 더 많은 팀원들의 + 더 많은 데이터 분석 ◦ + Firebase Analytics SDK 으로 찍는 라이더 앱 / 드라이버 앱 로그는 자동으로 BigQuery 에 쌓임 • 리포트 / 대시보드 작업 . . . . . . . 2019.10.19 데이터야 놀자 Icon made by Freepik from www.flaticon.com
  71. 현재 : 아키텍처 데이터 분석가 w/ Scheduled Queries w/ Cloud

    Composer 2019.10.19 데이터야 놀자
  72. 결론 2019.10.19 데이터야 놀자

  73. SQL 로 원하는 데이터 조회 가능 • SQL 모르는 개발자

    외 팀원들은?
  74. Feat. 데이터 부트캠프 (= SQL 세션) 2019.10.19 데이터야 놀자

  75. 분석 쿼리 유저 1~2 5~10 49 런칭 직후 과도기 현재

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

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

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

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

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

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

    큰 역할 • 데이터 엔지니어 -> 좋은 데이터 웨어하우스에 대해 끊임없이 고민 + 탐색 2019.10.19 데이터야 놀자
  82. 그리고 2019.10.19 데이터야 놀자

  83. We Are Hiring • 힘들지만 재밌게 문제를 해결하고 있고, 문제

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

    SOCAR 변성윤님 (a.k.a @zzsza) 2019.10.19 데이터야 놀자
  85. 감사합니다 2019.10.19 데이터야 놀자