Data Mesh 7 — Modern Data Stack & công nghệ

Sáu bài trước của series bàn về mô hình tổ chức của Data Mesh: tổng quan, sở hữu theo miền, dữ liệu như sản phẩm, data contract, nền tảng tự phục vụ và quản trị liên bang. Đến đây một câu hỏi rất thực tế bật ra: dùng công nghệ gì để làm ra tất cả những thứ đó? Bài này trả lời bằng cách vẽ bức tranh Modern Data Stack (MDS) — tập hợp các lớp công cụ đã trở thành chuẩn de-facto để hiện thực hoá kiến trúc dữ liệu hiện đại.

Một cảnh báo đặt trước, vì nó quan trọng nhất bài: Modern Data Stack không phải Data Mesh. MDS là công nghệ; mesh là cách tổ chức con người và trách nhiệm quanh công nghệ đó. Bạn có thể mua đủ mọi công cụ hiện đại mà vẫn vận hành một data warehouse tập trung silo kiểu cũ. Ta sẽ quay lại điểm này ở cuối. Trước hết, hãy đi qua từng lớp.

Modern Data Stack là gì

"Modern Data Stack" là tên gọi cho một kiến trúc dữ liệu ra đời khoảng 2015–2020, khi kho dữ liệu đám mây (cloud warehouse) trở nên rẻ và co giãn đủ để thay đổi luật chơi. Đặc trưng của MDS:

• Cloud-native, tách compute khỏi storage — trả tiền theo lượng dùng, scale co giãn.
• Modular, ghép từ nhiều công cụ chuyên biệt (best-of-breed) thay vì một monolith khép kín. Mỗi lớp có công cụ tốt nhất của nó, nối với nhau qua storage chung.
• ELT thay vì ETL — nạp thô trước, biến đổi sau, ngay trong warehouse/lakehouse.
• SQL là ngôn ngữ trung tâm, kéo được cả analyst lẫn engineer vào cùng một luồng.

Bức tranh tổng thể các lớp:

Đi qua từng lớp

1. Ingestion / EL — đưa dữ liệu vào

Vai trò: kéo dữ liệu thô từ nguồn (core banking, CRM, ứng dụng, SaaS) vào storage trung tâm, giữ nguyên hình dạng gốc, chưa biến đổi. Chữ "E" và "L" trong ELT nằm ở lớp này.

• Fivetran — dịch vụ EL quản lý (managed), hàng trăm connector dựng sẵn, tự lo schema drift. Đắt nhưng gần như zero-maintenance.
• Airbyte — mã nguồn mở, self-host được, connector cộng đồng lớn. Phù hợp khi cần chủ động và kiểm soát chi phí/on-prem.
• CDC với Debezium — Change Data Capture đọc transaction log của database nguồn (Oracle redo log, PostgreSQL WAL) để bắt từng thay đổi row gần thời gian thực, phát ra Kafka. Đây là cách chuẩn để đồng bộ liên tục từ hệ thống giao dịch mà không truy vấn nặng lên nguồn — xem thêm kiến trúc Kafka.

2. Storage + Compute — nơi dữ liệu ở và được xử lý

Đây là trái tim của stack, chia làm hai nhánh lớn:

Warehouse — kho dữ liệu quan hệ tối ưu cho phân tích, cột-hoá (columnar), SQL-first:

• Snowflake — tách hoàn toàn storage/compute, "virtual warehouse" scale độc lập, quản trị đơn giản.
• BigQuery — serverless, không cần quản cluster, trả tiền theo byte quét — xem tổng quan BigQuery.

Lakehouse — hội tụ ưu điểm của data lake (rẻ, mở, lưu mọi định dạng trên object storage) với warehouse (transaction ACID, schema, hiệu năng SQL):

• Databricks — nền tảng lakehouse trên Spark + Delta Lake.
• Apache Iceberg / Delta Lake — các table format mở đặt lên trên file Parquet ở object storage, thêm ACID, time-travel, schema evolution. Chi tiết ở bài Lakehouse.

