DataOps nâng cao 32 — Blueprint stack DataOps mã nguồn mở

Suốt 31 bài trước, series này đi qua từng trụ của một nền tảng dữ liệu tin cậy: kiến trúc tham chiếu, transform bằng dbt, quality & contracts, observability, platform self-service, data mesh... Mỗi bài giải một mảnh. Bài khép này ghép chúng lại thành một bức tranh vật lý: nếu ngày mai NCB quyết định dựng nền tảng DataOps hoàn toàn bằng mã nguồn mở, tự host trong nước, thì lắp những công cụ nào, vào lớp nào, nối với nhau ra sao?

Đây là một blueprint tham chiếu — không phải "danh sách công cụ hot", mà là một bộ khung có kiến trúc, có nguyên tắc lắp ghép, và có lộ trình. Vì sao chọn OSS tự host cho ngân hàng? Ba lý do rất cụ thể: (1) kiểm soát dữ liệu — dữ liệu khách hàng, giao dịch không rời khỏi hạ tầng nội bộ, đáp ứng yêu cầu chủ quyền dữ liệu và NĐ13/2023; (2) tuân thủ & giải trình — mọi thành phần đều mở, kiểm toán được, không có "hộp đen" của nhà cung cấp; (3) tránh lock-in và chi phí license — không phụ thuộc một vendor duy nhất, chi phí chuyển sang công sức vận hành thay vì phí bản quyền theo dung lượng.

Đánh đổi là có thật — ta sẽ nói thẳng ở cuối bài. Nhưng trước hết, hãy đi qua từng lớp.

Kiến trúc tổng thể theo lớp

Một stack DataOps hoàn chỉnh gồm 10 lớp, chia làm hai nhóm: dòng chảy dữ liệu (storage → ingestion → transform → serving) và các lớp ngang bao quanh (quality, observability, catalog, CI/CD, hạ tầng). Toàn bộ được minh hoạ dưới đây.

Lớp 1 — Storage / Lakehouse

Đây là nền móng. Có hai hướng lớn:

Hướng lakehouse (khuyến nghị cho dữ liệu lớn, đa dạng). Ba tầng tách biệt:

• Object storage — MinIO là S3-compatible, tự host, chạy tốt trên K8s; đóng vai trò kho lưu file thô/parquet, thay cho HDFS. Chuẩn S3 API giúp mọi công cụ phía trên (Trino, Spark, dbt-duckdb) nói chuyện được ngay.
• Table format — Apache Iceberg hoặc Delta Lake biến đống file parquet thành bảng có schema, ACID transaction, time-travel, schema evolution. Đây là thứ nâng "data lake" thành "lakehouse". Iceberg đang là chuẩn mở được ưa chuộng vì đa engine.
• Query engine — Trino (phân tán, truy vấn nhiều nguồn, hợp cho quy mô lớn) hoặc DuckDB (in-process, cực nhanh cho dữ liệu vừa, chạy được ngay trong dbt qua dbt-duckdb). Cặp DuckDB + object storage đủ mạnh cho phần lớn mart cỡ ngân hàng vừa.

Hướng warehouse OSS (đơn giản hơn, hợp khi dữ liệu chủ yếu quan hệ). Nếu không cần lakehouse phức tạp, một warehouse cột OSS là đủ:

• ClickHouse — cực nhanh cho analytics khối lượng lớn, aggregate/OLAP.
• PostgreSQL (+ extension như Citus) — quen thuộc, đủ cho mart vừa, dễ vận hành với đội đã biết Postgres.

Nguyên tắc chọn: bắt đầu bằng cái đơn giản nhất đủ dùng. Đừng dựng Iceberg + Trino + Spark khi 5 mart của bạn chạy ngon trên Postgres. Xem thêm chi phí & hiệu năng.

Lớp 2 — Ingestion / EL

Đưa dữ liệu từ nguồn vào lakehouse/warehouse. Hai kỹ thuật:

• Batch EL (Extract-Load) — Airbyte (nhiều connector sẵn, có UI) hoặc dlt (data load tool, thư viện Python nhẹ, khai báo bằng code, hợp CI/CD và người thích Git-first). dlt đặc biệt gọn cho đội nhỏ: một script Python là một pipeline, không cần dựng server.
• CDC (Change Data Capture) — bắt thay đổi real-time từ Core Banking mà không truy vấn nặng lên OLTP: Debezium đọc binlog/WAL của DB nguồn, đẩy event vào Kafka, downstream tiêu thụ. Đây là cách chuẩn để bảng giao dịch trong lakehouse luôn gần với nguồn mà không "cày" DB production. Chi tiết ở ingestion & CDC.

