Ngân hàng đề — AWS Certified Data Engineer Associate

🧩 Phân tích nội dung câu hỏi

Đề mô tả một công ty dịch vụ streaming có metadata video nằm rải rác ở hai nơi khác nhau: trong Amazon RDS (dữ liệu quan hệ) và dưới dạng JSON trong Amazon S3 (dữ liệu tệp phi cấu trúc). Yêu cầu là tìm một dịch vụ managed để tự động catalog khối dữ liệu đó và phản ánh được các thay đổi schema.

Cụm từ quyết định nằm ngay trong câu hỏi: "a managed service to automatically catalog", "reflect schema changes" và "with minimal manual effort". Ba cụm này cùng chỉ về một hướng — người ra đề không hỏi "cách nào làm được", mà hỏi "cách nào làm được mà không phải tự viết và tự bảo trì". Bất kỳ phương án nào bắt bạn viết code quét dữ liệu, tự dựng bảng metadata, hay tự đồng bộ khi schema đổi đều bị loại bởi chính cụm minimal manual effort, dù về mặt kỹ thuật nó vẫn "chạy được".

Thêm một ràng buộc phụ dễ bỏ qua: nguồn dữ liệu có cả RDS lẫn S3. Lời giải phải catalog được cả hai loại nguồn, chứ không chỉ một.

✅ Vì sao đáp án đúng là đúng

B — AWS Glue Data Catalog với scheduled crawlers.

Glue Data Catalog là một dịch vụ quản lý hoàn toàn (fully managed), đóng vai trò kho metadata trung tâm dùng chung cho các dịch vụ dữ liệu trên AWS. Đúng phần việc mà đề đang cần.

Thành phần khớp trực tiếp với đề là crawler. Crawler có sẵn khả năng kết nối tới nhiều loại nguồn — trong đó có Amazon RDS qua JDBC connection và dữ liệu trong Amazon S3 — rồi tự suy ra schema và ghi vào Data Catalog thành database/table. Bạn không phải viết code phát hiện cột hay kiểu dữ liệu; đó là chức năng dựng sẵn.

Chi tiết scheduled trong phương án là mảnh ghép trả lời cho yêu cầu "reflect schema changes": crawler đặt lịch chạy định kỳ sẽ quét lại nguồn, phát hiện cột mới hoặc partition mới và cập nhật lại định nghĩa bảng trong catalog. Nhờ vậy metadata luôn theo kịp dữ liệu mà không cần ai đụng tay vào sau khi cấu hình xong — đúng nghĩa "minimal manual effort".

❌ Vì sao các phương án còn lại sai

A — AWS Lambda quét định kỳ, ghi metadata vào một RDS instance.

Đây là phương án "gần đúng về kết quả, sai về cách làm". Nó đúng ở chỗ vẫn cho ra một kho metadata được cập nhật theo lịch, nhưng toàn bộ phần khó phải tự làm: viết code kết nối từng nguồn, tự suy schema từ JSON, tự thiết kế bảng catalog trong RDS, tự xử lý khi schema đổi, rồi tự vận hành và sửa lỗi về sau. Đề nói rõ là muốn managed service và minimal manual effort — một giải pháp tự viết bằng Lambda là ngược lại đúng hai điểm đó.

C — Redshift Spectrum quét dữ liệu và đổ metadata vào schema trong Redshift cluster.

Redshift Spectrum đọc được dữ liệu ngoài (đặc biệt là dữ liệu trên S3), nhưng vai trò của nó là truy vấn, không phải catalog. Nó là bên tiêu thụ metadata chứ không phải bên tự sinh ra metadata. Không có cơ chế tự phát hiện và tự cập nhật schema như crawler, nên yêu cầu "reflect schema changes" không được đáp ứng; đồng thời cách này kéo theo một Redshift cluster phải dựng và vận hành, tức là nhiều thiết lập hơn chứ không ít hơn.

D — Athena truy vấn rồi ghi kết quả metadata vào DynamoDB làm catalog.

Phương án này lẫn lộn vai trò tương tự C. Athena là engine truy vấn — bản thân nó cần một catalog để biết bảng nằm ở đâu, chứ không phải công cụ tự khám phá schema. Còn ghi kết quả sang DynamoDB thì tạo ra một catalog thủ công: ai đó phải viết và duy trì quy trình đồng bộ, quyết định khi nào chạy lại, xử lý trường hợp schema đổi. Vẫn là công sức tự dựng, đúng thứ mà đề đang muốn tránh.

📌 Điểm cần nhớ

• Trong các câu hỏi kiểu "tự động catalog metadata, tự bắt kịp schema thay đổi, ít công sức nhất", đáp án gần như luôn là AWS Glue Data Catalog + crawler. Từ khoá crawler gắn liền với việc tự khám phá schema.
• Phân biệt rõ vai trò: Glue Data Catalog sinh và giữ metadata, còn Athena và Redshift Spectrum tiêu thụ metadata để truy vấn. Thấy phương án bắt Athena hay Spectrum đóng vai kho metadata thì nghi ngờ ngay.
• Cụm "managed service" và "minimal manual effort" là bộ lọc mạnh nhất trong đề: nó loại thẳng mọi phương án dựa trên code tự viết (Lambda quét định kỳ) hoặc quy trình đồng bộ tự dựng (ghi sang DynamoDB), kể cả khi chúng về lý thuyết vẫn cho ra kết quả đúng.
• Crawler đặt lịch chạy chính là câu trả lời cho vế "reflect schema changes" — nếu một phương án không nói được nó bắt kịp thay đổi schema bằng cách nào, phương án đó chưa trả lời hết câu hỏi.

🧩 Phân tích nội dung câu hỏi

Đề mô tả một đội DevOps đang theo dõi và gỡ lỗi cho một nhóm EC2 instance chạy ứng dụng web. Log của các ứng dụng này đã nằm sẵn trong Amazon CloudWatch Logs, và câu hỏi là: dùng dịch vụ hay tính năng nào của AWS để phân tích và truy vấn khối log đó theo thời gian thực, nhằm nhanh chóng tìm ra lỗi và hiểu được các mẫu sử dụng.

Cụm từ quyết định đáp án là "log data stored in Amazon CloudWatch Logs" kết hợp với "real-time analysis and querying". Hai ràng buộc này đi cùng nhau:

• Dữ liệu đang ở CloudWatch Logs, không phải ở S3, không phải ở một cụm search riêng. Vì vậy phương án nào đòi chuyển dữ liệu đi nơi khác trước khi truy vấn được đều thêm một bước mà đề không hề nhắc tới.
• Nhu cầu là truy vấn và phân tích log — chứ không phải theo dõi đường đi của một request qua nhiều service.

