Amazon Athena

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

• Amazon Athena কী, বুঝিয়ে বলতে: একটা serverless query service, যেটা S3-এর file-এর ওপর সরাসরি সাধারণ SQL চালায়; কোনো cluster চালাতে হয় না, কোনো ডেটা load করতে হয় না, আর ভেতরে আছে open-source Trino আর Presto engine।
• একটা query কীভাবে চলে, বলতে: AWS Glue Data Catalog-এ table-এর বর্ণনা, S3 থেকে একসাথে অনেক file পড়া, result আবার S3-এ লেখা, আর ওপরে console, JDBC ও ODBC driver আর QuickSight-এর মতো tool।
• একটা query কতটা ডেটা scan করে তা দেখে খরচ আন্দাজ করতে (us-east-1-এ TB-প্রতি ৫ USD, প্রতি query-তে কমপক্ষে 10 MB), আর কোন query-র টাকা লাগে কোনটার লাগে না, বলতে।
• চারটা চেনা কৌশলে খরচ আর সময় কমাতে: columnar format (Parquet, ORC), compression, partition আর বড় file; আর Glue job বা CTAS statement দিয়ে ডেটা convert করতে।
• Federated Query দিয়ে Lambda-তে চলা data source connector-এর মাধ্যমে S3-এর সাথে RDS, DynamoDB আর অন্য source join করতে, আর এর সীমাগুলো জানতে।
• Workgroup দিয়ে খরচ আর access সামলাতে (per-query limit, workgroup alert, result reuse, capacity reservation), আর Athena, Redshift আর Redshift Spectrum-এর মধ্যে ঠিকটা বাছতে।

#Athena কেন: file যেখানে আছে, প্রশ্ন সেখানেই করো

অধ্যায় ১৭-এর বিষয় data আর analytics: যেসব service বিশাল পরিমাণ ডেটা জমা রাখে, process করে, খোঁজে আর চার্টে দেখায়। SAA পরীক্ষায় এগুলো থেকে বেশ কয়েকটা scenario-ভিত্তিক প্রশ্ন আসে, আর প্রায় প্রতিটা উত্তরের শুরু একই জায়গা থেকে: ডেটা আগে থেকেই S3-এ বসে আছে। এই লেসন সেই ডেটাকে প্রশ্ন করার সবচেয়ে সহজ উপায় নিয়ে।

#সমস্যাটা কী

ঢাকার একটা e-commerce shop প্রতিটা page দেখা, প্রতিটা search আর প্রতিটা order S3-এ লিখে রাখে: website-এর clickstream, load balancer-এর access log, আর প্রতিদিনের order-এর একটা export। এক বছর পরে file জমে কয়েক terabyte। সোমবার সকালে marketing-এর প্রধান জানতে চান: “গত ঈদের সপ্তাহে চট্টগ্রাম থেকে কতগুলো order এসেছে, আর কোন বিজ্ঞাপন campaign থেকে?”

পুরোনো নিয়মে আগে file-গুলো একটা database বা data warehouse-এ load করতে হতো: table বানাও, ঘণ্টার পর ঘণ্টা import চালাও, একটা server সারাক্ষণ চালু রাখো। একবারের একটা প্রশ্নের জন্য এটা অনেক বেশি ঝামেলা। Analyst আসলে চায় file-গুলোর দিকে সরাসরি SQL তাক করতে, আর কয়েক সেকেন্ডে উত্তর পেতে।

#Athena জিনিসটা কী

Amazon Athena হলো একটা serverless interactive query service, যেটা standard SQL দিয়ে Amazon S3-এ রাখা ডেটা বিশ্লেষণ করে:

• Serverless। কোনো cluster বানাতে, তার মাপ ঠিক করতে, patch করতে বা বন্ধ করতে হয় না। Console খোলো (বা API call করো) আর query চালাও; ওই query-র জন্য compute AWS দেয়, কাজ শেষে সরিয়েও নেয়।
• Load করার ঝামেলা নেই। ডেটা S3-এ নিজের file-এই থাকে। তুমি একবার file-গুলোকে একটা table হিসেবে বর্ণনা করো (column, type, format, S3 location), আর Athena query-র সময় file পড়ে নেয়। একে বলে schema on read।
• সাধারণ SQL। Athena-র engine বানানো হয়েছে open-source Trino আর Presto নামের distributed SQL engine-এর ওপর (slide-এ লেখা “built on Presto”; Athena engine version 3-এর ভিত্তি Trino)। SELECT, JOIN, GROUP BY, window function, আর JSON, array, map ও geospatial ডেটার জন্য নানা function সবই পাবে।
• অনেক format। CSV আর অন্যান্য delimited text, JSON, ORC, Avro আর Parquet; সাথে log format (যেমন CloudTrail, ALB আর VPC Flow Logs) তৈরি করা table definition দিয়ে, আর Apache Iceberg-এর মতো open table format।
• Query ধরে টাকা। Server-এর জন্য না, টাকা দাও প্রতিটা query যতটা ডেটা scan করে তার জন্য। দুই query-র মাঝে কিছু চলে না, তাই মাঝের সময়ের কোনো bill নেই।

#একটা query কীভাবে চলে

#কোন কোন অংশ

#ধাপে ধাপে

1. File-গুলোর বর্ণনা একবার লিখে রাখো

   Data Catalog-এ একটা database আর একটা table বানাও, যেটা S3-এর prefix দেখিয়ে দেয় আর বলে দেয় file কীভাবে পড়তে হবে। Table drop করলে শুধু এই বর্ণনাটা মোছে; S3-এর file যেমন ছিল তেমনই থাকে।

2. SQL চালাও

   Query আসে console, API call, JDBC বা ODBC driver, কিংবা QuickSight থেকে। Athena তোমার IAM permission যাচাই করে, আর catalog-এ table-টা খুঁজে নেয়।

3. যেটুকু দরকার শুধু সেটুকু পড়ো

   কোন partition আর কোন file মেলে, Athena সেটা বের করে, আর অনেকগুলো worker একসাথে S3 থেকে সেগুলো পড়ে। Columnar file হলে শুধু চাওয়া column-গুলো পড়ে। পড়া প্রতিটা byte গোনা হয়।

4. Result ফেরত দাও আর জমা রাখো

   Result client-এর কাছে ফেরত যায়, আর S3-এর result location-এ জমা থাকে, যেখান থেকে অন্য tool (বা পরে download) ব্যবহার করতে পারে। বড় result যেকোনো format-এ লেখা যায় UNLOAD দিয়ে।

Athena S3 পড়ে যে query চালায় তার permission নিয়ে। যে মানুষ বা role query চালায়, তার লাগবে Athena-র নিজের অনুমতি, Glue catalog-এর অনুমতি (glue:GetTable, glue:GetPartitions…), ডেটার ওপর s3:GetObject আর s3:ListBucket, result location-এ s3:PutObject, আর ডেটা SSE-KMS দিয়ে encrypt করা থাকলে kms:Decrypt। কোন table, কোন column, কোন row কে দেখবে, এমন সূক্ষ্ম অনুমতি যোগ হয় Lake Formation দিয়ে (লেসন ১৭.৬)।

#সাধারণ ব্যবহার

• Log বিশ্লেষণ: VPC Flow Logs (লেসন ২২.৩), ALB আর CLB-এর access log, CloudTrail log (লেসন ১৯.৬), S3 server access log, S3 Inventory report। এই service-গুলো আগে থেকেই S3-এ লেখে, আর Athena-র documentation-এ এগুলোর জন্য তৈরি করা table definition দেওয়া আছে।
• Business intelligence আর reporting: S3-এর data lake-এর ওপর QuickSight dashboard, যার data source Athena।
• হঠাৎ দরকারি বিশ্লেষণ: analyst আর engineer-দের একবারের প্রশ্ন, বড় কিছু বানানোর আগে ডেটা ঘেঁটে দেখা।
• ডেটা তৈরি করা: CTAS আর INSERT INTO দিয়ে ডেটা পরিষ্কার করা, convert করা, নতুন আকারে S3-এ নতুন table বানানো।

#খরচ: যত byte scan, তত টাকা

Default model হলো query ধরে:

• us-east-1-এ TB-প্রতি ৫ USD scan (slide-এর দামটাই, এখনও চালু; কয়েকটা Region-এ একটু বেশি)।
• ওপরের দিকে নিকটতম megabyte-এ রাউন্ড হয়, আর প্রতি query-তে কমপক্ষে 10 MB। ছোট্ট একটা file-এ query চালালেও bill হয় 10 MB-র।
• বিনা পয়সায়: CREATE TABLE, ALTER TABLE ADD PARTITION, DROP TABLE-এর মতো DDL statement, আর ব্যর্থ query।
• টাকা লাগে: বাতিল করা query-তে, থামার আগে সে যতটা scan করেছে ততটার।
• আলাদা bill: তোমার ডেটা আর result-এর জন্য S3-এর request আর storage, free tier-এর বাইরে Glue Data Catalog, আর federated query-র জন্য Lambda।

Bill যেহেতু scan করা byte, তাই যা কিছু Athena-কে সস্তা করে, তা দ্রুতও করে: কম byte পড়া মানে কম কাজ।

একটা হিসাব করে দেখি: shop-এর orders table দিনে 10 GB CSV, এক বছরে 3.65 TB।

একই প্রশ্ন, ১৮ ডলার থেকে নেমে এক cent-এর দশ ভাগের এক ভাগ। যে dashboard এটা ঘণ্টায় একবার চালায়, তার জন্য এই পার্থক্য বছরে হাজার হাজার ডলার।

#Athena-কে দ্রুত আর সস্তা করা

এই চারটা কৌশলই notes, slide আর পরীক্ষার মূল কথা।

#১. Columnar format: Parquet আর ORC

CSV, JSON আর অন্য text format হলো row format: প্রতিটা লাইনে একটা পুরো record, সব column একসাথে। দুটো column পড়তে হলেও Athena-কে প্রতিটা লাইন পুরোটা পড়তে হয়।

Apache Parquet আর Apache ORC হলো columnar format: file-এর ভেতরে একটা column-এর সব মান একসাথে রাখা থাকে, block ধরে, আর file-এর ভেতরেই থাকে হিসাব (প্রতিটা block-এর সর্বনিম্ন আর সর্বোচ্চ মান)। এতে তিনটা লাভ:

• শুধু দরকারি column পড়া। ২০টার মধ্যে ২টা column-এর query file-এর মোটামুটি দশ ভাগের এক ভাগ পড়ে।
• ভালো compression। একটা column-এর মানগুলো একই রকম (তারিখ, শহর, দাম), তাই মেশানো row-এর চেয়ে অনেক ভালো compress হয়।
• Block বাদ দেওয়া। সর্বনিম্ন-সর্বোচ্চ হিসাব দেখে Athena পুরো block বাদ দিতে পারে, যেগুলো WHERE-এর সাথে মিলতেই পারে না (predicate pushdown)।

Notes বলছে এতে খরচ ৮০–৯০% কমে। হিসাবের একটা ভালো আন্দাজ হিসেবে কথাটা ঠিক; column কম আর compression ভালো হলে সাশ্রয় প্রায়ই আরও বেশি, ওপরের table-এই দেখলে।

Avro-ও পড়া যায়, তবে সেটা row-ভিত্তিক binary format, একটা একটা করে record লেখার জন্য ভালো (streaming), scan বাঁচানোর জন্য না।

#২. Compression

Compress করা file ছোট, তাই S3 থেকে পড়ার byte কম, দামও কম। Athena অনেক codec পড়তে পারে: Snappy, gzip, zstd (Zstandard), lz4, bzip2, zlib আর deflate। দুটো জিনিস মাথায় রাখো:

• Parquet আর ORC-এর ভেতরে compression হয় block ধরে (সাধারণ default Snappy, zstd আরও ভালো compress করে), তাই file ভাগ করে পড়া যায় (splittable): অনেক worker মিলে একটা file একসাথে পড়তে পারে।
• পুরো একটা text file gzip দিয়ে compress করলে সেটা ভাগ করা যায় না: একজন worker-কেই শুরু থেকে শেষ পড়তে হয়। মাঝারি মাপের অনেকগুলো gzip file ঠিক আছে; একটা বিশাল gzip file ধীর। bzip2 ভাগ করা যায়, কিন্তু decompress করতে সময় লাগে।

Compression CSV-রও কাজে লাগে (উদাহরণে প্রায় ৩:১), কিন্তু compress করা CSV-ও পুরো row ধরেই পড়তে হয়। সবচেয়ে ভালো ফল columnar আর compressed একসাথে।

#৩. Partition

