Architecting GenAI data pipeline with AWS native services

Khi mới bắt đầu xây dựng các giải pháp GenAI, câu hỏi lớn nhất là: nếu muốn dùng dữ liệu của riêng mình, thì bắt đầu từ đâu? Mỗi lần tìm hiểu, chỉ thấy lời khuyên rải rác trên internet, mập mờ, các setup chưa hoàn chỉnh, hoặc các công cụ/service không ăn khớp với nhau. Nếu bạn đã quen với AWS và quan tâm đến GenAI nhưng vẫn chưa biết cách tổ chức, làm sạch và chuẩn bị dữ liệu của mình, bài viết này dành cho bạn.

1. Bắt đầu từ đâu?

Trước tiên: cần gì trước khi bắt đầu? Ngoài một tài khoản AWS và kiến thức về data trên AWS, hãy bắt đầu bằng việc kiểm kê dữ liệu. Tự hỏi:

• Dữ liệu của tôi đang ở dạng gì? (CSV, JSON log, PDF, ảnh scan, table RDS...)
• Dữ liệu đang nằm ở đâu? (on-prem, RDS, SaaS API, S3 rải rác...)
• Tốc độ cập nhật của từng nguồn ra sao? (batch hàng ngày hay streaming real-time?)

Câu trả lời cho 3 câu hỏi này quyết định 80% kiến trúc bạn sẽ build. Một team xử lý chủ yếu CSV/JSON batch sẽ có pipeline đơn giản hơn rất nhiều so với team phải xử lý cả streaming IoT + scanned PDF + RDS legacy.

Hãy luôn bắt đầu từ 1 phần nhỏ:

• Tạo hoặc xác định một (vài) S3 bucket để chứa dữ liệu thô (raw).
• Nếu đã có nguồn dữ liệu sẵn (RDS, on-prem, SaaS API...), nghĩ cách đưa chúng vào — AWS Glue có connector, AWS DataSync hoặc Transfer Family hỗ trợ di chuyển file.
• Bật AWS CloudTrail cho S3 bucket để các sự kiện (như upload file mới) có thể trigger xử lý.

Điều quan trọng nhất: không cần làm đúng mọi thứ ngay từ đầu. Đưa một nguồn dữ liệu chạy vào S3, xem nó hoạt động thế nào, rồi mở rộng dần dần.

2. Tổ chức S3 Data Lake

Khi đã sẵn sàng lưu dữ liệu, cấu trúc dữ liệu là mandatory. AWS khuyến nghị nên có nhiều "zone" trong S3 — thường là các bucket riêng cho raw, stage/processing, và analytics/curated. Trong kiến trúc Data Lakehouse được gọi là Bronze layer (raw data), Silver layer (cleansed and conformed data), Gold layer (curated business-level tables).

• Raw layer – lưu file đúng như khi nhận (CSV, JSON, PDF...). Bật versioning để không bao giờ mất bản gốc.
• Stage layer – chứa dữ liệu đã qua xử lý sơ bộ: chuyển đổi format (ví dụ CSV → Parquet), thực hiện các transform ban đầu, và catalog schema bằng AWS Glue.
• Analytics layer – chứa các table đã xử lý hoàn chỉnh, sẵn sàng để query (thường là Parquet hoặc Iceberg). Đây là dữ liệu mà model hoặc analyst sẽ sử dụng cuối cùng.

Bạn nên dùng các bucket S3 riêng được đặt tên theo từng layer (ví dụ myorg-data-raw, myorg-data-stage, myorg-data-analytics), có thể kèm thông tin môi trường/account để rõ ràng hơn. Đặt tên tốt giúp việc quản trị và theo dõi chi phí dễ dàng hơn.

Trade-off cần lưu ý:

Tách 3 bucket không phải miễn phí. Bạn sẽ phải đối mặt với:

• Cross-bucket data movement: Khi Glue job đọc từ raw và viết vào stage, nếu khác region sẽ tốn data transfer cost. → Best practice: luôn đặt cùng region, và nếu có thể, cùng AWS account (hoặc dùng S3 Access Points cho cross-account).
• Quản lý nhiều bucket = nhiều policy hơn: Với tổ chức lớn (nhiều domain dữ liệu), số bucket có thể tăng theo cấp số nhân nếu không có convention đặt tên rõ ràng. Naming convention kiểu <org>-<domain>-<zone>-<env> (ví dụ ocb-payments-raw-prod) là điều must-have ngay từ ngày đầu, vì đổi tên bucket sau này gần như không thể (phải tạo bucket mới + migrate).

Checklist nhanh:

• Dùng tối thiểu 3 layer (raw, stage, analytics), mỗi layer là một bucket S3 riêng.
• Giữ nguyên dữ liệu gốc trong raw (không sửa thủ công!).
• Lập cấu trúc folder/prefix trong từng bucket (partition theo ngày sẽ hữu ích).
• Bật mã hóa (S3 hoặc AWS KMS) và versioning cho bucket raw và stage...

3. Ingest nhiều loại dữ liệu khác nhau

Dữ liệu rất đa dạng bao gồm: bảng quan hệ, file CSV, log JSON, và cả PDF hay hình ảnh/GIF. AWS có công cụ cho từng loại:

• File batch (CSV, JSON, ảnh, PDF trong S3): có thể upload trực tiếp lên S3 (qua CLI, SDK, hoặc giao diện), hoặc dùng AWS DataSync/Transfer Family cho dataset lớn/di trú. Sau khi vào S3, dùng AWS Glue Crawler để tự động phát hiện schema của CSV/JSON và đăng ký vào Glue Data Catalog.
• Dữ liệu streaming/real-time (log, IoT, social feed...): dùng Amazon Kinesis Data Firehose để đưa stream trực tiếp vào S3. Firehose còn có thể chuyển đổi JSON sang Parquet ngay khi nhận, và hỗ trợ gọi Lambda để transform tùy chỉnh (ví dụ chuyển log CSV thành JSON theo blueprint).
• Database (on-prem hoặc RDS): dùng AWS Database Migration Service (DMS) hoặc kết nối JDBC của Glue để đưa dữ liệu vào S3 hoặc trực tiếp vào Redshift/Athena khi cần.
• Tài liệu và hình ảnh (PDF, scan): Amazon Textract là công cụ phù hợp. Đây là dịch vụ OCR dùng AI, có thể trích xuất text và dữ liệu có cấu trúc từ file scan. Ví dụ: đưa file PDF báo cáo vào S3, trigger Lambda gọi Textract để lấy text, rồi lưu output (dạng text hoặc JSON) lại vào S3 để hòa vào phần còn lại của data lake.
• Bedrock Data Automation có thể ingest trực tiếp các format phổ biến như PDF, Word, HTML, CSV,... (lưu ý mỗi file nguồn nên ≤50MB).
• Biểu đồ & Report: Sử dụng các Multiple-LLM như Claude, OpenAI để trích xuất dữ liệu thông qua prompt instruction và export file lưu vào S3.

Pipeline thường là sự kết hợp của tất cả các loại trên. Có thể thiết lập một rule trên EventBridge (qua S3 event/CloudTrail) để mỗi khi có file mới upload vào S3, sẽ trigger một job Glue hoặc Lambda xử lý. Ví dụ: CSV mới trigger một Glue ETL job để làm sạch và chuyển vào bucket stage; PDF mới trigger một quy trình Textract để xuất text ra S3. AWS xử lý dữ liệu đa dạng rất tốt — chỉ cần ghép đúng các dịch vụ lại với nhau.

4. Catalog và đồng bộ schema (Glue & DataBrew)

Khi dữ liệu đã vào S3, bạn cần một catalog và một số bước làm sạch. AWS Glue xử lý phần catalog và ETL. Glue Crawler sẽ scan các folder S3 raw và đăng ký table vào Glue Data Catalog. Sau đó, bạn có thể dùng Glue job (PySpark) hoặc AWS Glue DataBrew (no-code/low-code cho data engineer) để làm sạch và đồng bộ hóa dữ liệu.

