DataOps nâng cao 1 — Bản chất & kiến trúc tham chiếu

Rất nhiều tổ chức tuyên bố "đã làm DataOps" sau khi cài dbt, dựng Airflow và bật CI trên GitLab. Ba tháng sau, họ vẫn mất bốn ngày để đưa một chỉ tiêu mới lên báo cáo, vẫn phát hiện số liệu sai từ email phàn nàn của nghiệp vụ thay vì từ hệ thống, và vẫn không ai dám sửa một model vì "không biết nó phá cái gì". Công cụ đã có đủ, nhưng bản chất thì chưa. Đó là lý do series này bắt đầu không phải từ công cụ, mà từ câu hỏi: DataOps thực sự là gì, và một nền tảng dữ liệu tin cậy trông ra sao ở cấp kiến trúc?

Bài DataOps — Tổng quan đã đặt nền về Agile + DevOps + Lean, ba vòng lặp và văn hoá. Bài này không lặp lại mà đào sâu hai thứ: (1) bản chất socio-technical của DataOps và vì sao nó khó hơn DevOps thuần, (2) một kiến trúc tham chiếu end-to-end đầy đủ — trục xương sống mà toàn bộ series nâng cao sẽ bám vào.

Bản chất: DataOps tối ưu điều gì?

Bỏ qua mọi định nghĩa hoa mỹ, DataOps là một hệ thống socio-technical (con người + quy trình + công cụ đan xen, không tách rời) nhằm tối ưu một đại lượng duy nhất:

Rút ngắn thời gian từ "ý tưởng" → "dữ liệu tin cậy trong tay người dùng", đồng thời TĂNG chất lượng và GIẢM rủi ro.

Ba vế này phải đi cùng nhau. Nhanh mà sai thì tệ hơn chậm mà đúng — trong ngân hàng, một báo cáo an toàn vốn (CAR) sai gửi lên NHNN không chỉ mất uy tín mà có thể vi phạm quy định. Vì vậy DataOps không phải "làm nhanh bằng mọi giá" mà là làm nhanh một cách an toàn và lặp lại được.

Hệ thống này vận hành qua ba vòng đan nhau:

• DEV pipeline — vòng phát triển & thay đổi analytics như phần mềm: một yêu cầu nghiệp vụ → nhánh Git → viết/sửa model → test trên môi trường dev → review → merge → deploy. Đây là nơi "thay đổi" xảy ra một cách có kiểm soát.
• VALUE pipeline — vòng chạy production giao dữ liệu hằng ngày: nguồn → ingestion → transform → phục vụ, chạy đúng lịch, đúng SLA (Service Level Agreement — cam kết mức dịch vụ). Đây là nơi "giá trị" được giao đều đặn.
• FEEDBACK loop — vòng giám sát & cải tiến: metric chất lượng, cảnh báo lỗi, số liệu vận hành và phản hồi người dùng quay ngược về, dẫn dắt cải tiến ở cả hai vòng trên.

Điểm cốt lõi: DEV pipeline thay đổi VALUE pipeline một cách an toàn, còn FEEDBACK loop đảm bảo cả hai không ngừng tốt lên. Thiếu bất kỳ vòng nào là DataOps què quặt — có DEV+VALUE mà thiếu FEEDBACK thì bạn "bay mù"; có VALUE+FEEDBACK mà thiếu DEV kỷ luật thì mỗi thay đổi là một canh bạc.

Ba đặc thù khiến DataOps khó hơn DevOps

DataOps mượn rất nhiều từ DevOps, nhưng có ba đặc thù khiến việc bê nguyên DevOps sang là không đủ:

1. Phải test cả DỮ LIỆU, không chỉ CODE. Trong DevOps, đầu vào (mã nguồn) nằm trong tầm kiểm soát: bạn viết ra nó, test nó, và nó không tự đổi. Trong DataOps, dữ liệu đầu vào thay đổi ngoài tầm kiểm soát của bạn — hệ nguồn Core Banking thêm một cột, nhập một mã sản phẩm mới, hay đơn giản là một ngày lễ khiến khối lượng giao dịch tụt 90%. Code không đổi một dòng nhưng output vẫn sai. Vì vậy DataOps phải kiểm soát cả pipeline code (test như phần mềm) lẫn data đi qua pipeline (test trên dữ liệu thực, liên tục). Đây là gốc rễ của data quality tests và data contracts (bài 5).

