Mở đầu — vì sao bài này quan trọng
Nếu bạn đã theo dõi khóa học đến đây, bạn đã biết dùng data như thế nào: đọc hiểu số liệu, ra quyết định, thiết kế metrics, xây văn hóa data. Nhưng có một câu hỏi mà sớm hay muộn mọi tổ chức đều phải trả lời: data đó "sống" ở đâu, chảy như thế nào, và ai chịu trách nhiệm cho từng chặng? Đó chính là câu hỏi về kiến trúc data platform (data platform architecture).
Hãy hình dung data platform giống như hệ thống cấp nước của một thành phố. Nước (data) đến từ nhiều nguồn (sông, hồ, mưa — tức là app, CRM, cảm biến IoT, file Excel). Nó phải được gom lại, lọc sạch, lưu trữ, rồi phân phối đến từng vòi nước trong nhà dân (dashboard, báo cáo, model ML). Nếu bạn thiết kế sai hệ thống ống — quá nhỏ, quá đắt, hoặc không có bể lọc — thì dù nguồn nước có dồi dào, người dùng cuối vẫn nhận được nước bẩn hoặc không có nước.
Trong thực tế, đây là nơi rất nhiều tổ chức Việt Nam "trả giá đắt": một startup fintech chọn kiến trúc quá phức tạp cho giai đoạn 50 nhân viên, đốt hàng trăm triệu đồng chi phí cloud mỗi tháng cho một hệ thống mà 5 người phân tích không dùng hết. Ngược lại, một chuỗi bán lẻ chọn kiến trúc quá đơn giản, đến khi có 200 cửa hàng thì mọi báo cáo chạy hàng giờ, ban lãnh đạo mất niềm tin vào data.
Bài này giúp bạn nắm được các pattern kiến trúc data platform phổ biến, hiểu khi nào nên chọn cái nào, và làm sao ra quyết định kiến trúc mà không rơi vào bẫy "chọn theo hype". Đây là kiến thức nền tảng cho bất kỳ ai muốn dẫn dắt tổ chức trở nên thực sự data-driven.
Khái niệm cốt lõi
Data platform là gì và gồm những lớp nào
Một data platform không phải một công cụ đơn lẻ mà là tập hợp các lớp (layers) phối hợp với nhau. Dù dùng pattern nào, hầu hết đều có 5 lớp logic sau:
- Ingestion (thu thập) — kéo data từ nguồn (database sản xuất, API, log, file) vào platform. Ví dụ công cụ: Fivetran, Airbyte, Kafka.
- Storage (lưu trữ) — nơi data nằm lại. Đây chính là lớp quyết định "pattern" của bạn: warehouse, lake, hay lakehouse.
- Transformation (biến đổi) — làm sạch, kết hợp, tính toán để biến data thô thành data dùng được. Ví dụ: dbt, Spark.
- Serving (phân phối) — đưa data đến người dùng: BI dashboard, API, model.
- Orchestration & Governance (điều phối và quản trị) — lịch chạy, giám sát, phân quyền, kiểm soát chất lượng. Ví dụ: Airflow, Dagster.
Bốn pattern kiến trúc nền tảng
Pattern 1 — Data Warehouse (kho dữ liệu có cấu trúc)
Data warehouse là mô hình lâu đời nhất và vẫn phổ biến nhất. Data được nạp vào theo schema-on-write — tức bạn phải định nghĩa cấu trúc bảng trước khi ghi data vào. Data chủ yếu là dạng có cấu trúc (bảng, cột), tối ưu cho phân tích BI và báo cáo.
Điểm mạnh: truy vấn nhanh, dễ dùng cho analyst quen SQL, dữ liệu sạch và nhất quán. Điểm yếu: khó chứa dữ liệu phi cấu trúc (ảnh, video, log JSON phức tạp), và có thể tốn kém khi lưu lượng data khổng lồ. Đại diện hiện đại: Snowflake, Google BigQuery, Amazon Redshift.
Triết lý cốt lõi: "Làm sạch trước, hỏi sau." Phù hợp khi câu hỏi phân tích đã tương đối rõ ràng.
Pattern 2 — Data Lake (hồ dữ liệu thô)
Data lake theo mô hình schema-on-read — bạn đổ tất cả data thô vào (bất kể định dạng: CSV, JSON, ảnh, log, Parquet) và chỉ áp cấu trúc khi đọc ra để dùng. Thường xây trên object storage giá rẻ như Amazon S3, Google Cloud Storage, Azure Blob.
Điểm mạnh: rẻ, linh hoạt, chứa được mọi loại dữ liệu, lý tưởng cho data science và ML. Điểm yếu: dễ biến thành "data swamp" (đầm lầy dữ liệu) — data đổ vào lộn xộn, không ai biết cái gì đáng tin, không có kiểm soát chất lượng. Truy vấn cũng chậm và phức tạp hơn warehouse.
Triết lý cốt lõi: "Lưu tất cả trước, tìm cách dùng sau." Phù hợp khi bạn chưa biết hết mình sẽ hỏi gì, và có nhiều dữ liệu phi cấu trúc.
Pattern 3 — Data Lakehouse (kết hợp lake + warehouse)
Lakehouse là nỗ lực "gom điểm mạnh của cả hai". Nó lưu data trên object storage rẻ như lake, nhưng thêm một lớp giao dịch (transactional layer) cho phép quản lý schema, đảm bảo tính nhất quán ACID và truy vấn nhanh gần như warehouse. Công nghệ chủ đạo: Databricks (Delta Lake), Apache Iceberg, Apache Hudi.
Điểm mạnh: một nơi duy nhất phục vụ cả BI lẫn ML, tránh phải sao chép data qua lại giữa lake và warehouse. Điểm yếu: công nghệ tương đối mới, cần đội ngũ kỹ thuật vững, và chi phí vận hành cụ thể có thể phức tạp. Đây là xu hướng thịnh hành nhất hiện nay ở các tổ chức có nhu cầu ML + BI song song.
Pattern 4 — Data Mesh / kiến trúc phi tập trung
Ba pattern trên đều mang tính tập trung (centralized): một đội data trung tâm sở hữu toàn bộ platform. Data Mesh lật ngược tư duy đó: mỗi domain nghiệp vụ (marketing, tài chính, vận hành) tự sở hữu data của mình như một "sản phẩm dữ liệu" (data product), trong khi platform trung tâm chỉ cung cấp hạ tầng dùng chung. Bài 28 của khóa học đã đi sâu vào Data Mesh; ở đây bạn chỉ cần hiểu nó là một pattern kiến trúc về mặt tổ chức và sở hữu, thường được xây trên nền lakehouse hoặc warehouse.
Batch vs Streaming — trục thứ hai của kiến trúc
Ngoài trục Storage, còn một trục quan trọng: data được xử lý theo batch (theo lô, ví dụ cập nhật mỗi giờ/mỗi ngày) hay streaming (real-time, liên tục). Một số kiến trúc kết hợp cả hai:
- Lambda architecture: chạy song song một luồng batch (chính xác, chậm) và một luồng streaming (nhanh, gần đúng), rồi hợp nhất. Mạnh nhưng phức tạp vì phải bảo trì hai bộ code.
- Kappa architecture: chỉ dùng một luồng streaming duy nhất, xử lý cả real-time lẫn lịch sử. Đơn giản hơn nhưng đòi hỏi công cụ streaming trưởng thành (như Kafka + Flink).
Tình huống thực tế
Ví dụ 1 — Chuỗi F&B 80 cửa hàng chọn Warehouse thay vì Lakehouse
Bối cảnh: "Cơm Phố" (tên giả định), chuỗi F&B với 80 cửa hàng ở TP.HCM và Hà Nội, doanh thu ~200 tỷ/năm. CEO muốn dashboard doanh thu, tồn kho, hiệu suất từng cửa hàng theo ngày. Đội data chỉ có 2 analyst, không có data engineer.
Một tư vấn ngoài đề xuất xây lakehouse trên Databricks vì "sau này còn làm AI". Nhưng data thực tế của họ đơn giản: giao dịch POS, tồn kho, chấm công — tất cả đều có cấu trúc, tổng dưới 500 GB.
Diễn giải: Đội quyết định chọn BigQuery (warehouse) kết hợp Fivetran để ingest và dbt để transform. Lý do: schema rõ ràng, câu hỏi phân tích đã biết trước (doanh thu, tồn kho), và không ai trong đội biết vận hành Spark. Toàn bộ setup mất 3 tuần, chi phí cloud ~8 triệu đồng/tháng.
Bài học: Kiến trúc phải khớp với độ chín của đội ngũ và bản chất dữ liệu, không phải với tham vọng tương lai. Warehouse đơn giản giúp họ có dashboard chạy được trong 1 tháng — thứ mà lakehouse phức tạp có thể khiến họ mắc kẹt cả quý. "Sau này làm AI" là một câu hỏi của sau này.
Ví dụ 2 — Startup fintech và cái bẫy Data Lake thành Data Swamp
Bối cảnh: Một ví điện tử Việt Nam (giả định, quy mô ~5 triệu người dùng) xây data lake trên S3 từ sớm để chứa mọi thứ: log giao dịch, event app, dữ liệu KYC, log server. Triết lý "lưu tất cả" nghe rất hợp lý với một fintech dữ liệu dày.
Diễn giải: Sau 18 tháng, S3 chứa hàng chục TB nhưng không ai biết bảng nào đáng tin. Cùng một chỉ số "số giao dịch thành công" cho ra 3 con số khác nhau tùy người truy vấn folder nào. Không có catalog, không có kiểm soát chất lượng — đúng định nghĩa data swamp. Đội data science mất 60% thời gian chỉ để tìm và làm sạch data trước khi làm được model.
Họ phải "giải cứu" bằng cách thêm một lớp lakehouse (Apache Iceberg) lên trên lake sẵn có, đưa vào data catalog và quy ước lớp Bronze/Silver/Gold (thô → sạch → sẵn dùng). Sau 4 tháng tái cấu trúc, thời gian chuẩn bị data giảm còn ~20%.
Bài học: Data lake không có governance thì gần như chắc chắn thành đầm lầy. Nếu chọn lake, bạn phải đầu tư song song vào catalog, chuẩn phân lớp và quyền sở hữu ngay từ đầu — nếu không, sự linh hoạt sẽ quay lại cắn bạn.
Ví dụ 3 — Grab và nhu cầu Streaming thực sự
Bối cảnh: Grab (công ty thật, hoạt động mạnh tại Đông Nam Á gồm Việt Nam) xử lý hàng triệu chuyến xe và giao dịch mỗi ngày. Với họ, một số bài toán không thể chờ batch: định giá động (surge pricing) theo cung–cầu tức thời, phát hiện gian lận thanh toán, ghép tài xế–khách hàng.
Diễn giải: Grab dùng kiến trúc kết hợp streaming (Kafka và các công nghệ xử lý luồng) cho các use case real-time, song song với warehouse/lakehouse cho phân tích lịch sử và báo cáo. Điểm mấu chốt: họ không streaming hóa mọi thứ. Báo cáo tài chính cuối tháng vẫn chạy batch — vì nó không cần real-time.
Bài học: Streaming là công cụ đắt và phức tạp, chỉ nên áp cho những bài toán mà độ trễ trực tiếp ảnh hưởng đến giá trị kinh doanh. Ngay cả một công ty tầm cỡ Grab cũng phân biệt rạch ròi cái gì cần real-time, cái gì để batch. Đây là bài học lớn cho các tổ chức nhỏ hay có xu hướng "streaming hóa" theo hype.
Hướng dẫn từng bước
Dưới đây là quy trình 6 bước để chọn và phác thảo kiến trúc data platform cho tổ chức của bạn:
Bước 1 — Lập bản đồ nguồn và loại dữ liệu. Liệt kê mọi nguồn (POS, CRM, app, web, IoT, file). Với mỗi nguồn, ghi rõ: có cấu trúc hay phi cấu trúc? Khối lượng bao nhiêu? Tốc độ tăng ra sao? Đây là dữ kiện quyết định warehouse-đủ hay cần lake/lakehouse.
Bước 2 — Liệt kê use case đầu ra và độ trễ chấp nhận được. Bạn cần gì: dashboard BI, báo cáo, hay model ML? Mỗi cái cần data "tươi" đến mức nào — theo ngày, theo giờ, hay theo giây? Nếu tất cả đều "theo ngày là ổn", bạn không cần streaming.
Bước 3 — Đánh giá độ chín của đội ngũ. Bạn có data engineer không? Đội quen SQL hay quen Python/Spark? Kiến trúc bạn vận hành được quan trọng hơn kiến trúc "đúng chuẩn sách vở".
Bước 4 — Chọn pattern Storage. Dùng quy tắc đơn giản:
- Chủ yếu data có cấu trúc + đội quen SQL + use case BI rõ ràng → Warehouse.
- Nhiều data phi cấu trúc + nặng về ML + câu hỏi chưa rõ → Lake (kèm governance) hoặc Lakehouse.
- Cần cả BI lẫn ML nghiêm túc trên cùng data + có đội kỹ thuật vững → Lakehouse.
- Tổ chức lớn, nhiều domain, đội data trung tâm quá tải → cân nhắc Data Mesh (xem Bài 28).
Bước 6 — Chọn công cụ orchestration và governance, rồi làm PoC nhỏ. Đừng xây tất cả cùng lúc. Chọn một use case có giá trị (ví dụ dashboard doanh thu), xây end-to-end trong 2–4 tuần, rồi mở rộng. Kiến trúc tốt là kiến trúc tiến hóa, không phải "big bang".
Lỗi thường gặp & mẹo
Lỗi 1 — Chọn theo hype thay vì theo nhu cầu. "Databricks/lakehouse đang hot nên ta làm lakehouse." Đây là sai lầm phổ biến nhất. Hãy để dữ liệu và use case dẫn dắt, không phải blog công nghệ.
Lỗi 2 — Over-engineering cho quy mô chưa tới. Xây kiến trúc streaming, multi-region cho một công ty 50 người. Chi phí cloud và độ phức tạp vận hành sẽ giết bạn trước khi bạn kịp mở rộng. Mẹo: thiết kế cho quy mô của 12–18 tháng tới, không phải cho ước mơ 10 năm.
Lỗi 3 — Lake không có governance. Như ví dụ ví điện tử: đổ data vào lake mà không có catalog, không phân lớp, không chủ sở hữu → data swamp. Mẹo: nếu chọn lake, ngân sách cho governance phải nằm ngay trong dự án ban đầu.
Lỗi 4 — Quên chi phí vận hành (TCO). Chi phí không chỉ là hóa đơn cloud mà còn là người vận hành. Một lakehouse "rẻ về storage" có thể đắt về nhân lực nếu bạn không có ai đủ trình vận hành. Mẹo: luôn tính tổng chi phí sở hữu gồm cả con người.
Lỗi 5 — Sao chép data lung tung. Copy data từ warehouse sang lake sang chỗ khác để mỗi đội có bản riêng. Kết quả: nhiều "phiên bản sự thật", số liệu mâu thuẫn. Mẹo: hướng tới "một nguồn sự thật" (single source of truth) ở lớp Gold.
Mẹo tổng quát: Bắt đầu đơn giản (warehouse hoặc lake nhỏ), thêm phức tạp chỉ khi có nhu cầu chứng minh được. Kiến trúc data tốt nhất cho hầu hết tổ chức Việt Nam giai đoạn đầu là một warehouse hiện đại (BigQuery/Snowflake) + dbt + một BI tool. Đơn giản mà mạnh.
Bài tập thực hành
- Bản đồ nguồn dữ liệu: Chọn một tổ chức bạn biết (nơi làm việc, hoặc một startup giả định). Liệt kê ít nhất 5 nguồn data, phân loại mỗi nguồn là có cấu trúc / phi cấu trúc, ước lượng khối lượng và tốc độ tăng.
- Chọn pattern có lập luận: Dựa trên bản đồ ở bài 1 và độ chín đội ngũ (tự giả định), chọn một trong bốn pattern (Warehouse / Lake / Lakehouse / Mesh). Viết một đoạn 150–200 từ giải thích vì sao — phải nêu ít nhất một lý do bác bỏ hai pattern còn lại.
- Quyết định batch vs streaming: Liệt kê 4 use case đầu ra của tổ chức đó. Với mỗi use case, ghi độ trễ chấp nhận được (giây/giờ/ngày) và kết luận cần streaming hay batch. Có bao nhiêu use case thực sự cần real-time?
- Thiết kế phân lớp: Vẽ (trên giấy hoặc Miro) sơ đồ Bronze/Silver/Gold cho một loại data cụ thể (ví dụ giao dịch bán hàng): ở mỗi lớp, data trông như thế nào và ai được quyền dùng?
- Phản biện một quyết định hype: Tìm một bài viết/công ty đề cao một công nghệ data mới. Viết 100 từ phản biện: trong hoàn cảnh nào công nghệ đó không phù hợp?
Tóm tắt
- Data platform gồm 5 lớp logic: ingestion, storage, transformation, serving, orchestration/governance. "Pattern kiến trúc" chủ yếu nằm ở lớp storage và transformation.
- Bốn pattern nền tảng: Warehouse (có cấu trúc, schema-on-write, BI — Snowflake/BigQuery/Redshift), Lake (thô, schema-on-read, linh hoạt nhưng dễ thành swamp — S3/GCS), Lakehouse (kết hợp cả hai — Databricks/Iceberg/Hudi), và Data Mesh (phi tập trung theo domain).
- Trục thứ hai là batch vs streaming; batch nên là mặc định, streaming chỉ khi độ trễ trực tiếp tạo giá trị kinh doanh.
- Chọn kiến trúc theo dữ liệu, use case và độ chín đội ngũ — không theo hype. Bắt đầu đơn giản, tiến hóa dần, áp phân lớp Bronze/Silver/Gold để chống data swamp.
- Ba bài học từ thực tế: chuỗi F&B chọn warehouse đúng với quy mô, ví điện tử trả giá vì lake thiếu governance, và Grab dùng streaming có chọn lọc chứ không streaming hóa mọi thứ.