# Chọn data mesh hay fabric? Đọc sơ đồ tổ chức của khách trước

> Ba kiến trúc dữ liệu thường bị so sánh như ba món công nghệ, nhưng thật ra chúng trả lời ba câu hỏi khác nhau về chuyện ai làm gì trong công ty khách hàng.

Bản gốc: https://fdetimes.net/vi/phan-tich/chon-stack-du-lieu-data-mesh-data-fabric/

Trong bài viết năm 2020 đặt nền móng cho data mesh, Dehghani không bắt đầu bằng một công cụ. Vấn đề được nêu ra nằm ở con người: mô hình kho dữ liệu tập trung buộc một đội trung tâm phải tự làm sạch, đồng bộ và mã hóa mọi dữ liệu đổ về.

Đó là một vấn đề về sơ đồ tổ chức, không phải về database. Thế nhưng khi một FDE ngồi vào phòng họp và khách hỏi "bên mình có nên làm data mesh không?", câu trả lời thường xoay quanh vendor, công cụ và chi phí cloud.

Câu trả lời tốt hơn bắt đầu từ chỗ khác. Mesh, fabric và kho trung tâm không phải ba phiên bản của cùng một thứ. Mỗi mô hình giả định công ty khách được tổ chức theo một kiểu khác, và nếu bạn chọn sai giả định thì stack tốt đến đâu cũng sẽ kẹt.

## Data mesh đổi cơ cấu trước khi đổi công cụ

AWS định nghĩa data mesh là mô hình quản lý dữ liệu phân tán, dùng cho những bài toán chia sẻ dữ liệu khó. Chi tiết quan trọng nằm ở câu tiếp theo: trách nhiệm quản lý dữ liệu được chia theo chức năng hoặc domain nghiệp vụ, chứ không đặt hết vào một đội.

Bài gốc của Dehghani nêu bốn nguyên tắc. Một là quyền sở hữu dữ liệu và kiến trúc được phân tán theo domain. Hai là dữ liệu được coi như sản phẩm. Ba là có một nền tảng tự phục vụ. Bốn là "federated computational governance", tức governance được liên kết giữa các bên và thực thi bằng code.

Bạn hãy đọc lại bốn nguyên tắc đó với tư cách người phải triển khai. Theo AWS, mỗi đội domain phải áp dụng tư duy sản phẩm cho các dataset họ cung cấp, còn governance trở thành trách nhiệm chung của cả tổ chức.

Nói cách khác, đội bán hàng phải có người hiểu schema, cam kết chất lượng và trả lời khi đội khác phàn nàn về dữ liệu của họ.

Khách hàng chưa có những con người đó thì mesh chỉ là một sơ đồ đẹp trên slide. Đó là lý do câu hỏi đầu tiên về mesh luôn là "domain nào có năng lực làm chủ dữ liệu?", chứ không phải "dùng công cụ catalog nào?".

## Mesh không xóa đội trung tâm, chỉ đổi việc của họ

Ngay cả khi các domain đã đủ người, mesh vẫn kèm một gánh nặng dễ bị đánh giá thấp, và nó nằm ngay trong bốn nguyên tắc. Một nền tảng tự phục vụ không tự mọc ra: phải có ai đó xây và vận hành nó cho mọi domain dùng.

Governance liên kết cũng có giá của nó. Khi trách nhiệm được chia sẻ, các domain phải thống nhất chuẩn chung rồi viết thành code để thực thi, và mỗi lần đổi chuẩn là một vòng phối hợp giữa nhiều đội.

Suy ra từ đó, mesh dời gánh nặng chứ không xóa nó: đội trung tâm thôi làm sạch dữ liệu cho người khác, chuyển sang làm nền tảng và luật chơi. Khi tính chi phí cho khách, bạn nên đặt khoản này lên bàn ngay từ đầu.

## Fabric không hỏi ai là chủ của dữ liệu

IBM mô tả data fabric là kiến trúc giúp truy cập dữ liệu rộng khắp, và nhấn mạnh rằng nó không phải một phần mềm mà là một cách tiếp cận thiết kế. Điều này đáng nhớ khi có vendor chào bán "một data fabric" đóng gói sẵn.