2. Nhiều bên tiêu thụ với kỳ vọng khác nhau. Một API phần mềm thường có hợp đồng interface rõ ràng cho một loại client. Một bảng dữ liệu (ví dụ fct_giao_dich) lại được dùng đồng thời bởi: phòng Rủi ro (cần độ chính xác tuyệt đối), phòng Marketing (cần tốc độ, chấp nhận gần đúng), một dashboard Ban điều hành, và một mô hình ML chấm điểm tín dụng. Cùng một dataset, bốn kỳ vọng về độ trễ, độ chính xác và độ ổn định schema. Một thay đổi làm hài lòng bên này có thể phá vỡ bên kia.

3. Tính đúng đắn khó xác minh. Với phần mềm, "đúng" thường nhị phân: test pass/fail, chức năng chạy/không chạy. Với dữ liệu, "đúng" là một phổ mờ: con số 1.234 tỷ dư nợ là đúng hay sai? Không có oracle tuyệt đối — bạn chỉ có thể kiểm tra tính hợp lý (không âm, khớp tổng kiểm soát, nằm trong biên độ so với hôm qua). Sai lệch dữ liệu thường âm thầm: không có exception, không có màn hình đỏ, chỉ là một con số hơi lệch mà không ai nhận ra cho tới khi quá muộn.

Khía cạnh	DevOps	DataOps
Đầu vào chính	Code (bạn kiểm soát)	Code + Data (data ngoài kiểm soát)
Phát hiện lỗi	Exception, test fail rõ ràng	Sai lệch âm thầm, khó thấy
Người tiêu thụ	Thường 1 loại client, hợp đồng rõ	Nhiều bên, kỳ vọng mâu thuẫn
"Đúng" nghĩa là gì	Nhị phân, xác minh được	Phổ mờ, chỉ kiểm tra hợp lý
Rollback	Deploy lại phiên bản cũ	Phải xử lý cả dữ liệu đã sinh sai

Kiến trúc tham chiếu DataOps end-to-end

Đây là trọng tâm của bài — bức tranh xương sống mà cả series sẽ lấp đầy. Một nền tảng DataOps trưởng thành có bảy lớp trong value pipeline, được bao quanh bởi ba lớp cắt ngang (cross-cutting): CI/CD & môi trường, data quality & contracts, observability & catalog. Bao quanh nghĩa là các lớp này không nằm trên một đoạn của luồng mà áp lên mọi đoạn.

Giải thích từng lớp và cách chúng phối hợp:

1. Nguồn (Sources). Core Banking (thường qua CDC — Change Data Capture, bắt thay đổi theo thời gian thực), log ứng dụng, file từ đối tác, dữ liệu thị trường. Nguyên tắc: không transform tại nguồn, chỉ lấy nguyên trạng để mọi transform về sau đều tái lập được và audit được.

2. Ingestion / EL (Extract-Load). Đưa dữ liệu thô vào nền tảng chưa biến đổi. Đây là chữ "E" và "L" của ELT (Extract-Load-Transform — nạp thô trước, biến đổi sau, ngược với ETL cổ điển). Công cụ: Fivetran/Airbyte cho SaaS, Kafka/Debezium cho CDC streaming, hoặc script cho hệ đặc thù. Lớp này ghi vào Bronze.

3. Lakehouse / Warehouse — kiến trúc medallion. Lưu trữ phân tầng: Bronze (raw bất biến, giữ nguyên để replay & audit) → Silver (đã làm sạch, khử trùng lặp, chuẩn hoá kiểu, áp dụng data quality cơ bản) → Gold (mô hình nghiệp vụ, các mart/fact/dim sẵn sàng cho tiêu thụ). Tầng hoá này chính là nơi value pipeline vật chất hoá, và là biên giới tự nhiên để đặt các cổng kiểm tra chất lượng.

4. Transform — dbt. Chữ "T" của ELT. dbt biến SQL declarative thành model có version, có test, có tài liệu, có lineage. Chính lớp này cho phép "coi analytics như phần mềm" — mỗi transform là một artifact review được, test được (chi tiết ở bài 2).

5. Orchestration — Airflow. Airflow điều phối thứ tự và phụ thuộc: khi nào chạy ingestion, khi nào trigger dbt, khi nào chạy DQ, retry ra sao khi lỗi, backfill thế nào. Orchestration không làm transform mà điều phối các lớp 2→3→4→7 thành một luồng có SLA (bài 3).