Vì sao lakehouse quan trọng cho mesh: nó cho phép một lớp storage mở, chia sẻ được, nhiều engine (Spark, Trino, warehouse) cùng đọc một bảng — đúng tinh thần domain tự chủ nhưng dùng chung nền tảng.

3. Transformation — biến thô thành dùng được

Vai trò: từ dữ liệu thô đã nạp, xây các model sạch, chuẩn hoá, tổng hợp mà nghiệp vụ dùng được. dbt (data build tool) gần như thống trị lớp này:

• Viết transformation bằng SQL SELECT thuần, dbt lo materialize thành table/view.
• Quản lý dependency giữa model thành DAG, chạy đúng thứ tự.
• Có test dữ liệu, documentation và lineage ngay trong code — biến transformation thành kỹ thuật phần mềm thực thụ. Xem series dbt.

dbt là lý do ELT khả thi: nó khiến việc "L rồi mới T" trở nên có kỷ luật, version-controlled và testable.

4. Orchestration — điều phối

Vai trò: chạy đúng thứ tự, đúng lịch, xử lý phụ thuộc, retry khi lỗi, cảnh báo khi hỏng.

• Airflow — chuẩn công nghiệp lâu năm, DAG viết bằng Python, hệ sinh thái operator khổng lồ.
• Dagster — thế hệ mới, mô hình asset-based (điều phối theo "tài sản dữ liệu" chứ theo task), tích hợp chặt với dbt, kiểm thử/local-dev tốt hơn.

5. Streaming — dữ liệu thời gian thực

Khi batch không đủ (chống gian lận, cảnh báo tức thời, số dư real-time):

• Apache Kafka — nền tảng log phân tán, xương sống cho event streaming và CDC.
• Apache Flink — engine xử lý luồng có trạng thái (stateful), làm windowing, join stream, aggregation liên tục với semantics exactly-once.

6. Catalog & Discovery — tìm và hiểu dữ liệu

Vai trò: giúp người dùng tìm data product, hiểu ý nghĩa, xem chủ sở hữu, lineage, độ tin cậy — nền tảng của nguyên tắc "khám phá được" trong data-as-product.

• DataHub, OpenMetadata — catalog mã nguồn mở, thu thập metadata + lineage tự động, hỗ trợ ownership/tag/glossary.

7. Observability & Data Quality — quan sát và chất lượng

Vai trò: phát hiện dữ liệu sai/thiếu/trễ trước khi nghiệp vụ dùng nhầm.

• Great Expectations — framework khai báo "kỳ vọng" (expectation) về dữ liệu rồi kiểm định trong pipeline — hợp để cài đặt data contract.
• Monte Carlo — data observability tự động: phát hiện anomaly về volume/freshness/schema (khái niệm "data downtime") mà không cần viết rule tay.

8. Reverse ETL — đưa dữ liệu trở lại nghiệp vụ

Chiều ngược của EL: đẩy dữ liệu đã tổng hợp từ warehouse ra lại các hệ thống vận hành (CRM, tool marketing, hệ thống gọi điện). Ví dụ: đẩy điểm rủi ro hoặc phân khúc khách hàng tính trong warehouse ra CRM để nhân viên quan hệ khách hàng dùng. Đây là cách "operationalize" phân tích.

9. BI & Visualization — trực quan hoá

Vai trò: dashboard, báo cáo, self-service analytics cho người dùng cuối.

• Superset, Metabase — mã nguồn mở, self-host được, phù hợp on-prem.
• Looker — thương mại, mạnh ở semantic layer (LookML).

10. Semantic layer — tầng ngữ nghĩa

Vai trò: định nghĩa metric một lần, dùng ở mọi nơi (một chỗ khai báo "dư nợ", "NIM", "khách hàng active"), tránh mỗi dashboard tự tính một kiểu ra số khác nhau. Xuất hiện ở dbt Semantic Layer, Looker (LookML), Cube. Đây là mảnh còn non nhưng đang trở thành trọng tâm.