Partition মানে table-এর file-গুলো এক বা একাধিক column-এর মান ধরে আলাদা folder-এ (S3 prefix-এ) রাখা, সাধারণত তারিখের অংশ ধরে, যাতে query শুধু দরকারি folder-গুলো পড়ে। Athena ব্যবহার করে Hive style, অর্থাৎ path-এ column=value:

s3://shop-logs-example/orders/year=2026/month=10/day=30/part-0001.snappy.parquet
s3://shop-logs-example/orders/year=2026/month=10/day=29/part-0001.snappy.parquet

year, month আর day table-এর virtual column হয়ে যায়: file-এর ভেতরে এরা নেই, আছে শুধু path-এ। WHERE year='2026' AND month='10' AND day='30' দেওয়া query একটা folder পড়ে, বাকি ৩৬৪টা বাদ দেয়। এর নাম partition pruning।

Notes-এর বাইরে তিনটা কথা জানা দরকার:

• Partition-গুলো catalog-কে জানাতে হয়। নতুন folder register না করা পর্যন্ত অদৃশ্য থাকে: register করা যায় ALTER TABLE ADD PARTITION দিয়ে, MSCK REPAIR TABLE দিয়ে (এটা prefix ঘেঁটে Hive-style folder খোঁজে, বড় table-এ ধীর হয়ে যায়), schedule করা Glue crawler দিয়ে, অথবা সময় ধরে সাজানো ডেটার জন্য সবচেয়ে ভালো, partition projection দিয়ে: table property-তে সম্ভাব্য মানগুলো বলে দাও (যেমন ২০২৪ থেকে প্রতিটা দিন), Athena query-র সময় নিজেই path হিসাব করে নেয়; register করার কিছু নেই, planning-ও দ্রুত।
• Query-কে partition column দিয়েই filter করতে হবে। order_date-এর মতো সাধারণ column-এ WHERE দিলে কিছুই বাদ যায় না, table দিন ধরে partition করা থাকলেও।
• অতিরিক্ত partition কোরো না। Partition করো সেই column দিয়ে, যেটা দিয়ে বেশিরভাগ query filter করে আর যার আলাদা মান কম (তারিখ, হয়তো দেশ বা region)। ঘণ্টা আর customer ID ধরে partition করলে লাখ লাখ ছোট্ট partition হয়; তখন planning, listing আর file খোলার খরচ পড়ার খরচকেই ছাড়িয়ে যায়। প্রতিটা partition-এ অন্তত কয়েকশো MB রাখার চেষ্টা করো।

#৪. বড় file, সংখ্যায় কম

প্রতিটা file-এর একটা নির্দিষ্ট খরচ আছে: একটা S3 request, file খোলা, তার শেষের অংশ (footer) পড়া। ১ KB-র লাখ লাখ file (কয়েক সেকেন্ড পরপর stream থেকে লেখার চেনা ফল) থাকলে byte কম হলেও query ধীর হয়। এগুলো জুড়ে মোটামুটি 128 MB থেকে 512 MB-এর file বানাও (slide বলছে “128 MB-র বেশি”)। খুব বড় file সমস্যা করে শুধু তখন, যখন সেটা ভাগ করা যায় না (একটা বিশাল gzip)। এই জোড়া লাগানোকে বলে compaction।

#ডেটা convert করা: Glue ETL নাকি CTAS

ডেটা সাধারণত আসে CSV বা JSON হয়ে। Convert করার দুটো চেনা উপায়:

• একটা AWS Glue ETL job (slide-এর উত্তর: “Glue দিয়ে ডেটা Parquet বা ORC-এ convert করো”): একটা serverless Spark job, যেটা কাঁচা prefix পড়ে, compress করা, partition করা Parquet লেখে curated prefix-এ, আর schedule বা trigger ধরে চলতে পারে। Job bookmark থাকায় পুরোনো file আবার process হয় না। Glue হলো লেসন ১৭.৬।
• একটা CTAS statement (CREATE TABLE AS SELECT), Athena-র ভেতরেই: query-র ফল নতুন একটা table হয়ে যায়, তোমার বাছা format, compression আর partition-এ। একটা CTAS বা INSERT INTO সর্বোচ্চ ১০০টা partition লিখতে পারে; বেশি লাগলে প্রথম ১০০-র জন্য CTAS, তারপর ১০০টা করে INSERT INTO।

