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

Tuần 5 - Ngày 4: DynamoDB cho Data Engineering

Tuần 5 – Ngày 4

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

  • Ôn nhanh DynamoDB: key schema, capacity modes, GSI/LSI
  • Nắm góc data engineering: Streams, export to S3, zero-ETL, TTL
  • Hiểu hot partition và thiết kế key
  • Biết khi nào DynamoDB đúng/sai vai trong pipeline

1. Ôn nhanh nền tảng

  • NoSQL key-value/document, latency ms một chữ số, scale ngang tự động
  • Partition key (bắt buộc, quyết định phân phối) + sort key (tùy chọn, sắp xếp trong partition)
  • Capacity: On-demand (trả theo request, không dự đoán) vs Provisioned (+auto scaling, rẻ hơn khi đều; RCU/WCU)
  • GSI: khóa khác để query — capacity riêng, eventual consistency; LSI: cùng partition key, sort key khác (tạo lúc create table)
  • DAX: cache đọc microsecond
  • 1 item ≤ 400KB — dữ liệu to để S3, DynamoDB giữ pointer/metadata

Hot partition

Partition key kém phân tán (một khách hàng khổng lồ, khóa ngày) → throttle (ProvisionedThroughputExceededException) dù tổng capacity thừa — giống hot shard Kinesis. Fix: key cardinality cao, write sharding (thêm suffix), adaptive capacity của DynamoDB giúp một phần nhưng không cứu key quá lệch.

2. DynamoDB trong pipeline dữ liệu

Đưa dữ liệu RA khỏi DynamoDB (analytics)

CáchĐặc điểmKhi dùng
Export to S3Export từ PITR backup, KHÔNG ăn RCU, ra DynamoDB JSON/Amazon Ion (full hoặc incremental export)Phân tích batch định kỳ trên Athena/Glue
DynamoDB Streams + LambdaCDC item-level, 24h retention, gần realtimePhản ứng sự kiện, sync search index
Kinesis Data Streams for DynamoDBĐẩy CDC vào KDS → hệ Kinesis (Firehose, Flink)CDC cần retention dài/fan-out lớn
Zero-ETL → Redshift / OpenSearchManaged replication liên tụcAnalytics/search không tự dựng pipeline
Athena federated queryQuery tại chỗ qua connectorAd-hoc, nhỏ
Scan bảng bằng GlueĂn RCU, chậm, đắtTránh — dùng export to S3

Bẫy kinh điển: "phân tích toàn bộ bảng DynamoDB bằng Athena/Glue" → export to S3 (không tốn RCU, không ảnh hưởng production) chứ KHÔNG scan trực tiếp.

Đưa dữ liệu VÀO DynamoDB

  • Batch: Glue/EMR ghi (BatchWriteItem), hoặc import from S3 (tạo bảng mới từ file S3, không ăn WCU)
  • Streaming: Lambda consumer từ Kinesis ghi vào bảng (kết quả aggregate realtime cho serving)

TTL

  • Tự xóa item hết hạn theo attribute epoch — miễn phí WCU; item xóa bởi TTL xuất hiện trong Streams (phân biệt được) → pattern "dữ liệu nóng 30 ngày trong DynamoDB, bản lưu dài hạn trên S3 qua Streams/Firehose"

3. Vai trò điển hình trong kiến trúc data

(1)SERVINGLAYER:kếtquảaggregatetừFlink/Glue──►DynamoDB──►APIlatencythấp(2)METADATA/STATE:idempotencymarker,jobstate,checkpoint(KCLleasetable)(3)NGUỒNCDC:DynamoDB──Streams/KDS──►lake/warehouse/OpenSearch

DynamoDB không phải engine analytics: không JOIN, không aggregate SQL — câu hỏi "complex analytical queries on DynamoDB data" luôn dẫn về export/zero-ETL sang công cụ khác.

Câu hỏi ôn tập

  1. Cần phân tích hằng ngày toàn bộ bảng DynamoDB 2TB bằng Athena mà không ảnh hưởng ứng dụng production. Giải pháp?

    Xem đáp án

    DynamoDB export to S3 (yêu cầu bật PITR): export chạy từ backup nên không tiêu thụ RCU, không ảnh hưởng bảng; kết quả (DynamoDB JSON/Ion) query bằng Athena hoặc convert Parquet bằng Glue. Có incremental export cho các lần sau. Scan bằng Glue connector ăn RCU lớn — sai với "không ảnh hưởng production".

  2. Mỗi thay đổi item cần cập nhật chỉ mục tìm kiếm gần realtime. Các lựa chọn?

    Xem đáp án

    (1) Zero-ETL integration DynamoDB → OpenSearch Service — managed, ít vận hành nhất; (2) DynamoDB Streams + Lambda ghi vào OpenSearch — linh hoạt custom; (3) Kinesis Data Streams for DynamoDB nếu cần fan-out/retention dài. Đề nhấn "least operational overhead" → zero-ETL.

  3. Ứng dụng ghi log phiên với khóa date (ngày hiện tại) bị throttle giờ cao điểm dù capacity thừa. Vì sao và sửa?

    Xem đáp án

    Hot partition: mọi ghi trong ngày dồn vào một partition key (date hôm nay). Sửa: thiết kế key phân tán — partition key là session_id/user_id (cardinality cao), hoặc write sharding: date#<random 0-9> rồi gộp khi đọc. Tăng WCU không giải quyết vì giới hạn throughput là per-partition.

  4. Dữ liệu sự kiện chỉ cần "nóng" 30 ngày cho API, nhưng phải lưu vĩnh viễn cho phân tích. Kiến trúc?

    Xem đáp án

    DynamoDB giữ 30 ngày với TTL tự xóa (miễn phí WCU); dòng dữ liệu vào song song ghi xuống S3 (vd nguồn Kinesis → Firehose → S3, DynamoDB chỉ là serving) — hoặc bắt Streams (kể cả sự kiện TTL delete) → Firehose → S3. Athena phân tích trên S3; DynamoDB gọn và rẻ vì chỉ giữ dữ liệu nóng.

  5. Khi nào chọn on-demand thay vì provisioned capacity?

    Xem đáp án

    On-demand: traffic không dự đoán/gai, bảng mới chưa rõ pattern, muốn zero capacity management — trả per-request. Provisioned (+auto scaling): traffic đều/dự đoán được, khối lượng lớn ổn định — rẻ hơn đáng kể, thêm reserved capacity càng rẻ. Tương tự logic Kinesis on-demand vs provisioned.

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

  • Tạo bảng demo, bật PITR, chạy export to S3 và query kết quả bằng Athena
  • Bật TTL với attribute expire_at, ghi item hết hạn ngắn và quan sát tự xóa
  • Thiết kế key schema cho bảng clickstream 100K events/s — viết lý do chọn partition key
  • Đọc DynamoDB zero-ETL integrations

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

Tiếp theo: OpenSearch và lựa chọn Data Store