DataBrew là công cụ chuẩn bị dữ liệu trực quan — không cần viết code — có thể profile và transform dữ liệu, với hơn 250 hàm dựng sẵn (filter, đổi tên cột, chuyển đổi format, xử lý giá trị thiếu...).

Ví dụ: một nguồn dùng "FirstName", nguồn khác dùng "first_name" — DataBrew có thể giúp đồng nhất chúng.

Trong khi đó, Glue ETL job có thể join, enrich, hoặc transform dữ liệu thêm nữa. Ưu điểm: toàn bộ có thể tự động hóa trong Glue Workflows. Glue kết hợp DataBrew cho phép "làm sạch và chuẩn hóa mà không cần viết code" — rất phù hợp cho các team mà không phải ai cũng là data/machine learning engineer. Sau khi transform, viết output vào bucket "stage" hoặc "analytics", và cập nhật Data Catalog với schema mới.

Trong thực tế, quy trình có thể là:

• Crawler tự động phát hiện schema trên dữ liệu raw, ghi log lỗi với các giá trị thiếu hoặc không hợp lệ.
• Chạy một DataBrew recipe để fix các vấn đề phổ biến trên nhiều dataset (chuẩn hóa ngày tháng, điền null...).
• Dùng Glue job (Spark) để join các dataset hoặc chuyển toàn bộ sang format phân tích tiêu chuẩn (như table Parquet/Apache Iceberg).

5. Chuẩn hóa tài liệu cho GenAI (Bedrock KB, Textract)

Tài liệu văn bản là một trường hợp đặc biệt. Với Generative AI (đặc biệt là RAG - Retrieval-Augmented Generation), bạn thường đưa tài liệu vào một knowledge base hoặc query engine. Amazon Bedrock KB cho phép ingest các file dạng text (theo các format đã hỗ trợ ở trên) và query chúng bằng LLM. Nhưng trước đó, bạn có thể cần chuẩn hóa và chia nhỏ (chunk) văn bản.

Ví dụ: nếu bạn có các file PDF tài liệu hướng dẫn hoặc báo cáo, dùng Textract để trích xuất text và bảng. Sau khi có text thô, có thể chạy một Glue job hoặc Lambda để chia thành các phần logic hoặc "chunk" — mỗi chunk khoảng vài trăm từ. Lý do là Bedrock KB thường hoạt động tốt nhất khi nội dung được chia thành các phần nhỏ (như từng đoạn văn).

Bedrock hiện hỗ trợ các tính năng như semantic chunking và hierarchical chunking, thậm chí dùng foundation model để parse các file PDF khó. Nhưng ở mức cơ bản, hãy bắt đầu đơn giản: trích xuất text, loại bỏ các phần "rác" do scan lỗi, và lưu tất cả vào file .txt hoặc .md trong S3. Sau đó kết nối S3 này làm data source cho Bedrock KB — dịch vụ sẽ tự parse và index để dùng cho RAG.

Một mẹo nữa — chuẩn hóa thuật ngữ: các tài liệu khác nhau có thể dùng "DOB", "Date of Birth", "Birth Date" cho cùng một khái niệm. Bạn có thể dùng Glue hoặc prompt LLM để chuẩn hóa các key này (để GenAI hiểu chúng là cùng một khái niệm). Trong xử lý tài liệu thông minh (IDP), đây gọi là "template và normalization" (định nghĩa các alias cho các thuật ngữ khác nhau). Giống như nói với AI: "này, bất cứ khi nào thấy DOB hay Birthdate, đều có nghĩa là cùng một thứ." Điều này giúp knowledge base của bạn sạch và nhất quán.

6. Bảo mật và quản trị Data Lake (IAM, Lake Formation, LF-Tags)

Khi đã có dữ liệu sạch, cần cấp quyền và quản trị đúng cách. Bắt đầu với IAM: áp dụng nguyên tắc least privilege, dùng IAM role cho Glue job và Lambda function (chỉ cấp đúng quyền S3/Glue cần thiết), và xem xét dùng AWS KMS để quản lý key. Nhưng chỉ dùng IAM sẽ trở nên cồng kềnh khi cần phân quyền theo từng table/column.

