폴 스미스
1. 가정하지 마라. (당연하다는 것을 당연하다고 받아들이지 마라.)
2. 모든 것에서 영감을 찾을 수 있다.
3. 표절하지 마라. (영감과 표절은 다르다.)
4. 고민해라.
"Never assume.
Keep your eyes open.
Don't copy.
Get inspired."
원글: https://brunch.co.kr/@voiz/22
유발 하라리
• 오직 모든 것이 변한다는 사실만 유효하다. (예전보다 더 빠르게.)
• 특이점(Singularity, 과학 기술이 폭발적 성장단계로 도약해, 인간 본연의 생물학적 조건을 뛰어넘는 새로운 문명을 낳는 시점)이 온다.
• 변화에 대응하는 능력을 길러야 한다. 새로운 것을 배우고, 익숙하지 않은 상황에서도 균형을 유지하는 능력을 길러야 한다. 때론 가장 잘 아는 영역을 포기해야 하며 전혀 알지 못하는 분야를 편안하게 받아들여야 한다.
• 우리는 특정 정보를 아는 것보다 ㅡ
1) 정보가 합리적인지를 판단할 수 있는 능력
2) 무엇이 중요하고 무엇이 그렇지 않은지를 알 수 있는 능력
3) 수많은 작은 정보를 모아 세상에 대한 폭넓은 관점을 가지는 능력
이 더 중요해진다.
오늘날 우리가 익혀야 할 것은 4C.
1. Critical Thinking
2. Communiation
3. Collaboration
4. Creativity
원글: https://ppss.kr/archives/175097
2019년 9월 26일 목요일
2019년 9월 17일 화요일
JPA 코드 없이 적는 기본 개념
JPA는 Java의 객체를 table/relationship에 직접 매핑해보자는 시도에서 출발한다. 이런걸 ORM이라고 한다. JPA 이전에 ORM은 이러한 프레임워크를 나타내는데 쓰이는 일반적인 용어였다.
JPA를 쓰면 애플리케이션의 클래스를 데이터베이스의 테이블에 매핑할 수 있다. (쿼리를 작성해 날리는 방식인 JPQL도 엔티티 간 매핑을 알고있는 상태에서 수행되기 때문에 SQL과 차이가 있다.) 객체 모델을 중심으로 사고할 수 있는 것이다.
JPA는 스펙이고, JPA 스펙을 구현하기 위해선 ORM 구현체(Provider)가 필요하다. 여기서 주로 쓰이는 구현체가 바로 그 Hibernate다. (Hibernate가 JPA를 위해 만들어진 것은 아니다. 특정 부분에선 JPA가 제공하는 기능 외의 기능들을 Hibernate가 제공하기도 한다.) 그리고 Hibernate 대신에 다른 JPA 구현체를 사용할 수도 있다.
→ 서블릿과 JSP가 웹 개발을 위한 자바 스펙인 것처럼, JPA는 ORM을 위한 자바 스펙인 것이다. 이와 유사하게 톰캣, 제티가 서블릿/JSP 스펙을 구현한 서버인 것처럼 Hibernate가 JPA 스펙을 구현하고 있다.
출발은 엔티티다.
데이터베이스 테이블에 저장하고 싶은 클래스 타입에 @Entity를 붙여주면, 클래스 타입에 맞는 테이블이 데이터베이스에 생성되는 방식이다. 인자없는 기본 생성자는 습관적으로 만들어주는 것이 좋다. 마지막으로 객체마다 ID를 설정해 주어야 한다. ID에 해당하는 필드엔 @Id, @GeneratedValue 어노테이션을 붙여준다.
일반적으론 JPA 조차도 쌩으로 쓰진 않는다. Spring Data JPA 라이브러리를 통하게 되는데 Spring Data JPA는 JPA를 더 쓰기 편하게 만들어 놓은 라이브러리다. JPA의 EntityManager를 직접 다루지 않고도 Spring Data JPA의 Repository를 통해 더 쉽게 데이터를 다룰 수 있게 된다.
특별한 관계를 갖지 않는 엔티티의 CRUD는 JpaRepository<T, ID>를 상속받고 @Repository 어노테이션을 붙이는 것만으로 끝이난다. 더 할게 없다. (조금만 살펴보면 JpaRepository는 PagingAndSortingRepository를 상속받고, PagingAndSortingRepository는 다시 CrudRepository를 상속받는 것을 알 수 있다.)
관계 설정도 어노테이션 방식으로 처리된다.
@OneToMany, @ManyToOne, @ManyToMany
관계 설정의 방식, mappedBy 속성의 사용 방식에 따라 조인 테이블의 생성 유무 등 테이블이 생성되는 방식이 조금씩 바뀐다.
• 자주 쓰이는 설정값
/src/main/resources/application.properties
• 사용상 주의점
JPA가 만능은 아니다. 특정 작업에선 SQL과 비교했을 때 성능 저하가 생길 수 있다. 통계, 집계, 배치와 같은 작업은 JPA보다 SQL을 쓰는 것이 낫다고 알려져 있다.
JPA를 쓰면 애플리케이션의 클래스를 데이터베이스의 테이블에 매핑할 수 있다. (쿼리를 작성해 날리는 방식인 JPQL도 엔티티 간 매핑을 알고있는 상태에서 수행되기 때문에 SQL과 차이가 있다.) 객체 모델을 중심으로 사고할 수 있는 것이다.
JPA는 스펙이고, JPA 스펙을 구현하기 위해선 ORM 구현체(Provider)가 필요하다. 여기서 주로 쓰이는 구현체가 바로 그 Hibernate다. (Hibernate가 JPA를 위해 만들어진 것은 아니다. 특정 부분에선 JPA가 제공하는 기능 외의 기능들을 Hibernate가 제공하기도 한다.) 그리고 Hibernate 대신에 다른 JPA 구현체를 사용할 수도 있다.
→ 서블릿과 JSP가 웹 개발을 위한 자바 스펙인 것처럼, JPA는 ORM을 위한 자바 스펙인 것이다. 이와 유사하게 톰캣, 제티가 서블릿/JSP 스펙을 구현한 서버인 것처럼 Hibernate가 JPA 스펙을 구현하고 있다.
출발은 엔티티다.
데이터베이스 테이블에 저장하고 싶은 클래스 타입에 @Entity를 붙여주면, 클래스 타입에 맞는 테이블이 데이터베이스에 생성되는 방식이다. 인자없는 기본 생성자는 습관적으로 만들어주는 것이 좋다. 마지막으로 객체마다 ID를 설정해 주어야 한다. ID에 해당하는 필드엔 @Id, @GeneratedValue 어노테이션을 붙여준다.
일반적으론 JPA 조차도 쌩으로 쓰진 않는다. Spring Data JPA 라이브러리를 통하게 되는데 Spring Data JPA는 JPA를 더 쓰기 편하게 만들어 놓은 라이브러리다. JPA의 EntityManager를 직접 다루지 않고도 Spring Data JPA의 Repository를 통해 더 쉽게 데이터를 다룰 수 있게 된다.
특별한 관계를 갖지 않는 엔티티의 CRUD는 JpaRepository<T, ID>를 상속받고 @Repository 어노테이션을 붙이는 것만으로 끝이난다. 더 할게 없다. (조금만 살펴보면 JpaRepository는 PagingAndSortingRepository를 상속받고, PagingAndSortingRepository는 다시 CrudRepository를 상속받는 것을 알 수 있다.)
관계 설정도 어노테이션 방식으로 처리된다.
@OneToMany, @ManyToOne, @ManyToMany
관계 설정의 방식, mappedBy 속성의 사용 방식에 따라 조인 테이블의 생성 유무 등 테이블이 생성되는 방식이 조금씩 바뀐다.
• 자주 쓰이는 설정값
/src/main/resources/application.properties
# 세션 메트릭을 보여준다.
spring.jpa.properties.hibernate.generate_statistics=true
# 쿼리를 표시한다.
spring.jpa.show-sql=true
spring.jpa.properties.hibernate.format_sql=true• 사용상 주의점
JPA가 만능은 아니다. 특정 작업에선 SQL과 비교했을 때 성능 저하가 생길 수 있다. 통계, 집계, 배치와 같은 작업은 JPA보다 SQL을 쓰는 것이 낫다고 알려져 있다.
2019년 9월 16일 월요일
C# Event vs Delegate, 이벤트와 델리게이트 차이점.
이벤트는 델리게이트와 동일하게 +, -의 조합 연산자를 지원하고, 실제 동작도 거의 같아 보이지만 이벤트엔 컴파일러가 적용하는 몇가지 사양이 있고, 속성에 대한 두가지 접근자가 추가된다는 차이점이 있다.
디자인 상 가장 큰 차이점은 이벤트는 인터페이스 내부에 선언할 수 있지만 델리게이트는 선언할 수 없다는 점이다. 이는 프로퍼티를 인터페이스 내부에 선언할 수 있지만 필드는 선언할 수 없는 C#의 디자인과 관련이 있다. 어떤 얘기인가 하면,
코드는 다음과 같이 변환된다.
위 코드 변환의 영향으로 이벤트는 클래스 내부에서만 호출할 수 있게 된다. 반면 델리게이트는 public인 경우 클래스 외부에서도 제약없이 호출할 수 있다.
차이점이 있다 하더라도 이 둘은 거의 같다. 알다시피 EventHandler도 델리게이트다. (.Net에서 이벤트는 event 키워드만 붙이면 어떤 형식의 delegate도 허용하긴 하지만 표준은 아래의 형식을 따르는게 맞다.)
개인적인 생각으론 통지 구조를 인터페이스에 드러내거나 publish 동작을 클래스 내부에 감추는 목적으로 이벤트와 델리게이트를 구분해서 쓰면 될 것 같다.
디자인 상 가장 큰 차이점은 이벤트는 인터페이스 내부에 선언할 수 있지만 델리게이트는 선언할 수 없다는 점이다. 이는 프로퍼티를 인터페이스 내부에 선언할 수 있지만 필드는 선언할 수 없는 C#의 디자인과 관련이 있다. 어떤 얘기인가 하면,
public event EventHandler SomeEvent;코드는 다음과 같이 변환된다.
private EventHandler _SomeEvent;
public event SomeEvent {
add { _SomeEvent += new EventHandler(value); }
remove { _SomeEvent -= new EventHandler(value); }
}위 코드 변환의 영향으로 이벤트는 클래스 내부에서만 호출할 수 있게 된다. 반면 델리게이트는 public인 경우 클래스 외부에서도 제약없이 호출할 수 있다.
차이점이 있다 하더라도 이 둘은 거의 같다. 알다시피 EventHandler도 델리게이트다. (.Net에서 이벤트는 event 키워드만 붙이면 어떤 형식의 delegate도 허용하긴 하지만 표준은 아래의 형식을 따르는게 맞다.)
public delegate void EventHandler(object sender, EventArgs e);
public delegate void EventHandler<TEventArgs>(object sender, TEventArgs e);개인적인 생각으론 통지 구조를 인터페이스에 드러내거나 publish 동작을 클래스 내부에 감추는 목적으로 이벤트와 델리게이트를 구분해서 쓰면 될 것 같다.
2019년 9월 4일 수요일
2019.09.04 AWS 웨비나 세션 4 정리(?)
.. 세션 3은 잘 못들었는데 세션 2와 유사한 내용의 발표였음. RedShift 솔루션 위주로 설명이 진행됨.
■ 세션 4. Amazon의 머신러닝 솔루션: Fraud Detection & Predictive Maintenance
• AWS ML Stack
- 전세계 모든 데이터 과학자와 개발자가 손쉽게 활용할 수 있는 편리한 인공지능 & 머신러닝 환경을 제공
- AI Services + ML Services + ML Frameworks & Infrastructure.
- AWS 클라우드 환경에서 제공되는 여러 서비스와 연계해 시스템을 구축할 수 있다. 타사 솔루션 대비 비용을 효율적으로 가져갈 수 있다고 함.
• Fraud Detection using Machine Learning (SageMaker 기반 솔루션)
# 잠재적 사기 행위의 탐지 및 검토 활동을 플래그 하는 아키텍처 구축 방법
# KB 국민은행의 인공지능을 활용한 금융사기 방지 시범과제 사례.
- Lambda를 이용해 프로세싱 파이프라인을 만들 수 있고, QuickSight를 이용해 예측된 결과를 시각화할 수 있다. (Lambda가 트리거 역할.)
• Predictive Maintenance using Machine Learning
# 장비의 이상 동작, 멈춤, 고장에 관한 잠재적 징후를 탐지하고 예방 및 조치에 권장하는 작업을 제공하는 아키텍처 구축 방법
- 센싱 데이터 기반으로 설비의 예기치 않은 고장을 탐지, 예측.
- RUL(remaining useful life) 예측.
- Fraud Detection 솔루션과 마찬가지로 CloudWatch Events로, 트리거는 Lambda가..
# 'turbofan degradation dataset'이 기본으로 제공됨. 데이터 성격이 맞으면 이걸 그냥 쓰면되고 성격이 다르면 이 모델을 시작점으로 해서 customization이 가능하다.
- 현재 Apache MXNet Gluon dataset 기반으로 만들어져 있다고 하는데 MXNet Gluon이 뭔진 잘 모르겠다. 업무 절차는 SageMaker notebook instance로 모델 트레이닝을 한 뒤에 SageMaker MXNet 모델로 모델을 생성한 다음에 S3 버킷에 놓고 돌리는 방식.
후반부엔 데모까지 있었으나 전반적으로 잘 와닿진 않았다. 실제로 써봐야 알겠는데, 난이도가 좀 있어 보인다.
■ 세션 4. Amazon의 머신러닝 솔루션: Fraud Detection & Predictive Maintenance
• AWS ML Stack
- 전세계 모든 데이터 과학자와 개발자가 손쉽게 활용할 수 있는 편리한 인공지능 & 머신러닝 환경을 제공
- AI Services + ML Services + ML Frameworks & Infrastructure.
- AWS 클라우드 환경에서 제공되는 여러 서비스와 연계해 시스템을 구축할 수 있다. 타사 솔루션 대비 비용을 효율적으로 가져갈 수 있다고 함.
• Fraud Detection using Machine Learning (SageMaker 기반 솔루션)
# 잠재적 사기 행위의 탐지 및 검토 활동을 플래그 하는 아키텍처 구축 방법
# KB 국민은행의 인공지능을 활용한 금융사기 방지 시범과제 사례.
- Lambda를 이용해 프로세싱 파이프라인을 만들 수 있고, QuickSight를 이용해 예측된 결과를 시각화할 수 있다. (Lambda가 트리거 역할.)
• Predictive Maintenance using Machine Learning
# 장비의 이상 동작, 멈춤, 고장에 관한 잠재적 징후를 탐지하고 예방 및 조치에 권장하는 작업을 제공하는 아키텍처 구축 방법
- 센싱 데이터 기반으로 설비의 예기치 않은 고장을 탐지, 예측.
- RUL(remaining useful life) 예측.
- Fraud Detection 솔루션과 마찬가지로 CloudWatch Events로, 트리거는 Lambda가..
# 'turbofan degradation dataset'이 기본으로 제공됨. 데이터 성격이 맞으면 이걸 그냥 쓰면되고 성격이 다르면 이 모델을 시작점으로 해서 customization이 가능하다.
- 현재 Apache MXNet Gluon dataset 기반으로 만들어져 있다고 하는데 MXNet Gluon이 뭔진 잘 모르겠다. 업무 절차는 SageMaker notebook instance로 모델 트레이닝을 한 뒤에 SageMaker MXNet 모델로 모델을 생성한 다음에 S3 버킷에 놓고 돌리는 방식.
후반부엔 데모까지 있었으나 전반적으로 잘 와닿진 않았다. 실제로 써봐야 알겠는데, 난이도가 좀 있어 보인다.
2019년 9월 3일 화요일
2019.09.04 AWS 웨비나 세션 1, 2 정리
들을 때마다 느끼는데 AWS 소속 아키텍트 분들은 설명 참 잘하신다. 스케일 예측이 안되거나 덩치가 너무 커져버린 경우엔 매니지드 클라우드 서비스는 거의 필수적인게 되버린 것 같다. 다행스럽게도(?) 우리 회산 아직 해당 사항 음슴.
... 초반 30분 못들음.
• Amazon Athena
- 표준 SQL을 사용해 Amazon S3에 저장된 데이터를 간편하게 분석할 수 있는 대화식 쿼리 서비스. 서버리스 서비스라 관리할 인프라가 없고, 실행 쿼리에 대한 비용만 지불하면 된다.
• Amazon Kinesis
- 실시간 데이터를 Data Lake로 전달하는 역할. 슈퍼셀에선 Kinesis를 이용해 일 450억건의 게임 사용자 실시간 데이터를 수집한다. Netflix는 1000개 이상의 Kinesis 샤드를 통해 일 수십억건의 VPC Flow Logs를 분석하고 있다.
• 하이퍼 커넥트 AWS 이용 사례
- Redshift를 활용 데이터 수집 및 집계 (9시간 -> 3시간 단축)
- EMR을 이용해 데이터 전처리 (4시간 -> 18분 단축)
- Elasticsearch를 통한 실시간 분석 (다양한 시각화 구현)
• 머신 러닝 모델 구축에 대한 어려움
- 훈련 데이터 수집 및 저장
- 최적화된 기계학습 알고리즘 선택
- 데이터 훈련을 위한 인프라 설정
- 훈련 및 학습 모델 튜닝 (반복)
- 최적화한 모델 배포
- 모델 기반 서비스 확장 및 운영
-> Amazon SageMaker, 완전 관리형 ML 서비스. 생성, 훈련, 그리고 배포까지 원클릭 형태로 머신 러닝 모델을 상품에 반영할 수 있다. #국내 MATHPRESSO 사례.
• 비즈니스 의사 결정을 위한 분석 빌딩 블럭
# 수집
Kinesis: 스트리밍 데이터
Direct Connect: 데이터 센터와 연결
Snowball: 기존 저장된 벌크 데이터 로드
Database Migration Service: Oracle 등의 데이터 임포트
# 저장/처리
Glue: 데이터 카탈로그와 ETL
Amazon S3: 안전하고, 비용 효율적 스토리지
# 분석
Redshift: 데이터 웨어하우스
EMR: 비정형 데이터 처리, Apache Spark
Athena: ad-hoc, 서버리스 쿼리
QuickSight: 시각화, BI
SageMaker: 기계 학습 플랫폼
• 데이터 분석 트렌드
# Data = The world's most valuable resource
- 데이터의 양과 형식이 생각했던 것 이상으로 늘어나고 있다. 따라서 이를 받혀주는 데이터 분석 기술이 필요함.
(Hadoop, Elasticsearch, Presto, Spark, ...)
- 더 다양해진 데이터 소비자, 더 복잡해진 데이터 요구사항
(Secure, Realtime, Flexible, Scalable, ...)
- 레거시 환경의 Data silos 문제, 모든 데이터 소스를 한 번에 볼 수 있는 단일 데이터 뷰가 없다. (데이터 소스 별로 분리되어 있고, 이를 결합할 수 없는 환경.)
# Data Lake는 중앙 집중식 데이터 저장소, 다양한 스키마와 구조의 데이터를 대상으로 수집, 저장, 변환, 분석이 용이해야 한다. Single View로 접근하는 차세대 데이터 플랫폼. (Amazon S3 기반)
- Data Lake - Amazon S3 설계
Tier-1 원본 데이터
Tier-2 분석용 데이터
Tier-3 특정한 목적을 갖는 데이터 (Optional, Use Case(또는 ML, AI)에 적합한 구성, 도메인 레벨로 데이터마트 분리)
• 전통적인 방식의 분석 시스템
- 관계형 DB에 저장된 정형 데이터
- 확장이 어려운 구조, 대규모 선비용 투자
- 분석의 복잡성, 비실시간성, 새로운 기술과의 접목 한계
-> Data Lake를 통해 전통적인 DW를 확장.
다양한 유형의 정형/비정형 데이터 저장, 낮은 비용으로 저장과 분석이 가능.
• Amazon Redshift
여러 개의 컴퓨팅 노드의 병렬 실행으로 페타 바이트 급 데이터를 빠르게 분석할 수 있다고 함.
• Data Lakes로 데이터를 이동
- AWS는 다양한 선택안을 제공하고 있다. Direct Connect (전용 네트워크 연결). Snowball로 엑사 바이트 급의 데이터를 이전. 등등.
- 또한 실시간 소스(모바일, IoT 기기)로 부터 발생하는 스트리밍 데이터를 저장할 수 있는 방법도 제공. (Kinesis, ...)
- 데이터 웨어하우징, 대화형 SQL 쿼리, 빅데이터 처리, 실시간 분석, 대시보드와 시각화, 기계학습등 다양한 요구에 부합하는 서비스가 이미 AWS에 존재.
• 데이터에 대한 도전 과제
- 혼란스러운 여러 버전의 데이터
- 데이터에 대한 제한된 가시성
- 데이터를 찾기위해 낭비되는 시간
- 누락된 통찰력에 의한 의사결정 저하
-> 통합 저장 -> 시각화 분석 -> 트렌드 분석 -> 클러스터 분석 -> 예측 분석.
# 최종 목표는 예측 분석 및 머신러닝.
# 다우 존스, 에픽 게임즈 사례.
• Data Lake 구축 단계
- S3 버킷 생성
- 데이터 수집
- 데이터 프로세싱 및 카탈로그화
- 보안 및 컴플라이언스 정책 설정
- 데이터 활용 및 분석
-> AWS Lake Formation을 이용하면 Data Lake를 신속하게 구축할 수 있다고 함.
... 뒤에 10여분 못들음;
■ 세션 1. 클라우드 기반 데이터 분석 및 인공 지능을 위한 비즈니스 혁신
... 초반 30분 못들음.
• Amazon Athena
- 표준 SQL을 사용해 Amazon S3에 저장된 데이터를 간편하게 분석할 수 있는 대화식 쿼리 서비스. 서버리스 서비스라 관리할 인프라가 없고, 실행 쿼리에 대한 비용만 지불하면 된다.
• Amazon Kinesis
- 실시간 데이터를 Data Lake로 전달하는 역할. 슈퍼셀에선 Kinesis를 이용해 일 450억건의 게임 사용자 실시간 데이터를 수집한다. Netflix는 1000개 이상의 Kinesis 샤드를 통해 일 수십억건의 VPC Flow Logs를 분석하고 있다.
• 하이퍼 커넥트 AWS 이용 사례
- Redshift를 활용 데이터 수집 및 집계 (9시간 -> 3시간 단축)
- EMR을 이용해 데이터 전처리 (4시간 -> 18분 단축)
- Elasticsearch를 통한 실시간 분석 (다양한 시각화 구현)
• 머신 러닝 모델 구축에 대한 어려움
- 훈련 데이터 수집 및 저장
- 최적화된 기계학습 알고리즘 선택
- 데이터 훈련을 위한 인프라 설정
- 훈련 및 학습 모델 튜닝 (반복)
- 최적화한 모델 배포
- 모델 기반 서비스 확장 및 운영
-> Amazon SageMaker, 완전 관리형 ML 서비스. 생성, 훈련, 그리고 배포까지 원클릭 형태로 머신 러닝 모델을 상품에 반영할 수 있다. #국내 MATHPRESSO 사례.
• 비즈니스 의사 결정을 위한 분석 빌딩 블럭
# 수집
Kinesis: 스트리밍 데이터
Direct Connect: 데이터 센터와 연결
Snowball: 기존 저장된 벌크 데이터 로드
Database Migration Service: Oracle 등의 데이터 임포트
# 저장/처리
Glue: 데이터 카탈로그와 ETL
Amazon S3: 안전하고, 비용 효율적 스토리지
# 분석
Redshift: 데이터 웨어하우스
EMR: 비정형 데이터 처리, Apache Spark
Athena: ad-hoc, 서버리스 쿼리
QuickSight: 시각화, BI
SageMaker: 기계 학습 플랫폼
■ 세션 2. 글로벌 기업들의 효과적인 데이터 분석을 위한 Data Lake 구축 및 분석 사례
• 데이터 분석 트렌드
# Data = The world's most valuable resource
- 데이터의 양과 형식이 생각했던 것 이상으로 늘어나고 있다. 따라서 이를 받혀주는 데이터 분석 기술이 필요함.
(Hadoop, Elasticsearch, Presto, Spark, ...)
- 더 다양해진 데이터 소비자, 더 복잡해진 데이터 요구사항
(Secure, Realtime, Flexible, Scalable, ...)
- 레거시 환경의 Data silos 문제, 모든 데이터 소스를 한 번에 볼 수 있는 단일 데이터 뷰가 없다. (데이터 소스 별로 분리되어 있고, 이를 결합할 수 없는 환경.)
# Data Lake는 중앙 집중식 데이터 저장소, 다양한 스키마와 구조의 데이터를 대상으로 수집, 저장, 변환, 분석이 용이해야 한다. Single View로 접근하는 차세대 데이터 플랫폼. (Amazon S3 기반)
- Data Lake - Amazon S3 설계
Tier-1 원본 데이터
Tier-2 분석용 데이터
Tier-3 특정한 목적을 갖는 데이터 (Optional, Use Case(또는 ML, AI)에 적합한 구성, 도메인 레벨로 데이터마트 분리)
• 전통적인 방식의 분석 시스템
- 관계형 DB에 저장된 정형 데이터
- 확장이 어려운 구조, 대규모 선비용 투자
- 분석의 복잡성, 비실시간성, 새로운 기술과의 접목 한계
-> Data Lake를 통해 전통적인 DW를 확장.
다양한 유형의 정형/비정형 데이터 저장, 낮은 비용으로 저장과 분석이 가능.
• Amazon Redshift
여러 개의 컴퓨팅 노드의 병렬 실행으로 페타 바이트 급 데이터를 빠르게 분석할 수 있다고 함.
• Data Lakes로 데이터를 이동
- AWS는 다양한 선택안을 제공하고 있다. Direct Connect (전용 네트워크 연결). Snowball로 엑사 바이트 급의 데이터를 이전. 등등.
- 또한 실시간 소스(모바일, IoT 기기)로 부터 발생하는 스트리밍 데이터를 저장할 수 있는 방법도 제공. (Kinesis, ...)
- 데이터 웨어하우징, 대화형 SQL 쿼리, 빅데이터 처리, 실시간 분석, 대시보드와 시각화, 기계학습등 다양한 요구에 부합하는 서비스가 이미 AWS에 존재.
• 데이터에 대한 도전 과제
- 혼란스러운 여러 버전의 데이터
- 데이터에 대한 제한된 가시성
- 데이터를 찾기위해 낭비되는 시간
- 누락된 통찰력에 의한 의사결정 저하
-> 통합 저장 -> 시각화 분석 -> 트렌드 분석 -> 클러스터 분석 -> 예측 분석.
# 최종 목표는 예측 분석 및 머신러닝.
# 다우 존스, 에픽 게임즈 사례.
• Data Lake 구축 단계
- S3 버킷 생성
- 데이터 수집
- 데이터 프로세싱 및 카탈로그화
- 보안 및 컴플라이언스 정책 설정
- 데이터 활용 및 분석
-> AWS Lake Formation을 이용하면 Data Lake를 신속하게 구축할 수 있다고 함.
... 뒤에 10여분 못들음;
피드 구독하기:
글 (Atom)