6. Data Quality & Contracts. Đặt cổng kiểm tra tại ranh giới các tầng: dbt tests (unique, not_null, relationships), Great Expectations cho kiểm tra thống kê phức tạp, và data contracts — cam kết schema + ngữ nghĩa giữa producer và consumer. Đây là câu trả lời cho đặc thù "phải test cả dữ liệu" (bài 5, liên hệ data contracts và chất lượng dữ liệu).

7. Observability & Catalog / Lineage. Trong khi DQ trả lời "dữ liệu này có đúng không", observability trả lời "hệ thống dữ liệu có khoẻ không": freshness (độ tươi), volume (khối lượng bất thường), schema drift, và lineage (truy vết một cột từ báo cáo ngược về nguồn). Catalog giúp tìm và hiểu dataset (bài 6, liên hệ catalog & lineage).

Phục vụ (Serving). Gold layer nuôi ba loại consumer: BI/dashboard, Data API cho ứng dụng nội bộ, và feature store/ML cho mô hình. Mỗi consumer có SLA và data contract riêng.

CI/CD & Môi trường — lớp bao quanh tất cả. Mọi thay đổi ở lớp 2–7 đi qua Git, CI (chạy test tự động khi mở PR), và promote qua các môi trường dev → staging → prod tách biệt. Đây là thứ khiến "thay đổi an toàn" thành hiện thực (bài 4, liên hệ CI/CD).

Ánh xạ series vào kiến trúc

Toàn bộ series nâng cao chính là đi sâu vào từng khối của bức tranh trên:

Bài	Lớp trong kiến trúc
Bài 2 — dbt & ELT	Lớp 4 Transform
Bài 3 — Airflow orchestration	Lớp 5 Orchestration
Bài 4 — CI/CD cho analytics	Lớp bao quanh CI/CD
Bài 5 — Quality & contracts	Lớp 6 DQ & Contracts
Bài 6 — Observability & DRE	Lớp 7 Observability
Bài 7 — Platform & self-service	Toàn nền tảng
Bài 8 — Case study ngân hàng	Ráp toàn bộ end-to-end

Phân biệt: DataOps vs Data Engineering vs MLOps vs SRE

Bốn khái niệm hay bị lẫn. Ranh giới:

	Đối tượng chính	Câu hỏi cốt lõi
Data Engineering	Xây pipeline, mô hình dữ liệu	Làm sao xây được hệ thống dữ liệu?
DataOps	Cách vận hành & thay đổi pipeline	Làm sao giao dữ liệu tin cậy, nhanh, lặp lại?
MLOps	Vòng đời mô hình ML	Làm sao train/deploy/monitor mô hình?
SRE	Độ tin cậy dịch vụ (system)	Làm sao giữ hệ thống đạt SLO?

Cách nhớ gọn: Data Engineering là nghề xây; DataOps là kỷ luật vận hành áp lên nghề đó (giống DevOps áp lên phát triển phần mềm). MLOps đứng trên DataOps — mô hình ML cần feature từ pipeline dữ liệu tin cậy, nên DataOps là nền móng của MLOps (xem MLOps pipelines). SRE là nguồn cảm hứng cho observability & xử lý sự cố của DataOps; khái niệm "Data Reliability Engineering" (DRE) chính là SRE áp cho dữ liệu (bài 6). Chúng không loại trừ nhau — một team trưởng thành dùng cả bốn góc nhìn.

Mô hình trưởng thành & vì sao công cụ không tạo ra DataOps

DataOps không phải trạng thái bật/tắt mà là một hành trình trưởng thành:

Cấp	Đặc trưng	Triệu chứng
0 — Thủ công	Query tay, sửa trực tiếp prod, không version	Số liệu lệch không ai giải thích được
1 — Có version	Code trong Git, chạy tay theo lịch	"Chạy được trên máy tôi"
2 — Tự động hoá	Orchestration + CI cơ bản	Pipeline chạy đều nhưng lỗi phát hiện muộn
3 — Có chất lượng	DQ tests + contracts + môi trường tách	Bắt lỗi trước khi tới người dùng
4 — Quan sát được	Observability + lineage + alerting	Biết lỗi trước khi nghiệp vụ phàn nàn
5 — Self-service	Nền tảng để team nghiệp vụ tự phục vụ	Data engineer làm platform, không làm từng report

Điểm mấu chốt — và là thông điệp xuyên suốt series: công cụ không tạo ra DataOps. Bạn có thể cài đủ dbt, Airflow, Great Expectations, một catalog xịn — và vẫn ở cấp 1 nếu không ai review PR, không ai định nghĩa SLA, không ai sở hữu dataset, và văn hoá vẫn là "sửa nóng trên prod cho nhanh". Ngược lại, một team kỷ luật với công cụ tối thiểu có thể đạt cấp 3. Con người (ai sở hữu, ai review, ai trực) + quy trình (Git flow, review, incident) + công cụ — cả ba mới tạo ra DataOps. Đây chính xác là nghĩa của "socio-technical": kỹ thuật và tổ chức khoá chặt vào nhau.