Khi đề đã chỉ đích danh nơi dữ liệu đang nằm, cách đọc đúng gần như luôn là: chọn công cụ nguyên bản, tích hợp sẵn với chính nơi đó.

✅ Vì sao đáp án đúng là đúng

A — Use CloudWatch Logs Insights to perform queries and analyze the log data.

CloudWatch Logs Insights là tính năng truy vấn được xây dựng ngay bên trong CloudWatch Logs. Nó cho phép đội DevOps viết truy vấn tương tác trực tiếp trên các log group hiện có, không cần export, không cần dựng hạ tầng, không cần cấu hình pipeline nạp dữ liệu.

Đúng theo phần giải thích gốc, đây là công cụ phù hợp nhất vì:

• Cung cấp giao diện tương tác để truy vấn và phân tích log đang lưu trong CloudWatch Logs.
• Chạy được các truy vấn phức tạp, giúp phân tích và trực quan hoá dữ liệu vận hành một cách hiệu quả.
• Đặc biệt hữu ích cho đúng ba việc đề nêu: nhận diện xu hướng, khoanh vùng lỗi, và rút ra thông tin có giá trị từ log — nền tảng của việc monitoring và troubleshooting ứng dụng web.

Nói gọn: dữ liệu ở đâu thì truy vấn tại đó. Không có độ trễ của bước sao chép dữ liệu, nên đáp ứng được yêu cầu "real-time".

❌ Vì sao các phương án còn lại sai

B — Set up Amazon Athena to query log data directly from CloudWatch Logs. Đây là phương án gần đúng nhất về mặt "truy vấn log", và nó hỏng ở đúng một chữ: directly. Athena là công cụ truy vấn mạnh cho tập dữ liệu quy mô lớn, nhưng địa bàn của nó là dữ liệu nằm trong Amazon S3 — nó không tích hợp trực tiếp với CloudWatch Logs để làm log analysis. Muốn dùng Athena thì phải đưa log ra S3 trước, tức là thêm một chặng và mất tính tức thời. Athena không mang lại khả năng phân tích log thời gian thực như Logs Insights.

C — Configure Amazon Elasticsearch Service for log analytics and visualization. Phương án này không hề sai về năng lực: Amazon Elasticsearch Service đúng là một công cụ mạnh cho log analytics và visualization. Nó hỏng ở cái giá phải trả so với yêu cầu của đề: dùng nó nghĩa là phải dựng và vận hành một cụm Elasticsearch. Với nhu cầu phân tích và truy vấn log đang nằm sẵn trong CloudWatch, Logs Insights là giải pháp trực tiếp và tích hợp hơn hẳn trong hệ sinh thái AWS. Đây là kiểu phương án "làm được nhưng thừa" — bẫy rất hay gặp.

D — Implement AWS X-Ray for in-depth analysis and tracing of application logs. X-Ray sai về bản chất công việc, chứ không chỉ sai về mức độ phù hợp. X-Ray tập trung vào hiệu năng của ứng dụng và service phân tán: nó trace request khi request đi xuyên qua các thành phần của hệ thống. Nó không phải công cụ để truy vấn và phân tích dữ liệu log như CloudWatch Logs Insights. Chữ "logs" trong phương án này là mồi nhử — việc mà X-Ray làm là tracing, không phải log querying.

📌 Điểm cần nhớ

• Log đã nằm trong CloudWatch Logs → CloudWatch Logs Insights. Đây là cặp mặc định; chỉ đi chệch khi đề nêu lý do rõ ràng để rời khỏi CloudWatch.
• Athena gắn với S3, không gắn với CloudWatch Logs. Thấy phương án nói Athena truy vấn "trực tiếp" từ CloudWatch Logs thì đó là dấu hiệu của phương án sai.
• Phân biệt log analysis với tracing. CloudWatch Logs Insights truy vấn log; AWS X-Ray theo dấu request qua hệ thống phân tán. Đề hỏi "query log" thì X-Ray không phải câu trả lời, dù phương án có kèm chữ "logs".
• Giải pháp phải tự dựng và tự vận hành thường thua giải pháp tích hợp sẵn, khi cả hai đều đáp ứng được yêu cầu. Amazon Elasticsearch Service đòi quản lý cluster; nếu đề không yêu cầu thứ gì mà Logs Insights không làm được, chi phí vận hành thêm đó là điểm trừ.

🧩 Phân tích nội dung câu hỏi

Một tổ chức đang dùng Amazon Athena để chạy truy vấn SQL cho việc phân tích dữ liệu. Giờ họ muốn dùng thêm Apache Spark cho các tác vụ xử lý và phân tích phức tạp hơn, và yêu cầu đặt ra là Spark phải truy cập được dữ liệu thông qua Athena.

Cụm từ quyết định nằm ở câu hỏi cuối: "enable Apache Spark to access and analyze data in Athena". Đây không phải câu hỏi "cách nào gọi được Athena bằng chương trình" — nếu vậy thì mấy phương án kia cũng có phần đúng. Ràng buộc thật là: cầu nối phải dùng được ngay từ bên trong môi trường Spark, tức là Spark cần một nguồn dữ liệu (data source) kiểu database mà nó biết cách đọc, chứ không phải một thư viện lập trình mà ta phải tự viết code kết dính.

Spark chạy trên JVM và có sẵn cơ chế đọc dữ liệu qua JDBC — đây chính là mấu chốt phân biệt bốn phương án gần giống nhau, vì cả bốn đều là "cách chạm tới Athena", nhưng chỉ một cái ăn khớp trực tiếp với Spark.

✅ Vì sao đáp án đúng là đúng

A. Athena JDBC driver.

JDBC là chuẩn kết nối cơ sở dữ liệu của Java. Khi nạp Athena JDBC driver vào môi trường Spark, Athena hiện ra trước mắt Spark như một nguồn dữ liệu JDBC bình thường: Spark gửi câu SQL qua driver, Athena thực thi truy vấn, rồi trả kết quả về cho Spark xử lý tiếp.

Đây là con đường liền mạch nhất: không phải viết lớp kết dính riêng, không phải tự quản lý vòng đời truy vấn hay tự đọc kết quả rồi nhồi vào cấu trúc dữ liệu của Spark. Kết quả là kết hợp được sức mạnh xử lý của Spark với dịch vụ truy vấn tương tác của Athena — đúng thứ đề bài đang cần.

❌ Vì sao các phương án còn lại sai

B. Athena SDK. SDK là bộ công cụ để phát triển ứng dụng giao tiếp với Athena. Nó dùng được, nhưng nó không cung cấp cách để Spark trực tiếp truy cập dữ liệu Athena — SDK hướng tới việc xây ứng dụng tuỳ biến và script, còn muốn ghép vào Spark thì lập trình viên phải tự viết toàn bộ phần trung gian. Đây là phương án "gần đúng" theo nghĩa vẫn chạm tới được Athena, nhưng nó hỏng ở chỗ không có tích hợp sẵn với Spark.

