Amazon Redshift আর Spectrum

এই লেসন শেষে তুমি পারবে

• Data warehouse কীসের জন্য, আর কেন Redshift (OLAP) আর RDS বা Aurora (OLTP) একটার জায়গায় আরেকটা চলে না, বুঝিয়ে বলতে।
• Redshift একটা query-র উত্তর কীভাবে দেয় তা বলতে: columnar storage, compression আর zone map, একটা leader node যে plan করে আর ফলাফল জোড়া দেয়, compute node আর slice যারা একসাথে কাজ করে (MPP), আর distribution key ও sort key যেগুলো একে দ্রুত বা ধীর বানায়।
• Provisioned cluster (RA3, reserved node, pause আর resume) আর Redshift Serverless (RPU, প্রতি সেকেন্ডের হিসাবে বিল)-এর মধ্যে বেছে নিতে, আর কোন node type বিদায় নিচ্ছে তা জানতে।
• ঠিক পথে data load করতে: S3 হয়ে Data Firehose, IAM role দিয়ে S3 থেকে একসাথে COPY, JDBC দিয়ে বড় batch-এ insert, Enhanced VPC Routing, আর zero-ETL integration।
• একটা warehouse সুরক্ষিত রাখতে: automated আর manual snapshot, retention, নতুন cluster-এ restore, KMS snapshot copy grant সহ cross-Region snapshot copy, Multi-AZ আর relocation।
• Load না করেই S3-এর data query করতে Redshift Spectrum ব্যবহার করতে, আর পরীক্ষার প্রশ্নে Athena, Redshift আর Spectrum-এর মধ্যে বেছে নিতে।

#Data warehouse কেন লাগে

Lesson 16.1-এ database-কে দুই ভাগে ভাগ করেছিলাম। OLTP হলো একটা app-এর প্রতিদিনের কাজ: order দেওয়া, টাকা পাঠানো, অসংখ্য ছোট transaction, প্রত্যেকটা হাতে গোনা কয়েকটা row ছোঁয়। OLAP হলো ইতিহাস নিয়ে বড় প্রশ্ন: তিন বছরের জেলা আর মাস ধরে বিক্রি, একটা query পড়ে কোটি কোটি row, কিন্তু মাত্র কয়েকটা column। দ্বিতীয় ধরনের কাজ প্রথম ধরনের database-এ চালালে সবার জন্য app ধীর হয়ে যায়। এই লেসন দ্বিতীয় দুনিয়ার জন্য বানানো AWS service নিয়ে।

Amazon Redshift হলো AWS-এর fully managed, petabyte মাপের data warehouse। নানা জায়গা থেকে data এনে relational table-এ load করো, আর analyst, dashboard আর BI tool সারাদিন তাকে SQL-এ প্রশ্ন করে। এটা OLAP engine, OLTP না।

#Redshift আসলে কী

Note আর slide কয়েক লাইনে Redshift-এর পরিচয় দেয়। লাইনগুলো আর তাদের আসল মানে দেখে নাও।

• Fully managed: machine দেওয়া, patch করা, বিকল node বদলানো, backup নেওয়া, cluster নজরে রাখা, সব AWS করে।
• PostgreSQL থেকে জন্ম, কিন্তু OLTP-র জন্য না: Redshift শুরু হয়েছিল PostgreSQL থেকে, তাই এর SQL আর client driver চেনা লাগে (JDBC, PostgreSQL-এর protocol), কিন্তু ভেতরের engine পুরো আলাদা। এটা বানানো বড় scan আর join-এর জন্য, এক row-এর transaction-এর জন্য না।
• Columnar storage আর MPP (massively parallel processing): data রাখা হয় column ধরে, compress করে, আর প্রতিটা query ভাগ হয়ে যায় অনেকগুলো node-এ, যারা একই সময়ে কাজ করে। Analytics-এ Redshift দ্রুত হওয়ার পুরো কারণ এই দুটো ধারণা। পরের দুটো অংশে এগুলো দেখবে।
• Petabyte মাপ: একটা RA3 cluster-এ ১৬ PB পর্যন্ত managed storage রাখা যায়।
• SQL interface: analyst-রা সাধারণ SQL লেখেন; Amazon QuickSight (lesson 17.5) বা Tableau-র মতো BI tool সরাসরি এর সাথে connect হয়।
• দুই রকম ব্যবস্থা: একটা provisioned cluster, যার মাপ তুমি ঠিক করো, অথবা Redshift Serverless, যে নিজের মাপ নিজে ঠিক করে।

