1. Định nghĩa Data Product với Metadata, Schema và Data Dictionary
Mỗi Data Product cần được đóng gói như một tài sản độc lập với đầy đủ thông tin mô tả để các đơn vị kinh doanh khác có thể tự phục vụ (self-serve).
Chúng ta sẽ tạo một cấu trúc YAML định nghĩa metadata, schema và tài liệu mô tả (Data Dictionary) cho Data Product "Customer_Segments" thuộc domain "Marketing".
Đường dẫn: /opt/data-mesh/products/marketing/customer_segments.yaml
Tạo file cấu hình với nội dung hoàn chỉnh sau:
cat > /opt/data-mesh/products/marketing/customer_segments.yaml
Verify: Kiểm tra cú pháp YAML và đọc lại file để đảm bảo cấu trúc đúng.
python3 -c "import yaml; print(yaml.safe_load(open('/opt/data-mesh/products/marketing/customer_segments.yaml'))['name'])"
Kết quả mong đợi: In ra tên product là "customer_segments" mà không báo lỗi.
2. Cấu hình ACL và Role-Based Access Control (RBAC) trên Iceberg Catalog
Để chia sẻ dữ liệu an toàn, chúng ta cần gán quyền truy cập dựa trên vai trò (Role) và đơn vị kinh doanh (Domain) thông qua Iceberg Catalog (ví dụ: Nessie hoặc Glue) tích hợp với LDAP/AD.
Ở đây, chúng ta sẽ cấu hình ACL trong file metadata của Iceberg Table để giới hạn quyền chỉ cho domain "Sales" và "Marketing" được đọc, trong khi domain "Finance" bị chặn.
Đường dẫn config: /opt/iceberg-catalog/acl/customer_segments_acl.json
Tạo file định nghĩa chính sách truy cập:
cat > /opt/iceberg-catalog/acl/customer_segments_acl.json
Áp dụng chính sách này vào Catalog (giả sử sử dụng CLI của Nessie hoặc Glue wrapper):
curl -X PUT "http://iceberg-catalog:8080/v1/namespaces/marketing/tables/customer_segments/acl" \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $ICEBERG_ADMIN_TOKEN" \
--data-binary @/opt/iceberg-catalog/acl/customer_segments_acl.json
Verify: Kiểm tra xem ACL đã được áp dụng bằng cách thử truy cập với user không có quyền.
spark-sql --conf "spark.sql.catalog.marketing=iceberg" \
--conf "spark.sql.catalog.marketing.uri=http://iceberg-catalog:8080/v1" \
-e "SELECT * FROM marketing.customer_segments LIMIT 1" \
2>&1 | grep -i "permission denied"
Kết quả mong đợi: Nếu user hiện tại không thuộc group được phép, lệnh sẽ báo lỗi "Permission Denied" hoặc "Access Denied".
3. Triển khai cơ chế phát hành dữ liệu (publish) và đăng ký (register) giữa các đơn vị
Quy trình này mô phỏng việc Domain Owner "Marketing" phát hành Data Product và Domain Consumer "Sales" đăng ký để nhận dữ liệu.
Chúng ta sẽ sử dụng một service đăng ký (Registry Service) chạy trên Kubernetes để quản lý trạng thái của Data Product.
Đường dẫn script: /opt/data-mesh/scripts/publish_register.sh
Tạo script để gọi API đăng ký và phát hành:
cat > /opt/data-mesh/scripts/publish_register.sh
Chạy script để kích hoạt quy trình:
bash /opt/data-mesh/scripts/publish_register.sh
Verify: Kiểm tra trạng thái trong Registry Service (giả sử lưu vào DB hoặc file log).
curl -s http://registry-service:8080/v1/products/customer_segments | jq '.status, .consumers[]'
Kết quả mong đợi: JSON trả về hiển thị status là "published" và list consumers có chứa "sales-team" với trạng thái "pending" hoặc "approved" (tùy logic approval).
4. Sử dụng Kubernetes Service Mesh (Istio) để bảo mật đường truyền giữa các services
Để đảm bảo dữ liệu chỉ được truyền tải giữa các service đã được ủy quyền, chúng ta sử dụng Istio Policy (AuthorizationPolicy) để kiểm soát giao tiếp giữa Service Consumer và Data Service.
Đường dẫn config: /opt/istio-configs/authorization-policy-data-access.yaml
Tạo file định nghĩa chính sách bảo mật cho Data Service:
cat > /opt/istio-configs/authorization-policy-data-access.yaml
Áp dụng chính sách vào cluster Kubernetes:
kubectl apply -f /opt/istio-configs/authorization-policy-data-access.yaml
Verify: Kiểm tra xem chính sách đã được áp dụng bằng cách list các policy trong namespace.
kubectl get authorizationpolicy -n data-mesh -o yaml | grep -A 5 "allow-sales-access"
Kết quả mong đợi: Thấy cấu hình AuthorizationPolicy với các rule cho phép "sales-data-consumer" và từ chối "finance-system".
Test kết nối thực tế (phải chạy từ trong pod sales):
curl -v http://marketing-data-service.data-mesh:8080/api/v1/query 2>&1 | grep "403 Forbidden"
Kết quả mong đợi: Nếu gọi từ pod không có quyền (ví dụ finance), sẽ nhận lỗi 403. Nếu gọi từ sales (đã cấu hình đúng service account), sẽ nhận 200 OK.
5. Tạo dashboard giám sát truy cập và sử dụng dữ liệu theo đơn vị kinh doanh
Chúng ta cần một dashboard để theo dõi ai đang truy cập Data Product nào, bao nhiêu lần, và từ domain nào, sử dụng Prometheus và Grafana.
Đầu tiên, cấu hình Prometheus để thu thập metric từ Istio (envoy proxy) và Data Service.
Đường dẫn config: /opt/prometheus/prometheus-data-mesh.yml
cat > /opt/prometheus/prometheus-data-mesh.yml
Áp dụng cấu hình Prometheus:
kubectl apply -f /opt/prometheus/prometheus-data-mesh.yml
Tiếp theo, tạo file Dashboard Grafana (định dạng JSON) để hiển thị metric truy cập theo Domain.
Đường dẫn: /opt/grafana-dashboards/data-mesh-access.json
cat > /opt/grafana-dashboards/data-mesh-access.json
Import dashboard vào Grafana (giả sử Grafana chạy trên host localhost:3000):
curl -X POST "http://localhost:3000/api/dashboards/import" \
-H "Content-Type: application/json" \
-d @/opt/grafana-dashboards/data-mesh-access.json \
-u admin:admin
Verify: Truy cập trực tiếp vào Grafana và xem biểu đồ.
curl -s "http://localhost:3000/api/search?type=dashboard" | jq '.[] | select(.title == "Data Mesh Access Monitor")'
Kết quả mong đợi: JSON trả về chứa thông tin dashboard đã được import thành công với ID và tiêu đề "Data Mesh Access Monitor".
Điều hướng series:
Mục lục: Series: Series: Xây dựng nền tảng Data Mesh phi tập trung với Apache Iceberg, dbt và Kubernetes để chia sẻ dữ liệu an toàn giữa các đơn vị kinh doanh
« Phần 3: Triển khai dbt để xử lý và chuẩn hóa dữ liệu trong Data Mesh
Phần 5: Tự động hóa vận hành và giám sát hệ thống Data Mesh »