AWSKRUG DS - 데이터 엔지니어가 실무에서 맞닥뜨리는 문제들
- 1. 데이터 엔지니어가 실무에서 맞닥뜨리는 문제들 크로키닷컴 강웅석
- 2. 목차 •Parquet/ORC Deep Dive •ORC Schema Evolution with AWS Glue •EMR (격하게) tuning 해보기 - Cost/Performance
- 3. 회사 소개 •지그재그 - No. 1 여성 쇼핑몰 모음앱 •2000만 다운로드 •DAU 700K+, MAU 3M+ •누적 거래액 1조 7천억 •데이터 엔지니어 절찬 채용중!
- 4. 지그재그 데이터 소개 •데이터 레이크 26TB+ •S3 •전체 등록 상품 수 50M+ •단일 테이블, JSON 19GB+ •Impression log 일 250M+ •peak시 5분에 1.7M 수집 •33 DAG, 200+ daily tasks in Airflow
- 5. Parquet/ORC •Hadoop, Spark ecosystem에서 널리 사용되는 columnar binary format
- 6. Parquet vs ORC •둘 다 널리 쓰이는 columnar format •Parquet는 2013년 Impala와 함께 발표됨 (Cloudera + Twitter) •ORC는 2013년 Hive와 함께 발표됨 (Hortonworks + Facebook) •최근 개발 동향 •Parquet는 2020-01-13에 2.8.0 발표 •ORC는 2020-04-23에 1.6.3 발표 •많은 소프트웨어, 프레임워크에서 ORC 지원 확대 중 •Spark - 2.3에서 VectorizedORCReader 추가 (Parquet보다 빠름!) •Hive - Native support •Presto •AWS - Glue, Firehose 등의 다양한 서비스에서 ORC 지원
- 7. ORC •Self-describing type-aware columnar file format for Hadoop workloads
- 8. ORC •Key features •Native rich file types: tinyint, smallint, structs, lists, maps, unions, … •Parquet는 제한적으로 지원 (e.g. tinyint는 Parquet에서 물리적으로는 32bit)
- 9. ORC •Native rich file types •간단 성능 비교: string vs struct
- 10. ORC •Native rich file types •간단 성능 비교: string vs struct => struct로 했을 때 파일 용량 8.7% 감소
- 11. ORC •Key features •Light-weight three level of indexes •File level •Stripe level •Row level
- 12. ORC •Key features •Light-weight three level of indexes •세 가지 단계의 metadata를 이용해 들어오는 질의의 predicate을 filter 할 수 있음 •column-level count, min, max, sum 등이 담겨있음 •SELECT name, age FROM users WHERE age > 30 •ORC file은 n개라고 가정 (concurrency readable) •File level: max가 30이 아닌 file은 footer만 보고 skip •Stripe level, Row level에 대해서도 동일하게 최적화 가능 •각 row를 읽을 때는 name, age column만 읽고 나머지는 discard
- 13. ORC •Light-weight three level of indexes •ORC scanning with orc-tools to describe metadata
- 14. ORC •Key features •Block-mode compression •Integer: Run-length encoding •String: Dictionary encoding •Splittable •압축 (snappy, zlib, …) 후에도 병렬 처리 가능 •JSON vs ORC (Parquet) •JSON: full plain-text를 암호화 •ORC: block (stripe) 단위로 암호화
- 15. ORC •Parquet 말고 ORC를 쓰면 좋은 점이 뭔가요? •Rich data type: 적은 용량, 빠른 처리 속도 => Athena, S3 비용 절감 •Predicate filtering with index: 더욱 빠른 처리 속도 •활발한 개발 및 유지보수 •신규 feature 지원 활발: zstd compression codec (from FB) •https://jira.apache.org/jira/browse/ORC-363 •Parquet는 아직 개발 중: https://jira.apache.org/jira/browse/PARQUET-1124
- 16. ORC •Parquet vs ORC benchmark •Hortonworks 사내 데이터로 실험 (Hortonworks, 2016 @ Hadoop Summit) •55 columns with null value (timestamp, string, double, boolean, list, struct, …) •25M rows
- 17. ORC •Parquet vs ORC benchmark •지그재그에 등록된 상품 데이터로 실험 •50M rows, JSON 19GB •int, timestamp, string, list, tinyint 등 다양한 column type 존재 •(1) 데이터 생성 •ORC/zlib: 1.9GB, 1m 30s (JSON 대비 압축률 90%) •Parquet/snappy: 3.6GB, 1m 30s (JSON 대비 압축률 81%) •데이터 크기는 Parquet가 90% 가량 큼
- 18. ORC •Parquet vs ORC benchmark •지그재그에 등록된 상품 데이터로 실험 •50M rows, JSON 19GB •int, timestamp, string, list, tinyint 등 다양한 column type 존재 •(2) integer, list 2개 column에 대해 10M rows projection w/ Athena •ORC/zlib: 38.05s, 550.7MB scanned •Parquet/snappy: 35.21s, 1.36GB scanned •속도는 Parquet가 8% 빠르지만, 데이터는 147% 많이 읽음
- 19. ORC •약간의 단점 •Parquet보다 유명하진 않기 때문에 AWS feature 지원이 조금 느림 •EMR: EMRFS S3 committer는 Parquet만 지원 •Aurora: Parquet export만 지원 •그래도 점점 ORC 지원을 늘리고 있어서 앞으로가 기대됨!
- 20. ORC in ZIGZAG •전체 데이터 레이크는 ORC로 이루어져 있음 •S3 용량 26TB+ (w/ ORC/zlib) •S3 용량 50TB (w/ Parquet/snappy) •S3 용량 260TB (w/ JSON) •기존 JSON, CSV, Parquet 파일을 거의 대부분 ORC로 conversion •Spark, Athena (+ Glue) 로 읽어서 사용 •tinyint, smallint, struct 등 rich type 사용을 통해 효율 증대 (+ Glue) •빈번하게 읽히는 column은 bloom filter column에 등록해서 filter를 빠르게 할 수도 있음
- 21. Schema evolution •개발팀: table schema가 바뀌었어요! log schema가 바뀌었어요! 😃 •데이터팀: … 😇
- 22. Schema evolution •Parquet/ORC는 self-describing format 이지만… •해당 정보는 파일 내에 있기 때문에 schema를 알기 위해서는 모든 file을 읽어야 함 •file을 열어보기 전까진 schema를 알기 어려움 (관리도 어려움) •External metadata store에서 schema를 주입하면 어떨까? •관리도 쉽고, file을 읽을 필요도 없다! •대표적인 External metadata store 두 개: •Hive •Glue
- 23. Schema evolution
- 24. Schema evolution •하지만 source의 schema가 바뀌면 어떻게 될까? •기본적으로 Hive나 Glue 같은 metastore 에서는 schema enforcement를 적용하고 있음 •Schema validation on write •데이터를 write 할 때 metastore의 schema와 다르면 실패 처리 •변경된 schema에 따라 schema가 업데이트 되어야 한다 •Evolution
- 25. Schema evolution •Q: self-describing format은 file 내에 schema가 있는데, evolution을 하려면 전체 파일을 다시 읽고 다시 써야하는 것 아닌가요? •A: 경우에 따라 다르다! •다음 경우에 대해서는 전체 file evolution 없이 metastore update 만으로 해결 가능 •Append column •Upcast (byte -> short -> integer) •다음 경우에는 전체 file evolution 필요 •Schema의 끝이 아닌 곳에서 column insert/delete •Change data type
- 26. Schema evolution •Glue + ORC를 이용한 schema evolution 과정
- 27. Schema evolution •Glue + ORC를 이용한 schema evolution 과정 1. Source의 schema change 감지 (보통은 error 발생) 2. Glue의 해당 table로 들어가서 직접 schema evolution 수행 1. Edit schema -> Add column
- 28. Schema evolution •Glue + ORC를 이용한 schema evolution 과정 1. Source의 schema change 감지 (보통은 error 발생) 2. Glue의 해당 table로 들어가서 직접 schema evolution 수행 1. Edit schema -> Add column 2. Edit table -> Table properties에서 직접 JSON 수정
- 29. Schema evolution •Glue + ORC를 이용한 schema evolution 과정 1. Source의 schema change 감지 (보통은 error 발생) 2. Glue의 해당 table로 들어가서 직접 schema evolution 수행 1. Edit schema -> Add column 2. Edit table -> Table properties에서 직접 JSON 수정 3. EMRFS consistent view를 사용한다면, 바뀐 table에 대해 emrfs sync 필요 •Evolution 시점에 이미 띄워져있는 cluster는 데이터를 제대로 write 할 수 없음 •시점 이후에 띄운 EMR은 괜찮음
- 30. Schema evolution •매번 수동으로 하기 귀찮다면, •Spark + Glue API를 통해 자동으로 구현 가능
- 31. Schema evolution •매번 수동으로 하기 귀찮다면, •Spark + Glue API를 통해 자동으로 구현 가능 •주의할 사항 •Glue SDK가 썩 친절하진 않음 •테이블이 큰 경우, schema part가 여러 개로 쪼개지는데 마지막 part를 수동으로 찾아줘야 함
- 32. EMR Tuning •적절한 architecture + 적절한 file format + 적절한 schema store •데이터를 잘 가지고 놀면 된다! •어떻게 하면 대용량 데이터를 제일 잘 가지고 놀 수 있을까? •복잡하게 놀고 싶을 때: S3 + EMR + Spark + Glue •Ad-hoc으로 놀고 싶을 때: S3 + Athena + Glue
- 33. EMR Tuning
- 34. EMR Tuning •(1) 최신 버전의 EMR 사용하기 •Spark의 속도에는 생각보다 다양한 component들이 영향을 미침 •Hadoop, Hive •Spark <-> S3 connector 구현같은 것이 들어있음 •https://jira.apache.org/jira/browse/HIVE-16295 •https://jira.apache.org/jira/browse/HADOOP-13786 •Zeppelin, Jupyter •Scala, Java
- 35. EMR Tuning •(1) 최신 버전의 EMR 사용하기 •2020년 4월에 나온 EMR 6.0.0은 다양한 major upgrade를 포함 •Hadoop, Hive -> 3.x •S3OutputCommitter 등에 zero-rename 기능이 추가되어 속도가 월등히 향상 •Scala -> 2.12 •change가 많은 만큼 한 번 놓치면 따라가기가 쉽지 않으므로, 주기적으로 업데이트 권장
- 36. EMR Tuning •(2) spark-defaults.conf tuning •Spark에서 성능에 영향을 미치는 중요한 요소들 •Executor •Executor 개수, Executor마다 할당된 자원 (CPU core, memory) •Partition •Executor가 아무리 많아도 partition 개수가 부족하면 executor가 놀 수 있음 •반대로, partition 개수가 너무 많아도 executor가 제 역할을 하지 못함
- 37. EMR Tuning •(2) spark-defaults.conf tuning •Executor 설정 •지그재그에서는 4xlarge instance 사용 •16 core, 128GB mem로 executor 3개 사용 •1 executor - 5 core, 32GB mem •128GB 중 약 5GB 정도는 OS나 YARN 등이 점유 (overhead)
- 38. EMR Tuning •(2) spark-defaults.conf tuning •Executor 설정 •지그재그에서는 4xlarge instance 사용 •16 core, 128GB mem로 executor 3개 사용 •1 executor - 5 core, 32GB mem •128GB 중 약 5GB 정도는 OS나 YARN 등이 점유 (overhead) •32GB 이상으로 할당하는 경우에는 compressed oops가 disable 되어 오히려 성능 손해를 볼 수 있음 (아예 더 많이 할당하는 것이 좋음) •남는 1 core는 Hadoop daemon이 사용 •5 core는 2015년부터 내려져오는 magic number •too many - context switching 때문에 성능 저하 •few - 하나의 JVM을 공유하는 의미가 떨어짐 •data broadcast 시 같은 executor 안에 있으면 바로 접근 가능
- 39. EMR Tuning •(2) spark-defaults.conf tuning •Executor 설정
- 40. EMR Tuning •(2) spark-defaults.conf tuning •각종 자잘한 tips •partition 개수: 기본값은 200이고, 코드에서 repartition이나 coalesce로 설정 가능 •JVM GC: G1GC 사용 추천 •Java 9부턴 G1이 기본이고, 11에는 ZGC가 있지만, Spark는 아직 Java 8 •Spark 3.0에선 11+을 지원한다는 얘기가 있음 •https://issues.apache.org/jira/browse/SPARK-24417 •각종 compress option: 사용 추천 •Serializer: Kyro serializer 추천 •이미 몇몇 군데에는 들어가 있지만, 아직 기본값은 아님
- 41. EMR Tuning •(2) spark-defaults.conf tuning
- 42. EMR Tuning •(3) 기타 config tuning •YARN (yarn-site) •큰 클러스터를 사용한다면 Fair scheduler 적용 추천 (기본은 FIFO) •DominantResourceCalculator •YARN이 container에 자원을 할당할 때 사용하는 calculator •기본은 Default로, Dominant가 좀 더 진화된 버전 •Hive (hive-site) •Hive에도 각종 config가 있는데 Spark에 적용되는 지 확인 필요 •Zeppelin, Jupyter •Heap mem을 늘리고 G1GC 적용 추천
- 43. EMR Tuning •비용 절감 - Spot instance •최대 80% 이상 싸게 쓸 수 있음 •다만, spot으로 사용하는 만큼 resource preemption 위험이 있음 •instance를 뺏기면 cluster 사망
- 44. EMR Tuning •비용 절감 - Spot instance •뺏기지 않고 잘 사용하는 법 •Bidding price •Spot fleet •Multi AZ •Spot block
- 45. 지그재그는 데이터 엔지니어 채용 중! •발표자의 역량과 관계 없이 내용이 흥미로우셨다면… •제게 말씀 부탁드립니다! 👀
- 46. 책 후원 - 딥러닝을 위한 수학 •Q&A에 질문해주시는 분께 드립니다! •책은 4권 있습니다! •https://wikibook.co.kr/mathdl/
- 47. THANK YOU!