#Columnar storage

Row store, যেমন RDS, প্রতিটা row-এর column-গুলো disk-এ পাশাপাশি রাখে: পুরো একটা order একবারে পড়তে বা লিখতে একদম ঠিক। Column store প্রতিটা column একসাথে রাখে: সব তারিখ এক জায়গায়, সব amount আরেক জায়গায়। এর তিনটা ফল:

1. ৫০টা column-এর মধ্যে ২টা যে query-র লাগে, সে শুধু ওই ২টাই পড়ে।
2. একটা column-এ একই রকম মান থাকে (তারিখের পাশে তারিখ), তাই খুব ভালো compress হয়, প্রায়ই কয়েক গুণ ছোট, মানে পড়ার জিনিস কম।
3. প্রতিটা 1 MB block-এর সর্বনিম্ন আর সর্বোচ্চ মান Redshift মনে রাখে, এর নাম zone map। Table যদি তারিখ ধরে সাজানো থাকে (sort key), অক্টোবরের query অক্টোবরের বাইরের তারিখের প্রতিটা block না পড়েই বাদ দেয়।

দাম দিতে হয় এখানে: একটা পুরো row আনতে প্রতিটা column-এ যেতে হয়, আর একটা row বদলালে block আবার লিখতে হয়। এই কারণে Redshift OLTP-তে খারাপ। নিজে চেষ্টা করে দেখো:

#Leader node আর compute node

একটা provisioned cluster-এ থাকে একটা leader node আর এক বা একাধিক compute node।

• Leader node হলো cluster-এর endpoint। Client-রা JDBC বা PostgreSQL driver দিয়ে এর সাথেই connect করে। সে প্রতিটা query পড়ে বোঝে, execution plan বানায়, compile করে, compute node-দের পাঠায়, আর তাদের আংশিক ফলাফল জোড়া দিয়ে চূড়ান্ত উত্তর বানায়। Table-এর কোনো data সে রাখে না। এর জন্য আলাদা টাকাও লাগে না।
• Compute node data রাখে আর plan চালায়। প্রতিটা node কয়েকটা slice-এ ভাগ করা, আর প্রতিটা slice প্রতিটা table-এর একটা ভাগের মালিক, সেই ভাগে বাকিদের সাথে একসাথে কাজ করে। Node বাড়ালে slice বাড়ে, তাই একই query-তে প্রতি slice-এর কাজ কমে।
• Single-node cluster-এ একটা machine-ই দুই কাজ করে; test-এর জন্য চলে, production-এর জন্য সুপারিশ করা হয় না।

Row-গুলো slice-এ কীভাবে ছড়ানো হবে, সেটা distribution style: AUTO (Redshift নিজে ঠিক করে, এটাই default), EVEN (পালা করে সমানভাবে), KEY (একটা column-এর একই মানের row একই slice-এ যায়, তাই ওই column ধরে join নিজের node-এই হয়), অথবা ALL (ছোট একটা table-এর পুরো copy প্রতিটা node-এ)। KEY ভুল বাছলে হয় skew: একটা node-এর কাছে বেশিরভাগ data, আর পুরো query তার জন্য অপেক্ষা করে।

এই স্তরে আরও কয়েকটা জিনিস জানা দরকার: workload management (WLM) query-গুলোকে আলাদা queue-তে রাখে, যাতে একটা বিশাল report ছোট dashboard query-গুলোকে আটকে না দেয়; concurrency scaling একসাথে অনেক user query করলে সাময়িক বাড়তি capacity যোগ করে; data sharing দিয়ে আরেকটা cluster বা account copy না করেই চালু data পড়তে পারে; আর result caching একই query আবার এলে memory থেকে উত্তর দেয়।

#Provisioned নাকি Serverless

#Provisioned cluster

তুমি আগে থেকে node type আর node-এর সংখ্যা বেছে নাও, আর node-ঘণ্টা ধরে টাকা দাও। স্থির, আন্দাজ করা যায় এমন ব্যবহারে এক বা তিন বছরের জন্য reserved node কিনলে অনেক ছাড় পাও (EC2 Reserved Instance-এর মতো, lesson 4.4)। Cluster pause করা যায় (তখন শুধু storage-এর টাকা লাগে), আর resize করা যায়।

