ETL, ELT, Data Modeling, Data Engineering & AI RAG – Nền tảng Hệ dữ liệu Hiện đại

Ở Phần trước, chúng ta đã xây nền móng về Data cơ bản: DIKW, OLTP – OLAP, ACID – BASE, Data Lake – Warehouse – Lakehouse. Nhưng đó chỉ là “bề mặt”. Để dữ liệu thực sự mang lại giá trị, doanh nghiệp cần một hệ thống: dữ liệu phải chảy đúng – được mô hình đúng – được vận hành đúng – và được AI hiểu đúng.

Phần này đi sâu vào 4 mảnh ghép then chốt trong mọi hệ sinh thái dữ liệu hiện đại: ETL/ELT, Data Modeling, Data Engineering và AI thời dữ liệu (Embedding, Vector DB, RAG, Data Agent).
Đây là những khái niệm quyết định dữ liệu có “sống” trong doanh nghiệp được hay không.

Dành cho bạn — người muốn đi xa hơn, làm chủ hệ thống dữ liệu và AI theo chuẩn Microsoft Fabric, Snowflake và Databricks.

Tóm tắt nhanh

• ETL/ELT là cách dữ liệu di chuyển — sai flow = sai toàn bộ hệ thống.
• Batch vs Streaming quyết định tốc độ phản hồi của doanh nghiệp.
• Data Modeling là xương sống BI & AI — không có model đúng thì AI không thể hiểu.
• Data Engineering đảm bảo dữ liệu đúng, đầy đủ, an toàn, truy vết được.
• Embedding – Vector DB – RAG – Data Agent là tương lai của phân tích dữ liệu.

1. ETL – ELT – Batch – Streaming

Dữ liệu chỉ có giá trị khi nó di chuyển. ETL/ELT là “hệ mạch máu” của toàn bộ Data Platform. Nếu mạch máu sai, mọi bộ phận phía sau (Modeling, BI, AI) đều sai theo.

1.1 ETL – Extract, Transform, Load (Mô hình truyền thống)

ETL xử lý dữ liệu trước khi nạp vào Warehouse. Phổ biến trong thời kỳ on-prem (SSIS, Informatica).

SOURCE → EXTRACT → TRANSFORM → LOAD → WAREHOUSE

1.2 ELT – Extract, Load, Transform (chuẩn Cloud & Lakehouse)

Trong Cloud, compute rẻ – scale linh hoạt → nên đổ dữ liệu vào Lakehouse trước rồi mới transform.

SOURCE → EXTRACT → LOAD → (TRANSFORM in Lakehouse)

1.3 Batch Processing – Xử lý theo lô

• Chạy theo giờ/ngày/tuần
• Ổn định, dễ kiểm soát
• Tối ưu cho báo cáo định kỳ

1.4 Streaming Processing – Xử lý thời gian thực

• Dữ liệu tới đâu xử lý tới đó
• Dùng trong fraud detection, IoT, quảng cáo real-time
• Fabric hỗ trợ Real-Time Hub và KQL Database

2. Data Modeling nâng cao

Data Modeling là xương sống của BI & AI. Một model sai → KPI sai → quyết định sai. Microsoft, Snowflake và Databricks đều khẳng định: Data Modeling quan trọng hơn công cụ.

2.1 Fact Table – bảng đo lường

• Chứa số liệu giao dịch: doanh số, tồn kho, chi phí
• Thường có grain (độ chi tiết) cố định
• Lớn nhất trong mô hình

2.2 Dimension Table – bảng mô tả

• Chứa thuộc tính mô tả (customer, product, region)
• Ít thay đổi nhưng rất quan trọng

2.3 Star Schema – mô hình Kimball chuẩn

         DimCustomer
              |
DimDate — FactSales — DimProduct
              |
          DimRegion

2.4 Slowly Changing Dimension (SCD) – thay đổi theo thời gian

• Type 0: không thay đổi
• Type 1: overwrite
• Type 2: lưu lịch sử (chuẩn nhất cho BI)
• Type 3–6: nâng cao

2.5 Các lỗi modeling phổ biến tại DN Việt Nam

• Fact thiếu grain → double count
• Dimension thiếu key → join sai
• Không dùng surrogate key
• Nhồi mọi thứ vào Fact (fact-đầy-đủ-đủ-thứ)

3. Data Engineering — Pipeline, Orchestration, Governance, Lineage

