AWSKRUG DS - 데이터 엔지니어가 실무에서 맞닥뜨리는 문제들

데이터 엔지니어가 실무에서
맞닥뜨리는 문제들
크로키닷컴
강웅석

목차
•Parquet/ORC Deep Dive
•ORC Schema Evolution with AWS Glue
•EMR (격하게) tuning 해보기 - Cost/Performance

회사 소개
•지그재그 - No. 1 여성 쇼핑몰 모음앱
•2000만 다운로드
•DAU 700K+, MAU 3M+
•누적 거래액 1조 7천억
•데이터 엔지니어 절찬 채용중!

지그재그 데이터 소개
•데이터 레이크 26TB+
•S3
•전체 등록 상품 수 50M+
•단일 테이블, JSON 19GB+
•Impression log 일 250M+
•peak시 5분에 1.7M 수집
•33 DAG, 200+ daily tasks in Airflow

Parquet/ORC
•Hadoop, Spark ecosystem에서 널리 사용되는 columnar binary format

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 지원

ORC
•Self-describing type-aware columnar file format for Hadoop workloads

ORC
•Key features
•Native rich file types: tinyint, smallint, structs, lists, maps, unions, …
•Parquet는 제한적으로 지원 (e.g. tinyint는 Parquet에서 물리적으로는 32bit)

ORC
•Native rich file types
•간단 성능 비교: string vs struct

ORC
•Native rich file types
•간단 성능 비교: string vs struct => struct로 했을 때 파일 용량 8.7% 감소

ORC
•Key features
•Light-weight three level of indexes
•File level
•Stripe level
•Row level

ORC
•Key features
•세 가지 단계의 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

ORC
•ORC scanning with orc-tools to describe metadata

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) 단위로 암호화

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

ORC
•Parquet vs ORC benchmark
•Hortonworks 사내 데이터로 실험 (Hortonworks, 2016 @ Hadoop Summit)
•55 columns with null value (timestamp, string, double, boolean, list, struct, …)
•25M rows

ORC
•지그재그에 등록된 상품 데이터로 실험
•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% 가량 큼

ORC
•지그재그에 등록된 상품 데이터로 실험
•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% 많이 읽음

ORC
•약간의 단점
•Parquet보다 유명하진 않기 때문에 AWS feature 지원이 조금 느림
•EMR: EMRFS S3 committer는 Parquet만 지원
•Aurora: Parquet export만 지원
•그래도 점점 ORC 지원을 늘리고 있어서 앞으로가 기대됨!

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를 빠르게 할 수도 있음

Schema evolution
•개발팀: table schema가 바뀌었어요! log schema가 바뀌었어요! 😃
•데이터팀: … 😇

Schema evolution
•Parquet/ORC는 self-describing format 이지만…
•해당 정보는 파일 내에 있기 때문에 schema를 알기 위해서는 모든 file을 읽어야 함
•file을 열어보기 전까진 schema를 알기 어려움 (관리도 어려움)
•External metadata store에서 schema를 주입하면 어떨까?
•관리도 쉽고, file을 읽을 필요도 없다!
•대표적인 External metadata store 두 개:
•Hive
•Glue

Schema evolution
•하지만 source의 schema가 바뀌면 어떻게 될까?
•기본적으로 Hive나 Glue 같은 metastore 에서는 schema enforcement를 적용하고 있음
•Schema validation on write
•데이터를 write 할 때 metastore의 schema와 다르면 실패 처리
•변경된 schema에 따라 schema가 업데이트 되어야 한다
•Evolution

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

Schema evolution
•Glue + ORC를 이용한 schema evolution 과정

Schema evolution
1. Source의 schema change 감지 (보통은 error 발생)
2. Glue의 해당 table로 들어가서 직접 schema evolution 수행
1. Edit schema -> Add column

Schema evolution
2. Edit table -> Table properties에서 직접 JSON 수정