RA3-তে তুমি কতটা data রাখবে তা local disk-এ আটকে নেই: যে block কম ব্যবহার হয় সেগুলো শুধু S3-এ থাকে, আর দুই জায়গাতেই storage-এর দাম একই। এজন্যই slide আর note বলতে পারে “petabyte পর্যন্ত বাড়ে”।

#Redshift Serverless

Redshift Serverless একই engine চালায়, কিন্তু মাপার মতো কোনো cluster নেই। তুমি বানাও একটা namespace (database, user আর data) আর একটা workgroup (compute)। Capacity মাপা হয় Redshift Processing Unit-এ (RPU, প্রতিটায় 16 GB memory): একটা base capacity ঠিক করো (default ১২৮ RPU, ৪ থেকে ৫১২ পর্যন্ত, কিছু Region-এ ১,০২৪), আর ভারী query এলে Serverless বাড়ে, অলস থাকলে কমে। টাকা দাও RPU-ঘণ্টা ধরে, প্রতি সেকেন্ডের হিসাবে, কমপক্ষে ৬০ সেকেন্ড, শুধু যখন query চলে, তার সাথে managed storage।

#Data ঢোকানো

Slide-এর নিয়মটা সোজা: ছোট insert-এর চেয়ে বড় insert অনেক ভালো। Redshift বানানোই হয়েছে বড় বড় batch গিলে ফেলার জন্য। চেনা পথ চারটা।

1. Amazon Data Firehose → S3 → COPY। Firehose streaming record জমায়, file বানিয়ে একটা S3 bucket-এ লেখে, তারপর তোমার হয়ে cluster-এ COPY চালায় (lesson 13.6)। প্রায় real time: কয়েক মিনিট পিছিয়ে (buffer interval, default ৩০০ সেকেন্ড, ০ থেকে ৯০০-র মধ্যে বদলানো যায়, তার ওপর COPY-এর সময়)। Lesson 13.6-এ যেমন দেখেছ, Firehose cluster-এ পৌঁছায় তোমার VPC-র বাইরে থেকে।

2. S3 থেকে COPY। Load করার সবচেয়ে দ্রুত পথ। একটা command একটা prefix-এর নিচের সব file load করে, একসাথে, প্রতিটা slice কিছু file নিয়ে। বড় data-কে কাছাকাছি মাপের কয়েকটা file-এ ভাগ করো, সংখ্যাটা slice-এর গুণিতক হলে সবচেয়ে ভালো, compress করা (gzip, bzip2, zstd…) বা columnar (Parquet, ORC)। S3 পড়ার অনুমতি আসে cluster-এর সাথে লাগানো একটা IAM role থেকে:

   copy sales
   from 's3://shop-staging-example/sales/2026/10/'
   iam_role 'arn:aws:iam::111122223333:role/RedshiftCopyRole'
   format as parquet;
   

3. JDBC দিয়ে app থেকে insert, যেমন EC2 থেকে। চলে, কিন্তু batch করে লেখো: এক transaction-এ হাজার হাজার row-এর একটা insert, কখনো এক statement-এ এক row না। বড় পরিমাণ হলে file S3-এ লেখো আর COPY করো।

4. Zero-ETL integration। Aurora MySQL আর PostgreSQL, RDS for MySQL, PostgreSQL আর Oracle, আর DynamoDB কয়েক সেকেন্ডের মধ্যে অবিরাম Redshift-এ data পাঠাতে পারে, কোনো pipeline বানাতে হয় না (lesson 7.3)। পরীক্ষার সূত্র: “Aurora/DynamoDB-র data নিয়ে Redshift-এ analytics, ETL বানানো ছাড়া”।

Enhanced VPC Routing। সাধারণত cluster আর S3-এর মধ্যে COPY আর UNLOAD-এর traffic তোমার VPC-র বাইরে দিয়ে যায়। Enhanced VPC Routing চালু করলে Redshift সেটা জোর করে তোমার VPC-র ভেতর দিয়ে পাঠায়, তাই security group, network ACL, VPC endpoint policy আর VPC Flow Logs সব খাটে। তখন VPC-তে S3-এ যাওয়ার একটা পথ থাকতেই হবে: একটা S3 gateway endpoint (lesson 22.2), বা NAT বা internet gateway; নইলে load fail করে।

#Snapshot আর disaster recovery

