DataOps nâng cao 25 — Analytics Engineering: vai trò & quy trình

Vai trò còn thiếu giữa hai bờ

Ở hầu hết ngân hàng, đội dữ liệu chia làm hai nhóm quen thuộc. Một bên là data engineer (DE) lo hạ tầng: dựng pipeline ingest từ core banking, card, LOS về data lake/warehouse, quản Airflow, tối ưu chi phí lưu trữ. Bên kia là data analyst (DA) và cán bộ nghiệp vụ: viết truy vấn, dựng dashboard, trả lời câu hỏi kinh doanh. Giữa hai bờ này có một khoảng trống rất tốn kém.

Khoảng trống đó là lớp biến đổi (transform). DE đổ về warehouse hàng trăm bảng thô — tên cột viết tắt khó hiểu, một khách hàng nằm rải ở năm hệ thống, ngày tháng ba định dạng, trạng thái mã hoá bằng số. DA muốn phân tích thì phải tự đi làm sạch, tự join, tự đoán nghĩa cột. Mỗi analyst làm lại một kiểu, và thế là "dư nợ" của người này lệch người kia. DE thì bận lo hạ tầng, không có thời gian (và thường không có bối cảnh nghiệp vụ) để chuẩn hoá dữ liệu thành mô hình phân tích tốt.

Analytics Engineer (AE) ra đời để lấp đúng khoảng trống này: người biến dữ liệu thô thành các mô hình dữ liệu sạch, tin cậy, có tài liệu và có test để analyst/nghiệp vụ tự phục vụ. Cách gọi ngắn gọn nhất: "software engineering áp dụng cho analytics".

Vai trò này không phải tự nhiên có. Nó xuất hiện cùng modern data stack (kho dữ liệu cloud như Snowflake/BigQuery + công cụ ingest như Fivetran/Airbyte + transform bằng dbt + BI) khoảng nửa cuối những năm 2010. Khi ingest và lưu trữ trở nên rẻ và dễ (chuyển từ ETL sang ELT — nạp thô trước, biến đổi sau ngay trong warehouse), nút thắt dịch từ "làm sao lấy được dữ liệu" sang "làm sao biến dữ liệu thô thành thứ dùng được". dbt cho phép làm bước transform bằng SQL + kỹ thuật phần mềm (version control, test, tài liệu, môi trường), và người chuyên trách công việc đó chính là AE.

AE làm gì

Cốt lõi công việc AE là lớp transform: nhận dữ liệu thô đã được ingest và biến nó thành mô hình dữ liệu phục vụ phân tích (analytics-ready data models). Cụ thể:

• Làm sạch & chuẩn hoá: đổi tên cột rõ nghĩa, thống nhất kiểu/định dạng, giải mã trạng thái, xử lý NULL, khử trùng lặp, chuẩn hoá đơn vị (VND, ngoại tệ).
• Mô hình hoá (modeling): gộp nhiều bảng thô thành các thực thể nghiệp vụ mạch lạc — khách hàng, tài khoản, giao dịch, khoản vay — dưới dạng mart mà analyst hiểu ngay.
• Đảm bảo chất lượng: viết test cho model (khoá không NULL, không trùng, giá trị hợp lệ, quan hệ referential) để dữ liệu sai bị chặn trước khi tới dashboard.
• Tài liệu hoá (documentation): mô tả từng model/cột, sinh data catalog và lineage tự động để người dùng biết con số đến từ đâu.
• Phục vụ self-service: kết quả là các bảng mart mà DA/nghiệp vụ chỉ việc SELECT, không cần join phức tạp hay hiểu bảng thô.

Điểm mấu chốt: AE không trả lời câu hỏi kinh doanh cuối cùng (đó là việc của analyst), cũng không lo hạ tầng ingest (việc của DE). AE làm cho dữ liệu đáng tin và dễ dùng — xây "sản phẩm dữ liệu" chứ không xây "báo cáo".

Phân biệt DE vs AE vs DA

Ba vai trò tạo thành một chuỗi: DE đưa dữ liệu vào, AE biến dữ liệu thành mô hình, DA rút ra insight.

Ranh giới không cứng nhắc: đội nhỏ thì một người kiêm cả DE và AE; đội lớn tách rõ. Nhưng chức năng thì luôn tồn tại — nếu không ai làm phần AE, phần đó sẽ bị đẩy sang DA (analyst mất thời gian làm sạch thay vì phân tích) hoặc DE (kỹ sư mất thời gian mà thiếu bối cảnh nghiệp vụ).

