Kiến trúc nền tảng Cloudera: Data Services, SDX và Object Store

Cloudera được dựng theo một nguyên tắc đơn giản nhưng có sức nặng: tách rời ba việc khác nhau — giữ dữ liệu, làm việc trên dữ liệu, và quản trị dữ liệu. Mỗi việc là một lớp riêng, có thể thay đổi và mở rộng độc lập.

Cụ thể: các dịch vụ dữ liệu (Data Services) — pipeline, kho phân tích, cơ sở dữ liệu vận hành, streaming, AI — chạy bên trên một nền lưu trữ dùng chung, và tất cả đều đi qua SDX (Shared Data Experience), lớp quản trị dùng chung của nền tảng. Hiểu ba lớp này là hiểu vì sao Cloudera có thể phục vụ nhiều đội, nhiều loại công việc mà vẫn chỉ có một bản dữ liệu và một bộ chính sách.

Toàn cảnh nền tảng theo lớp

Cách gọn nhất để nắm kiến trúc Cloudera là nhìn nó thành các lớp xếp chồng: hạ tầng ở đáy, định dạng bảng mở phía trên, rồi các lớp quản trị và dịch vụ, cho tới các engine khai thác ở trên cùng. Mỗi lớp có một trách nhiệm, và các lớp thay đổi độc lập với nhau.

Đọc từ dưới lên:

• Hạ tầng — nền tảng chạy trên đám mây công cộng (AWS, Azure, Google Cloud), đám mây riêng, hoặc hạ tầng Hadoop sẵn có trong trung tâm dữ liệu. Cùng một nền tảng, chỗ chạy thay đổi mà cách làm việc không đổi.
• Định dạng bảng mở (Apache Iceberg) — một bản dữ liệu duy nhất mà mọi lớp trên cùng đọc, ở định dạng có đặc tả công khai.
• Lakehouse Services — dịch vụ nền tự bảo trì bảng Iceberg (nén file, dọn ảnh chụp) và nhân bản dữ liệu; đây là lớp lo phần vận hành nặng nhọc mà nếu không có thì mỗi đội phải tự viết script. Xem Apache Iceberg và Vận hành Iceberg trong production.
• Cloudera SDX — lớp bảo mật và quản trị dùng chung: đặt chính sách một lần, áp cho mọi dịch vụ. Xem SDX.
• Quản lý metadata (REST Catalog và Metastore) — nơi các engine tìm ra bảng nào đang có, ở đâu; REST Catalog là chuẩn mở cho phép cả engine bên ngoài nền tảng đọc chung bảng Iceberg mà không sao chép.
• Dịch vụ dữ liệu và AI — trên cùng là các engine khai thác: xử lý luồng, Data Flow, Data Engineering, Data Warehouse, Cloudera AI, và cả engine bên thứ ba đọc bảng Iceberg qua REST catalog. Tất cả làm việc trên cùng một bản dữ liệu bên dưới.

Điểm cần nhớ ở bức tranh này: một bản dữ liệu ở đáy, một lớp quản trị ở giữa, nhiều engine ở trên — kể cả engine không thuộc Cloudera. Đó là điều làm nó trở thành một nền tảng mở, không phải một hộp đóng: bạn không bị khóa vào một engine, vì định dạng bảng và catalog đều mở.

flowchart TB
  subgraph DS["Dịch vụ dữ liệu — Data Services"]
    direction LR
    S1["Data Engineering<br/>Apache Spark"]
    S2["Data Warehouse<br/>phân tích SQL"]
    S3["Operational Database<br/>thời gian thực"]
    S4["Data Flow · Streaming<br/>NiFi · Kafka · Flink"]
    S5["Cloudera AI<br/>workbench · inference"]
  end
  subgraph SDXL["SDX — Shared Data Experience · lớp quản trị dùng chung"]
    direction LR
    G1["Bảo mật · phân quyền<br/>Apache Ranger"]
    G2["Data Catalog · Data Lineage<br/>Apache Atlas"]
    G3["Observability<br/>tài nguyên · chi phí"]
  end
  subgraph ST["Nền lưu trữ — một bản dữ liệu duy nhất"]
    direction LR
    T1["Bảng mở<br/>Apache Iceberg"]
    T2["Cloudera Object Store<br/>nền Apache Ozone · tương thích S3"]
  end
  DS ==>|"đường dữ liệu — đọc và ghi trực tiếp"| ST
  SDXL -.->|"đẩy chính sách xuống<br/>áp tại chỗ trong từng dịch vụ"| DS
  DS -.->|"metadata · nhật ký truy cập gửi lên"| SDXL
  T1 --- T2