James Serra, trong bài viết năm 2021, đưa ra cách phân biệt hữu ích nhất để chọn kiến trúc theo tổ chức: fabric lấy công nghệ làm trung tâm, còn mesh tập trung vào thay đổi tổ chức. Ông viết thêm rằng fabric chủ yếu là chuyện tích hợp dữ liệu về mặt kỹ thuật, và không quy định ai làm việc đó hay ai sở hữu dữ liệu.

Vì không đụng đến chuyện ai sở hữu dữ liệu, fabric thường dễ được khách gật đầu hơn: bạn không phải thuyết phục giám đốc khối nào nhận thêm trách nhiệm. IBM còn cho rằng fabric có thể chạy song song với mesh và thường giúp mesh hoạt động tốt hơn, nên đây không phải lựa chọn loại trừ nhau.

Nhưng chính điểm đó cũng là giới hạn của fabric. Nếu nỗi đau thật của khách là không ai chịu trách nhiệm về chất lượng dữ liệu, một lớp tích hợp dù tinh vi đến đâu cũng chỉ giúp mọi người truy cập dữ liệu tệ nhanh hơn.

## Kho trung tâm chưa lỗi thời

Giữa những cuộc tranh luận về phân tán, dễ quên rằng mô hình tập trung giải quyết được nhiều việc. Một data hub, theo cách Wikipedia mô tả, không chỉ chứa dữ liệu như hồ hay kho thông thường. Nó còn khử trùng lặp, kiểm soát chất lượng, bảo mật và cung cấp một bộ dịch vụ truy vấn chuẩn hóa.

Với một công ty chỉ có một đội dữ liệu năm người và các phòng ban còn lại chủ yếu dùng Excel, đó chính là thứ họ cần. Nút thắt mà Dehghani mô tả chỉ thật sự đau khi số domain và số nguồn dữ liệu vượt quá sức một đội trung tâm.

Bảng dưới đây xếp ba mô hình cạnh nhau theo câu hỏi tổ chức mà mỗi mô hình trả lời. Cột "khách hợp khi" là gợi ý suy luận từ đặc điểm của từng mô hình, không phải một quy tắc cứng.

| Câu hỏi | Kho / hub trung tâm | Data fabric | Data mesh |
|---|---|---|---|
| Ai chuẩn bị dữ liệu? | Một đội trung tâm làm sạch, đồng bộ, bảo mật | Không quy định, tùy tổ chức | Từng đội domain, coi dataset là sản phẩm |
| Governance nằm ở đâu? | Tập trung | Không quy định ai sở hữu | Chia sẻ giữa các domain, thực thi bằng code |
| Bản chất thay đổi | Một nơi phục vụ chuẩn hóa | Thiết kế công nghệ để tích hợp, truy cập | Thay đổi tổ chức |
| Khách hợp khi | Ít domain, một đội dữ liệu mạnh | Nhiều nguồn rời rạc, chưa muốn đổi cơ cấu | Domain đủ người và đủ năng lực làm chủ dữ liệu |
| Dấu hiệu chọn sai | Đội trung tâm thành hàng đợi của cả công ty | Truy cập nhanh hơn nhưng không ai chịu trách nhiệm chất lượng | Domain không có người nhận vai trò chủ sản phẩm dữ liệu, hoặc không ai lo nền tảng tự phục vụ |

## Thử hình dung một chuỗi bán lẻ

Giả sử bạn được cử đến một chuỗi bán lẻ có ba khối: bán hàng, kho vận và marketing. Khối bán hàng có một nhóm kỹ sư riêng và đã quen làm API. Kho vận chạy trên một hệ thống cũ, chỉ có một người hiểu cấu trúc bảng. Marketing kéo số liệu bằng file xuất tay mỗi tuần.

Nếu bạn đề xuất mesh cho cả ba khối ngay từ đầu, bạn đang đòi kho vận và marketing áp dụng tư duy sản phẩm cho dữ liệu trong khi họ không có ai để làm việc đó. Dự án sẽ đứng ở bước họp phân quyền.