Redshift নিজের backup নেয় snapshot দিয়ে: নির্দিষ্ট মুহূর্তের, incremental backup (শুধু বদলানো block রাখা হয়), রাখা থাকে Redshift-এর নিজের সামলানো S3-এ। ওই bucket তোমার S3 console-এ দেখা যায় না।

Restore সবসময় একটা নতুন cluster বানায়; সব block আসার আগেই query শুরু করা যায়। Serverless-এ recovery point নেওয়া হয় প্রতি ৩০ মিনিটে (বা প্রতি node-এ ৫ GB বদলালে), থাকে ২৪ ঘণ্টা, আর manual snapshot-ও নিতে পারো।

Redshift-এর DR-এর চিরচেনা উত্তর cross-Region snapshot copy। চালু করো, একটা destination Region বাছো, আর প্রতিটা automated আর manual snapshot আপনা থেকেই সেখানে copy হয়। Copy হওয়া automated snapshot destination-এ default ৭ দিন থাকে (বদলানো যায়)। Source Region বিকল হলে destination Region-এ একটা নতুন cluster restore করো (কৌশলগুলো lesson 23.1-এ)।

KMS দিয়ে encrypted cluster হলে copy-র জন্য আরেকটা জিনিস লাগে। KMS key Region-ভিত্তিক (lesson 21.2), তাই destination Region-এ একটা snapshot copy grant বানাতে হয়, যেটা Redshift-কে সেখানকার একটা customer managed key ব্যবহার করতে দেয়, আর copy চালু করার সময় সেই grant বেছে নিতে হয়।

#Multi-AZ আর relocation

একটা provisioned cluster সাধারণত চলে একটা Availability Zone-এ: তার node-দের নিজেদের মধ্যে দ্রুত যোগাযোগ লাগে। RA3-তে তোমার data এমনিতেই managed storage-এ নিরাপদ, কিন্তু ওই AZ বন্ধ হলে compute শেষ।

• Cluster relocation (RA3): AZ-এ সমস্যা হলে Redshift cluster-কে একই Region-এর আরেকটা AZ-এ সরিয়ে নেয়, endpoint একই থাকে। কয়েক মিনিট বন্ধ থাকে।
• Multi-AZ deployment (RA3, ২০২৩-এর শেষ থেকে সবার জন্য চালু): Redshift দুটো AZ-এ একই সংখ্যক node রাখে, দুটোই চালু, একটা endpoint-এর পেছনে, একই managed storage পড়ে। একটা AZ গেলে আরেকটা কাজ চালিয়ে যায়। SLA ৯৯.৯% থেকে বেড়ে ৯৯.৯৯% হয়। Compute-এর খরচ দ্বিগুণ। Slide-এর “কিছু cluster-এর জন্য Multi-AZ mode” কথাটার মানে ঠিক এটাই: শুধু RA3।

কোনোটাই পুরো Region বিকল হলে বাঁচায় না; তার জন্য এখনো cross-Region snapshot copy।

#Redshift Spectrum

সাধারণত Redshift শুধু সেই data query করতে পারে যেটা তার ভেতরে load করা। Redshift Spectrum দিয়ে একটা cluster S3-এ আগে থেকেই রাখা data, load না করেই query করতে পারে, এমনকি cluster-এর ভেতরের table-এর সাথে join-ও করতে পারে।

কীভাবে কাজ করে: তুমি একটা external schema বানাও যেটা একটা data catalog-এর দিকে তাকিয়ে থাকে, সাধারণত AWS Glue Data Catalog (Athena-র catalog বা Apache Hive metastore-ও চলে; lesson 17.6)। Leader query plan করে, আর S3-এর অংশটা দেয় Spectrum layer-কে: AWS-এর চালানো হাজার হাজার node, তোমার cluster-এর বাইরে, যারা একসাথে file পড়ে, filter আর aggregate করে, শুধু ছোট ফলাফল ফেরত দেয়। টাকা দাও S3-এ যত terabyte scan হলো সেই ধরে (প্রতি TB-তে প্রায় ৫ USD, Athena-র মতো), তাই Parquet আর partition এখানেও 17.1-এর মতোই জরুরি।

• Query শুরু করতে একটা Redshift cluster লাগবেই (বা Serverless workgroup)। Spectrum Redshift-এর একটা feature, আলাদা কোনো service না।
• RA3 আর DC2 cluster-এ S3-এর data cluster-এর একই Region-এ থাকতে হবে।
• External table মূলত পড়ার জন্য: এর row update বা delete করা যায় না।