Kỹ năng của một AE

• SQL sâu: đây là ngôn ngữ chính. Không chỉ JOIN/GROUP BY mà cả window function, CTE, xử lý slowly-changing dimension, viết SQL sạch, đọc được và tối ưu.
• dbt: công cụ trung tâm — model, ref/source, test, macro (Jinja), snapshot, materialization, docs. Xem DataOps nâng cao 2 — dbt & ELT và dbt — Tổng quan.
• Mô hình hoá dữ liệu: hiểu dimensional/star schema, khi nào dùng mô hình rộng (OBT), phân tầng staging → intermediate → marts.
• Git & CI/CD: làm việc theo branch, pull request, review; hiểu pipeline CI chạy test trước khi merge — xem DataOps nâng cao 4 — CI/CD cho analytics.
• Hiểu nghiệp vụ: biết "khách hàng hoạt động", "CASA", "dư nợ nhóm 2" nghĩa là gì để mô hình hoá đúng. Đây là điểm phân biệt AE với kỹ sư thuần.
• Giao tiếp: cầu nối giữa hai thế giới — dịch yêu cầu nghiệp vụ mơ hồ thành đặc tả model, và giải thích giới hạn kỹ thuật cho nghiệp vụ.

Chú ý AE thường không cần Spark, Kafka hay Kubernetes ở mức chuyên sâu như DE. Sức mạnh của AE nằm ở SQL + tư duy kỹ thuật phần mềm + hiểu nghiệp vụ, chứ không phải hạ tầng phân tán.

Một mart AE tạo ra trông thế nào

Ví dụ AE dựng mart tổng hợp khách hàng — mỗi dòng một khách, kèm số tài khoản, tổng số dư, hoạt động giao dịch 90 ngày gần nhất. Analyst chỉ việc SELECT từ mart này thay vì tự join bốn bảng. Dưới đây là logic SELECT minh hoạ kết quả của một mart như vậy (trên sandbox chỉ đọc):

-- ▶ Chạy được
WITH acct AS (
  SELECT customer_id,
         COUNT(*)                              AS so_tai_khoan,
         SUM(balance)                          AS tong_so_du
  FROM accounts
  GROUP BY customer_id
),
txn AS (
  SELECT a.customer_id,
         COUNT(t.id)                           AS so_giao_dich_90n,
         SUM(CASE WHEN t.kind = 'debit'  THEN t.amount ELSE 0 END) AS tong_chi,
         SUM(CASE WHEN t.kind = 'credit' THEN t.amount ELSE 0 END) AS tong_thu
  FROM accounts a
  JOIN transactions t ON t.account_id = a.id
  WHERE t.created_at >= NOW() - INTERVAL '90 days'
  GROUP BY a.customer_id
)
SELECT c.id                                     AS customer_id,
       c.full_name,
       c.city,
       COALESCE(acct.so_tai_khoan, 0)           AS so_tai_khoan,
       COALESCE(acct.tong_so_du, 0)             AS tong_so_du,
       COALESCE(txn.so_giao_dich_90n, 0)        AS so_giao_dich_90n,
       ROUND(COALESCE(txn.tong_chi, 0)::numeric, 2) AS tong_chi_90n,
       ROUND(COALESCE(txn.tong_thu, 0)::numeric, 2) AS tong_thu_90n,
       CASE WHEN COALESCE(txn.so_giao_dich_90n, 0) > 0
            THEN 'active' ELSE 'dormant' END    AS trang_thai_hoat_dong
FROM customers c
LEFT JOIN acct ON acct.customer_id = c.id
LEFT JOIN txn  ON txn.customer_id  = c.id
ORDER BY tong_so_du DESC NULLS LAST;

Trong dbt thực tế, khối SQL này sẽ là file marts/fct_customer_summary.sql, kèm một file YAML khai báo test (customer_id unique + not_null, trang_thai_hoat_dong chỉ nhận active/dormant) và mô tả cho từng cột để sinh docs. Đó là khác biệt cốt lõi: không chỉ viết query, mà biến nó thành tài sản có kiểm thử và tài liệu.

Quy trình làm việc điển hình của AE

AE làm việc theo vòng lặp giống hệt kỹ sư phần mềm, chỉ khác đầu ra là mô hình dữ liệu:

1. Nhận yêu cầu nghiệp vụ: ví dụ khối bán lẻ cần "bảng khách hàng ưu tiên theo số dư và mức độ giao dịch". AE làm rõ định nghĩa: "ưu tiên" là gì, "hoạt động" tính theo bao nhiêu ngày.
2. Mô hình hoá: xác định thực thể (khách, tài khoản, giao dịch), grain của bảng đích (mỗi dòng = một khách), nguồn dữ liệu, khoá join. Đây là bước tư duy quan trọng nhất.
3. Viết dbt model + test + docs: tạo staging model làm sạch từng nguồn, rồi mart tổng hợp; thêm test và mô tả. Code sống trong Git.
4. PR & review: mở pull request. Peer AE review logic SQL; đôi khi kéo nghiệp vụ vào xác nhận định nghĩa.
5. CI: pipeline tự động build model và chạy toàn bộ test trên môi trường riêng biệt (không đụng production) — xem mẫu DataOps nâng cao 11 — môi trường & WAP. Test đỏ thì không merge.
6. Deploy: sau khi merge, model được build vào production theo lịch (orchestrator gọi dbt build).
7. Phục vụ & lặp: DA dựng dashboard trên mart mới. Phản hồi và yêu cầu mới quay lại bước 1.

So với cách cũ (analyst tự viết query rời rạc, sửa trực tiếp trên production, không ai review), quy trình này đưa kỷ luật phần mềm vào analytics: mọi thay đổi đều được version, review, test tự động trước khi ra thật.

Nguyên tắc nền tảng của AE