Stream-এর বেলায় Amazon Data Firehose ঢোকার পথেই একটা Glue table-এর schema ধরে JSON-কে Parquet বা ORC-এ বদলে দিতে পারে, আর তার buffer setting ঠিক করে file কত বড় হবে (লেসন ১৩.৬)।

চারটা কৌশল নিজে হাতে চালিয়ে দেখো: format, partition, column আর তারিখের range বদলাও, আর দেখো scan কত হলো, bill কত হলো।

#Federated Query: S3-এর বাইরেও SQL

সব ডেটা S3-এ থাকে না। Order হয়তো Aurora-য়, stock-এর হিসাব DynamoDB-তে, product review DocumentDB-তে, কিছু পুরোনো ইতিহাস অফিসের নিজস্ব SQL Server-এ। Athena Federated Query AWS-এ বা on-premises-এ থাকা relational, non-relational, object আর custom data source-এর ওপর SQL চালায়, আর এক statement-এই সবগুলো join করে।

কীভাবে কাজ করে:

• প্রতিটা source-এ পৌঁছানো হয় একটা data source connector দিয়ে, যেটা তোমার account-এ একটা AWS Lambda function হিসেবে চলে (Athena Query Federation SDK দিয়ে বানানো; AWS প্রায় ৩০টা তৈরি connector দেয়, console বা Serverless Application Repository থেকে deploy করা যায়)।
• Connector আছে DynamoDB, RDS আর Aurora (MySQL, PostgreSQL), Redshift, DocumentDB, OpenSearch, CloudWatch Logs আর Metrics, Timestream, Neptune, ElastiCache-এর সাথে মেলে এমন Redis, EMR-এর HBase, MSK আর Kafka, SQL Server, Oracle, Db2, Teradata, Snowflake, Google BigQuery আর আরও অনেকের জন্য; চাইলে নিজেও লিখতে পারো।
• Athena column-এর তালিকা আর filter নিচে ঠেলে দেয় (push down), যাতে প্রতিটা source যত কম সম্ভব ডেটা ফেরত দেয়। একটা Lambda response-এর চেয়ে বড় result লেখা হয় S3-এর একটা spill bucket-এ।
• Query-র result জমা থাকে S3-এ, অন্য যেকোনো Athena result-এর মতোই, তাই আবার ব্যবহার করা যায়, বা CTAS দিয়ে Parquet table বানিয়ে data lake-এ পাঠানো যায়।
• খরচ: সব source মিলিয়ে যত ডেটা scan হলো তার ওপর Athena-র TB-প্রতি দাম (MB-তে রাউন্ড, কমপক্ষে 10 MB), সাথে Lambda invocation-এর দাম, সাথে source নিজে যা নেয় (যেমন DynamoDB-র read unit)।

মনে রাখার মতো সীমা: federated source-এ লেখা (INSERT INTO) চলে না; VPC-র ভেতরের database-এর connector-কে সেই VPC-তে চলতে হয়, সেখানে যাওয়ার network পথ আর security group rule-সহ; একটা ধীর বা ব্যর্থ connector পুরো query-কে ধীর বা ব্যর্থ করে দেয়; আর federated query চালু operational database সরাসরি পড়ে, তাই ভারী scan application-এর সাথে প্রতিযোগিতা করে।

#Workgroup: খরচ আর access-এর লাগাম

Workgroup হলো query রাখার একটা নাম দেওয়া পাত্র, যার নিজের setting আছে। প্রতিটা team, application বা environment-এর জন্য একটা করে বানাও:

• প্রতিটা workgroup-এর আলাদা result location আর encryption (অথবা Athena-managed result), আর সেগুলো enforce করার option, যাতে user বদলাতে না পারে।
• Per-query data usage control: একটা query কতটা ডেটা scan করতে পারবে তার সীমা, 10 MB থেকে ওপরে। যে query সীমা ছাড়ায়, সেটা বাতিল হয় (আর ততক্ষণ পর্যন্ত যা scan করেছে তার bill হয়)।
• পুরো workgroup-এর data usage alert: ঘণ্টায় বা দিনে মোট কত scan হলো তার সীমা। এটা একটা CloudWatch alarm বাজায়, সেটা একটা SNS topic-কে খবর দেয় (email, Lambda); query বাতিল করে না। খরচ থামাতে admin (বা একটা Lambda function) workgroup-টা disable করতে পারে।
• Metric আর খরচের ভাগ: প্রতিটা workgroup-এর CloudWatch metric, আর workgroup-এ tag বসিয়ে team ধরে bill ভাগ করা।
• Access control: IAM policy দিয়ে কোনো user-কে শুধু নির্দিষ্ট workgroup-এ query চালাতে দেওয়া যায়।
• Query result reuse: চালু থাকলে একই workgroup-এ হুবহু একই query আগের জমা result ফেরত দেয়, যদি সেটা সর্বোচ্চ বয়সের চেয়ে নতুন হয় (default ৬০ মিনিট, ৭ দিন পর্যন্ত), আর কিছুই scan করে না। এর মধ্যে ডেটা বদলেছে কি না, Athena দেখে না।
• Capacity reservation বসানো হয় workgroup ধরে (ওপরের পাশের কথা দেখো)।

#Security সংক্ষেপে

• কে query চালাবে আর কোন workgroup-এ, তা ঠিক করে IAM; কী পড়তে পারবে, তা ঠিক করে S3, Glue আর KMS-এর permission।
• Encryption at rest: Athena SSE-S3, SSE-KMS বা KMS দিয়ে client-side encryption করা ডেটা পড়তে পারে, আর query result encrypt করতে পারে SSE-S3, SSE-KMS বা client-side KMS দিয়ে (লেসন ১০.৮)। পথে (in transit) সবকিছু চলে TLS দিয়ে।
• Private access: Athena-র জন্য একটা interface VPC endpoint (PrivateLink) call-গুলোকে internet থেকে দূরে রাখে।
• সূক্ষ্ম access (শুধু কিছু column বা row, যেমন customer-এর phone number লুকানো): Glue Data Catalog-এর ওপরে AWS Lake Formation (লেসন ১৭.৬)।
• Audit: Athena-র API call CloudTrail-এ লেখা থাকে।

#সাধারণ query-র বাইরে

#Athena, Redshift, Redshift Spectrum আর EMR

এরা সবাই Glue Data Catalog-এর table definition ভাগ করে ব্যবহার করতে পারে। OLTP বনাম OLAP-এর পটভূমি আছে লেসন ১৬.১-এ।

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

• একটা query-তেই বিশাল bill: partition ছাড়া CSV-তে SELECT *, বা partition column-এর বদলে সাধারণ column-এ WHERE। Parquet-এ convert করো, partition করো, partition দিয়ে filter করো, আর workgroup-এ per-query data limit বসাও।
• নতুন ডেটায় শূন্য row: নতুন partition register হয়নি। Partition projection, crawler বা ALTER TABLE ADD PARTITION ব্যবহার করো।
• Scan কম, তবু query ধীর: লাখ লাখ ছোট file বা অতিরিক্ত partition। File জুড়ে 128–512 MB করো, কম column দিয়ে partition করো।
• একটা বিশাল gzip file ধীর: সেটা ভাগ করা যায় না। ভাগ করো, বা Parquet-এ convert করো।
• HIVE_BAD_DATA বা ভুল মান: table-এর schema file-এর সাথে মেলে না (CSV-র মাঝখানে নতুন column ঢুকেছে, type মেলে না)। Table definition ঠিক করো, বা এমন columnar format নাও যেটা নিজের schema নিজে রাখে।
• Access Denied: যে চালাচ্ছে তার S3, Glue বা KMS-এর permission নেই, বা result location-এ লিখতে পারছে না।
• HIVE_TOO_MANY_OPEN_PARTITIONS: একটা CTAS বা INSERT INTO ১০০টার বেশি partition লিখছে। ভাগে ভাগে চালাও।
• Federated query-র timeout: Lambda connector source-এ পৌঁছাতে পারছে না (VPC, route, security group), বা source নিজেই ধীর। আর federated query production database-এর ওপর চাপও বাড়ায়।
• পুরোনো সংখ্যা: query result reuse সর্বশেষ ডেটার চেয়ে পুরোনো result ফেরত দিয়েছে। সর্বোচ্চ বয়স কমাও, বা ওই query-তে reuse বন্ধ রাখো।
• বাতিল বা ব্যর্থ query-র পরে S3-এ অর্ধেক লেখা result file পড়ে আছে। Result bucket-এ lifecycle rule দাও, বা managed query results ব্যবহার করো।
• ব্যস্ত সময়ে query queue-তে আটকায় বা throttle হয়: account-এ একসাথে চলা query-র quota শেষ। চাপ ছড়িয়ে দাও, quota বাড়াও, বা capacity reservation নাও।