C. Athena UDFs. User Defined Functions là các hàm tuỳ biến để mở rộng khả năng SQL của chính Athena — ví dụ thêm một phép biến đổi mà SQL sẵn có không làm được. Nó nằm hoàn toàn bên trong Athena và hướng vào việc làm giàu truy vấn, chứ không phải cơ chế để một engine bên ngoài như Spark đọc dữ liệu. Phương án này lệch hẳn về mục đích.

D. Athena API. API cho phép truy cập Athena bằng chương trình: chạy truy vấn, quản lý việc thực thi, lấy kết quả về. Đây là phương án gây nhiễu mạnh nhất, vì kỹ thuật mà nói ta có thể dựng cầu nối bằng API. Nhưng nó không được thiết kế riêng cho việc tích hợp với Apache Spark — nó phù hợp với các ứng dụng tuỳ biến và luồng công việc tự động hoá hơn là dùng thẳng trong môi trường Spark. So với JDBC driver — thứ Spark hiểu ngay không cần dịch — API là con đường vòng.

📌 Điểm cần nhớ

• Khi đề hỏi cách để một engine xử lý dữ liệu (Spark, và các công cụ BI chạy trên JVM) nói chuyện với một dịch vụ truy vấn SQL, hãy nghĩ tới JDBC/ODBC driver trước tiên — đó là giao diện chuẩn mà các công cụ này đã biết sẵn cách dùng.
• Phân biệt rõ ba lớp công cụ quanh Athena: driver (cắm vào công cụ có sẵn), SDK/API (dùng để tự viết ứng dụng), UDF (mở rộng SQL bên trong Athena). Ba lớp này phục vụ ba loại nhu cầu khác nhau.
• Đề nêu tên một công cụ cụ thể (ở đây là Apache Spark) thì đó là ràng buộc, không phải trang trí: hãy chọn phương án tích hợp trực tiếp với công cụ đó, đừng chọn phương án chỉ "về lý thuyết thì làm được".
• API/SDK giải quyết được rất nhiều việc, nên chúng luôn là mồi nhử hấp dẫn trong câu trắc nghiệm. Tiêu chí loại chúng ra là câu hỏi: phương án này có phải cách được thiết kế sẵn cho tình huống trong đề không?

🧩 Phân tích nội dung câu hỏi

Đề mô tả một luồng xử lý dữ liệu: mỗi khi có tệp .csv được tải lên một S3 bucket cụ thể, cần một tiến trình serverless chạy Lambda để chuyển tệp đó sang định dạng Apache Parquet.

Ba cụm từ trong đề quyết định đáp án:

• "triggered only by the upload of .csv files" — cơ chế kích hoạt phải lọc được theo phần mở rộng tệp, chứ không chỉ theo sự kiện "có object mới".
• "most efficient method" kèm "minimize manual intervention" — đây là cách hỏi quen thuộc của AWS về least operational overhead: giữa nhiều cách chạy được, chọn cách ít thành phần trung gian nhất.
• "a serverless process" — loại bỏ mọi phương án đòi dựng thêm hạ tầng hay lớp điều phối.

Tất cả bốn phương án đều "chạy được" ở mức nào đó (trừ một cái sai hẳn về bản chất dịch vụ), nên ràng buộc phân biệt thật sự là ít lớp trung gian nhất mà vẫn lọc được đúng .csv.

✅ Vì sao đáp án đúng là đúng

Phương án A — cấu hình S3 event notification cho sự kiện s3:ObjectCreated:Put, đặt suffix filter là .csv, và trỏ thẳng ARN của Lambda function làm đích.

• S3 event notification là tích hợp gốc, trực tiếp giữa S3 và Lambda: S3 tự gọi Lambda, không cần dịch vụ nào đứng giữa.
• Bộ lọc của S3 event notification hỗ trợ cả prefix (theo đường dẫn/thư mục) lẫn suffix (theo phần đuôi tên object). Đuôi .csv nằm ở cuối tên tệp, nên đúng loại lọc cần dùng là suffix. Nhờ vậy Lambda chỉ được gọi khi object mới là .csv, đúng yêu cầu "exclusively".
• Không có thành phần nào phải vận hành thêm, không có rule, không có state machine — đây chính là cấu hình có operational overhead thấp nhất trong danh sách.

❌ Vì sao các phương án còn lại sai

B — EventBridge rule bắt mọi hành động put trên S3, lọc theo prefix .csv. Đây là phương án gần đúng nhất và cần nói rõ nó hỏng ở hai chỗ. Thứ nhất, về mặt kỹ thuật EventBridge có nhận được sự kiện S3 và có gọi được Lambda, nhưng nó thêm một dịch vụ trung gian vào đường đi trong khi S3 đã kết nối thẳng được với Lambda — thừa so với tiêu chí "most efficient". Thứ hai, và nghiêm trọng hơn, phương án viết là lọc theo prefix .csv: prefix khớp phần đầu khoá object, còn .csv là phần đuôi. Lọc kiểu đó sẽ không bắt được tệp nào có tên bình thường như bao-cao.csv. Sai loại bộ lọc là sai chức năng, không chỉ là kém tối ưu.

C — S3 Lifecycle policy gọi Lambda. Sai về bản chất dịch vụ. Lifecycle policy dùng để quản lý vòng đời object: chuyển sang storage class rẻ hơn, hết hạn và xoá object, dọn multipart upload dở dang. Nó không phải cơ chế sự kiện và không có khả năng invoke Lambda khi có tệp mới được tải lên. Phương án này không chạy được, không phải "chạy được nhưng kém".

D — Step Functions state machine khởi động khi có .csv tải lên, Lambda là bước đầu. Đây là phương án hợp lệ về mặt kiến trúc nhưng thừa. Step Functions sinh ra để điều phối nhiều bước — rẽ nhánh, retry có trạng thái, chờ, gọi nhiều dịch vụ nối nhau. Ở đây chỉ có đúng một việc: gọi một Lambda để chuyển CSV sang Parquet. Bọc một hàm duy nhất trong một state machine nghĩa là thêm một tài nguyên phải định nghĩa, phải cấp quyền, phải theo dõi và phải trả tiền theo state transition — tăng cả độ phức tạp lẫn chi phí mà không đổi lại được gì. Ngoài ra bản thân state machine cũng không tự "nghe" S3: vẫn cần một lớp sự kiện phía trước, nên nó chỉ là A cộng thêm một tầng.

📌 Điểm cần nhớ