Vì sao ELT thay ETL

ETL (Extract → Transform → Load) biến đổi dữ liệu trước khi nạp vào kho; ELT (Extract → Load → Transform) nạp thô vào kho trước, rồi biến đổi bên trong kho bằng chính compute của kho.

Khía cạnh	ETL (cũ)	ELT (hiện đại)
Nơi transform	Server/engine riêng bên ngoài	Trong warehouse/lakehouse
Compute	Cố định, phải mua trước	Co giãn, trả theo dùng
Dữ liệu thô	Thường bị bỏ sau khi biến đổi	Giữ lại, transform lại được
Sửa logic	Chạy lại toàn bộ pipeline	Chỉ chạy lại model SQL (dbt)
Ai làm được	Kỹ sư chuyên ETL	Cả analyst (SQL)

ELT thắng thế vì cloud warehouse khiến compute rẻ và co giãn, nên "cứ nạp hết vào rồi tính" trở nên khả thi. Giữ lại dữ liệu thô nghĩa là khi định nghĩa nghiệp vụ đổi, ta transform lại mà không cần nạp lại nguồn. dbt biến bước T thành code có test/version — đó là mảnh ghép làm ELT trưởng thành.

Lakehouse hội tụ lake với warehouse

Trước đây tồn tại hai thế giới tách biệt: data lake (rẻ, mở, lưu file thô, hợp cho ML/big data, nhưng thiếu ACID và dễ thành "đầm lầy dữ liệu") và data warehouse (SQL nhanh, có transaction/quản trị, nhưng đóng và đắt). Tổ chức thường phải chạy cả hai và copy dữ liệu qua lại.

Lakehouse xoá ranh giới đó: đặt table format mở (Iceberg/Delta) lên object storage rẻ, thêm ACID transaction, schema evolution, time-travel — để một lớp storage vừa phục vụ ML/streaming vừa phục vụ SQL analytics, nhiều engine cùng đọc. Với mesh, đây là nền tảng lý tưởng vì nó mở và chia sẻ được giữa các domain. Chi tiết kỹ thuật ở bài Lakehouse.

Bản đồ công nghệ vào 4 nguyên tắc Mesh

Đây là mấu chốt để nối bài này với cả series. Modern Data Stack không thay thế mesh — nó là vật liệu để xây mesh:

• Domain ownership → warehouse/lakehouse chia không gian theo domain (schema/database riêng), mỗi domain sở hữu pipeline của mình.
• Data as product → dbt tạo model có test/doc; catalog (DataHub) làm data product khám phá được; observability/DQ đảm bảo đáng tin cậy.
• Self-serve platform → đây chính là nơi MDS phát huy nhất: platform team đóng gói cả stack (ingestion + storage + dbt template + orchestration + catalog) thành một "paved road" để domain lắp ráp data product mà không phải tự dựng hạ tầng. Xem lại bài self-serve platform.
• Federated governance → catalog + DQ + policy engine là chỗ cài đặt các quy tắc chung (naming, PII, contract) rồi tự động thực thi xuyên domain.

Nói cách khác: data product được xây trên stack; stack là công cụ, không phải mục tiêu.

Cảnh báo: Modern Data Stack ≠ Data Mesh

Nhầm lẫn tai hại nhất trong ngành hiện nay: mua đủ Fivetran + Snowflake + dbt + Airflow + DataHub rồi tuyên bố "chúng ta đã làm data mesh". Sai.

• Mesh là mô hình tổ chức — về việc ai sở hữu, ai chịu trách nhiệm, ranh giới domain, contract giữa các đội. Đây là chuyện con người và trách nhiệm.
• MDS là công nghệ — công cụ để hiện thực. Bạn hoàn toàn có thể dùng đúng bộ công cụ này để dựng một data warehouse tập trung do một đội platform độc quyền vận hành — tức là silo kiểu cũ khoác áo mới.

