Udemy 의 Complete AWS Certified Data Engineer Associate - DEA-C01 강의 필기
< S3 >
S3 는 객체(files)를 저장하는 객체 저장소 |
각 Bucket 은 특정 지역(region) 에 따라 물리적인 위치가 바뀌며 사용자와 가장 가까운 region 을 선택해야 빠르게 IO 할 수 있어서 좋음 Bucket 이름은 전세계적에서 유일한 이름이어야 함 Users can experience fast IO speeds. |
S3 에 업로드 된 객체(files) 는 각자 고유의 Key 를 갖게 되며, 이 키를 기준으로 bucket 내의 객체를 판별할 수 있음 예를 들어, 아래와 같은 환경이 있다고 하자 bucket name : mybucket path : order/2025-06-25/ file name : data_001.parquet 여기서 S3 객체를 판별하기 위한 키는 "order/2025-06-25/data_001.parquet" 이 됨 즉, path 와 file name 이 합쳐진 문자열 그대로 Key 값이 됨 실제로 python 에서 s3 에 데이터 업로드 할 때, 아래처럼 'key' 파라미터를 넣음 s3.put_object( Bucket="mybucket", Key="order/2025-06-25/data_001.parquet", ) S3 에는 dir 개념이 없고, 단지 우리가 보기에 dir 처럼 보이는 것 뿐임 dir 는 key 에 붙는 접두사 같은 것이라고 생각하자 이렇게 (dir 처럼 보이는) 접두사가 key 에 붙으므로써 접두사 기반의 스캔이 매우 빠르고, partition 이 가능하게 됨 Pass the key parmeter to the function as follows. S3 doesn't have the concept of directories. What we see merely appears to be directories. Prefixes, suffixes. 접두사 접미사 A sort of prefix attached to the key. Partitioning becomes possible. |
S3 class 마다 각기 다른 Durability, Availability 를 갖음 Durability : 데이터를 잃어버릴 가능성. 모든 class가 99.999999999% 를 갖으며, 이를 11nines 라고도 부름 Availability : 데이터를 문제없이 읽을 수 있는 확률 Durability refers to the potential for data loss. Durability refers to the likelihood of not lossing data. Availability refers to the probability of being able to read data without issues. |
Lifecycle Rules : 다른 s3 class 로 변경할 때 적용되는 룰. (예를 들어, s3 standard 내 파일이 30일후에 glacier 로 옮겨짐) Versioning : 과거 버전 객체도 읽을 수 있는 기능이 제공됨 |
s3 bucket 에 tag 를 달면, 나중에 정산할 때 구분을 위한 지표로 사용 가능함 We can use tags as indicators for distinguishing pusrposes when settling accounts later. |
< Glue >
Glue 는 Fully-managed serverless ETL service 임 즉, 데이터 읽고 변경하고 저장하는 작업을 할 수 있음 게다가 코드 없이 visual interface 만 이용하여 작업이 가능함 (코드가 있긴 한데 자동으로 만들어지고 숨어있음) E : RDB, Redshift, S3, Kinesis (Streaming), JDBC 로 연결되는 외부 source 등 T : Filtering, Joining, Aggregation, Finding matches with ML, Detecting PII, Changing file formats, etc Scala Spark, PySpark 기반의 Glue Job, 처리 후 parquet/csv/orc 등으로 저장 가능 L : s3, Redshift, Kafka, JDBC 로 연결되는 외부 target 등 Moveover, we can work using only the visual interface without any code. External source connected via JDBC. |
Glue Crawlers 라는 기능이 있음 내가 csv 파일 하나를 s3 에 업로드 했다고 가정하자 Glue Crawlers 는 이 csv 파일의 정보를 분석하고 추론함 (파일 포맷은 무엇이고, csv 내 컬럼은 몇 개가 있고, 컬럼 이름을 무엇이고 타입은 무엇이고... 등등) Crawlers 는 S3 상의 특정 path 내 파일들을 처리할 수 있음 그 파일들은 모두 같은 포맷과 형식을 갖고 있어야 함 Glue Crawlers 는 주기적으로 자동 실행되도록 스케줄링하거나, 직접 수동으로 실행할 수 있음 There is a feature called Glue Crawlers. Glue Crawlers parse and infer. Glue Crawlers can be scheduled to run automatically at regular intervals. |
Glue Data Catalog 라는 기능이 있음 Glue Crawlers가 분석한 스키마와 메타데이터 등의 데이터가 Centralized Data Catalog 에 저장됨 이를 기반으로 Athena, EMR 등에서 csv 파일을 쿼리할 수 있음 Hive 의 metastore 와 같다고 생각하면 됨 Athena, EMR can query CSV files. |
ETL 작업 진행시, 기존에 처리하지 않았던 데이터만 load 하고 crawling 할 수 있음 이것을 incremental loads/crawling 이라고 함 예를 들어, crawlers 는 마지막 크롤링 이후 최근에 추가된 데이터만 크롤링(컬럼 분석, 스키마 추론) 하게 됨 Data that has not been previously processed. |
 Data Catalog/Crawlers 에 크롤러 내용이 들어감 Data Catalog/Databases/Tables 에 크롤러가 수집하고 추론한 메타데이터가 들어감 이 tables 내에 있는 데이터를 기반으로 Athena, EMR 이 데이터에 (SQL 처럼) 접근할 수 있음 |