Đây là lúc AWS Lake Formation phát huy tác dụng.

Lake Formation cho phép thiết lập kiểm soát truy cập chi tiết (fine-grained) trên catalog và table S3. Một tính năng mạnh là LF-Tags: các tag dựa trên thuộc tính (ví dụ department=finance hoặc sensitivity=PII) gắn lên table/column, rồi cấp các giá trị tag tương ứng cho user role.

Giống như hệ thống "thẻ đỗ xe": một garage công ty chia thành nhiều khu vực, mỗi dataset có một "tem đỗ xe" (LF-Tag), và mỗi analyst có một "thẻ" tương ứng — chỉ khi tem và thẻ khớp nhau, bạn mới "đi qua" được để truy cập dữ liệu. LF-Tags scale tốt hơn việc cấp quyền từng table cho từng user một.

Lưu ý quan trọng: LF-Tags không giống IAM tags. LF-Tags kiểm soát quyền truy cập table trong Lake Formation; IAM tags điều khiển IAM policy. Không nên nhầm lẫn hai khái niệm này — một dành cho truy cập dữ liệu, một dành cho quyền của service.

Ngoài ra, dùng Lake Formation để áp dụng filter ở cấp cột hoặc hàng nếu cần (ví dụ: ẩn email, hoặc chỉ hiển thị các dòng dữ liệu thuộc khu vực châu Âu). Đừng quên S3 bucket policy hoặc Access Point cho việc chia sẻ cross-account.

7. Tự động hóa Pipeline (EventBridge, Glue Workflows, Step Functions)

Các bước thao tác thủ công luôn dễ gây lỗi. Hãy tự động hóa pipeline để dữ liệu mới tự chảy qua các bước xử lý. AWS EventBridge đóng vai trò router sự kiện: ví dụ, thiết lập để bắt mọi event PutObject trên S3 (qua CloudTrail) và trigger Glue Workflows. Glue Workflows cho phép kết nối nhiều Glue job, crawler và trigger thành một pipeline duy nhất.

Một pattern phổ biến: S3 → CloudTrail → EventBridge rule → Glue workflow. Trong thực tế: khi có 10 file mới hoặc sau một khoảng 5 phút, EventBridge sẽ khởi động Glue workflow. Glue sau đó chạy một crawler (phát hiện schema mới), chạy một ETL job (làm sạch/chuyển đổi dữ liệu), và có thể một job khác để chuyển dữ liệu sang zone analytics. Đây là kiểu ETL hướng sự kiện (event-driven) — không cần polling hay chạy job theo lịch không cần thiết, pipeline chạy theo sự kiện thực tế.

Bạn cũng có thể dùng AWS Step Functions để điều phối (đặc biệt khi cần logic phân nhánh hoặc xử lý song song). Step Functions có thể gọi Glue, Lambda, SageMaker... với retry tích hợp sẵn — phù hợp để điều phối các luồng phức tạp, ví dụ: sau khi Glue hoàn thành, thực hiện các bước kiểm tra chất lượng tùy chỉnh (qua Lambda) trước khi load dữ liệu.

Tóm lại: các rule trên EventBridge (trigger-on-upload hoặc theo lịch) khởi động pipeline; Glue workflow hoặc Step Functions quản lý các bước; pipeline tự vận hành.

8. Giúp dữ liệu dễ tìm kiếm (Amazon DataZone & SageMaker)

Cuối cùng, khi data lake đã chạy ổn, hãy giúp các team dễ dàng tìm và sử dụng dữ liệu. Amazon DataZone là dịch vụ catalog và quản trị dữ liệu — có thể coi như "công cụ tìm kiếm Google" cho tài sản dữ liệu của công ty. Bạn có thể đăng ký dữ liệu S3 (qua Glue table) vào DataZone, gắn tag (ví dụ sales, raw-data), và viết mô tả. Người dùng trong tổ chức sau đó có thể tìm kiếm hoặc duyệt các dataset họ cần — rất hữu ích cho việc hợp tác.

