</>Học Dev
Bài học

Tuần 5 - Ngày 3: Amazon Athena

Tuần 5 – Ngày 3

Mục tiêu học tập

  • Hiểu Athena: serverless SQL trên S3, pricing theo data scanned
  • Tối ưu chi phí/hiệu năng: Parquet, partition, CTAS, reuse
  • Nắm workgroups, federated query, Iceberg trên Athena
  • Phân biệt Athena vs Redshift (Spectrum) — chọn đúng theo đề

1. Tổng quan

Athena = engine SQL serverless (nền Trino/Presto — engine v3) query trực tiếp dữ liệu S3 qua schema trong Glue Data Catalog. Không hạ tầng, trả $5/TB dữ liệu scan.

SQL(console/JDBC/API)│▼Athena(Trinoengine,serverless)│schema:GlueDataCatalog▼S3(Parquet/ORC/CSV/JSON/Avro,partitioned)│▼Queryresults→S3outputlocation(+resultreuse/cache)
  • Ad-hoc analytics, khám phá data lake, query log (VPC Flow Logs, CloudTrail, ALB logs)
  • DDL (CREATE TABLE) miễn phí; failed query không tính tiền
  • Ngoài SQL còn có Athena for Apache Spark (notebook Spark serverless)

2. Tối ưu chi phí và hiệu năng (trọng tâm thi)

Kỹ thuậtHiệu quả
Columnar (Parquet/ORC) + nénGiảm 90%+ data scanned
Partitioning (+ partition projection)Prune partition — chỉ scan phần WHERE chạm
SELECT đúng cột (bỏ SELECT *)Columnar chỉ đọc cột cần
BucketingLọc/join theo cột cardinality cao
Gộp small files (~128MB+)Ít overhead mở file
CTAS / INSERT INTOConvert + re-partition bằng SQL
Query result reuseTrả kết quả cache theo TTL — dashboard lặp lại không scan lại
LIMIT không cứu chi phí scanLIMIT vẫn phải scan trước khi cắt (trừ khi engine đẩy xuống)

3. Workgroups — quản trị và cost control

  • Tách workgroup theo team/ứng dụng: output location riêng, metrics riêng, enforce settings
  • Data usage controls: per-query limit (query scan quá X TB → hủy) và per-workgroup limit (ngưỡng theo giờ/ngày → alert SNS)
  • Gắn tag để cost allocation; buộc mã hóa kết quả
  • Exam cue: "kiểm soát chi phí Athena theo team / chặn query quét quá lớn" → workgroups + data usage controls

4. Federated query và Iceberg

Federated query

  • Query nguồn ngoài S3 qua Lambda connector (DynamoDB, RDS/JDBC, CloudWatch Logs, Redis...): join dữ liệu lake với nguồn khác không cần ETL
  • Hợp ad-hoc; volume lớn lặp lại → replicate về lake rẻ hơn

Iceberg và ACID trên Athena

  • CREATE TABLE ... TBLPROPERTIES ('table_type'='ICEBERG') — hỗ trợ INSERT/UPDATE/DELETE/MERGE INTO, time travel (FOR TIMESTAMP AS OF), schema evolution
  • OPTIMIZE table REWRITE DATA USING BIN_PACK — compaction small files; VACUUM dọn snapshot cũ
  • Đây là cách "UPDATE dữ liệu trên S3 bằng SQL" chuẩn trong đề hiện nay

5. Athena vs Redshift/Spectrum — chọn gì?

Tiêu chíAthenaRedshift (+Spectrum)
Hạ tầngKhông (serverless thuần)Cluster/workgroup (serverless option)
Chi phí$/TB scan — rẻ khi query thưaCluster/RPU — rẻ khi query dày liên tục
Latency/concurrency BI lớnKhá; không dành cho trăm dashboard đồng thờiMạnh (WLM, concurrency scaling, MV)
Dữ liệuS3 (+federated)Local + S3 (Spectrum)
Use case chuẩnAd-hoc, khám phá, log analytics, ETL nhẹ bằng SQLWarehouse BI production, aggregate lặp lại, ELT nặng