Nếu Data Modeling là “bộ não”, thì Data Engineering là “hệ tuần hoàn” giữ cho dữ liệu chảy đúng và sạch.

3.1 Data Pipeline

Data Pipeline là toàn bộ chuỗi bước mà dữ liệu phải đi qua: từ lúc xuất phát ở hệ thống nguồn (ERP, CRM, eCommerce, file Excel…) cho đến khi trở thành dữ liệu sẵn sàng dùng cho BI/AI.
Mỗi bước trong pipeline có nhiệm vụ rõ ràng: lấy dữ liệu, làm sạch, chuẩn hóa, biến đổi và nạp vào mô hình đích.

SOURCE → INGESTION → TRANSFORMATION → MODEL → BI / AI

Trong Microsoft Fabric, có nhiều “con đường” để xây pipeline, tùy vào mức độ kỹ thuật và nhu cầu:

• Dataflows Gen2 – công cụ low-code cho phép trích xuất, biến đổi dữ liệu bằng giao diện kéo thả. Rất phù hợp cho team BI, analyst, hoặc khi cần xử lý dữ liệu dạng bảng từ nguồn như Excel, SQL, SharePoint, OData…
• Data Factory (Pipeline orchestration) – “nhạc trưởng” điều phối luồng dữ liệu, kết nối nhiều nguồn, gọi nhiều activity (copy, transform, notebook…) và sắp xếp thứ tự chạy, thời gian chạy, điều kiện chạy. Đây là nơi bạn xây dựng các pipeline sản xuất cho toàn doanh nghiệp.
• Notebook (Spark) – môi trường code (Python, PySpark, Scala, SQL) chạy trên Spark cluster. Dùng khi cần xử lý dữ liệu lớn (big data), machine learning, hoặc các logic phức tạp mà Dataflows/Data Factory khó làm được. Notebook thường là “bộ não tính toán” trong các pipeline nặng.
• KQL Pipeline (real-time) – pipeline dành cho dữ liệu log, event, telemetry với ngôn ngữ Kusto Query Language (KQL).
  Rất phù hợp cho phân tích thời gian thực (real-time monitoring, IoT, hệ thống log).

3.2 Orchestration

Orchestration là việc điều phối các pipeline và các bước xử lý dữ liệu theo một kịch bản có trật tự, có điều kiện và có giám sát. Thay vì từng job chạy “mạnh ai nấy chạy”, orchestration đảm bảo:

• Retry logic – khi một bước nào đó trong pipeline bị lỗi (do mạng, do nguồn tạm thời không phản hồi…), hệ thống có thể tự động thử lại (retry 3 lần, delay 5 phút…). Nhờ đó, pipeline không “chết” chỉ vì một lỗi tạm thời.
• Dependency mapping – xác định mối quan hệ phụ thuộc giữa các bước.
  Ví dụ: pipeline nạp dữ liệu bán hàng chỉ được phép chạy sau khi pipeline nạp danh mục sản phẩm đã hoàn thành.
  Điều này giúp đảm bảo dữ liệu luôn ở trạng thái hợp lệ.
• Trigger theo lịch (schedule) – thiết lập cho pipeline chạy tự động vào các mốc thời gian cố định: mỗi giờ, mỗi đêm,
  đầu tháng, cuối quý… Đây là cách doanh nghiệp đảm bảo dữ liệu luôn được cập nhật mà không cần thao tác tay.
• Trigger theo sự kiện (event-based) – pipeline được kích hoạt khi có một sự kiện xảy ra,
  ví dụ: có file mới trong thư mục Data Lake, có bản ghi mới trong queue, có message mới trong Event Hub…
  Điều này rất hữu ích cho các kịch bản realtime hoặc near-realtime.

3.3 Data Governance (theo Microsoft Purview)

Data Governance là tập hợp các chính sách, quy trình và công cụ để quản lý dữ liệu một cách an toàn, có kiểm soát và có trách nhiệm. Microsoft Purview là nền tảng giúp triển khai Data Governance trên hệ sinh thái Microsoft.

Một số khái niệm cốt lõi trong Data Governance:

• Bảo mật (Security) – xác định ai được xem, sửa, tải, hay quản lý dữ liệu nào.
  Bao gồm phân quyền theo role (RBAC), theo nhóm, theo đối tượng (row-level security), tích hợp với Azure AD / Entra ID.
  Mục tiêu: dữ liệu nhạy cảm không “trôi nổi” ngoài tầm kiểm soát.