Nguyên tắc: EL, không ETL trong lớp này. Nạp thô, biến đổi để lớp transform lo.

Lớp 3 — Transform

Đây là trái tim của DataOps hiện đại, và câu trả lời gần như không phải bàn: dbt Core (bản OSS, không phải dbt Cloud). dbt biến transform thành phần mềm: model là file SQL versioned trong Git, có test, có docs, có lineage, chạy dbt run / dbt test trong CI. Toàn bộ triết lý analytics-engineering của series xoay quanh nó — xem transform bằng dbt và dbt overview.

dbt Core cắm vào mọi lớp storage ở trên qua adapter: dbt-trino, dbt-duckdb, dbt-clickhouse, dbt-postgres, dbt-spark. Đây chính là điểm interoperability then chốt: đổi storage không phải viết lại logic, chỉ đổi adapter và profile.

Lớp 4 — Orchestration

Điều phối "cái gì chạy khi nào, phụ thuộc cái gì". Hai lựa chọn OSS chín muồi:

• Apache Airflow — chuẩn de-facto, cộng đồng khổng lồ, nhiều operator, quen thuộc với hầu hết đội DE. Mô hình task-centric (DAG của task). Xem Airflow overview.
• Dagster — asset-centric: bạn khai báo tài sản dữ liệu (bảng, mart) và quan hệ giữa chúng, Dagster suy ra lịch chạy. Hợp tư duy data-aware, tích hợp dbt rất mượt, observability tốt sẵn. Xem Dagster assets.

Chọn thế nào? Đội đã có Airflow và quen → giữ Airflow. Đội mới, ưu tiên lineage/asset-aware → Dagster đáng cân nhắc. Cả hai đều đủ tốt; đừng đổi chỉ vì trend.

Lớp 5 — Data Quality

Test dữ liệu, không chỉ test code. Ba tầng bổ sung nhau:

• dbt tests — tuyến đầu, rẻ và gần logic: not_null, unique, accepted_values, relationships, cộng test tuỳ biến bằng SQL. Chạy ngay trong dbt test. Đây là 80% giá trị với 20% công.
• Great Expectations hoặc Soda Core — quality độc lập, expectation phong phú hơn, hợp kiểm dữ liệu ở tầng ingestion (trước khi vào dbt) hoặc kiểm nguồn ngoài dbt.
• Elementary — package dbt mã nguồn mở phát hiện anomaly (khối lượng, freshness, phân phối lệch) và ghi kết quả test vào bảng để dựng dashboard chất lượng.

Chi tiết cách ghép: quality & contracts và advanced testing.

Lớp 6 — Observability

Biết pipeline đang khoẻ hay ốm trước khi người dùng báo:

• Elementary (lại xuất hiện) — dashboard chất lượng & anomaly ngay trên metadata dbt, gần như miễn phí công nếu đã dùng dbt.
• OpenLineage + Marquez — chuẩn mở thu thập lineage runtime (job nào đọc/ghi dataset nào), Marquez là backend lưu và hiển thị. Trả lời được "mart NPL hỏng thì upstream nào là thủ phạm".
• Grafana + Prometheus — giám sát hạ tầng & vận hành: CPU/RAM của Trino, độ trễ job Airflow, số dòng nạp. Cặp này chuẩn công nghiệp cho metrics + cảnh báo.

Nền tảng lý thuyết ở observability & DRE và obs overview.

Lớp 7 — Catalog / Lineage

"Có dữ liệu gì, ở đâu, nghĩa là gì, ai dùng, đến từ đâu":

• OpenMetadata — catalog OSS toàn diện: metadata, lineage cột-tới-cột, glossary, data profiling, quyền, tích hợp sẵn dbt/Airflow/Superset. Rất mạnh cho ngân hàng cần glossary nghiệp vụ và giải trình.
• DataHub (LinkedIn) — catalog OSS quy mô lớn, mô hình metadata linh hoạt, mạnh về discovery và lineage ở quy mô data mesh.

Cả hai đều giải cùng bài toán; OpenMetadata thường dễ dựng hơn cho đội vừa. Liên hệ governance automation và governance overview.

Lớp 8 — BI / Serving

Đưa dữ liệu tới mắt người dùng:

• Apache Superset — BI OSS mạnh, nhiều loại chart, SQL Lab, dashboard, phân quyền theo hàng (RLS). Xem Superset cơ bản.
• Metabase — nhẹ, thân thiện, hợp người dùng nghiệp vụ tự khám phá; dựng nhanh hơn Superset.

Chọn theo đối tượng: analyst mạnh SQL, dashboard phức tạp → Superset; nghiệp vụ tự phục vụ nhanh → Metabase.

Lớp 9 — CI/CD

Analytics-as-code cần pipeline như phần mềm: Git (GitLab tự host / Gitea nếu muốn hoàn toàn nội bộ) làm nguồn sự thật, GitHub Actions hoặc GitLab CI chạy dbt build, dbt test, lint SQL (SQLFluff), và deploy khi merge. Kết hợp môi trường dev/staging/prod và pattern Write-Audit-Publish. Xem CI/CD cho analytics và environments & WAP.

Lớp 10 — Hạ tầng

Đế đỡ tất cả: Docker (đóng gói mỗi thành phần), Kubernetes (điều phối container ở quy mô, tự phục hồi, scale) — xem K8s production ops; và Terraform để khai báo hạ tầng bằng code (Infrastructure-as-Code), tái lập môi trường và kiểm toán thay đổi.

Bảng tổng hợp stack theo lớp

Nguyên tắc lắp ghép

Một stack không phải phép cộng công cụ — nó là kiến trúc. Bốn nguyên tắc:

1. Ưu tiên chuẩn mở & interoperability. Chọn công cụ nói chuyện qua chuẩn mở: S3 API, Iceberg table format, OpenLineage, dbt manifest. Nhờ đó thay một mảnh không phải làm lại toàn bộ — đổi DuckDB sang Trino chỉ là đổi adapter dbt.
2. Không over-engineer. Số công cụ tăng thì chi phí vận hành tăng theo cấp số nhân (nâng cấp, tích hợp, người trực). Mỗi công cụ phải kiếm được chỗ đứng bằng một nhu cầu thật.
3. Bắt đầu tối thiểu, rồi mở rộng. Không dựng cả 10 lớp ngày một. Dựng lõi chạy được trước (xem lộ trình dưới), thêm lớp khi đau thật sự.
4. Một công cụ một vai trò rõ. Tránh chồng chéo — đừng vừa GE vừa Soda vừa dbt tests kiểm cùng một thứ. Phân vai rành mạch.

OSS tự host vs managed — đánh đổi

Không có bữa trưa miễn phí. So sánh thẳng:

Với ngân hàng, cán cân thường nghiêng về OSS tự host cho các lớp chạm dữ liệu nhạy cảm (storage, ingestion, transform) vì chủ quyền dữ liệu và tuân thủ. Nhưng "công vận hành cao" là chi phí thật — cần đội có kỹ năng platform, nếu không, một stack OSS hoành tráng không ai chăm sẽ tệ hơn một managed đơn giản. Đây là quyết định chiến lược, không phải kỹ thuật thuần.

Tự host & tuân thủ

Điểm mạnh lớn nhất của blueprint này với ngân hàng: dữ liệu không rời khỏi hạ tầng nội bộ. Ba việc phải làm đúng để biến "tự host" thành "tuân thủ":

• Dữ liệu tại chỗ — MinIO, warehouse, Kafka đều chạy trong DC/VPC nội bộ; không có luồng ra internet với dữ liệu khách hàng. Đáp ứng chủ quyền dữ liệu và NĐ13/2023.
• Mã hoá — at-rest (mã hoá volume/object) và in-transit (TLS giữa mọi thành phần). MinIO, Postgres, Kafka đều hỗ trợ.
• Quyền & audit — phân quyền tối thiểu theo vai trò trên object storage, catalog, BI; ghi log truy cập. Xem access control, privacy & compliance và security trong pipeline.

Lộ trình dựng — MVP → mở rộng

Đừng dựng 10 lớp cùng lúc. Ba giai đoạn:

Giai đoạn 1 — MVP chạy được (1–2 tháng). Postgres/DuckDB (storage) + dlt (ingestion) + dbt Core (transform) + GitHub Actions (CI) + Metabase (BI). Năm thành phần, một luồng end-to-end chạy được, có test. Đã là DataOps thật.

