[11] Phân biệt: Database, Data Warehouse, Data Mart, Data Lake, Data Lakehouse, Data Mesh P2

Tiếp theo phần 1 Phân Biệt: Database, Data Warehouse, Data Mart, Data Lake, Data Lakehouse, Data Mesh P1. Hôm nay chúng ta tìm hiểu tiếp các khái niệm Data Lakehouse. Data Fabric, Data Mesh, … Ngoài ra, trong bài sẽ đề cập một số nguồn tài liệu tham khảo giúp bạn tự tìm hiểu sâu hơn về khái niệm này.

Data Lakehouse

A Data Lakehouse combines the advantages of a Data Lake and a Data Warehouse.

Data Fabric

Data Fabric được thiết kế để giúp các tổ chức giải quyết các vấn đề phức tạp về dữ liệu và các trường hợp sử dụng bằng cách quản lý dữ liệu của họ bất kể loại ứng dụng, nền tảng và nơi dữ liệu được lưu trữ. Với Data Fabric, sẽ cho phép truy cập liền mạch và chia sẻ dữ liệu trong môi trường dữ liệu phân tán. Tương tự như Data Lakehouse, kết hợp Data Warehouse và Data Lake. Nhưng tiến thêm một bước nữa và cũng tích hợp dữ liệu từ các ứng dụng với nhau. Data Fabrics tiến thêm một bước nữa và cung cấp cho bạn các dịch vụ hỗ trợ kiểm soát, giám sát, … cho bạn và công ty.

Data Mesh (lưới dữ liệu)

Mặc dù lưới dữ liệu (Data Mesh) nhằm mục đích giải quyết nhiều vấn đề tương tự như kết cấu dữ liệu (Data Fabric). Cụ thể là: khó khăn trong việc quản lý dữ liệu trong môi trường dữ liệu không đồng nhất. Data Mesh giải quyết vấn đề theo một cách cơ bản khác. Nói tóm lại, trong khi kết cấu dữ liệu (data fabric) tìm cách xây dựng một lớp quản lý ảo duy nhất trên dữ liệu phân tán, thì lưới dữ liệu (data mesh) khuyến khích các nhóm phân tán quản lý dữ liệu khi họ thấy phù hợp. Mặc dù với một số quy định quản trị chung.

Next Data Platform là Data Mesh?

Data Mesh là “ngôi sao mới nổi” khi nhắc về kiểu lưu trữ dữ liệu hiện nay. Trước khi tìm hiểu Data Mesh là gì, chúng ta cùng đi qua 2 khái niệm quan trọng: Monolithic Vs. Microservices Architecture

Monolithic architecture

Trong kiến trúc phần mềm (software engineering), kiến trúc nguyên khối (monolithic architecture) được coi là mô hình truyền thống, đó là xây dựng ứng dụng như một khối thống nhất khép kín và độc lập với các ứng dụng khác.

Kiến trúc này rất thuận tiện cho các giai đoạn đầu trong vòng đời của bất kỳ dự án nào. Bởi vì giai đoạn này dễ dàng phát triển và triển khai mã. Nói cách khác, cách tiếp cận nguyên khối cho phép mọi thứ được giải phóng cùng một lúc. Và như với mọi thứ trong cuộc sống, cách tiếp cận này có các dòng chảy của nó bao gồm:

Tốc độ phát triển chậm hơn (Slower development speed) – Một ứng dụng lớn, nguyên khối làm cho việc phát triển phức tạp hơn và chậm hơn.
Áp dụng công nghệ mới (New technology adoption) – Bất kỳ thay đổi hoặc nâng cấp nào trong công nghệ được sử dụng đều ảnh hưởng đến toàn bộ ứng dụng, khiến quyết định này trở nên tốn kém và khó khăn.
Phát triển và triển khai Khả năng mở rộng (Development and deployment Scalability) – Khi hệ thống phát triển để nâng cấp một thành phần duy nhất sẽ rất khó khăn và bất kỳ thay đổi nhỏ nào đối với một ứng dụng nguyên khối cũng yêu cầu triển khai lại toàn bộ nguyên khối.

Microservices architecture