• Prefix lọc phần đầu, suffix lọc phần đuôi. Lọc theo phần mở rộng tệp (.csv, .json, .parquet) luôn phải dùng suffix filter; đề nào viết "prefix filter for .csv" là dấu hiệu phương án sai.
• Khi đề nói "least operational overhead", "most efficient" hay "minimize manual intervention", hãy chọn tích hợp trực tiếp giữa hai dịch vụ nếu có, thay vì chèn thêm một dịch vụ điều phối vào giữa.
• S3 Lifecycle ≠ S3 event notification. Lifecycle quản lý vòng đời lưu trữ (chuyển tier, hết hạn, xoá); event notification mới là cơ chế kích hoạt xử lý. Đừng để hai khái niệm này lẫn nhau.
• Step Functions chỉ đáng dùng khi có nhiều bước cần điều phối. Một Lambda đơn lẻ phản ứng với một sự kiện thì không cần state machine — đó là dấu hiệu over-engineering mà kỳ thi hay đưa vào làm mồi.

🧩 Phân tích nội dung câu hỏi

Đề mô tả một công ty làm ứng dụng di động, dùng Amazon DynamoDB làm nơi lưu dữ liệu người dùng. Yêu cầu: có cơ chế theo dõi và phản ứng với thay đổi dữ liệu theo thời gian thực, cụ thể là bắt được các sửa đổi ở mức item trong DynamoDB rồi kích hoạt một tiến trình xử lý ngay khi thay đổi xảy ra.

Ba cụm từ trong đề quyết định đáp án:

• "changes in the user data" — nguồn thay đổi nằm ở DynamoDB, không phải ở S3 hay ở một luồng dữ liệu nào khác. Cụm này loại ngay những phương án gắn cơ chế bắt sự kiện vào dịch vụ sai.
• "in real-time" / "as they occur" — phải là mô hình đẩy sự kiện (event-driven), không chấp nhận cơ chế chạy định kỳ rồi so sánh.
• "captures modifications to DynamoDB items and triggers a process" — cần đúng hai vế: capture (ghi lại chuỗi thay đổi ở mức item) và trigger (tự động gọi tiến trình xử lý). Phương án nào chỉ làm được một vế thì chưa đủ.

✅ Vì sao đáp án đúng là đúng

Đáp án đúng theo tệp là B — Activate DynamoDB Streams to capture changes and trigger an AWS Lambda function for real-time processing.

DynamoDB Streams là tính năng ngay trong DynamoDB: khi bật lên, nó ghi lại một chuỗi thay đổi ở mức item theo thứ tự thời gian của bảng — thêm mới (insert), cập nhật (update), xoá (delete) — và giữ các bản ghi đó trong một khoảng thời gian giới hạn để bên tiêu thụ đọc.

Điểm khiến nó khớp trọn vẹn đề bài là tích hợp gốc với AWS Lambda: bạn gắn stream làm event source cho một Lambda function, và Lambda được gọi tự động ngay khi có bản ghi thay đổi mới, không cần ai đi hỏi bảng xem có gì mới không. Đúng hai vế mà đề yêu cầu — capture do Streams lo, trigger do tích hợp Streams–Lambda lo — và độ trễ chỉ ở mức xử lý sự kiện chứ không phụ thuộc chu kỳ hẹn giờ nào.

❌ Vì sao các phương án còn lại sai

A — Amazon S3 event notifications để phản ứng với thay đổi trong bảng DynamoDB. Sai ở chỗ gắn nhầm dịch vụ nguồn. S3 event notifications chỉ phát sự kiện cho các thao tác trên object trong bucket S3 (tạo, xoá object…). Nó không có bất kỳ khả năng nào quan sát bảng DynamoDB. Dữ liệu trong đề nằm ở DynamoDB nên cơ chế này không bao giờ được kích hoạt — đây là phương án sai rõ ràng nhất, không phải kiểu "gần đúng".

C — Dùng AWS Lambda định kỳ poll bảng DynamoDB để tìm thay đổi. Đây là phương án gần đúng nhất và cũng là bẫy chính của câu hỏi: nó có đúng dịch vụ nguồn (DynamoDB) và đúng thành phần xử lý (Lambda). Chỗ hỏng nằm ở chữ "periodically poll", va thẳng vào ràng buộc real-time / as they occur:

• Mô hình kéo theo chu kỳ luôn sinh độ trễ bằng khoảng cách giữa hai lần chạy — thay đổi xảy ra ngay sau một lần poll phải chờ đến lượt sau.
• Nó tốn tài nguyên vô ích: phần lớn các lần chạy sẽ không tìm thấy gì mới, nhưng vẫn tiêu read capacity của bảng và thời gian chạy Lambda.
• Bản thân việc "tìm ra cái gì đã đổi" cũng phải tự dựng lấy (so sánh, đánh dấu timestamp), trong khi Streams cho sẵn chuỗi thay đổi có thứ tự.

D — Amazon Kinesis Data Firehose để capture và xử lý thay đổi trong DynamoDB. Firehose là dịch vụ giao nhận (delivery) dữ liệu streaming: nhận dữ liệu từ producer rồi nạp vào các đích lưu trữ/phân tích. Nó không phải là cơ chế bắt thay đổi (change capture) của DynamoDB — nó không tự quan sát bảng để biết item nào vừa đổi. Nói cách khác, Firehose có thể nằm ở phía sau trong một đường ống, nhưng bản thân nó không giải quyết được vế "capture modifications to DynamoDB items" mà đề yêu cầu.

📌 Điểm cần nhớ

• Bắt thay đổi ở mức item của DynamoDB theo thời gian thực = DynamoDB Streams. Đây là câu trả lời mặc định cho mọi đề có cụm "track changes in a DynamoDB table" + "real-time".
• Cặp DynamoDB Streams → Lambda là một tích hợp gốc, Lambda được gọi tự động khi có bản ghi mới trong stream. Nhận ra cặp này thì loại được ngay các phương án tự dựng cơ chế thủ công.
• Thấy chữ "poll" / "periodically" trong đề đòi real-time thì gần như chắc chắn là bẫy. Kiến trúc đúng trong tình huống này luôn là đẩy sự kiện, không phải hỏi theo chu kỳ.
• Cơ chế bắt sự kiện phải khớp với dịch vụ đang giữ dữ liệu. S3 event notifications chỉ dùng cho S3; Firehose là kênh giao nhận dữ liệu streaming chứ không phải công cụ quan sát thay đổi của một bảng DynamoDB.

🧩 Phân tích nội dung câu hỏi

Bối cảnh: một tập dữ liệu giao dịch thương mại điện tử nhiều petabyte nằm trên Amazon S3, được một AWS Glue job cập nhật hằng đêm, và đội phân tích truy vấn ad-hoc bằng Amazon Athena. Yêu cầu là giảm chi phí truy vấn Athena nhưng vẫn giữ dữ liệu làm mới mỗi hai giờ trong BI tools.