Công cụ không tự tạo ra quyền sở hữu phân tán, không tự tạo tư duy sản phẩm, không tự tạo quản trị liên bang. Nếu bạn triển khai stack hiện đại nhưng vẫn để một đội trung tâm ôm hết mọi pipeline, bạn có modern data stack chứ không có mesh. Ngược lại, mesh không đòi hỏi mua đúng bộ công cụ đắt tiền — nhiều tổ chức làm mesh tốt trên nền tảng khiêm tốn hơn nhờ mô hình tổ chức đúng.

Build vs Buy

Với mỗi lớp, câu hỏi lặp lại: tự xây, mua SaaS, hay dùng mã nguồn mở self-host?

Lựa chọn	Ưu	Nhược	Hợp khi
Buy (SaaS)	Nhanh, ít vận hành	Đắt, dữ liệu ra ngoài, khoá nhà cung cấp	Startup, ưu tiên tốc độ
Open-source self-host	Kiểm soát, on-prem, chi phí license = 0	Tốn nhân lực vận hành	Có đội platform, cần chủ quyền dữ liệu
Build tự làm	Vừa khít nhu cầu	Rất tốn, dễ sa lầy	Chỉ khi thực sự khác biệt

Nguyên tắc: mua/dùng lại phần không tạo khác biệt, chỉ tự xây phần cốt lõi của nghiệp vụ mình. Không ngân hàng nào nên tự viết một Airflow.

Bối cảnh ngân hàng: chọn stack cho on-prem tuân thủ

Ngân hàng Việt Nam có ràng buộc đặc thù làm lệch cán cân so với công thức MDS đám mây điển hình:

• Chủ quyền dữ liệu & quy định: dữ liệu khách hàng thường phải nằm trong nước, nhiều trường hợp on-prem hoặc private cloud. Điều này loại nhiều SaaS thuần đám mây (Fivetran managed, Snowflake public) hoặc buộc dùng phiên bản triển khai riêng.
• Ưu tiên open-source self-host: vì lý do trên, ngân hàng thường nghiêng về Airbyte, dbt-core, Airflow/Dagster, Trino/Spark trên lakehouse (Iceberg/Delta), DataHub/OpenMetadata, Great Expectations, Superset/Metabase — bộ này self-host được toàn bộ, dữ liệu không rời hạ tầng nội bộ.
• CDC từ core banking: nguồn chính là core (thường Oracle). CDC qua Debezium/GoldenGate → Kafka là kênh ingestion trọng yếu, phải giảm tải lên hệ thống giao dịch.
• Bảo mật & audit: mọi truy cập phải log, PII phải che/mã hoá — lớp catalog + policy engine không phải tuỳ chọn mà là bắt buộc.

Ví dụ một stack tham khảo hợp NCB: Debezium/Kafka + Airbyte (ingestion) → lakehouse Iceberg trên object storage nội bộ + Trino/Spark (storage/compute) → dbt-core (transformation) → Dagster (orchestration) → DataHub + Great Expectations (governance) → Superset (BI). Tất cả self-host, dữ liệu không rời trung tâm dữ liệu.

Xu hướng

• Data contracts — chuẩn hoá giao kèo schema/semantics/SLO giữa producer và consumer (xem bài data contract), dịch chuyển kiểm tra chất lượng về bên trái (shift-left).
• Semantic layer trở thành trung tâm — metric định nghĩa một lần, mọi công cụ BI/AI dùng chung.
• AI/LLM trên dữ liệu — text-to-SQL, trợ lý phân tích, tự sinh doc/lineage; đồng thời stack trở thành nền cấp dữ liệu cho AI (feature, RAG, context). Chất lượng và governance càng quan trọng vì AI khuếch đại cả cái đúng lẫn cái sai.

Bài tiếp theo, mesh-08, bàn con đường triển khai mesh thực tế trong ngân hàng.

