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

Tuần 4 - Ngày 4: Lambda cho ETL nhẹ

Tuần 4 – Ngày 4

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

  • Biết giới hạn Lambda quyết định "dùng được cho ETL hay không"
  • Pattern event-driven ETL: S3 event → Lambda; Kinesis/SQS → Lambda
  • Xử lý lỗi: retry, DLQ, destination, idempotency
  • Nhận diện khi nào Lambda là sai công cụ (chuyển Glue/EMR/Flink)

1. Giới hạn Lambda phải thuộc

Giới hạnGiá trịHệ quả cho ETL
Timeout15 phút maxJob dài hơn → Glue/EMR/Step Functions chia nhỏ
Memory128MB - 10GB (CPU tỷ lệ theo)Dữ liệu phải xử lý streaming/chunk, không load file khổng lồ
/tmp storage512MB - 10GBFile tạm giới hạn
Payload sync6MB (response/request)Truyền data lớn qua S3, không qua payload
Concurrency1,000 mặc định/region (tăng được)Fan-out lớn cần để ý throttle
Deployment250MB unzipped (container image: 10GB)Thư viện nặng (pandas, pyarrow) → layer/container image

Quy tắc thi: thấy "processing takes ~30 minutes" hoặc "hundreds of GB per run" → Lambda SAI; chọn Glue/EMR. Lambda hợp: file nhỏ-vừa, per-event, < 15 phút.

2. Pattern event-driven ETL với Lambda

S3 event → Lambda (per-file processing)

File CSV đến s3://raw/incoming/
      │ S3 Event Notification (hoặc qua EventBridge)
      ▼
   Lambda: validate → transform nhẹ → ghi s3://curated/
      │ lỗi?
      ▼
   Retry (async: 2 lần) → On-failure destination / DLQ (SQS)
  • Async invocation (S3 event): tự retry 2 lần; cấu hình on-failure destination (SQS/SNS/EventBridge/Lambda) hoặc DLQ để không mất event lỗi
  • File lớn: chỉ dùng Lambda làm router/trigger (vd start Glue job), không tự xử lý

SQS → Lambda (buffer + throttle control)

  • SQS đứng giữa để hấp thụ burst, batch (tới 10 msg), kiểm soát concurrency (maximum concurrency per event source)
  • Partial batch response (ReportBatchItemFailures): chỉ retry message lỗi trong batch, không retry cả batch
  • Poison message → DLQ của SQS (maxReceiveCount)

Kinesis → Lambda

Đã học tuần 3: batch size/window, parallelization factor, bisect on error, on-failure destination; lỗi chặn shard (blocking) nếu không cấu hình — khác SQS.

Lambda trong pipeline lớn

  • Bước glue code trong Step Functions (gọi API, validate, quyết định nhánh)
  • Firehose transform (đã học)
  • Trigger: EventBridge schedule thay cron server

3. Idempotency — chủ đề vàng của DEA

Mọi nguồn event (S3, SQS standard, Kinesis) đều là at-least-once → Lambda có thể nhận duplicate. Code phải idempotent:

  • Ghi output deterministic (cùng input → cùng key S3, ghi đè thay vì append)
  • Conditional write: DynamoDB attribute_not_exists / S3 precondition để bỏ qua bản ghi đã xử lý
  • Lưu processed marker (idempotency key = event id) vào DynamoDB với TTL
  • Với SQS FIFO: deduplication ID giúp phía queue, nhưng consumer vẫn nên idempotent

4. Khi nào Lambda là ĐÚNG công cụ (tổng kết)

Tình huốngLambda?
Validate/convert từng file nhỏ khi upload
Gọi API làm giàu dữ liệu per-event
Route/filter event, trigger job khác
Transform record trong Firehose
Batch join 500GB hai bảng❌ Glue/EMR
Windowed aggregation 30 phút stateful❌ Flink
Job chạy 45 phút❌ Glue (hoặc chia nhỏ bằng Step Functions)
Nạp warehouse bằng INSERT từng dòng❌ COPY batch

Câu hỏi ôn tập

  1. Pipeline dùng Lambda xử lý file khi upload S3; thỉnh thoảng file 20GB làm Lambda timeout. Kiến trúc sửa thế nào?

    Xem đáp án

    Lambda 15 phút/10GB không hợp file lớn. Sửa: Lambda chỉ làm trigger — nhận S3 event rồi start Glue job (hoặc Step Functions/EMR Serverless) xử lý file lớn; hoặc bỏ Lambda, dùng EventBridge → Glue workflow trực tiếp. Giữ Lambda cho file nhỏ bằng cách rẽ nhánh theo size (lấy từ event) nếu muốn tối ưu chi phí.

  2. Lambda đọc SQS: một message hỏng làm cả batch retry mãi. Hai cấu hình để xử lý?

    Xem đáp án

    (1) Partial batch response (ReportBatchItemFailures) — Lambda báo riêng message lỗi, message thành công trong batch không bị retry lại; (2) DLQ trên SQS với maxReceiveCount — message hỏng (poison) sau N lần nhận bị chuyển sang DLQ để phân tích, không chặn queue.

  3. S3 event có thể gửi trùng; Lambda ghi kết quả vào DynamoDB. Làm sao tránh xử lý đôi?

    Xem đáp án

    Thiết kế idempotent: dùng khóa duy nhất từ event (bucket/key/versionId hoặc event id) làm idempotency key; ghi DynamoDB bằng conditional write (attribute_not_exists(pk)) — lần trùng sẽ fail điều kiện và bỏ qua; hoặc bảng marker "đã xử lý" có TTL kiểm tra trước khi chạy. Nguyên tắc: đừng giả định exactly-once từ nguồn event.

  4. Khác biệt xử lý lỗi giữa Lambda đọc Kinesis và Lambda đọc SQS?

    Xem đáp án

    Kinesis: lỗi mặc định chặn shard (retry cùng batch tới khi hết retention) vì phải giữ thứ tự — cần cấu hình maximumRetryAttempts, bisectBatchOnFunctionError, on-failure destination để tiến tiếp. SQS: message lỗi quay lại queue sau visibility timeout, retry độc lập, quá maxReceiveCount thì sang DLQ — không chặn message khác (standard queue).

  5. Cần chạy transform Python nhẹ (pandas, file ~50MB) mỗi giờ. Lambda hay Glue Python shell?

    Xem đáp án

    Cả hai hợp lệ; chọn theo ràng buộc: Lambda — event-driven/lịch EventBridge, xong trong phút, tích hợp nhẹ nhàng, chi phí per-invocation rất thấp; cần pandas thì dùng layer/container. Glue Python shell — cùng chỗ với pipeline Glue (workflow, catalog), chạy được lâu hơn 15 phút, DPU nhỏ 0.0625. Nếu thời gian xử lý có nguy cơ vượt 15 phút hoặc muốn nằm trong Glue workflow → Python shell; còn lại Lambda thường rẻ và đơn giản nhất.

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

  • Tạo Lambda trigger bởi S3 event: đọc CSV nhỏ, thêm cột, ghi Parquet (pyarrow layer) sang bucket curated
  • Cấu hình on-failure destination sang SQS, thử upload file hỏng để thấy event lỗi vào queue
  • Viết idempotency check bằng DynamoDB conditional write trong Lambda trên
  • Đọc Lambda event source mappings

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


Tiếp theo: Orchestration - Step Functions, MWAA, Glue Workflows, EventBridge