Có hai cụm từ trong đề quyết định đáp án:

1. "minimize Athena querying costs" — chi phí truy vấn Athena, không phải chi phí lưu trữ S3. Athena tính tiền theo lượng dữ liệu quét (data scanned) cho mỗi câu lệnh. Bất cứ phương án nào không làm giảm số byte Athena phải đọc thì đều không chạm tới khoản chi phí mà đề đang hỏi.
2. "without increasing infrastructure complexity" / "maintaining operational simplicity" — không được thêm bước xử lý, thêm pipeline hay thêm hệ thống mới.

Ghép hai ràng buộc lại: cần thứ gì đó cắt thẳng lượng dữ liệu quét, mà lại nằm sẵn trong cách tổ chức dữ liệu hiện có.

✅ Vì sao đáp án đúng là đúng

Đáp án đúng theo tệp là B — dùng data partitioning của Athena.

Partitioning tổ chức dữ liệu trên S3 theo các cột thường dùng để lọc (ngày, danh mục sản phẩm, khu vực…). Khi truy vấn có mệnh đề WHERE khớp với cột phân vùng, Athena chỉ đọc đúng những prefix S3 tương ứng và bỏ qua hoàn toàn phần còn lại — kỹ thuật partition pruning. Với tập dữ liệu nhiều petabyte, chênh lệch giữa "quét cả kho" và "quét đúng vài phân vùng của ngày cần xem" là rất lớn, mà mô hình giá của Athena lại tính theo chính lượng byte đó.

Về mặt vận hành, đây cũng là lựa chọn nhẹ nhàng nhất trong danh sách: Glue job đang chạy hằng đêm chỉ cần ghi dữ liệu vào cấu trúc thư mục theo phân vùng và cập nhật metadata trong Data Catalog. Không phát sinh dịch vụ mới, không đổi định dạng file, không ảnh hưởng nhịp làm mới mỗi hai giờ của BI tools.

❌ Vì sao các phương án còn lại sai

A — Athena Workgroups để kiểm soát chi phí. Workgroups tách biệt việc thực thi truy vấn giữa các nhóm người dùng, phân quyền, và cho phép đặt hạn mức dữ liệu quét cho mỗi truy vấn hoặc theo nhóm. Nhưng đó là kiểm soát và chặn chi tiêu, không phải giảm chi phí: cùng một truy vấn vẫn quét đúng bấy nhiêu byte và vẫn tính tiền đúng bấy nhiêu; vượt hạn mức thì truy vấn bị huỷ chứ không rẻ đi. Đề hỏi cách minimize cost, không hỏi cách đặt trần ngân sách.

C — S3 Intelligent-Tiering. Đây là phương án dễ nhầm nhất vì nó thật sự tiết kiệm tiền — nhưng là tiền lưu trữ, bằng cách tự chuyển dữ liệu ít truy cập sang tầng rẻ hơn. Giá truy vấn Athena được xác định bởi lượng dữ liệu quét, không phụ thuộc dữ liệu nằm ở access tier nào. Nó nhắm sai loại chi phí mà đề đang hỏi.

D — Chuyển sang định dạng cột như Apache ORC. Đây là phương án gần đúng nhất về mặt kỹ thuật: định dạng cột (ORC, Parquet) thực sự làm giảm dữ liệu quét, vì Athena chỉ đọc những cột được truy vấn thay vì cả dòng, lại thêm nén tốt. Nó hỏng ở vế thứ hai của đề: chuyển đổi cả tập dữ liệu nhiều petabyte là một tiến trình chuyển đổi lớn, phải sửa Glue job và có chi phí xử lý một lần đáng kể — nặng hơn hẳn về mặt operational overhead so với việc phân vùng. Với ràng buộc "không tăng độ phức tạp hạ tầng", partitioning là lựa chọn thắng.

📌 Điểm cần nhớ

• Athena tính tiền theo lượng dữ liệu quét. Gặp câu hỏi "giảm chi phí Athena", hãy tìm phương án cắt được số byte đọc: partitioning, định dạng cột, nén, hoặc lọc bớt file — chứ không phải phương án đụng tới lưu trữ hay quản trị.
• Phân biệt chi phí lưu trữ và chi phí truy vấn. S3 Intelligent-Tiering, Glacier, lifecycle policy đều thuộc nhóm lưu trữ; chúng không làm truy vấn Athena rẻ đi.
• Kiểm soát chi phí ≠ giảm chi phí. Workgroups và data usage limit đặt trần và cảnh báo, hữu ích cho quản trị, nhưng không hạ đơn giá của một truy vấn đã chạy.
• Khi đề nhấn "operational simplicity", hãy so sánh công sức triển khai giữa các phương án đều đúng về kỹ thuật. Partitioning và định dạng cột thường đi cùng nhau trong thực tế, nhưng khi đề bắt chọn một và ưu tiên đơn giản, partitioning là bước rẻ và ít xáo trộn hơn.

🧩 Phân tích nội dung câu hỏi

Đội phân tích của một tập đoàn bán lẻ để dữ liệu giao dịch trong Amazon S3, chạy Amazon EMR với Apache Hive cho nhu cầu batch processing. Họ cần một hệ thống quản lý metadata để định nghĩa, tổ chức và truy vấn cấu trúc dữ liệu.

Cụm từ quyết định nằm ở câu hỏi cuối: "manage their metadata effectively and ensure compatibility with Hive" — tức là thứ cần chọn phải (1) là một metadata store thật sự, chứ không phải một lớp truy cập dữ liệu, và (2) phải tương thích với Hive Metastore, chứ không phải một kho lưu trữ chung chung mà bạn tự viết code ghép vào.

Thêm một tín hiệu phụ: đề nhấn mạnh "manage effectively" — trong đề thi AWS, khi hai phương án cùng làm được việc thì phương án managed, ít vận hành hơn, thường là đáp án.

✅ Vì sao đáp án đúng là đúng

A. Cấu hình EMR cluster dùng AWS Glue Data Catalog thay thế Hive Metastore.

Glue Data Catalog là một metadata store bền vững, tương thích với Apache Hive Metastore và được tích hợp sẵn với Amazon EMR — bạn chỉ cần bật tuỳ chọn khi tạo cluster, Hive sẽ đọc/ghi bảng, partition, schema qua Glue thay vì qua metastore cục bộ. Đây đúng nghĩa "drop-in replacement": không phải viết lại query, không phải đổi cách Hive hoạt động.

Lợi ích so với tự dựng metastore:

• Là dịch vụ fully managed: không phải tự lo scaling, patching, backup cho một database riêng.
• Tập trung: nhiều EMR cluster (kể cả cluster tạm thời, dựng lên rồi huỷ) cùng dùng chung một catalog, nên metadata không chết theo cluster.
• Có thêm khả năng tìm kiếm/khám phá dataset, quản lý schema, và dùng chung với các dịch vụ analytics khác của AWS — cùng một định nghĩa bảng, nhiều engine đọc được.

❌ Vì sao các phương án còn lại sai

B. Dùng EMRFS để quản lý Hive metadata cùng chỗ với dữ liệu giao dịch trong S3.

Đây là nhầm lẫn giữa dữ liệu và metadata. EMRFS là lớp triển khai cho phép Hadoop/EMR đọc ghi dữ liệu nằm trên Amazon S3 như một hệ thống tệp — nó giải quyết chuyện truy cập dữ liệu, hoàn toàn không phải một hệ thống quản lý metadata và không thay thế được chức năng của Hive Metastore. Bật EMRFS xong bạn vẫn phải trả lời câu hỏi "bảng này định nghĩa ở đâu, cột gì, partition nào" — mà đó chính là câu hỏi đề bài đang hỏi.

C. Dựng một Amazon RDS instance làm external Hive Metastore.

Đây là phương án gần đúng nhất và cũng là bẫy chính của câu này. Về mặt kỹ thuật nó chạy được thật: dùng RDS làm external metastore cho Hive là một mô hình hợp lệ và được hỗ trợ, cũng giải quyết được chuyện metadata sống lâu hơn cluster.

Nó hỏng ở chỗ chi phí vận hành: bạn phải tự lo scaling, backup, patching, giám sát cho instance đó, tự quản lý kết nối và bảo mật tới nó, và metadata chỉ nằm riêng cho ngăn xếp Hive của bạn chứ không được các dịch vụ analytics khác dùng lại. Glue Data Catalog làm đúng việc đó nhưng ở dạng managed và tích hợp sẵn với EMR — trong bối cảnh đề bài chỉ nêu nhu cầu quản lý metadata thông thường, không nêu ràng buộc đặc biệt nào bắt buộc phải tự vận hành metastore, chọn C là tự chuốc thêm việc.

D. Dùng Amazon DynamoDB để lưu và quản lý Hive metadata.

DynamoDB là NoSQL key-value/document, hợp với ứng dụng cần độ trễ thấp và ổn định ở mọi quy mô. Nó không phải kho metadata cho Hive: Hive không nói chuyện với DynamoDB theo giao thức metastore, nên muốn dùng bạn phải tự viết một lớp triển khai riêng — vừa tốn công, vừa mong manh, trong khi đã có sẵn giải pháp managed đúng chuẩn. Đề bài yêu cầu "ensure compatibility with Hive", và một kho tự chế thì không có sẵn tính tương thích đó.

📌 Điểm cần nhớ

• Metadata ≠ data. EMRFS lo việc EMR đọc dữ liệu trên S3; Hive Metastore (hoặc Glue Data Catalog) lo việc mô tả dữ liệu đó là bảng gì, cột gì, partition nào. Câu hỏi hỏi cái nào thì trả lời cái đó.
• Glue Data Catalog là Hive-metastore-compatible và tích hợp sẵn với EMR — đây là lựa chọn mặc định khi đề nói "quản lý metadata cho Hive trên EMR".
• Khi hai phương án cùng chạy được, đề thi AWS thường ưu tiên phương án managed, ít vận hành hơn: RDS-as-metastore đúng kỹ thuật nhưng thua Glue về operational overhead, trừ khi đề nêu lý do rõ ràng phải tự vận hành.
• Đừng chọn dịch vụ lưu trữ tổng quát để làm việc chuyên biệt. DynamoDB lưu được mọi thứ, nhưng "lưu được" khác với "tương thích sẵn" — phương án nào đòi tự viết lớp tích hợp thì gần như luôn sai trong đề trắc nghiệm.

🧩 Phân tích nội dung câu hỏi

Một agency marketing chạy các truy vấn ad-hoc bằng Amazon Athena trên dữ liệu trong Amazon S3. Yêu cầu: các phòng ban khác nhau trong cùng một AWS account chỉ được xem và chạy truy vấn liên quan tới dự án của mình.

Cụm từ quyết định nằm ở vế cuối của câu mô tả yêu cầu: "cannot access others' query logs or results" — không được xem lịch sử truy vấn và kết quả truy vấn của phòng ban khác. Đây mới là ràng buộc phân biệt, bởi cả bốn phương án đều là những cách hợp lệ để phân tách quyền truy cập dữ liệu. Chỉ có một phương án chạm tới lớp thực thi truy vấn và lịch sử truy vấn của Athena.

Thêm một cụm phụ trợ: "within their shared AWS account" — không được tách account, mọi thứ phải giải quyết bằng cơ chế phân quyền bên trong một account duy nhất.

Nói cách khác, đề đang hỏi: cơ chế nào của Athena tách được workload chứ không chỉ tách data.

✅ Vì sao đáp án đúng là đúng

Đáp án C — tạo một Athena workgroup riêng cho mỗi phòng ban và gắn IAM policy cho từng workgroup.

Workgroup là cơ chế của chính Athena dùng để tách biệt khối lượng công việc theo team hoặc theo ứng dụng. Mỗi truy vấn chạy trong Athena đều thuộc về đúng một workgroup, và workgroup là ranh giới cho:

• quyền chạy truy vấn (ai được submit query vào workgroup nào),
• lịch sử truy vấn (query history) — truy vấn của một workgroup không hiện trong workgroup khác,
• cấu hình nơi ghi kết quả truy vấn trong S3.

Vì workgroup là một resource có ARN riêng, ta gắn IAM policy tham chiếu tới ARN đó để cấp cho mỗi phòng ban quyền trên đúng workgroup của họ. Kết quả là phòng ban A không nhìn thấy truy vấn, lịch sử hay kết quả của phòng ban B — đúng cái mà đề đòi hỏi, và làm được ngay trong một AWS account chung.

❌ Vì sao các phương án còn lại sai

A. S3 access points cho từng phòng ban, gắn IAM policy để quản lý quyền chạy truy vấn. S3 access point là cách quản lý truy cập vào tập dữ liệu trong S3 — nó nằm ở tầng lưu trữ. Vế "để quản lý quyền thực thi truy vấn" trong phương án này là cách diễn đạt sai bản chất: access point không biết gì về việc ai chạy query nào trong Athena, và không cung cấp độ chi tiết cần thiết để kiểm soát query execution cũng như query history.

B. Tạo một Glue Data Catalog database riêng cho mỗi phòng ban, dùng IAM policy kiểm soát từng database. Đây là phương án gần đúng nhất và đúng ở một nửa: tách database trong Glue Data Catalog thực sự giúp tổ chức dữ liệu và giới hạn phòng ban nhìn thấy metadata/bảng nào. Nhưng nó hỏng ở chỗ chỉ kiểm soát đối tượng dữ liệu được truy vấn, không kiểm soát quy trình truy vấn và lịch sử truy vấn — trong khi đó lại là yêu cầu then chốt của đề.