Giai đoạn 2 — Vững & quan sát được (2–4 tháng). Thêm orchestration (Airflow/Dagster), Elementary + Grafana/Prometheus (observability), OpenMetadata (catalog), chuẩn hoá môi trường dev/staging/prod.

Giai đoạn 3 — Quy mô & mesh (khi cần). Nâng lên lakehouse (MinIO + Iceberg + Trino) khi dữ liệu vượt Postgres, CDC (Debezium+Kafka) cho real-time, phân domain theo data mesh, self-service theo platform.

Cạm bẫy thường gặp

• Ghép quá nhiều công cụ ("stack sưu tầm"). Mỗi công cụ nghe hay nên gom hết → 12 hệ thống, không ai vận hành nổi. Ít mà sâu hơn nhiều mà nông.
• Thiếu người vận hành. OSS tự host cần đội platform trực nâng cấp, vá lỗi. Không có người → nợ kỹ thuật chồng chất, stack mục ruỗng.
• Không có chuẩn mở làm keo. Ghép công cụ bằng tích hợp tuỳ biến thủ công → mỗi thay đổi phá vỡ chỗ khác. Bám chuẩn mở.
• Big-bang thay vì incremental. Dựng cả platform 6 tháng rồi mới ra mắt → rủi ro cao, không có phản hồi sớm. Dựng MVP, ship, học.
• Bỏ quên tuân thủ tới cuối. Mã hoá, quyền, audit phải thiết kế từ đầu, không "gắn thêm sau".

Bản đồ toàn series — 32 bài

Blueprint này chỉ có nghĩa vì đứng trên 31 bài trước. Toàn series xoay quanh bảy trụ:

• Kiến trúc & bản chất — DataOps là hệ socio-technical, ba vòng dev/value/feedback, kiến trúc tham chiếu end-to-end.
• Công cụ dòng chảy — dbt Core cho transform, Airflow/Dagster điều phối, Airbyte/dlt/Debezium nạp dữ liệu.
• Quality & Observability — test cả dữ liệu lẫn code, contracts, SLA/SLO, phát hiện lỗi trước người dùng.
• Platform & self-service — trừu tượng hoá hạ tầng, môi trường, chi phí/hiệu năng, để analyst tự phục vụ an toàn.
• Data Mesh & semantic layer — phân domain, sở hữu dữ liệu như sản phẩm, một metric một định nghĩa.
• Security & Governance — quyền, PII, mã hoá, tuân thủ tự động, giải trình.
• Ứng dụng — case study ngân hàng, walkthrough dự án, và blueprint OSS này.

Bài này là mảnh khép: nó không thêm khái niệm mới mà lắp mọi thứ đã học thành một hệ thống vật lý dựng được.

Ví dụ docker-compose minh hoạ (KHÔNG chạy được)

Kiến trúc lõi MVP gói gọn thành một compose (minh hoạ ý tưởng, không phải cấu hình production):

# minh hoạ — stack lõi tự host
services:
  minio:            # object storage S3-compatible
    image: minio/minio
  postgres:         # warehouse cho mart
    image: postgres:16
  dbt:              # transform (dbt Core, chạy qua CI)
    image: ghcr.io/dbt-labs/dbt-postgres
  dagster:          # orchestration asset-aware
    image: dagster/dagster
  metabase:         # BI self-service
    image: metabase/metabase
  # thêm khi mở rộng: trino, debezium+kafka, openmetadata, grafana...

Truy vấn qua lớp query của stack

Trên lớp query của lakehouse (Trino/DuckDB), một mart tổng hợp trông rất giống SQL Postgres chuẩn — đây chính là giá trị của chuẩn mở: cùng một SQL analytics chạy qua nhiều engine. Câu dưới minh hoạ một tổng hợp top khách theo dòng tiền vào — kiểu truy vấn mà một mart phục vụ BI hay dùng, chạy được trực tiếp trên sandbox PostgreSQL:

-- ▶ Chạy được
SELECT c.city,
       COUNT(DISTINCT c.id)                         AS so_khach,
       COUNT(t.id)                                  AS so_gd_vao,
       ROUND(SUM(t.amount)::numeric, 2)             AS tong_vao,
       ROUND(AVG(a.balance)::numeric, 2)            AS du_binh_quan
FROM customers c
JOIN accounts a       ON a.customer_id = c.id
JOIN transactions t   ON t.account_id  = a.id
WHERE t.kind = 'credit'
GROUP BY c.city
ORDER BY tong_vao DESC;

