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

Tuần 2 - Ngày 5: AppFlow và tổng kết pattern Batch Ingestion

Tuần 2 – Ngày 5

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

  • Hiểu Amazon AppFlow: flow, connector, trigger, transformation
  • Biết các nguồn ingestion khác: Redshift COPY, Athena federated query
  • Tổng hợp decision tree chọn công cụ batch ingestion
  • Nhận diện anti-pattern ingestion thường gặp trong đề

1. Amazon AppFlow

Khái niệm

Dịch vụ no-code chuyển dữ liệu giữa SaaS applications và AWS: Salesforce, SAP OData, ServiceNow, Zendesk, Slack, Google Analytics, Marketo... → S3, Redshift (và chiều ngược: S3 → Salesforce...).

SaaS(Salesforce,SAP,GA4,ServiceNow...)│connectorOAuth,private(PrivateLinkvới1sốSaaS)▼AppFlowFLOW├──Trigger:on-demand|schedule|event(SaaSevent)├──Mapping:chọnfield,đổitên├──Transform:mask,truncate,validate,filtercơbản└──Incremental:chỉlấybảnghimới/thayđổitheolịch│▼S3(JSON/CSV/Parquet)hoặcRedshift...

Đặc điểm chính

  • Không viết code, không hạ tầng — cấu hình flow là xong
  • Trigger: on-demand, schedule (incremental theo trường thời gian), event-driven (vd Salesforce platform events)
  • Transformation nhẹ ngay trong flow: masking, filter, validate, map field
  • Ghi S3 ra được Parquet; tự đăng ký vào Glue Data Catalog (tùy chọn)
  • Bảo mật: mã hóa KMS; PrivateLink cho SaaS hỗ trợ — dữ liệu không qua Internet công cộng
  • Billing: theo số flow run + GB xử lý

Exam cue: "Salesforce/SAP data vào S3/Redshift, no code, scheduled" → AppFlow. Đừng chọn Glue custom connector hay Lambda gọi API khi AppFlow có connector sẵn (operational overhead cao hơn).

2. Các đường ingestion khác cần biết

CáchKhi nào
Redshift COPY từ S3Nạp batch vào Redshift — cách chuẩn, song song theo slice; file nén, chia nhỏ ~ bội số slice
Athena Federated QueryQuery tại chỗ nguồn ngoài (DynamoDB, RDS, on-prem qua Lambda connector) — ad-hoc, không phải pipeline replicate
Glue JDBC ingestionKéo bảng từ database khi cần transform ngay trong cùng job
Lambda + APINguồn API không có connector; volume nhỏ; event-driven
Kinesis/FirehoseDữ liệu streaming (tuần 3)

3. Decision tree batch ingestion (tổng kết tuần)

Nguồndữliệulàgì?├──Database(RDBMS/NoSQL)│├──Replicateliêntục(CDC)──────────►DMS(fullload+CDC)│├──Aurora/RDS→Redshift,managed───►Zero-ETLintegration│└──Kéomộtlần+transform──────────►Gluejob(JDBC)├──SaaSapplication(Salesforce,SAP...)─►AppFlow├──Fileserveron-prem(NFS/SMB/HDFS)│├──Đồngbộđịnhkỳquamạng─────────►DataSync│├──Volumequálớn/mạngyếu────────►SnowballEdge│└──On-premvẫncầnmounttiếp───────►StorageGateway(File)├──Đốitácngoàipushfile(SFTP/AS2)───►TransferFamily└──Streamingevents─────────────────────►Kinesis/MSK(tuần3)

4. Anti-patterns hay gặp trong đề

  1. Tự viết Lambda gọi Salesforce API khi AppFlow có connector → thừa code, sai với "least operational overhead"
  2. DMS để chuyển file (không phải database) → sai công cụ; DMS làm việc với database/log
  3. Transfer Family để đồng bộ nội bộ → Transfer Family là managed endpoint cho bên ngoài push; nội bộ dùng DataSync
  4. INSERT từng dòng vào Redshift thay vì COPY từ S3 → chậm và đắt; luôn COPY batch
  5. Crawler chạy full mỗi 5 phút trên bucket khổng lồ → event-based crawler hoặc partition projection
  6. Một file khổng lồ duy nhất khi COPY/Spark → chia nhỏ để song song (Redshift: bội số slice; Spark: ~128MB-1GB/file)