চিরচেনা ব্যবহার হলো গরম আর ঠান্ডা data: শেষ ১২ মাসের বিক্রি Redshift-এ, দ্রুত dashboard-এর জন্য; তার আগের ৫ বছর S3-এ Parquet হিসেবে, সস্তায়; আর একটা query দুটোই ছুঁতে পারে।

#Athena, Redshift নাকি Spectrum?

Note-এর exam trick, মানে একই রেখে: মাঝেমধ্যে ad-hoc query → Athena; বিশাল data-য় জটিল OLAP, reporting আর বারবার ভারী query → Redshift; “Redshift cluster-এ load না করে S3-এর data query” → Redshift Spectrum।

#কোথায় গোলমাল হয়

#System design-এ Redshift

• OLTP আর OLAP আলাদা রাখো। App লেখে Aurora বা DynamoDB-তে; Redshift পায় একটা copy, zero-ETL, Firehose বা batch COPY দিয়ে।
• আগে S3-এ নামাও। কাঁচা file থাকে S3 data lake-এ; গরম data Redshift-এ load হয়, ঠান্ডা data Spectrum বা Athena দিয়ে query হয়। S3 থাকে সস্তা, টেকসই আসল রেকর্ড।
• প্রশ্ন মাথায় রেখে table বানাও: সাধারণ filter-এর জন্য sort key, বড় join-এর জন্য distribution key, ছোট dimension table-এ ALL, অথবা AUTO-কে ঠিক করতে দাও।
• ধরন বুঝে মাপ ঠিক করো: সবসময়ের ভারী কাজে reserved node সহ provisioned, হঠাৎ ভিড় বা মাঝেমধ্যে কাজে Serverless।
• দুই রকম বিপদের পরিকল্পনা: AZ-এর জন্য Multi-AZ (বা relocation), Region-এর জন্য cross-Region snapshot copy, encrypted হলে KMS grant সহ।
• তালা দাও: private subnet, security group, নিয়ন্ত্রিত data-র জন্য Enhanced VPC Routing, at rest KMS encryption, in transit TLS, COPY আর UNLOAD-এর জন্য IAM role, S3 বা CloudWatch-এ audit logging।
• চোখে দেখাও: ওপরে dashboard-এর জন্য QuickSight (lesson 17.5); IoT device থেকে dashboard পর্যন্ত পুরো pipeline আছে lesson 17.8-এ।

#নিজে করে দেখো

এই command-গুলো টাকা লাগে এমন resource বানায়। Region ap-southeast-1; output ছোট করে দেখানো। শেষে সব মুছে ফেলো।

#ছোট একটা provisioned cluster

aws redshift create-cluster \
  --cluster-identifier shop-dw \
  --node-type ra3.large --number-of-nodes 2 \
  --master-username admin --manage-master-password \
  --iam-roles arn:aws:iam::111122223333:role/RedshiftCopyRole \
  --encrypted --enhanced-vpc-routing \
  --cluster-subnet-group-name private-dw
#   "ClusterStatus": "creating", "NodeType": "ra3.large", "NumberOfNodes": 2,
#   "EnhancedVpcRouting": true, "AutomatedSnapshotRetentionPeriod": 1

aws redshift describe-clusters --cluster-identifier shop-dw \
  --query 'Clusters[0].[ClusterStatus,Endpoint.Address]'
#   [ "available", "shop-dw.c1abcxyz.ap-southeast-1.redshift.amazonaws.com" ]

#Load আর query

create table sales (
  order_id   bigint,
  order_date date sortkey,
  district   varchar(32),
  amount     decimal(12,2)
) diststyle auto;

copy sales
from 's3://shop-staging-example/sales/2026/10/'
iam_role 'arn:aws:iam::111122223333:role/RedshiftCopyRole'
format as parquet;
-- INFO: Load into table 'sales' completed, 48211906 record(s) loaded successfully.

select district, sum(amount) from sales
where order_date >= '2026-10-01' group by district order by 2 desc limit 3;
--  district  |     sum
--  Dhaka     | 912337410.50
--  Chattogram| 301442119.00
--  Gazipur   | 118902337.75

#S3-এর ওপর Spectrum

create external schema lake
from data catalog database 'clickstream'
iam_role 'arn:aws:iam::111122223333:role/RedshiftCopyRole'
create external database if not exists;

