KA 6 · Bài 7

Data Integration & Interoperability

Data Integration & Interoperability (DII) là lĩnh vực tri thức mô tả các quy trình di chuyển và hợp nhất dữ liệu giữa các kho, ứng dụng và tổ chức. Bài này bao quát định nghĩa & mục tiêu, business drivers, các pattern tích hợp (ETL/ELT, batch, real-time, CDC, replication, virtualization, messaging/event, API/SOA, EAI, ESB), mức độ trễ (latency), data migration & consolidation, chuẩn interoperability và canonical data model, cùng vai trò, công cụ, chỉ số và các thực hành tốt.

1. Định nghĩa & Mục tiêu

DII là gì và hướng tới điều gì

Data Integration (Tích hợp dữ liệu) là việc hợp nhất (consolidate) dữ liệu thành các dạng nhất quán, dù ở dạng vật lý (di chuyển và lưu vào một nơi) hay ảo (truy cập tại chỗ). Data Interoperability (Khả năng liên thông dữ liệu) là khả năng nhiều hệ thống khác nhau trao đổi và hiểu dữ liệu của nhau. DII quản lý sự vận động và hợp nhất dữ liệu bên trong và giữa các data store, ứng dụng và tổ chức.

Theo DAMA-DMBOK2, mục tiêu của DII gồm:

Cung cấp dữ liệu an toàn ở đúng định dạng, đúng thời điểm, tới nơi cần dùng, với chi phí và độ trễ phù hợp.
Hợp nhất dữ liệu cả về vật lý và ảo vào các "hub" chung, giảm chi phí và độ phức tạp của các giải pháp điểm-điểm (point-to-point).
Hỗ trợ nhu cầu BI, analytics, MDM và hiệu quả vận hành thông qua các luồng dữ liệu được tái sử dụng.
Giảm chi phí và độ phức tạp bằng cách phát triển mô hình và giao diện dùng chung; quản lý rủi ro tuân thủ với các chuẩn chung.

Ghi nhớ: DII được xem là lĩnh vực then chốt vì hầu hết tổ chức có hàng trăm đến hàng nghìn kết nối dữ liệu. Nếu không quản lý tập trung, chi phí bảo trì các kết nối điểm-điểm tăng theo cấp số nhân.

2. Business Drivers

Vì sao tổ chức đầu tư vào DII

Các động lực nghiệp vụ chính thúc đẩy quản lý DII:

Driver	Diễn giải
Quản lý độ phức tạp & chi phí	Số kết nối điểm-điểm bùng nổ theo O(n²). Một giải pháp tích hợp dùng chung (hub-and-spoke, ESB) giảm mạnh số giao diện phải xây và bảo trì.
Hỗ trợ BI, analytics & MDM	Data warehouse, data lake, MDM đều phụ thuộc vào việc trích xuất, làm sạch và nạp dữ liệu từ nhiều nguồn một cách tin cậy.
Tuân thủ & quản trị	Quy định (GDPR, SOX, HIPAA) đòi hỏi kiểm soát chặt việc dữ liệu di chuyển đi đâu, ai truy cập, và có lineage rõ ràng.
Tái sử dụng & nhất quán	Chuẩn hoá luồng và mô hình dữ liệu chung giúp dữ liệu nhất quán giữa các ứng dụng, tránh mỗi nơi hiểu một kiểu.
M&A và hiện đại hoá	Sáp nhập, thay hệ thống legacy, di trú lên cloud đều đòi hỏi data migration và consolidation quy mô lớn.
Vận hành thời gian thực	Nhu cầu dữ liệu tức thời (fraud detection, IoT, cá nhân hoá) đẩy tổ chức từ batch sang real-time/streaming.

3. Khái niệm cốt lõi

Từ vựng nền tảng của DII