Quy ước đọc sơ đồ: mũi tên đậm là đường dữ liệu; mũi tên đứt là đường chính sách và metadata.

Chú ý cách vẽ ở trên: SDX không nằm trên đường dữ liệu. Dịch vụ đọc và ghi thẳng xuống nền lưu trữ. Chính sách được đẩy xuống và áp ngay bên trong từng dịch vụ, còn metadata cùng nhật ký truy cập thì đi ngược lên. Nói cách khác, quản trị không phải một trạm kiểm soát mà mọi truy vấn phải xếp hàng đi qua — nó là bộ luật mà mỗi dịch vụ mang theo mình. Chi tiết này quan trọng khi thiết kế cho tải cao: thêm một bộ luật không thêm một chặng trên đường dữ liệu.

Ba lớp, ba trách nhiệm rõ ràng

① Nền lưu trữ — Cloudera Object Store

Đáy của nền tảng là Cloudera Object Store: kho lưu trữ đối tượng tương thích S3 (Simple Storage Service — giao thức lưu trữ đối tượng đã thành chuẩn thực tế), xây trên dự án mã nguồn mở Apache Ozone. Vài điểm đáng chú ý:

• Quy mô hàng tỉ đối tượng (theo Cloudera công bố) — đủ cho dữ liệu lịch sử nhiều năm của một nhà mạng hay một ngân hàng bán lẻ, không phải chia nhỏ ra nhiều hệ thống.
• Tương thích S3 nghĩa là công cụ và thư viện viết cho giao thức S3 dùng được ngay — kể cả khi kho lưu trữ đó nằm trong trung tâm dữ liệu của bạn, không phải trên đám mây.
• Chạy được tại chỗ: đây là mảnh ghép cho phép giữ trải nghiệm kiểu đám mây mà dữ liệu vẫn ở trong nước, trong hạ tầng của tổ chức.

Bên trên kho đối tượng, dữ liệu phân tích được tổ chức thành bảng Apache Iceberg — một định dạng bảng mở. “Mở” ở đây có nghĩa cụ thể: nhiều engine khác nhau đọc cùng một bảng, không cần mỗi engine giữ một bản sao riêng theo định dạng riêng của nó.

② Lớp dịch vụ dữ liệu — Data Services

Mỗi loại công việc có một dịch vụ chuyên trách, nhưng tất cả cùng đọc một nền dữ liệu:

Nhu cầu nghiệp vụ	Dịch vụ Cloudera	Nền công nghệ mở
Làm sạch, biến đổi dữ liệu lô lớn	Data Engineering	Apache Spark trên Iceberg
Báo cáo, phân tích SQL nhiều người dùng đồng thời	Data Warehouse	Apache Iceberg
Tra cứu bản ghi tức thời, ứng dụng vận hành	Operational Database	Apache HBase
Thu thập, định tuyến, làm giàu dữ liệu	Data Flow	Apache NiFi
Xử lý luồng sự kiện liên tục	Streaming	Apache Kafka + Apache Flink
Thu dữ liệu từ thiết bị ở biên	Edge Management	—
Phát triển, triển khai, phục vụ mô hình	Cloudera AI	—

Điểm mấu chốt: các dịch vụ này không phải bảy sản phẩm rời rạc ghép lại. Chúng chia sẻ cùng một nền lưu trữ và cùng một lớp quản trị, nên dữ liệu do pipeline Spark sinh ra là dữ liệu mà kho phân tích thấy ngay — không có bước xuất/nhập ở giữa.

③ Lớp quản trị dùng chung — SDX

SDX (Shared Data Experience) là nơi đặt bảo mật, phân quyền và chính sách một lần, áp cho mọi dịch vụ. Thay vì khai báo “ai được xem cột số căn cước” bảy lần cho bảy công cụ, bạn khai báo một lần trên dữ liệu — mọi dịch vụ chạm vào dữ liệu ấy đều tuân theo.

SDX gồm các thành phần chính:

• Bảo mật & phân quyền — xác thực, RBAC (Role-Based Access Control — phân quyền theo vai trò), kiểm soát tới mức cột và hàng, che dữ liệu nhạy cảm.
• Data Catalog — khám phá, phân loại và gắn nhãn dữ liệu nhạy cảm, để biết mình đang có gì và cái gì cần bảo vệ.
• Data Lineage — truy vết nguồn gốc: con số trên báo cáo đến từ bảng nào, qua bước xử lý nào.
• Observability — giám sát tài nguyên và chi phí, biết công việc nào đang tiêu bao nhiêu.
• Data Visualization — dựng dashboard ngay trên dữ liệu đã được quản trị.