Điểm hay nhất: SageMaker hiện tích hợp trực tiếp với DataZone. Data scientist và ML engineer có thể tìm kiếm catalog của DataZone ngay trong SageMaker Studio hoặc Canvas, và đưa dữ liệu vào notebook hoặc Canvas bằng cách nhấn "Subscribe" vào dataset. Giống như có một "trung tâm mua sắm dữ liệu" tích hợp ngay trong IDE.

Ví dụ: bạn publish một table Parquet đã làm sạch lên DataZone với tên "SalesStats". Bất kỳ ai trong team ML cũng có thể tìm thấy "SalesStats" từ SageMaker và thêm vào môi trường Jupyter của họ. Sau khi train model, họ có thể publish model trở lại DataZone để người khác tái sử dụng.

Tóm lại: dùng DataZone (liên kết với Lake Formation/Glue Catalog) để catalog mọi thứ, và kích hoạt tính năng tìm kiếm/subscribe dữ liệu của SageMaker.

9. Best Practices triển khai thực tế (rút ra từ kinh nghiệm production)

1. Naming convention là quyết định một-chiều — đặt sai tên bucket/table ngay từ đầu, sửa sau cực kỳ tốn kém. Dành 1 buổi họp để chốt convention trước khi tạo resource đầu tiên.
2. Infrastructure as Code từ ngày 1 — toàn bộ S3 bucket, Glue job, Lake Formation permission, LF-Tags nên được quản lý bằng Terraform/CDK. Lake Formation permission đặc biệt khó audit nếu được tạo "tay" qua console — không có version history.
3. Observability cho data pipeline: Set up CloudWatch alarm cho Glue job failure, DLQ cho Lambda/SQS trong luồng ingestion, và dashboard theo dõi "data freshness" (thời gian từ lúc data sinh ra đến lúc available trong analytics zone) — đây là metric quan trọng nhất với GenAI pipeline mà ít người đo.
4. Cost guardrails: Glue job và DataBrew tính phí theo DPU-hour. Set MaxCapacity và Timeout rõ ràng cho mọi Glue job — một job "treo" do lỗi logic có thể chạy 48h và đốt budget không kiểm soát.
5. Bắt đầu với 1 use case RAG cụ thể, không build "generic platform" trước. Build pipeline cho 1 loại document (ví dụ: chính sách nhân sự dạng PDF), đo retrieval quality, rồi mới generalize pattern cho document type khác.
6. Tách biệt môi trường dev/staging/prod cho cả Glue Catalog và Lake Formation permission — vì LF-Tags áp dụng nhầm trong production có thể vô tình mở quyền truy cập dữ liệu nhạy cảm cho cả tổ chức.
7. Luôn sử dụng Architecture Decision Record: Đây là một tài liệu ngắn gọn ghi lại các quyết định quan trọng về thiết kế hệ thống hoặc công nghệ, bao gồm bối cảnh, lý do lựa chọn, các phương án thay thế và tác động của quyết định đó.

10. Tổng kết

Đó là rất nhiều thông tin, nhưng hãy nhớ: bắt đầu đơn giản và làm dần từng bước. Các bước tổng quát là: chuẩn bị tài khoản AWS, tổ chức S3, ingest các nguồn dữ liệu, làm sạch và catalog với Glue/DataBrew, trích xuất text từ tài liệu cho Bedrock, bảo mật mọi thứ với IAM/LF-Tags, tự động hóa với EventBridge/Glue/Step Functions, và cuối cùng kết nối với DataZone/SageMaker để người khác dễ tìm thấy.

Nếu team bạn đang chuẩn bị build GenAI application với dữ liệu nội bộ, lời khuyên của mình là: đừng bắt đầu từ model. Bắt đầu từ data inventory, chốt naming convention, build 1 pipeline mẫu end-to-end cho 1 nguồn dữ liệu đơn giản nhất, rồi mới mở rộng.