#System design-এ Athena

চেনা pattern:

• Serverless data lake: কাঁচা ডেটা S3-এ নামে (Firehose, DMS, upload থেকে), একটা Glue job বা CTAS curated Parquet লেখে, Glue Data Catalog তার বর্ণনা রাখে, Athena query করে, QuickSight দেখায়, Lake Formation ঠিক করে কে কী দেখবে। পুরো pipeline আছে লেসন ১৭.৮-এ।
• Log analytics: CloudTrail, VPC Flow Logs, ALB আর S3-এর access log S3-এ, দরকার হলেই শুধু Athena দিয়ে query।
• নির্দিষ্ট সময়ে report: EventBridge বা Step Functions প্রতি রাতে একটা Athena query চালায়; S3-এ জমা result যায় একটা report-এ বা pipeline-এর পরের ধাপে।
• ML-এর জন্য ডেটা ঘেঁটে দেখা: SageMaker job-এর আগে data scientist-রা S3-এর training ডেটা SQL দিয়ে ঘেঁটে দেখে (অধ্যায় ১৮)।

Athena যেখানে ভুল পছন্দ: application-এর জন্য খুব কম latency-র lookup (DynamoDB বা RDS নাও), শত শত BI user সারাদিন একই ডেটায় ভারী query চালায় (সাধারণত Redshift সস্তা আর দ্রুত), relevance আর আংশিক মিলসহ full-text search (OpenSearch), আর Iceberg ছাড়া আলাদা আলাদা row-এর transaction ধরে update।

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

এখানে AWS CLI v2 আর Athena query editor-এর SQL ব্যবহার হয়েছে। Query-তে সত্যিকারের টাকা লাগে, তাই table ছোট রাখো আর শেষে bucket মুছে দাও।

# ১. ডেটার জন্য একটা bucket, আর result location, enforce করা setting ও query-প্রতি 1 GB সীমাসহ একটা workgroup
aws s3 mb s3://shop-logs-example --region ap-southeast-1
aws s3 cp orders-2026-10-30.csv s3://shop-logs-example/orders_raw/year=2026/month=10/day=30/
aws athena create-work-group --name adhoc \
  --configuration 'ResultConfiguration={OutputLocation=s3://shop-athena-results-example/adhoc/},EnforceWorkGroupConfiguration=true,PublishCloudWatchMetricsEnabled=true,BytesScannedCutoffPerQuery=1073741824'

-- ২. কাঁচা CSV file-গুলোর বর্ণনা একবার লিখে রাখো (DDL বিনা পয়সায়)
CREATE DATABASE shop;

CREATE EXTERNAL TABLE shop.orders_raw (
  order_id string, customer_id string, city string, amount double, campaign string, order_ts timestamp
)
PARTITIONED BY (year string, month string, day string)
ROW FORMAT DELIMITED FIELDS TERMINATED BY ','
LOCATION 's3://shop-logs-example/orders_raw/'
TBLPROPERTIES ('skip.header.line.count'='1');

-- ৩. যে partition-গুলো আগে থেকে আছে সেগুলো register করো (Hive-style folder)
MSCK REPAIR TABLE shop.orders_raw;

-- ৪. CTAS দিয়ে compress করা, partition করা Parquet-এ convert করো
CREATE TABLE shop.orders
WITH (format = 'PARQUET', write_compression = 'SNAPPY',
      external_location = 's3://shop-logs-example/orders/',
      partitioned_by = ARRAY['year','month','day'])
AS SELECT order_id, customer_id, city, amount, campaign, order_ts, year, month, day
FROM shop.orders_raw;

-- ৫. এমন query যেটা partition বাদ দেয় আর মাত্র দুটো column পড়ে
SELECT city, count(*) AS orders
FROM shop.orders
WHERE year = '2026' AND month = '10' AND day = '30'
GROUP BY city ORDER BY orders DESC;