select s.segment, count(*)
from lake.clicks c join customers s on c.customer_id = s.customer_id
where c.year = 2023 and c.month = 10
group by s.segment;

#Snapshot আর DR

aws redshift modify-cluster --cluster-identifier shop-dw \
  --automated-snapshot-retention-period 7

aws redshift create-cluster-snapshot \
  --cluster-identifier shop-dw --snapshot-identifier before-schema-change
#   "Status": "creating", "SnapshotType": "manual"

# Destination Region-এ: সেখানকার একটা KMS key-এর grant
aws redshift create-snapshot-copy-grant --region ap-south-1 \
  --snapshot-copy-grant-name dw-mumbai-grant \
  --kms-key-id arn:aws:kms:ap-south-1:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab

aws redshift enable-snapshot-copy --cluster-identifier shop-dw \
  --destination-region ap-south-1 --retention-period 7 \
  --snapshot-copy-grant-name dw-mumbai-grant
#   "ClusterSnapshotCopyStatus": { "DestinationRegion": "ap-south-1", "RetentionPeriod": 7 }

# DR মহড়া: copy হওয়া snapshot থেকে Mumbai-তে restore
aws redshift restore-from-cluster-snapshot --region ap-south-1 \
  --cluster-identifier shop-dw-dr --snapshot-identifier copy:shop-dw-2026-10-30-06-00

#Serverless পথে

aws redshift-serverless create-namespace --namespace-name shop
aws redshift-serverless create-workgroup --workgroup-name shop-wg \
  --namespace-name shop --base-capacity 8 \
  --subnet-ids subnet-0abc1234 subnet-0def5678 subnet-0aaa9999
#   "workgroup": { "baseCapacity": 8, "status": "CREATING", ... }

শেষে মুছে ফেলো aws redshift delete-cluster --cluster-identifier shop-dw --skip-final-cluster-snapshot, disable-snapshot-copy, delete-cluster-snapshot, আর aws redshift-serverless delete-workgroup / delete-namespace দিয়ে।

#সারসংক্ষেপ

মূল কথাগুলো

• Redshift = fully managed OLAP data warehouse, PostgreSQL থেকে জন্ম কিন্তু OLTP-র জন্য না; SQL interface; QuickSight-এর মতো BI tool এর সাথে connect হয়।
• Columnar storage (শুধু দরকারি column পড়া, জোরালো compression, sort key সহ zone map) আর MPP একে দ্রুত বানায়। চিরাচরিত index নেই।
• Leader node plan করে আর জোড়া দেয় (এটাই endpoint); slice-ওয়ালা compute node data রাখে আর একসাথে plan চালায়। Distribution AUTO, EVEN, KEY বা ALL; খারাপ key মানে skew।
• Provisioned (managed storage সহ RA3, reserved node, pause/resize; DC2 বিদায় নিচ্ছে, RG নতুন) বনাম Serverless (RPU, প্রতি সেকেন্ডের বিল, কমপক্ষে ৬০ সেকেন্ড)।
• বড় batch-এ load: Firehose → S3 → COPY; IAM role দিয়ে S3 থেকে একসাথে COPY; batch করা JDBC insert; Aurora, RDS, DynamoDB থেকে zero-ETL। Enhanced VPC Routing COPY/UNLOAD-কে VPC-র ভেতর দিয়ে পাঠায়, তখন S3 endpoint বা NAT লাগে।
• Snapshot: incremental, Redshift-এর সামলানো S3-এ; automated প্রতি ~৮ ঘণ্টা / প্রতি node-এ ৫ GB / schedule, থাকে ১–৩৫ দিন (default ১); manual থাকে না মোছা পর্যন্ত; restore = নতুন cluster।
• DR: cross-Region snapshot copy (copy হওয়া automated default ৭ দিন থাকে); encrypted cluster-এ destination-এ snapshot copy grant লাগে। AZ বিকলের জন্য Multi-AZ (RA3) বা relocation।
• Spectrum: load না করে S3 query, চালু cluster লাগে, হাজারো Spectrum node, Glue Data Catalog, একই Region, প্রতি TB scan-এ টাকা।
• পরীক্ষা: S3-এ ad-hoc → Athena; বারবার ভারী BI/OLAP → Redshift; Redshift থেকে load না করে S3 → Spectrum।

নিজেকে যাচাই করো: Amazon Redshift আর Spectrum৩২টি প্রশ্ন