• Bloodline (Lineage) – bản chất chính là dòng dõi dữ liệu (data lineage).
  Nó cho phép vẽ lại sơ đồ: dữ liệu được sinh ra ở đâu, đi qua những hệ thống nào, được biến đổi ra sao, cuối cùng xuất hiện ở báo cáo nào.
  Điều này cực kỳ quan trọng khi kiểm toán, điều tra lỗi hoặc giải thích KPI cho ban lãnh đạo.
• Catalog (Metadata Catalog) – nơi tập trung thông tin về dữ liệu (metadata): bảng nào, cột nào, dữ liệu gì, mô tả kinh doanh, owner là ai, nhãn phân loại…
  Người dùng có thể “search dữ liệu” giống như search tài liệu trong công ty.
  Catalog giúp dữ liệu trở thành tài sản dùng chung, không bị “mất dấu” theo từng bộ phận.
• Data masking – kỹ thuật che giấu thông tin nhạy cảm (như số CMND, số thẻ, email, số điện thoại, lương…) đối với những người không được phép xem đầy đủ.
  Ví dụ: hiển thị ****-***-1234 thay vì full số thẻ.
  Masking giúp bảo vệ dữ liệu cá nhân nhưng vẫn cho phép sử dụng dữ liệu cho phân tích.

3.4 Data Lineage – truy vết dữ liệu

Data Lineage là khả năng truy vết hành trình của dữ liệu:
nó bắt đầu từ đâu, đi qua những bước xử lý nào, được join/transform/aggregate ra sao,
rồi cuối cùng xuất hiện trong dashboard, báo cáo hay mô hình AI như thế nào.

Nói cách khác: lineage giúp bạn trả lời câu hỏi “con số này từ đâu ra?”.

ERP / CRM / POS
        ↓ 
        ↓ (ingestion)
        ↓ 
    Data Lake / Lakehouse
        ↓ 
        ↓ (transform: clean, join, aggregate)
        ↓ 
  Semantic Model / Warehouse
        ↓ 
        ↓ (publish)
        ↓ 
   Power BI / Data Agent / API

Trong Microsoft Fabric và Purview, lineage có thể hiển thị trực quan thành các sơ đồ:
click vào một báo cáo → xem được nó dùng dataset nào → dataset lấy từ Lakehouse/BQ nào → Lakehouse được build từ nguồn nào…
Điều này giúp:

• Giải thích số liệu cho business khi có sự sai lệch.
• Tìm điểm lỗi trong pipeline (chỉ cần xem bước nào thay đổi gần nhất).
• Đảm bảo tuân thủ (compliance) với các quy định về dữ liệu.

ERP → Ingestion → Lakehouse → Semantic Model → Power BI → Data Agent

4. AI thời dữ liệu — Embedding, Vector Database, RAG, Data Agent

Đây là phần “đỉnh cao” của hệ sinh thái dữ liệu hiện đại.
Microsoft Fabric, Azure OpenAI, Databricks và Snowflake đều đang chuyển sang mô hình AI-native Data Platform.

4.1 Embedding – máy hiểu ngữ nghĩa

Embedding chuyển văn bản, số, hình ảnh thành vector 1.536 chiều (tuỳ model).

4.2 Vector Database

• Index theo similarity
• Hỗ trợ metadata filtering
• Dùng cho semantic search

4.3 RAG – Retrieval Augmented Generation

Tách việc “tìm kiếm thông tin” ra khỏi việc “sinh câu trả lời”.

QUESTION → RETRIEVE (Vector DB) → CONTEXT → LLM → ANSWER

4.4 Data Agent — tương lai của phân tích dữ liệu

• Hiểu cấu trúc dữ liệu
• Sinh SQL/DAX
• Tự động trực quan hóa
• Giải thích insight bằng ngôn ngữ tự nhiên

5. Kết luận

Bài này đã trình bày rõ bức tranh toàn diện về hệ sinh thái dữ liệu hiện đại: từ cách dữ liệu chảy, cách mô hình hóa, cách vận hành, đến cách AI hiểu và khai thác dữ liệu.

Bạn đã nắm từ nền tảng → vận hành → ứng dụng AI.
Từ đây, bạn có thể tự tin triển khai bất kỳ dự án Data, BI hoặc AI nào theo chuẩn Microsoft Fabric, Databricks, Snowflake và hệ sinh thái hiện đại.