크롤러가 특정 s3 path 를 크롤링하여 생성한 메타데이터가 data catalog 에 저장되고, 이 정보를 기준으로 테이블이 생성됨 Athena 는 data catalog 로부터 테이블 정보를 얻고, 또 이 테이블에 쿼리할 수 있음 (추가 설명; data catalog 가 저장하는 것은 metadata 가 맞지만 Athena, EMR 이 쿼리할 때 사용하는 이 '테이블'이라는 것은 메타데이터를 기반으로 생성한 논리적인 테이블이며 이 테이블을 이용하여 실제 s3 파일에 접근 가능함) 여기서 database 이름은 사용자가 직접 넣어줄 것이고, table 이름은 s3 경로의 마지막 디렉토리 이름을 기반으로 생성됨 예를 들어 s3://my-bucket/raw/sales 를 크롤러가 읽게된다면, 생성되는 테이블 이름은 'sales' 만약 두 개의 서로 다른 크롤러가 똑같은 s3 path 를 크롤링하고 동일한 이름의 테이블을 만든다면 마지막에 실행된 크롤러의 메타데이터가 처음에 실행된 크롤러의 메타데이터를 덮어씀 만약 두 개의 서로 다른 크롤러가 똑같은 s3 path 를 크롤링하고 서로 다른 이름의 테이블을 만든다면 덮어쓰거나 하는 일 없이 서로 다른 이름의 테이블이 생성됨 (동일한 데이터 중복 발생) |
S3 path 에 파티셔닝 정보(디렉터리)를 넣으면, Glue Crawlers 가 알아서 자동으로 파티셔닝 테이블을 만든다고 함 예를 들어 사용자가 아래와 같은 경로를 구축한 뒤, 크롤러를 설정하면 크롤러가 내부 경로를 자동으로 파싱해서 파티셔닝 테이블을 만듦 s3://my-bucket/ecommerce/orders/ dt=2025-01-01/ part-0001.snappy.parquet part-0002.snappy.parquet dt=2025-01-02/ part-0001.snappy.parquet dt=2025-01-03/ ... 이 테이블을 Athena 가 읽으면, 자동으로 partition pruning 해서 읽게 됨 실제로 크롤러가 생성한 메타데이터(in data catalog) 안에는 'partitionKeys' 라는 정보가 포함되어 있음 즉, data cagtalog 테이블이 파티셔닝 테이블로 설정되어 있다는 말임 It automatically performs or applies partition pruning. |
Data Ingestion Context - Stateful : 이전에 어디까지 데이터를 수집했는지 (offset, 시퀀스 넘버 등을 통해) 기억하고 있다가, 끊어진 부분부터 다시 수집 가능 stateful 은 'bookmark' 기능을 통해 구현할 수 있다고 함 - Stateless : 이전에 어디까지 데이터를 수집했는지 기억하지 않음. 수집 실행시, 처음부터 다시 다 수집함 Stateful functionality can be implemented through the 'bookmark' feature. |
Glue Job Workflow 를 통해 Glue 내 여러 작업들을 연결하여 스케줄링 할 수 있음 마치 airflow 처럼 처음에 workflow 가 트리거되면, 그 다음 ETL 작업을 실행되도록 하고, 그 다음 크롤러가 실행되도록 하고, 그 다음 퀄리티 체크 작업이 실행되도록 하고,,, Through the Glue Job Workflow, we can connect and schedule multiple Glue jobs. |
AWS Glue DataBrew 라는 서비스가 있음 DataBrew = GUI 기반으로 데이터를 정제(전처리) 하는 도구 여기서 '전처리'란 아래 작업들을 의미함
전처리 된 결과 데이터를 S3에 저장하거나 Glue 데이터 카탈로그에 등록 We can register this in the Glue data catalogue. 예를 들어, 아래와 같은 데이터가 존재하고 { "order_id": "123", "customer": " Lee, Woo ", "order_date": "2025/05/01 12:02:31", "amount": "399,000", "items": "[{'id': 10, 'name': 'Macbook', ...}]" } 아래와 같은 이슈 때문에 데이터를 전처리하려고 함
There are spaces before and after the name. DataBrew 가 S3 Raw 데이터를 가져와서 GUI로 전처리 “Recipe(레시피)”를 만듦 레시피는 아래처럼 생겼음 Step 1: Trim(customer) Step 2: ConvertToDate(order_date, format=YYYY-MM-DD) Step 3: RemoveCharacter(amount, ',') Step 4: ToInteger(amount) Step 5: ParseJsonColumn(items) Glue Job 에서 레시피를 실행. 실제 전처리 작업은 내부 Spark로 처리됨 전처리 결과 파일은 S3로 저장(Parquet 권장)하고, 추가로 Glue Catalog에 연결하면 Athena 등에서 바로 쿼리 가능 DataBrew = 전처리 레시피를 만드는 GUI 도구 Glue Job = 레시피를 실제 실행시키는 Spark 엔진 DataBrew 가 제공하는 프로파일링 기능이 굉장히 유용함 데이터 분포, Null 비율, value range, outlier 등을 자동 분석해 줌 문자열 처리, 숫자 변환, 날짜 변환, 파티셔닝, unnest 등. 근데 DataBrew 는 복잡한 전처리를 하기에 적절하지 않음(구현하기 어려움)
비용 측면에서도 Glue ETL 대비 효율이 안 나올 수 있음 (DataBrew는 쓰는 시간·데이터 양에 따라 과금되기 때문에) DataBrew is not suitable for certain complex pre-processing analyses. In terms of cost, it may not prove as efficient as Glue ETL. 외국인 관점에서 from a foreigner's perspective. |
Glue 에서 pyspark 를 실행하여 데이터를 transform 하는 방법 AWS Glue 의 왼쪽 메뉴에서 ETL → Jobs 선택 → “Create job” 선택하고 pyspark 스크립트를 넣음 → Job 화면에서 “Run” 누르면 Glue Spark Cluster가 자동으로 뜸 → PySpark 코드 실행 → 종료되면 cluster는 자동으로 사라짐 Press the 'run' button on the screen. |
hudi/Iceberg 를 이용하여 멱등성있게 데이터를 넣는 코드 샘플 : https://eyeballs.tistory.com/m/684 idempotently! |
< Athena >
S3 내 파일에 쿼리를 날릴 수 있음 어떤 종류의 파일(parquet, csv, txt, avro...), 어떤 형식의 파일(정형, 비정형...)이든 상관 없이 쿼리할 수 있음 AWS Glue 를 통해 수집한 메타데이터(Glue Data Catalog) 를 이용해서 데이터를 쿼리하는 것임 |
 Athena 화면 왼쪽을 잘 보면 Glue Data Catalog 에 설정된 부분을 선택하는 'data source', 'database' 가 있음 여기서 database (Glue Data Catalog) 를 선택하면 됨 Look at the left side of the screen Look at the right side of the screen Look at the centerof the screen Look at the top of the screen Look at the bottom of the screen |