Mặt khác, phương pháp Microservices là một phương pháp kiến trúc dựa trên một loạt các dịch vụ có thể triển khai độc lập. Các dịch vụ này có cơ sở dữ liệu và logic nghiệp vụ riêng với một mục tiêu cụ thể. Cập nhật, thử nghiệm, triển khai và mở rộng diễn ra trong mỗi dịch vụ. Điều này giúp loại bỏ nhược điểm của cách tiếp cận nguyên khối. Tuy nhiên “như mọi khi” lại tạo ra nhược điểm mới. Ví dụ:

Thêm độ phức tạp khi phát triển (Added development complexity) – Microservices thêm phức tạp hơn so với kiến trúc nguyên khối vì có nhiều dịch vụ hơn ở nhiều nơi do nhiều nhóm tạo ra. Nếu quá trình phát triển không được quản lý đúng cách, nó sẽ dẫn đến tốc độ phát triển chậm hơn và hiệu suất hoạt động kém.
Chi phí cơ sở hạ tầng cao (High infrastructure costs) – Mỗi dịch vụ vi mô mới có thể có chi phí riêng cho bộ thử nghiệm, sách phát triển khai, cơ sở hạ tầng lưu trữ, công cụ giám sát, v.v.
Các thách thức về gỡ lỗi (Debugging challenges) – Mỗi microservice đều có một bộ nhật ký riêng, điều này làm cho việc gỡ lỗi trở nên phức tạp hơn.
Thiếu quyền sở hữu rõ ràng (Lack of clear ownership) – Khi có nhiều dịch vụ hơn được giới thiệu, số lượng nhóm điều hành các dịch vụ đó cũng vậy. Theo thời gian, rất khó để biết các dịch vụ sẵn có mà nhóm có thể tận dụng và liên hệ với ai để được hỗ trợ.

Data Mesh là gì?

Data mesh is the data platform version of microservices (lưới dữ liệu là phiên bản nền tảng dữ liệu của microservices.)

Theo Zhamak Dehghani – Consultant in ThoughtWorks, người đưa ra định nghĩa này đầu tiên: “Data Mesh (lưới dữ liệu) là một loại kiến trúc nền tảng dữ liệu bao gồm tính phổ biến của dữ liệu trong doanh nghiệp (embraces the ubiquity of data in the enterprise) bằng cách tận dụng thiết kế tự phục vụ (self-serve design), theo định hướng theo mảng (leveraging a domain-oriented). Vay mượn lý thuyết của Eric Evans về thiết kế theo hướng mảng (theory of domain-driven design), một mô hình phát triển phần mềm linh hoạt, có thể mở rộng phù hợp với cấu trúc và ngôn ngữ mã của bạn với miền kinh doanh tương ứng của nó ”.

Nói một cách đơn giản hơn, Không giống như cơ sở hạ tầng dữ liệu nguyên khối truyền thống xử lý việc nhập, lưu trữ, chuyển đổi và xuất dữ liệu trong một hồ dữ liệu trung tâm, lưới dữ liệu hỗ trợ người tiêu dùng dữ liệu phân tán, theo mảng cụ thể và chế độ xem “data-as-a-product”, với mỗi miền xử lý các đường ống dẫn dữ liệu của riêng mình. Mô kết nối các miền này và các tài sản dữ liệu liên quan của chúng là một lớp khả năng tương tác chung áp dụng cùng một cú pháp và các tiêu chuẩn dữ liệu.

Nhiều công ty cho đến nay đã tận dụng một kho dữ liệu duy nhất (single data warehouse) được kết nối với nhiều nền tảng kinh doanh thông minh (business intelligence platforms). Các giải pháp như vậy thường gây ra nợ kỹ thuật (Technical debt) đáng kể trong việc duy trì đường ống trung tâm bởi một nhóm nhỏ các kỹ sư dữ liệu. Điều này tạo ra tắc nghẽn trong nền tảng dữ liệu của tổ chức.

*Technical debt là nợ kỹ thuật. Là khối lượng công việc cần phải được giải quyết trong một dự án về công nghệ thông tin.

Data monolithic architecture

Đối với nhiều tổ chức, kiến trúc nguyên khối dữ liệu (data monolithic architecture) có nhiều luồng (flows), bao gồm:

Đường ống ETL trung tâm cung cấp cho các nhóm kỹ thuật dữ liệu ít quyền kiểm soát hơn đối với việc tăng khối lượng dữ liệu.
Các trường hợp sử dụng dữ liệu khác nhau yêu cầu các kiểu biến đổi khác nhau, đặt nặng lên nền tảng trung tâm.

Các hồ dữ liệu tập trung như vậy dẫn đến các nhà sản xuất dữ liệu bị ngắt kết nối. Gây ra hậu quả những người tiêu dùng dữ liệu thiếu kiên nhẫn . Tệ hơn là, một nhóm kỹ thuật dữ liệu tồn đọng đang phải vật lộn để bắt kịp với nhu cầu của doanh nghiệp.

Instead, domain-oriented data architectures, like data meshes, give teams the best of both worlds: a centralized database (or a distributed data lake) with domains (or business areas) responsible for handling their own pipelines. As Zhamak argues, data architectures can be most easily scaled by being broken down into smaller, domain-oriented components.

Thay vào đó, các kiến trúc dữ liệu hướng mảng (domain-oriented data architectures), như lưới dữ liệu (data mesh). Sẽ cung cấp cho các nhóm điều tốt nhất của cả hai thế giới: cơ sở dữ liệu tập trung – a centralized database (hoặc hồ dữ liệu phân tán – distributed data lake) với các mảng kinh doanh (hoặc khu vực kinh doanh) – domains (or business areas) chịu trách nhiệm xử lý các đường ống dẫn của riêng họ. Như Zhamak lập luận, các kiến trúc dữ liệu (data architectures) có thể dễ dàng mở rộng quy mô nhất bằng cách được chia nhỏ thành các thành phần hướng mảng kinh doanh.

Nói một cách đơn giản hơn, các yêu cầu về cơ sở hạ tầng dữ liệu của công ty bạn càng phức tạp và khắt khe, thì tổ chức của bạn càng có nhiều khả năng được hưởng lợi từ lưới dữ liệu.

Ví dụ Data mesh ở mức “high-level”:

A data mesh architecture diagram is composed of three separate components: data sources, data infrastructure, and domain-oriented data pipelines managed by functional owners.

Phân biệt Data Lakehouse vs Data Mesh: “Data Mesh is a paradigm – Lakehouse is a platform”. Để phân biệt chi tiết hơn, mọi người xem tại video này nhé!

Tài liệu tham khảo

Do đây là những khái niệm lý thuyết, nên mình tham khảo định nghĩa học thuật của nó. Dưới đây là link tham khảo tại từng khái niệm các anh/chị tham khảo nhé:

https://www.zuar.com/blog/data-mart-vs-data-warehouse-vs-database-vs-data-lake/
https://www.holistics.io/blog/data-lake-vs-data-warehouse-vs-data-mart/
https://medium.com/@mhatout/data-mesh-as-i-know-it-d30d9fc1ea69
https://www.javatpoint.com/types-of-databases
https://www.atlassian.com/microservices/microservices-architecture/microservices-vs-monolith
https://www.montecarlodata.com/blog-what-is-a-data-mesh-and-how-not-to-mesh-it-up/
https://martinfowler.com/articles/data-monolith-to-mesh.html
https://www.databricks.com/session_na20/data-mesh-in-practice-how-europes-leading-online-platform-for-fashion-goes-beyond-the-data-lake

Tham khảo thông tin KHÓA HỌC “PHÂN TÍCH DỮ LIỆU KINH DOANH” – ONLINE/OFFLINE tại https://bit.ly/BI_MDA

Mastering Data Analytics là đơn vị dẫn đầu mảng Đào tạo kĩ năng Phân tích dữ liệu kinh doanh tại Việt Nam. Các khóa học Phân tích dữ liệu kinh doanh tại Mastering Data Analytics sẽ được khai giảng định kỳ hàng tháng, mỗi lớp học thu hút +100 anh/chị học viên – là trung tâm đào tạo Phân tích dữ liệu kinh doanh duy nhất tại Việt Nam thu hút được đông đảo học viên mỗi lớp như vậy, đã mở 34 khóa học Public trên thị trường và là đối tác đào tạo phân tích dữ liệu cho các doanh nghiệp lớn tại Việt Nam.

#dataanalyst #DataAnalytics #Data #dulieu #Analytics