Khái niệm	Ý nghĩa
Extract	Chọn và trích dữ liệu từ hệ nguồn (database, file, API, queue). Có thể full extract hoặc incremental.
Transform	Chuyển đổi để phù hợp đích: định dạng, chuẩn hoá cấu trúc, ngữ nghĩa, làm sạch, tính toán, tách/gộp, khử trùng lặp, tổng hợp.
Load	Ghi dữ liệu vào hệ đích (initial load, incremental/delta load, full refresh).
Latency (độ trễ)	Độ chênh thời gian giữa lúc dữ liệu sinh ra ở nguồn và lúc sẵn dùng ở đích: batch, near-real-time, real-time.
Orchestration	Điều phối thứ tự, phụ thuộc, lịch chạy và xử lý lỗi của các job tích hợp.
Data Migration	Di chuyển dữ liệu một lần (one-time) từ hệ cũ sang hệ mới.
Replication	Duy trì các bản sao dữ liệu giống nhau trên nhiều nơi để phục vụ hiệu năng/tính sẵn sàng.
Canonical Data Model	Mô hình dữ liệu chung, trung lập giữa các ứng dụng, dùng làm "ngôn ngữ chung" khi trao đổi.
Interaction Model (Publish–Subscribe / Request–Reply)	Cách các ứng dụng trao đổi: publish/subscribe cho phân phối, request-reply cho gọi đồng bộ.
Data Virtualization	Truy cập và kết hợp dữ liệu từ nhiều nguồn không sao chép vật lý, tạo view ảo hợp nhất.

4. Context Diagram

Inputs → Activities → Deliverables

Sơ đồ ngữ cảnh (context diagram) của DII theo DMBOK2:

Thành phần	Nội dung
Inputs (Đầu vào)	Business goals & strategies; nhu cầu dữ liệu (data needs); data models & data flows; semantic/technical metadata; kiến trúc dữ liệu & ứng dụng; chuẩn dữ liệu; quy tắc bảo mật & tuân thủ.
Activities (Hoạt động)	(1) Plan & Analyze: xác định yêu cầu tích hợp, khảo sát nguồn, profiling dữ liệu; (2) Design: thiết kế giải pháp, kiến trúc, mô hình mapping, orchestration; (3) Develop: xây data services, mappings, luồng ETL/CDC; (4) Implement & Monitor: triển khai, giám sát, xử lý lỗi và điều chỉnh.
Deliverables (Đầu ra)	Kiến trúc DII; data services & interfaces; data mappings & transformation specs; luồng tích hợp (ETL/CDC/replication); dữ liệu đã hợp nhất tại đích (DW, hub, MDM); tài liệu & metadata lineage.
Suppliers (Nhà cung cấp)	Data Producers, Data Architects, Data Stewards, Data Governance, chủ hệ nguồn (source system owners), nhà cung cấp bên ngoài.
Participants (Người tham gia)	Data Integration Architect, ETL/Integration Developer, Data Analyst, DBA, Data Modeler, Data Steward.
Consumers (Người tiêu dùng)	Ứng dụng đích, data warehouse/marts, MDM hub, BI & analytics teams, hệ vận hành, đối tác trao đổi dữ liệu.
Tools & Techniques	Công cụ ETL/ELT, ESB/message broker, data virtualization, CDC, API/data services; profiling, mapping, model canonical.

5. ETL và ELT

Hai thứ tự xử lý — khi nào dùng cái nào

ETL (Extract – Transform – Load): trích xuất, biến đổi ở tầng trung gian (staging/engine) rồi mới nạp vào đích. ELT (Extract – Load – Transform): trích xuất, nạp thô vào đích trước, biến đổi ngay trong hệ đích (thường là data warehouse/lake mạnh về tính toán như MPP, cloud DW).

Tiêu chí	ETL	ELT
Nơi transform	Ở engine/staging trung gian trước khi load	Trong hệ đích, sau khi load thô
Phù hợp	Đích năng lực tính toán hạn chế; cần làm sạch/che dữ liệu nhạy cảm trước khi nạp	Đích mạnh (MPP, cloud DW, data lake); dữ liệu lớn, cần linh hoạt schema-on-read
Ưu điểm	Kiểm soát chất lượng & bảo mật trước khi vào đích; đích gọn, chuẩn hoá	Tận dụng sức mạnh đích; nạp nhanh dữ liệu thô; giữ raw để tái xử lý
Nhược điểm	Engine ETL có thể thành nút cổ chai; kém linh hoạt với big data	Dữ liệu thô/nhạy cảm nằm trong đích; cần quản trị & bảo mật đích tốt
Bối cảnh điển hình	Data warehouse truyền thống on-prem	Cloud data warehouse (Snowflake, BigQuery, Redshift), data lake