Athena 를 처음 사용하면 '쿼리 결과를 저장 할 s3 path를 선택하라'는 메세지가 나옴 이 s3 path 에 들어가는 데이터는 - 쿼리 실행 후 반환되는 실제 쿼리 결과 - 쿼리 실행에 사용된 메타데이터 (쿼리 실행 ID, 실행 시간, 스캔된 데이터양, 에러메세지 등) 이걸로 쿼리 디버깅 할 수 있겠네 이렇게 저장된 쿼리 결과들은 시간이 지나면 의미가 사라지니까, retention 기간을 설정하는 게 좋겠음 Query results lose their meaning over time. |
CREATE EXTERNAL TABLE ecommerce.orders ( order_id string, user_id string, amount double ) PARTITIONED BY (dt string) STORED AS PARQUET LOCATION 's3://my-bucket/ecommerce/orders/'; 위와 같은 쿼리를 실행해서 파티셔닝 테이블을 만들고, MSCK REPAIR TABLE ecommerce.orders; 위 쿼리를 실행하면, Athena 가 s3 partitining path 를 만들고 자동으로 Data Catalog 에 등록한다고 함 전회사에서는 이 방법(with glue crawlers) 사용하지 않고 아래 방법을 사용하여 partitining 했음 |
Athena 가 partitinging 된 테이블에 쿼리를 날릴 때 partitining 정보를 Data Catalog 로부터 읽어오는데, 만약 partitining 정보가 많다면, 이 읽는 과정 자체가 오버헤드로 작용할 수 있음 이를 방지하기 위해 Partition Projection 을 사용 Data Catalog 으로부터 partitining 정보를 읽지 않고, Athena 자체적으로 partition 을 계산하고 파티셔닝함 예를 들어, Athena 에서 아래와 같은 쿼리를 통해 테이블을 생성 CREATE EXTERNAL TABLE orders ( order_id string, user_id string, amount double, product_id string ) PARTITIONED BY (date string, hour int) STORED AS PARQUET LOCATION 's3://my-bucket/ecommerce/orders/' TBLPROPERTIES ( 'projection.enabled'='true', -- date partition projection 설정 'projection.date.type'='date', 'projection.date.format'='yyyy-MM-dd', 'projection.date.range'='2025-01-01,NOW', 'projection.date.interval'='1', 'projection.date.interval.unit'='DAYS', -- hour partition projection 설정 'projection.hour.type'='integer', 'projection.hour.range'='0,23', 'projection.hour.interval'='1', -- 경로 템플릿 'storage.location.template'='s3://my-bucket/ecommerce/orders/date=${date}/hour=${hour}/' ); 혹은 Spark 에서 아래와 같은 쿼리로 partitining 테이블에 데이터를 추가 df.write .partitionBy("date", "hour") .mode("append") .parquet("s3://my-bucket/ecommerce/orders/") 그러면 아래와 같은 조건절이 포함된 쿼리 실행시 Athena 가 직접 partition projection 하여 정해진 파티션만 읽음 (여기선 Glue Data Catalog 정보를 가져오는 과정이 생략됨) SELECT * FROM orders WHERE date = '2025-01-15' AND hour = 10; In other words, we skip the process of reading info. |
Athena 는 Federated Query 기능을 사용할 수 있음 쿼리 대상이 단지 s3 내 파일에만 있는 것이 아니라 다른 스토리지, 예를 들어 AWS DynamoDB, RDS, 혹은 외부 MySQL 등을 데이터 source로 설정하고 쿼리 가능 (connector 를 꼭 설정해야 연결됨) |
< Lambda >
lambda 는 AWS 에서 제공하는 서버리스 코드 실행기임 특정 조건이 만족했을 때 (미리 넣어둔) 코드가 실행되도록 설정하는 방식으로 사용함 다르게 말하면, event-driven 으로 실행됨 예를 들어, s3 의 abc bucket 에 파일이 새로 생성되는 경우 xyz lambda 함수가 실행되도록 할 수 있음 여기서 '이벤트'는 's3 버켓에 파일이 업로드 되었을 때'임 You can configure the code to execute when the conditions are met. its called 'event-driven' |
코드 실행에 필요한 자원은 자동으로 늘어나거나 줄어듦 즉, auto scaling 이 기본으로 지원되며, 엔지니어인 우리가 따로 설정하지 않아도 됨 Auto scaling is supported by default. |
Lambda 함수는 stateless 임 기존에 동작했던 내용을 저장해두거나 기억하지 않음 lambda 함수는 동작 할 때마다 매번 새롭게 동작하게 됨 It does not store or remember what it previously did. A lambda function executes anew each time it is invoked. |
lambda 코드는 python3, NodeJS, JAVA, Go 등 다양함 lambda 에서 하라는대로 코딩해야 함(...) lambda 가 이해할 수 있는 방식을 사용해서 코딩해야 한다는 말임 (마치 lambda 함수를 사용하여 코딩하는 느낌) |
Lambda Layer 라는 개념이 있음 lambda layer 는 zip 파일인데, lambda 코드에서 import 하여 사용함 마치 python 이 외부 package 를 import 하여 사용하는 것처럼. 여러 lambda 함수에서 사용하는 공통 기능을 (모듈화 하는 느낌으로) Lambda layer 의 zip 파일로 만들 수 있음 관리 측면에서 아주 유용함 Common functionality used across multiple Lambda functions can be packaged into a zip file as a Lambda layer (in a manner similar to the modular approach). We can bundle several common functions together to create a zip file. |
< Redshift >
Redshift 는 AWS 에서 완전 관리하고 petabyte-scale 데이터를 관리할 수 있는 데이터 웨어하우스 서비스 - 어마어마한 양의 데이터 처리가 가능하며 scale out 역시 가능함 - columnar stroage 를 사용하여 IO 성능이 좋음 - 모든 SQL 명령어를 지원하여 테이블에 쿼리를 날릴 수 있음 - Massively Parallel Processing 함. 즉, 대규모 병렬 처리를 사용하여 처리 성능이 좋음 - 다른 aws services(s3, dynamnoDB, glue, lambda) 등과 호환되어 데이터 수집이나 변환, 분석 등을 쉽게 할 수 있음 - 세분화된 보안 제어를 제공함 It is compatible with other services. |
Lakehouse (in s3) 에 있는 parquet 데이터를 Data Warehoue인 Redshift 로 옮기는 방법에 대해 설명 Lakehouse 내 아래와 같은 경로에 데이터가 있다고 가정 s3://my-datalake/bronze/orders/year=2025/month=01/day=10/orders_2025-01-10.parquet s3://my-datalake/bronze/orders/year=2025/month=01/day=11/orders_2025-01-11.parquet ......... 이 데이터에 맞춘 스키마를 미리 준비하여 Redshift 내 테이블로 생성 external table 을 만들 수 있고, internel table 을 만들 수 있음 아래는 external table 을 만드는 형태임 CREATE EXTERNAL TABLE spectrum_orders.orders_raw ( order_id BIGINT, user_id BIGINT, product_id BIGINT, price DECIMAL(10,2), quantity INT, order_timestamp TIMESTAMP ) PARTITIONED BY (year int, month int, day int) STORED AS PARQUET LOCATION 's3://my-datalake/bronze/orders/'; -- external table 이라서 데이터 위치는 그대로 근데 external table 은 s3 에 있는 데이터를 그대로 가져오는거라 집계 성능이 떨어짐 이렇게 s3 에 있는 데이터를 Redshift SQL 로 직접 조회하는 기능을 Redshift Spectrum 이라고 함 반대로, internal table 을 생성할 수 있음 internal table 은 미리 테이블을 만들고, 데이터를 lakehouse 로부터 table 로 복사하는 과정을 거쳐야 하지만 대신 external table 사용했을 때보다 쿼리 성능은 더 뛰어남 CREATE TABLE public.orders ( order_id BIGINT, user_id BIGINT, product_id BIGINT, price DECIMAL(10,2), quantity INT, order_timestamp TIMESTAMP ) DISTKEY(order_id) SORTKEY(order_timestamp); 위와 같이 테이블을 먼저 생성한 후, datalake 데이터를 table 로 복사 COPY public.orders FROM 's3://my-datalake/bronze/orders/' IAM_ROLE 'arn:aws:iam::1234567890:role/MyRedshiftRole' FORMAT AS PARQUET; On the contrary, we can create an internal table. Instead, query performance is superior compared to when using an external table. 이 과정에서 Redshift 는 지정된 s3 경로 내 모든 파일(여기선 parquet)을 스캔 스캔한 파일을 읽고 Redshift 내부 저장 형식(columnar + compression)으로 변환 변환한 파일을 각 compute node 내 slice 단위로 데이터를 분산 저장 이렇게 COPY 명령을 통해 Redshift 의 compute nodes 로 데이터를 옮길 수 있고 아래와 같이 Redshift 테이블에 쿼리 할 수 있음 SELECT * FROM public.orders WHERE order_timestamp >= '2025-01-01'; 위와 같이 쿼리를 실행하면, Redshift 의 compute nodes slice 기반의 분산 처리 시스템과 IO 효율이 좋은 columnar 저장 방식에 의해 쿼리의 성능이 높아짐 During this process, Redshift scans all files within the specified S3 path. Convert it into Redshift's internal storage format. The converted file can be stored in slices across distributed computing nodes. 여기서 특히 중요한 COPY 명령어가 내부적으로 하는 일을 정리함 - s3 파일 병렬로(MPP) 다운로드 - compute node 로 분산 로딩 (s3 에서 각 compute nodes 로 데이터를 읽어옴) - 컬럼 기반 압축 인코딩을 데이터에 적용 - slice 단위로 테이블 내에 저장 (compute node 로 읽은 데이터를 각 slices 로 나눠서 저장) - commit - 추가로 통계 데이터 update Store within the table in slice units. 참고로 COPY 는 주기적으로 처리되도록 설정할 수 있음 |
Redshift 의 external table, internal table 간 쿼리 성능 차이 정리 IO - external table : 쿼리 실행시 s3 에 있는 데이터를 네트워크를 통해 읽어와야 하기 때문에 네트워크 오버헤드가 있음 - internal table : compute node 내 캐시로 사용되는 local ssd 가 존재하기 때문에 IO 가 엄청 빠름 최적화 - external table : 최적화 기법을 거의 적용하지 못 함 - internal table : 직접 관리하는 테이블이기 때문에, 여러 최적화 적용 가능 예를 들어 DistKey, SortKey 적용, Zone map, 컬럼 압축 인코딩 등 병렬처리 - external table : s3 데이터를 읽는 단계에서 파일 개수에 따라 병렬로 read 가능 (아래 spectrum 부분에 추가 설명) - internal table : compute node 의 slice 기반으로 병렬처리 가능 The stage of reading s3 data. |
최적화 방법에 대해 설명 - DistKey (distribution key) 데이터가 어떤 기준으로 각 compute nodes 에 분산 저장될지 결정하는 키 join, group by 등 그룹을 지어야 하는 연산 실행시 같은 key 값을 갖는 row 가 같은 node 에 있어야 (노드 간) 데이터 이동(shuffle)이 없어서 빠르게 처리되기 때문에 DistKey 를 기준으로 각 compute nodes 에 미리 나눠두는 것 - SortKey 각 slice 내부에서 데이터를 어떤 컬럼 기준으로 정렬하여 저장할지 결정하는 키 where 조건 검색 성능이 높아지고 읽기 실행시 필요한 부분만 읽게 되어 읽기 효율이 좋아지고 order by 가 빨라짐 - Zone Map 각 data block 의 min/max 값이 저장된 메타데이터 where 조건 검색시 필요한 block 만 읽게되므로 성능 향상 - 컬럼 압축 인코딩 컬럼별로 가장 효율적인 압축 방식을 적용 저장 용량을 줄이고 IO 성능도 향상하는 방법 DistKey is the key that determines the criteria by which data is distributed and stored across the compute nodes. SortKey is the key that determines which column to sort data within each slices before storage. Rows with the same key value must reside on the same node to eliminate shuffle, thereby accelerating processing. |
Redshift Spectrum 데이터는 S3 에 존재 Redshift 는 메타데이터만 갖고 있음 쿼리할 때 s3 로부터 필요한 파일을 읽고 처리 (처리하는 엔진은 여전히 Redshift) 데이터가 수백 TB~PB 정도로 어마어마하게 크거나 자주 쿼리하지 않는 cold data 를 s3 에서 꺼내야 할 때 spectrum 을 이용하여 쿼리함 s3 데이터를 읽을 때는 Glue Data Catalog 로부터 얻은 메타데이터를 참고하여 찾아 읽음 이 말인 즉슨, s3 데이터는 이미 Glue Crawler 에 의해 분석되고, 생성된 메타데이터가 data catalog 에 미리 넣어져야 한다는 말이지 하나의 큰 파일을 s3 로부터 읽는 것보다 여러개의 작은 파일들을 s3 로부터 읽는 것이 read 작업에 병렬성을 부여하기 때문에 더 빠름 read 작업을 처리하는 스레드가 있다고 함...그게 뭔지는 모르겠다 data that is not frequently accessed in S3 |
Redshift 는 - Data Warehousing 용도로 사용 - Business Intelligence 를 위한 분석 엔진 용도로 사용 |
Amazon Redshift query editor v2 라는 툴을 사용하여 Redshift 에 접근하고 쿼리를 실행할 수 있음 혹은 외부 BI 툴로 Redshift 에 접근하여 쿼리를 실행할 수 있음 다양한 데이터 포맷을 지원. csv, json, orc, parquet.... |
Redshift 를 구성하는 클러스터는 두 가지 종류의 노드로 구성됨 (spark 와 많이 닮아있어서 spark 베이스로 이해하면 될 것 같음) - Leader Node : spakr 의 driver 와 같은 역할. master node. 하나 존재함 2대 이상의 compute nodes 를 coordinating 하는 역할 외부 odbc, jdbc 로 클라이언트와 연결되고, 클라이언트로부터 명령(쿼리)을 받음 클라이언트로 받은 쿼리를 실행 계획으로 변환 실행 계획 기반으로 쿼리를 compute nodes 로 보내어 실행하게 하고 그 결과를 모두 넘겨받아 정리하여 클라이언트에게 전달해 줌 오직 Leader Node 에서만 실행되는 SQL 함수가 있다고 함 (Leader Node 에서 실행되지 않으면 오류를 일으킴) - Compute Nodes : spark 의 workers 와 같은 역할. 여럿 존재함 리더 노드의 지시에 따라 (클라이언트가 요청한) 쿼리를 실행함 각 compute node 는, (리더노드 실행 계획에 따른)명령 실행을 위한 실제 데이터를 저장하고 있음 (각 compute node 는 테이블을 슬라이스(slice) 라는 작은 단위로 분할해서 저장하고 있음) 각 compute node 가 갖고있는 작은 데이터 파트들에 쿼리 명령을 실행하고 결과를 리더노드에게 전달함 노드 수를 늘리거나, 노드 타입을 바꿔서 capacity 를 바꿀 수 있음 Compute Nodes 가 저장하는 데이터는 columnar 로 저장되어 있음 즉, 압축률이 매우 높고, 필요한 열만 읽어 IO 비용 효율적임 It achieves very high compression ratios and reads only the necessary data, making it highly cost-effective in terms of I/O. Compute node 간 데이터를 어떻게 배치할지 결정하는 것을 Distribution Style 이라고 함 - DISTKEY : 특정 컬럼 기준으로 데이터를 서로 다른 노드에 분배. 큰 fact 테이블 조인 시 사용 - SORTKEY : 정렬 기준. WHERE, ORDER BY, RANGE 쿼리 성능 향상 - EVEN : 특정 컬럼 값이 아니라 그냥 균등하게 모든 compute nodes 에 데이터를 골고루 분배함 - ALL : 작은 dimension 테이블은 모든 노드에 복제. 조인 성능 향상 - AUTO(default) : Redshift 가 테이블 사이즈 기반으로 알아서 자동으로 분배함. 심지어 테이블 크기가 커지면 distribution style 을 key 기준으로 바꾸기도 함 dist style 이 바뀌는 작업은 background 에서 진행되므로 쿼리 실행에 큰 영향을 주지 않음 실제 Redshift 노드를 구성할 때, 두 가지 옵션을 선택할 수 있음 - Redshift Serverless : 클러스터 없이 사용 가능한 Redshift 엔지니어가 직접 노드를 구성하는 것이 아니라, AWS 에서 알아서 서버를 구성해 줌 사용량에 따라 자동으로 scaling 됨 노드 관리, 데이터 용량 걱정 없음 (데이터는 Redshift Managed Storage(S3) 에 저장되기 때문) 쿼리 실행 시간만큼 비용 지불 작은 회사에서 운영 부담 줄이기 최적화. 수요 예측이 불가능할 때 선택하는 옵션 - provisioned cluster : 엔지니어가 직접 노드를 구성함 원하는대로 구성할 수 있으며, 수요가 예측 가능한 상황일 때(안정적인 상태) 선택하는 옵션 This is the option chosen when demand forecasting is impossible. 수요, 공급 : demand and supply |
compute nodes 구성을 위해 선택할 수 있는 두 가지 노드 타입 - DC2 : 노드 내 SSD 기반 스토리지를 사용하여 데이터 저장. IO 고성능이지만 저장 공간이 작음 (저장 공간 늘리려고 DC2 노드 추가하면 의미없는 컴퓨팅 자원까지 같이 늘게되어 비용 효율적이지 못 함) 그리고 오직 하나의 Availability Zone 만 지원함 1TB 까지만 지원한다고 함(....) - RA3 (권장되는 노트 타입) : Compute/Storage 가 분리되어 있는 아키텍처 데이터는 S3 기반의 Redshift Managed Storage(RMS) 에 저장하고, 노드 안에는 데이터 저장하지 않음 여기서 노드는 계산만 진행함 저장 공간(s3)이 무한하고, 필요할 때 compute node 만 스케일링 하면 되서 비용이 절감됨 또한 multi Availability Zone 을 지원한다고 함 여기서 말하는 Redshift Managed Storage(RMS) 란, s3 를 기반으로 하는 스토리지를 말 하지만,무조건 s3 만 사용하는 건 아님 로컬 디스크(SSD) 도 사용함 근데 캐시로 사용함 즉, hot data 는 SSD 에 캐싱해여 빠르게 IO 하게 되고 cold data 는 S3 에 영구 저장하게 됨 multi Availability Zone 을 지원한다는 건 무슨 말일까? RMS (s3)에 저장되는 데이터는 여러 AZ 에 복제되어 있다는 말임 예를 들어서, RA3 노드를 사용하면 다음과 같은 AZ 세 곳에 각각의 compute node, storage(RMS) 가 분포하게 됨 - us-east-1a : compute node, RMS 복제본 (+leader node) - us-east-1b : RMS 복제본 - us-east-1c : RMS 복제본 쿼리는 compute node 에서 실행되고, 실제 데이터 파일은 RMS 에서 필요한 블록만 가져오게 됨 만약 1a 존에 장애가 발생하게 되면? compute node 와 RMS 복제본 하나를 잃어버리게 되지만 데이터는 나머지 복제본을 통해 복구 가능함 Redshift 가 나머지 존(us-east-1b)에 compute node 를 자동으로 새로 띄우고 1b, 2c 에 있는 복제본 데이터를 이용해서 쿼리를 실행하게 됨 이것으로 cluster 가 문제없이 복구! 여기서 compute node 는 반드시 하나의 AZ 에만 존재해야 함 multi AZ 지원은 오로지 RMS 에만 적용 위 예제처럼 leader node 와 compute node 들은 대개 같은 AZ 에 하나씩만 존재함 (comput node 는 전체 클러스터에서 딱 하나만 뜬다는 말이 아니라, 여러 compute nodes 가 뜨는데 각각 하나씩만 존재한다는 말) 게다가 놀랍게도 leader node 는 SFOP 가 아님 (=복제 불필요) leader node 는 stateless 이며, 저장하고 있는 메타데이터가 없음 (쿼리 실행에 필요한 데이터들은 모두 compute node 가 저장하고 있음) leader node 에 이슈가 발생해도 잠깐의 failover 타임만 있을 뿐, 다시 복구해서 사용 가능 We can restore data using another copy. Redshift automatically launches new compute nodes in the remaining zone. |
Redshift 기반으로 아래와 같은 모의 클러스터를 만들어 볼 수 있음 Redshift Cluster (analytics-prod) ├── Leader Node ├── Compute Node #1 (RA3) │ ├── slice 1 → sales 테이블 일부 │ ├── slice 2 → customers 일부 │ └── slice 3 → orders 일부 ├── Compute Node #2 (RA3) │ ├── slice 1 → sales 테이블 일부 │ ├── slice 2 → customers 일부 │ └── slice 3 → orders 일부 ├── Distribution key: user_id └── Sort key: order_date 슬라이스들이 각 테이블들의 일부를 저장하고 있는 점이 눈에 띔 Each slice stores a portion of each table. |
compute nodes 가 쿼리를 실행할 때는 compute nodes 내에 기본 탑재된 '커스텀 PostgreSQL' 엔진을 사용함 일반 PostgreSQL 이 아니라, Redshift만을 위해 커스텀 된 아예 새로운 PostgreSQL 분산 실행 엔진 일반 PostgreSQL 과 다른 점은 - row-store PostgreSQL과 다르게 columnar 저장 방식 - RDB 기능 일부 제거 (index 없음) - MPP 전용 기능 추가 (exchange, redistribution, parallel join 등) The engine pre-installed within the compute nodes. The differences from the original engine are as follows. Added MPP-specific features. |
compute nodes 의 가장 기본 실행 단위인 slice 에 대해 더 자세히 알아봄 slice 는 Redshift 병렬처리의 기본 단위이며, Compute node 내부의 “CPU/메모리 단위로 쪼갠 미니 실행 단위” 테이블을 row 단위로 나누는 개념도 맞고 Compute 자원을 나누는 개념도 맞음 즉, 두 가지 의미를 모두 가지고 있는 논리적 단위 slice 는, 병렬 처리(Parallel Processing)를 극대화하기 위해 존재함 (compute node 하나가 들고있는 여러 CPU 마다 하나의 slice를 할당해서 쿼리를 병렬로 실행) 각 Slice 를 미니 노드라고 생각해도 됨 각 Slice 는 자신만의 전용 CPU 스레드, 전용 메모리, 자신만의 데이터 블록 을 모두 갖고 쿼리를 실행하게 됨 각 slice는 자신에게 할당된 row를 독립적으로 처리함 It refers to execution units divided into CPU and memory units. : cpu 와 메모리 단위로 구분된 실행 단위 The concept of dividing tables into rows. Each slice processes its assigned row independently. 예를 들어, Compute Node 2개가 있고 각 Node에 Slice 2개가 있다고 하자 - Node 1 : Slice 1, Slice 2 - Node 2 : Slice 3, Slice 4 즉 전체적으로 4개의 slice가 있는 클러스터가 됨 그리고 1,000만 row 를 갖는 테이블이 이 Node 1, Node 2 에 저장되면, 아래와 같이 됨 (물론 distribution style 에 따라 저장되는 방식은 다르겠지만 쉬운 이해를 위해 그냥 골고루 나눠졌다고 가정) - Slice 1 : 250만 row - Slice 2 : 250만 row - Slice 3 : 250만 row - Slice 4 : 250만 row That is, it is a cluster consisting of a total of four slices. 즉 |
만약 다른 Slice 가 갖는 데이터를 사용해야하는 쿼리(join 등) 실행시, 데이터는 어떻게 어디로 이동될까? Redshift에서 join을 할 때 필요한 row가 같은 slice 에 없다면 leader node가 “redistribute” 또는 “broadcast” 명령을 내려서 다른 slice로 데이터를 이동시킴 어디로 이동시키느냐? 바로 compute node 의 메모리 및 로컬디스크(ssd) 메모리에 우선 저장하고, 메모리가 부족하면 disk 로 spill Redshift 에서 Join 하는 예를 들어봄 Redshift 내 저장된 테이블 A, B가 각 slice 1, slice 3 에 저장되어 있음 - A 테이블 : Node1 내 Slice1 에 저장되어 있음 - B 테이블 : Node2 내 Slice3 에 저장되어 있음 그리고 JOIN key가 다르게 분포되어 있음 Join 을 실행하면 아래와 같은 절차를 거치게 됨 1. Leader node → 쿼리 분석 2. Leader node → 실행 계획 전달 3. “redistribute” 필요 판단 (왜냐면 하나의 slice 에서 join 을 처리할 수 없기 때문) 4. Slice1의 일부 데이터를 Slice3로 이동. 노드 간 네트워크 비용이 소모 5. 이동한 데이터는 Slice3의 메모리 버퍼 또는 SSD 캐시에 저장 6. Slice3에서 join 쿼리 실행. (즉, A의 일부분 (받은 데이터) + B의 로컬 데이터 를 합쳐서 join 실행) 7. Slice 3의 join 결과를 leader node로 보냄 여기서 중요한 점은, Slice3 으로 이동된 데이터가 계속 Slice3 에 머물지 않음 이동된 데이터는 캐시로 취급하기 때문에, 쿼리 실행이 끝나면 삭제됨 The data does not remain in slice 3. Since the transferred data is treated as cache, it is deleted once the query execution is complete. |
cluster 크기를 두 가지 방법으로 resizing 할 수 있음. 1. elastic resizing compute nodes 의 수를 늘리거나 줄임. 혹은 노드 타입을 바꿔서(예를 들어 ds2 에서 ra3 로 변경) resizing 함 게다가 빠르게 수행됨 심지어 cluster 를 중단하지 않아도 됨 그럼 실행중이던 쿼리는 어떻게 되느냐? 일부는 성공하고 일부는 실패함 대개 해당 옵션을 통해 resizing 한다고 함 2. classic resizing elastic resizing 에 비해 resizing 하는 데 시간이 오래 걸림 elastic resizing 을 할 수 없을 때 선택하는 옵션임 별로 중요하지 않은가? 빠르게 훑기만 하고 지나감 |
Redshift 는 스냅샷 기능도 제공함 ㄷㄷ 클러스터 전체 데이터(테이블 단위가 아님)를 특정 시점에 backup 하는 기능이며, point-in-time backups 이라고 부름 Redshift 가 주기적으로 백업하며, 백업된 snapshot 은 s3 에 저장됨 저장된 snapshot 은 Redshift 가 관리함 추후 새로운 cluster 를 생성할 때, 백업해 둔 snapshot 기준으로 restore 가능함 snapshot 은 주기적으로 자동 처리하도록 만들거나, 수동으로 처리할 수 있음 snapshot 을 주기적으로 진행 할 때마다 매 번 전체 copy 를 저장하지 않음 처음 snapshot 생성시 전체 백업을 진행하지만 두번째 snapshot 부터는 증분(incremental) 데이터만 backup 함 따라서 생각보다 크기가 크지 않고, 처리 속도도 빠름 backup 은 RMS 기반으로 copy 를 만들기 때문에 cluster downtime 이 없고 빠르게 backup 처리됨 주로 새로운 ETL, table 배포 진행 전에 snapshot 으로 backup 을 하거나 다른 region 에 있는 cluster 들 간에 데이터를 공유하거나 테스트 환경을 만들 때 백업해 둔 snapshot 기반으로 새로운 cluster 생성하는 용도로 사용됨 혹은 보안 및 재해대비를 위해 백업해 둠 주기적으로 쌓이는 snapshot 의 기본 retention period 는 하루 수동으로 쌓은 snapshot 의 retention period 는 엔지니어가 선택 가능. 1일, 7일, 혹은 무기한. This feature backs up the entire cluster data at a specific point in time. The first snapshot creates a full backup, but subsequent snapshots only back up incremental data. From the second time on 두번째부터는 |
Vaccum 이라는 기능이 있음 - Redshift 테이블 내 데이터가 지워질 때, 지워진 데이터가 차지했던 공간이 바로 비게 되는게 아니라고 함 (삭제 마크만 붙어있음) - 그리고 데이터가 지워지고 추가되고 지워지고 추가되고 하면서 테이블 내 row 정렬이 망가지기도 한다고 함 (쿼리 성능 저하 요인) Vaccum delete 명령이 주기적으로 자동 수행되어 - 삭제된 데이터가 차지하고 있던 저장 공간을 되찾고 (reclaim space) - row 를 다시 정렬함(re-sort rows). 물론 이미 정렬되어있는 경우엔 정렬 안 함(threshold 95% 정렬되어있으면 정렬 안 함) The space occupied by deleted data is not immediately freed up; only a 'deletion flag' is added. The row alignment within the table could sometimes become distorted.(corruption) Factor that degrade query performance. Reclaims space marked with a deletion flag. If the table is sorted to at least 95% of the threshold, it is not sorted again. |
Materialized View 는 SQL 결과를 실제 저장소에 물리적으로 저장해두는 view임 따라서, materialized view 에 쿼리하면 즉시 결과가 반환되어 빠름 (일반적인 view 는 쿼리 할 때마다 원본 테이블을 다시 읽고 매번 계산하기 때문에 느림) Materialized View 는 자주 사용하는 복잡한 쿼리 결과를 미리 계산해서 캐싱해두는 view 라고 보면 됨 복잡하고 무거운 연산을 미리 해두기 때문에 자원을 절약하고 성능을 높일 수 있음 게다가 Incremental refresh 까지 지원함 Redshift 가 원본 테이블에 변경을 감지하면, 바뀐 파티션만 Incremental refresh 수행하여 MV 을 업데이트 함 MV 가 구체적으로 어디에 저장되나? Columnar Storage 로 Redshift 내부에 저장된다고 함 A materialized view can be thought of as a view that pre-calculates and caches the results of frequently used complex queries. Materialized View 만드는 쿼리 CREATE MATERIALIZED VIEW mv_daily_sales AUTO REFRESH YES AS SELECT store_id, date(order_time) AS order_date, SUM(amount) AS daily_sales FROM sales GROUP BY 1,2; 쿼리 실행되면 my_daily_sales 테이블(view)이 생성되고, 아래와 같이 쿼리 가능 SELECT * FROM mv_daily_sales; MV 는 BI 리포트나 대시보드에 사용하기 좋고, 무겁고 복잡한 쿼리 결과가 바로 필요할 때 사용하면 좋음 |
참고로 MV 가 아닌 일반 view는 아래와 같이 만듦 CREATE VIEW my_daily_sales AS SELECT * FROM sales; 이후에 select * from my_daily_sales 처럼 쿼리할 수 있는 view 가 생기게 되지만,, view 에 쿼리를 실행 할 때마다 원본 테이블을 읽고 매번 계산하게 됨 |
< Lake Formation >
Lake Formation 이란, DataLake(on S3) 에 저장된 데이터를 중앙에서 안전하게 관리하고 테이블, 컬럼 단위까지 권한을 제어하는 서비스임 S3, Glue, Athena, EMR 등 Data Lake 를 위한 서비스들을 함께 쓰면 데이터 접근 관리가 복잡해지는데 이걸 Lake Formation 이 단일 권한 시스템으로 정리해 줌 Lake Formation 이 DataLake 의 각 S3 path 접근 권한과 Glue Catalog 테이블 권한을 가져오면 이제 DataLake(S3), Athena, Glue 등의 접근 권한은 IAM role 이 아니라 LF 이 진행하게 됨 DataLake 의 테이블, 컬럼, 행 단위까지 접근 권한을 세분화하여 설정 가능 이렇게 설정한 LakeFormation 접근 권한은 Athena, Redshift spectrum, EMR, Glue Job 등 모두에게 적용됨 Using the Lake Formation service, we can control permissions down to the table and column level. |
데이터 엔지니어가 실제로 LF 으로 하는 일 - Data Lake 의 s3 경로의 읽기, 쓰기 권한을 Lake Formation 이 대신 관리하도록 설정 이렇게 해야 Lake Formation 이, Athena, EMR가 S3 에 접근하는 것을 통제할 수 있음 - Glue Catalog 에 등록된 테이블의 모든 권한(읽기, 쓰기, DML, DDL....)을 Lake Formation 으로 이관 이렇게 해야 Lake Formation 에서 누가 어떤 테이블의 컬럼에 접근하는지 통제할 수 있음l - 데이터 엔지니어가 직접 AD/SAML 기반 그룹과 LakeFormation 권한을 매핑할 수 있음 - 이후, Athena, EMR 등에서 Lake Formation 기반 권한으로 접근이 통제됨 Transfer all permissions for tables registered in the Glue catalog to Lake Formation. |
< EMR >
Elastic Map Reduce 하둡,스파크, 플링크 등 분산처리 빅데이터 프레임워크를 프로비저닝 하도록 도와주고 운영을 쉽게 만들어주는 서비스 Glue Job 도 Spark 를 실행할 수 있지만, Glue Job은 가벼운 ETL 처리에 쓰이고 좀 더 무거운, 그러니까 데이터 규모가 엄청 큰 ETL 처리 진행에는 EMR 을 사용함 |
on-premise 에서 사용하던 리소스들 (이를테면 Hive metastore) 를 EMR 로 옮겨서 그대로 사용 가능하다고 함 (Hive 가 EMR 내에 떠있는다는 전제겠지..?) Resources previously used on-premise can be migrated to EMR and used as-is. You can see the scene exactly as it appeared in the video. It assumes that Hive operates within EMR. |
EMR 을 구성하는 노드 종류 설명 : https://eyeballs.tistory.com/m/677 |
EMR 클러스터의 인스턴스 유형은 두 가지로 나뉨 - x86 based instance intel, amd cpu를 사용함 안정적이지만 비용이 높음 모든 lib 와 호환되기 떄문에, 복잡한 네이티브 라이브러리(혹은 구형 jar)가 필요할 때 선택함 m5.xlarge m5.2xlarge c5.xlarge c5.2xlarge r5.xlarge r5.2xlarge - graviton-based instance AWS 자체 설계한 Graviton (arm 기반) cpu 를 사용함 x86 과 비용하여 더 많은 코어를 제공하여 병렬성이 높아지고 spark job 성능이 더 좋아짐 네이티브 x86-only lib는 사용 불가 일반적인 spark, hadoop job 실행시 선택함 m6g.xlarge c7g.xlarge r6g.xlarge m7g.2xlarge It is stable but costly. It utilizes more CPU cores compared to x86. Therefore, parallelism is enhanced. |
참고로, EC2 인스턴스 이름으로 사양을 확인하는 방법은 아래와 같음 <인스턴스 패밀리><세대><옵션>.<사이즈> 인스턴스 패밀리 - 접두사를 통해 용도를 구분할 수 있음 m 이 붙으면 일반적인 용도. cpu, memory 균형있게 들어감 : m6g.large c 가 붙으면 cpu 연산 집중하는 용도 : c7.xlarge r 이 붙으면 memory 가 많이 필요한 작업용 : r5.xlarge i 가 붙으면 IO 성능이 필요한 작업용 : i5.large - 접미사를 통해 cpu 를 구분할 수 있음 g 가 붙으면 graviton 사용 : m6g.large, c7g.xlarge a 가 붙으면 amd(x86) 사용 : m5a.xlarge, c5a.large 안 붙어있으면 intel/amd x86 사용 : m5.xlarge 세대 - 대개 세대 숫자가 높을수록 신형이며, 성능과 비용이 비싸짐 사이즈 - 숫자가 크면 cpu, memory 가 커지고, 각 사이즈별로 2배씩 차이가 있음 large : 기본 xlarge : large 의 2배 2xlarge : xlarge 의 2배 4xlarge : 2xlarge 의 2배 8xlarge : 4xlarge 의 2배 Here's how to check the specifications using the instance name: The higher the number, the greater the cost and performance. The larger the number, the greater the CPU and memory. Each size differs by a factor of two. xlarge has twice the resources of large. 2xlarge has four times the resources of large. 4xlarge has eight times the resources of large. Reduce the CPU of Cluster A by 3 times, A 클러스터 cpu는 3배 줄이고, and increase the memory of Cluster B by 2 times. B 클러스터 memory 는 2배 늘리자. factor : 배율
multiple : 배수
|
Cluster 타입은 두 가지 존재함 - Transient Cluster 일회성 클러스터 전 회사에서, airflow 에 의해 주기적으로 실행되어 batch 처리하고 job 이 끝나면 terminated 되던 그 클러스터 - Long Running Cluster 계속 실행되는 클러스터 spark streaming 을 실행하는 등 계속 실행되어야 하는 job 실행시 사용되는 클러스터 Transient clusters are disposable. |
cluster 의 scaling 은 수동, 자동 둘 다 가능함 수동으로 직접 cluster 의 크기를 줄이거나 늘릴 수 있음 EMR 콘솔에서 인스턴스 그룹의 노드 수를 변경하면 됨 자동으로 scaling 하는 방법은 두 가지가 존재함 - Amazon EMR Managed Scaling : 추천되는 방법 AWS 가 작업량(cluster metrics)를 살펴보고 자동으로 scale-out/in 해줌 최대, 최소 vCPUs capacity 만 설정해두면 됨 예를 들어, 어떤 EMR 클러스터에서 배치잡이 진행되는 중에 AWS 가 worker 개수를 10개 늘림 배치잡이 종료된 후에 worker 개수를 3개로 축소함 자동으로 진행되기 때문에 운영 비용이 줄어들지만 특정 조건(예를 들어 cpu 가 90퍼 이상 사용되면 scale-out 하라)에 스케일링 되도록 설정하는 것은 불가능함 - Custom Automatic Scaling : CPU, YARN Pending Memory, HDFS 사용률 등 CloudWatch 지표 기반으로 조건을 직접 작성 어떤 cloudwatch metric 에 의해 scale-out/in 될지 설정해야 함 예를 들어 cpu 90퍼 지속이 10분 이상이면 노드를 3개 늘리고 20퍼 이하면 노드를 3개 줄임 설정이 복잡하지만 세밀하게 조정 가능 You can change the number of nodes in an instance group from the EMR console. During the batch job execution, AWS increases the number of workers by 10. Management costs are reduced. If CPU usage remains above 90% for 10 minutes or longer, increase the number of nodes by 3. If CPU usage falls below 20%, decrease the number of nodes by 3. |
IAM : https://eyeballs.tistory.com/580
Network : https://eyeballs.tistory.com/582
'눈가락' 카테고리의 다른 글
| [Git] 내가 보려고 만든 git 명령어들 (0) | 2025.04.08 |
|---|---|
| [AWS] EMR, Athena, Glue, Lake Formation, DMS 필기 (0) | 2024.07.03 |
| [AWS EMR] step 추가하여 shell command 실행하는 방법 (0) | 2024.05.07 |
| Gradle 공부 필기 (0) | 2024.04.01 |
| [JAVA] enum 간단한 샘플 코드 (0) | 2023.08.20 |