D. Chia dữ liệu theo prefix S3 cho từng phòng ban, tạo IAM role tương ứng. Cũng là phương án gần đúng, và thường được dùng kèm trong thực tế. Vấn đề giống B nhưng ở tầng thấp hơn: prefix + IAM role quản lý được quyền đọc bản thân dữ liệu, nhưng không tách được tiến trình truy vấn, cũng không chặn được phòng ban này xem query history của phòng ban kia. Một người vẫn có thể thấy lịch sử truy vấn dùng chung dù không đọc nổi dữ liệu bên dưới.

📌 Điểm cần nhớ

• Khi đề Athena nhắc tới query history / query results / query execution, hãy nghĩ tới workgroup trước tiên — đó là ranh giới cách ly workload của Athena, và nó có ARN nên gắn IAM policy được.
• Phân biệt rõ ba tầng khi làm bài dạng này: dữ liệu (S3 prefix, S3 access point), metadata (Glue Data Catalog database/table), và truy vấn (Athena workgroup). Yêu cầu của đề rơi vào tầng nào thì chọn công cụ của tầng đó.
• Tách dữ liệu không tự động tách được lịch sử truy vấn. Hai phương án "gần đúng" (Glue database, S3 prefix) đều rơi vào cái bẫy này.
• "Shared AWS account" là tín hiệu loại bỏ mọi hướng tách account; phải giải quyết bằng IAM policy trỏ tới resource ARN bên trong account.

🧩 Phân tích nội dung câu hỏi

Đề mô tả một doanh nghiệp phân tích dữ liệu lớn đang chuyển từ data center tại chỗ lên AWS, muốn giảm độ phức tạp vận hành và ưu tiên kiến trúc serverless bất cứ khi nào có thể. Hệ thống hiện tại chạy Apache Pig, Oozie, Spark, HBase và Flink, xử lý khối lượng dữ liệu ở mức petabyte với yêu cầu tốc độ cao.

Cụm từ quyết định nằm ngay ở câu hỏi cuối: "achieve serverless ETL at scale". Đây là một câu hỏi mang tính định danh dịch vụ — đề không hỏi "lưu trữ ở đâu", "truy vấn ra sao" hay "xử lý luồng thời gian thực thế nào", mà hỏi dịch vụ nào đóng vai trò ETL (extract – transform – load) và đồng thời serverless. Hai ràng buộc này phải thoả cùng lúc.

Ràng buộc thứ hai hỗ trợ thêm: danh sách framework hiện có xoay quanh Apache Spark. Dịch vụ đích lý tưởng nên chạy được job Spark để việc di trú không phải viết lại từ đầu.

✅ Vì sao đáp án đúng là đúng

Đáp án đúng theo tệp là D — Use AWS Glue for serverless ETL operations.

AWS Glue là dịch vụ ETL được quản lý hoàn toàn, không cần người dùng cấp phát hay vá cụm máy chủ — đúng nghĩa serverless, khớp với mong muốn cắt giảm gánh nặng quản trị mà đề nêu ra. Glue lo việc phân loại, làm sạch, làm giàu và di chuyển dữ liệu, tức là bao trọn vòng đời ETL chứ không chỉ một mắt xích.

Về quy mô, Glue được thiết kế để xử lý khối lượng dữ liệu rất lớn và tự co giãn theo tải, nên đáp ứng được yêu cầu "hiệu năng tương đương hoặc tốt hơn" mà đề đặt ra so với hệ thống tại chỗ.

Điểm ăn khớp mạnh nhất: engine xử lý của Glue dựa trên Apache Spark. Doanh nghiệp đang dùng Spark, nên các job hiện có có thể chuyển sang Glue mà không phải xây lại logic biến đổi dữ liệu từ con số không. Đây chính là lý do Glue nổi bật hơn hẳn ba phương án còn lại trong bối cảnh cụ thể của đề.

❌ Vì sao các phương án còn lại sai

A — Amazon S3 với S3 Select. S3 là dịch vụ lưu trữ, còn S3 Select chỉ cho phép lấy về một tập con của dữ liệu trong một đối tượng thay vì tải nguyên đối tượng. Đó là tối ưu hoá việc đọc, không phải năng lực biến đổi. Nó không thay thế được vai trò của Pig hay Oozie trong luồng ETL hiện tại — không có bước transform, không có điều phối job. Chọn A là nhầm lẫn giữa nơi chứa dữ liệu và công cụ xử lý dữ liệu.

B — Amazon Kinesis Data Analytics. Đây là phương án gần đúng nhất về mặt "có xử lý dữ liệu", và nó hấp dẫn vì đề có nhắc Apache Flink — Kinesis Data Analytics đúng là chạy Flink. Nhưng nó hỏng ở chỗ: dịch vụ này hướng tới phân tích thời gian thực trên dữ liệu luồng, trong khi bài toán của doanh nghiệp là ETL trên khối dữ liệu petabyte, tức nghiêng về xử lý theo lô. Nó cũng không phủ được phần còn lại của ngăn xếp (Pig, Oozie, Spark) mà chỉ giải quyết mảnh streaming. Chọn B là bám vào một chi tiết phụ trong đề và bỏ qua yêu cầu chính "serverless ETL".

C — Amazon Athena. Athena đúng là serverless, nên nếu chỉ đọc lướt chữ "serverless" thì phương án này trông rất hợp lệ — đây là bẫy chính của câu hỏi. Vấn đề: Athena là dịch vụ truy vấn tương tác bằng SQL trên dữ liệu nằm sẵn trong S3, không phải dịch vụ ETL. Nó phục vụ việc đọc và phân tích, chứ không đảm nhiệm được quy trình làm sạch, làm giàu, điều phối và nạp dữ liệu, cũng không thay thế được các framework như Pig hay Oozie. Athena thoả một nửa yêu cầu (serverless) nhưng trượt nửa còn lại (ETL).

📌 Điểm cần nhớ

• Khi đề hỏi thẳng "serverless ETL", hãy tách thành hai điều kiện và kiểm tra từng phương án theo cả hai. Athena, S3 Select đều serverless nhưng không phải ETL; loại chúng bằng vế thứ hai.
• Phân biệt vai trò: S3 = lưu trữ, Athena = truy vấn tương tác, Kinesis Data Analytics = phân tích luồng thời gian thực, AWS Glue = ETL được quản lý. Ranh giới này giải quyết được rất nhiều câu trong Domain 1.
• Đề nhắc tới Apache Spark trong ngăn xếp hiện tại là một tín hiệu mạnh trỏ về Glue, vì Glue chạy trên nền Spark nên job cũ di trú được mà không phải viết lại.
• Cảnh giác với chi tiết gài bẫy: đề liệt kê Flink chỉ để mô tả hiện trạng, không có nghĩa đáp án phải là dịch vụ chạy Flink. Luôn quay lại câu hỏi cuối cùng để biết đề thực sự đang hỏi gì.

