Cloud dw benchmark using tpd-ds( Snowflake vs Redshift vs EMR Hive )SANG WON PARK
몇년 전부터 Data Architecture의 변화가 빠르게 진행되고 있고,
그 중 Cloud DW는 기존 Data Lake(Hadoop 기반)의 한계(성능, 비용, 운영 등)에 대한 대안으로 주목받으며,
많은 기업들이 이미 도입했거나, 도입을 검토하고 있다.
본 자료는 이러한 Cloud DW에 대해서 개념적으로 이해하고,
시장에 존재하는 다양한 Cloud DW 중에서 기업의 환경에 맞는 제품이 어떤 것인지 성능/비용 관점으로 비교했다.
- 왜기업들은 CloudDW에주목하는가?
- 시장에는어떤 제품들이 있는가?
- 우리Biz환경에서는 어떤 제품을 도입해야 하는가?
- CloudDW솔루션의 성능은?
- 기존DataLake(EMR)대비 성능은?
- 유사CloudDW(snowflake vs redshift) 대비성능은?
앞으로도 Data를 둘러싼 시장은 Cloud DW를 기반으로 ELT, Mata Mesh, Reverse ETL등 새로운 생테계가 급속하게 발전할 것이고,
이를 위한 데이터 엔지니어/데이터 아키텍트 관점의 기술적 검토와 고민이 필요할 것 같다.
https://blog.naver.com/freepsw/222654809552
데브시스터즈 데이터 레이크 구축 이야기 : Data Lake architecture case study (박주홍 데이터 분석 및 인프라 팀...Amazon Web Services Korea
데브시스터즈 데이터 레이크 구축 이야기 : Data Lake architecture case study
이 세션에서는 데브시스터즈의 Case Study를 통하여 Data Lake를 만들고 사용하는데 있어 요구 되는 사항들에 대해 공유합니다. 여러 목적에 맞는 데이터를 전달하기 위해 AWS 를 활용하여 Data Lake 를 구축하게된 계기와 실제 구축 작업을 하면서 경험하게 된 것들에 대해 말씀드리고자 합니다. 기존 인프라 구조 대비 효율성 및 비용적 측면을 소개해드리고, 빅데이터를 이용한 부서별 데이터 세분화를 진행할 때 어떠한 Architecture가 사용되었는지 소개드리고자 합니다.
Cloud dw benchmark using tpd-ds( Snowflake vs Redshift vs EMR Hive )SANG WON PARK
몇년 전부터 Data Architecture의 변화가 빠르게 진행되고 있고,
그 중 Cloud DW는 기존 Data Lake(Hadoop 기반)의 한계(성능, 비용, 운영 등)에 대한 대안으로 주목받으며,
많은 기업들이 이미 도입했거나, 도입을 검토하고 있다.
본 자료는 이러한 Cloud DW에 대해서 개념적으로 이해하고,
시장에 존재하는 다양한 Cloud DW 중에서 기업의 환경에 맞는 제품이 어떤 것인지 성능/비용 관점으로 비교했다.
- 왜기업들은 CloudDW에주목하는가?
- 시장에는어떤 제품들이 있는가?
- 우리Biz환경에서는 어떤 제품을 도입해야 하는가?
- CloudDW솔루션의 성능은?
- 기존DataLake(EMR)대비 성능은?
- 유사CloudDW(snowflake vs redshift) 대비성능은?
앞으로도 Data를 둘러싼 시장은 Cloud DW를 기반으로 ELT, Mata Mesh, Reverse ETL등 새로운 생테계가 급속하게 발전할 것이고,
이를 위한 데이터 엔지니어/데이터 아키텍트 관점의 기술적 검토와 고민이 필요할 것 같다.
https://blog.naver.com/freepsw/222654809552
데브시스터즈 데이터 레이크 구축 이야기 : Data Lake architecture case study (박주홍 데이터 분석 및 인프라 팀...Amazon Web Services Korea
데브시스터즈 데이터 레이크 구축 이야기 : Data Lake architecture case study
이 세션에서는 데브시스터즈의 Case Study를 통하여 Data Lake를 만들고 사용하는데 있어 요구 되는 사항들에 대해 공유합니다. 여러 목적에 맞는 데이터를 전달하기 위해 AWS 를 활용하여 Data Lake 를 구축하게된 계기와 실제 구축 작업을 하면서 경험하게 된 것들에 대해 말씀드리고자 합니다. 기존 인프라 구조 대비 효율성 및 비용적 측면을 소개해드리고, 빅데이터를 이용한 부서별 데이터 세분화를 진행할 때 어떠한 Architecture가 사용되었는지 소개드리고자 합니다.
DB Migration to Azure Database for PostgreSQLrockplace
Migration from Oracle to PostgreSQL using Azure DMS
-Table of contents-
1) Azure DMS Introduction
2) What are the Azure DMS restriction ?
3)Guide Quick for Azure DMS
4) Test Environment for Migration
5) Migration Progression Procedure
6) DEMO
넥슨 글로벌 플랫폼 구축 이야기 : DB Migration case study (임현수 플랫폼인프라실 Technical Manager, 넥...Amazon Web Services Korea
넥슨 글로벌 플랫폼 구축 이야기 : DB Migration case study
이 세션에서는 넥슨의 Case study를 통하여 글로벌플랫폼 구축을 위해 기존 플랫폼을 AWS로 Migration하는 과정 및 발생가능한 이슈를 공유합니다. 넥슨이 DB서버를 이전하는 과정 속에서 마주한 기술적 고민과 이슈를 통하여 AWS 활용 시 고려해야 할 부분들에 대해 소개하고 함께 이야기 나누고자 합니다.
이 강연에서는 NoSQL 데이터베이스인 DynamoDB를 활용하기 위해 개발 실무자가 알아야 할 실용적 지식을 소개해 드립니다. 테이블을 설계하고 모범사례를 도입해 최적화된 성능과 비용으로 고가용성 데이터베이스 아키텍처를 구축하는 방법에 대해 말씀드린 뒤 다양한 용도로 DynamoDB를 활용하고 계시는 한국 고객들의 사례에 대해 소개하도록 하겠습니다.
연사: 김일호, 아마존 웹서비스 솔루션즈 아키텍트
컨테이너를 활용하여 마이크로서비스를 구성할 때는 효과적으로 컨테이너 및 서비스를 관리할 수 있는 방법이 필요합니다. 본 세션에서는 유연하게 컨테이너 환경을 관리/모니터링 할 수 있는 Amazon EC2 Container Service 및 EC2 Container Registry를 소개합니다. 아울러 Amazon ECS/ECR 환경에서 효과적인 자원 및 로그 관리, 마이크로서비스 관리에 대해서 자세히 살펴봅니다.
게임 서비스를 위한 AWS상의 고성능 SQL 데이터베이스 구성 (이정훈 솔루션즈 아키텍트, AWS) :: Gaming on AWS 2018Amazon Web Services Korea
게임 서비스를 위한 AWS상의 고성능 SQL 데이터베이스 구성
게임 서비스 아키텍처에서 관계형 데이터베이스는 핵심 컴포넌트이며 또한 전체 서비스의 성능 병목 지점이 되곤 합니다. 이 세션에서는 AWS 상에서 게임 서비스를 구현할 때, 기존 물리환경에서의 DB 성능과 동일하거나 더 높은 성능을 얻을 수 있는 구성을 설명 드리며, MS SQL 구성의 성능 데모를 시연하고자 합니다.
DB Migration to Azure Database for PostgreSQLrockplace
Migration from Oracle to PostgreSQL using Azure DMS
-Table of contents-
1) Azure DMS Introduction
2) What are the Azure DMS restriction ?
3)Guide Quick for Azure DMS
4) Test Environment for Migration
5) Migration Progression Procedure
6) DEMO
넥슨 글로벌 플랫폼 구축 이야기 : DB Migration case study (임현수 플랫폼인프라실 Technical Manager, 넥...Amazon Web Services Korea
넥슨 글로벌 플랫폼 구축 이야기 : DB Migration case study
이 세션에서는 넥슨의 Case study를 통하여 글로벌플랫폼 구축을 위해 기존 플랫폼을 AWS로 Migration하는 과정 및 발생가능한 이슈를 공유합니다. 넥슨이 DB서버를 이전하는 과정 속에서 마주한 기술적 고민과 이슈를 통하여 AWS 활용 시 고려해야 할 부분들에 대해 소개하고 함께 이야기 나누고자 합니다.
이 강연에서는 NoSQL 데이터베이스인 DynamoDB를 활용하기 위해 개발 실무자가 알아야 할 실용적 지식을 소개해 드립니다. 테이블을 설계하고 모범사례를 도입해 최적화된 성능과 비용으로 고가용성 데이터베이스 아키텍처를 구축하는 방법에 대해 말씀드린 뒤 다양한 용도로 DynamoDB를 활용하고 계시는 한국 고객들의 사례에 대해 소개하도록 하겠습니다.
연사: 김일호, 아마존 웹서비스 솔루션즈 아키텍트
컨테이너를 활용하여 마이크로서비스를 구성할 때는 효과적으로 컨테이너 및 서비스를 관리할 수 있는 방법이 필요합니다. 본 세션에서는 유연하게 컨테이너 환경을 관리/모니터링 할 수 있는 Amazon EC2 Container Service 및 EC2 Container Registry를 소개합니다. 아울러 Amazon ECS/ECR 환경에서 효과적인 자원 및 로그 관리, 마이크로서비스 관리에 대해서 자세히 살펴봅니다.
게임 서비스를 위한 AWS상의 고성능 SQL 데이터베이스 구성 (이정훈 솔루션즈 아키텍트, AWS) :: Gaming on AWS 2018Amazon Web Services Korea
게임 서비스를 위한 AWS상의 고성능 SQL 데이터베이스 구성
게임 서비스 아키텍처에서 관계형 데이터베이스는 핵심 컴포넌트이며 또한 전체 서비스의 성능 병목 지점이 되곤 합니다. 이 세션에서는 AWS 상에서 게임 서비스를 구현할 때, 기존 물리환경에서의 DB 성능과 동일하거나 더 높은 성능을 얻을 수 있는 구성을 설명 드리며, MS SQL 구성의 성능 데모를 시연하고자 합니다.
서버 개발자가 바라 본 Functional Reactive Programming with RxJava - SpringCamp2015NAVER / MusicPlatform
youtube : https://youtu.be/E_Bgv9upahI
비동기 이벤트 기반의 라이브러리로만 생각 했던 RxJava가 지금 이 시대 프로그래머에게 닥쳐 올 커다란 메시지라는 사실을 알게 된 지금. 현장에서 직접 느낀 RxJava의 본질인 Function Reactive Programming(FRP)에 대해 우리가 잘 아는 Java 이야기로 풀어 보고 ReactiveX(RxJava) 개발을 위한 서버 환경에 대한 이해와 SpringFramework, Netty에서의 RxJava를 어떻게 이용 하고 개발 했는지 공유 하고자 합니다.
Just Model It 이벤트에서 사용할 Backend.AI 에 관한 소개입니다. Backend.AI의 개괄, 주요 기능 및 사용예들을 다룹니다. 또한 Backend.AI 를 이용한 End-to-end ML model 개발 시나리오도 소개합니다.
An Introduction to Backend.AI to use in Just Model It event. It covers the overview of Backend.AI, its main features and examples. It also introduces the scenario of developing end-to-end ML model using Backend.AI.
2. index
1.General Principles
2.Common Techniques
3.Scalable System Design Patterns
2
3. General Principles
"Scalability" is not equivalent to "Raw Performance"
Understand environmental workload conditions
Understand who is your priority customers
Scale out and Not scale up
Keep your code modular and simple
Don't guess the bottleneck, Measure it
Plan for growth
3
4. Common Techniques
Server Farm (real time access)
Data Partitioning
Map / Reduce (Batch Parallel Processing)
Content Delivery Network (Static Cache)
Cache Engine (Dynamic Cache)
Resources Pool
Calculate an approximate result
Filtering at the source
Asynchronous Processing
Implementation design considerations
4
5. Scalable System Design Patterns
Load Balancer
Scatter and Gather
Result Cache
Shared Space
Pipe and Filter
Map Reduce
Bulk Synchronous Parallel
Execution Orchestrator
5
6. Load Balancer
설명
디스패처가 매 요청마다 리퀘스트를 처리할 워커를 선택함
다른 정책에 기반한 요청을 처리할 수 있음
어플리케이션은 어떤 워커도 요청을 처리할 수 있도록 “stateless“가 권장됨
대부분의 대용량 웹사이트에서 사용되는 패턴
메시징에서는 Point to Point 방식에 해당
출처: http://architects.dzone.com/news/scalable-system-design 6
7. Scatter and Gather
설명
이 모델은 디스패처가 풀의 모든 워커에 요청을 multicast 함
각 워커는 로컬결과를 계산하고 디스패처로 결과를 전송함
디스패처는 클라이언트에 각 워커의 결과를 조립해서 전송함
대부분의 검색엔진에서 사용됨 (구글, 야후 등)
메시징에서는 Pub-Sub방식에 해당됨
출처: http://architects.dzone.com/news/scalable-system-design 7
8. Result Cache
설명
이 모델은 디스패처가 처음에 요청이 저장됐는지 lookup함
만약에 결과가 있는 경우에는 이전 결과를 돌려줌
캐싱 중에서는 sideline cache에 해당함
출처: http://architects.dzone.com/news/scalable-system-design 8
9. Shared Space
이 모델은 “Blackboard”로 알려짐
모든 워커는 shared space에서 정보를 모니터하고, 부분지식을 blackboard에 돌려줌
정보는 솔루션이 도착할때까지 지속적으로 풍푸해짐
이 패턴은 JavaSpace와 GigaSpace에서 사용됨
출처: http://architects.dzone.com/news/scalable-system-design 9
10. Pipe and Filter
이 모델은 "Data Flow Programming“으로 알려져 있음
모든 워커는 데이터 플로우가 흐르도록 파이프를 통해 연결되어있다.
이 패턴은 일반적인 EAI pattern이다.
출처: http://architects.dzone.com/news/scalable-system-design 10
11. Map Reduce
이 모델은 디스크 IO가 큰 병목인 경우에 사용되는 배치작업이다.
분산파일시스템에서 디스크 IO가 병렬로 실행될 수 있다.
이 패턴은 많은 구글의 내부 어플리케이션에서 사용되고, 하둡 프레임웍에서도 채택됨
출처: http://architects.dzone.com/news/scalable-system-design 11
12. Bulk Synchronous Parallel
이 모델은 모든 워커에 걸쳐 lock-step 실행에 기반을 두고 마스터에 의해 조작된다.
각 워커는 종료조건에 도달할 때까지 다음 스텝을 반복한다.
각 워커는 인풋큐로부터 데이터를 읽는다.
각 워커는 읽은 데이터로부터 로컬 프로세싱을 수행한다.
각 워커는 로컬 결과를 직접 연결된 곳에 푸시한다.
구글 Pregel graph processing model 에서 사용되었고, 아파치 하마 프로젝트에서도 사용됨
출처: http://architects.dzone.com/news/scalable-system-design 12
13. Execution Orchestrator
설명
dependency에 기반한 태스크 실행
각 태스크에서 워커를 호출함
오케스트레이터는 워커의 실행결과를 받아 다음 태스크를 실행함
이 모델은 intelligent scheduler에서 사용됨
Job Scheduler
BPM
ESB
출처: http://architects.dzone.com/news/scalable-system-design 13