data platform on kubernetes

1. Data platform
on kubernetes
Jung Chang Un

2. Kubernetes as data platform
infrastructure

3. 확장성
● Data, 사용자 증가에 따른
● 확장이 빠르고, 가격이 적정하며, 원하는 성능까지 쉽게
● Data 저장에서는 재분산 issue
안정성
● HA
● Fault Tolerance
실시간
● Data river
● Monitoring, Fraud/Anomaly Detection,
bigdata/cloud 시대의 data platform

4. Kubernetes as data platform infrastructure
데이터플랫폼 구축
● 서비스 설치가 용이함
○ Helm (https://helm.sh/)
○ Yaml ( https://kubernetes.io/ko/docs/tutorials/stateful-application/zookeeper/)
● Data 서비스제공
● Pod/서비스 재시작이 편함
EKS
● AWS Managed Kubernetes
● Master관리, multi AZ, upgrade, 가격이 저렴

5. Data Processing(Scheduling, Data Mart, ODS, Realtime)
Data Analysis(Presto)
Data Platform 구축

6. 개발/운영 Concept
● Job Scheduler/Coordinator
● Airflow worker에서 직접 Data처리를 하지 않음
● Kubernetes executor를 사용하지 않지만, kubernetes operator는 사용
○ 실제로 Data Processing을 하는 task는 pod 형태로 실행됨
관련Link : https://www.slideshare.net/changunjung/data-platform-data-pipelineairflow-kubernetes
Kubernetes
● Webserver, Scheduler - Fault Tolerance
● Worker - Scalability
● Source - Git sync, EFS
Data Processing(Scheduling - Airflow)

7. Legacy
● DMS - 변경분만 가져오고 싶지만 전체데이터만 가져와야함
● Glue(python) - 설치된 library 외에 추가로 설치불가. 다양한 database 활용불
가
● Glue(spark)
○ Glue ETL의 GUI환경에서 개발.
○ Spark 으로 read하기때문에 운영db에 부하를 줌
○ Source관리 어려움
○ Data platform 적용
■ Glue ETL의 GUI에서 개발된 job을 그대로 사용하지는 않고 script를 복사해서 airflow에서
submit 하는 방식으로 실행. Airflow환경변수 활용가능
■ 원인 모를 Hang. Job timeout 변수설정으로 Hang발생시에 다시 실행될수 있도록 구성
Data Processing (ODS)

8. Kubernetes ELT Pods
● ODS 적재를 위한 container
○ Airflow operator 형태로 개발
○ K8s spark operator 를 활용해서 실행 ( https://github.com/GoogleCloudPlatform/spark-on-k8s-operator )
● Extract
○ Extract from source db
○ python script를 사용/multi-processing(using query sharding)
○ 최적화된 Query, fetch 를 통해 db부하 줄여주고, extract performance 증가
○ Extract from Mysql, SQLServer, 필요시 DB 추가가 쉽도록 sqlalchemy활용
● Load
○ Load to target storage(S3, Hive)
○ pyspark(k8s as master) 활용해서 hive table로 insert
○ Spark container
Data Processing (ODS)

9. ● Glue(spark)
○ 비쌈
○ executor/driver 자원을 받는데 처음시작할때는 10분가량 대기가 있고 이후실행은 바로 될때도
있고 다시 10분 기다려야할 때도 있음. 작업시간 예상이 어렵고 Job을 하나의 script에 넣지 않
는한 불필요한 대기시간이 많아짐 -> 개선될 가능성도 있음
○ glueContext 개선기대
○ Executor 사용하는 메모리 모니터링은 직관적임
○ EMR에 비해서 실행시간,비용,instance type지정에 이점이 없어 mart processing에는 사용하고
있지 않음
● EMR
○ EMR 시작하는데 3~5분가량 소요, AWS Dependency
○ EC2 요금 + EMR요금. Spot instance활용으로 ec2비용은 많이 줄일수 있음
○ 빠르게 hive, spark, hive-metastore(glue) 환경 구성이 가능함
○ Data platform 적용
■ airflow에서 job 단위로 EMR start/terminate 함으로써 EMR관리에 대한 resource 및 EMR
서버 안정성에 대한 이슈를 줄일수 있음
■ Livy(REST service for apache spark)
Data Processing (Data Mart)

10. ● Kubernetes ELT(Extract-Load-Transform) Pods
○ Data Processing(ODS)와 같은 container
■ pyspark 실행
■ Airflow kubernetes operator 를 통해서 실행
○ EMR 에 의존성/추가비용 없이 Data Processing
○ 필요한 library를 추가해서 custom image 개발
■ Glue-metastore 설정/관련 library설치
○ Data Mart에 대한 Processing은 DataLake내부의 Hive -> Hive 방식으로, pyspark 을 submit 하
는 방식으로, Transform 작업만
Data Processing (Data Mart)

11. Data Processing (실시간)
Log Monitoring
● Kinesis - Druid활용한 실시간 logs 모니터링
● Kinesis
○ Log수집
○ AWS managed realtime stream service
● Druid
○ Kinesis를 data source로 사용가능
○ Pivot, Superset, Tableau 등에서 실시간 Monitoring Dashboard 구성
Log data analysis(table)
● Spark-streaming 을 이용한 Log Hive테이블 제공
○ Presto, spark에서 활용가능
○ K8s spark-operator
○ spark using kinesis, insert into hive table

12. 역할
● log데이터 모니터링, 분석cube
ES와 비교
● Druid, ES 둘다 대용량 데이터에 대한 빠른 분석 및 실시간 데이터 처리
● ES는 local storage가 필요하고 druid도 cache를 위해서 local storage가 필요하지만, druid는 deep
storage 가 있어서 node의 추가, 삭제시 데이터 재구성이 용이함 (단일화된 storage 제공으로서의
DataLake구성 concept에 druid가 더 적합)
● ES에 비해서 Druid의 구성, 설치가 복잡함
○ Master/Data/Query + Zk vs node configure
● Druid가 좀더 Query 적용이 용이함
● Druid가 데이터 재적재, 변경등이 불편함(ES는 esquery를 통해서 가능하지만 druid는 별로 api를 사
용해야함)
Kubernetes사용으로 인한 장점
● Node scale 변경시 Statefulsets replica숫자 변경으로 쉽게 적용가능
● Master HA 구성, Druid, Zk 설치
Data Processing (실시간 - druid)

13. Data Analysis(Presto)
역할
● EDA
● Tableau Report
● Table Summary ETL
PrestoSQL
● fork from prestodb
● CBO
● AWS Glue metastore
● https://prestosql.io/
● Starburstdata.com : presto with k8s, Apache Ranger, Apache Sentry

14. “If you were entering Hadoop ecosystem 8-10 years ago, there was this mantra:
bring compute to your storage, tie them together; shipping data is so expensive.
That is no longer true. All modern architectures right now separate storage from
compute. Grow your data without limit, scale your compute power whenever you
need.”
Kamil Bajda-Pawlikowski, Data Council NY, Nov 7-8, 2018
● S3 as DataLake
● Presto as Compute
Data Analysis(Presto)

15. Kubernetes사용하는 장점
● EMR에서 제공하는 presto 에 비해 비용이 저렴하고 서비스 문제시에 재시작,
version upgrade 등이 용이함
● data processing 역할만 담당하고 데이터는 s3저장되어있기때문에 다른
database등과 비교했을때 데이터 동기화/DQ 관리용이
● Worker Scaling
○ Deployments replicas 조정으로 바로 적용가능
○ HPA(cpu,memory,custom metrics)/AutoScaler/Scheduled Scaling
● Multi Cluster
○ K8s Service설정으로 multi cluster, load balancing
■ https://github.com/lyft/presto-gateway
○ Sandbox 형태로 사용자group에게 Cluster 제공 가능
Data Analysis(Presto)

16. Kubernetes 기반 data platform의 이점

17. K8s 기반 data platform의 이점
Scalability
● HPA/VPA, AutoScaler
● Metrics기반, Scheduled Scaling
● Service별 구성
○ Airflow worker : worker가 부족할경우 worker pod 추가함으로써 resource 부족해결
○ Druid data server : 필요에 따라 druid data server statefulset replicas 조정
○ Presto worker
■ 필요에 따라 presto worker deployments replicas 조정
■ Presto multi cluster
안정성
● Service pods 를 statefulSet/deployments로 구성하게되면 장애시 자동으로
pod 재시작(Falut Tolerence)
○ Spot instance로 서비스 구성
● Presto multi cluster(HA)

18. K8s 기반 data platform의 이점
서비스제공
● K8s service, Ingress 구성을 통해서 data 서비스를 사용자에게 제공하기 용이
함
● Docker image, helm을 통해 jupyter, superset, redash등의 데이터조회,분석
solution에 대한 빠른 제공/삭제
Computing Node관리
● ec2를 k8s에서 관리
● Spot instance/on demand + fargate 구성
● Node group 에 대한 auto scaling group 설정
○ Auto scale 가능하지만 instance가 뜨는데 시간이 걸리기때문에 instance 사용 resource 계획에
따라서 schedule 가능