글쓰는 감자

( 참고: https://www.youtube.com/watch?v=I7zcRxHbo98 )

DynamoDB concept 정리

• (Primary key = Partition key + Sort key), 해당 PK로만 쿼리 가능!!
• 제약 조건
  • Scaling
    • 처리량(throughput):
      • RCU: 4KB per second / WCU: 1KB per second (독립적)
      • Eventually Consistent는 Strongly Consistent 보다 RCU를 절반만 사용: 8KB per second
    • 사이즈(size): 
      • Item 최대 크기는 400KB(모두 사용하는 건 비권장)
      • 하나의 item에서 한글자만 바뀌어도 전체 item 다시 씀 → item 한 개의 크기를 작게, 여러개의 item으로 넣자!
    • 파티셔닝(partitioning):
      • 각 파티션은 1000 WCU/sec, 3000 RCU/sec (둘 중 하나가 초과되면 파티션 늘어남)
        • 테이블에 10만 RCU 설정 시 파티션의 구조가 100개로 늘어남
      • 데이터 용량이 10GB 초과 시 파티션 늘어남

DynamoDB에서 데이터 읽는 방법 (REST API)

• GetItem
  • Partition key의 정확한 값 지정
  • 정확히 0 또는 1개의 아이템을 반환
  • 아이템 크기에 따라 RCU 사용
• Query
  • Partition key의 정확한 값 지정
  • 선택적으로 non-key 어트리뷰트에 필터링 조건 추가
  • 일치하는 아이템 반환(여러 개 가능)
  • Key 조건과 일치하는 아이템의 크기에 따라 RCU를 소비하여 단일 결과 반환
• Scan
  • 키가 아닌 어트리뷰트에 대한 필터 조건 지정(필터 표현식과 일치하는 모든 아이템 반환)
  • 1MB 단위로 스캔 가능(리턴 메시지의 토큰 값으로 다음 1MB API 호출 반복)
  • OLTP(On-Line Transaction Processing) 환경에선 사용 못함
    • OLTP: 여러 과정의 연산이 하나의 트랜잭션으로 실행하는 프로세스(정규화 쪽..)
  • On-Line 마이그레이션 때 고민하게 될거다
    • 하나씩 다 옮겨버리면 되는거니까... (단순 작업)
• 대표적인 API 제약 조건
  • Query & Scan: 단일 호출로 최대 1MB 반환, 응답 메시지가 1MB 이상이면 LastEvaluatedKey을 이용해 pagination 가능
  • BatchGetItem: 단일 호출로 최대 100개 아이템 혹은 최대 16MB 반환
    • (API 서버와 DynamoDB 사이에 RoundTrip Time을 줄여 한번에 GetItem을 묶어 실행)
  • BatchWriteItem: 단일 호출로 최대 25 PutItem 혹은 DeleteItem 수행하며 최대 16MB 쓰기

LSI vs GSI

DynamoDB 키 디자인 패턴

Tenet

• 애플리케이션의 usecase가 DynamoDB와 맞는지
  • DynamoDB는 무한대에 가까운 item들 중에서 하나 또는 몇 개의 item을 primary key로 빠르게 찾는걸 잘함
  • 대량의 range 쿼리, fullstacks search, 집계 쿼리 못함
• 테이블 안에 파티션의 개수가 많을수록 애플리케이션의 데이터 액세스가 여러 개의 파티션에서 일어날 확률이 높아짐
  • Hot Partition의 확률이 낮아짐
  • size가 작은 여러 개의 테이블 보단, 하나의 큰 테이블이 장점이 더 많음!
• OLTP여야하고 OLAP의 분석이 필요할 경우 DynamoDB web으로 분석 파이프라인 생성해 워크로드 수행 

디자인 패턴 및 비정규화

• 비정규화
  
  •  " DynamoDB는 무한하게 많은 아이템 중에 하나 혹은 몇 개를 일정한 시간 안에 찾아낸다"
• RDBMS의 경우 데이터 모델 정규화에 대한 노력을 하는데 DynamoDB는 모든 데이터 액세스 패턴을 알고 시작한다.
  
  • RDBMS: 데이터 중복을 최소화하여 정규화된 테이블 간의 조인을 이용해 Ad-hoc하게 런타임의 디스크에서 데이터를 읽어 CPU 연산을 이용해 조인을 수행(과거엔 디스크가 더 비싸... 디스크에 최소의 데이터를 저장하고 런타임의 cpu 리소스를 많이 사용하게끔..)
  • NoSQL: 디스크 가격이 싸져 상황이 역전됨. 조인과 같은 복잡한 연산 불가(결과 셋 형태로 입력이 필요하다...?)

• 간단한 PK 유일 키: 사용자 프로파일, 세션 스토어, 상품 정보

• PK + SK 복합키: 
  • SK(Sort key):
    • 많이 사용되는 값: 알파벳, 숫자, 타임스탬프, ULID/KSUID
    • 오름차순, 내림차순 조회 가능
  • 예제: IoT 로그, 소셜 네트워크의 포스트 리스트, 주문 상세정보 혹은 이력 등

• 노래의 상세 정보만 조회 가능
• begins_with 연산자를 통해 Did로 시작하는 다운로드 이력만 조회 가능
• 쿼리 API를 이용해 PK id 1에 모든 아이템을 한번에 조회 가능

Key 디자인 시 지속적으로 생각할 포인트: 내가 보여줄 UI에 있는 데이터를 그대로 저장하는 것

싱글 테이블 디자인

• 모든 엔티티를 하나의 테이블로 설계하는 방법
• 장점: 적은 운영 부담, 높은 테이블 최대 성능 및 쓰로틀링 줄어들 수 있음
• 단점: 높은 러닝 커브, 시계열이나 다른 액세스 패턴의 엔티티에는 적합하지 않음
• 안티 패턴
  • PK를 UserID로 고정하고 시작하는 습관
    • 일반 사용자와 VIP를 같은 키 디자인으로 해결하려는 습관
    • 대량 트래픽을 유발하는 heavy user를 항상 고민해야함
  • 엔티티 별로 테이블을 만들려는 습관
  • GSI를 많이 사용하려는 습관
• 예시: 이커머스 애플리케이션 디자인
  • 키 디자인 full-cycle
    • 비즈니스 유즈 케이스 이해 → ER 다이어그램 그리기 → 모든 데이터 액세스 패턴 정리 → 키 디자인 시작
  • 비즈니스 유즈 케이스(엔티티 설정)
    • 고객(customer)은 온라인 샵에 방문하고 여러개의 온라인 상품을 둘러보다 여러개의 상품(products) 주문(order)
    • 주문과 연결된 인보이스(invoice)를 기반해 여러 결제수단을 결합해 지불(해당 영상에선 결제 관련 엔티티 다루지 않음)
    • 구매된 상품들은 하나 혹은 여러 곳의 물류 창고(warehouses)에서 픽업되어 고객의 주소로 배송됨(shipped)
  • ERD 그리기(엔티티 연결 관계)
    •  고객(customer)은 여러개 주문(order) 가능 / 주문(order)은 하나의 (invoice) / 주문(order) 안에 여러개의 상품(product) / 상품(product)은 여러개의 주문(order)에 속함
  • 모든 액세스 패턴 정리
    • 어떤 값으로 어떤 데이터를 조회하겠다. 
    • 실제 워크로드의 경우 읽기/쓰기 모두 정리되어야 함
  • 키 디자인 시작하기
    • NoSQL Workbench 다운로드
  • 참고: https://github.com/aws-samples/amazon-dynamodb-design-patterns/tree/master/examples/an-online-shop

❗ 솔직히 겁네 어렵네...?! ❗

(출처:  https://www.youtube.com/watch?v=U_GJYMUjiwA&t=2s )

DynamoDB

• Key-Value 형식의 NoSQL
• 다수의 서비스들과 컴퓨팅이 결합된 분산 시스템 구조
• 3 AZ - 3 copy / 수백만의 요청에 한자리 ms 지연시간(모든 규모에서 10ms 미만)
• Data types: String, Number, Binary, Bool, Null, List, Set of String/Number, Map

동작 방식

• Item: 테이블에 저장되는 레코드
• 각 Item들은 RDBMS에서 Column 이라 부르는 Attributes로 구성
• 하나의 테이블은 Partition Key를 기준으로 분산됨
  • Partition Key 필수(사용자 ID와 같은 unique한 데이터)
  • 결국 Partition Key는 물리적인 공간인 파티션을 특정하는 키
• Partition Key + Sort Key = PK(Primary Key)
  • PK는 유일 조건을 만족해야 함
  • Sort Key: 파티션 내에서 정렬하는 기준 값
• DynamoDB Secondary Index:
  • LSI(Local Secondary Indexes): 원본 테이블과 파티션 키를 같이 가져감 → 테이블에 속한 인덱스
  • GSI(Global Secondary Indexes):  원본 테이블로부터 복사본을 갖는 별도의 테이블(원본 테이블과 다른 파티션 키를 생성 가능) → Item을 조회하기 위한 또 다른 (PK + SK)를 추가할 수 있음!!
• DynamoDB의 성능: RCU / WCU

SQL / NoSQL

• RDBMS와 다르게 정규화 과정이 없으며 액세스 패턴에 따라 Item의 Attribute들이 달라질 수 있음
• 기존에 테이블들로 분리했던 데이터들은 Document 형식으로 데이터 처리 가능

 DynamoDB 테이블

• partition key에 의해 분산되며 같은 노드에서 sort key로 정렬됨
• 각 Item의 Attribute들은 schemaless 방식으로 순서 및 개수에 상관 없이 저장 가능

Partitioning

• OrderId가 Partition Key, 해당 OrderId는 해시함수에 의해 물리적으로 Partition된 노드로 전환
  • 요청 받은 파티션 키를 파라미터로 Hash Value를 도출하여 파티션이 결정되기 때문에 테이블이 아무리 커져도 Hash Value를 도출해 빠른 속도로 해당 데이터에 접근하기 때문에 일관된 응답 시간을 제공할 수 있음!!
  • Partition Key 연산은 "Equal" 만 가능!!
• 설정된 용량은 각 노드에 균등하게 배분되어 리소스로 사용됨
  • 1 Partition 의 크기 = 10GB / 1 Item = Max 400 KB / 1 Partition에는 25000개의 Item이 들어감
  • 1 Partition의 최고 RCU = 3000 / 최고 WCU = 1000

• Sort Key는 동일 파티션 키에 대해서 정렬 기준으로 사용 됨
  
  • 연산: 선택, 범위 연산 가능(>, >=, <, <=, begin_withs, between)
• Customer#가 같은 애들은 같은 파티션에 저장되며 Order#에 대해 정렬됨

LSI(Local secondary index)

• Table과 같은 파티션 키를 가지고 sort key를 별도로 구성이 가능하다
• 용량은 10GB(테이블당 5개)
• Projection: 인덱스에 어떤 Attribute를 추가할지 결정하는 것
  • KEYS_ONLY / INCLUDE / ALL
• 최대한 안쓰는 걸 추천!
  • LSI는 파티션 키를 테이블의 파티션 키와 동일하게 설정해야하기 떄문에 두 파티션 키가 같은 데이터를 바라보고 연산한다는 점에서 별루.. 또, 테이블 생성 시에만 생성 가능하고, 삭제 불가능

GSI(Global secondary index)

• Table과 다른 파티션 키를 가질 수 있음 → Item을 조회하기 위한 또다른 (PK + SK) 추가
• 원본 Table로 부터 새로운 테이블을 만드는 방식(원본 테이블 변경되면 GSI의 테이블도 동기화 되는 구조)
• 별도의 저장공간 필요(용량 제한 없음)하기 때문에 RCUs/WCUs 설정해야함
  • 원본 Table의 저장 성능을 보장하기 위해 같은 Capacity설정 권장
• 중요한게... Eventual Consistent Read / Strong Consistent Read 가 있는데 GSI는 Strong Consistent Read 불가!!
  • Eventual Consistent Read: 응답 속도는 빠르지만 최근 완료된 쓰기 작업 결과가 반영되지 않아 최종적인 데이터를 가져오지 않음(3 AZ에서 젤 빠른거 가져옴)
  • Strong Consistent Read: 응답 속도는 느리지만 최근 완료된 쓰기 작업 결과가 반영됨(3 AZ 변경 다 하고 나서 가져옴, GSI 사용 불가)

Burst capacity

• Partition당 사용되지 않는 용량을 최대 5분동안 저장
• 설정된 용량 이상의 요청이 들어올 경우 저장된 용량을 사용할 수 있음

• Partition 1,2,3에 미사용 용량이 Partition 4로 넘어가 초과되는 용량을 커버쳐줌
• 커버를 치지 못할 경우 Throttling 발생 → "Hot Partition"
  • 500 Error 리턴 후 write 요청 실패
  • 특정 파티션에 지속적으로 예기치 않은 요청이 오는 것을 막을 수 있도록 파티션 키의 변경이 필요함
  • 만약 워크로드가 예상된다면, provisioned 모드에서 on-demand 모드로 변경

테이블 설계 예시

• ProductID 2에 대해 type을 보면, albumID의 track에 대해 Attributes가 존재하도록 구성 가능

• 하나의 ProductID에 대해서 Attribute에 document 형식으로 데이터 관리 가능

❗ 아래의 링크는 DynamoDB 데이터 설계할 때 도움이 많이 될만한 블로그 이다.. ❗

https://zuminternet.github.io/DynamoDB/ 

AppStream 2.0

• AWS의 EUC(End User Computing) 서비스
• 유저가 어디서나 데스크톱 애플리케이션에 즉시 액세스할 수 있는 완전관리형 애플리케이션 스트리밍 서비스
•  concept
  • application: 유저에게 스트피밍하려는 애플리케이션을 시작하는데 필요한 정보가 포함됨(app block, image 등 시작하는데 필요한 파일이 포함된 리소스)
  • app block: 유저에게 스트리밍하려는 애플리케이션 파일과 이를 구성하는데 필요한 세부 정보
  • image builder: 이미지를 생성하는데 사용하는 가상 머신
  • image: 유저가 스트리밍할 수 있는 애플리케이션과 빠르게 시작할 수 있도록 하는 기본 시스템 및 애플리케이션 설정 포함(이미지를 만든 후 변경 불가)
  • fleet: 지정한 이미지를 실행하는 스트리밍 인스턴스를 묶은 집합(유저 1명당 1대의 인스턴스 필요)
  • stack: 스택을 통해 플릿과 사용자를 연결해주고 플릿 제어를 위한 설정 적용(연결된 플릿, 사용자 액세스 정책, 스토리지 구성)
  • streaming instance: 단일 유저가 사용할 수 있는 EC2 인스턴스(유저 세션이 완료되면 종료됨)
  • user pool: 사용자 및 할당된 스택 관리
  • auto scalings rules: 스트리밍 인스턴스 수를 자동으로 관리하기 위함
    • Always-On(24시간 내내 on) / On-Demand(유저가 on/off)

개념은 간단하게 소개 정도로 하고 생성한 뒤 자세히 살펴보려고 한다.(사실 개념 글만 봤을 땐 잘 안 잡혀서 실습으로 바로 때려 박는게 낫다는 판단을 했다!)

실습 참고: https://catalog.us-east-1.prod.workshops.aws/workshops/e324c13e-2ded-4da2-ad9c-f685305156ac/en-US

(실습이 길기에 전체 과정을 정리할 순 없고 내가 궁금한 부분들만 정리해볼려 한다.)

스트리밍할 애플리케이션 설치 및 구성

cloudformation을 통해 작업을 했고 github을 통해 받으면 된다.

Imagebuilder까진 생성이 된다!

Image builder 연결 단계 부터 쭉 진행하면 된다.

(Connect 누르고 Administrator로 진입해 원하는 애플리케이션을 다운로드 한다.)

해당 실습에서는 Google Chrome과 Notepad++의 설치를 진행할 예정!

위처럼 그냥 Firefox로 들어가서 url로 들어가 설치한다.

위처럼 설치 프로그램 파일이 나열 되어 있어야 함.(둘 다 설치 진행 하자)

해당 과정까지가 스트리밍할 애플리케이션 설치 및 구성 이다.

스트리밍용으로 활성화될 로컬에 설치된 애플리케이션 정의

(Image Assistant 활용)

이런 느낌! 위의 과정들을 거쳐야 유저들도 Administrator에서 다운받았던 어플들 사용이 가능해짐 :)

Configure Apps 과정에서 사용자를 위한 기본 애플리케이션 및 Windows 설정을 만드는데 실습에는 없다!(시간 오래걸림;;)

Test 단계에서 Switch User로 테스트 유저로 들어간 화면이다.

잘 되어 있다~! 앱들 클릭해보자.

이미지 생성 프로세스를 완료하는 데 약 15분이 걸린다. (Image builder의 상태가 Snapshotting)

위 Image registry의 경우 'Visibility = Private' 하면 생성 중인 이미지 확인 가능!

여기까지가 기본적으로 설정해줘야 할 것들이고 이후 실습들은 User에게 어떻게 배포할건지 진짜 스트리밍을 시작하는 과정 이다.

Fleet Provisioning

• Maximum session duration in minutes: 사용자 스트리밍 세션이 활성 상태로 유지될 수 있는 기간(끊기기 5분 전 알림)
• Disconnect timeout in minutes: 사용자가 연결 해제된 후 사용자 스트리밍 세션이 활성 상태로 유지될 수 있는 시간
  • (이 시간 간격 내 연결 해제 또는 네트워크 중단 후 스트리밍 세션에 다시 연결 시도 시 이전 세션 연결 가능)
• Idle Disconnect Timeout in minutes: 사용자가 스트리밍 세션에서 연결 해제되기 전에 유휴(비활성) 상태일 수 있는 시간

프로비저닝 완료하는데 약 10 - 15분 걸림

Stack Definition

최종 사용자는 S3에서 지원하는 세션 사이에 파일을 저장할 수 있는 영구 위치를 갖게 됨.

(Google Drive, One Drive 계정을 연결하게끔 구성도 가능)

최종 사용자 액세스

생성된 Stack을 선택한 뒤 Action에서 Create Streaming URL 클릭!

생성된 URL로 새로운 창에서 들어가보면 다음과 같은 화면을 보면 성공!

User Pool

User를 생성하고 해당 유저에게 Stack을 부여한다.(Action → Assign Stack)

이후 해당 User에게 Email이 발송되며 URL과 임시 비밀번호를 받을 수 있다.

❗ 스토리지 사용에 대한 내용은 좀 더 찾아봐야 할 듯!! ❗

Amazon QuickSight

• 클라우드 규모의 BI(Business Intelligence) 서비스
  • BI: 기업에서 데이터를 수집, 정리, 분석, 활용해 효율적인 의사결정을 할 수 있는 방법에 대해 연구
• Enterprise / Standard 비교:
  
  • https://aws.amazon.com/ko/quicksight/pricing/
  • ...
• SPICE(Super-fast, Parallel, In-memory Calculation Engine): 고급 연산을 신속하게 수행하고 데이터 제공하게 설계된 인메모리
• QuickSight Q
  • Q: QuickSight 엔터프라이즈 에디션을 위한 자연어 쿼리 도구
  • Q라는 친구와 대화를 하면서 5단계의 프로세스를 거치게 되는 느낌
  • https://aws.amazon.com/ko/blogs/korea/amazon-quicksight-q-business-intelligence-using-natural-language-questions/

참고: https://catalog.workshops.aws/quicksight/en-US

데이터 세트: SaaS-Sales.csv

위의 데이터 세트로 진행한다.

QuickSight 설정

그냥 계정 설정하면 된다... (일단은 standard로 지정)

그 다음 데이터 세트를 생성한다.

QuickSight 시각화

목표는 월별 매출 시각화 이다.

위와 같이 선택해주고 

Order Date의 집계를 Month로 설정해준다.

위와 같은 결과를 확인할 수 있다.

근데 여기서 문제는 내가 standard로 진행해서 추가적인 작업이 힘들다... 왜 Enterprise로 하라고 했는지 알 것 같기도....?

이런 식으로 데이터를 시각화를 하는 것!

❗ 뭔가 엔터프라이즈는 사용하기에 무서워서... 테스트 용이니까 standard로 진행했닿ㅎㅎ ❗

Athena 사용법: https://realyun99.tistory.com/147

Athena+Glue(Crawler) 활용: https://realyun99.tistory.com/148

저번 포스팅들에 이어서 계속 진행해볼 것...

• Athena CTAS를 사용한 ETL

대부분의 경우 데이터 레이크 또는 테이블로 들어오는 raw data는 csv 또는 텍스트 형식이다.

이런 형식은 Athena, 기타 엔진으로 쿼리하는 데 최적이 아니다. 데이터를 parquet과 같은 포맷으로 변환하는 것이 좋다.

CTAS(Create Table As Select) 쿼리를 사용해 테이블을 tsv 형식에서 parquet 포맷으로 변환하고 압축 및 분할을 통해 저장할 것..

저장된 쿼리에서 Athena_ctas_reviews를 실행해보자

(s3 버킷 이름을 잘 설정 해주자!)

다음 쿼리를 실행하면 다음과 같이 결과를 볼 수 있다.

명령들을 좀 살펴보자!

CREATE TABLE amazon_reviews_by_marketplace
WITH ( format='PARQUET', parquet_compression = 'SNAPPY', partitioned_by = ARRAY['marketplace', 'year'], 
external_location =   's3://<<Bucket-name>>/athena-ctas-insert-into/') AS
SELECT customer_id,
        review_id,
        product_id,
        product_parent,
        product_title,
        product_category,
        star_rating,
        helpful_votes,
        total_votes,
        verified_purchase,
        review_headline,
        review_body,
        review_date,
        marketplace,
        year(review_date) AS year
FROM amazon_reviews_tsv
WHERE "$path" LIKE '%tsv.gz';

/* Let's try to find the products and their corresponding category by number of reviews and avg star rating for US marketplace in year 2015 */

SELECT product_id,
        product_category,
        product_title,
        count(*) AS num_reviews,
        avg(star_rating) AS avg_stars
FROM amazon_reviews_by_marketplace
WHERE marketplace='US'
AND year=2015
GROUP BY  1, 2, 3
ORDER BY  4 DESC limit 10;

parquet_compression = 'SNAPPY' 같은 경우는 압축 방식을 정하는 것..

https://docs.aws.amazon.com/ko_kr/athena/latest/ug/compression-formats.html

Like 구문: SELECT * FROM [table name] WHERE [column] LIKE [condition];

부분적으로 일치하는 컬럼을 찾을 때 사용

• Athena Workgroups

Workgroup: 사용자, 팀, 애플리케이션 또는 워크로드를 분리하고 각 쿼리 또는 전체 workgroup이 처리할 수 있는 데이터 양에 대한 제한을 설정하고 비용을 추적한다.

"Workgroup이 리소스 역할을 하기 때문에 리소스 수준 ID 기반 정책을 사용해 특정 workgroup에 대한 액세스 제어 가능!"

저번 포스팅의 테이블 생성 실습에서 primary 작업 그룹에 대한 CloudWatch 메트릭을 활성화했다.

CloudWatch 지표를 확인해보자(작업 그룹 → primary → 지표)

데이터 사용 제한을 설정해보자.

workgroupA를 클릭한 뒤 편집에 들어가 해당 데이터를 제한하자.

CloudFormation을 열고 스택 출력에 들어가 ConsolePassword 링크 클릭(AWS Secrets Manager로 이동)

해당 암호 값 검색을 통해 비밀번호를 확인하자.

시크릿 탭을 열어

IAM user name: userA

Password: 복사한 비밀번호 로 로그인하자.

Athena 콘솔을 열고 쿼리 결과 위치에 primary 위치를 입력한 다음 wrokgroupA를 선택하자.

(참고로 현재 실습은 버지니아 북부에서 진행 중이다!)

쿼리를 실행해보면 실행 불가!

실행했던 쿼리문이다..

/* Let's try to find the products and their corresponding category by number of reviews and avg star rating on parquet table */

SELECT product_id, product_category, product_title, count(*) as num_reviews, avg(star_rating) as avg_stars
FROM amazon_reviews_parquet 
GROUP BY 1, 2, 3
ORDER BY 4 DESC
limit 10;

다음으로 workgroupB로 전환하고 userA가 workgroupB에서 동일한 쿼리를 실행할 수 있는지 확인해보자.

권한이 없어 할 수 없다는 오류가 발생한다.

Athena 사용법: https://realyun99.tistory.com/147

저번 포스팅에 이어서 Glue까지 사용을 해보자. 사용 전에 Glue가 뭔지 부터 확인하자.

AWS Glue

• 분석, 기계 학습 및 애플리케이션 개발을 위해 데이터를 쉽게 탐색, 준비, 조합할 수 있도록 지원하는 서버리스 데이터 통합 서비스
• 데이터 통합: 해당 개발을 위해 데이터를 준비하고 결합하는 프로세스
  • 데이터 검색 및 추출
  • 데이터 강화, 정리, 정규화 및 결합
  • 데이터베이스, 데이터 웨어하우스 및 데이터 레이크에 데이터 로드 및 구성 등
• 기능
  • Data Catalog: 모든 데이터 자산을 위한 영구 메타데이터 스토어
    • 모든 AWS 데이터 세트에서 검색: 자동으로 통계를 계산하고 파티션을 등록, 데이터 변경 사항 파악
    • Crawlers: 소스/대상 스토어에 연결해 우선순위가 지정된 Classifiers을 거치면서 데이터의 스키마 결정, 메타 데이터 생성
    • Stream schema registries: Apache Avro 스키마를 사용해 스트리밍 데이터의 변화를 검증하고 제어
  • Data Integration and ETL(Extract / Transform / Load)
    
    • Studio Job Notebooks: Studio에서 최소한으로 설정할 수 있는 서버리스 노트북
    • Interactive Sessions: 데이터 통합 작업 개발을 간소화, 엔지니어와 대화식으로 데이터 탐색, 준비
    • ETL 파이프라인 구축: 여러 개의 작업을 병렬로 시작하거나 작업 간에 종속성을 지정
    • Studio: 분산 처리를 위한 확정성이 뛰어난 ETL 작업 가능, 에디터에서 ETL 프로세스를 정의하면 Glue가 자동으로 코드 생성
    • 등등...
  • Glue DataBrew: 시각적 데이터 준비 도구(사전 빌드된 250개 이상의 변환 구성 중 선택해서 코드 없이 가능)

솔직히 뭐라고 하는지 모르겠다.. 직접 써보는게 답!

Crawler로 실습을 진행해보자.

• Glue로 테이블 만들기

크롤러를 생성해주자.

데이터 스토어는 저번 포스팅 때 가져왔었던 데이터셋이 위치한 버킷으로 지정할 것!

Create new IAM role을 통해 새로 생성하고 지정해준다. 타겟 DB까지 정해주면 끝!

크롤러를 돌려주자(생성된 크롤러 선택 후 Run 버튼 클릭)

Glue → Tables에 들어가면 테이블이 하나 더 추가된 것을 볼 수 있다.

Athena로 돌아가 다음 쿼리를 실행해 데이터를 확인해보자.

select * from amazon_review_glue_parquet limit 10;

• Views 만들기

다시 Athena로 돌아왔다.(Athena의 view는 물리적 테이블이 아닌 논리적 테이블!)

저장된 쿼리에서 Athena_create_view_top_rated를 클릭한다.

위 이미지 처럼 선택 후 실행한다. 아래와 같이 보기에 추가된 것을 확인할 수 있다.

두번째 쿼리를 선택한 뒤 실행해 등급별로 상위 10개 제품을 확인해보자.

• 결과 확인(S3 버킷)

S3에서 athena-workshop-<account-id> 로 시작하는 버킷을 찾아 들어가면 처음엔 비어있던 버킷이 Athena에서 돌렸던 쿼리문을 기준으로 폴더들이 생성되어 있는 것을 볼 수 있고, Athena_compare_reviews 접두사 중 하나를 찾아보면 쿼리 ID와 함께 저장된 결과를 볼 수 있음.

❗ 그래서 결과적으로 Glue Crawler가 무슨 역할을 했냐...? ❗

크롤러 작동 방식:

데이터를 분류하여 raw data의 포맷, 스키마 및 관련 속성 결정 / 데이터를 테이블 혹은 파티션으로 분류 / 메타데이터를 Data Catalog에 작성

위와 같은 것들을 crawler를 생성하고 실행하면 알아서 해주는 느낌인듯?

데이터 스토어를 지금은 하나를 지정했지만, 여러 개 병렬로도 가능하고...

지금 했던 실습 같은 경우는 아주 단순한 경우인 거고, 여러 방식으로 활용이 가능하다!

(그리고 Athena는 쿼리를 돌려서 테이블을 만들었지만, 크롤러는 그런게 없이 알아서 돌려주네?!)