Nguyên tắc: "occasional/ad-hoc queries on S3, no infrastructure" → Athena. "high-concurrency BI, consistent sub-second dashboards" → Redshift. Đề cho cả hai vế → kiến trúc kết hợp.

Câu hỏi ôn tập

  1. Query Athena trên 1TB CSV tốn $5 và chạy chậm. Ba việc giảm 90%+ chi phí?

    Xem đáp án

    (1) Convert sang Parquet + nén (CTAS) — columnar chỉ đọc cột cần; (2) partition theo cột lọc phổ biến (vd ngày) để prune; (3) bỏ SELECT *, chỉ SELECT cột dùng. Ba thứ cộng lại thường giảm >90% data scanned — công thức kinh điển của mọi câu "reduce Athena cost".

  2. Cần chặn analyst chạy query scan quá 1TB và theo dõi chi phí theo team. Tính năng Athena nào?

    Xem đáp án

    Workgroups: tách mỗi team một workgroup, bật per-query data usage control (vượt 1TB → query bị hủy) và per-workgroup limits (ngưỡng tổng theo giờ/ngày → SNS alert), gắn tag cost allocation, enforce output location + encryption.

  3. Dashboard gọi lại cùng câu query mỗi 10 phút trong khi dữ liệu chỉ cập nhật mỗi giờ. Giảm scan thế nào?

    Xem đáp án

    Bật query result reuse với TTL ~60 phút — Athena trả kết quả cache thay vì scan lại S3 (không tính phí scan cho lần reuse). Cách khác: vật thể hóa kết quả bằng CTAS/INSERT INTO bảng tổng hợp nhỏ và cho dashboard query bảng đó.

  4. Cần join dữ liệu S3 với một bảng DynamoDB cho phân tích ad-hoc một lần. Giải pháp nhanh nhất?

    Xem đáp án

    Athena Federated Query với DynamoDB connector (Lambda) — join thẳng trong SQL, không cần export. Nếu nhu cầu lặp lại thường xuyên trên bảng lớn → export DynamoDB sang S3 (export to S3 tích hợp sẵn) rồi query, rẻ hơn và không ăn RCU.

  5. Bảng Iceberg trên Athena bị chậm dần do hàng nghìn file nhỏ từ ghi streaming. Lệnh xử lý?

    Xem đáp án

    Chạy OPTIMIZE <table> REWRITE DATA USING BIN_PACK — compaction gộp file nhỏ thành file lớn; định kỳ VACUUM để expire snapshot cũ và xóa orphan files (cũng giảm chi phí storage). Có thể tự động hóa qua Step Functions/EventBridge Scheduler, hoặc dùng S3 Tables để AWS tự compaction.

  6. Khi nào Athena là lựa chọn SAI so với Redshift?

    Xem đáp án

    Khi cần: (1) hàng trăm query BI đồng thời với latency ổn định sub-second — Athena không có WLM/concurrency scaling tương đương; (2) aggregate lặp lại liên tục cả ngày — trả $/TB scan mỗi lần sẽ đắt hơn cluster; (3) transform ELT nặng phụ thuộc bảng local/tối ưu sort-dist key. Athena thắng ở ad-hoc, thưa, không hạ tầng.

Bài tập thực hành

  • Query CloudTrail hoặc VPC Flow Logs bằng Athena (dùng DDL mẫu trong docs)
  • Tạo workgroup mới với per-query limit 100MB, thử chạy query vượt ngưỡng
  • Tạo bảng Iceberg bằng Athena, chạy INSERT + UPDATE + time travel query
  • Đọc Athena performance tuning tips

Tài liệu tham khảo chính thức

Tiếp theo: DynamoDB cho Data Engineering