Khi nào chọn: Chọn ELT khi đích có sức mạnh xử lý dồi dào và bạn muốn giữ dữ liệu thô để tái xử lý về sau (ưu thế trên cloud/big data). Chọn ETL khi phải làm sạch, chuẩn hoá hoặc che (mask) dữ liệu nhạy cảm trước khi đưa vào đích, hoặc khi đích không đủ mạnh để transform.

6. Các pattern tích hợp

Batch, real-time, CDC, replication, virtualization, messaging, API/SOA, EAI, ESB

Pattern	Mô tả & khi dùng
Batch (theo lô)	Xử lý một khối lớn bản ghi theo lịch (đêm, mỗi giờ). Đơn giản, throughput cao; phù hợp DW, báo cáo. Độ trễ cao.
Real-time / Streaming	Xử lý sự kiện ngay khi phát sinh (Kafka, Kinesis, Flink). Độ trễ thấp; dùng cho fraud, IoT, cá nhân hoá, dashboard vận hành.
CDC (Change Data Capture)	Chỉ bắt và lan truyền phần thay đổi (insert/update/delete) từ nguồn, thường qua đọc transaction log. Giảm tải nguồn, cho near-real-time. Kỹ thuật: log-based, trigger-based, timestamp/diff-based.
Replication	Tạo & đồng bộ các bản sao dữ liệu giống nhau (đồng bộ/bất đồng bộ) để tăng hiệu năng đọc, sẵn sàng cao, phân tán địa lý. Không biến đổi dữ liệu.
Data Virtualization	Tạo lớp view ảo hợp nhất truy vấn nhiều nguồn tại chỗ, không sao chép vật lý. Nhanh triển khai, dữ liệu luôn tươi; nhưng phụ thuộc hiệu năng nguồn.
Messaging / Event-driven	Ứng dụng trao đổi qua message/event bất đồng bộ (queue, topic). Mô hình publish–subscribe hoặc point-to-point; tách rời (decouple) hệ thống, chịu tải và co giãn tốt.
API / SOA (Service-Oriented)	Truy cập dữ liệu qua dịch vụ chuẩn (REST, SOAP, gRPC). Request–reply đồng bộ; tái sử dụng, đóng gói dữ liệu như data service, phù hợp microservices.
EAI (Enterprise Application Integration)	Khuôn mẫu tích hợp các ứng dụng doanh nghiệp qua giao diện & message dùng chung, thay cho tích hợp điểm-điểm rời rạc.
ESB (Enterprise Service Bus)	Xương sống tích hợp trung tâm: định tuyến, biến đổi định dạng, điều phối message giữa nhiều ứng dụng theo mô hình hub-and-spoke, thường dùng canonical model.

DSP (Data Service Platform) & hub-and-spoke: Xu hướng DMBOK2 nhấn mạnh là chuyển từ tích hợp điểm-điểm sang mô hình hub-and-spoke qua ESB/data services để mỗi hệ chỉ tích hợp một lần với hub, giảm mạnh số giao diện.

7. Latency — mức độ trễ dữ liệu

Batch · Near-real-time · Real-time

Mức latency	Đặc điểm	Kỹ thuật tiêu biểu
Batch	Độ trễ cao (giờ/ngày); xử lý khối lớn theo lịch; kinh tế cho khối lượng lớn.	ETL/ELT theo lịch, bulk load.
Near-real-time (micro-batch)	Trễ vài giây đến vài phút; chạy theo chu kỳ ngắn hoặc bắt thay đổi liên tục.	CDC, micro-batch, trickle feed.
Real-time / event-driven	Trễ mili giây đến giây; xử lý ngay khi có sự kiện; đòi hỏi hạ tầng streaming.	Streaming (Kafka/Flink), messaging pub-sub, synchronous API.

DMBOK2 phân biệt thêm đồng bộ (synchronous) — bên gọi chờ phản hồi trước khi tiếp tục (nhất quán nhưng dễ nghẽn dây chuyền) — và bất đồng bộ (asynchronous) — gửi rồi tiếp tục, xử lý độc lập (chịu tải & tách rời tốt hơn, nhưng dữ liệu có thể tạm thời không đồng bộ).