Use case thực tế

Bối cảnh. NCB muốn dựng nền tảng dữ liệu cho 6 domain (Tiền gửi, Cho vay, Thẻ, Rủi ro, Marketing, Vận hành), ràng buộc dữ liệu on-prem, ngân sách license hạn chế. Team platform 4 người được giao chọn stack và dựng "paved road".

Quyết định stack (self-host toàn bộ).

Lớp	Chọn	Lý do
Ingestion	Debezium→Kafka (core Oracle) + Airbyte (SaaS/CRM)	CDC nhẹ tải core; Airbyte cho nguồn phụ
Storage/Compute	Lakehouse Iceberg + Trino	Mở, on-prem, nhiều engine cùng đọc
Transformation	dbt-core	Test/doc/lineage, analyst dùng được
Orchestration	Dagster	Asset-based, hợp dbt
Governance	DataHub + Great Expectations	Discovery + cài đặt data contract
BI	Superset	Self-host, miễn phí license

Kết quả sau 6 tháng. Platform đóng gói stack thành template: một domain mới clone repo mẫu, khai báo nguồn + model dbt, CI tự dựng pipeline Dagster và đăng ký catalog. Time-to-first-data-product rút từ ~10 tuần (tự dựng thủ công) xuống ~4 ngày. Domain Rủi ro publish "data product khách hàng có rủi ro" (dbt model + Great Expectations test + đăng ký DataHub), rồi Reverse ETL đẩy phân khúc ra CRM cho quan hệ khách hàng dùng.

Điểm mấu chốt rút ra. Ban đầu team định gọi đây là "đã làm data mesh". Thực tế 3 tháng đầu vẫn là warehouse tập trung: platform team ôm hết pipeline, domain chỉ mở ticket. Chỉ khi chuyển quyền sở hữu pipeline về từng domain (đổi mô hình tổ chức, không đổi công cụ) thì mới thực sự thành mesh. Đúng như cảnh báo: stack là điều kiện cần, không phải điều kiện đủ.

Ghi nhớ

• Modern Data Stack = kiến trúc cloud-native, modular, ELT-first gồm ~10 lớp: ingestion/EL, storage+compute, transformation, orchestration, streaming, catalog, observability/DQ, reverse ETL, BI, semantic layer.
• Công cụ tiêu biểu mỗi lớp: Fivetran/Airbyte/Debezium; Snowflake/BigQuery/Databricks/Iceberg/Delta; dbt; Airflow/Dagster; Kafka/Flink; DataHub/OpenMetadata; Great Expectations/Monte Carlo; Superset/Metabase/Looker.
• ELT thay ETL vì compute cloud rẻ và co giãn: nạp thô trước, transform trong kho (dbt), giữ dữ liệu thô để tính lại khi định nghĩa đổi.
• Lakehouse hội tụ lake (rẻ, mở) + warehouse (ACID, SQL) qua table format mở → nền tảng chia sẻ lý tưởng cho mesh.
• Công nghệ bản đồ vào 4 nguyên tắc mesh: domain sở hữu schema; data product = dbt+test+catalog; self-serve = đóng gói cả stack; governance = catalog+DQ+policy.
• Modern Data Stack ≠ Data Mesh: mesh là mô hình tổ chức, MDS là công nghệ. Mua đủ công cụ không tạo ra mesh; ngược lại có thể dựng silo cũ bằng công cụ mới.
• Build vs buy: mua/dùng lại phần không khác biệt, tự xây phần cốt lõi. Đừng tự viết Airflow.
• Ngân hàng on-prem: nghiêng open-source self-host (Airbyte, dbt-core, Dagster, Iceberg/Trino, DataHub, Great Expectations, Superset) để giữ dữ liệu trong nước; CDC từ core là kênh ingestion trọng yếu.
• Xu hướng: data contract, semantic layer, AI/LLM trên và từ dữ liệu — càng đề cao chất lượng và governance.