5. Checklist thiết kế ingestion (dùng khi làm bài)

  • Tần suất: one-time / định kỳ / liên tục (CDC, streaming)?
  • Nguồn: DB / SaaS / file / API / stream?
  • Ai chủ động: mình kéo (pull) hay bên kia đẩy (push)?
  • Khối lượng vs băng thông: có cần thiết bị vật lý?
  • Định dạng đích: Parquet + partition ngay từ đầu nếu được (Firehose/AppFlow/DMS đều ghi được Parquet)
  • Bảo mật: private connectivity (PrivateLink, VPN/DX), KMS, Secrets Manager cho credentials

Câu hỏi ôn tập

  1. Marketing cần dữ liệu Salesforce đổ vào S3 mỗi giờ dạng Parquet, đăng ký vào Glue Catalog, không viết code. Giải pháp?

    Xem đáp án

    Amazon AppFlow: flow Salesforce → S3, schedule hourly ở chế độ incremental, output format Parquet, bật tùy chọn tích hợp Glue Data Catalog. Không cần Lambda/Glue custom code — AppFlow là connector managed cho SaaS.

  2. Nạp 2TB dữ liệu batch từ S3 vào Redshift nhanh nhất — dùng lệnh gì và tối ưu file thế nào?

    Xem đáp án

    Lệnh COPY (không phải INSERT): Redshift load song song theo slice. Tối ưu: chia thành nhiều file kích thước gần bằng nhau, số file là bội số số slice của cluster, nén (gzip/zstd), cùng prefix để COPY quét một lần. Một file duy nhất khiến chỉ 1 slice làm việc.

  3. Khi nào Athena Federated Query hợp lý hơn là replicate dữ liệu về S3?

    Xem đáp án

    Khi cần query ad-hoc/không thường xuyên trên nguồn ngoài (DynamoDB, RDS, CloudWatch Logs...) mà không muốn xây pipeline: Athena dùng Lambda connector query tại chỗ và join với dữ liệu S3. Nếu query lặp lại thường xuyên trên khối lượng lớn → replicate về lake (DMS/Glue) sẽ rẻ và nhanh hơn (federated query chậm và tốn tài nguyên nguồn).

  4. Dữ liệu SaaS chứa PII, yêu cầu không đi qua Internet công cộng và che một số trường. AppFlow đáp ứng ra sao?

    Xem đáp án

    AppFlow hỗ trợ PrivateLink với các SaaS tương thích (vd Salesforce Private Connect) để traffic đi trong mạng AWS, mã hóa bằng KMS key tùy chọn, và có transformation masking ngay trong flow để che trường PII trước khi ghi vào S3.

  5. Chọn công cụ cho từng nguồn: (a) SAP OData hàng ngày; (b) PostgreSQL on-prem CDC liên tục; (c) 300TB HDFS một lần, mạng 10 Gbps; (d) đối tác gửi CSV qua SFTP.

    Xem đáp án

    (a) AppFlow (connector SAP OData). (b) DMS full load + CDC. (c) 300TB qua 10 Gbps ≈ 3-4 ngày lý thuyết — khả thi qua mạng: DataSync (hỗ trợ HDFS); nếu băng thông phải chia sẻ/deadline gắt thì Snowball. (d) Transfer Family SFTP endpoint → S3.

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

  • Xem danh sách AppFlow connectors — note 5 connector quen thuộc
  • Vẽ decision tree ingestion của mục 3 từ trí nhớ
  • Viết câu COPY mẫu nạp Parquet từ S3 vào Redshift với IAM role
  • Ôn lại 4 ngày tuần 2 chuẩn bị quiz ngày mai

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

Tiếp theo: Quiz Tuần 2