Điểm cần nhớ: cùng câu SQL này, khi lớp storage là Trino trên Iceberg, engine đổi nhưng logic mart giữ nguyên — đó là interoperability mà blueprint theo đuổi. (Trên Trino cú pháp ép kiểu có thể là CAST(... AS DECIMAL) thay vì ::numeric, khác biệt phương ngữ nhỏ do dbt macro che đi.)

Use case thực tế

Dựng nền tảng DataOps OSS tự host tại NCB — giai đoạn 1 (minh hoạ). Ban dữ liệu quyết định không mua data platform SaaS nước ngoài vì lo dữ liệu khách hàng ra ngoài lãnh thổ và chi phí license tăng theo dung lượng. Mục tiêu: 8 tuần có một luồng end-to-end chạy được cho báo cáo huy động vốn.

1. Chốt phạm vi MVP. 5 thành phần: DuckDB trên MinIO (storage), dlt (nạp từ Core Banking staging), dbt Core (transform), GitLab CI tự host (test + deploy), Metabase (BI). Không dựng Airflow/Trino/CDC ở giai đoạn này.
2. Tuần 1–2: hạ tầng. Terraform dựng namespace K8s nội bộ, MinIO với mã hoá at-rest, GitLab CI self-host. Không có luồng nào ra internet mang dữ liệu.
3. Tuần 3–4: nạp & transform. dlt kéo bảng tai_khoan, giao_dich từ replica read-only của Core Banking (không đụng OLTP production) vào MinIO/DuckDB. dbt dựng 4 model staging + 2 mart (mart_huy_dong_ngay, mart_huy_dong_kh).
4. Tuần 5: quality. 18 dbt tests (not_null, unique, relationships) + Elementary theo dõi freshness và anomaly khối lượng. CI chặn merge nếu test đỏ.
5. Tuần 6: BI + quyền. Metabase với RLS theo chi nhánh; kế toán chỉ thấy dữ liệu đơn vị mình. Log truy cập bật.
6. Tuần 7–8: nghiệm thu & bàn giao. Runbook vận hành, phân công người trực nâng cấp. Đo baseline: freshness mart ≤ 6h sáng, MTTR mục tiêu ≤ 2h.

Kết quả (minh hoạ): một nền tảng 5 công cụ, 0 phí license, dữ liệu 100% nội bộ, chạy end-to-end với test và BI phân quyền. Chi phí thật nằm ở một kỹ sư platform bán thời gian — và đó chính là đánh đổi ngân hàng chấp nhận để đổi lấy kiểm soát và tuân thủ. Giai đoạn 2 (Dagster, OpenMetadata, Grafana) lên kế hoạch cho quý sau, không big-bang.

Ghi nhớ

• Stack DataOps OSS hoàn chỉnh gồm 10 lớp: storage, ingestion, transform, orchestration, quality, observability, catalog, BI, CI/CD, hạ tầng.
• Bộ khung khuyến nghị: MinIO+Iceberg+Trino/DuckDB (hoặc ClickHouse/Postgres) / Airbyte-dlt-Debezium / dbt Core / Airflow-Dagster / dbt tests+GE/Soda+Elementary / OpenLineage-Marquez+Grafana / OpenMetadata-DataHub / Superset-Metabase / Git+CI / Docker-K8s-Terraform.
• Lắp ghép theo nguyên tắc: chuẩn mở & interoperability, không over-engineer, bắt đầu tối thiểu rồi mở rộng, một công cụ một vai trò.
• OSS tự host đổi kiểm soát/tự chủ/không license lấy công vận hành cao — ngân hàng thường chọn OSS cho lớp chạm dữ liệu nhạy cảm, nhưng phải có đội platform.
• Tự host giúp tuân thủ: dữ liệu ở nội bộ, mã hoá at-rest/in-transit, quyền tối thiểu + audit (NĐ13, chủ quyền dữ liệu) — thiết kế từ đầu, không gắn sau.
• Lộ trình: MVP 5 công cụ chạy được → vững & quan sát được → quy mô/mesh — mỗi giai đoạn có giá trị độc lập, không big-bang.
• Cạm bẫy: ghép quá nhiều công cụ, thiếu người vận hành, thiếu chuẩn mở làm keo, big-bang, bỏ quên tuân thủ.
• Bài khép series 32 bài — bảy trụ kiến trúc, công cụ, quality/observability, platform, mesh, security, ứng dụng hội tụ thành một blueprint dựng được, không phải lý thuyết.