Một lộ trình hợp lý hơn là dựng một hub trung tâm làm điểm chuẩn hóa chung, thêm lớp tích hợp kiểu fabric để nối hệ thống kho vận cũ mà không phải viết lại. Sau đó chọn khối bán hàng làm domain thử nghiệm đầu tiên theo hướng mesh, vì đó là nơi duy nhất có người đủ sức nhận trách nhiệm.

**Điểm mấu chốt:** Kiến trúc dữ liệu phải đi theo năng lực tổ chức hiện có của khách, và chỉ nên tiến dần sang phân tán khi từng domain đủ người để làm chủ dữ liệu.

Cách làm này không phải thỏa hiệp. Nó đúng với nhận định của IBM rằng fabric và mesh có thể cùng tồn tại, và giữ cho mỗi bước đều gắn với một đội có thật trong sơ đồ tổ chức.

## Buổi discovery nên mở đầu bằng câu hỏi nào?

Với dữ liệu, việc tìm hiểu khách trước khi chốt kiến trúc nên bắt đầu từ con người chứ không phải từ hạ tầng.

Trong buổi đầu tiên với khách, bạn có thể hỏi bốn câu. Ai đang làm sạch dữ liệu hôm nay? Yêu cầu dữ liệu mới phải xếp hàng bao lâu? Khi một con số sai, ai là người bị gọi? Có domain nào đã có kỹ sư riêng không? Bốn câu trả lời này thường đủ để bạn biết khách đang ở cột nào của bảng trên.

Với developer Việt Nam muốn chuyển sang FDE, đây là kỹ năng nên luyện và nên thể hiện. Khi đọc job description, hãy để ý các cụm như "work with stakeholders across business units" hay "data ownership". Đó là tín hiệu công việc đòi hỏi bạn đọc được tổ chức chứ không chỉ viết được pipeline.

## Một dòng CV, trước và sau

Lấy đúng dự án chuỗi bán lẻ ở trên. Bản trước, kiểu thường gặp: "Xây data pipeline cho chuỗi bán lẻ bằng công cụ X." Dòng này chỉ cho thấy bạn biết dùng một công cụ.

Bản sau: "Chuỗi bán lẻ ba khối, chỉ khối bán hàng có kỹ sư riêng: dựng hub trung tâm, nối hệ thống kho vận cũ qua lớp tích hợp, thí điểm cho khối bán hàng tự sở hữu dữ liệu." Thứ tự là bối cảnh tổ chức, quyết định kiến trúc, lý do.

Nhà tuyển dụng đọc bản sau sẽ thấy bạn hiểu điều mà ba kiến trúc này đặt cược vào. Công cụ sẽ thay đổi theo từng mùa vendor, còn câu hỏi ai trong công ty khách sẵn sàng chịu trách nhiệm về dữ liệu thì luôn cần được trả lời trước tiên.

**Thử ngay tuần này:**

- Lấy một hệ thống dữ liệu bạn đang làm, vẽ ra ai tạo ra, ai làm sạch và ai dùng từng bảng chính. Sau đó đánh dấu xem đội nào đang là nút thắt.
- Đọc bài gốc của Dehghani trên martinfowler.com và viết lại bốn nguyên tắc, mỗi nguyên tắc một câu, kèm một điều kiện tổ chức cần có để nguyên tắc đó chạy được.
- Viết lại một dòng trong CV về dự án dữ liệu theo dạng: bối cảnh tổ chức, lựa chọn kiến trúc, lý do chọn.

## Nguồn

- [What Is a Data Mesh? - AWS](https://aws.amazon.com/what-is/data-mesh)

- [Data Mesh Principles and Logical Architecture](https://martinfowler.com/articles/data-mesh-principles.html)

- [What is a data fabric?](http://ibm.com/think/topics/data-fabric)

- [Data Fabric defined](https://www.jamesserra.com/archive/2021/06/data-fabric-defined/)

- [Data hub](https://en.wikipedia.org/wiki/Data_hub)