8. Data Migration & Consolidation

Di trú một lần và hợp nhất dữ liệu

Data Migration là việc di chuyển dữ liệu một lần từ hệ nguồn (thường là legacy) sang hệ đích mới — khi thay ERP, hiện đại hoá, lên cloud, hay sau M&A. Đây là dự án rủi ro cao: cần profiling nguồn, mapping kỹ, làm sạch, chạy thử (mock/trial load), đối chiếu (reconciliation) và kế hoạch fallback.

Data Consolidation là hợp nhất dữ liệu từ nhiều nguồn về một nơi tập trung (DW, hub, MDM) để có "một phiên bản sự thật". Consolidation là mục tiêu thường trực, còn migration thường là sự kiện một lần.

Profiling nguồn: hiểu cấu trúc, chất lượng, khối lượng và các ngoại lệ dữ liệu trước khi di trú.
Mapping & transform: ánh xạ trường nguồn sang đích, xử lý khác biệt định dạng & ngữ nghĩa.
Trial load & reconciliation: chạy thử nhiều vòng, đối chiếu số lượng và giá trị nguồn–đích.
Cutover & fallback: lên lịch chuyển đổi, có phương án quay lui nếu thất bại.

Cảnh báo: Đánh giá thấp chất lượng dữ liệu nguồn là nguyên nhân phổ biến khiến dự án migration trễ hạn và vượt ngân sách. Luôn profiling và làm sạch trước, đừng để đến lúc load mới phát hiện.

9. Interoperability standards & Canonical Data Model

Ngôn ngữ chung để liên thông

Chuẩn interoperability giúp các hệ thống/tổ chức khác nhau trao đổi và hiểu dữ liệu: định dạng & giao thức chung (XML, JSON, EDI, REST/SOAP), chuẩn ngành (HL7/FHIR cho y tế, ISO 20022/SWIFT cho tài chính, ACORD cho bảo hiểm), và chuẩn ngữ nghĩa (RDF, OWL, XBRL). Chuẩn giúp giảm biến đổi tuỳ biến và tránh khoá cứng cặp hệ thống.

Canonical Data Model là mô hình dữ liệu chung, trung lập giữa mọi ứng dụng: mỗi hệ chỉ cần chuyển đổi giữa định dạng riêng và canonical, thay vì phải hiểu định dạng của từng hệ khác. Nhờ đó, với n hệ thống chỉ cần n phép chuyển đổi (mỗi hệ ↔ canonical) thay vì tới n×(n−1) chuyển đổi điểm-điểm.

Không có canonical	Có canonical model
Mỗi cặp hệ thống cần mapping riêng → bùng nổ giao diện O(n²)	Mỗi hệ chỉ map với mô hình chung → tuyến tính O(n)
Thay đổi một hệ ảnh hưởng lan sang nhiều hệ	Cô lập thay đổi tại lớp mapping của hệ đó
Khó chuẩn hoá ngữ nghĩa	Ngữ nghĩa & định dạng chuẩn hoá tại một chỗ

10. Vai trò (Roles)

Ai làm gì trong DII

Vai trò	Trách nhiệm
Data Integration Architect	Thiết kế kiến trúc tích hợp tổng thể, chọn pattern (ESB, hub-and-spoke, virtualization), định nghĩa canonical model & chuẩn.
ETL / Integration Developer	Xây và bảo trì luồng ETL/ELT/CDC, data services, mappings; kiểm thử và tối ưu hiệu năng.
Data Analyst	Phân tích yêu cầu, profiling nguồn, xác định quy tắc mapping & transform.
Data Modeler	Mô hình hoá đích và canonical data model; đảm bảo nhất quán ngữ nghĩa.
DBA	Tối ưu, cấu hình replication, đảm bảo hiệu năng & sẵn sàng của nguồn/đích.
Data Steward	Đảm bảo chất lượng, ý nghĩa & quy tắc dữ liệu được tôn trọng trong luồng tích hợp.
Data Governance	Ban hành chuẩn, chính sách bảo mật & tuân thủ cho việc di chuyển dữ liệu; giám sát lineage.

11. Tools & Techniques

Công cụ và kỹ thuật