Schema evolution
2. Edit table -> Table properties에서 직접 JSON 수정
3. EMRFS consistent view를 사용한다면, 바뀐 table에 대해 emrfs sync 필요
•Evolution 시점에 이미 띄워져있는 cluster는 데이터를 제대로 write 할 수 없음
•시점 이후에 띄운 EMR은 괜찮음

Schema evolution
•매번 수동으로 하기 귀찮다면,
•Spark + Glue API를 통해 자동으로 구현 가능

Schema evolution
•매번 수동으로 하기 귀찮다면,
•Spark + Glue API를 통해 자동으로 구현 가능
•주의할 사항
•Glue SDK가 썩 친절하진 않음
•테이블이 큰 경우, schema part가 여러 개로 쪼개지는데 마지막 part를 수동으로 찾아줘야
함

EMR Tuning
•적절한 architecture + 적절한 file format + 적절한 schema store
•데이터를 잘 가지고 놀면 된다!
•어떻게 하면 대용량 데이터를 제일 잘 가지고 놀 수 있을까?
•복잡하게 놀고 싶을 때: S3 + EMR + Spark + Glue
•Ad-hoc으로 놀고 싶을 때: S3 + Athena + Glue

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

EMR Tuning
•(1) 최신 버전의 EMR 사용하기
•2020년 4월에 나온 EMR 6.0.0은 다양한 major upgrade를 포함
•Hadoop, Hive -> 3.x
•S3OutputCommitter 등에 zero-rename 기능이 추가되어 속도가 월등히 향상
•Scala -> 2.12
•change가 많은 만큼 한 번 놓치면 따라가기가 쉽지 않으므로, 주기적으로 업데이트 권장

EMR Tuning
•(2) spark-defaults.conf tuning
•Spark에서 성능에 영향을 미치는 중요한 요소들
•Executor
•Executor 개수, Executor마다 할당된 자원 (CPU core, memory)
•Partition
•Executor가 아무리 많아도 partition 개수가 부족하면 executor가 놀 수 있음
•반대로, partition 개수가 너무 많아도 executor가 제 역할을 하지 못함

EMR Tuning
•Executor 설정
•지그재그에서는 4xlarge instance 사용
•16 core, 128GB mem로 executor 3개 사용
•1 executor - 5 core, 32GB mem
•128GB 중 약 5GB 정도는 OS나 YARN 등이 점유 (overhead)

EMR 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 안에 있으면 바로 접근 가능

EMR Tuning
•Executor 설정

EMR 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 추천
•이미 몇몇 군데에는 들어가 있지만, 아직 기본값은 아님

EMR Tuning

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 적용 추천

EMR Tuning
•비용 절감 - Spot instance
•최대 80% 이상 싸게 쓸 수 있음
•다만, spot으로 사용하는 만큼 resource preemption 위험이 있음
•instance를 뺏기면 cluster 사망

EMR Tuning
•비용 절감 - Spot instance
•뺏기지 않고 잘 사용하는 법
•Bidding price
•Spot fleet
•Multi AZ
•Spot block

지그재그는 데이터 엔지니어 채용 중!
•발표자의 역량과 관계 없이 내용이 흥미로우셨다면…
•제게 말씀 부탁드립니다! 👀

책 후원 - 딥러닝을 위한 수학
•Q&A에 질문해주시는 분께 드립니다!
•책은 4권 있습니다!
•https://wikibook.co.kr/mathdl/

AWSKRUG DS - 데이터 엔지니어가 실무에서 맞닥뜨리는 문제들

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à AWSKRUG DS - 데이터 엔지니어가 실무에서 맞닥뜨리는 문제들

Similaire à AWSKRUG DS - 데이터 엔지니어가 실무에서 맞닥뜨리는 문제들 (20)

Dernier

Dernier (8)

AWSKRUG DS - 데이터 엔지니어가 실무에서 맞닥뜨리는 문제들