Xem chi tiết ở SDX và Data Catalog & Lineage.

Vì sao tách “lưu trữ – dịch vụ – quản trị” lại quan trọng?

Đây là phần đáng dừng lại lâu nhất, vì nó quyết định chi phí và rủi ro của cả nền tảng trong nhiều năm. Ba lớp tách rời cho ba kết quả:

Một bản dữ liệu

Khi lưu trữ tách khỏi dịch vụ, thêm một loại công việc mới không kéo theo một bản sao dữ liệu mới. Đội phân tích, đội khoa học dữ liệu và ứng dụng vận hành cùng nhìn vào một bảng Iceberg. Con số họ báo cáo vì thế khớp nhau — không phải vì có người đi đối chiếu, mà vì chúng đến từ cùng một chỗ.

Nhiều loại công việc

Vì dịch vụ tách khỏi lưu trữ, bạn mở rộng năng lực tính toán cho từng loại việc một cách độc lập. Pipeline ban đêm cần nhiều tài nguyên thì cấp thêm cho Data Engineering, không ảnh hưởng tới kho phân tích đang phục vụ người dùng ban ngày. Cần thử một engine mới cho một bài toán mới? Nó đọc thẳng bảng Iceberg sẵn có.

Một bộ chính sách

Vì quản trị tách thành lớp riêng, chính sách gắn vào dữ liệu chứ không gắn vào công cụ. Thêm dịch vụ thứ tám vào nền tảng, nó thừa hưởng nguyên bộ chính sách đang có. Khi cơ quan quản lý hỏi “ai đã truy cập dữ liệu này, và con số này từ đâu ra”, câu trả lời nằm ở một nơi.

💡 Điều này có nghĩa gì với bạn?

Một bản dữ liệu, nhiều loại công việc, một bộ chính sách. Đó là toàn bộ tinh thần của kiến trúc này. Mỗi khi cân nhắc thêm một công cụ dữ liệu mới, câu hỏi đáng hỏi là: nó có đọc chung bản dữ liệu và có chịu chung bộ chính sách không? Nếu không, bạn đang thêm một kho riêng lẻ nữa.

Liên hệ thực tế

Tình huống	Kiến trúc trả lời thế nào
Kho phân tích và mô hình AI cần cùng bộ dữ liệu khách hàng	Cùng đọc một bảng Iceberg — không sao chép, không lệch số
Pipeline ban đêm nặng, sợ ảnh hưởng báo cáo ban ngày	Mỗi dịch vụ có năng lực tính toán riêng trên nền lưu trữ chung
Quy định mới về che dữ liệu cá nhân	Đặt chính sách một lần trên SDX — mọi dịch vụ áp theo
Kiểm toán hỏi con số trên báo cáo từ đâu ra	Data Lineage truy ngược tới bảng nguồn và bước xử lý
Muốn nền tảng ngoài đọc dữ liệu mà không sao chép	Truy cập bảng Iceberg trực tiếp — xem Iceberg

Các sai lầm dễ mắc phải

• Đặt chính sách ở từng dịch vụ thay vì ở lớp quản trị. Nó chạy được lúc đầu, nhưng tới dịch vụ thứ tư thì việc rà soát trở thành gánh nặng thường trực.
• Chọn định dạng lưu trữ đóng cho dữ liệu lõi. Định dạng bảng mở giữ cho bạn quyền đổi engine sau này mà không phải chuyển đổi lại dữ liệu.
• Đo nền tảng chỉ bằng tốc độ truy vấn. Số bản sao phải đồng bộ và thời gian trả lời một câu hỏi kiểm toán thường mới là thứ tốn tiền dài hạn.

Đọc tiếp

Triển khai & Cloud Bursting Ba kiểu triển khai Public Cloud, On-premises, Hybrid — và cách mở rộng sang đám mây lúc cao điểm mà không nhân bản dữ liệu.

SDX — Shared Data Experience Lớp quản trị dùng chung: đặt bảo mật, phân quyền và chính sách một lần, áp cho mọi dịch vụ dữ liệu.

Ghi chú

Tổng hợp & diễn giải tiếng Việt theo tài liệu Cloudera. BSD Insight — đối tác Cloudera tại Việt Nam — liên hệ tư vấn.