# ৬. একই query CLI থেকে চালাও, তারপর হিসাব আর result পড়ো
QID=$(aws athena start-query-execution --work-group adhoc \
  --query-string "SELECT city, count(*) AS orders FROM shop.orders WHERE year='2026' AND month='10' AND day='30' GROUP BY city" \
  --query QueryExecutionId --output text)
aws athena get-query-execution --query-execution-id "$QID" \
  --query 'QueryExecution.[Status.State,Statistics.DataScannedInBytes,Statistics.EngineExecutionTimeInMillis]'
# [ "SUCCEEDED", 1874211, 912 ]
aws athena get-query-results --query-execution-id "$QID" --max-items 3
# { "ResultSet": { "Rows": [
#     { "Data": [ { "VarCharValue": "city" }, { "VarCharValue": "orders" } ] },
#     { "Data": [ { "VarCharValue": "Dhaka" }, { "VarCharValue": "8412" } ] },
#     { "Data": [ { "VarCharValue": "Chattogram" }, { "VarCharValue": "1284" } ] } ] } }

# ৭. একটা run-এর জন্য result reuse চালু করো (৬০ মিনিট পর্যন্ত পুরোনো)
aws athena start-query-execution --work-group adhoc \
  --query-string "SELECT count(*) FROM shop.orders WHERE year='2026'" \
  --result-reuse-configuration 'ResultReuseByAgeConfiguration={Enabled=true,MaxAgeInMinutes=60}'

# ৮. পরিষ্কার করো
aws athena delete-work-group --work-group adhoc --recursive-delete-option
aws s3 rb s3://shop-logs-example --force

Console-এও চেষ্টা করো: ধাপ ৫-এর query একবার orders_raw-এ আর একবার orders-এ চালাও, আর result-এর নিচে Data scanned তুলনা করো। তারপর workgroup-এর Workgroup data usage alerts খুলে একটা SNS topic-সহ ঘণ্টাভিত্তিক alert যোগ করো।

#সারসংক্ষেপ

মূল কথা

• Athena = S3-এর file-এ সরাসরি serverless SQL: cluster নেই, load নেই, Trino/Presto engine-এ সাধারণ SQL, table-এর বর্ণনা Glue Data Catalog-এ (schema on read), result লেখা হয় S3-এ।
• Format: CSV, JSON, ORC, Avro, Parquet (আর log, Iceberg)। চেনা ব্যবহার: VPC Flow Logs, ELB আর CloudTrail log, হঠাৎ দরকারি বিশ্লেষণ, QuickSight দিয়ে BI।
• দাম: TB-প্রতি ৫ USD scan (us-east-1), MB-তে রাউন্ড, প্রতি query-তে কমপক্ষে 10 MB। DDL আর ব্যর্থ query বিনা পয়সায়; বাতিল query যতটা scan করেছে তার দাম দেয়। চাইলে capacity reservation, তখন bill unit-ঘণ্টা ধরে।
• সস্তা মানেই দ্রুত: columnar format (Parquet, ORC), compression (Snappy, zstd, gzip…), partition (year=2026/month=10/day=30/, partition column দিয়ে filter, partition register বা project করো), বড় file (লাখ লাখ ছোট file-এর বদলে 128–512 MB)। পরীক্ষার উত্তর: Parquet/ORC-এ convert আর partition।
• Convert করো Glue ETL job বা CTAS statement দিয়ে (একটা CTAS বা INSERT INTO-তে সর্বোচ্চ ১০০টা partition); Firehose সরাসরি Parquet লিখতে পারে।
• Federated Query: Lambda-তে চলা data source connector দিয়ে RDS, Aurora, DynamoDB, Redshift, DocumentDB, on-premises database আর আরও অনেকের ওপর এক SQL; result জমা S3-এ; শুধু পড়া যায়।
• Workgroup: per-query data limit (query বাতিল করে), পুরো workgroup-এর alert (CloudWatch + SNS, বাতিল করে না), আলাদা result আর encryption, tag, query result reuse, capacity reservation।
• হঠাৎ আর মাঝে মাঝের S3 query-র জন্য Athena; load করা ডেটায় ভারী, ঘনঘন BI-র জন্য Redshift; চালু Redshift cluster থেকে S3 query করতে Redshift Spectrum।

নিজেকে যাচাই করো: Amazon Athena৩০টি প্রশ্ন