• Analytics-as-code: mọi logic biến đổi nằm trong file text, version bằng Git — không có logic "ẩn" trong dashboard hay query lưu tay. Nhờ vậy có lịch sử thay đổi, review, rollback.
• DRY (Don't Repeat Yourself): định nghĩa mỗi thứ một lần. Logic "khách hàng hoạt động" viết trong một staging/intermediate model, mọi mart dùng lại qua ref() thay vì chép công thức khắp nơi.
• Modular — phân tầng staging → intermediate → marts: staging làm sạch 1-1 với nguồn (đổi tên, ép kiểu); intermediate xử lý logic trung gian; marts là bảng nghiệp vụ cuối cho consumer. Mỗi tầng một trách nhiệm, dễ test và tái dùng.
• Test & document mọi thứ: mọi model có test (không trùng khoá, không NULL cột quan trọng, quan hệ hợp lệ) và mô tả. Xem dbt — Test & docs.
• Single source of truth: một chỉ tiêu/thực thể chỉ có một định nghĩa được duyệt; mọi báo cáo lấy từ đó. Đây là điều kiện tiên quyết để dashboard các phòng khớp nhau.
• Semantic consistency: đảm bảo cùng một chỉ tiêu (dư nợ, CASA, số khách hoạt động) mang cùng ý nghĩa ở mọi nơi. AE hiện đại đẩy định nghĩa chỉ số lên semantic layer để "define once, query anywhere" — xem DataOps nâng cao 19 — semantic layer.

AE trong tổ chức: nhúng domain vs trung tâm

Có ba mô hình bố trí AE trong ngân hàng:

• Đội trung tâm (centralized): tất cả AE ở một đội dữ liệu tập trung, phục vụ mọi phòng nghiệp vụ. Ưu điểm: chuẩn hoá cao, dễ giữ single source of truth. Nhược: xa nghiệp vụ, dễ thành nút cổ chai khi yêu cầu dồn.
• Nhúng domain (embedded): AE ngồi trong từng khối (tín dụng, thẻ, huy động), gần bài toán nghiệp vụ. Ưu: hiểu sâu, phản ứng nhanh. Nhược: dễ trôi khỏi chuẩn chung, mỗi domain một kiểu.
• Hub-and-spoke (kết hợp): một hub trung tâm giữ nền tảng, chuẩn, công cụ và quản trị; các spoke là AE nhúng trong domain, tuân chuẩn hub nhưng tự chủ trong domain của mình. Đây là mô hình phổ biến nhất khi quy mô lớn và là nền của data mesh — xem DataOps nâng cao 14 — data mesh khi mở rộng và nền tảng self-service.

Với ngân hàng vừa và lớn, hub-and-spoke thường là điểm cân bằng: đủ nhất quán để báo cáo NHNN khớp nhau, đủ linh hoạt để mỗi khối tự phát triển mart riêng.

Lộ trình sự nghiệp & đội hình data hiện đại

AE là một trong những vai trò tăng trưởng nhanh nhất trong đội dữ liệu hiện đại. Các lối vào phổ biến:

• Từ DA lên AE: analyst giỏi SQL, chán viết lại logic, học dbt + Git + mô hình hoá — lối đi tự nhiên nhất.
• Từ DE sang AE: kỹ sư muốn gần nghiệp vụ hơn, giảm hạ tầng.
• Lên cao: Senior AE → Analytics Engineering Lead → Head of Analytics Engineering / Data Platform. Nhiều tổ chức nay coi AE là xương sống của đội, còn DA tập trung vào phân tích sâu và DE tập trung nền tảng.

Đội hình data hiện đại điển hình: DE lo nền tảng & ingest → AE lo lớp mô hình hoá (thường đông nhất) → DA/data scientist lo insight, phối hợp qua quy trình chung. Văn hoá làm việc chung xem thêm DataOps — thực hành đội nhóm.

Công cụ hệ sinh thái

Cụm gọn nhất — và cũng là "trái tim" của công việc AE — là dbt + warehouse + Git + CI. Ba thứ còn lại (orchestrator, BI, catalog) bao quanh nhưng dbt là nơi AE dành phần lớn thời gian.

Use case thực tế

Khối bán lẻ NCB có 8 phòng nghiệp vụ, mỗi phòng tự dựng dashboard KPI khách hàng trên bảng thô. Kết quả: "số khách hàng hoạt động" tháng 5 hiện 6 con số khác nhau ở 6 dashboard (người tính hoạt động 30 ngày, người 90 ngày, người tính cả tài khoản đóng), mỗi lần họp giao ban mất ~30 phút cãi con số nào đúng. Analyst mỗi phòng dành ~40% thời gian đi làm sạch và join lại từ đầu.

Đội cử một AE đứng ra chuẩn hoá. Quy trình 3 tuần:

1. Tuần 1 — thống nhất định nghĩa: AE làm việc với các phòng, chốt "khách hàng hoạt động" = có ≥1 giao dịch trong 90 ngày trên tài khoản còn hiệu lực. Định nghĩa được duyệt và ghi vào docs.
2. Tuần 2 — xây mart: dựng chuỗi dbt stg_customers / stg_accounts / stg_transactions (làm sạch) → fct_customer_summary (mart tổng hợp mỗi khách một dòng, giống query minh hoạ ở trên). Thêm test: customer_id unique/not_null, trang_thai_hoat_dong ∈ {active, dormant}.
3. Tuần 3 — PR, CI, deploy: mở PR, peer review, CI build + chạy 12 test trên môi trường staging (2 test đỏ do dữ liệu trùng ở nguồn card → sửa staging), merge, orchestrator build hằng ngày.

Kết quả: 6 con số về 1; 8 phòng cùng SELECT từ một mart; thời gian analyst dành cho làm sạch giảm từ ~40% xuống gần 0, dồn vào phân tích. Con số "khách hàng hoạt động" nay có lineage rõ ràng, ai cũng truy được nguồn — báo cáo giao ban thôi tranh cãi và các phòng bắt đầu tin dashboard trở lại.

Ghi nhớ

• AE là cầu nối giữa DE (hạ tầng/ingest) và DA (phân tích/nghiệp vụ), ra đời cùng modern data stack & dbt; khẩu quyết: "software engineering cho analytics".
• Việc cốt lõi của AE là lớp transform: biến dữ liệu thô thành mart sạch, có test & docs để nghiệp vụ tự phục vụ — xây sản phẩm dữ liệu, không xây báo cáo.
• Phân vai: DE đưa dữ liệu vào, AE biến thành mô hình đáng tin, DA rút insight. Kỹ năng AE = SQL sâu + dbt + mô hình hoá + Git/CI + hiểu nghiệp vụ + giao tiếp.
• Quy trình chuẩn giống kỹ sư phần mềm: yêu cầu → mô hình hoá → dbt model + test + docs → PR/review → CI → deploy → phục vụ → lặp.
• Nguyên tắc: analytics-as-code, DRY, modular (staging/marts), test & document, single source of truth, semantic consistency.
• Tổ chức: hub-and-spoke (hub giữ chuẩn, spoke nhúng domain) cân bằng nhất quán và linh hoạt khi mở rộng.
• Bối cảnh ngân hàng: AE dựng lớp mart chuẩn hoá để các phòng tự phân tích trên cùng một nguồn — giảm tải analyst và chấm dứt cảnh "mỗi báo cáo một con số".