🧩 Phân tích nội dung câu hỏi

Đề mô tả một tình huống rất quen: dữ liệu .csv mới đổ vào S3, có cột timestamp, dữ liệu cũ bị xoá hằng ngày, và cần chuyển đổi định dạng để truy vấn nhanh hơn.

Cụm từ quyết định đáp án là "most cost-effective" (tiết kiệm chi phí nhất). Cả bốn phương án đều làm được việc chuyển CSV → Parquet và partition theo timestamp — về mặt kỹ thuật không phương án nào là bất khả thi. Vì vậy câu này không hỏi "cái nào chạy được" mà hỏi "cái nào rẻ và ít việc phải quản lý nhất".

Hai cụm phụ cũng đáng chú ý:

• "reformat ... for more efficient analytics" → đích đến là định dạng cột (columnar) như Parquet, đọc ít dữ liệu hơn khi truy vấn.
• "older data is removed daily" → gợi ý phải partition theo timestamp, vì xoá theo partition rẻ hơn và gọn hơn xoá theo từng dòng.

Cả hai yêu cầu này đều nằm sẵn trong mọi phương án, nên chúng chỉ xác nhận hướng đi chứ không phân biệt được đáp án. Ràng buộc phân biệt duy nhất vẫn là chi phí và mức độ phải vận hành hạ tầng.

✅ Vì sao đáp án đúng là đúng

D — Athena CTAS query, Parquet + Snappy, partition theo timestamp.

CREATE TABLE AS SELECT của Athena làm đúng ba việc đề yêu cầu, trong một câu lệnh SQL duy nhất:

• Đọc dữ liệu .csv đang nằm trong S3 và ghi ra Parquet với nén Snappy — Parquet là định dạng cột nên truy vấn chỉ quét những cột cần dùng, còn Snappy giảm dung lượng lưu trữ mà vẫn giải nén nhanh.
• Khai báo partition ngay trong câu CTAS, nên dữ liệu ra được xếp theo timestamp. Khi xoá dữ liệu cũ hằng ngày, chỉ cần bỏ nguyên prefix của partition đó trên S3.
• Kết quả ghi thẳng trở lại S3, không cần chuyển dữ liệu đi đâu khác.

Điểm mấu chốt về chi phí: Athena là dịch vụ serverless, tính tiền theo lượng dữ liệu quét khi chạy truy vấn. Không có cluster để dựng, không có worker để cấp phát, không trả tiền cho thời gian nhàn rỗi. Với một tác vụ chuyển đổi định dạng thẳng thớm như trong đề, đó là cách rẻ nhất và ít thao tác vận hành nhất trong bốn lựa chọn.

❌ Vì sao các phương án còn lại sai

A — EMR Spark job. Đây là phương án nặng nhất. EMR là nền tảng cluster có quản lý để chạy các framework big data như Apache Spark; Spark hoàn toàn viết được Parquet có partition. Nhưng bạn phải dựng cluster, chọn kiểu instance, chỉnh cấu hình, và trả tiền cho các node trong suốt thời gian cluster sống — kể cả phần thời gian dựng và dọn. EMR chỉ đáng đồng tiền khi khối lượng xử lý lớn và logic phức tạp. Đổi một mớ CSV sang Parquet thì không cần tới ngần ấy bộ máy, nên nó thua ở đúng tiêu chí "most cost-effective".

B — AWS Glue. Đây là phương án gần đúng nhất và cũng là bẫy chính của câu này. Glue là dịch vụ ETL có quản lý, chuyển CSV → Parquet và partition theo timestamp là việc kinh điển của nó, không hề sai về mặt kỹ thuật. Chỗ nó hỏng là ở tiêu chí so sánh: Glue job chạy trên các đơn vị xử lý được cấp phát và tính tiền theo thời gian chạy, kèm theo phần việc phải viết và bảo trì job (script, phiên bản, cấu hình). So với một câu CTAS gõ ra là xong, Glue thừa cả về công sức lẫn chi phí cho một tác vụ chuyển đổi đơn giản. Nếu đề bỏ chữ "most cost-effective" và thay bằng một pipeline ETL nhiều bước có làm sạch, join, xử lý schema thay đổi, thì Glue mới là câu trả lời.

C — Lambda chạy hằng ngày. Nghe thì hợp lý vì "dữ liệu cũ xoá hằng ngày" trùng với nhịp chạy hằng ngày của Lambda. Nhưng Lambda sinh ra cho các đoạn xử lý ngắn, theo sự kiện; nó bị chặn bởi giới hạn thời gian chạy và bộ nhớ của một lần gọi. Chuyển đổi định dạng cả một tập dữ liệu analytics rất dễ vượt qua các giới hạn đó, và khi ấy bạn phải tự chia nhỏ công việc, tự quản lý trạng thái, tự xử lý phần chạy dở — biến một câu SQL thành cả một hệ thống nhỏ phải bảo trì. Athena CTAS không vướng các giới hạn kiểu này.

📌 Điểm cần nhớ

• Khi đề hỏi "most cost-effective" mà cả bốn phương án đều làm được việc, hãy xếp hạng theo mức độ phải quản lý hạ tầng: Athena (serverless, trả theo truy vấn) < Glue (job có quản lý, trả theo thời gian chạy) < EMR (cluster, trả theo node).
• Athena CTAS là công cụ mặc định cho bài toán "đổi CSV/JSON sang Parquet/ORC, có nén, có partition, kết quả để lại trên S3" — một câu SQL, không hạ tầng.
• Parquet + Snappy + partition là bộ ba chuẩn để tối ưu truy vấn analytics trên S3: Parquet giảm lượng dữ liệu quét theo cột, Snappy giảm dung lượng lưu trữ, partition giúp loại bỏ hẳn dữ liệu không liên quan và khiến việc xoá dữ liệu cũ theo chu kỳ trở thành xoá cả partition.
• Lambda không phải công cụ chuyển đổi dữ liệu lớn. Thấy phương án Lambda trong bài toán biến đổi cả tập dữ liệu, hãy nghĩ ngay tới giới hạn thời gian chạy và bộ nhớ của một lần gọi.
• Phân biệt Glue và Athena CTAS: pipeline ETL nhiều bước, có làm sạch và lịch chạy → Glue; chuyển đổi định dạng một lần, thẳng thớm, ưu tiên rẻ → Athena CTAS.