Use case thực tế

Bối cảnh (NCB). Phòng Tài chính cần chỉ tiêu mới trên báo cáo quản trị: tỷ lệ CASA (tiền gửi không kỳ hạn / tổng tiền gửi) theo chi nhánh, cập nhật hằng ngày. Trước khi có kiến trúc DataOps, quy trình là: một data engineer viết query tay trên warehouse prod, xuất Excel, gửi email — chu kỳ 4 ngày, và mỗi lần nguồn Core Banking đổi mã sản phẩm tiền gửi là con số sai âm thầm.

Sau khi ráp theo kiến trúc tham chiếu:

1. DEV pipeline. Engineer tạo nhánh Git, thêm một dbt model gold.fct_casa_chi_nhanh dựng trên silver đã chuẩn hoá mã sản phẩm, kèm dbt test: not_null cho tỷ lệ, test accepted_range (0–1), và một test so tổng tiền gửi khớp bảng kiểm soát. Mở PR → CI chạy toàn bộ test trên môi trường dev → đồng nghiệp review → merge.
2. VALUE pipeline. Airflow điều phối hằng ngày: CDC nạp Bronze → dbt build Silver → dbt build Gold → chạy DQ. Nếu test tỷ lệ ngoài [0,1] hoặc tổng lệch bảng kiểm soát, DAG fail và chặn publish, không đẩy số sai lên dashboard.
3. FEEDBACK loop. Observability giám sát freshness (Gold phải cập nhật trước 7h sáng) và volume (số dòng giao dịch không được tụt >40% so với trung bình 7 ngày). Cảnh báo bắn vào kênh trực trước khi nghiệp vụ kịp mở dashboard.

Kết quả (minh hoạ). Thời gian đưa một chỉ tiêu mới lên báo cáo: từ ~4 ngày còn <1 ngày. Số sự cố "số liệu sai phát hiện bởi nghiệp vụ": giảm về gần 0 vì lỗi bị chặn tại DQ gate hoặc phát hiện qua observability trước. Khi Core Banking đổi mã sản phẩm, contract test ở ranh giới Silver fail ngay thay vì để lỗi trôi tới Gold — đúng ba đặc thù đã nêu: kiểm soát cả dữ liệu, phục vụ nhiều consumer (Tài chính + Ban điều hành), và biến "đúng đắn khó xác minh" thành các kiểm tra hợp lý cụ thể.

Ghi nhớ

• DataOps là hệ socio-technical tối ưu một thứ: rút ngắn thời gian ý tưởng → dữ liệu tin cậy, đồng thời tăng chất lượng và giảm rủi ro — ba vế đi cùng nhau.
• Vận hành qua ba vòng: DEV (thay đổi có kiểm soát), VALUE (chạy production giao dữ liệu), FEEDBACK (giám sát & cải tiến). Thiếu vòng nào cũng què.
• Ba đặc thù khó hơn DevOps: phải test cả dữ liệu (đầu vào ngoài kiểm soát), nhiều consumer kỳ vọng khác nhau, và tính đúng đắn khó xác minh (sai lệch âm thầm).
• Kiến trúc tham chiếu 7 lớp value pipeline (nguồn → ingestion → lakehouse bronze/silver/gold → transform dbt → orchestration Airflow → DQ/contracts → observability/catalog → phục vụ BI/API/ML) được bao quanh bởi CI/CD & môi trường. DQ và observability áp lên mọi đoạn, không chỉ một đoạn.
• Medallion (bronze/silver/gold) cho biên giới tự nhiên để đặt các cổng kiểm tra chất lượng và replay/audit.
• Phân biệt: Data Engineering là nghề xây; DataOps là kỷ luật vận hành; MLOps đứng trên DataOps; SRE/DRE là cảm hứng cho observability.
• Công cụ không tạo ra DataOps — con người + quy trình + công cụ mới tạo. Trưởng thành đi từ cấp 0 (thủ công) tới cấp 5 (self-service platform).
• Trong ngân hàng, đây là nền tảng để giao dữ liệu/báo cáo tin cậy nhanh trong môi trường tuân thủ — nhanh mà sai là không chấp nhận được.