Nhóm	Ví dụ & ghi chú
ETL/ELT tools	Informatica PowerCenter, IBM DataStage, Talend, Microsoft SSIS, Pentaho, dbt (ELT), AWS Glue, Azure Data Factory.
Data virtualization	Denodo, TIBCO Data Virtualization, IBM Cloud Pak for Data.
Messaging / streaming	Apache Kafka, RabbitMQ, ActiveMQ, AWS Kinesis, Apache Flink/Spark Streaming.
ESB / integration platform	MuleSoft, IBM Integration Bus, Apache Camel, WSO2, TIBCO BusinessWorks.
CDC tools	Oracle GoldenGate, Debezium, Qlik Replicate, HVR.
Kỹ thuật	Data profiling, mapping specification, canonical modeling, orchestration/scheduling, error handling & reconciliation, lineage tracking.

12. Metrics

Đo lường hiệu quả DII

Nhóm chỉ số	Ví dụ
Availability / Reliability	Tỉ lệ job thành công, uptime của luồng, số lần lỗi & thời gian phục hồi.
Volume / Throughput	Số bản ghi/giao dịch xử lý mỗi chu kỳ; dung lượng dữ liệu di chuyển.
Latency / Speed	Thời gian từ nguồn đến đích; thời gian chạy job so với cửa sổ batch (batch window).
Data Quality	Tỉ lệ bản ghi lỗi/bị loại, số vi phạm quy tắc, kết quả reconciliation nguồn–đích.
Cost / Efficiency	Chi phí vận hành, số giao diện được tái sử dụng, mức giảm tích hợp điểm-điểm.
Coverage	Tỉ lệ giao diện tuân theo chuẩn/canonical; số nguồn được đưa vào giải pháp tích hợp chung.

13. Quan hệ với DW/BI & MDM

DII là nền tảng cho các KA khác

Với Data Warehousing & BI: DII cung cấp các luồng ETL/ELT/CDC nạp dữ liệu vào data warehouse, marts và data lake — là "hạ tầng ống dẫn" mà BI & analytics dựa vào. Nếu DII yếu, dữ liệu trong DW sẽ trễ, thiếu hoặc sai.

Với Master & Reference Data (MDM): MDM cần DII để thu thập bản ghi master từ nhiều nguồn, đối sánh (match) & hợp nhất (merge), rồi phân phối "golden record" ngược lại các hệ tiêu dùng. Ngược lại, canonical model & master data chuẩn hoá giúp các luồng tích hợp nhất quán hơn.

Ghi nhớ: DII là lĩnh vực nền — Data Warehousing/BI (KA9) và Master/Reference Data (KA8) đều đứng trên nó. Đầu tư đúng vào DII sẽ nâng chất lượng của toàn bộ chuỗi giá trị dữ liệu.

14. Best practices & Pitfalls

Nên và không nên

Best practices	Pitfalls (cạm bẫy)
Chuyển từ tích hợp điểm-điểm sang hub-and-spoke/ESB và data services tái dùng.	Để giao diện điểm-điểm sinh sôi → bùng nổ O(n²), bảo trì tốn kém.
Xây canonical data model & tuân thủ chuẩn ngành.	Mỗi luồng tự định nghĩa cấu trúc riêng → ngữ nghĩa lệch nhau.
Profiling & đánh giá chất lượng nguồn trước khi thiết kế luồng.	Giả định dữ liệu nguồn sạch → phát hiện lỗi lúc load, phải làm lại.
Chọn latency theo nhu cầu nghiệp vụ thật, không real-time hoá mọi thứ.	Ép real-time không cần thiết → chi phí & độ phức tạp tăng vô ích.
Ghi rõ lineage & metadata, có giám sát & xử lý lỗi bài bản.	Luồng "hộp đen" không lineage → khó truy vết, khó tuân thủ.
Thiết kế cho khả năng phục hồi: retry, idempotent, reconciliation.	Không có reconciliation → sai lệch dữ liệu âm thầm giữa nguồn & đích.
Áp bảo mật khi dữ liệu di chuyển: mã hoá, mask dữ liệu nhạy cảm.	Bỏ qua bảo mật khi truyền/di trú → rò rỉ, vi phạm tuân thủ.